-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce randomness into the scheduler. #8
Comments
Karma:ProblemI think it would be wasting effort to improve schedules for the current bot but rather go straight ahead to working on bot 1 and 2 and how to schedule them. This is because the time it will take to build out the schedules for the current iteration which I estimate will be by end of this week and to be deployed by the beginning of the next one. Which will then overlap with the schedules for the next iteration which should be done by the end of next week. I tend to avoid Friday deploys. So with this in mind let me give my implementation plan for what I feel has most value (scheduling of bot 1 and bot 2):
Okay that out of the way let's talk about scheduling of the messaging hour/time. We have randomly generated the time for each of the 16 interactions. Which is indistinguishable from if they were generated randomly in real time. For example: message them at 10 am after 3 days, 8 pm after 6 days, 2 pm after 9 days, 1pm after 12 days and so forth. Since there will be be 16 total interactions (I'm ignoring the initial non scheduled one) and we have a 12 hour period from 09:00 to 21:00 in which to message them we can initiate 13 interactions using the 13 hours from 09:00 to 21:00 and still have 3 interactions to repeat hours that we feel have a lot of value. SolutionUse RapidPro campaigns Rationale
|
Scheduling engineering implementationWe want to be able to message users in a predetermined schedule (intervals) or/and at a time of day that they or we specify (think of a setting reminder). Real time random scheduling in terms of time of day is indistinguishable from predetermined random scheduling as long as the messaging interval is not random. Otherwise, random intervals can also be p regenerated and then saved in which case they are also indistinguishable than if they were generated in real time. In other words, real time random scheduling is either impossible or not worth the effort. Problem/current requirementsKarmaHas two conversations.
SofiaHas 5 conversations aimed at different users entirely. Schedules not yet determined.
Possible future requirementsHave users set the time that they want to be messaged (like setting a reminder). Implementation ideasWhat can be used:
RapidProUse RapidPro to manage not only the users but the messaging schedules.
Advantages
Drawbacks
Triggers
CampaignsCampaigns are a RapidPro feature that allows you to run a flow over a group.
A scheduling tool from the internetWriting our own scheduling toolRequirements/good to have
Components
Redis scheduler DB schema
Redis -> Celery -> RapidPro Platform permissionsMessengerWe need pages_messaging_subscriptions permission to initiate messaging with user more than once in 24 hours for now we are able to use pages_messaging. Facebook permissions:
|
This is a great write-up 😄, it sounds like we're committing to using RapidPro campaigns, but to use them for our particular use-case we'll need to write code on our end to manage communicating with the campaign API. I.e. we'll still be writing something that creates campaign events for a group based on a schedule, so aren't we still responsible for writing that scheduler? And then I'm not sure if the answer is yes, and the parts about the custom scheduler are describing how we'd build that, which something that uses the RapidPro campaigns |
Yes! For Karma we'll use the pre-determined schedule going straight down to create RapidPro campaign. |
Cool, so we need to add some details, or a separate implementation issue describing how the tool that creates campaigns based on the pre-determined schedule will work |
Environment
All
Expected behavior
We want to be able to message different contacts within the same group at different and random times. Moreover, we would like to stagger the number of messages per week to something like 3 messages a week.
Actual behavior
Messages can only be sent out at a fixed time every day as a minimum.
Implementation plan
The text was updated successfully, but these errors were encountered: