woocommerce/woocommerce-google-analytics-integration

When "Add to Cart Events" option is checked, sends a 2nd gtag.js config event

anastas10s-afk opened this issue · 5 comments

anastas10s-afk commented

Describe the bug:

Possible unintended behavior: When checking the “Add to Cart Events” setting, a 2nd/duplicate gtag.js config is added to all the site's pages. It is reported to be throwing warnings in all the debugging tools. Tested on clean, up-to-date installation.

Steps to reproduce:

  1. Create sandbox site on tastewp.com
  2. Install + activate "WooCommerce" and "WooCommerce Google Analytics Integration" plugins
  3. Add tracking code, and enable Standard Tracking (not sure if this is needed)
  4. Open site in Incognito window
  5. You might need to wait 5 seconds for the tag to appear

Expected behavior:

To only come across the script below the "!-- WooCommerce Google Analytics Integration --" comment, in the page's source.

Actual behavior:

See here: gUlo3W.jpg

Additional details:

Having "Enable Enhanced eCommerce" unchecked does not seem to affect this. Only the “Add to Cart Events” option.
This might be a distant cousin of #212
Related forum thread: https://wordpress.org/support/topic/add-to-cart-events-sends-a-2nd-gtag-js-config-event/

mikkamp commented

Hi @anastas10s-afk,

The extra tracking snippet is coming from the WC Blocks implementation, so this is expected behaviour. As outlined in the comment here, it doesn't break tracking, it's just not efficient.

Besides it throwing warnings in the debug tools, are you aware of any circumstances where this is causing the tracking to function incorrectly?

Otherwise it seems to be a matter of expected behaviour which won't be resolved until the WC Blocks tracking is fully integrated within the extension. We are tracking that in the issue #227

Note
It's best not to post login credentials in a public repository even if they are temporary, so I've removed them from the issue. We can use the steps to reproduce to setup the same scenario.

andreasaptum commented

Hi @mikkamp. Thanks for the info.

The reason I was looking at this as an issue is that we are having trouble getting the purchases in GA4 and UA to match closely.

We have tried different approaches and settings, but the result is always that GA4 is missing between 5-18% of purchase events compared to UA. I would expect a closer match, and since duplicate code is something Google always warns about, it seemed like a possible reason.

Now that you confirmed it shouldn't be, I can go back and search for other reasons. If you have a preferred setup for your plugin to track to both UA and GA4 (as is the recommended approach these days), feel free to share. Thanks!

anastas10s-afk commented

Thanks for clarifying further, @mikkamp. As expected, it is a "distant cousin" of #212. Haven't had an issue myself (with the plugin functioning incorrectly), but I went ahead with subscribing to the updates of #227 since I am interested in its progress. Does this mean that this issue can be closed now, also? Cheers!

mikkamp commented

Thanks for the additional context. I'll go ahead and close this issue then since there isn't any action that's needed.

That's unfortunate to hear that you are registering less purchase events with GA4. I wouldn't be in a position to evaluate why that is so as there can be many factors involved. At the moment we don't have a suggested recommendation for tracking both UA and GA4. We are following the recommendation from Google to switch to only GA4.