“What does this thing actually see?” is a fair question to ask before putting a script tag on a client's live site, especially one still in staging or sitting behind a password wall. The honest answer is narrower than most people assume: a visual feedback widget captures what it needs to describe a single reported problem, at the moment it is reported, and nothing running in the background.
What Gets Captured When a Report Is Filed
The moment a client clicks on a problem and submits a report, five things are recorded: a screenshot of the page as it looked at that instant, the exact page URL, the spot on the page the client clicked, and the browser, operating system, device type and viewport size in use. Where console logging is enabled, any script errors sitting in the browser console are captured too, so a developer can see what actually broke without reproducing the bug from scratch.
That is the entire list. It is deliberately the same information a developer would otherwise have to ask a client for, one message at a time — which page, which browser, can you send a screenshot, is there anything in the console — captured automatically instead of chased down after the fact.
What Does Not Get Captured
A click-to-report widget is not a session-replay tool, and the two get confused often enough that the distinction is worth stating plainly. There is no video recording of the visit, no camera or microphone access, and no keystroke or form-input logging. Nothing is recorded about a visitor's browsing before they click the report button, and nothing continues recording after the report is submitted — capture happens at the moment of the click, not continuously in the background.
Captured
Screenshot, page URL, click location, browser, OS, device, viewport, and console errors when enabled — only at the moment of the report.
Not Captured
No video or session replay, no camera or microphone, no keystroke or form-input logging, no continuous background recording.
Why This Matters on Staging and Password-Protected Sites
Agencies regularly install a feedback widget on a build that is not public yet — a staging URL, a site sitting behind HTTP auth or a password wall while a client previews it before launch. The widget does not change who can reach the page: it only activates for whoever already has access, the same way any other script on the page would. It does not bypass authentication, create a new way in, or expose the build to anyone who could not already see it. A password-protected site stays exactly as protected with the widget installed as it was without it.
The widget sees what a developer would otherwise have to ask for — not more, and not continuously.
Who Actually Sees a Report
A submitted report is visible to the team that owns the project it was filed against, full stop. The client who filed it never gets a dashboard login and never sees other reports on the same project, let alone reports filed against a different client's project. tapko.app's own privacy policy covers how that data is stored and secured in more detail, including encryption in transit and at rest.
For agencies weighing a widget against the alternative — clients sending screenshots over email or WhatsApp with no structure at all — the comparison usually favors the widget on privacy, not just on speed. An ad-hoc screenshot can accidentally include far more of a client's screen than the bug itself; a widget captures a defined, consistent set of fields and nothing else.
Frequently Asked Questions
What does a website feedback widget capture when a client reports a bug?
A screenshot of the page at the moment of the report, the exact page URL, the spot on the page the client clicked, and browser, operating system, device and viewport size. Console logs are captured too, where the widget is configured to record them, to help a developer see any script errors without reproducing the bug first.
Does a feedback widget record video, audio or the camera?
No. A visual feedback widget built around click-to-report captures a still screenshot at the moment of the report, not a video recording, and does not access a visitor's camera or microphone. Session-replay tools are a different product category and work differently.
Does it log keystrokes or form input?
No. The widget captures what is visible on the page in the screenshot and the browser/device metadata around the report itself — it does not track what a visitor types into other fields on the page, before or after a report is filed.
Is it safe to put a feedback widget on a client's staging or password-protected site?
Yes. The widget only activates for someone who already has access to the page it sits on — it does not bypass authentication or expose the site to anyone who would not already see it. A password-protected staging site stays exactly as protected with the widget installed as without it.
Who can see a report once it is submitted?
Only the team that owns the project the report was filed against. The client who filed it does not get a dashboard login or visibility into other reports, and reports from one project never appear in another.