Debug Amplitude in Chrome DevTools

What Amplitude traffic looks like

The Amplitude browser SDK batches aggressively: one request often carries several events queued since the last flush.

Endpoint pattern

api2.amplitude.com/2/httpapi (older SDKs: api.amplitude.com; EU-residency projects: api.eu.amplitude.com); amplitude.com/batch is a dedicated batching endpoint. Config requests to regionconfig.amplitude.com and SDK loads from cdn.amplitude.com are part of the same footprint but carry no events

Transport

JSON POST body with two things at the top level: the project's api_key and an events array; older instrumentation sometimes sends URL-encoded form data with the events JSON in an e parameter instead

Key parameters

event_type event name (SDK-generated names are bracketed, like [Amplitude] Page Viewed) · user_id / device_id the identity pair · session_id millisecond timestamp marking session start · event_properties / user_properties the custom payload where tracking-plan drift shows up

A typical event batch, as Event Watcher captures it:

{
  "api_key": "a1b2c3d4…",
  "events": [
    {
      "event_type": "[Amplitude] Page Viewed",
      "user_id": "user@example.dk",
      "device_id": "3f6a91…",
      "session_id": 1754640000000,
      "event_properties": { "page_path": "/pricing" }
    }
  ]
}

Debugging Amplitude with Event Watcher

• The Amplitude parser handles all the body formats: JSON body, form-encoded e/events parameters, and query-string variants.
• Each batched request unpacks into individual events, showing the event name, user ID, device ID, session ID, and the full event and user property objects per event.
• Verify a tracking plan against the wire: filter to Amplitude, trigger the interaction, and read the decoded event_properties instead of un-base64ing DevTools payloads by hand.
• The api_key is surfaced too, which settles "which project is this actually sending to" in one glance.

Amplitude and consent

The extension checks Amplitude against analytics consent. Amplitude has no consent-mode-style degraded ping: a request reaching /2/httpapi before the CMP grants analytics is a straightforward pre-consent fire, marked as such and counted in the violations tally.

The usual root cause: the SDK initializes on page load with a device ID cookie already set, while the consent gate only wraps the track() calls. Identity establishment then precedes consent even when events are held back.

Common debugging scenarios

• Events show in the panel but not in Amplitude Charts. Check the decoded api_key against the intended project; staging keys in production are a classic.
• Session counts look inflated. Compare session_id across consecutive events; a new value on every event means the SDK re-initializes per page instead of persisting.
• Anonymous users never merge. Inspect user_id vs device_id on events before and after login to confirm the identify call actually landed on the wire.
• A property is undefined in charts. Find the event in the stream and check event_properties as sent; the gap is usually upstream in the dataLayer, which push source attribution can pin to a script.
• Events fire before the banner. The pre-consent badge plus the violations counter make the audit concrete instead of anecdotal.