Most Samply problems are configuration, not failure, and almost all of them are visible before the first notification goes out. This page is ordered by what you would notice, not by what is technically wrong.
If your study has not started yet, the fastest route is the Setup check on your study dashboard: it inspects your configuration and offers a test notification that sends through the real pipeline and shows you the survey link exactly as the participant's phone received it. Almost everything below is caught by that one check.
1 · A participant stopped receiving notifications
This is the most common report, and it has several causes with very different fixes. Work down the list — they are ordered by how often they turn out to be the answer.
What happens: the push token identifies the app installation, not the person. Reinstalling, restoring to a new device, or in some cases an OS upgrade issues a new token, and the old one stops working permanently.
What you see: the analytics page shows “N participant(s) can no longer receive notifications”. Samply learns this from the push service's delivery receipts, usually within an hour of the next send.
The fix: the participant opens Samply Research and logs in. That re-registers the device automatically. If they are unsure, ask them to open the Notification check screen in the app menu and tap Re-register this device — the same repair, done deliberately.
What happens: many Android manufacturers add aggressive battery management on top of stock Android. The push is accepted by Google's servers and then delayed or dropped by the phone itself. Samsung, Xiaomi, OnePlus, Huawei, Oppo and Vivo are the usual offenders; behaviour varies by manufacturer and by Android version.
What you see: nothing. This is the important part. The notification was accepted for delivery, so Samply counts it as sent and no warning appears anywhere. The only signal is a participant who reports missing prompts while every server-side indicator looks healthy.
The fix: the participant excludes Samply from battery optimisation. The steps differ per manufacturer, and dontkillmyapp.com documents them device by device — it is the best reference available and worth sending directly to participants with Android phones. The in-app Notification check screen also links to the phone's settings.
Prevention: mention this in your onboarding instructions rather than after the fact. Asking Android participants to do it on day one costs a minute; asking on day five means you have already lost their data.
What happens: the app asks for permission at first launch. If the participant declines — or later turns notifications off, which some people do in bulk when tidying their phone — nothing can be delivered.
What you see: if permission was never granted, the participant has no push token, so they appear enrolled but never receive anything. If it was revoked later, the token may keep working from the server's point of view for some time.
The fix: Notification check in the app menu reports the permission state directly and opens the right settings page.
A device registers for notifications when the app runs. Someone who joins through a link, then force-quits and never reopens, may never complete registration. Their row exists; their device is unreachable.
iOS can hold notifications back and deliver them in a batch, or silence them under a Focus mode. Participants often do not realise this is on. The notification arrives — just not when you scheduled it, which for experience sampling is frequently the same as not arriving. Ask participants to allow Samply to deliver immediately.
Push services hold a message for a while and deliver it when the device reconnects, but they do not guarantee it, and an expired link may no longer be useful by then. If your design depends on a prompt reaching people within a narrow window, set a link expiry so late arrivals are not answered out of window — and expect some loss.
2 · The survey export has no participant identifier
This is the most damaging thing that can go wrong, because it is silent, and because it is discovered during analysis when the study is already over.
There is no way to reconstruct who answered what after the fact. If your design needs person-level or multilevel analysis, verify this on day one with a test notification.
What happens: without %SAMPLY_ID% in the Web Link, the survey receives no identifier at all. Every response is anonymous and unlinkable.
The fix: the schedule editor now warns about this while you type, and the Setup check reports it. Use the Build this link for me builder rather than assembling the URL by hand — it adds the correct parameters with the right names for your survey platform.
What happens: a URL may contain only one ?; further parameters are joined with &. Pasting a second ?id=%SAMPLY_ID% onto the end swallows everything after it into the previous parameter's value, and the survey stores a mangled identifier or none.
The fix: saving a schedule with a duplicated placeholder or a stray second ? is now blocked with a specific message. If you are editing an older schedule, re-save it to run the check.
What happens: most survey platforms ignore unexpected URL parameters unless you declare them. In Qualtrics an Embedded Data field must exist in the Survey Flow with a name matching the query key exactly, including capitalisation. SoSci needs the parameter registered; LimeSurvey needs it defined under panel integration.
How to tell this apart: this is the case where Samply's test notification shows the ID present in the link, but your export still has an empty column. The problem is on the survey tool's side.
The fix: follow the integration guide for your platform, then run a test response and download the export to confirm the column is populated. Watch for reserved parameter names — each tool has some, and they are listed per platform.
This works, but adds burden at every single prompt and introduces typos and inconsistent casing that you will have to clean. It is worth the twenty minutes to wire the parameter through properly.
3 · Response rates look wrong, or reminders go to everyone
What happens: Samply only knows a survey was finished if the survey tells it. That requires two things: %MESSAGE_ID% in the notification link, and a redirect at the end of your survey back to /studies/<study-code>/done/<message-id>, with the message id echoed using your tool's own syntax.
What you see: the analytics page warns when a study has sent notifications but recorded no completions at all. That banner appears during the run, not after it.
Also worth knowing: some tools cannot redirect to an external URL at all, and some only on paid plans. The compatibility table lists which.
Why: reminders are cancelled automatically the moment a completion is registered — but if completion tracking is not wired up, Samply has no way to know who has answered, so every reminder goes to everyone. This is the same root cause as above, and it produces duplicate submissions you will have to de-duplicate by hand.
The fix: add %MESSAGE_ID% and the end-of-survey redirect. The reminders step in the schedule editor warns you when they are missing.
Samply counts a notification as answered if the participant tapped it, opened it from their in-app history, or the survey reported completion. If none of those happened — for example they copied the link to a desktop browser — the response exists in your survey tool but Samply cannot attribute it. Compare against your survey export before treating Samply's compliance figure as final.
4 · The numbers on the analytics page look wrong
Check the window selector at the top of the page. Entire study is the default; a fixed window such as 7d is a rolling window anchored to now, so messages older than that leave the count as the study progresses. Nothing is lost — the window moved. Switch back to Entire study for cumulative figures.
Notifications sent before mid-2026 were not tagged with the schedule that produced them, so they cannot be attributed retroactively. New sends are. Event-contingent and API-triggered notifications legitimately have no schedule and always appear here.
They measure different things, and some divergence is expected. Samply counts notifications and interactions with them; your survey tool counts submissions. Partial responses, responses started from a desktop, and duplicate submissions all separate the two. Test notifications are excluded from Samply's figures and its data export, so they will not explain a gap. For your own analysis, export the raw event log from the study's History page and compute what you need directly.
5 · No notifications were sent at all
Check these in order:
- Is the study active? An inactive study sends nothing.
- Has anyone joined? A schedule with no recipients produces no sends.
- Does the schedule target the right people? If it is limited to a group and nobody is in that group, or limited to participants enrolled at creation time while your cohort joined afterwards, the queue will be empty.
- Check the timezone. A schedule set in the wrong timezone fires at the wrong local hour — often in the middle of the night, which looks like non-response rather than misconfiguration.
- Look at the scheduled queue. Every schedule expands into one row per participant per send time. If the queue is empty, the schedule never produced anything, and the cause is above rather than in delivery.
6 · What to tell participants
Most participant-side problems are fixed by the participant, not by you. It is worth putting this in your onboarding material rather than sending it reactively:
- Allow notifications when the app asks. If you declined, you can turn them on in your phone's settings.
- On Android: turn off battery optimisation for Samply, or the phone will delay or block prompts. dontkillmyapp.com has the steps for your specific phone.
- On iPhone: make sure Samply is allowed to deliver immediately, not held in a Scheduled Summary or silenced by a Focus mode.
- If you reinstall the app or change phone, open Samply and log in again so your device is re-registered.
- If prompts stop arriving, open Notification check in the app menu. It shows exactly which step is broken and offers a one-tap repair.
7 · Preventing all of this
Run the Setup check on your study dashboard and send yourself a test notification before recruiting. The test goes through the ordinary send pipeline and reports four things: that the notification was sent, that the link carries the participant identifier, that it was opened, and that completion was reported back. A study that passes all four will not fail in any of the ways described on this page.
Then complete one full response yourself and download the export. That is the only way to confirm your survey tool is storing the identifier, which Samply cannot see from its side. It takes five minutes and it is the single highest-value thing you can do before recruiting.
If something here does not match what you are seeing, or you hit a failure this page does not describe, get in touch — the list grows from reports.