I did some more research and testing regarding campaigns and added those findings to the documentation.
However, one key learning is that not only page views can have campaigns, but other actions like events or content tracking, too.
In retrospective, this seems only logical, since the campaign settings are encoded in the url parameter and it turned out that the url parameter is actually used in every track... call in the JavaScript Tracker, what kind of supprised me:
Sure, the documentation recommends setting url for every track... call, but so does it for action_name, and that is a whole different story (see matomo-org/developer-documentation#735).
From my tests I found out that when setting the pvId in e.g. an event tracking call to the pvId of a page view, both things are assosiacted with one another correctly, so I didn't think an url was needed, and my thought was why send it when it's not needed?
But to conclude I now think that every track... call should have the possibility to set a campaign and a path (what relates to having an url in our case). Imo the path is related to the page view (just as pvId) but a developer should have the opportunity to manually set it, so my approach was to add the path parameter to every track... call (with appropriate documentation) and change attachLastPvId to attachLastScreenInfo so it not only accounts for the automatical attachment of pvId but also of path. Futhermore I found out, that most track... calls can have a pvId (until now I thought only event and content tracking can have one), so I added it as parameter. If someone is interested in those additional tests, they can be found here.
I also added search and outlink tracking to the example (because I wanted to see how it looks like in the dashboard), and fixed a small macro mistake.
Finally I want to propose to rename trackScreen to trackPageView and trackScreenWithName to trackPageViewWithName since the documentation always refers to the thing they track as page views. This would also imply changing screenId in MatomoAction to pvId.
I did some more research and testing regarding campaigns and added those findings to the documentation.
However, one key learning is that not only page views can have campaigns, but other actions like events or content tracking, too. In retrospective, this seems only logical, since the campaign settings are encoded in the
urlparameter and it turned out that theurlparameter is actually used in everytrack...call in the JavaScript Tracker, what kind of supprised me:urlfor everytrack...call, but so does it foraction_name, and that is a whole different story (see matomo-org/developer-documentation#735).pvIdin e.g. an event tracking call to thepvIdof a page view, both things are assosiacted with one another correctly, so I didn't think anurlwas needed, and my thought was why send it when it's not needed?But to conclude I now think that every
track...call should have the possibility to set acampaignand apath(what relates to having anurlin our case). Imo thepathis related to the page view (just aspvId) but a developer should have the opportunity to manually set it, so my approach was to add thepathparameter to everytrack...call (with appropriate documentation) and changeattachLastPvIdtoattachLastScreenInfoso it not only accounts for the automatical attachment ofpvIdbut also ofpath. Futhermore I found out, that mosttrack...calls can have apvId(until now I thought only event and content tracking can have one), so I added it as parameter. If someone is interested in those additional tests, they can be found here.I also added search and outlink tracking to the example (because I wanted to see how it looks like in the dashboard), and fixed a small
macromistake.Finally I want to propose to rename
trackScreentotrackPageViewandtrackScreenWithNametotrackPageViewWithNamesince the documentation always refers to the thing they track as page views. This would also imply changingscreenIdinMatomoActiontopvId.