Guide 23 · Debugging · GA4 + Tag Manager
Preview shows the draft, not the live site: publish before you judge the fix
Preview runs your workspace as if it were published, and only in the browser where you started it. Nobody else sees it, and the live site does not change until you publish a version.
After the steps below, the fix is tested in Preview, published as a version, and confirmed on the live site in a browser that never opened Preview.
Download the check: the debugging check (JSON) (MD5 7493b7cdf3ec8b3c14f62d70bde0661d, 429 bytes). It lists the checkpoints from this guide and the worked check, with the figures recomputed. The file was built for this guide and validated structurally — it was not exported from a live container or a live property.
What you need
- The fix, saved in the workspace. A tag or trigger change, saved but not yet published.
- Preview, for the test. Tag Assistant, connected to your site, showing the draft working.
- The Submit flow. The publish step in the workspace, with a version name and description ready.
- A clean browser for the live check. A browser, or a private window, that never opened Preview — that is what your visitors see.
The trace
The worked check: the figures below were recomputed before publication, and the note under the table shows the working.
| Check | Figure |
|---|---|
| Test events in Preview after the fix | 5 |
| Test events on the live site before publishing | 0 |
| Test events on the live site after publishing | 5 |
| Versions published for this fix | 1 |
Five test events were done in Preview after the fix and 5 arrived in DebugView. On the live site before publishing, 0 of 5 test events arrived — 5 minus 0 is 5 events the draft held back. After publishing 1 version, 5 of 5 live-site events arrived, so the publish, not the fix, was the missing step.
- Test the fix in Preview first. Click Preview, connect your site, and do the action. The tag should fire and the event should reach DebugView. If it does not fire in Preview, the fix is wrong — stop here and fix it again. Preview is where fixes are proven.
- Check the live site in a browser that never opened Preview. Open the site in a private window, or a different browser, and do the same action. The event should not arrive — the live site still runs the old published version. If it does arrive, someone else published already, or the fix was already live.
- Publish the version. In the workspace, click Submit at the top right, select Publish and Create Version, enter a name and a description for the version, and click Publish. The name should say what changed, so the version list reads like a history, not a puzzle.
- Wait a minute, then test the live site again. In the clean browser, reload the site and do the action again. The event should now arrive. If it does not, the published version may not be the one you think it is — open Versions in the workspace and check which version is live.
- Check the version list, not just the workspace. The workspace shows your draft; the Versions list shows what is live. If the live version number is older than the version you published, the publish did not take, or you published to a different container. Match the numbers.
Dead ends
DEAD END — PREVIEW SHOWS THE DRAFT, NOT THE LIVE SITE. Preview runs your workspace as if it were published, and only in the browser where you started it. Nobody else sees it, and the live site does not change until you publish a version.
DEAD END — PUBLISHING AND TESTING IN THE PREVIEW BROWSER. Testing the live site in the same browser that ran Preview still shows you the draft, because the preview session is still attached. Use a private window or a different browser for the live check, or stop the preview session first.
DEAD END — A VERSION NAME THAT SAYS NOTHING. A version named Version 12 with no description cannot be told apart from Version 11 when the fix needs to be undone. Name the version after the change — the tag, the trigger, and the reason — so a rollback picks the right one.
End state
The fix proven in Preview, published as one named version, and confirmed on the live site in a clean browser. The draft and the live site are now the same setup, and the next test measures the live site, not your preview session.
Sources
- Tag Manager Help — Preview and debug containers — Preview and debug mode letting you browse the site as if the current container draft was deployed, visible only in the browser where it was started
- Analytics Help — Confirm that you are collecting data — Realtime as the same-day check on the live site after publishing
Checked 11 November 2026. The click paths above are the ones in Google's help pages, opened 11 November 2026. What was run: the publish counts, recomputed — 5 events in Preview, 0 on the live site before publishing and 5 after, with 1 version published. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.