No ecom data for gtm4wp.orderCompletedEEC event sent to GA3

@duracelltomi Cookiebot is now paused on the test site. Also, I′ve removed the cookiebot-variable condition for the 2 ecom triggers for the GA3 ecom events.

This means that ONLY the GA3 ecom events will fire at the site right now.

But it seems that the ecom data is comming correctly through now… so probably it is Cookiebot, that is conflicting with your plugin somehow…?!?

@ludyamano Thank you very much for explaining your solution in detail. For now I′ll wait to try it until Thomas has completed his investigation of the issue.

@duracelltomi What do you think of ludyamano′s suggestion… should we try that? Or do you want to investigate further why Cookiebot seems to create this issue in the first place?

Hi,

I placed another test purchase on your test site and I can see purchase data as well.
I wouldn’t say this is an incompatibility between GTM4WP and Cookiebot but some odd behaviour in Google Consent Mode that is enforced in Cookiebot to be used.

Let’s review your Cookiebot implementation in more details:
– have your added Cookiebot using the official tag template in GTM? If yes, do you fire the tag using the Consent initialization trigger?
– are you setting up consent related options in GTM using the new Consent configuration options?

Hi Thomas

Maybe it would be easier if I just gave you read-only access to the GTM container?

But to answer your questions:

– Cookiebot is added in GTM using the official tag template
– Cookiebot is loaded via the Consent initialization trigger
– I am not using the new consent related options in GTM

Hi,

Unfortunately requesting any access is forbidden on this forum, I have been warned earlier despite my intentions are harmless.

Could you send me an updated GTM share preview URL? I can review your container through that link as well and if I do not see something, I will ask for screenshots.

Please revert your Cookiebot settings before you send the preview link

Cookiebot settings has been reverted. Here is an updated GTM share preview URL:

https://tagassistant.google.com/#/?id=GTM-WN38ZLZ&url=https%3A%2F%2Fbof.octotest.dk%2F%3Fgtm_debug%3D1637690026948&source=TAG_MANAGER&gtm_auth=RUshyB8gtrClO8k2kK4TRg&gtm_preview=env-10

Just a thought… could it maybe have an impact, that the test-domain (bof.octotest.dk) has been added as a test-domain in Cookiebot instead of a regular domain?

I am not sure this has to do with your domain set as regular or test.

Please have a look at this screenshot taken on your test site on a product detail page:
https://www.awesomescreenshot.com/image/17304370?key=95d424b5fc17e5167966b69c13388eab

This is how the GTM data layer is populated with events and variables. Time passes from top to bottom. As you can see, Cookiebot is setting consent mode way after ecommerce events happen (in push no. 11).

Though I do not see any defaults being set while Cookiebot itself is initialized, my assumption is that consent is set to denied by default in your case (Google’s own documentation clearly states that if no consent settings are explicitly set, “granted” is the default state. In your case, that seems to be “denied” for some reason. I can tell you why I think this:

https://www.awesomescreenshot.com/image/17304909?key=3d7dacff6198383c6e244187ee152239

This is the GA hit sent on the gtm4wp.changeDetailViewEEC event. It should include ecommerce data about the currently viewed product but it doesn’t. Instead, it includes the gcs parameter set to G111. The gcs parameter controls consent mode in hits but unfortunately this is an undocumented parameter thus we do not know what G111 means. In most cases, G100 can be seen when consent is denied, G111 could mean some other behavior or it could mean denied state as well.

Important is that when I fire the event again after Cookiebot has updated consent mode status, ecommerce data is present. It is the same data layer, so I do not see how GTM4WP could fire the event differently during page load.

What I also know is that in Cookiebot, you can not turn off Consent Mode. I do not know why, I have seen a checkbox for this in other vendor tag templates, Cookiebot however seem to enfore using Consent Mode.

(disclaimer: I do believe that Consent Mode is a good approach to manage data and allow Google to at least model unconsented data, but here we have some very twisted situation)

I will do some more research, please give me more 1-2 days.

Ok, it took less than that ??

There is an option in the Cookiebot tag under “Default consent state” called “Wait for update”.

It defaults to 2000ms.
Could you lower this number to 100ms?

I understand what you are saying and it makes sense that consent mode in some way is causing issues here.

But actually I have from the beginning changed the default consent state in the Cookiebot tag template to “granted” instead of “denied”:

But maybe this isn′t working in reality… ??

PS: I have never seen an option for turning off consent mode in Cookiebot anywhere (which is kind of frustrating)

“Wait for update” has now been changed to 100 miliseconds ??

Thanks!

That does not seem to work… ??
I am asking some other professionals, perhaps they have seen any similar case.

Hi @duracelltomi

I just wanted to check in quickly… how are things on your end regarding this issue? Are you still investigating? ??

I am facing a similiar issue with Borlabs Cookies. I am not intending to hijack the thread, but want to express the assumption that it could indeed have something to do with time-outs.

My data is here, if it helps.

Hi @franz92

Thanks for your contribution. Let′s see what Thomas makes of this… ??

Hi,

A still do not have any news on this ??
What I though is to test what happens if we manually add default consent state before the GTM container code…