PacketZoom makes content downloads to your mobile app faster and more reliable than TCP. In this blog post I want to show you data specific to mobile games that are currently PacketZoom customers.
I will discuss speedups, but another metric I will focus on is what we call Continuity. We think of Continuity as the ability to continue file transfers after a network disconnection occurs. A disconnection occurs when the player switches networks or goes through a network dead spot. In other words, we rescue what would have otherwise been a failed transfers. Continuity is an incredibly important metric that frankly most developers don't even know how to measure, and it can have dramatic impact on the player experience. Continuity is tough to measure but is one of the many metrics that is visible with our SDK.
Figure 1: App Sessions with Network Disconnections and Download Continuation
Figure 1 contains production data from a mobile game that uses the PacketZoom SDK. It shows the total number of sessions in blue, the sessions that experienced a disconnection in red and the sessions that PacketZoom Protocol saved in green. On a mobile connection, your IP address can change for a multitude of reasons including network changes, moving through dead spots, etc. With a traditional HTTP/TCP based stack, these situations can result in abandoned downloads and a broken player experience. PacketZoom deliver data to unique devices, not to ephemeral IP addresses. This is how PacketZoom wass able to rescue the 67% of the sessions that would have failed with HTTP/TCP in Figure 1.
Diving in deeper(Figure 2), we show the percentage of sessions that experienced a disconnection by network type. Think of these cases as players going through a tunnel while playing your game on the train or switching from wifi to LTE as they leave a coffee shop mid-transfer. The game in this example is available worldwide on Android devices.
Figure 2: Percentage of Transfers that Experienced Network Disconnection for Each Network Type
As you probably could have guessed, 2G networks experience more disconnections than other networks because players have more opportunities to move around (and get disconnected) with longer download times that are inherent to 2G(Figure 2). If you aren’t using PacketZoom then you can think of this chart as the percentage of your users that have a broken experience when trying to play your game, either because an initial asset bundle failed to load, an image in your store inventory didn’t load or they couldn’t get to the next level because the assets for that level failed to download.
Now let's talk about speed. The next chart shows the distribution of players across each network type and the average speedup that those players experienced. Note the multiples you see in Figure 3 are in comparison to the baseline throughput of this game using HTTP/TCP in the same time period using our built-in A/B testing framework. Figure 3 contains production data of an Android mobile game with worldwide users:
Figure 3: Speed Improvements of PacketZoom Downloads Compared to HTTP
The PacketZoom protocol’s performance increases are most evident on bad networks, so it should be no surprise that 2G players experienced the highest speedup factor, what's interesting is the effect that PacketZoom can have on even faster WIFI networks.
Figure 4 shows the average throughput of PacketZoom vs standard HTTP. As you can see, PacketZoom was consistently able to achieve higher throughput than HTTP over a 3 week period on WIFI networks worldwide.
Figure 4: Throughput comparison on WIFI between PacketZoom and HTTP
I’ve been working in the the mobile industry for a while and have always loved playing mobile games. One thing that everyone knows is that the player experience is critical to the success of a game (especially f2p games). The reality is that there are a lot of great games out there that have bad player experiences because there are some things that just can’t be done well with existing protocols, frameworks or libraries. Even if you’re meticulous and architect the game so that every failed download is automatically retried, the experience is still broken. That first step of detecting a TCP timeout takes enough time that it’s measured in seconds. That time is enough to gate the player from doing the one thing you want them to do - enjoy the game you worked so hard on. PacketZoom fixes this.
I'll leave you with a short video that shows what PacketZoom can do.