App size matters II
By
Gonçalo Alvarez
At Farfetch for 5 years. Has built his career in mobile development with sheer curiosity for the most complex tech matters. Carhartt enthusiast.
View All Posts
How much for a byte?
This is the second of a series of blog articles dedicated to Mobile Apps Performance at Farfetch. This time around, the focus will turn towards monetising mobile app sizes at Farfetch, building a business proposition. If you have not read the first article in the series about, please find it here.
Have you ever wondered how much an extra megabyte in our app size costs our business?
Mobile app sizes at Farfetch, as all software performance traits, are an engineering team’s realm and responsibility to take care of. This entails developing against the highest standards of quality by choosing the best in class patterns as well as cherry-picking top-shelf tools for monitoring both our app and all the services feeding its data. All the while coordinating a growing operation of 60+ multisite mobile developers developing an omnichannel product in tandem with a sea of platform, infrastructure and product, teams shaping business-driven domains toward building, maintaining and evolving the Global Platform for Luxury Fashion.
The shape, form and performance of your app, is an organisation’s business card. One that engages customers around the clock through the screen of their devices, powered by hundreds of services, platforms and data flows you need to gel in harmonious and performant balance with one sole purpose: solving customer needs quickly.
Now, to do good by the performance of your app, you’ll have to make room for discussing it, holding the spotlight on the matter and swaying your organisation’s attention to the commonly opaque matters of performance. Business-driven initiatives are easier to arbitrate, prioritize and measure impact, as they provide a clear figure for monetary impact to the business. As an engineer, you will have to adapt your performance initiatives in lingo that is recognised across the board. This will help to clearly convey the impact, importance and business case, in a language that everyone understands, speaks and shares, no matter the area (i.e. business, product, finance, tech, operations, etc). You’ll be Larry Lingo speaking Business - embrace the numbers language.
At Farfetch, we do so - by fine-tuning metrics for success, gathering data on our customers and calculating the impact of changes in our app sizes, brought to life every fortnight.
According to Segment - a customer data platform - there is an impact of 0.45% in iOS app installs per megabyte for apps under 100mb and 0.32% per megabyte on apps above 100mb. The rate differs once we step into values closer to 200mb - Apple’s own cellular download limit. Although Apple claims the cell data limit is 200mb, in practice a 201 mb does not trigger the cellular download block, the limit is somewhere between 201 and 220mb. While these numbers portray a fairly linear approach - app performance is an ecosystem, every variable impacts every other variable - they provide solid ground for trade-off conversations about app size and app adoption.
Understanding our customer base and download habits is key to surfacing the impact of each megabyte in each release’s install rate. An in-depth analysis of behavioural metrics, conducted through the tracking funnels by the team of Product Analytics at Farfetch, shows that an average of 100.000 downloads per version, leads to a cost of 450 app installations per megabyte added to our app. Apple defines App installations as the total number of times your app has been installed. While this includes redownloads and restores, this value conveys a figure of all downloads that happened on the App Store showing clear intent. Should the increase be as high as 15mb in a given version, then we’re facing a 6750 download units cost.
Now take 6750 download units and have it multiplied by an estimated fortnightly Gross Transaction Value of $50* for each new customer funnelled through the app download. To reach this figure, we calculated the 15-day value of new customers based on their Lifetime Transaction Value - LTV - crossed with the new app downloads within this period - we’re looking at nearly $350.000 opportunity cost. Does the new onboarding video business case cover this cost? Maybe it does - the good news is now you are equipped with the right tools to pose that question.
Should we zoom out and look at an estimated yearly GTV of $150* for each new customer funnelled through an app download - this time we calculated the 12-month value of new customers based on their LTV and once again crossed them with the new app downloads - then we’re looking at a yearly cost of nearly $1M tied to a single release. Stack such figures through the amount of releases in a year and you’re building a case. This makes for great arguments to factor into conversations around throwing a new SDK, heavy imagery and more resources into the app binary.
This rationale goes both ways and should not pose a red herring - it is as helpful to use this line of thought to eschew from importing new load to our app binary, as it is to delving what extra load we should consider throwing overboard.
Defining performance budgets
The train of thought that got us to measuring the business impact of app size fluctuations also led us to define both a target app size per version and a set of performance budgets - this time focusing on App Size Budget.
Negotiation is key. You trade, compromise and agree on a strategy based on pros and cons, costs and benefits, bang for the buck. The app size budget, quantified in megabytes, allowed us to unfold a trade-off strategy with product counterparts and peer engineering representatives - adding a new SDK arbitration now has a richer base for discussion as it is made clear for everyone involved, from business to product across engineering, what piece of the budget we have left to consume and what the impact of such consumption is. Also, as a byproduct, it triggers second-order thinking revolving around replacing or removing current SDK or external app modules, be them in-house or third party. These budgets are evaluated every quarter in order to make room for adjustments as we are sensitive to an ever-evolving tech stack and set of technologies whose evolution also reflect in terms of size. The budget definition also poses a chance to equate a budget cut as a means to factor in a change in direction to influence a reduction in the app size. This drives strategies for app thinning as well as product decisions as to reduce the load of third party SDK in the app.
Our teams have also come to leverage performance budgets as an artefact to factor go/no go decisions for each new version of the app, deriving a target app size used as a threshold for comparison against the current app size. Should this threshold be exceeded, then the release of our app gets blocked until further assessment. This heeded in promoting the role of performance of mobile apps as first-class citizens in our product development processes.
Learning about our very own app size and how the market, however inelastic a given target audience may be, reacts to fluctuations, has led us to improved business decisions. Putting pen to paper and vesting our time in building tech business bases adds invaluable data to weighing the costs and benefits of product business cases.
There is a business impact in every decision we make on a daily basis - it is only fair we make informed choices.
* GTV and LTV figures presented throughout this article are fictional, used to labour the point of App Size costs to Businesses.
