This is the fourth installment of mParticle’s “Connected Marketing Stack” playbook.
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
The SDK tax comes in several varieties, some more obvious than others…
- 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:
Under this scenario, you still maintain a best-in-breed stack, but it requires only 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 fully aware of the consequences because there is an alternative.