Capture information on STOP responses to SMS messages

[brotzmanmj]

Need to discuss where to store this information and the scope of information to be stored.

[brotzmanmj]

Decided on 3/7 to put this on hold and not purpose for this release

[brotzmanmj]

One thing we need to understand is what information if any is captured in the Notifications table if someone has requested STOP in response to a text message and we attempt to send them another text message (i.e. we have permission to text in the PWA). This is important for our metrics and our accounting of how many contact attempts we have made to the participant for an activity.

Warren's response: For example, a participant replied a “STOP”, then Twilio would put the phone number in its block list after receiving the “STOP”. If we later send a SMS message to the participant through Twilio, Twilio will give us a error response with code 21610. Based on my current implementation, if Twilio gives an error as response, the message is considered failed and thus its record won’t be saved. So, after a participant reply a “STOP”, there will be no further SMS message sent through Twilio and no records saved to notifications collection.

When @we-ai has time, he will test this and confirm.

[we-ai]

Hi @brotzmanmj I tested the "STOP" reply on March 12. My comments above are not accurate, because of the timing of Twilio checking block list.

This could be the flow of actions. When our code sends a message to Twilio, Twilio responds with a OK if it doesn't see anything wrong. Our code then saves the message record in Firestore. Before sending out a message, Twilio checks the block list, and send us a message with status "failed" when the recipient phone number is on the block list. Our code handles the incoming message and update the SMS message record with changed status.

So, after a participant reply a "STOP", Twilio still accepts messages sending to the participant without telling us errors, so message records can still be saved after our code calls the Twilio API. But Twilio later will send to us an error message with status "failed" (code 21610), and the information will be saved in the message record.

Check this file if you want to see more detailed about the data.

[brotzmanmj]

HI @we-ai This is very helpful, thank you for testing.
I see the blocked message at 8pm got the ErrorCode: 20160 and error message: "Attempt to send to unsubscribed recipient".

So @depietrodeanna and @HanaShiho from our perspective from a metrics accountability standpoint, we would know that this failed attempt should not be counted as one of the 10 contact attempts based on the error code and error message. (of course if the concurrent email was successfully delivered than the overall contact attempt would still count).

I think this is fine.

We discussed with Mia today and agrees we can discuss in a few months whether to import the STOP data and history. No need to do so for now.

[we-ai]

We need to update stop/start info to participant data, right? @HanaShiho @brotzmanmj

[brotzmanmj]

@we-ai Yes, thanks. Would the best route for this involve changing the existing 'permission to text' field for the mobile number to 'no' if they request 'STOP' and 'yes' if the request 'START'?

[HanaShiho]

@we-ai FYI, there is another GitHub issue related to this: https://github.com/episphere/connect/issues/1104

[we-ai]

Thanks for your comments @brotzmanmj @HanaShiho. I'll try to implement this (also #1104) in September release.

[we-ai]

PR#643 implements the requirements, with details below:

• SMS opt-out: Stop, Cancel, End, No, Quit, Unsubscribe
• SMS opt-in: Start, Unstop, Yes
• Data backfill: Update "can we text" (CID 646873644) to "no" (CID 104430631) when error code "21610" ("Attempt to send to unsubscribed recipient") is bounced back from Twilio