In-app surveys are simultaneously the highest-leverage and most-abused tool in the product team's toolkit. They give you direct user signal that no analytics dashboard ever will. And they get butchered.
The classic failure mode looks like this:
- Team decides "we should measure satisfaction."
- Someone wires up a quarterly NPS modal that fires on login for every user.
- Response rate is 3 percent. Most respondents are angry.
- Team uses that 3 percent to make decisions.
- Everyone wonders why the decisions feel off.
This post is a playbook for not doing that.
There are really only three survey types worth running in-product. Each answers a different question and they are not interchangeable.
"How likely are you to recommend [product] to a friend or colleague?"
NPS measures brand love. It is a long-horizon signal. If your NPS is bad, your product is in trouble at a fundamental level. If it is good, you have permission to keep doing what you are doing.
NPS is the wrong tool for:
- Measuring whether a specific feature works.
- Diagnosing why activation is low.
- Anything you want to act on within a quarter.
NPS is the right tool for the executive dashboard slide, and not much else.
"How satisfied were you with [the thing that just happened]?"
CSAT is contextual. It fires after a specific interaction, asking about that interaction. After a checkout. After a support ticket closes. After a feature is used.
The trick is that the question must be tightly scoped. "How satisfied are you with Frigade?" is useless. "How satisfied were you with the chart you just exported?" is actionable.
CSAT is what you want when you are diagnosing a specific journey.
"What is one thing we could do to make this better?"
This is the most underused survey type and frequently the most useful. One field. Plain text. No rating scale.
The yields are lower than rated surveys (people will not always type) but the quality of answer per response is dramatically higher. You will get five sentences of context instead of a number.
Use this when you have a specific decision to make and need real reasons, not aggregate ratings.
Brex's NPS pattern and Slack's product survey are both clean examples of well-targeted in-app surveys, each using a different type for a different goal.
The single biggest determinant of survey response quality is when it fires.
Bad timing:
- On login, before the user has done anything.
- During an active workflow (writing a doc, processing a payment).
- Three milliseconds after the user signs up.
- Five seconds after a flow that just frustrated them.
Good timing:
- After a successful action that took some effort. The user feels a small sense of accomplishment and is in a generous mood.
- After the user has been quiet for a few minutes (about to leave). They are thinking about wrapping up.
- A few days after a specific feature launch, only to users who actually tried the feature.
The "after a successful action" timing alone will roughly triple your response rate compared to "on login."
Survey question framing is its own discipline. A few rules that compound:
Avoid double-barreled questions. "How happy are you with the speed and accuracy of our search?" Speed and accuracy are two things. The user picks an answer that averages them, which is meaningless.
Avoid leading language. "How much did you love our new feature?" already implies they should love it. Use neutral framing.
Use specific time references. "In the last week" or "the last time you used X" beats abstract "in general."
Cap the rating scale at 5 or 7. Eleven-point scales (the NPS standard) are statistically defensible but psychologically miserable. For most internal questions, 5 is plenty.
You do not need every user to respond. You need enough responses to be confident in the signal. For most product decisions, 30 to 50 responses per cohort is enough to see a clear pattern. For statistical significance on a small effect, you need more.
The relevant heuristic: if your top answer category has fewer than 10 votes, you do not have enough data yet. If it has more than 50, you can probably stop collecting and start acting.
The number from a rated survey is not actionable. The text in the comments is.
For every NPS or CSAT survey, include an optional follow-up text field. The rating tells you the magnitude. The follow-up tells you the reason. Decisions get made from reasons, not magnitudes.
When reviewing responses:
- Read the comments first, before looking at the score distribution. Score distribution will bias your reading.
- Tag comments by theme (do this manually for the first 100, then automate). The themes are where the work is.
- Cross-reference theme tags with cohort segmentation. "Onboarding is confusing" from a free-trial user is a different problem than "onboarding is confusing" from a 6-month customer.
If you have three different surveys firing in your product, you have probably trained your users to dismiss surveys as a category. There is a real survey fatigue tax.
Cap it: one survey per user per month, total. If you must run more, segment them so a given user only sees one of them.
You will get more signal from one well-timed, well-framed survey than from five that everyone ignores.
A simple in-app survey is roughly 50 lines of code if you build it yourself: a dismissible widget, a rating component, a free-text field, and a backend endpoint to store responses. If you have engineering capacity, that is the cleanest path because the result lives in your codebase, integrates with your design system, and writes to your data warehouse.
If you do not have that capacity, a Form or Survey component from a tool like Frigade gives you the same shape with less work.
Every shape above is the same medium: pick a rating, click a button, fill a field. That medium is now the legacy one. Users in 2026 are already in the habit of typing what they actually think to an AI, in plain language, and getting a useful response back. A rating-and-textarea modal feels like a fax machine by comparison.
The next shape of in-app research is a conversation. The user does not pick from a rating scale, they say what they mean. The agent asks the follow-up that an experienced researcher would have asked. The depth of a user interview at the response volume of a survey, which has historically been impossible.
The Frigade Assistant runs in-app research this way. It opens the conversation proactively at the right moment per user (via Frigade Suggestions) instead of waiting for the user to opt into a modal, which lifts response rates dramatically. It asks targeted follow-ups based on what the user just did and what they said to the previous question. Useful when "rate this from 1 to 5" is too thin and "schedule a 30 minute call with me" is too heavy.
Either way you ship in-app research, the technology is the easy part. Picking the right shape (conversational vs clickable), timing it well, and asking the right question is the work.
