Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Goals:

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

Non-Goals:

  • Generic re-usable automated notifications.

How to Model Activity Burst

App will need to use the Publish Custom Event API to publish custom events for "activityBurst1Start", "activityBurst2Start", etc... (Note that we can schedule off custom events, but if there are duplicate event IDs, we schedule off the first such event. So each activity burst start will need to use a different event key.) "activityBurst1Start" should be the same as enrollment date (or possibly whenever the user upgraded to mPower 2), and the subsequent burst start times should be every 3 months after that (or whatever interval we decided).

If the user reinstalls, the app can use the Get Activity Events API to verify if the user already has activity burst events configured.

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".)

When the app completes each activity, it will need to call the Update Activity API to mark that activity as completed.

Registering for Notifications

In order for the app to receive in-app 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?

Activity Burst Notification Worker

We will need to add worker APIs for:

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

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:

  1. Check that the user has registered for notifications. If they haven't, don't bother doing any work. Just skip.
  2. Look up the user's activity events to determine where they are in the study burst.
  3. If the user is in an activity burst, get all their activities since the start of the activity burst to see if they've been completing their activities. (Note that the only way to look up a user's activity is by their guid, so the worker will need to know the activity guids for the activity burst.)
  4. If certain conditions happen (the user has done less than X activityes in at least Y days), send a notification to the user using the Send Notification API.

Handling Time Zones

(Stretch Goal)

The previous design assumes everyone is in the US, and it will send notifications at 12pm/1pm for PST/PDT, 1pm/2pm for MST/MDT, 2pm/3pm for CST/CDT, and 3pm/4pm for EST/EDT. Note that Alaska is one hour before Pacific Time, and Hawaii is 2 hours before Pacific Time, meaning that Hawaiians can be notified as early as 10am. This doesn't account for US residents in Pacific Islands that are far outside our timezones, or are otherwise not anywhere near contiguous US timezones. This also means that the notification can be spread around up to 4 different hours in the contiguous US (more outside the US), rather than having a consistent notification time.

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.)

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 runs, 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.
  • No labels