Debug mParticle in Chrome DevTools

What mParticle traffic looks like

Unlike Segment's one-call-per-event model, mParticle is batch-centric: one request carries one user context plus an events array.

Endpoint pattern

Web SDK loads from jssdks.mparticle.com; events POST to the same host, typically jssdks.mparticle.com/v2/JS/<apiKey>/Events; identity resolution is a separate call to identity.mparticle.com (/v1/identify, /v1/login, /v1/logout, /v1/<mpid>/modify); server-side feeds hit s2s.mparticle.com with the same batch format

Transport

JSON POSTs keyed by the workspace API key: each batch carries one user context and an events array

Key parameters

mpid mParticle ID · user_attributes and user_identities · device and application info · per event: an event_type enum (custom_event, screen_view, commerce_event, session_start, session_end, user_attribute_change, and so on) and a data object with event_name, custom_attributes, and timing fields

E-commerce

Commerce events nest a product_action (or promotion_action) with an action like purchase or add_to_cart and a product_list

A typical batch, as Event Watcher captures it:

{
  "mpid": "-8123456…",
  "user_identities": { "email": "user@example.dk" },
  "events": [
    {
      "event_type": "commerce_event",
      "data": { "product_action": { "action": "purchase", "product_list": [{ "name": "Trail Runner", "price": 499 }] } }
    }
  ]
}

Debugging mParticle with Event Watcher

• The mParticle parser unpacks the batch so each event in the events array appears individually with a readable name: custom events show their event_name, commerce events the action (for example Commerce: purchase), screen views the screen name, lifecycle events their type label.
• The detail view separates custom attributes from user attributes and identities, and surfaces the mpid and session data, useful when verifying that identity calls resolved before events were attributed.
• Identity requests to identity.mparticle.com are captured as their own events, so you can see the identify/login sequence in order.

mParticle and consent

The extension checks mParticle against the analytics consent category. On the wire, verify order and gating: a session_start batch or the initial identity call firing before the CMP resolves shows up as pre-consent and counts toward the violations total.

mParticle carries its own consent model (GDPR and CCPA state stored on the user profile, forwarded to downstream outputs), so correct wiring writes CMP decisions into mParticle consent events rather than just blocking the SDK.

Since mParticle often fans out server-side, anything it captures pre-consent may reach downstream tools with no further client-side evidence.

Common debugging scenarios

• Events attributed to the wrong user. Check whether events fired before the identity.mparticle.com response. Batches sent with a stale or anonymous mpid land on the wrong profile.
• A purchase is missing downstream. Find the commerce_event batch in the stream and confirm the product_action.action and product list are populated; if the event never left the browser, the downstream connector is not the problem.
• Duplicate session starts. Group by Event Name and look for repeated session_start events, usually the SDK initializing twice, which the Script Tree view can attribute to two loaders.
• Consent decisions not reaching mParticle. Watch for a user_attribute_change or consent-carrying batch after the CMP interaction; if the SDK fires events but no consent state update follows, the CMP-to-mParticle bridge is missing.
• Verifying a migration from another CDP. Run both side by side and use Grouped view by Tool to compare event counts and names between the old and new pipelines on the same page.