Shopify Google Ads SST Double Conversion Value

Hi,
I set up Google Ads SST for a Shopify store, where the client already had client-side tracking configured with GTM. Client-side conversion tag is firing on purchase event called “ee_purchase”.

I then implemented GAds server-side tracking, firing a custom purchase event called ‘mr_purchase’ when a purchase occurs. Everything was working fine until my client noticed that some conversion values were being counted twice.

When I checked the Webpages tab under the conversion action settings, I found that all confirmation pages were listed with conversion values. However, when I copied a thank-you page URL and opened it in the browser, the conversion value displayed was exactly half of what appears in Google Ads.

I’ve reviewed the setup from scratch. I’m correctly passing the transaction ID and conversion value in the purchase event, and the event is firing only once. I’ve added to condition with the trigger so that even user reload the thank you page tag does not fire again. but it didn’t solve the issue. Conversion is still showing double in Google ads account.

Also, this issue is happening for some conversions, not all.

Is there any reason why this might be happening?



@Alex Could please guide me with this? I’m really stuck with this issue. I would really appreciate your help. Thanks

@Alex @Dan
Please help.
I’ve checked the access log in my stape server container. The purchase request URL has purchase conversion value 351.05, in Shopify store purchase value is 351.05 But when I check it in Google ads conversion action under webpages tab the conversion value is showing exactly double 702.10.

From access log, it seems my server is receiving correct purchase value which is 351.05 but in Google ads account it shows double. I’m just stuck here.

In server GTM, I’ve set up Google ads SST tag following standard method.

Hey @Md_Monirul_Islam

Haven’t encountered this problem before.
I can suggest to try the following:

  1. Make sure that the conversion value is transmitted correctly. It can be assumed that in some cases just not correct value is used in data layer or if you modify it somehow it affects it.
    Google ADS can’t have outbound logs, but you can check inbound requests using the logger tag and logging GA4 purchases:
    Troubleshooting server-side tagging using server GTM logs - Stape

You may find that the problem somewhere is that the wrong value is being sent to the server container.

  1. We can assume that this is a glitch in a particular conversion, i.e. the problem is on Google’s side. You can try to start a new conversion and send data to it in parallel.
    You may find out that the new conversion does not have this problem.

I honestly don’t see any other options here. It will be interesting to find out what the cause of the problem is, but usually only experimentation to localise the problem will help.

1 Like

Hi @Alex
Really appreciate your insights.

I’ve checked with my client and made a real purchase to validate how conversion value is being received and being sent to Google server.

I found that conversion value is being received correctly in server GTM and then being sent to Google ads server correctly. You can have a look in the images. I have checked the inbound requests in the ‘Access Logs’ in Stape. Value is correct there. Then Also checked the outbound request both from Server GTM preview and browser’s developer >> Network section. Value is showing correct there as well.

Interestingly number of conversion is counting correct. That means if a conversion happen then conversion is counting as one but for some conversion, value is showing double. Really Strange.

If this is a glitch in a particular conversion, i.e. the problem is on Google’s side the should I consult with Google representative?

I’ll try your suggestion with new conversion and send data parallelly. I’ll monitor it. Let’s see what happens.

Again Thank you so much for your input.




If the amount is correct and everything on the tracking side is working correctly and you have verified this - the problem is very likely on the platform side.

2 Likes