...

• If a user doesn't do their scheduled burst activities after N days, we send them an in-app SMS notification.

Non-Goals:

• Generic re-usable automated notifications.

...

If the user reinstalls, the app can use the Get Activity Events API to verify if the user already has activity burst events configured. Note that we use this API because it already exists, and because we assume the app wants to know where the user is in an existing study burst (if any). If it turns out that the app doesn't need to know where the user is in the study burst, we could always implement a "publish activity event if not exists" API, but that API doesn't exist yet.

The server will have schedules for each activity burst, using the activity burst event ID and sequence period to schedule daily activities. (Note that for custom events, we add the prefix "custom:" to the event key. Example: "custom:activityBurst1Start".)

...

In order for the app to receive in-app SMS notifications, the app will need to call the Create Notification Registration API.

Open Question: How does the notification get routed to the app? Does AWS take care of this?

SMS vs In-App Notifications

SMS notifications are desired specifically because they are more heavyweight than in-app notifications, and because users who haven't engaged with the app are unlikely to respond to in-app notifications.

Opting Out of SMS Notifications

We need to give users a way to opt-out of receiving SMS notifications. We only send SMS notifications if a user hasn't engaged with their study burst in 2+ days, so at that point, opting out of SMS notifications should also opt the user out of the study. So the users will need to respond to the SMS with "QUIT STUDY" to opt out.

Open Question: How to handle opt-outs? Can this be configured in AWS?

Activity Burst Notification Worker

...

• get notification registrations for user
• get activity events for user
• get activity history for user
• send notification to user

(NOTE: These APIs all exist for study researchers, but they do not yet exist for workers.)

The worker will be scheduled to run daily at (for example) 20:00 UTC (12pm PST / 1pm PDT). The worker will iterate over every user in the given study, and for each user:

...

We can instead have the notification worker run every hour, calculate what timezone offset corresponds to "noon local time" (or whatever arbitrary local time we want notifications to be sent at). Note that special handling will need to be done to handle fractional timezones. (Note that there are no fractional timezones in the US.) This will be configured as part of the notification worker.

While iterating users, the notification worker can check the user's time zone (this is persisted when they first ask for scheduled activities), and if that user's time zone doesn't match with the time zone we're currently processing, we skip the user.

Note that there are a few issues with this approach:

• If a user changes time zones between notification runsNote the users cannot currently change their timezone on the server. Even during DST change, we use the user's original timezone for scheduling. This means that during DST change, or if the user physically changes timezones, this could cause the notification to be sent at a different local time zone.
• If in the future, we do allow a timezone change, this may cause the notification worker to "skip" that user. This can be fixed by having our notification rules to send on Day >= 3 instead of on Day 3, but we'll need to keep track of whether we've sent the notification to that user for this activity burst, to make sure they don't receive duplicate notifications.If a user changes time zone without updating their time zone in the server, or if the DST switch happens, this could change the local time the notification is sent.
• The notification worker iterates over all users 24 times a day. This is fine for now, while the participant pool is fairly small. Long term, we could solve this by building a more sophisticated worker, where the first worker runs daily, goes through all users, figures out if we should send a notification, and if so, figures out when (based on user's time zone). The second worker runs hourly, figures out which users have scheduled notifications, and then sends them.