1.1 Keep surveys short and focused

Participant fatigue is the single biggest threat to EMA compliance. Aim for surveys that can be completed in under two minutes; longer than three to four minutes and response rates fall sharply.

Rule of thumb: every additional question past ~10 items costs you measurable compliance. Cut anything that isn't core to your research question.

Why this helps us both: shorter surveys mean higher response rates and cleaner data for your analysis — and fewer participant complaints and drop-out tickets reaching our support team.

1.2 Use the right question types

Prefer single-tap question types (Likert scales, single-choice, sliders) over free text. Free-text questions are slow on a phone keyboard, and participants will start skipping them or giving one-word answers within a few days.

Reserve free text for a small number of high-value moments (e.g., one daily reflection prompt).

Why this helps us both: single-tap responses give you analyzable structured data and us fewer "my keyboard isn't working in the survey" tickets to investigate.

1.3 Design assessments for high-frequency data collection

Assessments designed to collect self-report data infrequently don't work well when they run multiple times per day or per week. In particular, questions that ask for a response of degree (e.g., “on a scale of one to five, how are you feeling?”) become relatively meaningless without something to frame the answer against. Participants tend to select much the same answer every time.

Increasing the numeric range (e.g., one to ten, or one to one hundred) only introduces false precision.

To make these questions useful and improve accuracy, you can:

Create question pairs. Introduce a calibration question, then the primary question. For example, if someone told you about a friend who is an amazing guitar player and you asked, “On a scale of one to ten, how good are they?”, they would likely say eight or nine. But if you first ask a calibration question — “Who is the best guitar player ever?” — and they answer “So-and-so”, you can use that to anchor the primary question: “OK, let's say So-and-so is a ten. On a scale of one to ten, how would you rate your friend?”

Replace fixed-scale answers with comparative answers. When you ask the same question many times per day (e.g., “On a scale of one to ten, how are you feeling?”), the same answer can indicate any number of states depending on when and in what context it was asked. But if you ask “Compared to last time, how are you feeling?” with options such as “Worse than last time”, “The same as last time”, and “Better than last time”, you create a context that yields more meaningful data. You also build a cumulative scale based on mean variance rather than absolute ratings — regardless of how someone responds in the moment, you can plot a trend across their responses. To increase granularity, add options such as “much worse” and “much better” to the list.

Why this helps us both: making answers more contextually meaningful to the participant lets you offer trend analysis and even charts that show progress. This can dramatically improve compliance and produce much more accurate data.

1.4 Make assessments engaging and fun

The easiest way to sustain schedule compliance is to make completing an assessment feel rewarding — even fun.

• Use plain, easy-to-understand language

• Give participants feedback based on the answers they provide

• Create multiple paths through an assessment, with conditional questions based on previous answers

• Vary questions by randomly selecting from n versions of the same question

• Use mean variance to show progress

• Provide positive feedback based on compliance scores

Why this helps us both: assessments that are engaging and have rewards built in reliably improve compliance — especially when participants are asked to complete the same questionnaire day after day or week after week.

1.5 Think carefully about prompt timing

Notifications should fit into participants' lives, not interrupt them. Avoid prompts during likely sleep hours, very early morning, or late evening unless your protocol specifically targets those windows.

For random-prompt designs, set a minimum gap between prompts so participants are not pinged back-to-back, and limit the number of daily prompts to what your sample can realistically sustain (typically 4–6 per day for healthy adults; fewer for clinical populations).

Why this helps us both: well-timed prompts protect your response rate and reduce the volume of "why am I getting notifications at 3am" support tickets — which are stressful for participants and time-consuming for us to triage.

1.6 Pilot internally before anyone else sees it

Before you invite even a single participant, have at least two people on the team install the build and live with it on their own phone for two or three days. You will catch things no spec review surfaces: confusing wording, broken skip logic, notifications firing at the wrong time, surveys that feel longer than they read.

If it annoys you for three days, it will infuriate participants for three weeks.

Why this helps us both: issues found in internal pilot are issues we never have to debug under launch pressure. Every problem you catch here is one we don't have to fix urgently later.

1.7 Never change schedules, configurations, or assessments once you go live

Too often a seemingly innocuous change to an assessment, schedule, or configuration parameter affects data collection in unforeseen ways. Even if it means delaying launch, make sure you have thoroughly piloted your final assessments, configurations, and schedules before setting them loose on participants.

Why this helps us both: most issues after launch trace back to a minor, seemingly innocuous change to an assessment, a schedule, or a configuration. With a thorough pilot of the final product, we can avoid almost all of the problems that arise during a live study.

Before moving on

