Why web solutions won’t solve your mobile app challenges

 

We are often asked how mParticle is different than various web solutions like data management platforms (DMPs) or tag management platforms, and I hope to address the differences in this post. The key differences between mParticle, a solution for native apps, and web-based solutions revolve around three points:

1. How data gets captured
2. Which services are required for native apps to run their business
3. How data gets distributed from native apps.

First, let’s review why these web solutions came to market. A few years ago, as the ecosystem of analytics and data-driven ad tech solutions rapidly fragmented, marketers became burdened by the continual need to add tracking pixels and tags to web pages, while publishers needed a way to capture the same data that ad networks and intermediaries were utilizing to build a competitive advantage among ad buyers. DMP’s and tag management emerged as viable solutions and, additionally, provided a valuable safeguard against third-party tags hampering site performance. In the early days, data management was different than tag management as the latter did not capture data, rather acting mainly as a solution to distribute data. There was a debate whether or not tag management was a feature of a DMP or a stand-alone product, but this is a separate discussion altogether.

So, how do these solutions work? Tag management solutions typically solve data distribution challenges by firing a number of partner pixels when instructed by a server-side, rules-based engine. The solutions allow for dynamic integrations, and they are powerful platforms that help marketers and publishers reduce the operational complexity associated with integrating multiple partner tags. The tags used in tag management systems are mainly for analytics and marketing services, the main tools that marketers and publishers use to run their web businesses.

Why don’t web solutions work for native mobile apps?

1. The way data is captured in a native app is completely different than on the web. In order to collect native app data, developers must instrument an SDK to capture specific interactions within specific parts of the app. This instrumentation process can be time-consuming in part because you don’t have the copy/paste simplicity of javascript tags on web pages. Combine the complexity of the integration with the general shortage of mobile engineering talent, and you get an expensive process that can disrupt development cycles, degrade the user experience, and increase legal exposure. These effects have led to a phenomenon referred to as the ‘SDK Crunch’ or ‘SDK Fatigue’.

Its important to note that many of the web-based DMPs and tag management solutions have in fact built SDKs to capture data in native app environments. This is an important first step but this doesn’t solve the problem that apps face, which brings me to my second point.

2. To run their businesses, native app owners require a set of tools that extend beyond media partnerships and analytics services. This is an important point because there are many tools that native apps use to run their business that isn’t relevant for web business, like crash reporting, push notifications, and mobile conversion tracking. While tag management consolidates certain web analytics solutions, it does not offer a comprehensive way to consolidate all the tools relevant to native apps. Because of this, adding an SDK from a DMP or tag management solution is just another SDK to embed, and it doesn’t properly address the SDK overhead challenge faced by app developers (in fact it makes it worse).

3. Data distribution is radically different in native apps than on the web. While you can easily create ad hoc integrations with web pixels using tag managers, distributing native app data requires a completely different toolset. To accomplish the same level of flexibility as web solutions, native app solutions must have server-side API integrations with the ecosystem of app tools and services. Short of this, a tag manager’s SDK is simply adding to the SDK overhead, not solving it, as I mentioned above. To help solve the SDK issue, mParticle is integrating into tag and data management platforms to allow our customers to get all their data in a single place.

Finally, the architecture of a data solution that works for native apps must incorporate a couple important features. First, the solution must work offline. One of the major differences between web and native apps is that you can use native apps offline, so the service must be able to capture in offline states and send data when it sees an open network connection. Second, the service should support data replay, which allows the app owner to send raw streams of historical data to any partner at any time.