Author: Alon Nafta

As we get closer to iOS 16 being released, predictions and rumors are increasing around Apple finally forcing the mobile advertising industry to exclusively use SKAdNetwork as originally intended. While some are still theorizing about yet-to-be-endorsed alternatives that can still attribute device-level data, at Singular we have been investing a lot of time and effort into understanding what the next phase of privacy-safe mobile analytics and campaign optimization should look like for iOS.

Our vision for Singular’s SKAdNetwork product is to deliver a reporting experience that’s as close as possible to pre iOS 14 user acquisition, including ad spend and ROAS, cohort metrics, and as many relevant breakdowns as possible … all of which are needed by marketers to optimize their iOS performance. 

At the same time, it is our mission to support campaign optimization, and work with our partners to ensure campaigns can run at scale and deliver results. Ironically, one of the main challenges in SKAN is that these two often come at the expense of each other.

In this blog post we’ll describe how mobile analytics on iOS 14 has evolved in the last 2 years, clarify where it is today, and share why we are excited (or rather, not as worried) about where it’s going over the next few years.

The reporting versus campaign optimization tradeoff

One of the most meaningful things to understand about SKAdNetwork is that in contrast to iOS reporting pre-iOS 14, campaign optimization and reporting are tightly coupled. This is because the signals, i.e. conversion values, that an app reports to SKAdNetwork are used for both optimization as well as reporting. 

In other words, if I’m choosing not to optimize against a specific event, I will not have it in my UA report. This is a huge change compared to the past where everything was always available regardless of what events were sent via postbacks for the purpose of campaign optimization.

A few examples for this:

• Revenue vs. events: if the app is only reporting revenue amounts to SKAdNetwork, ad networks will only optimize based on these revenue amounts and other events won’t be available to directly deduce from SKAdNetwork conversion value data. Recently, Singular added an option to include both by using mixed conversion models where the main trade-off is using less events.
• Measurement periods: the standard today is for apps to update conversion values to SKAdNetwork for the first 24 hours. This allows ad networks to receive SKAdNetwork postbacks roughly 2 days after every install. On the one hand, using a longer measurement period can increase accuracy by introducing additional conversion values. However, this will increase the delay before which ad networks receive postbacks for campaign optimization, which can damage performance.

Reporting in the early days of SKAdNetwork

SKAdNetwork 2.0 introduced a variety of new functionalities vs. the older SKAdNetwork 1.0 and finally became functional enough, albeit very limited, for marketers to use for optimizing while also being able to create a report. 

The IDs available on the SKAdNetwork postback allowed marketers to report on app, campaign, and publisher ID, although pragmatically very few marketers reported on publishers given the extremely low volumes at the time. Getting the IP on the postback also meant that one could deduce the country from the IP address, which provided reasonable accuracy.

Outside of breakdowns, the big new thing for SKAdNetwork 2.0 was of course the new conversion value framework, which means that marketers can optimize and report on conversion events. Despite the limitations, this was a huge advancement for SKAdNetwork and encouraged a lot of new solutions.

In SKAdNetwork 2.2, which became available with iOS 14.5, marketers could run and report on view-through traffic, meaning conversions that Apple would attribute to an ad being viewed and not clicked. And later in SKAdNetwork 3.0, which became available on iOS 14.6, marketers could also understand if certain ad networks had an ad clicked while not being attributed to … AKA “loser postbacks.”

Reporting as it is done in Singular today

So what happened since iOS 14.5 and what marketers can see in Singular today? A lot. 

We can generally categorize our efforts into two main categories:

1. Enrichment with ad network data
2. Estimation and modeling

Enrichment with ad network data
We can extract a lot of information about the campaign from the ad network report. 

It starts with metrics such as Ad Spend as well as Cost, Impressions, Clicks, and breakdowns such as Country (since each campaign is targeting certain countries). Joining SKAN conversion data with ad networks’ campaign data also means that breakdowns such as Campaign Name, Ad Group and others are now available if the ad network tells us how they are mapped – which most of them do. 

Note that the default campaign-id field in SKAdNetwork postbacks is not the ad network’s campaign ID, but rather a “SKAN Campaign ID” whose values are limited to between 1-100 per partner. This SKAN Campaign ID often represents an ad network campaign, and sometimes may also represent a specific ad group and even a specific creative.

Enrichment of SKAdNetwork data with ad network data allows us to create a full-funnel report, connecting top of the funnel ad spend with bottom of the funnel conversions, which is the foundation of effective user acquisition reporting.

Estimation and modeling
In addition to limited metrics and breakdowns, SKAdNetwork also introduced the concept of privacy thresholds – a mechanism designed to protect user privacy and ensure that individual user info can never get exposed through the SKAdNetwork framework. The impact on marketers, however, is negative: some conversion value data is null instead of having a value that can be decoded back to its original meaning. 

On average, nullified data due to privacy thresholds takes approximately 20% of all data, which causes a meaningful accuracy decrease. 

