days
-1
-2
hours
-2
0
minutes
0
-8
seconds
-1
-9
search
Worst case scenario: a slow connection

Why your UX needs to be realtime or it’s already out of date 

Matthew O'Riordan
realtime
© Shutterstock / solarseven

No one likes slow connections. Realtime messaging is crucial to keep customers happy and engaged. In this article, Matthew O’Riordan explains how companies companies implement realtime delivery without running into common problems.

Demanding and impatient – that’s a typical web user, myself included. We want more and more instantaneous experiences with immediate feedback, from all our connected devices.

Realtime messaging is changing the world. You cannot afford to deliver poor customer experience or your customers will go elsewhere. Customer experience is the new competitive battleground and realtime delivery is a key part of that. So, what are the key problems in implementing realtime delivery and how do you avoid them?

Latency is too high

Nearly 70% of consumers following live sports on a mobile app would look for an alternative if the app was slow or not working. (OnePulse, 2018)

High latency levels no longer meet the expectations of customers. Customers are used to realtime messaging like WhatsApp or realtime vehicle tracking like Uber – no refreshing is required.

You need latencies in the range of 5 milliseconds to 200ms, with a target of under 100ms, to give your customers a ‘live’ or ‘instantaneous’ experience. Polling by the app improves speed, but latencies and the load on your servers remain high. There is also complexity in handling failures.

The practical way to solve this is to establish a realtime connection with your service, so that updates are pushed to devices. As devices do not have public IP addresses, it is impractical for servers to communicate directly with individual devices. Devices instead communicate with the servers and keep that bi-directional connection open.

To achieve low latency updates, you need to consider the many stacks in your layer. Having scalable servers close to your customers is also important, especially when you have lots of subscribers listening for the same data at the same time. That requires scale in your cluster to distribute the work of fanning out these updates.

Other things that can affect performance include the total bandwidth required to deliver each update, as well as the encoding and decoding times in the publisher and client. Using efficient encodings like binary MsgPack can help to reduce bandwidth along with encoding and decoding delays. Depending on the types of updates, it may be more efficient to send the changes (deltas) as opposed to the entire state each time.

SEE MORE: Meet dejavu, the Elasticsearch web UI that supports importing data via JSON and CSV files

Lack of synchronization across screens

Viewers expect to experience realtime synchronization across their screens through instant updates, in line with the action on the pitch. However, many users currently complain that their biggest issue with second screens is a lack of live synchronization with the primary device or when they are watching an event live.

63% of users would change to a more reliable betting app if the stats were incorrect when placing an in-play bet. (OnePulse, 2018)

Quite rightly, a lack of synchronization that can cause considerable frustration and commercial damage. Take in-play and cash-out betting, live commentary, or fantasy sports games, as an example. These services all rely on data being created by actions in the game, which need to be instantly reflected in the second screen experience.

The solution? You need to use a platform which can simultaneously and reliably update all devices and screens in realtime so there is no dislocation in the customer’s experience across screens.

Loss of connectivity across changing network conditions

Over 80% of users follow live sports while on the move. (OnePulse, 2018)

Increased demand for data on the move has led to a sharp rise in the use of mobile phones as a primary connection point for many businesses. Issues arise due to constantly changing network conditions, as users move between 3G, 4G and Wi-Fi, or lose connectivity completely. These changes cause disruptions to data delivery, as connections open and close. Customers, who have lost connectivity may well refresh their app, which rebuilds their feed from scratch.

While you cannot guarantee that your customers will have a continuous connection, you still need to provide a continuous service. The trick is to make it possible for disconnected devices that reconnect within a short window to resume the data stream from where they left off. This significantly reduces work for your engineering team, as they do not have to handle failed connection states.

SEE MORE: An introduction to building realtime apps with RethinkDB

100% uptime required

You may think 99.99% uptime is a decent level to aim for; but what if that means your customer is without your service for almost an hour a year? Given many events are extremely time-sensitive, that missing hour of an event (at any time) could be a disastrous experience.

Long-term effects can be even more damaging. Customers generally show low brand loyalty; they will likely gravitate to more reliable services. Nowadays, only 100% uptime is good enough.

Only 12% of users claim a slow or nonworking sports app is not important to them. Don’t ignore the other 88% who value speed and reliability. (OnePulse, 2018)

Unreliable message ordering

It’s critical that any data is delivered in the correct order. If updates are not delivered and displayed in the order they happen, your customers will be confused, and might switch off.

Over 90% of users get annoyed by poor reliability when using an app to follow live sports. (OnePulse, 2018)

Data ordering becomes a greater concern when the events or data you are streaming to your clients are partial updates (data deltas or patches), as opposed to full updates. To reduce bandwidth and latency, it can make sense for service providers to send only the updates of a dataset to a device, as opposed to the whole dataset.

In most cases, that works fine on any realtime transport. However, when updates arrive in the incorrect order, the data deltas / patches can result in corrupted data. Then there is no guarantee that all devices will have the same view of the same data, despite the fact they all received the same updates at the same time.

SEE MORE: End-to-end latency challenges for microservices

Handling sudden spikes in demand

You need to be able to deal with unprecedented and sometimes unexpected spikes in demand. Focusing on growth opportunities without the burden of knowing if your technical systems are ready.

Imagine if the Australian Open final goes to a tie break and millions of fans are using their second screen to follow updates, place in-play bets, and check their fantasy team results.

3.6bn people watched the 2016 Rio de Janiero Summer Olympics. (Statista, 2016)

Conclusion

When choosing a realtime data platform, you need to know that – regardless of the number of active users – the amount of work required from your servers remains constant. All the work required to keep millions of connections alive and distribute the published data to them should be deferred to the realtime platform. Simplifying your technical architecture and reduces associated engineering costs.

Find out more about the importance of realtime user experiences in our whitepaper by visiting 6 Ways to Lose Sports & Gaming Customers Through Poor Realtime UX.

Author

Matthew O'Riordan

Matthew O’Riordan is the CEO & Co-founder of Ably Real-time.

Ably’s global realtime platform enables Internet enabled devices, such as a browser, phone, server or IoT sensor to stream data in realtime to any other Internet connected device in milliseconds. Our platform brings enterprise scale messaging to developers by delivering 100% service availability, message delivery guarantees and low latencies globally.
At its core, Ably Realtime is a cloud-based pub/sub Platform as a Service (PaaS) ensuring any device publishing messages to Ably Realtime will be received in realtime by any number of subscribing devices. But it is more than that. Our platform makes it possible for developers to build apps and infrastructure that can communicate in realtime without the worries of: managing scale, latency, data durability, integrity and storage, seamless connection recovery, device interoperability, network outages, encryption, security and authentication, throttling, and denial of service attacks.
Ably Realtime’s client libraries have been developed to offer a consistent yet idiomatic API across every language. Regardless of your development environment our platform keeps things simple for you by being consistent. The platform also supports several other protocols to provide interoperability with a huge array of third party client libraries across every imaginable platform.
Ably Realtime’s customers include: Yahoo, CA Technologies, Netsuite Oracle and Tennis Australia. For more information about Ably Realtime.


Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of