Privacy is the inspection step, not a footnote.
Capture starts from an explicit report action, lasts for the report window, and is reviewed before anything is submitted.
Incident recorder, not a visitor recorder.
ClipInbox captures the browser context around a report the user chose to send, not a permanent record of every visitor’s behavior.
Capture boundary
| Captured | Not captured by default |
|---|---|
| Console logs and warnings | Input values |
| Failed request URLs and status codes | Request or response bodies |
| URL path, title, and referrer | Cookies, auth headers, and browser storage |
| Browser, OS, viewport, and visible screenshot | Full DOM snapshots or background behavior outside the report session |
Why ClipInbox does not record sessions
Session replay can be useful when a team needs a continuous timeline of every visitor action. ClipInbox is built for a narrower job: a person decides to report a bug and sends the browser context needed to reproduce that bug.
Replay tradeoff
| Question | ClipInbox answer |
|---|---|
| Who starts capture? | The reporter opens the widget. Capture is not always on. |
| What is the debugging artifact? | A report packet with note, screenshot or clip, console signals, failed request metadata, browser context, and selected recent steps. |
| What is intentionally missing? | No full replay timeline, no full DOM snapshots, no input values, no cookies, no auth headers, no request bodies, no response bodies, and no storage values by default. |
| When is replay a better fit? | When the team needs passive product analytics, broad funnel observation, or a continuous record of behavior before the user decided to report anything. |
User-visible by default
The report flow is meant to make the boundary obvious to the person sending it.
- User-triggeredThe report starts when a user opens the widget. ClipInbox is not a passive surveillance layer.
- Short-livedCapture is scoped to the report session instead of an endless replay timeline.
- Review-before-submitUsers can inspect the note, screenshot, and capture summary before sending.
- Developer-usefulTeams still receive enough browser context to diagnose the issue and reduce follow-up questions.
Give support a better intake path and engineering reports they can use.
Start with a script tag. Let users review the report. Send your team a compact browser-context packet instead of another vague ticket.