How to avoid the SDK tax

In the mobile app space, it’s all too common for marketing technology platforms to solve a headache for marketers while creating one for engineering and, even worse, for user experience.

This is because the default method for implementing many of the mobile-first platforms and tools on the market is via installing an SDK, which taxes the product experience and creates significant engineering overhead.

App is crashing? Implement a crash reporting solution. Want to understand user flows and cohorts? Implement an analytics tool or two. Want to send push notifications? Implement a marketing automation solution. Need to re-engage users? Implement a retargeting solution. And so it goes, until the app is bloated, slow, and unstable.

Typically, it looks something like this (only a lot messier when you consider the average app has at least a half dozen marketing-related SDKs):

While pretty much every marketing and analytics SDK implementation presents some version of the “rob Peter to pay to Paul” dilemma, the good news is that, as I’ll explain in a moment, it doesn’t have to be this way. But first, it helps to understand the full extent of the SDK tax and why it’s bad for business.

The SDK tax comes in several forms, some more obvious than others…

• Labor cost: Because native apps are software products that consist primarily of independent elements, data collection of any sort requires a skilled engineer to define explicitly which user interactions should be captured for each specific element within the app. This happens on a per-SDK basis, and there can be hundreds of in-app events that need to be manually tagged and QA’d for any given one. This is quite different from the web, where a single or couple lines of javascript was usually more than sufficient to capture all the user activity on a given page
• Opportunity cost: Native apps are typically deployed in fixed release cycles, sometimes quite infrequently. Even a “simple change” requires custom coding, which means disrupting engineers and then waiting for app store approval for it to go live. (Again, this isn’t at all the case with web sites, which can be updated on the fly.)
• Risk and complexity.:In the mobile space, there’s also considerable fragmentation across carriers, device manufacturers and models, operating systems (including OS version), app software versions and other technographic features. This is especially the case when you consider that app ecosystems are not limited to iOS and Android but also now Roku, Playstation, and more. As a result of all this, it’s not uncommon for vendors to release feature upgrades and bug fixes which require an SDK update. Since one never quite knows when this is going to happen, it creates significant risk for the business.

All of these factors grow exponentially (not linearly) the more SDK are added to the mix. Which leads to the fourth type of tax…

• Degraded user experience: With multiple SDKs sending and receiving very similar sets of data, you end up creating overhead on the client side. The result is that users are more likely to experience app crashing and latency issues. If end-users look closely, they will also note that your app consumes an unusual amount of storage space and data, which no one likes.

Rather than doing what’s convenient (say, for marketing) at the expense of what’s right (for the customer, and your colleagues in engineering), the first principle of any new technology initiative should be “do no harm”. Do not bloat the app or tax the user experience, and do not create a nightmare for engineering.

The solution is to capture data once and then syndicate that data out with a centralized data layer. Conceptually, it looks like this:

In this scenario, you still maintain a best-in-breed stack, but it requires a single SDK residing on the client-side device (ideally one that’s low weight, open source and embodying all industry best practices).

The data layer essentially functions as an “API of APIs” connecting to all of your various partners through server-to-server integrations in a controlled fashion, and enables companies to get economies of scale from a single engineering initiative (integrate once, send anywhere). Over time, the data layer can also serve as a single source of truth for unifying data across the enterprise.

If you’re constantly building, tinkering or changing your mobile strategy, as most companies are, you should consider what kind of speed and simplicity is required to execute on your strategy.

There is nothing wrong with paying the SDK taxman per se, but you have to do so being aware of both the consequences and the existence of an alternative.