Debug Drift in Chrome DevTools

What Drift traffic looks like

Drift is a conversational marketing widget, which in practice means a chat window plus an identity and event pipeline aimed at B2B lead capture. Its traffic splits across a loader host and three API hosts.

Endpoint pattern

The snippet calls drift.load('<embedId>'), which pulls the widget bundle from js.driftt.com/include/…/<embedId>.js; the running widget then uses api.drift.com and customer.api.drift.com for configuration and visitor identity, and posts tracked events to event.api.drift.com

Transport

Script load plus JSON POSTs. Playbook and conversation state is fetched from the API hosts; drift.track calls surface as separate event posts

Config object

The drift global: drift.load('<embedId>'), drift.identify(userId, attributes), drift.track('event name', { … }), and the drift.on('ready' | 'startConversation' | …) handlers

Key parameters

The embed id in the loader URL identifies the Drift account · userId and the attributes object on identify · event name and properties on track

Cookies

drift_aid and driftt_aid carry the anonymous visitor id; drift_campaign_refresh tracks playbook re-entry

An identify call, as Event Watcher captures it:

{
  "userId": "u-4821",
  "attributes": {
    "email": "buyer@example.com",
    "company": "Example A/S",
    "plan": "enterprise"
  }
}

Debugging Drift with Event Watcher

• No dedicated parser. Requests are matched by hostname, named Drift, badged with the Widgets category, and shown with parsed query and body parameters plus cookies set and sent.
• The embed id in the js.driftt.com URL is the fastest confirmation of which Drift account a page is wired to. Two embed ids in one session means two snippets.
• Grouping by Endpoint separates configuration traffic on the API hosts from the event.api.drift.com posts, which is where drift.track calls land.
• Script Tree attributes the loader to the site's template, a tag manager, or another third-party script. On B2B sites Drift is frequently deployed through a tag manager alongside ABM and reverse-IP tools, and the tree is what untangles that.

Drift and consent

Event Watcher checks Drift against the functional consent category.

The chat surface is functional. The identify pipeline is not obviously so: drift.identify sends CRM-shaped attributes, commonly including an email address and company, and the anonymous drift_aid cookie is written before any conversation starts. On most B2B sites Drift is part of the marketing stack rather than the support stack, and the consent posture should follow how it is actually used rather than the fact that it looks like a chat box.

Common debugging scenarios

• The playbook never fires. Confirm the js.driftt.com/include/… request returns for the expected embed id before looking at targeting rules.
• Identified visitors stay anonymous in Drift. Open the identify request and check that userId and the attributes object are actually in the body, not just set on the page.
• A tracked event is missing. Check event.api.drift.com for a POST carrying the event name. A name that does not match the one configured in Drift silently reports nothing.
• Two Drift installs. Two embed ids, or duplicate loader requests, mean the snippet is present both natively and through a tag manager.
• Drift loads before consent. Filter to Drift and read the consent verdict on the first loader request, then check whether drift_aid was set pre-banner.