I’m trying to debug a situation in Shopify and doublecheck/confirm that our Ads tags are firing correctly, with all data (gclid primarily) included.
I’ve noticed that add_to_cart (and all other non-checkout events) would fire Ads related events serverside, each of them having clearly visible gclaw parameter. the incoming request shows all cookies clearly too.
However, the checkout events (obtained in the sGTM preview via Stape Preview Webhooks) are only firing back the clientside ads events and there are no serverside fired events. Also, the incoming GA4 request contains no cookies and the outgoing browser events do not show gclaw.
HOWEVER; when I debug and inspect those client side requests in the browser dev tools, I can see they are fired with gclaw and cookies too.
I can also see the request fired to my sGTM domain with the en=purchase having gclaw param and all the cookies set up properly
So my question is - is this all normal and why? If not, why not? Shouldn’t ads conversions be firing equally regardless of how they get triggered on the fronted?
Due to the fact that your tracking works in an iframe on Shopify checkout pages, cookies are not available in headers.
Therefore, for correct operation, it is necessary to make the settings described in detail by Simo:
For non-Google platforms, you can use Data tag to transfer data to sGTM (for example, for Meta) and use the built-in option to transfer cookies in the event payload:
Hi @Alex thank you for the followup. But that only answers a portion of the question.
Do you know about the part with the client-only triggers? The ATC event triggers serverside Google Ads tags, while the Purchase event triggers only the clientside tags. Both of those are initiated from the checkout pixel, and have same configuration in sGTM (besides the conversion label) so I’m trying to understand the difference in runtime?
Further, since the GA4 client event that triggers the purchase comes with the cid and sid parameters - shouldn’t that be enough for the Ads Tags to pick up the gclid/gclaw/FPID and pass it along? Or what else could be making these params passed when Ads trigger the purchase event on the clientside?
Do you know about the part with the client-only triggers?
there is no official answer, since the tag is a blackbox. The surface difference between your ATC and Purchase would be Cookie header (missing in the latter) so give it a try once you handle gclid as per suggestion above.
Further, since the GA4 client event that triggers the purchase comes with the cid and sid parameters - shouldn’t that be enough for the Ads Tags to pick up the gclid/gclaw/FPID and pass it along?
I can see where such expectation would come from, but no, there is no ‘stitching’ like that happening in sGTM. Any tag (Google Ads in this instance) works with whats available within incoming request.
Alrighty, following up for posterity sake and future readers.
I can confirm that after passing in the gclid via a page_location param transformation the Google Ads requests on checkout events are now triggering serverside properly! That is, they are triggering together with the clientside, while before they were only triggering clientside. My take is that sGTM Google Ads tag would see there’s no gclid/_gcl_aw and would return it back to the client to try and pick up the cookie and send request from there (which it did). I also now see gclid in all the GA4 client logs in Stape where I would expect them to be.
IMO, this is the critical step in order to make Google Ads conversion reporting serverside. Without it, it can’t be called serverside since without it it relies only on the clientside tech. I’m really surprised this was not present in official Stape documentation, it should be there.
Additionally, I was able to achieve this without the switching GA4 cookies to be client managed from server managed (since this relies on client-managed _gcl_aw, not server-managed FPID). I’ll be monitoring everything and test this separately since this change doesn’t seem critical to Google Ads conversion tracking but to how GA4 does it - and I’m not sure we were seeing problems on that front.
Hey @Luka_Horvat thanks for the confirmation and sharing with community.
Few points:
I will see to it that relevant articles are updated. This a Shopify-only thing though, in any other environment the issues would never present itself in the first place cause all the headers would be where they are expected
Indeed the switch to client-side cookies is not critical here, I believe Simo is describing that more for a scenario where all of your tracking is in a shopify sandbox
I don’t expect you to see any issues with ga4 around this, please do let us know should any surface ultimately.
