What is in-app feedback?

What does in-app feedback look like?

In-app feedback is a short form that lives inside your product. A customer clicks a button labeled "Feedback", picks a type such as bug, idea, praise or other, types a message and sends it. The message reaches your team without an email client, a support address or a separate web page.

The button can be a floating element in a corner of the screen, a link in a settings menu or a button placed next to one feature. Escuta Produto's widget adds the floating button by default. Any element with a data-escuta-open attribute opens the same form, so you can place entry points wherever a customer is most likely to have something to say.

How does it differ from email and surveys?

Three channels compete for the same customer attention. Each answers a different question.

Channel	Who starts it	Context you get	Best for
In-app feedback	The customer, when they have something to say	Page, browser and any user details you send	Bugs, ideas and praise tied to a screen
Support email	The customer, often after the problem has grown	Whatever the customer types	Account problems that need a conversation
Survey	You, on a schedule you choose	Only the answers to the questions you wrote	Comparing the same question over time

Email is the default for most small teams, and it works for one-off questions. Its weakness is missing context. A message that says "the export is broken" arrives without the page, the browser or the plan, so someone has to ask follow-up questions before the item is useful.

A survey asks the questions you chose. It answers "what do you think of this?" but misses the message you did not think to ask about, such as "this button did nothing on my phone". In-app feedback is open by default, so customers can raise the problem you did not expect. Escuta Produto does not run surveys or NPS campaigns. If you need scheduled questions, run them with another tool and post the results through the REST API with metadata.

When does in-app feedback work best?

Show the entry point at a moment when the customer has something concrete to say:

1. Right after a task. Exporting a report, inviting a teammate or finishing a setup step are good moments to ask how it went.
2. Next to a new feature. A button beside a feature you just shipped can preselect the idea or bug type, so the feedback is about that feature.
3. On error screens. A "something went wrong" page is where the most useful bug reports begin. A feedback link there turns a dead end into a report.
4. In settings or help menus. Customers who want to suggest something larger will look there.

Keep the form away from onboarding steps and checkout. A customer who is trying to pay should not be stopped by a feedback prompt, and a new user who has not yet reached the core feature has nothing to report about it.

What should the form ask for?

A good in-app form asks for very little. A typical form has four parts:

• Type: bug, idea, praise or other. Customers pick the type themselves, and you can preselect it from the entry point.
• Rating: an optional 1 to 5 star rating. It gives you a quick trend number alongside the written message.
• Message: the only required field in practice. Ask for the message itself, not for a long template.
• Email: shown only when the user is not identified. If you pass the email with identify(), customers never see the field.

Every extra field lowers the number of people who finish the form. Let the page context do the work that a long form would otherwise do.

What context does an in-app message carry?

Context is what separates in-app feedback from a contact form. The Escuta Produto widget saves the following automatically or from your code:

• Page URL: the screen the customer was on when they sent the message.
• Browser: the user agent string, which names the browser and operating system. It helps when a layout bug only appears in one browser.
• Country: added by the server when the message arrives.
• User details: the email and name you pass to identify(), plus any other keys, such as an account id or plan name, stored as metadata on every message.

With the page URL, a message about a broken export becomes a link you can open. You can load the same page, try the same action and see the failure. Without it, the first reply is usually a question about where the customer was.

What are the limits of in-app feedback?

In-app feedback has real limits, so plan around them:

• It only reaches people who use the product. Prospects, trial visitors and churned customers will not see your button. Keep a support address or a hosted feedback page linked from your site for them.
• A broken product can block the button. If a bug stops the page from loading, the customer cannot send the report. Link the hosted feedback page from your help center as a fallback.
• It creates volume. A busy product can produce dozens of messages a week. You need a routine to read and decide on them, which is covered in what feedback triage is.
• It does not capture the screen. Escuta Produto does not record sessions or take screenshots. Ask customers to describe what they see when the bug is visual, or use a dedicated visual bug tool for that job.

How do you start with in-app feedback in Escuta Produto?

Copy the script tag from your product settings into your app, with your product key in the data-key attribute. For logged-in users, queue an identify call so every message carries who sent it:

window.EscutaProduto = window.EscutaProduto || { q: [] };
(window.EscutaProduto.q ||= []).push(["identify", [{ email: user.email, name: user.name, id: user.id }]]);

Then read the widget setup guide for placement options such as data-position, data-color and data-trigger. If some customers need a link instead of a button, the hosted feedback page gives them one. For a deeper definition of the context that makes messages useful, see what feedback metadata is and why it matters, and for the difference between the button and the wider collection process, read what a feedback widget is.