Debug Snowplow in Chrome DevTools

What Snowplow traffic looks like

Snowplow is self-hosted by design, so there is no canonical vendor hostname: the compact, distinctive tracker protocol is what identifies the traffic.

Endpoint pattern

Collectors usually live on a first-party subdomain like sp.example.com or collector.example.com; the tracker itself is often served as sp.js or a renamed equivalent

Transport

GET requests to /i (a pixel) or POSTs to /com.snowplowanalytics.snowplow/tp2 carrying a data array of event objects

Key parameters

e codes the event type: pv page view · pp page ping (the activity heartbeat) · ue self-describing event · se structured event · tr/ti transaction and items; structured events add se_ca, se_ac, se_la, se_pr, se_va (category/action/label/property/value)

Identity

duid domain user ID · sid/vid session · eid event ID · aid app ID · tv tracker version

Payload

Self-describing events pack their schema-versioned JSON into ue_px (Base64) or ue_pr (plain); attached context entities ride along in cx/co the same way

A typical tp2 POST, as Event Watcher captures it:

{
  "schema": "iglu:com.snowplowanalytics.snowplow/payload_data/jsonschema/1-0-4",
  "data": [
    { "e": "pv", "url": "https://example.dk/", "duid": "7c1a2b…", "sid": "4", "aid": "web", "tv": "js-3.24.0" },
    { "e": "pp", "duid": "7c1a2b…", "sid": "4" }
  ]
}

Debugging Snowplow with Event Watcher

• Detected by protocol shape rather than hostname, so first-party collectors are picked up too.
• The dedicated parser decodes the tracker protocol: event type codes become readable names, and structured events display as category: action.
• Most usefully, the Base64-encoded ue_px and cx payloads are decoded: read the self-describing event's schema URI and body, and every attached context entity, without copying strings into a decoder.
• POST batches to /tp2 are unpacked into individual events; IDs and session data (duid, sid, eid, aid) are broken out in the detail view.

Snowplow and consent

Event Watcher checks Snowplow against the analytics consent category.

Because Snowplow typically runs first-party (same-site collector, first-party cookies), it is invisible to blocklist-based tools and easy to overlook in a consent audit; the extension's check applies regardless of hostname.

Pre-consent pv or pp hits show up marked as violations like any third-party tag.

Setups that model consent as self-describing events or attached consent context entities: decode ue_px/cx around the CMP interaction to verify the granted state is actually recorded in the payload, not just assumed downstream.

Common debugging scenarios

• A self-describing event has the wrong schema version. Open the decoded ue_px payload and read the iglu: schema URI directly. Schema mismatches that fail validation in the pipeline are visible in the browser before they hit the loader.
• Page pings inflate engagement numbers. Filter or group by Event Name to separate pp heartbeats from real events and confirm the ping interval matches the tracker configuration.
• Events missing an expected context entity. Decode cx on a captured event and check which entities are attached. A missing context usually means the plugin or global context was not registered.
• First-party collector fires before consent. The consent check flags pre-consent hits even on your own subdomain; check the first pv of the session.
• Duplicate events in the warehouse. Compare eid values in captured requests: identical eids indicate retries (deduplicated downstream), distinct eids mean the tracker genuinely fired twice.