Have a written protocol document that captures: survey content and skip logic, prompt schedule, study duration, enrolment criteria, compensation structure, and the criteria you will use to define a "compliant" participant. You will refer back to this constantly.

2.1 Send for an audit request after building and testing

Once your survey is built and you have tested it internally, send the survey for an audit request before enrolment. The audit is a second pair of eyes on survey logic, structure and complex dependencies — issues caught here cost minutes, the same issues caught after launch can cost the study.

Why this helps us both: the audit is the single highest-leverage moment for us to help you. Catching a misconfigured dependencies in 10 minutes during audit saves both of us days of urgent fixes during the study.

2.2 Test the full participant flow end-to-end

Walk through what a participant will actually do: install the app, sync, grant permissions, receive prompts, complete surveys across multiple days, hit the end-of-study. Do this on both iOS and Android if your study supports both.

Pay special attention to: notification delivery (especially after a phone restart or being unlocked for the first time in the morning), permissions flows (microphone, location, notifications, bluetooth), and what happens if a participant misses a prompt or completes a survey late.

Why this helps us both: platform-specific quirks found during testing are easy for us to address; the same quirks found after enrolment turn into emergency tickets affecting real participants and real data.

2.3 Verify data is landing as expected

While testing, check that your test responses are actually arriving in the dataset, that timestamps and identifiers look right, and that any passive measurements (AMP, GPS, Garmin) are producing the rows you expect. It is much easier to debug a missing field with two test participants than two hundred real ones.

Why this helps us both: verifying the data pipeline before launch means we can fix issues at the source rather than working backwards from a partial dataset weeks later.

2.4 Prepare participant-facing materials

Write a short onboarding document or video covering: how to install the app, how to grant permissions (and why), what to expect day-to-day, what to do if notifications stop arriving, and who to contact. Participants who understand the study upfront are dramatically more compliant.

Include a troubleshooting one-pager (e.g.: OnDemand survey): "my notifications stopped", "I missed a survey", "I am traveling to a different timezone", "my phone died".

Why this helps us both: good onboarding materials prevent the most common participant questions from ever reaching support, freeing us up to help with genuine issues and you to focus on your data.

2.5 Test your participant-facing materials

Recruit people you know and fellow team members to test your onboarding protocol and materials. Don't wait until you're onboarding live participants to discover that the process or materials aren't clear and easy to follow. When you can, watch someone download the app, apply their configuration, and get started — that is how you find the gaps in your instructions.

Why this helps us both: observed dry runs uncover gaps in participant guides — the kind that creep in because the people writing the guides already know what needs to happen and take “obvious” steps for granted. Testing with people who don't have an insider view surfaces the small things that cause the biggest headaches.

3.1 Onboard participants in person or on a call when possible

Walking a participant through installation, permissions, and the first survey live (in person or over video) dramatically reduces drop-out in the first week. Many participants who would silently churn after a confusing self-onboarding will stick around if the first session goes smoothly.

If in-person onboarding is not feasible, send a clear written guide and offer an optional 10-minute support call.

Why this helps us both: live onboarding catches setup problems while they're still fixable. The alternative is days of back-and-forth support tickets with a confused participant whose data is already incomplete.

3.2 Stagger enrolment when feasible

Resist the urge to enrol every participant on day one. Staggered enrolment (in waves of 5–20) means that if a problem surfaces — a misconfigured prompt schedule, a broken question, an unexpected platform behaviour — it affects only the first wave and can be fixed before it touches everyone else.

Why this helps us both: staggering means any issue we discover together impacts a small group rather than the whole cohort — easier for us to fix, less data lost for you.

Once enrolment starts: freeze the survey

Do not change survey content, prompt schedule, or data fields after the study has started. Even a "small" change — re-wording a question, adding an option, shifting a prompt window — creates a discontinuity in the data that is painful (sometimes impossible) to disentangle in analysis. If a change is truly unavoidable, document the date and exact nature of the change in your protocol, and treat pre-change and post-change data as separate cohorts.

Note: if you make any saved configuration change at all, participants must perform a Download Update on their phone for it to take effect — another reason changes mid-study are risky.

Why this helps us both: a stable configuration means we can support your study confidently with a clear picture of what every participant is seeing. Mid-study changes force us into reactive debugging and you into messy analysis.

4.1 Have team members shadow the study from the participant side

As a standing practice, for each type of phone in the study (Android and/or iOS), have at least one person on the team enrolled in the live study with the same configuration as participants. They receive the same prompts, fill out the same surveys, and notice the same friction. This single practice catches more real-world issues — missed notifications, draining battery, confusing wording in context — than any amount of dashboard-watching. And if you see compliance problems within your own team, that is a strong signal you need to improve the engagement and rewards built into your assessments.

