How to Run an In-App NPS Survey

What you'll end up with

• A 0–10 NPS question inside your logged-in product, shown to the users you choose, at a moment you choose

• Every response attributed to a real person, without asking them who they are

• Promoters routed into a testimonial request or a case study invite, automatically

• In-app responses you can read separately from email responses

In-app or email: pick by who you need to hear from

When to show it

What never to interrupt

• The first session and any onboarding checklist. You'll measure setup friction and call it loyalty.

• Checkout, upgrade and cancellation flows. A score shown during cancellation measures the cancellation.

• Error states, and the screen right after a failed action.

• Anything with unsaved work — an editor, a long form, a half-built report.

• The week after a support ticket. You'll be scoring the ticket.

Card, panel or modal

Doing this with Testimonial

What you need before starting

• The Ultimate + plan. NPS with auto-routing is listed under Ultimate +, $95/month per space as of October 2026 — see pricing.

• A Space in Testimonial.

• Access to your app's front-end, or a developer who has it. The embed is a snippet; you decide where it goes.

• The signed-in user's name and email, available where you render the survey.

Steps

1. Create the survey. In your Space, click "NPS" in the left sidebar, then "New NPS survey" — or "Create your First NPS Survey" if you don't have one yet.

2. Name it for yourself. The Name is an internal label — recipients never see it. Something like "In-app — product" keeps it apart from your email survey.

3. Keep the question. The default is "How likely are you to recommend us to a friend or colleague?" You can rewrite it, but if you'll compare scores over time, leave it alone.

4. Turn on the follow-up. Tick "Ask a follow-up question". The default is "What's the main reason for your score?" It's optional for the respondent, sits on the same screen as the score, and takes up to 2,000 characters. In-app, I'd always keep it: the person has the product in front of them and can tell you exactly what they meant.

5. Check the thresholds. The colour-coded score bar has drag handles. Leave the standard 0–6 / 7–8 / 9–10 unless you have a reason to move them — how to calculate NPS shows how the buckets turn into the score.

6. Set promoter routing. Under Promoters, tick "Send them a testimonial request email", "Invite them to a case study", or both. The testimonial request goes out with the subject "Would you leave us a quick testimonial?" by default, with a "Leave a testimonial" button to your collection page. You can edit the sender name, subject, body and button colour. Passives and detractors have their own options in the same section; our guide to NPS surveys covers what to do with each.

7. Click "Create". You land in the survey's management view: Analytics, Submissions, Recipients, Settings, Embed. Skip "Recipients" — that's for email invitations.

8. Open "Embed" and choose the look. Turn on "Dark theme" if your app is dark. Turn on "Minimal mode" — a transparent background with no header — so the survey reads as part of your UI. Then click "Copy code".

9. Pass the person in. The help centre's instruction: if you already know who is viewing the page, append &email=... and &name=... to the iframe URL. That pre-fills and locks both fields and skips the "Tell us who you are" step. URL-encode both values. Illustrative, with blanks:

<!-- Paste the full snippet from "Copy code", then add the two parameters to the iframe's src -->
<iframe src="[the src from Copy code]&email=[url-encoded user email]&name=[url-encoded user name]" ...></iframe>

Build those values from your logged-in session on the server or in your app state, never from a field the user types into.

10. Render it only when your rule says yes. The embed shows wherever your code puts it, so the "when" lives in your app. A minimal version, illustrative:

// Illustrative — replace the bracketed values with your own rules
const showNps =
  user.isSignedIn &&
  user.coreActionCount >= [your threshold] &&
  daysSince(user.npsLastShownAt) >= [your cadence in days] &&
  !user.inOnboarding &&
  !user.openSupportTicket;
if (showNps) {
  renderNpsCard();            // your container + the snippet from step 9
  saveNpsLastShownAt(user);   // write the timestamp when you show it, not when they answer
}

Write the timestamp when the card is shown. If you only write it on submit, someone who ignores the card will see it every session.

11. Test it. Click "Preview" in the management view first to see what respondents see. Then sign in to your app as a test user, let the rule fire, and submit a score. Use a throwaway survey for this so test scores don't sit in your real numbers.

What it looks like when it worked

• The signed-in user sees the 0–10 buttons, labelled "Not at all likely" to "Extremely likely", straight away. No name or email screen.

• After they click "Submit", the response appears in "Submissions" with their name, score, comment and date.

• In "Analytics" you can view embedded NPS, email NPS, or all — so in-app responses stay separable from email ones.

• If they scored in your promoter range and routing is on, the testimonial request goes to the email you passed in step 9.

Where ours stops

1. It doesn't decide when to appear. It's an embed. Targeting, sampling and "last shown" tracking are yours to build — step 10 is the minimum.

2. The documented setup is a snippet for a web page. If your product is a native mobile app, check how you'd host it before you plan around it.

3. Identity is whatever you append. The pre-fill trusts the URL. Get the values from the session and the attribution is solid; get them wrong and every routed email goes to the wrong person.

Where people get stuck

Wrapping up