Intently
Open app

Documentation

Debug overlay

On-site capture QA: blocked vs captured, consent pills, delivery chips, and known caveats.

The on-site debug overlay shows live capture on a verified origin: event rows, consent state, payloads, and destination routing. Enable it under Settings → Debug & Overlay, then open your site with the overlay token (or the Open links from that settings page).

Use this guide as the reference for what the overlay does — and what it does not claim.

Consent: analytics vs marketing

These categories are evaluated separately.

ConsentWhat the overlay shows
Analytics deniedCapture is blocked for gated events. Rows appear as blocked with reason analytics_consent_missing (when Show Blocked Events is on). The capture pill reads Capture blocked.
Marketing deniedEvents can still be captured if analytics is granted. Marketing destinations (Meta, TikTok, LinkedIn, …) are skipped before send. Analytics destinations such as GA4 stay eligible.

That split matches server enforcement: analytics gates storage/capture; marketing gates ad-platform destinations. See Consent.

What each row shows

  • Status: captured, blocked, or routed
  • Detail line: path, UTM, form id, ecommerce value, and similar fields when present on the event object. If those fields are missing, the detail line may be empty (blocked rows still lead with the consent reason).
  • Delivery chips (conversion-style events): destination results such as GA4 · ok or Meta · skip

Open a row for the full JSON payload. Blocked payloads include blocked: true and reason: analytics_consent_missing.

Caveats (read these)

1. Blocked rows need Show Blocked Events

Consent-blocked events are hidden unless Show Blocked Events is enabled on Settings → Debug & Overlay. With the setting off, a denied-analytics visit can look like “nothing fired.” Turn the setting on to preview blocks on-site.

2. routed is not instant on capture

A row starts as captured. It becomes routed after:

  • delivery proofs return for that event name (session delivery poll), and/or
  • the overlay annotates consent-skipped destinations as · skip chips

Expect a short delay after conversion events. Empty chips right after a purchase usually means proofs have not arrived yet — check Destinations → Delivery log as well.

3. Consent skips are not delivery-log rows

Destinations skipped for consent never create success/fail rows in the delivery log. The overlay may still show Meta · skip on the event row and “Skipped — marketing consent denied” in Destinations details. The log only records sends that were actually attempted. See Pixels & destinations.

4. Detail lines depend on the payload

The overlay does not invent path or UTM text. If the pushed event lacks page_location / page_path, utm_source, form ids, or ecommerce value, the detail line stays thin. The event modal still shows the full object.

5. Overlay vs Event log vs delivery log

SurfaceAnswers
Debug overlayWhat fired (or was blocked) on this page right now
Event logWhat Intently stored for the account
Delivery logWhich destinations accepted or failed a dispatched send

Capture and delivery are two halves of the same pipeline. Use both when QA’ing install.

Quick checklist

  1. Overlay enabled + origin verified
  2. Show Blocked Events on if you need to see analytics denials
  3. Confirm Analytics / Marketing pills match your CMP choice
  4. Fire a conversion, wait for chips or open Destinations → Delivery log
  5. Open a blocked row and confirm reason: analytics_consent_missing in the payload

Next