Since the release of the first iPhone back in 2007, Apple’s annual reveal of the newest model has generated massive hype and demand. And each year, the launch takes place increasingly online. Telecom and electronic retailers’ websites experience huge surges in visitors. Not even Apple itself is immune to website crashes during the pre-sales.
The iPhone launch is one of telecom and electronics retailers’ most business-critical days of the year. Competition is fierce, with consumers having many places to shop for the same product.
But mishandling this launch doesn’t just mean lost sales revenue now. With slim margins on the iPhones themselves, lost subscriptions impact the bottom line long after the pre-sales are over. A crash jeopardizes future launches too. Apple prioritizes retailers primarily based on the volume of iPhone sales they achieve. A failed launch day means losing out to competitors and being relegated to the back of the line for re-stocking.
Uncertainty abounds with the iPhone releases. Each launch has been a unique exercise in predicting the overall demand and the web traffic associated with the release.
This is especially true with Apple’s new multi-tiered launch schedule, making it hard to nail down how many consumers each version will draw. To make matters worse, Apple has made last-minute changes to the iPhone release. In 2016, for example, it moved the official release time to an overnight release within days of the event.
What’s certain is to achieve a successful iPhone launch, you need to be prepared for high uncertainty and unprecedented website traffic.
Over the past decade monitoring the online iPhone releases at Queue-it, we have helped top telecoms and electronics retailers run successful iPhone launches. Meanwhile, many other telecoms experienced website outages due to traffic overload.
Here are 3 key considerations to ensure you are ready to run a smooth iPhone launch.
1. Know your site thresholds
Many enterprises we’ve met over the years are unaware of what their threshold is. Without knowing the visitor levels at which your site starts to fail, you’re really going into the pre-sale blind.
The remedy for this is to run load tests. Load testing involves sending increasing levels of traffic to your site under controlled conditions. The aim is to help you understand how it will perform when real visitors start to hit it in big numbers. And good news is thanks to open source software, load testing is almost free to run.
But, defining your capacity based on concurrent users, like what you see in Google Analytics, will set you up for failure. That’s because it assumes that visitors are spread evenly throughout the customer journey on your website. However, your website will have certain primary bottlenecks that will always be the first to fail. Typically, these are the inventory and payment systems. If more visitors than normal collect at these points, you’ll experience downtime sooner than Google’s “Active Users” would suggest. A flow-based approach sidesteps these issues by throttling inflow to ensure even distribution of traffic on your site.
Knowing your site thresholds and bottlenecks, you’ll know when systems are running hot. What’s the contingency plan for this happening? Who are the key point-people responsible for managing traffic peaks? Having an internal communication plan clearly defined is mandatory to minimize any downtime you might experience.
2. Consider rethinking business strategy
Payment and inventory systems are two of the biggest bottlenecks in any online customer journey.
Part of the reason for this is that online transactions reflect how things are done in physical retail. For instance, an ecommerce site will typically process a credit card authorization in the same way as your local corner store. That is, the authorization needs to come through before the customer can leave with his or her goods.
However, this now tightly links payment to the website’s performance. The payment processor becomes a limiting resource on your website’s customer journey.
If you’ve bought something on Amazon, you may have received an email explaining that your payment didn’t go through and asking you to re-enter your credit card information. This happens because the payment is only processed after the order goes through and the shopper received his or her order confirmation.
For the iPhone release, ask yourself: Do we have to pick the item from the inventory when it is added to the basket? Or is it fine to do it asynchronously when the order is completed? Can we complete orders without authorizing credit cards? If you could, your website could process orders in amounts that at times are far higher than the payment or inventory systems’ capacity.
3. Have a way to handle early visitors
With any timed release, you’ll accumulate visitors on your infrastructure before the start of the sale. This happens in everything from Black Friday to concert ticket onsales. The iPhone release is no different. But if you’re not deliberate about your strategy, you could fail right out of the gate.
The build-up of shoppers can crash your site before the sale even starts.
If early visitors are landing on static pages, you could use a CDN to minimize the load on your servers. But this wouldn’t help for dynamic pages.
Server scaling is another option. But because the traffic increase is difficult to estimate, it’s very difficult to plan the scale up of your infrastructure. Plus, you can’t just scale any application. And stepping up hosting capacity doesn’t address 3rd party overload limits once shoppers enter the customer journey. The customer journey involves many such touchpoints, like payment gateways, stock control extensions, or shipping integrations. Server scaling can help but is unlikely to give you the peace of mind you’re after. You need a solution that can quickly adapt to sudden traffic surges and safeguard your website where bottlenecks are most likely to occur.
Get the online launch right
Consumer demand for the iPhone is headed your way on launch day.
The question is how you will manage it.
(Editor's Note: This post has been updated since it was originally written in 2017.)