How to beat the mobile SDK tax

In mobile it’s all too common that solving a problem for marketing creates a problem for engineers, and, worse, end users. David Spitz, CMO of mParticle explains why this is and how, with a proper data infrastructure, you can avoid the SDK tax trap

When it comes to a CMO’s priority list, a lot of times marketing data infrastructure falls into Zone 2 of the Eisenhower matrix, which is to say “important but not urgent”. DMPs, tag managers, CDPs all face this challenge to some degree. While they promise better targeting and insights it's sometimes hard to justify their value relative to more simple and straightforward optimization opportunities.

However, in the mobile world it’s an entirely different story; there are few things more urgent than customer data infrastructure.

That’s because the (unfortunate) default for implementing mobile tools in the absence of a proper data layer is via an SDK that taxes experience and creates significant engineering overhead.

You know the routine. Is your app is crashing? Implement a crash reporting solution. Want to understand user flows and cohorts? Get an analytics tool (or two, or three). Need to send push notifications, or re-engage users? You get the idea...and so it goes, until your mobile app is bloated, unstable and slow.

While your new SDKs may have cured a headache for marketing, they’ve just created an even bigger one for engineering and end users.

To visualize what this ends up looking like, have a look at this graphic.

Almost all marketing and analytics implementations present some version of this ‘robbing Peter to pay Paul’ dilemma. But it doesn’t have to be this way, if you understand the implications of the SDK tax, and how to avoid it.

How the SDK Tax works

The SDK Tax comes in several varieties, some more obvious than others:

• Labor Cost: Native apps are software products; they consist of independent elements. So, data collection requires a skilled engineer to define what user interactions should be captured for each app element. Because this happens on a per-SDK basis, there can be hundreds of in-app events that need to be manually tagged and run through a QA process. This is different from desktop, where a few lines of JavaScript are sufficient to capture all the activity on a given page.
• Opportunity Cost: Native apps are typically deployed in fixed-release cycles, sometimes quite infrequently. Even simple changes require custom coding, meaning disruption for engineers and sometimes long waits for app store approval. Again, this isn’t the case with websites, which can be updated on the fly.
• Risk and Complexity: In the mobile space, there is significant fragmentation across carriers, device manufacturers, operating systems, app software versions and other techno-graphic features. This is especially true in app ecosystems, which are not limited to iOS and Android (i.e. Roku, Playstation, etc.) As a result, it’s not uncommon for app publishers to release upgrades and bug fixes that require an SDK update -- you never know when this will happen, creating significant risk for business.

Each of these factors grow exponentially as more SDKs are added to the mix, leading to the most damaging form of taxation:

• Degraded User Experience: With multiple SDKs transmitting similar sets of data you end up with client-side overhead. Users experience app crashing and latency issues more frequently, and your app consumes more storage space and data on their device, which ain’t good.

SDK Tax relief

Rather than doing what’s convenient for marketing at the expense of what’s right for users and the folks in engineering, the first principle of any marketing technology initiative should be to do no harm. Don’t bloat the app, don’t tax user experience, and don’t create pain for engineering. Capture your data once and syndicate it through a centralized data layer, which, conceptually, looks like this.

This way, you’ll maintain a best-in-breed mobile martech stack that works off a single SDK residing client-side.
 

In this scenario, your data layer functions as an “API of APIs” and connects all partners in a controlled fashion.

It's critically important, of course, that this SDK be low-weight, open source, easy to implement and maintain, and battle-tested by other apps of similar size and data complexity. Assuming these conditions are met, though, you can then achieve your marketing goals without undermining product and engineering.

For most of us, taxes are our number one expense, so it pays to optimize them before tweaking around the edges. The same goes for mobile marketing. A great programmatic ad campaign is no excuse for a poor mobile experience and frustrated engineers. The good news is that with the right help, you can have your cake and eat it too. Tax free.