Surveys

Everything else in StorePilot watches what people do. A survey is the one place you can ask them why. It renders as a small card on your storefront, in its own shadow DOM root so your theme cannot restyle it and it cannot restyle your theme, and the answers land beside the session that produced them — so a one-word complaint can be followed straight into the recording of the visit that prompted it.

A site with no active survey downloads nothing: the survey bundle is only imported when the loader says there is a live survey to consider.

Building one

Dashboard → Surveys → New survey. A survey is up to 10 questions, each one of four kinds:

Kind	What the visitor sees	What is stored
NPS	The 0–10 "how likely are you to recommend" scale	The integer 0–10
Rating	A 1–5 scale	The integer 1–5
Choice	Up to 12 options, one pick	The index of the option, not its text
Text	A free-text box, up to 2 000 characters	The answer, with personal data scrubbed

A choice answer stores the option's position rather than its label on purpose. Rename "Fast delivery" to "Delivery speed" a month in and every past answer is relabelled with it, instead of splitting into two rows that look like two different answers to two different questions.

Question text is limited to 300 characters and each option to 120. Question IDs are minted once, when you add the question, and are never re-minted when you edit it — answers are stored under them.

A new survey is a draft

Surveys are created switched off, unlike alert rules, and the list shows them as Draft until you flip the toggle to Live. A rule that goes live early routes a notification to you; a survey that goes live early shows itself to your customers. Only an admin can switch one on.

Who sees it, and when

Targeting decides who, and it is evaluated in the visitor's browser — nothing about who was considered is sent anywhere.

• Page — contains, starts with or exactly, matched against the path. Leave it empty for every page.
• Device — any of desktop, tablet, mobile. Empty means all three.
• Sample — 1–100%. The sample is deterministic on the visitor, not on the page view: a visitor who falls outside a 20% sample stays outside it for every page of every visit, rather than rolling the dice again each time and eventually being caught.

The trigger decides when, and the three kinds select genuinely different people:

• Delay — seconds after the page loads. 0 shows it as soon as the page is up.
• Inactivity — seconds of stillness; any movement, key, scroll or touch restarts the count. Floored at 3 seconds, because 0 would mean "immediately", which is what Delay is for.
• Scroll — a percentage down the page. A page with nothing to scroll counts as 100%, so the survey still fires.

Asking twice, and not asking twice

The card keeps appearing until the visitor decides. What is recorded is the decision, never the fact that a card was shown:

• Answered → never shown to that browser again.
• Dismissed with the × → not shown again for 24 hours, then it may ask once more.
• Ignored → nothing is written, and it appears again on the next page.

Both records are kept per survey, in localStorage (wpelSurveyDone_<id> and wpelSurveyDismissed_<id> — also listed in the Cookie Policy). The earlier design counted showings and counted them globally, and a real visit killed it: a card appeared on one page, the visitor changed page without touching it, and that single showing spent the budget for a second survey nobody had ever seen. Nothing had been answered and nothing refused, and the shop had gone quiet on both questions.

The cost of the current rule is stated plainly: a visitor who neither answers nor closes the card sees it again on the next page. The × is one click and it buys a day.

Answering some questions and then closing the card sends what was answered. Partial answers are answers.

Checking that it works, without polluting the results

Add ?sp_survey=<id> to any page of your site — the Preview button on a live survey builds the URL for you. It skips the sample, the 24-hour cooldown and the trigger, so the card appears immediately, and it labels itself "Preview — answers are not saved".

Preview does not skip consent. A browser sending Global Privacy Control, or one that has not accepted your banner when consent is required, sees nothing whatever the URL says — and that is the most common answer to "why is my survey not showing".

This exists because "it doesn't show" was otherwise unfalsifiable: the sample, the fatigue rules and the trigger are three reasons a correctly built survey legitimately does not appear, and from your side they look exactly like a broken one.

Reading the answers

Dashboard → Surveys → [survey], with a date range like every other screen.

NPS gets the score itself — promoters minus detractors as a percentage — over a band bar showing Detractors (0–6), Passives (7–8) and Promoters (9–10). Ratings and choices get magnitude bars per value. Text answers are listed newest first, 50 at a time, and each one that belongs to a recorded session carries a Watch the visit link straight to the replay.

Export CSV gives you all of them, not the visible 50 — one row per response, one column per question, with choice answers resolved to their labels rather than the stored indexes. It needs the member role, like every other export.

What is and is not collected

A response is one row per (survey, session): a replayed or double-clicked submit cannot double a vote. Answers ride the same consent gate as everything else — a refusal, a Global Privacy Control signal, or an unknown survey all end the same way, with nothing stored and no error shown to the visitor.

Free-text answers pass through the same personal-data scrubbing as every other free-text field, so an email address typed into a comment box is stored as [email].

Responses are kept for 365 days. They are included in a visitor's data export and removed by an erasure request, like every other record tied to a person — see GDPR.