To address this, we are now launching SKAN Advanced Analytics and are introducing the concept of modeling, where Singular is creating approximations for the missing data by leveraging the aggregated data it is able to access under Apple’s guidelines. This allows marketers to compensate for the signal loss, and our beta test customers achieved 87% accuracy.

What’s coming up (and why are we insanely excited)

So, after all of this, where do we stand now? 

The report that marketers access on Singular when running SKAdNetwork is fairly comprehensive, and many of our customers are happy with the performance of SKAdNetwork. However … SKAdNetwork-based user acquisition data doesn’t include Apple Search Ads or organic installs. This is since these data sets are not supported by SKAdNetwork and are reported or calculated differently. 

Metrics available in the report are totals (“actuals”) over 24 hours. This is due to the relationship between the conversions UA is trying to optimize versus. conversions it’s trying to report on. 

These are the truths in today’s SKAdNetwork reality that we are looking to redefine.

So what is the future we are envisioning? It is one where …

1. You can optimize campaigns for a desired measurement period, but reporting is not constrained by that time frame. Marketers should be able to calculate cohorts for any given time period.
2. You can view and optimize by the true KPIs that matter to your app. Whether it’s ROAS or CPA, we want to make sure mobile analytics can support the business metric.
3. You are able to get a single, consistent view of all channels and traffic types on the same table, using the same schema.

But why would this be possible? Well, we’re not certain it is, but we have every reason to believe so. 

In the current state of user acquisition on iOS, marketers rely on the limited data reported back by SKAdNetwork. However there are additional, high-resolution data sets which are left aside. This is where algorithms and estimation theory can come in and leverage additional sources of information to create estimates and predictions, solving for the missing gaps.

Let’s remind ourselves what are the data sets available to us as iOS marketers:

• SKAdNetwork data: This data set captures all paid traffic and provides the attribution source of truth as determined by a last-touch model.

• First-party data (i.e. IDFV data): This is a data set that every app developer collects, and a lot of it is already reported to MMPs and some other vendors (e.g. in-app analytics). It is highly granular and gives us an exact snapshot of device and user activity, minus the attribution information.

• Opt-in data (i.e. IDFA data): This is a data set that many apps who surface the ATT prompt continue to have, and is also, like IDFV data, highly granular. A key point to remember here is that SANs are no longer attributing to IDFA, so this data set is partial and provides a skewed image of reality where only non-SAN partners are attributed.

• Cost and campaign data: This is a fourth data set that is typically highly granular and is very useful for prediction algorithms. Methods such as Media Mix Modeling (MMM) heavily rely on this data set as the input to the marketing equation.

When we look at these data sets above, it is pretty clear that there’s a lot of information out there that our algorithms should be using. But why hasn’t this been done before? Because we didn’t need to. IDFA data was perfect (well, ignoring issues around last touch attribution models) and allowed marketers to calculate any metric needed. 

This also, at least intuitively, tells us about the huge potential for smarter technology used in the space of marketing measurement. The better we can use all of these four data sets, the better accuracy and detail we’ll be able to deliver back to marketers in the world of SKAdNetwork, privacy, and limited data sets.

We are excited about this future and can’t wait to let you try the new products that are coming up soon. As always, we highly value feedback and interest from customers looking to try these out as early adopters.

Today, we are announcing the general availability of Singular Private Cloud: a complete mobile measurement and attribution solution that runs on a dedicated cloud environment that is owned and controlled by advertisers themselves. Singular Private Cloud leverages data clean room technologies that allow advertisers to control, collaborate, and use data in a privacy-safe way best-suited to their individual needs.

We are proud to share that we’ve been live with the Singular Private Cloud solution for the past 18 months (!!), which has allowed us to evolve the technology and environment to dynamically work with any future privacy frameworks. (Anecdotally, when we first started, SKAdNetwork did not even exist in its current form, and this was a major change that was added to the solution during beta testing.)

The Singular Private Cloud solution allows brands and advertisers to maintain complete control over their growth stack, marketing measurement, and sensitive user data in an environment that they own and manage themselves. These new developments in data clean room technology will allow us to continue to innovate, and promise exciting opportunities as the technologies mature (which we’ll dive into later!).

Why Singular Private Cloud?

In today’s advertising landscape, it is no longer uncommon for marketers to learn about a new privacy-driven change and its effect on how they measure.

The recent iOS changes were very notably a striking demonstration, and it seems that every couple of months there is another change that marketers and marketing tools have to account for. The forces behind these changes are often regulatory, but media platforms such as Facebook or Google also often introduce changes to better accommodate for the public’s increased interest and scrutiny in how personal data is being collected, stored and used.

Mobile Measurement Partners, also known as MMPs, are often at the forefront of these changes. This is because:

• We operate globally, so any country legislation has to be accounted for
• We exchange sensitive information with all the media platforms, so any platform-specific requirements have to be met
• By definition, we collect first-party and third-party data, and brands may have specific requirements as to how we should collect, store and/or process a specific data set

