Hello,
I have this similar situation where I need a group trigger.
The problem is that when you have variable products (on a woo site), users can select another variation (another color with another size, lets say), the view_item event fires but there no other cookie_consent_update, so the View Item Tag with the group trigger will NOT catch the 2nd view_item event. Or 3rd, an do on.
Any idea how this issue should be solved keeping the group trigger?
Thanks!
I don’t believe a group trigger is the ideal solution here. Make sure you fire GA4 initialization tag on the initialization trigger, and not cookie_consent_update. Therefore all events will be fired after the configuration.
You can set a parameter in the configuration tag “send_page_view” to “false”, and then add a separate tag for page_view that triggers on cookie_consent_update.
You can also manage consent settings in the Tag’s advanced options and manually block a tag if specific consent is not given.
Unfortunatelly there is no ideal way to block the configuration tag itself prior to consent if you want everything to work properly. But you can set the GTM to not set any events.
hope that helps,
Hey, Gasper,
Already did that. I have a GA4 config tag and a separate Page View tag.
Since cookie_consent_update is fired too late, after all the GA4 tags, your suggestion cannot be implemented. Or maybe I am missing smth. Actually this is the main problem, the consent is fired too late - and I am not sure if this is an issue with other CMPs, but for Cookie Yes this is a real problem. Their support said " Please note that the cookie_consent_update event cannot be fired before other events. This event is only triggered once the consent banner has loaded or after the user interacts with it. However, it is possible to modify the behaviour of the tag by assigning an appropriate trigger to it."
Make sure you fire GA4 initialization tag on the initialization trigger, and not cookie_consent_update. Therefore all events will be fired after the configuration.
This way you will load gtag to a known consent status. Gtag has a mechanism to detect that the consent has changed and will resend events with the new status, but I wouldn’t rely on it too much. I think it’s much better to set things up so that all the tags work when the actual agreement status is already known.
Any idea how this issue should be solved keeping the group trigger?
Use both triggers. Just view_item (here additionally check that the analytics/marketing cookie is accepted) + additionally the trigger group view_item + consent event.
This way you will cover both options, and the important first touch.
Hey, @Alex , thanks for your reply.
but I am not sure that I fully understand your answer.
The only option that I have (or at least the one that I know) is with cookie_consent_update.
So, agian, I am not sure what you mean by using both triggers.
On view_item I dont have any consent.
I have to wait for cookie_consent_update in order to fire GA4 View Item with the group trigger.
Thanks
Hi Alin,
You can use two triggers on a single tag in this way:
The view_item trigger (which is outside the group trigger) must additionally check the banner’s cookie for consent to be granted
Hey, @Alex
After some testing it seems that I get duplicated events.
If I use 2 triggers, one GA4 View Item event is fired on view_item trigger and another one if fired on the other (group) trigger (view_item + cookie_consent_update).
What I don’t understand is why do I need to use that cookie_consent_update?
I mean, If I add on my GA4 (or any others) tag a condition to fire only if ad_storage is granted, why do I need that cookie_consent_update?
Thanks,
Alin
This is needed at first touch and for the tag to work always after the actual state of the consent is already known (this is reported by the cookie_consent_update event in your case).
And yes, there will be a little overreporting when a user with an accepted consent lands on the product again. But it’s better than not correct first touch robot as I think.
If you want to avoid overreporting completely - you can make some additional check to use in the tag. For example, record in sessionStorage/local on which page path the view item was triggered and in the trigger check that it was not equal to the current page path.
Thanks, @Alex!
I will give a try.
