Implementation worksheet · 5 min read
A Survey Dismissal Persistence Test Plan
Test seven cases against any survey tool (or your own layer) before trusting it in production: dismiss then reload (prompt stays gone), dismiss then new session next day (still gone — the cooldown is server-side, not a cookie), dismiss on desktop then log in on mobile (gone there too — persistence is per-user, not per-device), dismiss then re-qualify for the same survey's audience (cooldown wins over re-targeting), dismiss then a DIFFERENT survey targets the user (the global frequency budget arbitrates, not each survey independently), respond then re-qualify (response cooldown wins), and clear cookies then return (logged-in users stay suppressed — only anonymous users may legitimately re-see). A tool that fails case two or three treats dismissal as a UI event instead of a user decision, and it will spend your users' patience to fill your response quota.
Every survey tool demos the beautiful prompt; none demo what happens after 'no thanks'. But dismissal handling is where tools quietly diverge — cookie-based suppression that resets, per-survey cooldowns that let five surveys each take their shot, per-device state that re-prompts on mobile. The test plan takes an hour and predicts a year of user goodwill.
Put it into practice
1. Build the two-account, two-device rig
One test user on desktop browser + mobile (or second browser), one control user untouched. Every case below runs on the test user; the control confirms targeting still works for the un-dismissed.
2. Run the persistence trio first
Dismiss → reload; dismiss → next-day session; dismiss → other device, same login. All three must stay suppressed. Cookie-only suppression fails the second or third — that's a disqualifying architecture for logged-in products, not a settings issue.
3. Test cooldown vs re-targeting
Re-add the test user to the survey's audience (edit the segment, or re-trigger the event). The cooldown must win. Tools that re-prompt on every audience refresh turn weekly segment recomputes into weekly nags.
4. Test cross-survey arbitration
With survey A dismissed, launch survey B targeting the same user. If B fires immediately, each survey manages its own politeness and the user experiences their sum — this is where a global frequency budget either exists or doesn't.
5. Test the response side and the anonymous edge
A completed response must suppress at least as long as a dismissal. Cookie-cleared anonymous visitors may legitimately re-see prompts; logged-in users never should. Document each case's result — this artifact is your vendor-acceptance record.
The seven cases
Copy this structure into your review document and record your observed result for each row.
| Case | Action | Must hold | Pass? |
|---|---|---|---|
| Reload | dismiss → refresh | suppressed | |
| New session | dismiss → return tomorrow | suppressed (server-side) | |
| Cross-device | dismiss desktop → open mobile | suppressed (per-user) | |
| Re-targeting | dismiss → re-enter audience | cooldown wins | |
| Cross-survey | dismiss A → B targets user | frequency budget arbitrates | |
| Post-response | respond → re-qualify | response cooldown wins | |
| Anonymous edge | clear cookies (logged-in) | still suppressed |
A failure worth checking
The per-device amnesia: dismissal stored in localStorage, so the user who said no on desktop gets the same prompt on mobile that evening, and again after the next cache clear. Each re-prompt reads as the product not listening — and the response-rate dashboard reads it as 'more impressions', rewarding the leak. By the time anyone audits, the survey's real output has been unsubscribes from attention, not answers.
Common questions
What's a reasonable dismissal cooldown to configure?
30-45 days for recurring programs like NPS; forever for one-off research surveys (a declined study invitation shouldn't reappear). The number matters less than the persistence being server-side and per-user.
We run anonymous-heavy pages — what then?
Accept cookie-based suppression as the ceiling for anonymous traffic and set longer cooldowns to compensate. The moment a user authenticates, migrate their suppression state server-side — the test plan's anonymous edge case verifies exactly this handoff.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.