Private Cloud can be a challenging concept to understand in a practical way. To add some color to this, let’s think about a few real-life examples:

• We have a customer whose privacy team determines that user data can only be saved for 30 days
• For data originating in certain countries, new legislation declares that IP addresses are private data which cannot be saved in plaintext
• A media partner or ad network shares data with Singular, but only allows certain brands to access it, and only in very specific ways, with custom limitations per brand
• A Fortune-100 company wants to have its first-party data stored in a dedicated database

All of these are real examples that we see at Singular regularly, and need to accommodate. As consumers become more conscious about privacy, new requirements constantly emerge. To solve this, the industry needs to start thinking about MMPs as the facilitators of data clean rooms.

What are Data Clean Rooms?

A data clean room is an environment (for example, a data lake on a public cloud), which allows multiple parties to share data in a mutually agreed upon manner. Sometimes this will be described as privacy-safe, but how the data is used is dependent on specifical rules. In this case, it simply means that there are certain privacy-driven rules applied to how and what data is entering and leaving this environment, and what data is accessible to each party.

In the marketing landscape, this translates to brands (advertisers) whose data is the first-party data collected on their assets such as a mobile app. Other parties include publishers and media platforms: notably the walled gardens such as Google, Facebook, and Twitter.

Interestingly for mobile advertising, MMPs were always somewhat of a data clean room since by their very definition, MMPs can access unique data sets that advertisers cannot … for example, click data for an ad. As such, MMPs always had various sets of rules they had to follow, mandated by the media and hardware platforms themselves.

In the last few years, more and more rules have been added due to a growing number of new privacy regulations. These changes have also led to increasing demand for data clean rooms and new technologies that would allow them to adapt to both new external constraints as well as brand-specific requirements.

Finally, while not strictly mandatory in its definition, it is assumed that for data clean rooms, the environment is completely isolated between different brand and publisher combinations. And this is a big technological leap that MMPs have not taken so far.

MMP evolution in the privacy landscape

MMPs facilitate mobile measurement and attribution and often, such as in the case of Singular, also collect additional data sets for the purposes of rich analytics.

Singular is responsible for collecting a multitude of data sets. There are aggregated data sets such as ad spend, creative, and bid data, which is then combined with device-level impressions, clicks and events. Advertisers often send additional first-party data, for example subscription information, so that ultimately Singular can calculate and visualize the KPIs that matter most towards optimization.

These data sets, especially the device-level ones, are at the intersection of multiple sets of constraints and requirements that MMPs have to accommodate for.

A few examples:

• Apple and Google have platform-specific requirements for mobile apps to get published on the App and Play Stores. Example: only using designated advertising IDs and not hardware IDs such as IMEI.
• Apple and Google have also introduced additional privacy-driven initiatives such as those for kids apps and, of course, iOS 14.5.
• Facebook, Google and all other Self-Attributing Networks (SANs) each have their own unique set of constraints that MMPs must meet, for example, on how and for how long device-level data is saved, and what type of data can be shared with the advertiser.
• Regulations such as COPPA, GDPR and CCPA are both geo-specific and provide room for brands to interpret differently.
• Privacy frameworks such as the UK’s AADC, Privacy Shield and others also translate to additional requirements on the data MMPs are collecting, processing and sharing.

If you generalize all of this, it’s pretty clear that MMPs are acting as data clean rooms. Thus, building the technology to quickly adapt to new requirements is critical in the current landscape and has to be an inherent component of the platform and design process.

Announcing Singular’s latest solution

Privacy technologies are constantly evolving, and new technologies for data processing in a privacy-safe manner are fascinating.

For example, federated learning could allow for some user data to never have to leave the device, without compromising measurement capabilities. Differential privacy methodologies can provide needed marketing optimization insights without accessing sensitive information tied to specific individuals.

All of these will play a rule in tomorrow’s data clean room.

But today, we can already provide to customers the ability to run on a dedicated measurement environment that provides the same exact set of capabilities you’re getting from our public platform. This means that mobile and web attribution, fraud prevention, cost aggregation, and ROAS and cohort reporting are all available in a dedicated environment, allowing your data to live and breathe in complete isolation from other brands’ data. Brands can apply customer-specific privacy rules to accommodate their specific privacy and legal teams’ unique requirements.

Over the past 18 months we’ve built the technology that allows us to operate these environments in a reliable and scalable manner, and we’ve been running with a few major brands as beta partners to bring this to general availability. I am excited to share that we can now offer Singular Private Cloud to additional customers.

What’s next?

Privacy tech is constantly changing and new technologies will allow us to take this even further. But most importantly, more and more brands adopting these platforms will meet us with additional needs and will accelerate our learnings as we continue to build for the purpose of providing better data and better measurement to the market.

Want to take ownership of your data and leverage Singular’s data clean room technology? Have more questions? There are a few more details in our press release.

