Verify wiring in Preview

The app page header reads Verify wiring in Preview. This is an optional cross-container probe. The two preceding Connect steps each verify a container in isolation: Web Container confirms the web container is configured and firing in GTM Preview, and Server Container confirms the server container processes incoming events and forwards them to the test GA4 property. Preview test stitches the two together — it captures evidence that an event leaving the browser actually arrives at the server, gets processed by the server workspace, and lands in the test GA4 property, all in one probe.

Preview test is not a gate. Passing it never unlocks anything new; failing or skipping it never blocks Publish — Review staged setup. It is a checkpoint for catching wiring mistakes before they become published wiring mistakes. Recommended but not required.

Happy path

  1. Web Container and Server Container steps are both passing (otherwise the page renders a locked banner with a link to the lowest unmet step).
  2. Step 1 — Create the capture panel: click Create. GSS adds three items to your web container’s workspace (Debug Mode built-in, GSS - Preview Mode trigger, GSS - Preview Overlay tag).
  3. Step 2 — Verify in Preview: open GTM Preview for both containers, visit a page on your site so events flow, click the panel’s Copy button when it reads "Ready to copy", paste the JSON into the textarea, and click Validate preview.
  4. All three checks (browser sent events, server received events, visitor ID matched) turn green; continue to Publish — Review staged setup.
Glossary▶
Cross-container probe
A capture panel (a GTM Custom HTML tag staged into your web workspace) that records /collect requests while both containers are in GTM Preview. The panel outputs a JSON blob you paste into the GSS page to verify the round trip from browser to server to GA4.
Preview mode
GTM's developer mode that attaches debug headers to requests so the staged (unpublished) workspace is the one that fires. The preview Cloud Run service serves the server-side preview session.
Wiring evidence
The captured JSON contains per-event records linking a browser collect to the matching server collect, with shared client_id. That's what proves the two containers are talking to each other.
Skip
Explicitly mark the preview test as skipped. The step shows "Skipped" and Publish remains unblocked. Skip is not a one-way door — you can re-run later.

Decision record

The decision record at the top of the page (header: Preview verification) summarizes where the validation stands. It renders on every state except Prerequisites missing, and has two rows:

  • Capture panel — "Ready", "Out of date", "Could not check", "Pending", "Active during validation" (after a pass / fail), or a dash on skipped.
  • Last validated — a local-time timestamp + outcome ("X of Y confirmed", "Failed — re-run to retry", or "stale, last checked greater than 7 days ago" in the stale state). Shows "Skipped" when you have opted out.

Page states

The page renders in one of five states depending on prerequisites and prior runs. Each state shows a different surface.

State What it means What is on the page
Prerequisites missing Web Container or Server Container is not yet passing. Locked banner with a "Go to {step} →" link to the lowest unmet Connect step. No decision record, no probe UI.
Runnable Both prereqs green; no run captured yet. Decision record at top, then Step 1 (Create capture panel) and Step 2 (Verify in Preview, locked until Step 1 reports ready). A separate "Skip validation" card sits below with an Acknowledge checkbox and a Skip button.
Passed A probe run completed with all three checks green. Receipt view inside Step 2 (per-check pass status + a Re-verify button). The Skip card is suppressed.
Skipped You marked the validation as skipped. Step 1 dims to grey "Skipped". Step 2 shows "Validation deferred". The Skip card swaps to a Require button to re-enable the validation. Skip is reversible.
Failed A run completed but one or more checks did not pass. Step 2 renders a failure breakdown per check, plus a Re-verify button. The Skip card stays visible so you can still skip past the failure.

Step 1 — Create the capture panel

Step 1 stages a small capture panel into your web container’s draft workspace so it fires only while GTM Preview is running. Click Create to stage it. (Status pill flips to "Saved — All three items staged in your web workspace" once it lands.) GSS adds three items to the workspace:

Name Type Why
Debug Mode built-in variable Enabled so the trigger below can gate on "are we in GTM Preview?"
GSS - Preview Mode trigger Fires only when {{Debug Mode}} equals true. The capture panel tag is bound to this trigger, so the panel never appears on real traffic.
GSS - Preview Overlay Custom HTML tag Injects the capture panel script onto your site. Carries a hidden marker comment that lets GSS recognize and manage the tag on future visits.

The Re-create button

Once the panel is staged, Step 1’s Detected column shows ✓ or ✗ for each item. The button on Step 1 swaps from Create to Re-create. Clicking it replaces the previously staged tag with a fresh canonical copy in one POST — equivalent to deleting the tag and clicking Create again, without the in-between empty state.

