sGTM tag test

Same-site test harness. Append ?id=GTM-5KSDP7NQ to switch containers.
Fire one event per page load and reload in between — in testing, only the first GA4 event of a page load reliably produced a network hit, so back-to-back clicks under-report and read as a broken container.

Environment

Page origin
Loader
gtm.js from
Container
_ga cookie
FPID

Fire events

Verifying with GTM server Preview

  1. Open the server container (GTM-TLM3TGBJ) and click Preview. Every load of the debug page mints a new session, so reload it if the tab has been sitting open — a stale tab is watching a session that nothing attaches to.
  2. Come back here, reload, and fire one event.
  3. A collect?v=2&tid=G-TR4R16LEFG message should appear in the Preview tab within seconds. Select it and check, in order:
    • Request — Client should be GA4. "No client claimed the request" means a path mismatch, not a tag problem.
    • Event Data — the parsed event. This is the server-side equivalent of the dataLayer tab.
    • Tags — OpenAI CAPI - all events should have fired.
    • Outgoing HTTP Requests — a POST to bzr.openai.com/v1/events answering {"accepted_events": 1}. That response is the only real proof the event reached OpenAI.

Preview never records a real conversion. Connecting Preview sets test_mode, which flips validate_only: true on the CAPI tag. OpenAI still answers accepted_events: 1, so a Preview session looks identical to a live one and cannot confirm that conversions are landing. For that, close Preview and find an outgoing log in Stape with validate_only: false.

Seeing nothing at all? Before suspecting the container, open DevTools → Network, filter collect, and fire again. A red (blocked:other) row — or no row — means an ad blocker ate the request. It never left the browser, so it cannot reach the server, the Stape logs, or Preview, and a blocked request looks exactly like a tag that never fired. Disable blocking for waveform.com and retry.

dataLayer