Better yet, schedule time with one of our product experts.

The future of mobile measurement on iOS is a single view that brings back KPIs, cohorts, and ROAS analysis. Marketers want a single source of truth for iOS like they once had, and I think we’ll be able to provide it.

Of course, there’s mileage to travel before we get there.

While we can’t predict exactly what SKAdNetwork changes are coming, I think we can all agree that the split between SKAdNetwork and MMP data that inherently exists today is not good enough. But, there’s good reason to have hope that it will improve, and that mobile marketers will have the data, insights, and tools they need to optimize growth.

 

Where we are today: mobile measurement on iOS

Over the past year, many of the fundamental truths we’ve known about mobile app attribution have changed. User acquisition teams learned a brand new set of terms, definitions, and best practices. The mechanics of how you optimize campaigns — and even how you run campaigns — is now different.

Wishfully, some parts of the industry, and perhaps not-so-small parts of it, have seen the iOS changes and the new Apple privacy policies as no more than a technical hurdle. But as we’ve seen throughout the year, SKAdNetwork is here to stay.

Recognizing this leads to an obvious conclusion – we are in need of new technology.

Apple has laid out the basics. There is a way to get attribution on iOS, but it’s neither as good nor as easy as it was with IDFA. The good news, however, is that there is plenty of technology potential out there, and that the measurement market is more competitive than ever. Solutions are coming.

 

MMPs’ evolving role in iOS marketing measurement

Not surprisingly, we’ve seen a vast change in MMP philosophy towards iOS measurement and SKAN over the past year.

Let’s be honest: even today, the vast majority of MMPs are not really ready when it comes to supporting advertisers with running and reporting on SKAN campaigns. However, in sharp contrast to the past, it’s clearly sensible to argue that the MMP is the optimal SKAdNetwork facilitator: running your conversion value updates against iOS devices and collecting all the SKAdNetwork data from your media partners. Plus, good SKAdNetwork systems will support as many measurement models as possible so your mobile app can best utilize the limited bitwise representation of conversion values that Apple has given us. And better SKAdNetwork systems will decode those conversion values back to the original events so that reporting makes sense to advertisers and they can optimize on actual KPIs.

 

I’m not shy to say that Singular has led the way in defining what is needed from a good SKAdNetwork system.

Early on, we defined (and then released) the common models we believed should be suitable for most mobile apps. We released multi-day measurement even when no ad network was supporting it, as soon as it became clear that doing so would help push the market to adopt this. We worked with partners to create powerful integrations that would help everyone exchange information on the relationship between the SKAdNetwork campaign and ad network campaigns, as well as define how in-app events are encoded to SKAdNetwork bits.

But today we are not going to talk about what a good SKAdNetwork system looks like. Today we are going to define what the best SKAdNetwork system will look like — even if it’s not quite available just yet.

 

An important first step: Fix the data

The first thing to acknowledge about SKAdNetwork data specifically and SKAdNetwork in general is that it’s hard. It is genuinely hard, and this is mostly because Apple has made it as such.

But we need to remember that this is a new framework, and we have to think in new terms. It is no longer about attributing a single user: small data sets that expose individual users are no longer supported, and SKAN’s random timers make it even harder to get information about individual users.

What this all means is that even if you’ve gone through the effort of implementing SKAdNetwork in your mobile apps and are running SKAdNetwork campaigns with partners, there is still a fairly decent chance that the data you see, likely in your MMP dashboard, can range between bad and non-usable.

That is horrible.

Let’s just be honest about it. It is really, really bad when marketers adopt the new standard, put in a ton of hard work, and see no reward for their efforts.

A lot of it is due to privacy thresholds as well as common errors that people are making when it comes to running SKAN campaigns. For our customers, we see Singular as a key piece in solving for that, and this is where our new technology comes in. In last week’s release, we announced SKAN Advanced Analytics and its first milestone – Modeled Metrics.

Modeled Metrics fixes the data gaps caused by privacy thresholds using data science and statistics.

It is not magic, but it is some very cool tech that allows our customers to worry less about the common SKAdNetwork pitfalls that would otherwise compromise SKAN data and enables them to just do their jobs. In other words, SKAN Modeled Metrics from Singular supplies clean, actionable insights that lets marketers make allocation and optimization decisions with a high degree of confidence that their data is complete.

 

The future of iOS mobile attribution: A single view

To understand where we are going with SKAN Advanced Analytics, let’s think about the potential for MMPs as a powerful technology provider for advertisers:

• Our SDK is in the app
• We operate SKAdNetwork updates
• We collect unattributed in-app data, and cover 100% of users
• We still collect attributed opt-in IDFA data for some apps/users, which typically covers 20-40% of users
• We collect SKAdNetwork data from all media partners via postbacks and APIs
• In Singular’s case, we also collect granular ad spend data that tells us where advertiser budgets are going in a very accurate way

Now, let’s think about the problem.

