sGTM – receiving the same event twice or trice

diesdas · September 17, 2025, 2:19pm

Hi,

for some reason, I am seeing the same event (byte for byte) twice or trice. It also get’s claimed multiple times and Tags fire multiple times.

It drives me cracy.

I am 100% sure I am sending it only once
there is only one client in sGTM to claim those requests
the incoming request is 100% the same each multiple time I receive it - every byte. Also event ID is the same.

Does anyone know why this is happening?
Everything else is normal.

Request 1

{
“method”: “GET”,
“protocol”: “https:”,
“hostname”: “xxxxx”,
“pathname”: “/g/collect”,
“searchParams”: {
“v”: “2”,
“tid”: “G-ASDF”,
“gtm”: “45je59f1z89102625371za204zb9102625371zd9102625371”,
“_p”: “1758118215785”,
“_dbg”: “1”,
“gcs”: “G111”,
“gcd”: “13t3t3t2t5l1”,
“npa”: “0”,
“dma_cps”: “syphamo”,
“dma”: “1”,
“cid”: “223299103.1750436353”,
“ecid”: “1071449910”,
“ul”: “de-de”,
“sr”: “2560x1440”,
“ur”: “DE”,
“uaa”: “arm”,
“uab”: “64”,
“uafvl”: “Not%3BA%3DBrand;99.0.0.0|Google%20Chrome;139.0.7258.157|Chromium;139.0.7258.157”,
“uamb”: “0”,
“uam”: “”,
“uap”: “macOS”,
“uapv”: “15.6.0”,
“uaw”: “0”,
“are”: “1”,
“frm”: “0”,
“pscdl”: “noapi”,
“_eu”: “AAAAAAQ”,
“sst.rnd”: “1656005326.1758118218”,
“sst.etld”: “google.de”,
“sst.gcsub”: “region1”,
“sst.tft”: “1758118215785”,
“sst.lpc”: “199385835”,
“sst.navt”: “n”,
“sst.ude”: “0”,
“sst.sw_exp”: “1”,
“_s”: “4”,
“tag_exp”: “101509157~103116026~103200004~103233427~104527907~104528500~104630779~104630781~104684208~104684211~104948813~105367987~105367989~105426769~105426771~115480710~115616985~115688283~115688285”,
“cu”: “EUR”,
“dp”: “/software”,
“sid”: “1758113796”,
“sct”: “27”,
“seg”: “1”,
“dl”: “xxxxx/software?gtm_debug=1758118214558”,
“dr”: “tagassistant/”,
“dt”: “Software | xxxxx”,
“_tu”: “BA”,
“en”: “calendly.date_and_time_selected”,
“ep.tabID”: “start”,
“ep.event_id”: “1758118712859_1758119021316102”,
“ep.value”: “10”,
“_et”: “2655”,
“tfd”: “20632”,
“richsstsse”: “”
}
}

Request 2

{
“method”: “GET”,
“protocol”: “https:”,
“hostname”: “xxxxx”,
“pathname”: “/g/collect”,
“searchParams”: {
“v”: “2”,
“tid”: “G-ASDF”,
“gtm”: “45je59f1z89102625371za204zb9102625371zd9102625371”,
“_p”: “1758118215785”,
“_dbg”: “1”,
“gcs”: “G111”,
“gcd”: “13t3t3t2t5l1”,
“npa”: “0”,
“dma_cps”: “syphamo”,
“dma”: “1”,
“cid”: “223299103.1750436353”,
“ecid”: “1071449910”,
“ul”: “de-de”,
“sr”: “2560x1440”,
“ur”: “DE”,
“uaa”: “arm”,
“uab”: “64”,
“uafvl”: “Not%3BA%3DBrand;99.0.0.0|Google%20Chrome;139.0.7258.157|Chromium;139.0.7258.157”,
“uamb”: “0”,
“uam”: “”,
“uap”: “macOS”,
“uapv”: “15.6.0”,
“uaw”: “0”,
“are”: “1”,
“frm”: “0”,
“pscdl”: “noapi”,
“_eu”: “AAAAAAQ”,
“sst.rnd”: “1656005326.1758118218”,
“sst.etld”: “google.de”,
“sst.gcsub”: “region1”,
“sst.tft”: “1758118215785”,
“sst.lpc”: “199385835”,
“sst.navt”: “n”,
“sst.ude”: “0”,
“sst.sw_exp”: “1”,
“_s”: “4”,
“tag_exp”: “101509157~103116026~103200004~103233427~104527907~104528500~104630779~104630781~104684208~104684211~104948813~105367987~105367989~105426769~105426771~115480710~115616985~115688283~115688285”,
“cu”: “EUR”,
“dp”: “/software”,
“sid”: “1758113796”,
“sct”: “27”,
“seg”: “1”,
“dl”: “xxxxx/software?gtm_debug=1758118214558”,
“dr”: “tagassistant”,
“dt”: “Software | xxxxx”,
“_tu”: “BA”,
“en”: “calendly.date_and_time_selected”,
“ep.tabID”: “start”,
“ep.event_id”: “1758118712859_1758119021316102”,
“ep.value”: “10”,
“_et”: “2655”,
“tfd”: “20632”,
“richsstsse”: “”
}
}

