By the Wavefield Research team · Published Sep 25, 2026
App survey questions come in two channels: short in-app prompts, and link surveys sent to your user list by email or text. The 30 examples below, across six lifecycle moments, work in either — but the channel decides who you can reach, and the users you most need to hear from never see an in-app prompt.
The pages ranking for this search are in-app survey tools listing 25 to 65 questions for their own widgets. This page covers the part they can't: when the in-app channel is the wrong instrument, what a mobile app survey can claim about your user base, and the app store rating rules that make the prompt a terrible research tool.
The in-app prompt wins on timing: it can fire the moment a task completes, which no other channel can, and response rates on a one-question prompt are high. Its costs are structural. It earns one to three questions before abandonment, it interrupts the exact experience it is measuring, and — the part the widget vendors' guides leave out — it only samples people currently using the app. Every response comes from an engaged user by definition. That skew is invisible in the results: the dashboard shows healthy satisfaction scores drawn entirely from the people who stayed.
The link survey — an emailed or texted invitation to a survey the respondent opens on their own time — wins on everything that needs depth or reach: 10 to 12 questions instead of 3, lapsed and churned users included, segments you choose rather than whoever happened to open the app, and answers given outside the moment of use. Its cost is the invitation math: response runs 10–40% depending on the relationship (the honest benchmarks are in survey response rates), so reaching 300 churned users means inviting a multiple of that.
The working rule: in-app for pulses, links for research. A one-question effort score after checkout is a pulse. Understanding why activation stalls, what a plan is worth, or why people leave is research, and it runs on the link channel — on Wavefield, by uploading your user list and sending invitations by email link or text message, with quotas and reminders handled by the platform. We are a research platform, not an in-app widget SDK — if you need a one-question prompt inside your product, use a widget tool for that and a research survey for the questions that decide things.
Six moments, five questions each, with the response format tagged on every question — the format decision is half the craft. These are mobile app survey questions and web application survey questions alike; the lifecycle is the same, only the delivery differs. Swap the bracketed placeholders for your product and feature names.
First session to first week
Ask the goal question before habits form — the answer segments every later metric by intent, and it is the option list your roadmap conversations will quote.
After the first meaningful task completes
Trigger on the completed task, not a timer — 'day 3' hits people at random points in their journey, and the answers blur together. Event-triggered timing is the one real advantage in-app delivery has.
After first use of a specific feature
One feature per survey. A questionnaire that tours four features collects polite generalities about all of them; five questions about one feature collect something a product team can act on.
Around upgrade, renewal, or plan-limit moments
The switch question is the honest value read — naming a paid alternative signals real willingness to pay; 'nothing, I'd go back to spreadsheets' prices the product more truthfully than any satisfaction scale.
Active users, monthly or quarterly cadence
Cap the cadence: one survey per user per quarter is a defensible ceiling for active users. Fatigue shows up as declining response rates first and declining answer quality second — track both.
Cancellation flow, plus 2–4 weeks after going quiet
These cannot run in-app — a lapsed user never opens the app to see the prompt. This whole moment belongs to the link channel: email or SMS to your user list, within weeks while the reasons are still specific.
The most consequential app research question — why do people leave — is unanswerable through the app, because leaving means not opening it. In-app-only feedback programs run for years with this hole in them: every satisfaction read, every feature poll, every NPS pulse is sampled from survivors. The fix is boring and effective: keep your user list current, and field the churn and lapsed-user questions above as link surveys — email within days of cancellation, or a text message two to four weeks after activity stops, while the reasons are specific enough to code.
The same list-based fielding fixes the representativeness problem for big reads. When a launch decision needs “what share of our users would pay for this” rather than “what do the people in the app today think,” sample from the full user list with quotas by plan, platform, and tenure — so the answer describes your user base, not your most active decile. Screening and quota mechanics are covered in survey screening questions.
Both platforms constrain the rating flow in ways that make it useless for research — deliberately. Apple's system prompt displays to a user at most three times within a 365-day period, returns nothing to you but the public rating, and its timing is ultimately the system's call. Google's In-App Review guidelines go further: your app shouldn't ask the user any questions before or while presenting the rating flow — which outlaws the old “are you enjoying the app?” gate that routed happy users to the store and unhappy ones to a feedback form.
The clean pattern: let the rating prompt fire on its own best moment (after a completed task, within the platform quotas), and run your actual research as a survey on its own schedule. If a survey respondent turns out delighted, the thank-you page can invite a store review — that direction is compliant, because the survey came first and gated nothing.
A blended app-wide score hides everything useful. The same questionnaire read by platform (iOS versus Android), plan, and tenure routinely shows a healthy average masking a collapsing segment — new users on one platform, say, failing at a step long-tenured users never see. Cross the closed questions by those three segments as a default banner, mind the base sizes as segments get thin, and let significance letters say which gaps are real — the conventions are worked through in cross tabulation. NPS and satisfaction reads belong in the same discipline; the score math and its margins are in the NPS calculator.
And version the research like you version the app. A question set re-fielded after each major release, to a fresh sample from the same list with the same quotas, turns one-off reads into a trend — the wave mechanics are the same as any tracking study, and the broader customer-feedback program this slots into is covered in customer feedback surveys.
Match the question to the lifecycle moment: a goal question at onboarding ('What are you hoping to get done?'), an expectation check after first feature use ('Did it work the way you expected?'), an effort score after setup, a switch question around pricing ('What would you use instead?'), and open-ended reason questions at cancellation. Generic satisfaction questions asked at random times produce the least actionable answers in app research.
One to three. An in-app prompt interrupts a task, so it earns seconds, not minutes — a single scale question plus one optional follow-up is the standard pattern. Anything longer belongs in a link survey sent by email or text, where 10 to 12 questions is a reasonable ceiling and the respondent chose the moment.
The rating prompt is not a survey and cannot be treated as one. Apple's system prompt can appear at most three times per user per 365 days and returns no data to you beyond the public rating; Google's In-App Review guidelines prohibit asking users any questions before or while showing the rating flow. Run your research as a survey, separately, and let the rating prompt do its one job.
A working ceiling is one survey per user per quarter for active users, with event-triggered microsurveys (one or two questions after a specific action) allowed more often but capped per user per month. The failure mode is invisible: over-surveyed users don't complain, they just stop responding, and your response rate quietly becomes a biased sample of your most forgiving users.
The same sets by lifecycle moment — application survey questions differ from mobile app questions in delivery, not in content. Desktop and web software can rely more on email link surveys since there is no app store review flow competing for the same moments, and session lengths are longer, so end-of-session timing works better than mid-task interruption.
Yes, but as one question among several, on a quarterly cadence, always with the follow-up asking the reason for the score — the verbatims carry more product signal than the number. Track the score by segment (platform, plan, tenure) rather than as one blended figure, and mind the base sizes when segments get small.
Related: customer feedback surveys · survey response rates · SMS surveys · survey question types
Upload your user list, brief the agent, and field by email link or text with quotas by plan and tenure. Weighted, significance-tested results. From $99 per study.
Start a study