Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 theurl
parameter is actually used in everytrack...
call in the JavaScript Tracker, what kind of supprised me:url
for everytrack...
call, but so does it foraction_name
, and that is a whole different story (see What exactly is action_name? (Maybe) Change its documentation. matomo-org/developer-documentation#735).pvId
in e.g. an event tracking call to thepvId
of a page view, both things are assosiacted with one another correctly, so I didn't think anurl
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 acampaign
and apath
(what relates to having anurl
in our case). Imo thepath
is related to the page view (just aspvId
) but a developer should have the opportunity to manually set it, so my approach was to add thepath
parameter to everytrack...
call (with appropriate documentation) and changeattachLastPvId
toattachLastScreenInfo
so it not only accounts for the automatical attachment ofpvId
but 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
macro
mistake.Finally I want to propose to rename
trackScreen
totrackPageView
andtrackScreenWithName
totrackPageViewWithName
since the documentation always refers to the thing they track as page views. This would also imply changingscreenId
inMatomoAction
topvId
.