Why this helps us both: a shadow account gives you a trusted in-team reporter and gives us a high-quality first-hand description when something does go wrong. "It happened to me too at 09:15 yesterday" is far easier to investigate than a second-hand participant report.

4.2 Check the compliance dashboard regularly

Make checking compliance a routine — daily for the first week, then at least two or three times per week. You are looking for:

• Participants whose response rate drops sharply (likely about to disengage — reach out)

• Participants who never started at all (onboarding failure — reach out quickly while it is still recoverable)

• Cohort-wide dips on specific days or times (suggests a notification or scheduling issue)

The earlier you intervene with a slipping participant, the more likely they recover. After about a week of silence, most participants are gone.

Why this helps us both: early detection of cohort-wide patterns lets us investigate while the cause is still recent and traceable. Spotting a notification problem in week 1 is far easier for us to diagnose than the same pattern reported retrospectively at the end of the study.

4.3 Inspect your data regularly, not just at the end

Not pulling and reviewing your data regularly is the single most common reason problems go unaddressed and study results end up compromised. Pull the dataset at least weekly and look at it — not just count rows, but actually scan a few participants' records end-to-end. Things to check: are all expected fields present, are timestamps sensible, are passive measurements (Garmin, GPS, etc.) producing rows when they should, are there silent participants showing up as "enrolled but empty".

It is much cheaper to discover a missing field in week one than in week six.

Why this helps us both: weekly data review surfaces pipeline issues while we still have the device logs and context to debug them. Six weeks later, a missing field is much harder for either of us to trace back to its cause.

4.4 Communicate proactively with participants

A short check-in message at week one and again mid-study — "thank you, you're doing great, here's how to reach us if you need help" — measurably improves retention. Participants who feel forgotten disengage; participants who feel seen keep going.

Always provide a clear contact channel (email or in-app) and respond within a business day. A 48-hour silence after a participant reports a problem is often the moment they decide to stop.

Why this helps us both: engaged participants ask their questions to you first, and you can resolve most of them quickly. Disengaged participants either drop out silently or escalate small issues straight to us as urgent tickets.

4.5 Reward compliance — and structure the reward well

Compensation is one of the strongest predictors of compliance. Beyond the headline amount, the structure matters:

• Tiered or milestone-based rewards ("complete 80% in week 2 to unlock the next tier") outperform a single end-of-study payment.

• Small, frequent payments feel more motivating than a large lump sum far in the future.

• Be transparent: participants who know exactly what they will earn, and when, are more compliant than those who are unsure.

Why this helps us both: well-rewarded participants stay engaged and complete the protocol, which gives you cleaner data and reduces the volume of "why isn't this participant responding" investigations that pull our team in.

4.6 Report problems right away — and never delete a participant account when something goes wrong

We do our best to address problems quickly, but too often the trace evidence that would help us diagnose an issue has gone cold or been deleted altogether. Report problems as soon as you notice them, and never delete a participant account when something has gone wrong — that account and its data are frequently exactly what we need to find the cause.

Why this helps us both: early reporting and an intact trail of evidence make it possible for us to keep your study on track and prevent the same problem from recurring.

Heuristic for "is this study healthy?"

Three numbers tell you most of what you need: overall response rate, week-over-week response rate trend, and the proportion of participants still actively responding. If any one of these drops noticeably for two consecutive checks, treat it as a signal to investigate, not a noise blip.

5.1 Notify participants when the study ends

Send a clear end-of-study message: thank them, confirm their compensation timeline, tell them they can uninstall the app (and how to do so cleanly if any data needs to sync first). Participants who finish a study positively are far more likely to take part in your next one.

Why this helps us both: participants who close out cleanly stop generating uncertainty about whether their data is still arriving — which means fewer late-arriving rows for you and fewer "is this participant still active?" investigations for us.

5.2 Do a final data integrity pass before analysis

Before locking the dataset, do one careful scan: confirm all enrolled participants are represented (or accounted for in dropout records), check that every expected field is populated, verify timestamps and timezone handling, and reconcile compliance numbers between the dashboard and the raw export.

Document any data anomalies, dropouts, or mid-study events (a participant changing phones, a network outage) — these belong in your analysis notes, not your memory.

Why this helps us both: if there's an issue in the final dataset, finding it now means we can investigate it with full context. If it surfaces during analysis weeks later, both of us will be working from cold.

5.3 Run a brief retrospective

Write down what worked and what did not, while it is still fresh. Survey questions that turned out to be confusing, prompt schedules that hurt compliance, onboarding steps that tripped people up, dashboards that were not informative — all of this is gold for your next study and for the rest of the team.

Why this helps us both: retrospectives shared with our team help us improve the platform and our support for your next study — which directly benefits your next protocol.

