The survey lifecycle
- Draft — editable, invisible to users. Everything starts here.
- Published — targeted users are prompted on their next page load. The text is fingerprinted at this moment, and that fingerprint is what every response records.
- Archived — prompting stops. Existing responses are untouched.
Reusing a survey
Clone, in the row menu, copies a survey and its questions — body, type, enforcement, audience, pacing and window all come across. The copy is titled “… (copy)” and always arrives as a draft at version 1, with no publish date and no content fingerprint.
Use it to run the same rating survey each quarter, to trial reworded terms beside the current ones, or to reuse a carefully targeted audience without rebuilding it.
Clone or bump the version? Clone when you want a separate instrument that keeps its own answers. Bump the version when it is the same obligation and you need everyone to agree again — see below.
Writing a prompt people will answer
- Keep optional surveys to one or two questions. Response rates fall off a cliff after that.
- Say why you are asking in the message. “We are deciding what to build next quarter” earns more answers than a bare rating widget.
- For required surveys, put the whole obligation in the text. The person is agreeing to what is on screen, and that is what gets fingerprinted — not a linked document elsewhere.
- Write the question as a question. “How would you rate ERPat this month?” not “Rating”.
Versioning: when to bump
Editing a published survey changes what new people see. Ticking Publish as a new version does something much bigger: it invalidates every answer already given and asks everyone again.
| Change | Bump the version? |
|---|---|
| Fixing a typo or a broken link | No |
| Clarifying wording without changing the obligation | No |
| New clause, changed obligation, new data use | Yes |
| Annual re-acknowledgement of an unchanged policy | Yes |
Keeping optional surveys polite
Three settings control how often someone is bothered. They apply to optional surveys only; a required survey ignores all of them and keeps asking until it gets an answer.
| Setting | Default | What it does |
|---|---|---|
| Snooze (days) | 7 | How long “Not now” holds the prompt back. |
| Cooldown (days) | 30 | Quiet period after the person answers anything. |
| Max prompts | 0 (unlimited) | Hard ceiling on how many times they are ever asked. |
Users also have their own escape hatch: Don’t ask again opts them out of that survey permanently, across every future version. That is intentional — an optional survey somebody has explicitly refused is not one worth asking again.
Reading the responses
The Responses page is the ledger. Filter by survey, by outcome, or by date.
| Outcome | Means |
|---|---|
| Agreed | Accepted a required prompt, or submitted one. |
| Declined | Explicitly refused. A deliberate, recorded choice. |
| Answered | Completed an optional survey. |
| Opted out | Chose “Don’t ask again”. Not an answer to the question. |
Each row shows the person as they were when they answered — not as they are now. If someone changes their name or leaves, the record of what they agreed to stays accurate.
Watching the numbers
Overview gives you acceptance rate, response counts and the star distribution. A required survey’s acceptance rate is the number worth watching: a high decline rate usually means the text is unclear or is asking for something people are not willing to give.
Ratings from the mobile app
Rating Details lists what users submitted through the mobile app, filterable by app, platform, star value and date. Which apps can be rated is decided in the App Library (the Applications module): a published app accepts ratings (apps with admin-only or hidden visibility stay off the rating surface), and unpublishing it stops new ratings while keeping the history. The old in-module App Catalog was retired in 1.6.0.