Maximizing web-to-app attribution insights

Welcome to the second blog in our series on cross-device attribution, where we dive deeper into the mobile web as a meaningful acquisition channel for mobile apps.

In this post, we describe the mechanics of web-to-app attribution and the core functions an attribution system needs to provide for app marketers to get the most out of their web campaigns.

What is web-to-app attribution

In the first post of this series, we described the starting point of a web-to-app attribution flow, where users visit a web page on their mobile phones. From that point on, marketers can create different product experiences to convert, acquire, and reactivate users on their app.

Web-to-app attribution is when an in-app event, such as an app open, sign up, or in-app purchase, is attributed to the web activity from which the app install originated.

This activity can be a paid campaign on the web, organic search, or even a direct visit. In some cases, it can be a combination of these and may include mobile campaigns that the user had interacted with on other apps. Ultimately, the marketer would need to know what has their ad spend yielded in the app.

Getting started: Tools needed for web-to-app attribution

So how do you get started with building your own attribution system that supports accurate web-to-app? Let’s take a look at the core elements that are needed:

• Website tag – Every attribution system that wants to analyze web activity needs a website tag. That tag would often be based on Javascript and need to perform a tracking tag’s core functionalities, a) tracking events, and b) understanding who may be behind these events or, more specifically, which of these users are the same and which are new. It should also collect the necessary metadata for these events to determine where the user came from, and in some cases, the relevant IDs that partners are using for optimization.
• Web attribution – Besides the client-side code, an attribution system needs to be able to distinguish between paid, organic search, referrals, and other types of common web activities. This attribution stack would commonly feed data into a flexible analytics platform that can count unique events, deduplicate users, and join conversion data with web campaign ad spend to calculate ROAS and other bottom-funnel metrics.
• Mobile attribution – Since conversions, or at least some of them, are happening after the app is installed or re-opened, another must-have component is mobile attribution. Consider the scenario where a user came to your website through organic search and installed the app shortly after. What if that very same user saw a Facebook ad a week ago for your product? Regardless of the exact attribution model you’d like to use, it’s evident that the attribution system should consider every marketing touchpoint that user has had, on every platform and every device they may own.
• URL generator – Everything on the web works with UTM and URL parameters, which leaves too much flexibility for marketers when setting up campaigns. Even though the basics of using UTM parameters are common knowledge, maximizing these parameters to report on granular data is critical for being able to get analytics that allows marketers to optimize channels, campaigns, keywords, and creatives, consistently across web and mobile. Surprisingly, not many tools out there are providing this, and many marketing teams today still use spreadsheets or worse … manual links!

The above four elements are the main functions needed for supporting web-to-app attribution. Surprisingly, various vendors, including a few MMPs, offer limited subsets, but no one provides all of them in a single platform, except for Singular (you must have expected this, right?). But we’ll get back to this later.

Mechanics of web-to-app attribution — and why it’s relevant to iOS 14

So how does web-to-app attribution work? Let’s look at the user journey to understand what is happening at every step:

1. User gets on your web page using their mobile device
   Whether it’s through paid, another website that had a link to your website or a direct visit (that just means the user learned about your website elsewhere), as soon as they land on your website, your tag would kick in. The website tag will first try to establish if this is a new or repeating user. It will commonly do so by using localStorage or cookies. It will then start sending events – page visits, sessions, other types of conversions to the attribution system, and metadata such as UTM parameters. The attribution system will record these and attribute every event to the appropriate activity according to a given attribution model, for example, last touch.
2. User clicks on a link that opens the app or takes them to the app store
   The user experience worked well, and users want to open the app after visiting your website. The link to open the app should usually contain a deep link to take existing app users to a specific page — perhaps it’s the in-app page for the same product they viewed on the web. Users who do not have the app will be taken to the app store to install the app or reinstall if they’ve had it before. The attribution system should then determine for every in-app event the original activity on the web that led to it. It should also dedupe this device against any other mobile touchpoint that could have otherwise claimed it (and this is where most MMPs fail). Depending on the specific scenario, this can happens through deep link parameters or probabilistic matching to the click. Establishing this relationship allows the attribution system to tie between an event happening in the app to the marketing campaign on the web that has led to it.
3. User converts and engages with the app
   When the relationship between an in-app user and the associated marketing campaign is established, we know what marketing activity produced the conversions. This is where having strong governance and consistency in the parameters used for web tracking helps, as utm_campaign, utm_source, utm_term, and others can be used to generate granular reporting that can be joined with ad spend and other data sets. The attribution system needs to attach the web attribution data against every in-app event, and the analytics system that leverages this data needs to present the web and mobile together to report on every marketing activity.

How does this relate to iOS 14?

With iOS 14, Apple is making it very clear that any probabilistic matching is forbidden when done across apps where users did not agree to be tracked. Therefore, the IDFA is not available. However, in web-to-app, the web page and the mobile app belong to the same advertiser, and tying in-app events to UTM parameters is allowed. This makes web-to-app highly attractive for marketers whose products are suitable for mobile web and web-based landing pages.

What’s next in the series?

Now that we understand how web-to-app attribution works, we can continue exploring additional use cases where users may browse on desktop first or install on multiple platforms, for example, when playing a desktop game with an iOS version. In these scenarios, the marketer may want to know how each app, which corresponds to a device, was acquired individually and where the user first came from or what ad they last engaged with. All of these are use cases that a cross-device attribution system should solve for, which will be our topic for the next post in this series.

In the meantime, if you’d like to learn more about Singular’s web-to-app and cross-device capabilities, please reach out to schedule a demo.