Guides

Published 30 September 2026 · By Jonathan Jones

Privacy-Friendly Website Feedback Widgets: What Data Should You Collect?

A practical guide for indie SaaS founders on the page and device context a feedback widget needs, and the invasive data it should avoid collecting by default.

A website feedback widget should collect the visitor’s message and feedback type, plus enough page and device context to help you investigate. Explain what you collect, make personal details optional when possible, and avoid recording sessions, keystrokes, screenshots, or other activity by default.

A data-minimisation checklist

Before adding a feedback widget to your SaaS site, use this checklist to decide what it needs:

  • Collect the visitor’s chosen feedback type and message. Keep the form short enough that someone can report a problem without filling in a technical questionnaire.

  • Attach the page title, path, URL and submission time. These details show where the visitor was when they sent the report.

  • Include only technical context that helps diagnose likely issues, such as browser, operating system, device type, viewport size and display preferences.

  • Make a reply email optional. Ask for it only when the visitor wants a response, rather than requiring an address for every submission.

  • Tell visitors what the widget collects and how you handle the feedback. Check your own privacy notice and the widget provider’s current documentation before making specific privacy or retention claims.

A useful test is to ask whether each field helps you understand or respond to a real report. If you cannot name that use, leave the field out.

Context that helps without watching the visitor

Suppose a customer writes, “The menu disappears when I try to change my plan.” The page path can tell you whether they were in billing settings. Their browser and viewport can help you check whether the layout behaves differently on a particular setup. That is useful context, but it does not explain the customer’s intent or reproduce the problem on its own. Keep the message itself clear and follow up when important details are missing.

A URL deserves particular care. Query parameters can sometimes contain invitation codes, search terms, account identifiers or other sensitive values. Avoid putting secrets in URLs, and check whether your widget stores the full URL or removes selected parameters. Do not assume a page URL is harmless just because it is technical context.

What a feedback widget should avoid collecting by default

A visitor who chooses to send a report has not necessarily agreed to have their entire visit recorded. For a straightforward feedback workflow, avoid collecting:

  • Session recordings or click-by-click activity.

  • Keystrokes or values typed into unrelated forms.

  • Screenshots or page captures that may include private information.

  • Console logs or network requests unless a separate, clearly explained diagnostic tool genuinely needs them.

  • Personal identifiers that are not needed to review or answer the report.

These choices have trade-offs. A screenshot or recording may help reproduce a visual bug, but it can also capture account details or information elsewhere on the page. If you need that level of diagnosis, consider it separately: explain what is captured, when it happens and how a visitor can choose whether to share it.

How Feedback Bubble handles submission context

Feedback Bubble pairs the visitor’s selected category and plain-text message with page context, including the page title, path, full URL and submission time. Its available context can also include browser and operating-system details, device and screen information, display preferences, browser language and reported online status. If reply requests are enabled, a visitor can optionally provide an email address.

The widget does not record sessions, keystrokes, screenshots, console logs or network requests. It also does not automatically read form fields or scrape the private contents of the host page. The current security documentation describes those collection boundaries. Its privacy policy says website feedback is retained for 12 months from submission. Check the live policy before relying on that retention period, and remember that your own visitor notice and obligations depend on your product and circumstances.

This is a description of product behaviour, not legal advice or a claim that using a particular widget makes a site compliant with a privacy law. As the site owner, explain your feedback process to visitors and review the applicable policy for your service.

Make the data useful and understandable

When you choose a widget, look beyond its form fields. Check what context is attached automatically, whether visitors can submit without an email address, how long submissions are kept, and whether the provider documents data it does not collect. Page and device context can reduce follow-up questions, but it should support the visitor’s report, not replace it with silent observation.

For a focused way to collect issues, ideas and questions with page context, see Feedback Bubble’s features.