giovaniortolani · September 17, 2025, 3:27pm

Hi.

It seems that there’s some sort of miscommunication between the service worker and the gtag code in the page. What should happen normally is the service worker telling gtag that the event has been sent successfully, and gtag will abort sending the event again. But this doesn’t seem to be happening right now. This is a bug on Google’s side.

Currently, gtag sends the suppressSuccessCallback = true to the service worker, so the service worker doesn’t communicate the result back to gtag in the main page, resulting in the duplicate hit.

Old versions of gtag sent the parameter as suppressSuccessCallback = false, waiting for the service worker to communicate the success result back, thus aborting sending the event again.

So far, there isn’t a good way to overcome that. Some people are using triggers in sGTM to abort any event that comes from the Service Worker.

I would approach this carefully, because if and when Google fixes this bug, this solution in sGTM that excludes every request from the service worker will cause a lot of valid events to be dropped.

Examples of the communication between gtag and the service worker:

Previous gtag versions

Summary

{
  "type": 1,
  "clientId": "1108605607836496",
  "requestId": "27",
  "command": {
    "commandType": 0,
    "params": {
      "url": "https://sst.example.com/g/collect?v=2&tid=G-ABC123&gtm=[...]",
      "method": 0,
      "templates": {
        "transport_url": "https://sst.example.com",
        "encoded_path": "%2F"
      },
      "body": "",
      "processResponse": true,
      "suppressSuccessCallback": false,
      "sinceInit": 241811,
      "attributionReporting": true,
      "referer": "https://sst.example.com/products/example-hat?variant=50356795343165"
    }
  },
  "result": {
    "data": "event: message\ndata: {\"response\":{\"status_code\":200,\"body\":\"\"}}\n\n"
  }
}

Current gtag version

Summary

{
  "type": 1,
  "clientId": "1108605607836496",
  "requestId": "27",
  "command": {
    "commandType": 0,
    "params": {
      "url": "https://sst.example.com/g/collect?v=2&tid=G-ABC123&gtm=[...]",
      "method": 0,
      "templates": {
        "transport_url": "https://sst.example.com",
        "encoded_path": "%2F"
      },
      "body": "",
      "processResponse": true,
      "suppressSuccessCallback": true,
      "sinceInit": 241811,
      "attributionReporting": true,
      "referer": "https://sst.example.com/products/example-hat?variant=50356795343165"
    }
  }
}

diesdas · September 17, 2025, 4:50pm

Thank you so much!

How’d you find out, or is this a "known problem and you derived the diagnosis from the looks of it?

I wonder why it only affected the 3 new Tags I implemented today.

Thankfully, in Google Ads I can set the conversion counting to “once” so it should not affect campaigns.

giovaniortolani · September 17, 2025, 5:06pm

Some other people reported the same thing in Measure Slack this week.

I debugged gtag code a bit and found out the reason for the problem.

From what I can see, it happens for all events that are sent when the service worker is loaded and registered on the page. Usually, it won’t happen for events that fire on page load (or close to it) because the service worker may not be up yet.

diesdas · September 18, 2025, 11:34am

Can you point me to the threat? I am in this group aswell, but not very active.

giovaniortolani · September 18, 2025, 12:02pm

Sure.

https://measure.slack.com/archives/C05EQBHEJUS/p1757936784953139

warcious · September 29, 2025, 6:45pm

Dear @giovaniortolani

I can not access this thread that you are referring to, even if I do have slack.
Can you share it in any different way possible?

giovaniortolani · September 29, 2025, 7:23pm

Hi @warcious, you have to apply for an account on Measure Slack https://www.measure.chat/. After that, you will be able to access the thread I shared.

warcious · September 30, 2025, 10:38am

Dear @giovaniortolani

It may take a couple of weeks to get an account verified by measure.chat.
Is it possible that you can paste the solution here?

I am extremely frustrated as it is already, that we can not finish our tracking solution for FB and Google using Stape.io Data Tag as it is.
Please understand!

giovaniortolani · September 30, 2025, 1:27pm

Hi @warcious,

this has nothing to do with Stape Data Tag, but with a bug caused by Google in GA4 tags. They have already fixed it.

warcious · September 30, 2025, 1:43pm

But we are getting double and tripple fires in sGTM, but not in GTM.
Did they fix it today maybe, since we are having this problem every day, since we started using Stape Data Tag?

warcious · October 2, 2025, 9:12am

Could you possibly share the solution from measure.chat in here so we can access it without having to wait for an account with measure.chat?

I am really stuck here, whole e-commerce business stopped due to tracking bugs.

giovaniortolani · October 2, 2025, 4:48pm

Could you possibly share the solution from measure.chat in here so we can access it without having to wait for an account with measure.chat?
I am really stuck here, whole e-commerce business stopped due to tracking bugs.

Hi @warcious,
I answered you via DM.

For future reference, if anyone encounters this problem, check if the GTM is being injected twice: once in the main frame and once in an iframe.