Add a feedback widget to a Bubble app

Where does Bubble let you add a script?

Bubble apps have a script area in the SEO and metatags settings, where you can add script and meta tags to the page header. Anything you put there is included on every page of the app. That makes it the right place for the widget's single script tag, so the floating Feedback button appears throughout your app.

The script goes in the header area, not inside a page element. Use the defer attribute as shown in the install snippet so the page does not wait for the widget.

<script src="https://escutaproduto.com/widget.js" data-key="pk_your_product_key" defer></script>

Identify the Current User with a workflow

The header area cannot use Bubble's dynamic data, so the widget cannot know who is logged in from there. The workaround is a workflow. Create a workflow that runs when the page loads, add a condition so it runs only when the Current User exists, and then add a Run JavaScript action. That action comes from the free Toolbox plugin, so install Toolbox from the plugin marketplace first if your app doesn't have it.

In that action, pass the Current User's email and name as properties. Inside the JavaScript, call the widget's identify function with those values. The queue pattern is the safe way to do it, because it works whether the script has loaded yet or not:

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

Check how your Bubble version names the properties inside the action, because the name you give each property in the action has to match the name the code reads. Test with a logged-in user. The email field should be hidden in the form.

A condition is important. If you run identify for a logged-out visitor, the email and name fields are filled with empty values, which is confusing. Run the action only when there is a user.

Open the widget from your own button

Many Bubble apps have a help or feedback button in the navigation, and that is a better prompt than a floating corner button in some layouts. To use your own button, set the floating button off in the script tag by adding data-trigger="none" to the snippet.

Then add a button element with a workflow on click. The workflow runs a Run JavaScript action that calls the widget's open function with the type you want:

window.EscutaProduto.open({ kind: "bug" });

Use kind "idea" or "praise" for other prompts. Only call open after the page has loaded, since the script has to be present. The button should say what happens, such as Report a problem, so visitors know where the message goes.

Test the live version, not the development version

Bubble keeps a development version of your app, which you edit, and a live version that visitors use. Changes you make in the editor reach the live app only after you deploy. A widget test in the development environment does not prove that the live app works.

Deploy the change to live, then open the live domain in a private window. Sign in with a test user to check identify, and sign out to check the anonymous form. If a test fails, the live version is the one to debug, because that is what customers see.

Keep allowed origins in step with Bubble's domains

Your app answers at your custom domain, and Bubble also gives it a default address on its own domain. If you test on a Bubble address, add that address to allowed origins too, using the full https form. Requests from any site not on the list are rejected with a 403 response.

Add the live domain first, since that is what customers use. Only add the other addresses if your team tests there, and remove any you no longer use.

Bubble feedback in Escuta Produto

Each message from your app lands in the inbox of its product, with the page URL and browser saved. In a Bubble app, the page URL often shows a route with parameters, so you can see which screen the visitor was on. Filter by type to separate bugs, ideas and praise, then set statuses as you decide.

Internal notes are the right place for context the customer never sees, such as a link to the Bubble workflow that needs a fix. Slack and Discord webhooks in the product settings send each new message to your team channel, so a bug report reaches the person who can fix it quickly.

Common Bubble mistakes to avoid

A few problems come up again and again on Bubble apps, and each one is quick to avoid.

The first is running identify without a condition. A visitor who is not logged in has no Current User, so the email and name fields are empty. Add the condition, so the workflow runs only when a user exists.

The second is testing only in the editor. The development version is useful for building, but customers use the live version. Check the live domain after every deploy, because a change that looks right while you edit can behave differently once it is live.

The third is putting dynamic data in the header. The header area is static, so Bubble values written there do not change per user. Use a workflow for anything that depends on the visitor.

The fourth is leaving test domains on the allowed origins list. Remove any Bubble address you no longer test on. The live domain should always be on the list, and nothing else should need to be.

The fifth is forgetting that the floating button appears on every page of the app, including screens where a feedback prompt would confuse people, such as a checkout or a sign-up step. Either accept it, or turn the floating button off and place your own button on the screens where feedback fits.

Related

• The full widget reference is in the widget docs, including the identify call and the open function.
• If you would rather send people to a page than add a widget, see the hosted page docs.
• For a different no-code builder with a header script, read Add a feedback widget to a Framer site.
• For how to sort what arrives, read What is feedback triage?.