29th - Jan - 2016
SMS and its Need for Speed!
At Mblox we are obsessed about mobile messaging, and the one question that comes up often is, “Just how important is the delivery time of an SMS message?”
First, let’s be clear, we are not talking about how long it takes for a message to leave your phone and arrive on your friends (although we know this is extremely important), we are talking about enterprise to consumer messaging, e.g. when your bank sends you a fraud notification.
We’ve been thinking about this question a lot and we hope this blog will help in explaining just how critical message delivery time matters. It surprised us just how vital it really is.
The industry divides enterprise to consumer messaging into two types, transactional and promotional. There is an implied speed for each type, for transactional messages delivery is required to be quick and promotional messaging not as much.
Examples of each type:
Transactional - financial balance alerts, hotel booking confirmation, package delivery confirmation, one-time password, these are a one-time message usually opted in to and sent on an as-needed basis. In some cases the messages are sent whilst the user is in session e.g., on the web making a booking. Transactional messages are definitely expected to be delivered within minutes.
Promotional - vouchers, redemption codes, special offers, these messages are usually opted in to on a per brand basis, and will be sent until you opt-out. These types of messages are not as time critical and are expected to be delivered within 1 hour of when it was sent.
By far the most important transactional messages are those that are sending you a PIN code or password required to transition to the next step in a process e.g., logging in to access an online account or resetting a password. For the sake of clarity we will group this subset of transactional messages into one and call them “two factor authentication” (2FA) messages.
It should be noted the speed to deliver a message, or the delivery time is often called the latency of a message. The true meaning of latency requires a magnifying glass in most contracts because the definition can vary significantly from one provider to another and in most cases does not actually mean the time from when a user requests the message to when they receive it on their phone.
Our starting point in answering the question, “Just how important is the delivery time of an SMS message?” was looking at other digital communications and seeing if there were any similarities, we started with looking at web page loading times and associated drop off of conversion.
A company we use for our own web analytics has an excellent infographic of the importance of web page load time on conversion. See Kissmetrics article here. They found 35% of surveyed users would abandon the page within 10 seconds of waiting. Intuitively this sounded roughly about what most users would do if they did not receive a 2FA message within the same time period, but we needed proof.
Many companies who implement 2FA have this data at the tip of their fingers, but because Mblox only carries these messages, and is unable to know exactly when a user actually enters the code, we needed some other mechanism to determine the tipping point, the point when the user becomes impatient and requests the message to be resent. After racking our brains we realised the most likely thing someone would do if the 2FA message was delayed was to simply request another one! We embarked on a journey of discovery to determine what the ‘repeat request’ rate was as a function of delivery time. As 90% of Mblox messages are delivered in less than 5 seconds, we needed to seek out periods where we had rare but known blips of congestion either due to a carrier network being down or other issue.
When using 2FA the need for immediate delivery of the text message to the handset is not only required, but expected by the consumer. But how “immediate” does the message have to be? How long are people willing to wait to receive the text before making an additional request to resend the message?
To determine this threshold, we specifically looked at one-time-request versus multiple-requests-per-unique-mobile-number. Prior to analysis the data was cleansed, for example for non-delivery issues we did an HLR on all handsets in the data set and excluded those that showed any kind of potential delivery issue i.e., we deleted repeat requests from non-existent numbers, as this would indicate someone had entered their mobile number incorrectly.
The first finding from the analysis showed multiple requests to be quite infrequent, in fact 98% were single entries, meaning the security code was sent to the handset once, the remaining 2% made more than one request. This low percentage for total retries can be explained by the fact that congestion on the Mblox network is rare and transient. It is our assumption every 2FA message will get a repeat request if the message is not delivered within a reasonable and expected period of time.
Looking at this data set closer we can see just how important delivery latency is. First off, 10% of users asked for a repeat message if they did not receive the message within 3 seconds, a further 19% asked for a repeat message if they didn’t receive the message within 7 seconds, and 6% asked for a repeat message within 11 seconds. In total, this is a staggering 35% of users will ask for a repeat message if the first one is not delivered within 11 seconds. This is very similar to the Kissmetrics finding showing 35% of users would abandon a web page within 10 seconds of waiting.
We also noted the average number of repeat requests was 1.2 across the data set which means for these users, the enterprise will be paying at least double if not more than double per user than required and this can be directly attributed to latency.
Our theory for why so many users only attempt a second request after 41 seconds is because they are easily distracted, and when they remember what they were doing, they notice they have not received the message and re-request it.
The conclusion is a 2FA message simply must be delivered end to end (i.e. enterprise to handset) within 10 seconds maximum, and ideally it should be in less than 3 seconds.
There are a number of things that can impact the speed of delivery:
The rate at which your SMS provider can accept messages needs to be sufficient to ensure even at peak periods they are able to accept the message within 100 ms.
The capacity your SMS provider has for both delivering the message and doing a mobile number portability lookup (MNP), both are of equal importance, and the ability to maintain throughput during peak demand is critical.
The ability for your messaging provider to split traffic between low latency and high latency traffic, i.e., split and prioritise messages by whether they are transactional or promotional.
The routing algorithm your messaging provider uses. Some least cost providers will queue messages to send them down the lowest cost route regardless of congestion or latency.
Multi-hop connections make it very difficult to control latency and therefore using direct connections will always lead to higher performance and visibility. Grey routes, SIM farms or other routes that are likely to be blocked can also lead to latency issues as various filters may impact delivery from time to time
Operator SMSC configuration, ideally operators should split A2P and P2P messaging so retry algorithms within the SMSC can be more aggressive.
Backup connectivity in the event of a primary route failure or direct connection failure is critical. Using SS7 connectivity (albeit at a much higher price) can be beneficial.
Recommendations for optimizing for speed of delivery:
Ensure your messaging provider is able to offer a SLA and provide regular reports against those SLA’s.
Choose a messaging provider who has direct connections and SS7 backups to the destinations you are sending to, as this will provide the highest reliability and speed.
Ensure your messaging provider is continuously analysing and monitoring message delivery latency end to end, i.e., to the handset, to ensure problems within carrier networks can be proactively detected.
Ensure your messaging provider can split traffic by message priority at the message provider level and can send high priority messages out before lower priority messages to the carrier networks if capacity / congestion is detected.
Ensure your application only allows a repeat request after 10 seconds as this will deter some users from being overly trigger happy.
Mblox has over 100 direct connections worldwide and we proactively monitor our system performance and message delivery times. Part of the monitoring process has our system continually running tests, some of these tests are outbound to the carrier networks and partners to measure message delivery times and to alert us to changes in latency. Early detection allows us to notify and expedite working with carriers and partners to correct the performance. Following is a sample of how Mblox performs this monitoring and reporting.
The graphic above shows how Mblox tests and monitors our two products to France every 10 minutes (during peak hours) using a variety of different features and measuring end to end latency. The analysis of the data can reveal trends. Below is a graphic summarizing the results of these tests over the last 18 days. As you can see the vast majority of traffic is delivered within 3 seconds to the handset (86%). 95% of messages are delivered within the 10 seconds. The remainder of the 5% could be related to congestion at the carrier networks or issues with test node connectivity. We strive every day to bring the latency down further and further.
If you have mission critical messages and time sensitive use cases ensure you take message delivery latency seriously and choose your provider wisely, as the need for speed is real. It seems end user’s patience (or in this case impatience) is universal across multiple channels. Message delivery immediacy is a major strength of SMS messaging, and not taking advantage of it could cost you more than double.
Author: Rob Malcolm
Contributors: Doug Boykin, Mitzi Mori
Article also appears in Telefonica’s 1Q2016 Newsletter
Originally posted on mblox.com