When a visitor clicks the bug report button and submits, Yaplet assembles a structured report in the background. You receive far more context than a written description alone could provide. Here's everything that's collected.
Screenshot
A full-page screenshot of the visitor's browser at the moment they clicked the report button. It captures the visible viewport including any UI elements, error messages, or broken layouts. The visitor can annotate the screenshot with a drawing tool before submitting — circling the problem area, adding arrows, or highlighting text.
Screen recording
An optional short video the visitor can record directly from the bug report flow. The visitor controls when to start and stop recording. This complements the session replay for situations where the visitor wants to narrate or demonstrate a specific interaction.
Session replay
A playback of the visitor's last ~30 seconds of browser interaction before the report was submitted — all mouse movements, clicks, scrolls, and DOM changes, reconstructed as a video-like replay. This shows you exactly what the visitor did immediately before the bug occurred, without them needing to describe it. Session replay is opt-in per widget; see Session replay — what it is and how to enable it.
Console logs
All messages the browser wrote to the developer console during the visitor's session — errors, warnings, and informational logs from your application's JavaScript. Console logs often contain the exact error stack trace that caused the bug.
Network logs
A log of HTTP requests made by the page during the session, including the URL, method, status code, response size, and timing. Failed requests (4xx, 5xx) and slow requests are highlighted. This pinpoints API failures and backend errors without needing to reproduce the issue manually.
Browser metadata
Automatically captured browser details:
- Browser name and version (e.g. Chrome 124, Safari 17)
- Operating system (Windows, macOS, iOS, Android, Linux)
- Viewport dimensions (inner width and height)
- Current page URL at the time of the report
- User language setting
Device metadata
Physical and display characteristics of the visitor's device:
- Screen width and height
- Device pixel ratio (important for retina/HiDPI display bugs)
- Mobile flag (whether the visitor was on a mobile device)
Custom metadata
Any data your development team has attached via the Yaplet SDK — for example, the current user ID, subscription plan, active A/B experiment variant, cart value, or any application state relevant to debugging. See Send custom metadata with bug reports.
Linked chat conversation
If the visitor also has an open or recent chat conversation in Yaplet, the bug report ticket is linked to it. This means you can read the full chat context alongside the technical data — invaluable when the visitor already described the issue in their own words.