Marketers want reporting to be as it was, which means cohorted, full-funnel metrics, against every meaningful breakdown that can teach us something about the campaign.

Some breakdowns, such as creative, are not readily available by the framework. We expect these to either get added by Apple or supported indirectly by increasing the limits on skan_campaign_id. Improving the conversion model will improve the underlying accuracy. Combining the knowledge we have from all these siloed data sets should teach us a lot more than what we can learn based on the SKAdNetwork dataset alone.

As I mentioned initially, we can’t predict what changes Apple will make in SKAN.

We can argue, however, that the future of iOS measurement is a single view of marketing reality: a single source of truth that returns KPIs, cohorts, and ROAS analysis. And, a source of truth that offers predictive values for KPIs like revenue.

 

What that means: how we see iOS measurement evolving

As we’ve previously established,SKAdNetwork data is determined by the following aspects:

• The conversion model determines the underlying accuracy.
  • For example, an optimized revenue model for an app with in-app purchases happening in the first 24 hours will generate better data than a basic six-event model that doesn’t optimize on value.
  • In another example, a model that uses a 72-hour measurement period will generate better data for an app that has the vast majority of conversions happening in the first three days than a model that only looks at the first 24 hours.
• Statistical algorithms can aid in reconstructing partial data due to privacy thresholds and timer skews
• Predictive analytics can leverage multiple data sets collected by MMPs to create an easy to understand and easy to use report.

If we look at these components we can also imagine additional improvements:

• Machine learning can help cluster users better, thus further optimizing the conversion model to distinguish between high value and lower value users. We expect this to be common for Singular and other MMPs as the operators of the model.
• Machine learning and other technologies can help calculate the predictions of previously mentioned KPIs, and any improvement in the underlying data will further improve such predictions.

To summarize, we believe that over the next year iOS measurement will go through a dramatic change. SKAdNetwork will continue to grow in adoption as the de facto standard, and marketers that rely on non-compliant workarounds may find themselves lagging behind while others are taking advantage of the gigantic pool of growth opportunity that is the iOS ecosystem.

We do recognize that supportingSKAdNetwork for the past year has been quite taxing, but these new technologies provide our advertisers with a real edge. The simple fact is that advertisers that use MMPs that are betting against SKAdNetwork will be left behind.

It is only a question of when.

As technologists, we are excited by the enormous opportunity that lies ahead of us. We are going to be building a lot in this upcoming year, and we can hardly wait to reveal what will be coming next.

 

What’s next, and how to get better insights yourself

We are only getting started with SKAN Advanced Analytics, and the recent release, SKAN Modeled Metrics, already gives our customers improved visibility to SKAN performance. Stay tuned for our upcoming posts that provide more detail.

In the meantime:

If you want to take ownership of your iOS marketing measurement or have more questions, schedule some time with one of our product experts.

Welcome to the third blog in our cross-device attribution series, where we discuss how advertisers can leverage web campaigns as a meaningful acquisition medium for mobile apps and other platforms. Check out our previous posts on this topic, Part one and Part two, to get up to speed.

This recent post will address some of the critical data and reporting challenges that marketers face when implementing cross-device attribution. We’ll then present different methods to generating meaningful analytics when the underlying datasets are collected across multiple platforms.

Providing the correct views and analysis to marketers can often create the difference between having the ability to distinguish between your stronger and weaker channels and activities vs. running reports that lead to misinformed decision-making.

Cohort Analysis for Cross-device Attribution: The Basics

Let’s start with the basics and remind ourselves how we define cohorts in marketing analytics:

A cohort is a group of users with a common property. By looking at users with a common property, marketers can often isolate findings and effectively identify trends.

There’s no strict outline of how cohorts should be defined; however, certain industries have their own standard conventions. In mobile marketing, advertisers are often looking at app install campaigns, so Mobile Measurement Partners (MMPs) provide install-based cohorts, users grouped by install date. So if you go to your Singular dashboard and run a report that includes cohorted metrics, these metrics are calculated for a given install date, such as ad revenue, the total revenue during the first seven days after the install. A sharp reader may also call out that seven days can be calculated “on the calendar” or in 24-hour increments, and both would be valid! The MMP can decide on one of these or provide the option to the advertiser to choose the cohort definition that best works for them.

Lastly, we should also call out that cohorts are defined as groups of installs in mobile marketing, not users. This is because a new install might belong to the same user, but to the standard MMP, this would be a new install added to the cohort. Similarly, in web marketing, cohorts are often defined based on the user’s acquisition date, which is when (i.e., the date when) the user first landed on your webpage, which is not too different from the install date on mobile.

Cohort Analysis for Cross-device Attribution: User vs Device

When we look at cross-device, a single user can interact with ads and consequently convert on multiple devices and platforms, so the cohort definition needs to be redefined. With a single platform, the norm is to look at when the device converted. While with cross-device, we’d want to look at when the user is converting. In most products, this would be when the user sets up an account or signs in for the first time.

