When it comes to their websites, marketers have been very successful in leveraging their first-party data. They use this data to generate insights about site performance, retarget customers who failed to convert, and to synchronize with third-party audiences to better understand the common characteristics of their site visitors.
Marketers are now looking to do the same with their other customer-facing channels, such as their mobile apps. Mobile app data is highly valuable, but successfully accessing that data in the years since mobile has emerged has often been complicated.
Mobile apps are a significantly different technical environment than browsers. For instance, while websites are built in a variety of different programming languages, native mobile apps are built in defined languages dependent on the operating system the app will be living in. Websites are designed to be flexible and responsive, where small changes and updates can be made frequently, but large changes are more difficult. Mobile app updates go through an approval process where a large number of changes are implemented at once, usually quarterly.
These differences and others have complicated marketers’ efforts to capture data from mobile. Here are some early approaches to mobile data collection that missed the mark, followed by an assessment of the (much better) place we find ourselves now:
Tags Are Built For Browsers, Not Apps
The problem was that cookies cannot be placed on mobile apps, as they can on browsers. As a work-around, the display advertising technologies suggested to their clients that they open up a hidden browser behind the mobile app that would enable the dropping of cookies. That way, the advertising technologies could still retarget users who visited the mobile app. This work-around is called a WebView.
The User Experience Problem
The WebView solution proved unreliable almost instantly. Mobile app users began to experience loss of battery power, slower mobile app experiences, and more frequent mobile app crashes. These symptoms stemmed from the mobile device having to work twice as hard when being used, because it had to support the mobile app and allocate resources to the hidden WebView browser and its data requests. (For deeper look at WebView use considerations, see this article in Smashing Magazine.)
Advertisers needed an alternative solution to leveraging their mobile app data that could accomplish two things:
- Provide customers with the best mobile app experience possible
- Leverage the full extent of their first-party mobile app data
A Better Way: SDKs
It was clear that using the WebView was not a viable long-term solution. That led major digital companies like Google and Facebook to develop a superior solution: the mobile software development kit (SDK).
SDKs are now the standard for collecting data from mobile apps. They are specifically designed for mobile applications by enabling marketers to bypass the WebView and collect data directly from the source. Additionally, the SDK provides mobile app owners with a variety of tools to enhance their mobile app experience. For example: Some mobile app data collection SDKs enable owners to decide the frequency at which data is collected, so that an owner can optimize their application to provide their users with the best possible experience.
One SDK for All Your Technologies
SDKs gave advertisers what they were looking for: a safe and reliable purpose-built technology to access their first-party mobile app data. Soon advertisers were being asked to install multiple SDKs to their app: App analytics, mobile display advertising, and app download campaigns all became reasons to add a new SDK for every mobile technology the advertiser was using.
In an effort to minimize the amount of code added to mobile apps, advertisers began turning to companies like Signal. Signal enables advertisers to install one SDK that collects mobile app data and sends it to the Signal Data Hub, where it can then be sent to any technology or platform in real-time via Server-Side integrations or API calls.
WebView Work-Around for Mobile Tag Management
Using WebView adds a middleman between the mobile app data collection and its delivery to the tag management system. The reason a middleman is required for this approach is that in order for tags to execute, they need a browser to be present, requiring advertisers to essentially duplicate their entire native app into browser form, then support both.
Evaluating Mobile App Data Collection Methodology
Add these issues to the quickly-evolving marketing landscape, and it can be challenging for marketers to select the right long-term mobile app data collection solution. Fortunately, advertisers can now trust that a reliable and consistent mobile SDK solution will enable them to leverage their data without compromising the user experience.
Accessing mobile app data is just the beginning of an advertiser’s cross-channel marketing success. The next step is to connect mobile app data with customer engagement data from other channels to develop a single customer view, and leverage the unified customer view to generate better marketing performance.
When selecting a partner to both enable mobile app data collection and match that data across channels, marketers should look for the following criteria:
Mobile App Data Collection Requirements:
- Optimal user experience
- Purpose-built for mobile app data collection
- Captures all possible mobile app event data
- Employs long-term technological standards
Cross-channel Data Matching Requirements:
- Can collect data from other channels seamlessly
- Can match customer data in real time
- Can enable the use of cross-channel data in real time
Signal built the Fuse Open Data Platform to empower advertisers to take full advantage of their customer data (including mobile app data), without impeding the customer experience. We can help you plan, build, and prepare for the consumer data available now and in the future, so that your technologies and marketing work better together.
To learn more about how you can build your Unified Customer View, click here to request a demo.
Originally published February 20, 2015