Debug Smartlook in Chrome DevTools

What Smartlook traffic looks like

Smartlook splits its hosts by job, which is unusually convenient when debugging: the SDK, the configuration, and the recording stream are three separate hostnames, so you can tell how far the setup got before something stopped.

Endpoint pattern

The SDK loads from web-sdk.smartlook.com; project configuration comes from manager.smartlook.com; the recording payload streams to rec.smartlook.com

Transport

Script load, then a configuration fetch, then a continuous stream of recording data for as long as the session is being captured

Client API

smartlook('init', '<projectKey>'), smartlook('identify', id, { … }) to attach a user identity, smartlook('track', name, props) for custom events, and smartlook('record', { … }) to control which sensitive inputs are captured

Key parameters

The project key identifies the workspace. Identify calls carry the user id and any custom properties the site chose to attach

The three hosts, and what each one means when it appears:

web-sdk.smartlook.com     SDK loaded
manager.smartlook.com     project configuration fetched
rec.smartlook.com         session actually being recorded

Debugging Smartlook with Event Watcher

• No dedicated parser. Requests are matched by hostname, named Smartlook, badged with the Session Replay category, and shown with parsed query and body parameters plus cookies set and sent.
• Grouping by Endpoint turns the host split into a diagnosis. SDK plus configuration with no rec.smartlook.com traffic means the SDK initialized but recording never started, which is a different problem from the SDK failing to load at all.
• The identify call is worth opening on any logged-in area. It shows exactly which user id and which custom properties the site is attaching to the recording, which is the detail most likely to be over-shared without anyone noticing.
• Script Tree attributes the SDK to the site's own code, a tag manager, or another third-party script.

Smartlook and consent

Event Watcher checks Smartlook against the analytics consent category.

Two things make a replay tool a heavier consent finding than a pageview counter. It captures the rendered page rather than an event, and Smartlook's masking of sensitive inputs is configuration rather than a default, so what ends up in a recording depends on choices made in smartlook('record', …). Check both: that no rec.smartlook.com traffic exists before analytics consent, and that identify calls are not attaching personal data to sessions recorded under a consent state that did not cover it.

Common debugging scenarios

• No sessions in the dashboard. Look for rec.smartlook.com traffic specifically. SDK and configuration requests alone mean recording never started, often due to sampling or a project setting.
• Recordings are not linked to users. Check for an identify call and read the id it sends. Without it, sessions stay anonymous no matter what the site knows about the visitor.
• Custom events missing. Confirm the track call fires at the moment of the interaction and carries the expected event name.
• Recording starts before consent. Filter to Smartlook and read the consent verdict on the first rec.smartlook.com request, not on the SDK load.
• Two projects installed. Compare project keys across requests. Two keys means two initializations.