Let’s demonstrate this by example. My company built the latest social network, which offers 13-second chats with users you’ve never met before around the world! We have built this new network on mobile and web, so we get installs from the mobile stores and website visits from desktops and mobile phones. Users click ads, but as soon as they try to use the product on the respective platform, they need to sign up and log in. Another thing worth mentioning is that a user may click on multiple ads across multiple platforms before deciding to sign up and start using the product. And this is what we are interested in as the point of reference.

When thinking about this problem in terms of your standard marketing tools, an attribution provider that is limited to a single platform will present a partial snapshot of reality — and consequently, when working with several tools, there will be overlap, leading to inaccuracies in each tool’s cohorts. Determining a certain campaign’s LTV becomes difficult since you might be including existing users in that campaign, thus inflating the LTV from user acquisition (UA) activity.

Another thing worth mentioning is that even on a single platform, looking at users instead of installs or devices reveals a lot more insight. In addition to a more accurate LTV, the change in the definition of conversion carries a lot of value to ROI analysis and comparison. For this reason, in certain verticals such as Ecommerce, it is more common for marketers to define cohorts based on the first time a user makes a purchase, for example, which is much more meaningful than the time of install. However, the most important thing is to ensure that the data is accurate given a point of reference.

Cross-device Attribution and Analytics in Singular

By providing the option to select how cohorts are calculated in real-time, marketers using Singular can choose between device-based cohorts and user-based cohorts. This allows you to understand the actual LTV, or any other KPI, for a group of users instead of installs or website visits. It also enables you to understand how those users interact with your product across platforms. For example, you may acquire users at scale on the web, but they use the product on multiple platforms with different retention patterns. A particular web campaign may drive revenue on both mobile and web, depending on the campaign and the channel where the users are acquired.

Similarly, a particular mobile web may drive X new website visits where only a fraction is new users. Understanding these relationships is key to scaling your UA effectively.

This also suggests that on the Singular side, we have to distinguish between the marketing parameters that are attributed to the device (e.g., a new install on iOS) vs. different marketing parameters that are attributed to the user (e.g., Evie who has just signed up for a new account after clicking on an ad). The channel, campaign, creative, and more could be completely different. By getting this data also in raw form, marketers gain complete visibility into the user journey.

What’s next in the series?

Now that we’ve covered how reporting for cross-device attribution works, we’ll continue to discuss meaningful topics for marketers who run across multiple platforms or who want to diversify their UA to better prepare for iOS 14.5. In the next post, we’ll dive deeper into pixels, postbacks, and conversions to understand how your ad partners are also affected by how your cross-device attribution setup and what marketers should do to improve campaign performance. As always, we encourage you to learn more about Singular’s web, web-to-app, and cross-device capabilities and schedule a demo with one of our product experts.

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.

 

Since WWDC20 everyone in the mobile ecosystem has been busy learning, asking, discussing, and mainly, formulating solutions for measurement after iOS 14.

Today, we’re excited to walk you through our solution and update you on multiple new measurement methods that are now part of Singular’s SKAdNetwork solution. This solution is a major step forward for SKAdNetwork attribution, ensuring that your data is trustworthy, fraud-free, unlocking ROAS, and cohorts.

Our solution focuses on three areas:

1. A Secure-SKAN setup that ensures SKAdNetwork data can be trusted
2. Smart Conversion Management for seamless in-app event modeling
3. SKAdnetwork-powered Analytics that unlocks ROAS and cohorts

 

A bit of background

At Singular, we’ve been super busy as we made it our goal to educate all who want to learn about the new reality of iOS 14 and SKAdNetwork. We’ve also formed a working group over a year ago with less than 20 companies, that now has 1400+ members – and we highly encourage you to join.

After launching our first-to-market support of SKAdNetwork in July (see more details in our Help Center), we decided to take things a step further. We drafted a new standard for implementing SKAdNetwork that we’ve called SKAN — a framework we strongly believe will be the foundation for how the entire mobile marketing ecosystem can run user acquisition post-iOS 14. We’re now releasing version 1.1 in GitHub – and we’re excited to update that multiple top ad networks and leading advertisers are collaborating with us to make the standard more usable and widely adopted.

Initially, we noticed hesitation from other MMPs to adopt SKAN, but nowadays, it seems like everyone is quickly accepting the reality of needing an SKAdNetwork solution with the principles Singular has introduced in SKAN. That makes us incredibly happy, and a bit proud, as we strongly believe this is where the industry needs to go in terms of both privacy and standardization.

It certainly benefits advertisers and marketers when there’s alignment across vendors.

Quick recap: what does an SKAdNetwork solution need to do?

If you haven’t yet, read the quick summary of what SKAdNetwork is and the main limitations it presents. In a nutshell, leveraging SKAdNetwork as an advertiser entails building three main functions:

