Closed peterbo closed 5 months ago
They are basically different tracker instances (one instance per variable in https://github.com/matomo-org/tag-manager/blob/3.x-dev/Template/Tag/MatomoTag.web.js#L104-L106)
Therefore they would have different IDs. At first I was wondering if this is actually something that needs to be done in Matomo core (making pageViewId global or so and sharing it across trackers). However, this doesn't work since different trackers might track different page views within the same page etc.
I was then thinking maybe we shouldn't have a tracker instance per Matomo variable but instead always use the same tracker instance when the Matomo Url and IdSite is the same. However, trackers might be configured quite differently so this might not really be a solution either.
Is there any possibility to prevent the need for different trackers in the first place? Wonder if it would work to use some lookup table or something to avoid needing multiple trackers. (I'm not so much into the topic right now.). I suppose defining maybe the custom dimensions through the dataLayer might help and be maybe the correct way? Of course it be more work on the implementation side if it is possible at all.
Hi @tsteur , thanks for your thoughts and comments on that matter! It's really hard to think about a solution that fits every use case. The fact that we have different tracker instances per configuration is good - a lot of use cases may need to have different endpoints / Site-IDs / settings.
Therefore they would have different IDs. At first I was wondering if this is actually something that needs to be done in Matomo core (making pageViewId global or so and sharing it across trackers). However, this doesn't work since different trackers might track different page views within the same page etc.
Agreed!
I was then thinking maybe we shouldn't have a tracker instance per Matomo variable but instead always use the same tracker instance when the Matomo Url and IdSite is the same. However, trackers might be configured quite differently so this might not really be a solution either.
Agreed, but this could be the right place for a potential setting - Proposals: a) When setting up the configurations, you can select a default tracker and if the tracking code should be bundled within the container. Perhaps this would be the right place to also select, if this tracker should use the same tracker instance of the tracker that was set as "default"? (not too elegant, but perhaps this idea can be optimized) b) Perhaps the setup of the custom variables could be outsourced from the tracker base configuration. Custom Variables definition should be much more flexible than setting the Site-ID/Tracker endpoint. For example, there could be a new variable to setup a Custom variable group that can be assigned to a given Tag/trigger or something?
Is there any possibility to prevent the need for different trackers in the first place? Wonder if it would work to use some lookup table or something to avoid needing multiple trackers. (I'm not so much into the topic right now.). I suppose defining maybe the custom dimensions through the dataLayer might help and be maybe the correct way? Of course it be more work on the implementation side if it is possible at all.
I think there is always a method to work around any requirement that is not directly supported. However, custom dimenions offer a lot of possibilities and it would be nice to be able to set them very flexible. As action dimensions are primarily (but not only) set with actions (downloads/events/etc.) there should be a way to have "groups" of custom dimensions that you can assign easily to certain tags or configurations. Otherwise, numbers / reports for these custom dimensions would be off/uncontrollably, because they'd be tracked with other actions / pageviews as well.
@peterbo Is this still an issue ?
Hi @AltamashShaikh - it still is, but there are also reasons for the current behaviour. This can be closed until we have a better idea of how this should work.
Events triggered (and fired) by the Matomo TagManager "native" event tag doesn't seem to include the pageView correlation, when a different "Matomo Configuration" Variable is used.
We're using different "Matomo Configuration" Variables for PageViews and Events, since the number and types of attached CustomDimensions for these two actions are fundamentally different.
The "Matomo Configuration" setting for the PageView actions is configured with "Bundle tracker" and "Register as default tracker". The "Matomo Configuration" for the Events is configured without "Bundle" and without "Register as default tracker".
Screenshot description: The first arrow points to the triggered event when I directly use the _paq variable in a tag, the second arrow points to the event that was issued by the native Tag Manager mechanism (and the alternative configuration)
The issued request to the server confirms this behaviour:
Since this is probably a quite important use case, how could that be solved /worked around?