6.1 Understand what the app can do before you finalize your protocol

Have a clear understanding of the app's existing functionality before locking in your study design. Many sudden mid-study requests for app changes trace back to a protocol that was written without knowing what the app already supports — or what it doesn't. Read the existing documentation, ask questions, and walk through a sample study build before you commit.

If your protocol depends on a feature that isn't already in the app, surface that early — not after enrolment has started.

Why this helps us both: knowing the app's capabilities upfront means your protocol fits what's available, and we can flag any genuine gaps with enough time to address them properly — rather than building features under launch pressure.

6.2 Triangulate before declaring an app issue

If a participant reports they are responding but their data shows otherwise — or says notifications aren't arriving — check whether other participants are seeing the same thing before concluding it's an app issue. One participant's report can be caused by many things: a phone-specific setting (Do Not Disturb, battery saver, notification permission revoked), an OS update, network issues, or a genuinely silent participant.

Cross-checking with the rest of the cohort tells you whether you're looking at an individual-device problem or a study-wide one — and that distinction completely changes how it gets fixed.

Quick check: is this participant the only one with the issue, or are several affected? Same device/OS, or mixed? Did the issue start at a specific date/time? Answers to these three questions usually point straight at the cause.

Why this helps us both: this small check filters out the ~70% of "app issues" that turn out to be device settings or individual quirks. The cases that do reach us come with the context already gathered, so we can focus on solving them instead of asking diagnostic questions for a day before we start.

6.3 Be specific and complete when requesting a new feature

When asking for a new feature, be clear and concrete from the start. Vague requests like "can we add some flexibility to the prompt schedule" generate rounds of clarifying questions; a one-paragraph description of the exact behaviour, with an example, can save days of back-and-forth.

A good feature request includes:

• What you want to do (the user-facing behaviour, not the implementation)

• Why you need it (the research goal it serves)

• A concrete example or scenario showing the desired outcome

• Any constraints (which platforms, by when, must it work alongside existing features X and Y)

• What "good enough" looks like — the minimum that would unblock you, vs. the ideal version

Why this helps us both: a complete request lets us scope and prioritize accurately the first time, so you get a useful answer faster and we avoid building something that doesn't quite solve your problem.

6.4 Write support tickets the support team can act on

When a participant has an issue, the speed of resolution depends almost entirely on how complete the ticket is. Always include:

• Participant ID (rsp_id or mobile code)

• Survey (survey ID)

• Timestamp or timeframe of when the issue happened — as narrow as you can make it (a 10-minute window beats "yesterday afternoon")

• What the participant did, what they expected, what actually happened

• Device and OS version if known

Even when you suspect the issue is general, always include at least one concrete example. Your suspicion may be right, but it may also be wrong, and a single specific example lets the support team verify which it is in minutes rather than hours. "This affects everyone" without an example is the slowest possible kind of ticket to triage.

Why this helps us both: a complete ticket is one we can start working on immediately. A partial ticket means a back-and-forth that delays the fix — affecting the participant whose data is at risk, and pulling our team into diagnostic loops instead of solving the underlying issue.

Anatomy of a fast-to-resolve ticket

Subject: Survey not advancing after question 3 — participant P-1042, study X

Body: Participant P-1042 reports that on May 18, around 14:30 local time (UTC+2), the morning survey (svy_id: morning_v3) froze after answering question 3 and the Next button stopped responding. Device: iPhone 13, iOS 17.4. They force-closed the app and the data for that survey didn't sync. Have not yet checked whether other participants saw the same — flagging now in case it's broader.

This ticket has everything the support team needs to start investigating immediately, plus the right framing about whether it's individual or widespread.

Avoid

Long surveys. Participants will not complete a 6-minute EMA survey five times a day for three weeks, no matter what they tell you at enrolment.

Changing the survey mid-study. Creates a permanent break in the data. If you must, treat pre- and post-change as separate cohorts.

Skipping the audit. The cost of a 1-hour audit is always lower than the cost of fixing a launched study.

Treating the dashboard as a launch-and-forget tool. Compliance erodes silently; only active monitoring catches it.

Silent participant communication. Going dark on participants between enrolment and end-of-study is the single biggest controllable cause of attrition.

Asking participants to fix things you should have caught. If multiple participants report the same issue, the problem is the study, not the participants.

Reporting issues to support without specifics. "The app is broken" with no participant ID, no timestamp, and no example is the slowest kind of ticket to resolve. Always include one concrete case, even if you think it's widespread.

Assuming "it must be the app" before triangulating. Most apparent app issues turn out to be device-specific (Do Not Disturb, battery saver, revoked permission). Check across participants before raising it as a platform bug.