Debug view
The Debug view shows every event a paired device sends within seconds, with what ingest did to it — accepted, dropped and why, modified by a rule, or not counted. Pairing needs no extension and no developer access; a link, a QR code or one console line is enough.
What the Debug view shows#
The page sits in the Realtime menu as Debug view (/debug). In Data streams, the Open Debug view button takes you straight to it.
Every event that arrives from a paired device is listed, newest first, with:
- the verdict, and the reason when the event was dropped;
- its parameters, identity and session, attribution and consent at the moment of the event;
- the pipeline: which event rules applied to it and which did not;
- instrumentation warnings, such as an event name over 40 characters,
valuewithoutcurrency, or apurchasewithouttransaction_id, next to what GA4 would do with the same event; - the raw request and the row actually stored, side by side.
The strip at the top counts the last 30 minutes of events minute by minute, and the side panel shows the top events and the user's current state. You can pause the stream, search and filter, narrow it to one device, and take everything out with Export JSONL.
Pair a device#
ap('debug', '<code>') in the console of a tab that already has your site open.The link is your own site's address with ?apx_debug=<code> appended. The tracker reads the code from the URL, keeps it in that tab's sessionStorage, and stamps it on every event from that tab. In debug mode the tracker sends each event immediately instead of waiting to fill a batch.
One code can be used on any number of devices at once; the page groups events by device.
If a code has expired or is unknown, the event is processed exactly as usual, with no tracing at all. A link left in an old message breaks nothing.
The verdict on each event#
| Verdict | Meaning |
|---|---|
| Accepted | The event was stored and counts in reports once processing catches up. |
| Modified by rule | An event rule changed its name or parameters. |
| Created by rule | An event rule created a new event from this one. |
| Not counted (test) | The event was stored but appears in no report, because the code is in test mode. |
| Dropped | The event was not stored and never reaches reports. |
Dropped events are shown by default; the Show dropped toggle hides or reveals them. The reason is written on the event's red chip:
| Reason | Means |
|---|---|
| bot user agent | The user agent is on the bot list. |
| excluded IP | The visitor's IP is in the site's excluded IP ranges (internal traffic, for example). |
| opt-out cookie | The browser carries the __sov_x cookie and has opted out of measurement. |
| duplicate page view | The same URL was already counted in the same batch. |
| duplicate event | An event with the same id had already arrived. |
| unknown tag ID | The tag's tag ID belongs to no data stream. |
| code belongs to another website | The site's tag belongs to a different website; the event is processed under its own website and only flagged here. |
| malformed envelope / batch too large | The request body could not be read, or the batch exceeded the size limit. |
"Don't count my traffic in reports"#
With this option on, events from paired devices still appear in the Debug view, but they are stored marked as test traffic and every report leaves them out. AdPix writes this traffic nowhere else either: not into e-commerce line items, not into CRM or webhook deliveries, not into the paid-click log.
Creating a code with this option needs the editor role or higher, because anyone holding the link could otherwise hide real visitors from reports. Plain pairing is open to every member of the website.
Without this option, your test purchase counts in revenue and key events like any other purchase. For QA on a live site, create the code with Don't count my traffic in reports.
The debug tracker command#
| Call | Effect |
|---|---|
ap('debug', '<code>') |
pairs the current tab with the six-character code. |
ap('debug', false) |
un-pairs the current tab. |
?apx_debug=<code> on the page URL |
the same as ap('debug', '<code>'), in the query or the hash. |
Any value other than six letters and digits un-pairs. __sov('debug', …) is the legacy name of the same command and does the same thing.
Limits#
- A website has at most 5 live codes at a time. Close one you no longer need from Live codes with End.
- Each code traces at most 2,000 events. After that a "Trace limit reached" notice appears; pair again.
- The stream shows only the last 30 minutes and keeps nothing for good. If you need a record, use Export JSONL.
- Email, phone and user traits are shown masked unless your role may see identifiers. The Raw request and Stored row tabs also need raw-data access.
Frequently asked questions#
Do events from a paired device still count in reports?
Yes, unless you ticked "Don't count my traffic in reports" when creating the code. Pairing only adds tracing; the same event flows to reports as usual, so you can confirm it arrives there too.
Why is my event in the Debug view but not in the report?
Reports lag the stream by up to a few minutes. An event marked "Not counted (test)" or "Dropped" never reaches reports; the "Why isn't it in my report?" section in that event's detail names the reason.
When does a pairing code expire?
Thirty minutes after the Debug view page last refreshed it. While the page stays open the code stays live; once it is closed the code stops half an hour later and later events are processed as usual, untraced.
How do I take a tab out of debug mode?
Run ap('debug', false) in that tab's console, or close the tab. The code is stored for that tab only, so other tabs and later visits are unaffected.
Thanks — your feedback helps us improve the docs.