Debug Segment in Chrome DevTools

What Segment traffic looks like

Segment's browser library analytics.js posts spec-shaped JSON to api.segment.io on short, type-coded paths.

Endpoint pattern

analytics.js loads from cdn.segment.com/analytics.js/v1/<writeKey>/analytics.min.js, pulls source configuration from cdn.segment.com/v1/projects/<writeKey>/settings, and sends events to api.segment.io (or api.segment.com); destinations running in device mode (say GA4 or Meta Pixel loaded by Segment) fire their own native requests alongside, routed by Segment but not sent through api.segment.io

Transport

JSON POSTs on type-coded paths: /v1/t for track · /v1/p for page · /v1/i for identify · /v1/g for group · /v1/a for alias · /v1/batch when calls are queued and flushed together

Key parameters

type · event name (for track calls) · properties object · userId and/or anonymousId · context carrying library, page, campaign, and locale data · messageId and timestamp · writeKey · the integrations object showing per-destination routing overrides, worth checking when a downstream tool is not receiving data

A typical /v1/t track call, as Event Watcher captures it:

{
  "type": "track",
  "event": "Order Completed",
  "userId": "u-4821",
  "anonymousId": "9d2c1e…",
  "properties": { "total": 499, "currency": "DKK" },
  "context": { "library": { "name": "analytics.js" }, "locale": "da-DK" },
  "integrations": { "All": true, "Google Analytics 4": false },
  "writeKey": "AbC123…"
}

Debugging Segment with Event Watcher

• The dedicated Segment-spec parser decodes each call into a readable event: track calls surface their event name directly in the stream, identify shows the userId, page shows the page name.
• /v1/batch requests are unpacked so each batched call appears as its own event.
• The detail view breaks out properties, user traits, IDs (userId, anonymousId, writeKey), context data, and any consent signals in the payload.

Segment and consent

Event Watcher checks Segment against the analytics consent category of the detected CMP.

The common failure mode: analytics.js initializes on page load and fires an automatic page call before the CMP has an answer, a pre-consent /v1/p hit that increments the violations counter.

Setups using Segment's consent wrapper should show no calls at all until consent resolves; stamped context.consent data in payloads means the wrapper is at least forwarding state.

Gating Segment itself does not gate cloud-mode destinations: those inherit whatever Segment sends.

Common debugging scenarios

• A track event fires twice. Group the stream by Event Name and compare the two payloads' messageId and calling script. A duplicate often comes from the tag being loaded both natively and via a tag manager.
• identify has traits but no userId. Open the decoded call: if only anonymousId is present, the identify ran before login state was available.
• A destination is not receiving data. Check the integrations object on the decoded event for an explicit false, and check whether the destination is device mode (look for its own requests in the stream) or cloud mode (nothing to see client-side).
• Events fire before consent. Filter by consent state or check the violations counter; pre-consent page calls point at an ungated analytics.load().
• Unknown code is calling analytics.track. Use the Script Tree view and script badges to attribute the call to the site's own code, the tag manager, or a third-party script.