Find Activation Blockers With In-App Surveys
Use an activation survey when events show where progress stopped but you still need the visitor’s account of the experience. Define the activation milestone, ask a short question at a supported moment, and compare the answer with the behavior you can inspect.
A response can identify a reported blocker. It does not prove that the blocker caused every drop-off, and it remains useful even when no associated replay is available.
Define the activation question
Choose a concrete milestone: a completed import, a connected integration, a first published item, or another verified action that represents first value for your product. A signup is not automatically activation.
Map the steps before that milestone. Select one step and one audience for the review. Record which completion events exist and which signals are missing before interpreting the drop-off.
Choose a supported moment
Monolytics Surveys support page or path conditions, load, time on page, instrumented custom events, and client or session properties. A failed-attempt trigger requires a verified event your product emits. Time on page alone does not establish that someone is stuck.
Check the survey with test activity before launch. The targeted-feedback guide shows how to choose an audience, check conditions, and review an answer.
Ask one neutral question
| Audience | Example question | What it can help you investigate |
|---|---|---|
| Visitors at the selected setup step | “What, if anything, made this step difficult?” | Reported effort, unclear instructions, or an external dependency. |
| Users who completed setup | “Which part of setup, if any, took more effort than expected?” | Friction that successful users encountered. |
| Users who did not activate | “What were you trying to do when you last used the product?” | Whether the chosen milestone matched their task. |
If you follow up with people who have left the site, use your own permitted outreach process; this guide does not promise automated email follow-up in Monolytics.
Avoid questions that assume failure or demand a negative answer. Start with one question, and add another only when it serves the decision. The UX question guide includes more examples and leading-question rewrites.
Read the answer without dismissing it
These illustrative responses suggest different checks:
- “I got an error when I tried to import my CSV but the message just said ‘invalid format.’” Check the import error and recovery instructions.
- “I need to ask my IT team to whitelist the domain before the integration works.” Check the external dependency and whether the setup instructions explain it.
- “I set up the project but then didn’t know what to do next. The dashboard was empty.” Review the next-step guidance and available session context.
- “The permissions screen asked for access I’m not comfortable granting without talking to my manager.” Investigate the reported approval need.
“It’s fine, just exploring” and “Everything is great!” can also be valid experiences. They do not become bad responses merely because they fail to support the team’s suspected problem. A vague answer such as “I don’t like the design” may need a follow-up before choosing a change.
Compare with available behavior
Group responses by the issue reported, then record the evidence separately:
- Reported experience: what the respondent said.
- Observed activity: relevant events or behavior visible in an associated replay, when the underlying record exists.
- Open question: what remains unverified or was not captured.
- Next check: a reproduction, clearer instruction, neutral follow-up, or bounded change to evaluate.
Not every answer has a stored replay. Keep those responses in the review and state the missing context. Repeated reports and matching recordings can strengthen a hypothesis, but a fixed response count does not establish causality or represent every new user.
Choose the next action
Prioritize using the task blocked, the ability to recover, the affected segment, and confidence in the evidence. If you estimate prevalence, use an appropriate denominator from your measured cohort; survey respondents alone are not all users.
A useful handoff has one row per candidate issue: the setup step, reported experience, observable evidence, limitations, and next check. After a change, verify the activation event and review whether the same symptom remains.
For the broader setup path, use the onboarding friction workflow. To review the current product scope, see Website Surveys.