[flibble]

We are facing the issue of SMS not getting delivered and have implemented failovers (Messagebird, Nexmo, Twilio) when we detect delivery problems. However we have a problem that frequently we get sent positive delivery receipts despite the SMS not being delivered. This makes it hard to know if we should fail over. Has anyone good solutions fur this?

[toast0]

Positive delivery receipts from an SMS aggregator have approximately zero diagnostic value.

If you want them to mean something, you need to have a direct connection with the carrier of your user, and you have to know that the carrier or their network doesn't just fake positive delivery receipts at some point in the system to make numbers look good. With an aggregator between you and the carrier, you have no way of knowing when the delivery path changed and the intermediary faked a delivery report.

The absence of a positive delivery receipt doesn't really mean anything either. Negative delivery reports have some information content though.

My context is sending verification codes though; receiving a code back from a user is a much better measure of successful delivery to the user than a delivery receipt. If you're sending news or something where there's no measurable direct action taken as a result of the message, I guess a delivery receipt is better than nothing, maybe?

Realtime measurement and thompson sampling or multi-armed bandit with as many credible providers as you can manage is the best way forward, don't send retries through the same provider either.

[Vuska]

I used to work for a UK SMS SaaS provider.

I'm surprised you'd frequently get false positives. What regions were you sending to?

They were essentially unheard of with the UK networks and very rare with European networks. It was only Middle East and African networks that were troublesome, but they represented a tiny fraction of our traffic. Even then, false positives were rare compared to messages just not getting delivered.

[dsincl12]

Super interested in this as well. I switched from Messagebird to Twilio after giving Nexmo a try and it's a lot better now but still get false positives.

[xeromal]

Who do you get false positives from the most?

[dsincl12]

For me personally it was Messagebird. Two failed demos because of this and the response from them where non-existent. I was even contacted by one of their sales people after I wrote my last "angry I'm leaving" email asking me if I was interested in using their services.

[theblueprint]

Yes, similar position with Messagebird. Lack of transparency in their reporting/insights vs Twiliio. That said, our Twilio pricing is 2-3x Messagebird.

[aeonsky]

If its something requested, the user can always re-request it. If it not something requested like news, use two different providers to send 2 messages. One the actual content, and then a minute later, a different smaller message saying "This message brought to you buy MyCompany. Please text back STOP to stop messages or AGAIN to get the latest alert again." Some end users might get better delivery results with a specific texting service, so it might be useful to set service affinities on a user specific basis.

[john_minsk]

You must be kidding. This never happened to me so far, but if it did, I would be so unhappy with YourCompany that probably would never buy anything from you again

[aeonsky]

You understand that OP is requesting a solution for a practically unfixable issue. Unless you a have relationship with the carrier itself. A provider sends you a success, but it was actually a failure. Imagine a DB sending Commit-OK, but data was never written. You probably wouldn’t buy very much from a company that uses that kind of DB as well, since it loses your orders.

Once again, if you are receiving texts that must mean you opted into them. User is expecting them and it’s different from a user receiving two texts never having signed up for them.

I do believe this technique uses some out of the box thinking and mostly DOES solve OPs problem.