Home / Guides

Test Events for TikTok, Snap, UET and five more

Everyone knows about DebugView and Tag Assistant. Every other platform has the same thing, switched on by a cookie almost nobody documents — here is the full list.

Published 10 August 2026

Google gets all the attention here: DebugView and Tag Assistant are documented, linked from the interface and known by everybody. The other platforms have equivalents that are just as useful, and most of them are switched on by setting a cookie or a localStorage key that is barely documented anywhere. Here is the whole set, with what each one actually changes.

The list

• TikTok — Test Events. Cookie tt_test_id, set to the Test Event code from TikTok Events Manager. Your events then appear in its Test Events tab, the same way DebugView works for GA4.
• Snapchat — Test Events. localStorage key _scTestEvent. The value is not just the test ID: scevent.min.js expects <uuid>|<epoch-ms>, the UUID being the Test ID from Snapchat Events Manager, and the whole thing is valid for one hour.
• Microsoft UET — debug beacons. Cookie _uetdbg, which adds a debug flag to UET beacons so the UET Tag Helper can read them. bat.js accepts a 13-digit millisecond timestamp or a UUID v4 and silently ignores anything else.
• Tealium — utag debug console. Cookie utagdb=true. utag then logs what it is doing to the browser console.
• Yandex Metrica — debug panel. Cookie _ym_debug=2. Metrica draws its own panel on the page listing counters, events and ecommerce.
• Hotjar — debug logging. Cookie hjDebug=true. Hotjar prints what it is recording, which is also the fastest way to see what it is not recording.
• Criteo — tag debug. Cookie criteoTagDebugMode=1. OneTag logs its events instead of staying completely silent.
• Adobe Launch — debug. localStorage key com.adobe.reactor.debug=true, equivalent to calling _satellite.setDebug(true), except it survives navigation.

Why bother when you can already see the request

Reading the outgoing request tells you what the browser sent. A platform's own test mode tells you what the platform received and accepted, which is a different claim and occasionally a very different answer. A hit can leave correctly and still be rejected for a malformed payload, an inactive pixel ID, or a value the platform will not take. Test Events is where you find that out.

The two views together are the complete picture: the request proves it was sent, the platform's console proves it landed.

The silent-rejection problem

Two of these validate their input and say nothing when it is wrong. UET wants a 13-digit millisecond timestamp or a UUID v4 in _uetdbg; write anything else and bat.js drops it without a warning, so debug mode looks enabled and simply does not work. Snap rejects a malformed UUID in _scTestEvent the same way, and its one-hour expiry means a value that worked this morning is dead by lunch.

This is the failure that costs an afternoon: the debug mode appears to be on, the events are not showing up, and you go looking for the bug in your tags.

What a test event does not prove

Seeing your event in Test Events means the platform received something. It does not mean the payload is right. Value, currency, content IDs and deduplication keys are separate questions, and an event that arrives with the wrong revenue is worse than one that does not arrive at all — the first one silently corrupts your reporting, the second at least looks broken.

Check receipt in the platform's console; check content in the request.

Cleaning up afterwards

These are ordinary cookies and localStorage keys, and they persist. Leaving _ym_debug on a client's site means their Metrica panel greets the next person who opens that browser, and leaving utagdb on fills a console you are not watching. Turn them off when the check is finished. If you set them by hand, remember that a cookie set for the wrong domain scope will keep coming back on subdomains you have forgotten about.

Related guides

• Testing tracking without polluting production analytics
• A GTM click trigger the next deploy will not break
• Google Tag Gateway: checking that it actually works