Features

Event debugger and lineage

When a number in an ad platform looks wrong, you find out why in one place — not by guessing between browser console, vendor UI and a colleague's memory.

Event lineage

Example data: Static example state — not live traffic, no real customer data.
Event
purchase · evt_…7f2a
Origin
browser SDK + server (shop webhook)
Configuration
version 12, signature verified
Consent snapshot
analytics, marketing · source: CMP
Click ids
gclid (captured 3 days ago)

Delivery attempts

Delivery attempts
DestinationStatusResult
Meta Conversions API200accepted, deduplicated by event id
Google Ads200accepted, deduplicated by order id
TikTok Events API503retry 2 scheduled with backoff
Redacted payloadjson
{
  "event": "purchase",
  "event_id": "evt_…7f2a",
  "order_id": "A-1042",
  "value": 129.9,
  "currency": "EUR",
  "user": { "em": "sha256:…9c1e" },
  "click_ids": { "gclid": "…" }
}

One purchase, read from origin to vendor answer.

Example event stream: delivered events, one deduplicated purchase and one server purchase blocked for a missing marketing purpose.

One event, the whole path

Open any event and read its story: source and SDK version, the consent that was granted at that moment, captured click ids, the configuration version that routed it, and the delivery attempt per destination including the redacted payload and vendor answer.

The debugger follows an event from the origin through normalization, the consent decision and every delivery attempt. Drops are never silent: each carries a reason such as missing consent, blocked PII, an invalid name, a duplicate or a paused destination.

One event, the whole pathThe website sends events from the browser SDK and the server API with one shared event id to Track; the consent gate is open and events reach the destinations.Websiteone event idBrowser SDKServer APITrackConsent / Policyconsent grantedMetadeliveredGoogle AdsdeliveredGA4deliveredTikTokretrying
The lineage keeps the origin, the consent snapshot, the routing decision and each vendor's answer together.

How it is built

The technical decisions behind the capability — the proof after the benefit.

  1. 01

    Redacted, not hidden

    Payload previews show structure and hashed identifiers so you can verify mappings without exposing personal data or tokens.

  2. 02

    Test events through the real pipeline

    Test events are flagged, run through the same queue and worker, and report the vendor's verdict — no simulated success.

  3. 03

    Drops are explained

    Every dropped event carries a reason: missing consent, PII blocked, invalid name, duplicate, paused destination or policy block.

Debugging by console versus debugging by lineage

The same question — why did this purchase not reach Meta? — answered two ways.

Debugging by console versus debugging by lineage
Debugging by console versus debugging by lineageBrowser console and vendor UIEvent lineage in Track
Where to lookNetwork tab, tag preview mode, the vendor's event managerOne event record with every attempt and answer
Consent at that momentUnknown; reconstructed from the banner settingsStored as a snapshot with the event
Server-side eventsInvisible from the browserSame lineage, marked with their origin
Personal dataRaw payloads in logs and screenshotsHashed identifiers, redacted previews

What you can verify

Product facts you will find in the dashboard, the docs and the audit log.

  • Filter by event name, state and source
  • Per-destination attempt history with HTTP status and error class
  • Vendor test-mode hints per platform
  • Links straight into the destination wizard

Questions

How long are debugger records kept?
Delivery attempts default to 90 days and events to 13 months; both are configurable per organization in the privacy center.

More capabilities

Built on the same signed configuration and event schema.

Try it on your domain

Create a site, install one snippet and let the assistant configure the first destination in minutes.