Choosing the right SDK for your mobile app

Having built a few consumer-focused apps I was no stranger to the array of mobile app services for analytics, attribution, marketing automation, etc. – there’s a seriously long list of competing SDKs out there. Fast-forward three years into my tenure at mParticle, I’ve worked in-depth with over 100 of them as partners in the ecosystem. In this post, I’ll cover the basics of how mParticle allows you to collect everything so you can take control of your data, and from an engineer’s perspective, why I think you should give us a try.

In this post, I’ll cover the basics of how mParticle allows you to collect everything so you can take control of your data, and from an engineer’s perspective, why I think you should give us a try.

Collecting a Superset

“SDK” is an incredibly general term—first, let’s talk about what mParticle does and doesn’t do. mParticle is not a shiny UI widget. It’s not a magical unicorn ORM on top of SQLite. The mParticle platform focuses on device metrics, attribution, event, and eCommerce data. We’ve created an internal language, or “schema”, that allows app makers to know and describe everything that their users do either implicitly (eg. install the app), or explicitly (eg. purchase something) in their mobile app or site. We’ve surfaced this schema in the form of our mobile SDKs and a server API – you can send it to the mParticle platform any way you’d like.

Plenty of SDKs collect similar data, but what makes mParticle unique is what we enable you to do with all of this data, and how initially collecting it into a single platform (as opposed to multiple platforms) changes the game. Stick the mParticle SDK in your app, or send data to us server-to-server, and then flip on any of our 100+ partner integrations via our web console. Even more powerful, dynamically describe a cohort of users based on that data in our Audience Platform, and send that audience to an audience integration. Put simply, we integrate with all of these services so you don’t have to.

Server-side is the best side

Despite focusing on mobile development, I’ll admit it: in a lot of cases, the more you can push server-side the better. This is a fantastically convenient excuse for me to put work on my good friends on the mParticle server team! But the truth is, the more logic and computation that lives server-side, the faster you can roll out new app features to users irrespective of app updates and ecosystems. The same is true with your app with respect to SDK integrations.

At mParticle, we have a dedicated integrations team to partner with and learn how all of these SDKs speak to their respective HTTP APIs. Once you’ve integrated with us – we’ll take care of sending the data where you want it to go. From a user action all the way to creating an audience across services – here’s a basic overview of an mParticle datapoint:

1. User X is looking to invest in a few dinosaur plush toys. He opens your dinosaur plush toy app, picks out a super-cute Sauropod and adds it to his virtual shopping cart. After some trepidation, he taps to purchase it and boom your app crashes. User X sobs and tosses his phone across the room.
2. Luckily, the mParticle SDK has tracked that the app was opened, that a user attempted to purchase a Sauropod, and that the app crashed. In the background, the SDK ferries this data from one SQLite table to the next, preparing it to be uploaded to the mParticle server.
3. To save on battery and network communication, the mParticle SDK waits until User X’s phone is in radio coverage, and after a configurable interval, the SDKs shoots a compressed payload to mParticle containing the failed purchase session.
4. mParticle deserializes this data and multicasts it server-side to every service you have configured.
5. Using your crash-monitor of choice, you notice that there are a great many crashes on your app’s checkout screen. You also notice in your favorite analytics provider that there’s a lot of near-purchases. This is a potential opportunity.
6. Using mParticle, you create an Audience of users who crashed and who attempted to make a purchase. mParticle sends that Audience to your email or push provider of choice.
7. User X gets your email apologizing for the crash, perhaps with a coupon code, and they try again to buy their Sauropod. Since the first attempt, you’ve analyzed the stack trace and fixed your silly NullPointerException, and order in the universe is restored.

There are a few important points here. For one, you only needed a single SDK to do all of this. Another, the SDK communicated with a server only once during this entire interaction. Last, you managed to leverage mParticle as a connector between multiple services. Without mParticle, you would have had a range of SDKs with differing APIs, spinning up the cell-radio out of sync with each other, potentially never letting it sleep¹. Worst of all, building the integrations across these services would have torn you away from focusing on your core engineering efforts.

Looking forward

This was meant to give some idea of how mParticle works – there are many applications for and implications to this architecture, the case above is just a simple example. In future posts I’ll get more technical, perhaps covering how we’re leveraging the Gradle build tool to test all of this, tips for creating a low-memory offline SDK, and much more!

¹Here’s a great write-up explaining how network access should be coordinated to optimize battery life: https://goo.gl/x4H26b