Good survey copy cannot rescue bad timing. “How was your experience?” is vague after login, intrusive during payment, and nearly useless without knowing what the user attempted. The same question can become useful when it appears after a completed workflow and feeds a defined decision.

Before choosing an example, review the principles for collecting app feedback. Then adapt one of the six patterns below to your event and uncertainty.

Trigger: the user completes the core workflow for the first time.

Ask: “What nearly stopped you from completing this?”

Optional context: “Which step felt uncertain?”

Decision: choose the next onboarding clarification or remove an unnecessary step.

This question avoids asking whether the entire product is “easy.” It looks for friction while the sequence is fresh. Suppress it if the workflow ended with an error or support incident.

Trigger: the user repeatedly performs a detour, such as copying data out, reopening a filter, or correcting the same setting.

Ask: “What are you trying to preserve or change each time?”

Optional context: one short text field.

Decision: improve persistence, defaults, export, or workflow memory.

Behavior selects the audience, so the question reaches people with actual evidence. Do not infer the motive from analytics alone; the survey exists to test that interpretation.

Trigger: an operation fails and the user either retries, exits, or recovers.

Ask: “What were you trying to complete when this failed?”

Optional context: “Did you find a workaround?”

Decision: prioritize the failure by blocked job and improve recovery guidance.

Do not ask the user to reproduce technical details the app can log safely. Attach the error class, version, and workflow step internally while avoiding sensitive payloads.

Trigger: a user views plan details but does not purchase.

Ask: “Which outcome would make this plan worth considering?”

Choices: a small set based on actual product outcomes, plus “None of these” and an optional explanation.

Decision: clarify value, change packaging, investigate missing capability, or leave the offer unchanged.

Avoid asking “Why didn’t you buy?” immediately after every visit. Apply a cooldown and do not confuse a stated preference with willingness to pay.

Trigger: the user completes the same feature on several distinct days.

Ask: “What job does this feature replace for you?”

Optional follow-up: “What still happens outside the app?”

Decision: improve the repeated job, integration, or positioning instead of adding unrelated features.

This pattern studies value after real use. It is more reliable than asking new users which future features they might want.

Trigger: the user has decided to cancel or delete; the action remains unblocked.

Ask: “What changed or remained missing for your use case?”

Choices: no longer needed, missing capability, reliability, cost or predictability, trust or privacy, switched workflow, other.

Decision: separate product gaps from changed circumstances and determine which issue deserves follow-up.

Never make feedback mandatory to leave. Confirm the requested action clearly and keep retention offers separate from research.

Preview the survey on the smallest supported screen, with a keyboard open, larger text enabled, and a slow connection. Confirm that dismissal is visible, focus order is sensible, the prompt is not repeated after submission, and the underlying task can still be completed.

We reviewed verified public Google Play feedback visible for Todoist and Replit on 16 August 2026. We paraphrased recurring language around sync and task state, downtime and repeated errors, pricing or credit expectations, and useful calendar, widget, or fast-creation experiences.

Those themes informed the example categories above. They do not show how common an issue is: public reviewers self-select, ordering changes, and context is incomplete. No reviewer identity or verbatim quote is used.

For the complete timing workflow, read how to run a mobile app survey without annoying users.