Preview mode is the testing view in Google Tag Manager that lets you try unpublished changes on your real website, in your own browser only, and see exactly which tags fired, which did not, and why. Nothing changes for other visitors until you publish.
How preview mode works
When you click Preview in a GTM workspace, Tag Manager opens Tag Assistant and asks for the address of the page to test. It then opens your site in a new window with a debug connection and loads the draft version of your container in that one session instead of the published version. Every other visitor still gets the live container.
The Tag Assistant window lists each event on the page in order: the container loading, the page structure becoming ready, the window finishing loading, then clicks, form submissions and anything the site pushes to the data layer. Select an event and you see the tags that fired on it, the tags that did not, the value of every variable at that moment and the contents of the data layer. For a tag that stayed silent, it shows which trigger condition failed, which is usually the quickest route to the cause.
GA4 has a matching tool. While a preview session runs, GA4 events are flagged as debug traffic and appear in DebugView, so you can confirm the event names and parameters that actually arrived in the property, not only what the tag tried to send.
Preview links can be shared. A developer or client who opens the link sees the draft on their own device, which helps when a change needs checking on a particular phone.
Why it matters
A tag change reaches every visitor the moment it is published. A trigger that fires the purchase tag on every page view, or a form tag that fires when the page loads rather than when the form is sent, quietly inflates conversions and feeds false data into Google Ads and Meta bidding. Preview mode is where you catch that before it costs money.
For UK sites it is also where you prove the consent setup works. Analytics and advertising tags should wait for consent under PECR, so a proper test runs twice: once rejecting non-essential cookies on the banner, checking that no analytics or advertising tags fire, and once accepting, checking that they do. Tag Assistant shows the consent state for each event, so you can see whether tags respect it instead of trusting the banner supplier’s description.
Common mistakes
- Publishing without previewing, because the change “only touched one tag”.
- Testing only the straightforward path. Submit a form with an error, abandon a checkout, use the back button: that is where duplicate and missing events hide.
- Testing with an ad blocker or strict browser privacy settings switched on, then misreading blocked tags as broken ones, or finding the debug connection will not start.
- Forgetting that preview sends real data. Test purchases and enquiries land in GA4 and can reach ad platforms, so use GA4’s developer traffic filter or note the test orders and remove them from your sales figures.
- Checking desktop only when the menu, form or checkout behaves differently on a phone.
- Leaving a preview tab open and later mistaking draft behaviour for the live container.
How to act on it
Make preview the fixed step between editing and publishing. For each change, write down what should happen, start preview, carry out the actions, and confirm every tag fired once, on the right event, with the right values. Check that the matching events arrive in DebugView, then publish with a version name that says what changed, and look at the live data again the next day.
Keep a short test script for the actions that matter most to the business, such as an enquiry form, a click on the phone number, an add to basket and a purchase. Running the same script after every change makes regressions obvious. I follow this routine before any budget goes live in performance marketing, and I explain how to check the end result without opening GTM in how to check your conversion tracking works.