Feedback widgets, GDPR and LGPD

This is not legal advice

This article describes what one feedback widget does in the browser and on the server. It is a product explanation, not legal advice. GDPR (the European General Data Protection Regulation) and LGPD (Brazil's Lei Geral de Proteção de Dados) apply to your own situation in ways that depend on where you and your visitors are, what you do with the data and what else your site collects. Read your privacy notice with a qualified lawyer or data protection professional before you publish it. Nothing here replaces that review.

What the widget sends, field by field

The widget sends one JSON payload each time someone presses the send button. These are the fields, and where each value comes from:

Field	Source	Required
message	Typed by the visitor, at least two characters	Yes
kind	Bug, idea, praise or other, chosen by the visitor or set by your trigger	Yes, defaults to idea in the panel
rating	One to five stars, if the visitor picks one	No
email	Typed by the visitor, or taken from your identify call	No
name	Taken from your identify call only	No
pageUrl	The full address of the page, including any query string	Sent automatically
metadata	Values from setMetadata and extra keys from identify	Only if you pass them
website	The hidden honeypot field, normally empty	Sent automatically

The server adds two more values from the request. It saves the browser's user agent, which the browser sends as a request header, and the country, which the server derives from the request. The widget script does not send a user agent field in the payload, so do not describe it as doing so.

Each field is there for a reason. The message and kind are the feedback. The email is optional, so the visitor can choose whether you can reply. The page URL tells you where the problem happened.

Watch the page URL

The widget sends location.href, the full address of the current page. That includes everything after the question mark. If your app puts a token, an invitation code or an email address in the address, the widget will send it with the feedback. Clean up those parameters before you install the widget on the page, or move sensitive values out of the address. The same caution applies to the hosted feedback page, where ?email= prefills the email field.

What the widget stores on the visitor's device

The widget script sets no cookies and writes nothing to localStorage or sessionStorage. That is what people mean when they say the widget has no tracking cookies. The widget itself does not identify returning visitors, and it does not load analytics, fonts or other third-party scripts. After the script loads, the only request it makes is the one that sends the feedback. That request is cross-origin and uses the browser's default credential handling, so the browser does not attach your site's cookies to it.

Your site may still set cookies for other reasons, such as login sessions or your own analytics. Those belong in your privacy notice and your cookie policy, separately from the widget.

Data you add with identify and metadata

Your code can attach more information. The identify call takes an object with an email, a name and any other keys. The email and name fill the form fields. Every other key, such as an account ID, becomes metadata on the feedback item. The setMetadata call replaces the metadata object directly, and metadata is limited to 4 KB of JSON.

This is useful and it is also where the most personal data tends to slip in. Pass the fields you actually use to answer the feedback, such as an account ID or a product version, and leave out anything you would not want in an inbox. Every value you pass travels with each feedback item sent while it is set, so a value that looks harmless on one page can still reveal more than you intended.

Data minimization in practice

Both laws ask you to collect what you need for the purpose you state. For feedback, a practical version of that rule looks like this:

1. Keep the message required and the email optional, as the widget does.
2. Ask for a rating only if you will use it.
3. Pass an account ID in metadata, not a full name and a phone number, unless you need both to reply.
4. Strip tokens and personal addresses from page URLs before the widget loads.
5. Close items that no longer need an answer, using the Closed status in the inbox.

Each step reduces the amount you have to explain in the privacy notice.

Write the privacy notice around the real fields

Your notice should match the table above. List the fields the widget collects, say why you collect each one, and say who in your team can read the inbox. Describe the optional fields as optional. Name the places the data goes: Escuta Produto stores it, and your notification webhook may post an excerpt to a Slack or Discord channel you control. If you use the REST API from your own servers, describe that flow too.

Escuta Produto does not record sessions, take screenshots or record the screen, so your notice does not need to describe those. Keep the notice accurate to the fields you actually send. A notice that describes features you do not use is as much of a problem as one that leaves out features you do.

For setup, the widget docs list the options and the metadata behavior, and the notifications docs explain what a webhook message contains. For how a widget loads and what it sends on the page, see content security policy for third-party widgets. For the handling side, read how to triage customer feedback.

How Escuta Produto keeps the data small

The widget is built to collect a short list of fields, and the inbox is built to stay private to your team. Each product has its own inbox. Each item has internal notes that visitors never see. You can export a product's feedback as UTF-8 CSV and delete a product from its settings. Those are the controls you have, and your privacy notice should describe them accurately, not as guarantees you have not checked with your own advisers.