3 ms·

Thanks. I understand limits these days are based on 10DLC trust? Do those throttling still apply even with staying under those limits? I think the floor is 0.0

Thanks. I understand limits these days are based on 10DLC trust? Do those throttling still apply even with staying under those limits? I think the floor is 0.0025 to 0.003 based on network access fees and depending on carrier. With margin I suppose yes I won't get much cheaper. If I scale to that level I will look at direct integration, thanks. Do I still need blacklist if I have double opt in and users can opt out? Requiring confirmation would remove the need for that?

twunde 5y ago
Yes, you'll still encounter throttling even with 10DLC trust, it will just be less. If I remember correctly 10DLC is supposed to have a send rate of 15 text message segments per a second, although you can get that bumped up after vetting. But for example if you try to send 250K SMS at 10:05 am EST, those messages will be queued up and will be received by clients at varying times. This is something you'll want to monitor. If I remember correctly Twilio (and presumably other vendors) will show the actual sent time, so you'll be able to compare when you triggered a send with the actual send date. Unfortunately I don't think you'll see when clients actually receive the SMS unless you've got a personal phone number on your send list that you use to monitor. There are also daily send limits, which again can be increased after vetting. From a software engineering perspective SMS sending is really a series of queues. Twilio has its own queue per a number and a queue per a carrier. Each carrier maintains their own sending queues. As such, you'll want to monitor SMS sending the same way you'd monitor a queue ie by measuring throughput, and number of items in the queue. Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. The companies I worked at, did tests and found that emojis didn't really impact response rates, although its worth testing your specific use-case. With the double opt in, you probably don't need a blacklist, although you may want one for customers that reply with expletives, etc (assuming you're supporting 2-way).
- to11mtm 5y ago
  > Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive Technically it's more than just emojis, anything outside of GSM-7 [0] will result in fallback to UCS-2 and you get about half the number of characters per segment. FWIW Twilio does allow status callbacks so you can see that twilio sent the messaage and when(/if, sometimes they don't) carrier acknowledged delivery success/failure. [0] https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_.2F_GSM_03.38 https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_al...
- toast0 5y ago
  > Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. This might happen, but it really shouldn't. Sending emoji as utf-16 surrogate pairs in a message marked as UCS-2 generally works, even if it's technically invalid. Of course, using UCS-2 means 70 symbols? max, instead of the 160 you get from a 7-bit GSM encoding (or 140 with an 8-bit encoding, if there's a useful one). Emoji that are one unicode code point will take up two symbols if they need to be sent as surrogage pairs, and if you use any of the combining character based emoji, that's going to use your message length budget real quick. Pushing you into multiple messages or MMS, both of which are expensive.

twunde 5y ago

Yes, you'll still encounter throttling even with 10DLC trust, it will just be less. If I remember correctly 10DLC is supposed to have a send rate of 15 text message segments per a second, although you can get that bumped up after vetting. But for example if you try to send 250K SMS at 10:05 am EST, those messages will be queued up and will be received by clients at varying times. This is something you'll want to monitor. If I remember correctly Twilio (and presumably other vendors) will show the actual sent time, so you'll be able to compare when you triggered a send with the actual send date. Unfortunately I don't think you'll see when clients actually receive the SMS unless you've got a personal phone number on your send list that you use to monitor. There are also daily send limits, which again can be increased after vetting. From a software engineering perspective SMS sending is really a series of queues. Twilio has its own queue per a number and a queue per a carrier. Each carrier maintains their own sending queues. As such, you'll want to monitor SMS sending the same way you'd monitor a queue ie by measuring throughput, and number of items in the queue. Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. The companies I worked at, did tests and found that emojis didn't really impact response rates, although its worth testing your specific use-case. With the double opt in, you probably don't need a blacklist, although you may want one for customers that reply with expletives, etc (assuming you're supporting 2-way).

to11mtm 5y ago
> Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive Technically it's more than just emojis, anything outside of GSM-7 [0] will result in fallback to UCS-2 and you get about half the number of characters per segment. FWIW Twilio does allow status callbacks so you can see that twilio sent the messaage and when(/if, sometimes they don't) carrier acknowledged delivery success/failure. [0] https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_.2F_GSM_03.38 https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_al...
toast0 5y ago
> Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. This might happen, but it really shouldn't. Sending emoji as utf-16 surrogate pairs in a message marked as UCS-2 generally works, even if it's technically invalid. Of course, using UCS-2 means 70 symbols? max, instead of the 160 you get from a 7-bit GSM encoding (or 140 with an 8-bit encoding, if there's a useful one). Emoji that are one unicode code point will take up two symbols if they need to be sent as surrogage pairs, and if you use any of the combining character based emoji, that's going to use your message length budget real quick. Pushing you into multiple messages or MMS, both of which are expensive.