1. Postbacks: Receiving and validating SKAdNetwork postbacks from your ad network partners
2. Conversion management: Conversion management to generate insightful SKAdNetwork datasets
3. Analytics: Reporting and analytics that would report on SKAdNetwork data, as well as combine it with other data sets you already have ranging from ad spend to publisher-level bids, and ultimately allow marketers to optimize their UA efforts

Every one of these areas presents new challenges for marketers, but also opportunities for innovation that we believe can keep user acquisition alive and strong post iOS 14.

Part 1: Collecting SKAdNetwork data and announcing Secure-SKAN

Establishing trust in your data is at the core of any analytics system — especially when dollars are involved. By default, the entity that receives the SKAdNetwork notification (postback) is the ad network, which needs to register with Apple. Ad networks can then forward install postbacks to advertisers and MMPs to validate them, which is rather straightforward as Apple cryptographically signs them.

Singular has over 2000+ proprietary data connectors to various ad networks, and we are working with our partners to embed SKAdNetwork data into APIs and reporting interfaces. Being the market leader in data aggregation, we will be able to quickly and accurately ingest the SKAdNetwork data in addition to all the other metrics we’re collecting today: ad spend, impressions, clicks, bids, video views, creatives, etc.

 

Announcing Secure-SKAN

There is however one critical flaw that has to be addressed: Apple does not sign conversion values in SKAdNetwork. That effectively means that conversion values are self-reported by ad networks. That’s where Singular’s Secure-SKAN solution comes into play.

Secure-SKAN is a solution where Singular as the MMP will register jointly with every partner that will be publishing your ads. SKAdNetwork supports this by design, and we’ve been working closely with partners and advertisers (including Apple) to validate the solution is technically equivalent and solves the trust piece. On the ad network side, adopting Secure-SKAN is straightforward as you essentially receive the same exact postback — however, Singular is simply forwarding it.

Part 2: Privacy-safe SDK with Smart Conversion Management

Conversion management in SKAdNetwork is a complex, onerous task that if done incorrectly will yield fragmented, inaccurate data. However, when done right, the six bits of conversion values provided by SKAdNetwork can do quite a lot — including cohorts, which can be used for ROAS analysis.

Unfortunately, all this heavy lifting is the advertiser’s responsibility — and this is where Singular comes in.

When thinking about what our iOS 14 SDK should achieve, we had the following principles:

• Offer a fully-automatic SKAdNetwork solution that does not require additional development efforts, while recognizing that some teams may want to manage conversions themselves
• Offer complete control for the new Apple privacy policies and what data is being reported from the device —  especially as these policies will change over time

 

Now live: iOS SDK with advanced SKAdNetwork support

We’re excited to announce that our latest iOS SDK version with support for SKAdNetwork is now live. This gives our customers ample time ahead of iOS 14 to study, discuss, and integrate everything they need to be ready. (Access the documentation here.)

For customers leveraging Singular’s S2S solution, an update to the S2S integration will be required and will rely on the same principles. We will be reaching out to review the updates needed.

As mentioned before, in the SKAdNetwork solution, the SDK has a critical role in smart management of conversion data. This means that in addition to supporting basic models for revenue, retention and event optimization, our SDK will add some cool, unique features we’re especially excited about.

Smart Conversion Management

We all know by now that SKAdNetwork only supports six bits of data for conversion values. This seems rather limiting but can actually facilitate quite … a bit. Or, at least a little more than you’d initially expect.

When we say Smart Conversion Management, we mean the following:

• Simplicity
• Scalability to complex uses
• Cohort capability with ROAS
• SKAdNetwork timer support management

To keep ourselves honest here, six bits won’t give us the ability to report on 180-day cohorts. We wish it did. But at the same time, establishing 3-day and even 7-day cohorts provides a great foundation for optimization that takes you a whole lot closer to true LTV.

Conversion management in SKAdNetwork is a fascinating topic, and we can’t wait to provide more details about it soon.

Part 3: SKAdNetwork-powered analytics and testing tools

Finally, let’s talk about analytics. By design, SKAdNetwork data is highly fragmented. We’ve solved a very similar problem for ad spend and ad network data, so these challenges are quite familiar. Then there’s also conversions – you’ll need to translate values to meaningful event information, as well as tie it all back to the right campaigns.

As you may recall, the fields available in the SKAdNetwork response are the following:

• Source, which would normally be the attributed ad network or any other registered publisher that called loadProduct() to display the ad
• Campaign ID, which is generated by the ad network
• Source App ID, which is the actual publisher app that showed the ad

Leveraging Singular’s Data Connectors, we can connect this data to campaign names, app names (for the publishing app), bids, and other metadata at the campaign and publisher level and of course — ad spend. Tying this together with 3-day, 5-day, or even 7-day cohorts can produce a powerful report that continues to enable user acquisition teams to make informed decisions about their ad spend.

Of course, there will be trade-offs and limitations depending on the different models selected, but at the same time, there are also further opportunities for improvement which we’ll touch on soon.

