The three minutes before the question.
Recording and chat were built against one visitor id, so the replay is already attached when the message arrives. You read the sentence knowing what produced it.
Scrub it yourself.
This is a real session from the demo workspace. Drag the timeline, or jump to the moment the discount code failed for the fourth time.
Loading the recording
What happened first
visitor_id 8c1f04ae
Then they typed
“why cant i pay”
You already know the answer. The code needs 200 EUR and the basket is at 184.
16 seconds
of a real checkout session, captured with rrweb
4.3 KB
the whole thing, gzipped. It records changes, not frames
Every field masked
those dots are the recording, not a screenshot filter
Why a bolted-on recorder cannot do this.
Running a separate analytics recorder next to a separate chat tool gives you two id systems with no shared key. There is no field that matches, so nobody can tell you which recording belongs to the person currently typing.
Two products
recorder → session 4f21c8
chat → visitor u_88301
join → nothing to join on
One product
recording → visitor 8c1f04ae
conversation → visitor 8c1f04ae
join → already the same row
This is a data model difference, not an integration gap. Catching up means rebuilding.
Safe enough to leave on a checkout page
Recording a payment flow is more sensitive than storing a chat log. The defaults assume that.
What is captured
- DOM mutations
- rrweb records changes rather than frames, so an hour of browsing is kilobytes, not megabytes.
- Pointer and scroll
- Movement, clicks, rage clicks and how far down each page they got.
- Console and network errors
- The failed request behind a stuck button, lined up with the moment it was pressed.
- Viewport and device
- Replays render at the size they happened at, so a mobile bug looks like a mobile bug.
What is not
- Field contents
- Inputs are masked in the browser before anything is sent. Keystroke timing survives, characters do not.
- Payment frames
- Third-party card iframes are cross-origin and out of reach by construction.
- Anything you mark
- Add a data attribute to an element and it is excluded at capture time.
- Sessions after deletion
- Delete a visitor and their recordings go with them, including from the object store.
How it behaves
- Buffered upload
- Events batch server side and write in bulk, which keeps object-store operation costs sane at volume.
- Automatic expiry
- Recordings age out on your retention setting and are metered separately from file storage.
- Quality self-check
- If a stylesheet on your CDN blocks capture we tell you, rather than letting a naked replay reach you as a complaint.
- Portable export
- Raw rrweb event files, playable in any rrweb player, on any plan.
Attached, not searched for
The recording is on the conversation when it opens. Nobody hunts for it by timestamp.
Marked where it matters
Rage clicks, dead clicks and error responses are flagged on the timeline so the incident is one jump away.
Shareable to your developer
Send a link to the exact second. The person fixing it does not need an account to watch it.
Watch one session end to end.
Turn recording on for a single site and open the first conversation that arrives. That is usually the whole demo.
Free plan stays free. The AI is the only thing that ever costs you anything.