Usually you don’t need it. The page provisions the canonical body on first Create, and inspect-on-load detects drift. Reach for Re-create when:

  • Step 1 shows the Out of date status pill and an advisory pointing at one of the three legs (tag body, trigger missing, trigger filter modified, Debug Mode disabled).
  • The capture panel shows on your site but behaves oddly after a GTM workspace edit.
  • You bumped the overlay script version on the GSS side and want the staged tag to point at the new URL immediately.

Note: the trigger_filter drift case is the one that does NOT recover via Re-create alone. GSS will not auto-overwrite a trigger whose filter has been modified. Delete the GSS - Preview Mode trigger in GTM, then click Create here.

Why the trigger and Debug Mode stay on Re-create

Re-create only deletes the GSS - Preview Overlay tag. The GSS - Preview Mode trigger and the Debug Mode built-in are left in place. That's deliberate:

  • The tag carries an ownership marker (a hidden comment in its HTML body). GSS only deletes tags it can prove it created. Re-create finds the marker, deletes the tag, then provisions a fresh copy with the current canonical body.
  • The trigger has no body to embed a marker in. A trigger named GSS - Preview Mode could in theory have been authored by you or a teammate. GSS won't auto-delete a trigger by name alone — that would risk destroying user content. On Re-create, GSS checks whether the existing trigger matches the canonical filter; if it does, the new tag is bound to it; if it doesn't, the page flags trigger_filter drift and asks you to delete the trigger in GTM manually so GSS can author a fresh one.
  • The Debug Mode built-in is a workspace-level toggle, not something GSS exclusively owns. Disabling it could break unrelated tags that depend on the same built-in. GSS re-asserts it as enabled on every Create / Re-create but never disables it on Remove.

If you want to fully clear all three artifacts from a workspace, do it in GTM: delete GSS - Preview Overlay, GSS - Preview Mode, and uncheck the Debug Mode built-in. The publish flow's pre-publish guard handles the tag cleanup automatically before a published version is created, so manual cleanup isn't required just to publish safely.

Step 2 — Verify in Preview

Step 2 is locked with a grey "Complete step 1 first" pill until Step 1 reports the capture panel as ready. Once it unlocks, the body renders four numbered substeps (2.1 – 2.4) and a textarea for the captured probe JSON.

  1. 2.1 — open GTM Preview for both containers in separate browser tabs (the app surfaces inline links to the web and server workspace Preview URLs). Click Preview in the top-right of each.
  2. 2.2 — visit the page you want to capture on your site with GTM Preview enabled. The capture panel should appear in the bottom-right corner within a few seconds.
  3. 2.3 — trigger an event (refresh the page, click a button, or use the site’s normal navigation). The panel counts requests to GA4 directly and to your tagging server, and confirms the visitor ID matches across them. When it reads Ready to copy, click Copy. The panel only tracks the current page (plus in-app SPA navigations) — a full-page navigation resets the capture, so on non-SPA sites capture one page at a time.
  4. 2.4 — switch back to the GSS tab, paste the JSON into the textarea, and click Validate preview. One page is enough — GSS only needs to see one request reach each side.

After a successful run, Step 2 turns into a receipt with three pass rows:

  • Browser sent events
  • Server received events
  • Visitor ID matched across both

A Re-verify button on the receipt re-opens the runnable two-step flow if you want to capture a fresh probe. After a failure, the same three rows appear with per-check status + message; fix the underlying issue (the failure message usually points at the right substep above) and click Re-verify.

If the capture panel never appears on your site (CSP blocks the script tag, an extension is interfering, etc.), the page exposes a Panel not loading? disclosure with a draggable bookmarklet you can use as a fallback. It also shows the JSON shape so you can hand-build a capture from DevTools network logs if you have to.

Skip validation

Every runnable / failed / skipped state surfaces a Skip card below the two guided sections (passing receipts hide it). The actionable variant has an Acknowledge checkbox + a Skip button (Skip stays disabled until you tick the checkbox; ticking the checkbox also dims Sections 1 and 2 so you can preview what skipping will look like before committing). After skipping, the same card renders a Require button so you can re-enable the validation in one click — Skip is not a one-way door.

Skip only if you are confident the setup is correct. Validation confirms that browser events fire, that they reach your tagging server, and that the visitor ID matches across both — mistakes on any of those legs become published mistakes if you do not catch them here.

Why it's optional

Web Container and Server Container each validate their side of the pipeline thoroughly. The only thing they can't directly observe is the message-passing in between — the wiring. Most setups have correct wiring once both per-container checks pass, which is why the preview test is recommended but not gated. The gated end-to-end test happens after publish in Publish → Confirm live traffic, where the same wiring is verified against real production traffic instead of a preview session.

Next: Publish — Review staged setup →