What is a feedback widget?

Which parts make up a feedback widget?

A feedback widget has three parts that work together:

1. The trigger. The element a customer clicks to open the widget. Usually this is a floating button in a corner, but it can be any link or button you mark up yourself.
2. The form. The panel that opens. It asks for the type of message, the message itself and, optionally, a rating and an email address.
3. Context capture. The data the widget attaches without asking. The page URL, the browser string and any user details your code passes in.

Remove any one part and the widget becomes something else. A form with no trigger is a page nobody finds. A trigger with no context is a contact link that produces unanswerable messages.

What does the trigger need to do?

The trigger has one job: make it obvious where feedback goes, without taking attention from the page. Good triggers are small, labeled and placed where they do not cover content, such as the bottom corner of the screen.

Most embeddable widgets, including Escuta Produto's, let you choose the side and color of the floating button. You can also hide the floating button and open the form from your own elements. In the Escuta Produto widget, data-trigger="none" hides the floating button, and any element with data-escuta-open opens the form. The value of that attribute, such as bug, preselects the message type.

How does the form collect a message?

A widget form should be short enough to finish in under a minute. The fields that matter most are the type and the message. Everything else is optional, which keeps the completion rate high for the messages you care about.

Customers choose a type from buttons such as bug, idea, praise and other. Some forms add a star rating, and the Escuta Produto form offers an optional 1 to 5 star rating. An email field is useful for people you cannot identify, but hide it when your code already knows who is signed in.

What is context capture and why does it matter?

Context capture is the difference between a useful report and a vague one. A widget that saves the page URL tells you where the customer stood. A widget that saves the browser string tells you which environment they used.

The Escuta Produto widget saves the page URL and the user agent on every message. The server adds the country. Your code adds the rest through the JS API, for example:

• EscutaProduto.identify({ email, name, id, plan }) sets who the customer is for every message sent after the call.
• EscutaProduto.setMetadata({...}) attaches extra JSON, up to 4 KB, such as the feature flag a customer is testing.

For a full explanation of what each field is for, read what feedback metadata is and why it matters.

What are the main types of feedback widget?

Widgets differ mainly in how they are opened and where they sit:

Type	How it opens	Best for
Floating button	Always visible in a corner	General feedback on any page
Inline trigger	A link or button you place next to a feature	Feedback about one feature or screen
Code-triggered form	Your code calls the open method after an event	Error screens and post-task moments
Hosted page	A link to a separate page, not a widget	Customers who cannot load the app, and sharing in emails

A hosted page is not a widget because it lives on its own address. It is useful as a fallback, and the hosted feedback page shows how to link to one.

How do you keep a widget from slowing the page?

Load the script with the defer attribute so the page renders first. The Escuta Produto widget is about 5 KB compressed, has no dependencies and renders inside a Shadow DOM, so its styles do not leak into your site and your styles do not leak into it. Those choices keep the impact on the rest of the page small.

Check the widget on a slow connection before you publish it. If the page is slower after adding the script, move the script lower in the body or load it only on pages where customers can act on it.

How do you add a feedback widget with Escuta Produto?

Copy the script tag from your product settings into the pages where feedback makes sense. The tag carries your public product key in data-key, which can only create feedback and never read it. Add data-color to match the button to your brand and data-position to move it to the left.

Set the allowed origins in product settings so only your own sites can submit through the widget. That single setting blocks most abuse from copied keys. The full list of attributes is in the widget documentation.

If you are not sure whether to build your own widget or use a ready one, the build versus buy comparison covers the work a widget hides. For the wider picture of how feedback arrives, read what in-app feedback is.