Parallel testing of conversion models

This notion of selecting your model beforehand (since it needs to be managed by the device) is somewhat new, and there will definitely be a lot of learning required. We are excited to see what advertisers come up with and look forward to working with you to build the technology to facilitate it.

Given that this is such a new technology, we anticipate that many advertisers will not really know what will work best and will want to test to find out. That’s why we came up with a solution for parallel model testing

With this tool, we can test and calibrate a variety of conversion models with existing data collected outside of SKAdNetwork. In fact, we’re even doing this today to test our models’ accuracy! This is super cool and will allow marketers to better understand what models can work best for them without sacrificing data integrity.

Singular’s parallel testing is not a solution that splits your devices between models. We’ve seen this around, and although it’s interesting, the concern is that with the privacy thresholds that Apple is introducing, resulting user segments will be too small, which will hurt the reliability of the data.

Where do we go next?

The solutions presented here are the result of hard work before and after the WWDC20 announcement, and there’s a lot more that is still needed by everyone – advertisers, ad networks, and MMPs alike.

In the upcoming weeks, we’ll work with you — our customers and partners — to bring these solutions to production. We’re happy to hear your ideas and suggestions about further enhancements we can add.

Lastly, but most importantly, no one party can solve this on their own. We invite marketers, app developers, MMPs, ad networks, and any other individuals interested in mobile app privacy to join the Mobile Attribution Privacy (MAP) coalition Slack group to learn, debate, iterate and collaborate to chart the course towards better measurement solutions.

 

Last Thursday, the Court of Justice of the European Union (CJEU) issued its decision around the “Schrems II” case, effectively invalidating the EU-US Privacy Shield framework, one of the mechanisms that support transfers of personal data from the EU to the US.

Singular’s Attribution customers are not affected by this ruling; however, we understand that our customers and marketers, in general, may have questions about this decision. Note that if you’re using Singular for Analytics, we encourage you to reach out to your MMP for further details on how they are handling transfers of personal data from a compliance perspective.

The invalidation of Privacy Shield will likely impact thousands of US companies that rely on the framework. Thankfully, we already have a solution in place, “Standard Contract Clauses” (sometimes referred to as “Model Clauses”), to seamlessly continue receiving personal data from the EU despite the Privacy Shield’s invalidation. The CJEU upheld this approach in the Schrems II case.

What is Privacy Shield?

The US-EU Privacy Shield framework, aka Privacy Shield, is a mechanism established in 2016 by the United States government and the European Commission. Companies in the US who want to receive personal data originating in the EU for processing in the United States could voluntarily self-certify under the US-EU Privacy Shield framework and take on higher commitments to privacy to be considered “adequate” by the EU to receive personal data. 

Singular and many other companies who are required to process personal data as part of its services, had certified itself under Privacy Shield.

What is the new ruling?

In Thursday’s judgment, the CJEU invalidated the US-EU Privacy Shield framework as a data transfer mechanism. The court held that given the disproportionate, mass and bulk access that US law enforcement and intelligence agencies have to personal data under US laws, the US-EU Privacy Shield framework does not provide sufficient protection to EU personal data per the GDPR. Therefore, the court’s striking down the US-EU Privacy Shield framework renders the Privacy Shield an invalid mechanism to support cross-border transfers of personal data from the EU to the US. The court’s judgment is effective immediately.

Singular is certified under the now-invalidated Privacy Shield. How can Singular continue to receive EU data lawfully?

Singular uses a solution called “Model Clauses” or “Standard Contract Clauses”, which was upheld by the CJEU in the Schrems II case. According to the Model Clauses solution, Singular’s data processing addendum (DPA) includes special data protection clauses adopted by the EU Commission as a mechanism to legalize cross-border transfers of personal data from the EU to the US. If you’re using our attribution services, you should have a DPA as part of your service agreement that includes the Model Clauses.

Are Model Clauses sufficient to allow cross-border transfers of personal data from the EU to Singular?

Based on the Schrems II case, Singular firmly believes the Model Clauses are sufficient. Under the Model Clauses, Singular is committed to notifying the customer immediately if it has reason to believe that it cannot comply with the Model Clauses due to US law enforcement or intelligence agencies requesting access to the data Singular has. Singular reaffirms this commitment and confirms that we have no reason to believe that we cannot comply with the Model Clauses.

What’s next?

The privacy landscape is ever-evolving – recently at higher speeds than ever before. Our security and privacy philosophy, as reflected recently with our response to IDFA changes in iOS 14 and SKAdNetwork, has always opted for a more strict approach, with a multitude of solutions for our customers. This philosophy translates to significant investments we are making by introducing more robust mechanisms to go beyond what’s minimally required by the standard compliance. Additionally, it means that we look at regulations such as GDPR and CCPA, and at standards such as COPPA with a more critical eye than otherwise required.

We continue to stay committed to ensuring your data on our platform remains protected and private.