Customer and user data security and privacy at Singular

Sometimes the things you think don’t need to be said, need to be said.

Singular is a marketing analytics partner operating in the age of privacy. We have been in that age for some time, and the demands for privacy as well as data security and integrity are only increasing. That’s why it’s important to not only take the responsibility of holding our customers’ data very seriously, but also recognize how important it is legally and ethically to ensure that our customers’ customers — the people using their apps and games, or buying their services or products — are treated with the same respect.

That means:

  • Our customers’ data is theirs, not ours
  • We never sell or disclose or rent our customers’ data to third parties
  • We minimize how much data we collect for the specific legal and authorized purposes our customers have
  • We hold all data in secure, private storage
  • We delete data in accordance with legal and partner requirements 
  • We comply with all applicable laws and regulations
  • We are a member of the PRIVO Kids Privacy Assured Program for COPPA Safe Harbor Certification and GDPRkids, and fully comply with GDPR

These kinds of commitments are why we were first to market with a mobile attribution solution for Apple’s privacy-preserving SKAdNetwork. They’re why we are working on technology for Google’s Privacy Sandbox for Android and Privacy Sandbox for Web, and why we’re committing ourselves to the concept of hybrid measurement, which uses multiple privacy-safe technologies in conjunction to generate accurate and actionable marketing signal in the absence of old-school unpermissioned technology-based tracking.

They’re also why we never developed any kind of data clearinghouse to share/rent/sell user data. And why — back when it was feasible — we never built a device graph to correlate data on the phones, tablets, and computers that engaged with our clients’ advertising or marketing campaigns. 

Our goal is simple: help our clients grow faster than their competition.

Since growing is hard to do when major partners or platforms get concerned about potentially questionable data practices, or authorities start investigations, we ensure we achieve our goal through legal, ethical, and compliant means.

If you have any questions about data integrity, storage, use, or compliance, please feel free to contact your Singular representative, or me personally.

Leveling up SKAN performance: 3 stages of SKAdNetwork effectiveness

“SKAN performance sucks”

“SKAdNetwork is useless”

“Performance marketing is over”

I’ve spent more hours, days, and months in the last two years than I care to count thinking about, talking about, working on, consulting about, and advising on how to extract every possible ounce of marketing signal from Apple’s SKAN framework. Over the course of countless deep dives into data, connectors, conversion models, and SKAN set-ups, a few things have become clear about SKAN performance.

  1. Everyone’s at a different stage with SKAN
  2. It’s easy to do SKAN wrong
  3. When you do it wrong, the data looks … well, insane
  4. When the data looks insane, it’s easy to give up on SKAN
  5. But … everyone can get better at setting SKAdNetwork up
  6. Everyone can optimize their conversion models
  7. Everyone can get usable signal out of SKAN
  8. Everyone can still do performance marketing on iOS at scale

I’m not claiming it’s easy. Nor am I saying you’ll get it right the first time around. You may need some help from a tool like Singular’s SKAN Advanced Analytics to model missing data and re-create cohorts, or our latest tech to automatically optimize SKAN conversion models. But — with a little help from friends — you can run high performance marketing campaigns on iOS with SKAdNetwork.

Let’s go through the levels that I’ve seen out there.

SKAN performance level 1: beginner

Not everyone’s an early adopter, and that’s OK. No one can decide better than you where to allocate your finite resources for product development, marketing, and data science.

But here we are.

The App Tracking Transparency reality is people aren’t opting into sharing IDFAs. The tracking reality is that fingerprinting violates Apple’s guidelines and risks getting your app yanked from the App Store. If you’re going to do mobile user acquisition measurement on iOS, SKAdNetwork is the way.

IDFA-skadnetwork-singular

Want to do incrementality instead? Want to do media mix modeling instead?

Sure, go ahead. There is some value in those approaches (and stay tuned for more from Singular on this). But you’ll find the data science, modeling, and tweaking you’ll need to do here outweigh what you’ll need to make SKAN work by an order of magnitude, at least. And do you really want to turn your back on the one deterministic (if aggregate) measurement methodology we still have on iOS?

Of course not.

So, here’s how SKAN works in a nutshell

  1. A publisher app shows an ad for your app (the advertiser app) from a network for a specific “SKAN Campaign ID”
  2. A person clicks the ad, installs, and launches your app
  3. Your app, the advertiser app, updates a “Conversion Value” (CV) for that user in the first 24 hours, which is a number between 0-63
  4. After a random timer of 24-48 hours, their device sends a “SKAN Postback” to the ad network (and you) to report on the new install
  5. If the number of installs per SKAN Campaign ID passes Apple’s “Privacy Thresholds”, the postback includes the CV
how SKAN works?

There’s a bunch of problems from a mobile marketing point of view with this model, especially compared to what you had before App Tracking Transparency. The core problem: restricted visibility of post-install events is causing a gap between the data SKAN provides and the data marketers have traditionally needed.

The challenges include:

  1. Capturing complete SKAN data
  2. Navigating complexities in SKAN conversion value management
  3. Dealing with very limited 24-hour data windows, mainly driven by how major ad networks implement SKAN for campaign optimization
  4. Missing data due to unmet privacy thresholds

The solution has three core parts

The solution has three parts, each of which is essential for optimal SKAN performance: a foundational conversion management system, out-of-the-box SKAN reporting, and advanced data science to model missing data and restore your ability to analyze, optimize, and predict. 

SKAN performance

That’s Singular’s solution for SKAN, where:

  • The SDK manages all the API calls you need
  • Our conversion management technology encodes your conversion values and shares your model with the ad networks you partner with so they understand what good results look like for you and can optimize campaigns
  • SKAN reports aggregate and validate all your SKAN postbacks from all your partners, decode your conversion values, and calculate cost per acquisition and return on ad spend
  • Advanced analytics return missing data to provide complete visibility into your SKAN campaigns performance

I always recommend marketers start with a very simple conversion model and iterate. Pick events that you can easily validate, and that are highly indicative of high-value users. The events you choose MUST be likely in the first 24 hours post-install.

Also, include revenue buckets in your conversion model (don’t worry, there’s a simple wizard to walk you through setting it all up) if you have in-app purchases or ad revenue. We call this using mixed conversion models, and I’ve seen it result in getting literally 50% more data out of SKAdNetwork.

Worried about getting the right conversion model?

We can help, but most importantly, Singular has automated technology that in many circumstances can detect if there’s a more optimized SKAN model to use and will notify you.

SKAN

All the major ad networks support SKAN today, so start with whichever one you’re familiar with. Don’t just put a few dollars on it: due to privacy thresholds data returned from below about 20 installs per SKAN Campaign ID will be incomplete and unusable. So drive some scale with each partner and in each campaign. Talk to your partners about how many SKAN campaign IDs they use for internal optimization processes, and get their recommendations for campaign budgets and scaling.

Once you’re up and running, check your SKAN reports in Singular’s dashboard. See if the conversion values look right. Scan through the estimated CPA and ROI numbers and check for anomalies. 

Once you’re happy with the results, iterate onward and upward: you’re ready to level up your SKAN performance.

SKAN performance level 2: advanced (optimizing and scaling)

It’s a big leap from wiring up SKAN and defining an initial conversion model to optimizing SKAN, and this big leap is what separates those who find iOS performance marketing success and those who never really get their SKAdNetwork reporting to the point where it becomes a useful tool for user acquisition and growth marketing at scale.

There are a bunch of challenges mobile marketers typically face when they get SKAN up and running:

  • Your data looks completely different from what you’re used to and expecting
  • You’re not getting enough conversion values
  • Which means you’re barely seeing any revenue
  • And, of course, there’s no granular device-level information

The result is that your initial performance looks bad, and this is the point where many give up. Persist: there are practices to both optimize and scale your campaigns.

But you have to go beyond the basics.

SKAN insights

Your foundational outputs in a SKAN world are not just from SKAdNetwork. You have more data than you think: you just need to unlock it, combine it, enrich it, and use it to generate meaning, accuracy, and insight.

It starts with campaign data from ad partners: delivery, cost, creative … all your network KPIs. It continues with all the data you get from the SKAN framework — raw postbacks — and the conversion model you set up that is tailored to just your specific KPIs and measurement periods. (Note for those with multiple apps: this is generally unique to each app.) And then you cap it all off with device-level data that you can still get: IDFAs where you get ATT consent, IDFVs for all your installs. This will help you build measurable, trackable, privacy-safe cohorts.

How?

Singular’s SKAN solution combines all these outputs of your marketing and mobile activity and, in the SKAN basic insights layer, delivers actual SKAN CPI that is enriched with campaign data. Plus SKAN actual ROAS and SKAN actual CPA, using actual decoded events and estimated install dates.

Alone, however, that’s not enough to generate the level of measurement and insight you need to really optimize current campaigns and strategize future ones. The reason is that with missing data due to privacy thresholds and single point-in-time postbacks, the actual hard data that SKAN returns is insufficient.

You also need Singular’s advanced analytics insight layer, which models missing conversion data using your own first-party data, including IDFV, to deliver modeled and de-censored ROAS and CPA, estimated cohorts with ROAS and CPA, and SKAN LTV optimization. All of which unlocks Singular’s ability to automatically check and re-check your operational conversion model and provide recommendations for improvement that will unlock even more accuracy.

Why is optimizing conversion models so incredibly critical?

Our best customers — the smartest mobile marketers we know — test 6 models on average before finding success. (And guess what: when the world changes, when your app changes, when your marketing changes … the “best” SKAN conversion model may have to change as well.)

The ideal SKAN conversion model uses both early signals and strong predictors of high LTV. Revenue is the most accurate predictor, but it’s scarce. Events have a much higher volume, but they’re significantly less predictive. So most user acquisition experts end up using a mixed conversion model using all of SKAN’s bits that includes both revenue and events: 2 bits for 3 events, and 4 bits for 16 different revenue buckets.

(Note: coming soon we’ll have a new mixed model type that will support 3 “preliminary” events and up to 60 revenue buckets. Stay tuned!)

Why is it critical to have so many revenue buckets to achieve SKAN performance?

When you don’t have enough granularity in your revenue buckets, you lose accuracy.

SKAN performance

For example, a bucket that’s from $2 to $4 might end up containing events that, on average, cost $3.75. But when you decode SKAN conversions, you don’t know that. So your average estimated revenue might just be $3 per conversion. True performance is significantly higher, but none of your network optimization or internal accounting knows that. Partners can’t optimally optimize (if I can say that) and you report much lower ROI, ROAS, and predictive LTV than you should.

This makes a couple things about SKAN performance really clear.

  1. Working with your product team is essential to building your conversion model right. You simply have to be in super tight communication so that events and revenue that are likely to happen — and that product incentivizes or guides users toward — are reflected in your conversion model.
  2. Matching revenue buckets as closely as possible to the actual distribution of revenue — what gets sold at what price points early in your users’ journey — is really, really important.
SKAN performance

For instance, using 16 revenue buckets instead of 8 can increase accuracy 45%. Using 32 revenue buckets can make you 74% more accurate.

That’s huge.

You have to know the good, and you have to know the bad. As bad as it is being unable to optimize campaigns that are working well BUT YOU DON’T KNOW IT, it’s even worse to be unable to optimize campaigns that are failing … but you also don’t know it …

All because your individual revenue buckets are simply too big.

Best practices for optimizing SKAN conversion models

As you work through your 3 or 6 or 9 different steps of getting to the perfect SKAN conversion model for your app, here are a few things to keep in mind.

  1. Keep at least one baseline event to ensure your conversion values make sense, and to get at least SOME signal if revenue doesn’t happen
  2. Ad revenue is a massive advantage: it’s very useful as a short-term early indicator. (Of course, this depends on your app and its category.)
  3. Creativity is critical. Think — and check the data — for user actions that are predictive of future revenue activity.
  4. And, again, revenue bucket ranges are critical for accuracy. Define these based on your observed user behavior, or try our recommended models.

You will arrive at a solid conversion model and you will get good data … if you’re persistent. It takes time and effort, so a little bit of patience is a good thing too!

Understanding privacy thresholds to maximize SKAN performance

None of the above matters if you don’t understand privacy thresholds in SKAdNetwork and optimize your campaigns to minimize data loss via censorship. Postbacks without conversion values give you some signal, but it is insufficient to optimize.

The SKAN framework decides whether or not to censor conversion values at time of install. It’s not related to what the user does or who the user is: it’s simply predicated on how many installs you’ve generated per SKAN campaign ID in the last 24 hours.

SKAN conversion values

You need at least 10-15 installs to get conversion values. Over 30 per SKAN campaign ID is better, and obviously, with more scale, you increase the percentage of SKAN installs that come with SKAN conversion values, thereby increasing accuracy.

SKAN daily install volume

As we’ve seen multiple times from multiple customers and partners, daily install volume is your friend when seeking to optimize the percentage of SKAN postbacks with conversion value payloads.

But there’s a catch.

Just because you have something classified internally as a single campaign doesn’t mean it shows up in the SKAN framework as a single campaign ID. Ad partners will often decompose a single campaign into multiple SKAN campaigns in order to test placements, creative, or other elements of your ads so that they can run their own optimization engines. Since censorship happens at the campaign ID level, this can reduce signal fast if you’re not pumping enough volume into each partner.

SKAN campaigns

The solution is communication.

Talk to your partners about how they break down campaigns into different SKAN IDs, and how much volume they typically distribute in each one. Use that data to inform how much volume to run with each partner. And, while this may take some juggling as you experiment with new partners, concentrate spend in periods of time to ensure maximum signal delivery.

One other thing: don’t panic.

SKAN performance

Performance might look like it really sucks early on in your SKAN journey. And it may not look amazing even when you become advanced SKAN users. But your true performance is almost certainly much higher than what it seems.

And you can see that with our modeled metrics.

Singular’s Advanced SKAN Analytics pulls back the curtain on censored values, estimates your missing conversions and revenue, and is completely upfront about the confidence intervals so you know exactly how much to trust the insights. This single step can increase your visible SKAdNetwork performance by 50%, which is absolutely huge and gives you the confidence to run performance marketing at scale on iOS, knowing what your return on investment is.

Two keys to keep confidence intervals tight and to improve the accuracy of your modeled metrics:

  1. Consolidate campaigns to reduce missing data due to privacy thresholds
  2. Use optimized conversion models to get more accurate inputs 

Bringing cohorts back to iOS

With easy IDFA access, mobile growth marketers had the ability to monitor cohort ROI and LTV performance over the long term. The biggest limitation of SKAN v3 is the incredibly short window: essentially 24 hours in most cases thanks to the optimization needs of ad partners.

That is just not enough time to really know how performant a campaign has been or how good a cohort of users it brought in. Longer cohorts give users more time to use your app, develop a habit, and convert into highly engaged paying customers. Just because a new player doesn’t buy something in your game immediately does not mean they won’t become one of your most valuable players down the road.

Time makes a huge difference in campaign analysis … often 2X to 5X just between D1 and D7!

cohort campaign analysis

Singular revives long cohorts on iOS by combining SKAdNetwork-derived conversion data with actual device-level data: what does SKAN say you did, informed by aggregated data about what actually happened in your app. The result is modeled data, with confidence intervals, showing what a particular SKAN campaign delivered in D7 revenue.

Bringing all your insight layers to life

Advanced mastery of SKAdNetwork requires bringing all of these insight layers together in one place. That includes:

  • Partners
  • Publisher apps
  • Campaign names
  • Foundational outputs
    • Cost
    • Impressions
    • SKAN-reported installs
  • SKAN basic insights layer
    • SKAN eCPI
    • SKAN revenue
    • SKAN ROI
  • SKAN Advanced Insights layer
    • Modeled metrics
      • Modeled SKAN revenue
      • Modeled SKAN D7 revenue
    • SKAN Cohorts
      • Modeled SKAN ROI
      • Modeled SKAN D7 ROI
SKAN insights

Now, at last, you have the tools you need to accurately assess the result of your iOS user acquisition campaigns. Now you have the data you need to make decisions about future growth.

Key indicators of advanced SKAN experts

SKAN experts consistently do 5 things that others don’t.

  1. Continuously test and iterate different mixes of conversion models
  2. Use optimized revenue buckets to increase model accuracy
  3. Rely on modeled metrics to overcome SKAN’s privacy thresholds
  4. Consolidate campaigns in case of high censorship rates
  5. Use modeled longer cohorts to understand your true ROI

It sounds simple when you put it in 5 steps. It’s really not, and some of the world’s best marketers and best mobile growth teams have struggled with SKAdNetwork like no other measurement framework ever before. 

But the good news is that there is light at the end of the SKAN performance tunnel. You can make SKAN function. And you can make SKAN-assisted attribution the foundation of high-performing mobile marketing.

But wait, there’s more on SKAN performance (later!)

Right up at the top of this way-too-long blog post, I said there were 3 levels of SKAdNetwork effectiveness. Readers who can count may have noticed that we’ve only covered 2 of them so far.

There’s a good reason for that, and it’s not only that I’m tired of writing such a long blog post, or that you’re tired of reading it. It’s simply that level 3 will come with SKAN 4 later this year. 

As you’ve heard, SKAN 4 is a massive change to SKAdNetwork. It’s also a massive upgrade, providing significantly more data (while remaining privacy-safe) and covering a significantly longer time frame. We’ve written a lot about SKAN 4 already, which you can check out in these blog posts:

We also did a deep dive on the details we know so far in a webinar format, which you can access right here.

But the reality in terms of leveling up with SKAN 4 performance is that it’s simply not here yet. It’s going to enable much more (and require much more), but we’ll have to share more about how to make it work and perform well after it’s released, not before.

In the meantime, check out these additional resources on SKAN:

I particularly recommend this one, straight from the experts at Rovio:

And … keep tuned

We are always working with our very best customers to reveal top techniques and insights on iOS attribution and everything else you need to do. Keep tuned to stay in the loop.

The ultimate guide to SKAdNetwork privacy thresholds

While privacy thresholds on conversion values are essential to making Apple’s SKAdNetwork mobile attribution framework actually privacy-safe, at the same time they are also one of the biggest challenges that prevent marketers from learning what’s working. Or, in other words, actually performing meaningful attribution that guides future decisions.

Which, clearly, makes the mobile growth job harder.

That said, the good news is that with the right data science and modeling tools, you can recapture much of the missing insight you need to optimize campaigns.

More on that later. First, in this ultimate guide to SKAdNetwork privacy thresholds, I want to share what we know so far about:

  • what they are
  • why they matter
  • how they work
  • what they impact
  • how they change ad network behavior
  • how to compensate for them

How SKAdNetwork privacy thresholds work

Apple built SKAN to ensure that while marketers get some information about the results of their mobile user acquisition campaigns, any device-level or personally identifiable data is fully permissioned. Unpermissioned data is aggregated: private by default because it’s not linked to any individual person or device.

Not only is the data that represents the results of app install marketing campaigns aggregated, some is censored. That’s simply because if marketers received aggregated data on small numbers of app installs, it wouldn’t be too hard, over time, to connect specific people and specific activities with specific ads and partners with a fairly high level of certainty.

This certainly increases privacy, but it also adds noise to the marketing impact signal that growth experts use to evaluate success and plan additional tactics.

When app marketers run SKAdNetwork-enabled campaigns on iOS, they get data from Apple’s devices on the results in an electronic package called a postback. The device sends postbacks to the ad networks that place ads that result in downloads as well as (optionally) to the developer of the app itself. MMPs like Singular get those postbacks either via reflection from the ad network or if advertisers designate Singular’s address as their collection point.

Here’s an example of a SKAN postback for an ad that worked, based on Apple’s documentation: it generated an app install, and whoever installed the app actually opened it and performed some action that the app developer has assigned a conversion value of “20.”

SKAN postback

You’ll notice that this comes from campaign-id #42. That’s important information: advertisers can now credit that campaign with the successful conversion and use it in their assessment of whether or not that ad campaign generated positive return on investment. 

You’ll also notice that the campaign delivered the ad in an app identified as “1234567891.” That data is in the “source-app-id” field, and it’s also important information: now marketers know that this publisher app aligned well enough with their target audience to find at least this one person who was interested enough by the ad and the advertiser app that it displayed, to click the ad and download the app.

Digging into SKAN postbacks

If the number of app installs per campaign ID falls below a number that Apple sets, there aren’t enough installs to camouflage the identities of all the new people showing up as users in your app. Even though you don’t have hard deterministic data on which click/ad/campaign delivered which user/conversion/purchase, you could make pretty good guesses.

So Apple censors the data, and here’s what that looks like:

SKAN postbacks

It’s important to note that even if you don’t pass the privacy thresholds, you still get an SKAdNetwork postback. However, two things will be missing:

  1. Source app ID
  2. Conversion value

That means you still get valuable deterministic data from SKAN for every single install. It’s less useful than with a conversion value and source ID attached, but it’s still important.

It’s also important to note that a conversion value of “0” doesn’t mean the data is censored. If Apple censors a conversion value, that field simply disappears from the SKAN postback as shown above, along with the source app ID. A conversion value of zero simply indicates a person who installed your app as part of a campaign that passed the privacy thresholds … but didn’t do too much after installing the app, and didn’t trigger an update to the conversion value according to whatever conversion logic you’ve set up. 

There’s other information in SKAdNetwork postbacks, including a flag on whether an app install is a redownload or a net new one and another for whether it’s a winning postback or losing postback, but more on that at another time.

Behind the scenes: how SKAdNetwork works

Behind the scenes several critical things happen that determine how and when SKAN postbacks get sent, and some of them impact privacy thresholds and conversion values.

Here’s the sequence:

  1. AdNetwork23 creates SKAN Campaign1 for App A
  2. AdNetwork23 creates an ad in Campaign1 for App A, and places it in app B
  3. Francine17 sees the ad while in app B, taps it, and installs app A
  4. As she does so, SKAdNetwork assess the number of installs currently happening from SKAN Campaign 1, and makes a decision
    1. There are enough installs: it will release the conversion value and source app ID
    2. There are too few installs: activate privacy thresholds
  5. SKAdNetwork follows the postback timer set up by App A’s marketers in the app
  6. When the timer runs out, SKAdNetwork sends up to 2 postbacks to up to 6 locations
    1. 1 ‘winner postback’ to winning ad network and, potentially, a designated server for the app publisher and/or MMP
    2. 1 ‘loser postback’ to as many as 5 other ad networks that showed ads that Francine17 saw, but did not lead to the actual app install
  7. Marketers collect their postbacks, generally via an MMP like Singular, and find out whether or not privacy thresholds have been implemented, censoring data.

The main point here is that since the privacy threshold decision happens at download time, the actual conversion value doesn’t affect the censorship in any way. Only the number of downloads controls that decision.

In practice, what this means is that the first few installs of a campaign don’t have conversion values. The App Store seems to count the number of installs that happened in the last 24 hours or so, and once they pass a specific number, privacy thresholds are removed and SKAdNetwork starts including conversion values and source app IDs.

How many does it take?

SKAN postbacks censored data

There appears to be some degree of randomness here, but privacy thresholds seem to be in effect for the first 10-20 installs of a campaign, decreasing thereafter as you scale install volume. And when you’re getting 100 installs per day, you usually see 100% CVs. There’s a sliding scale here up to that point, however: if you only have 15 app installs, you probably won’t get any conversion value data. If you have perhaps 30 installs, you’ll get about 50% of your conversion values.

But there’s a very important point to remember: this is the number of installs per SKAN Campaign ID.

SKAN Campaign ID

Your ad network growth partners will divide your campaigns up into multiple SKAN campaigns so they can do their own creative/placement/targeting optimization to maximize learning and therefore campaign ROI. A single ad network campaign can be made up of multiple SKAN campaign IDs – different SKAN campaign IDs can encode different creatives or targeting.

Maximizing data from SKAN

There are some implications of how Apple runs privacy thresholds here. 

For instance, traffic “bursts” can cause missing conversion values at high volume too. For instance, a sudden burst of 100 installs once every 48 hours will see some installs with missing conversion values on every burst … despite the fact that you’re largely clear of the danger territory where users might be identified and privacy broken. But driving just 30 installs spread throughout the day will likely only result in missing conversion values at the beginning of the campaign.

Only Apple really knows what the limits are here. Given the nature of cloud-enabled and sharded services, a massive global burst in a brief period of time might result in a higher censorship rate if you overwhelm SKAdNetwork’s ability to increment install counts coherently across all geos.

The best option, therefore, is maintaining a relatively steady momentum across all SKAN campaign IDs.

You also want to consider your ad partner mix and activation for iOS in the light of SKAN privacy thresholds. Even if you’re driving thousands of installs a day, splitting them up between 40 ad partners, each of which can run up to 100 SKAN campaign IDs, could result in significant loss of data. If you’ve got a smaller budget, focus on a few ad partners at a time (which can also help with incrementality and cohort analysis). Of course, if you’re driving tens of thousands of installs per day per app you have much less to worry about.

Here’s what we’re seeing so far:

SKAN Campaign ID

For example, Google recommends consolidating to just 8 or less app install campaigns, saying that “this helps maintain optimal performance within SKAdnetwork’s campaign limitations.” Adding more will degrade performance, Google says. Facebook recommends a minimum of 88 app installs per campaign per day, and says you should consider increasing budgets or combining ad sets and campaigns to reach that level.

Snap is close to that at 75 installs per day, while Unity is a bit of an outlier at just 30.

All these affect the number of conversion values to expect for your planned budget per network.

So: how do you optimize iOS campaigns for privacy thresholds?

First, monitor your conversion value rate. 

If it’s dropping below 50%, that’s not great. You want to see a conversion value rate of 80%, ideally. The higher the better, because that’s the data that Singular uses to model missing data as well as D7 revenue cohorts, and the more we have to feed the models, the more accurate modeling you’ll get.

SKAN report

Consolidate campaigns where needed to meet the minimal recommended threshold for each network. Again, the more data your ad partners have, the better their optimization can be as well, which will only help improve campaign results as well as campaign measurement.

And finally, use modeling to fill out the gaps.

Singular just released SKAN Advanced Analytics, which restores your ability to run high-performance iOS user acquisition campaigns by modeling missing data due to SKAN privacy thresholds and randomized postback timing. Customers using the private beta reached an impressive 87% D7 revenue prediction accuracy, and SKAN Advanced Analytics gives you back cohort data as well, thanks to sophisticated data science.

Becoming a SKAN expert is just essential if you want to drive significant growth on iOS right now, and using our modeled insights is a massive improvement on typical SKAN results.

Next step: get the definitive SKAN guide

We’ve put together a simple, direct, and to-the-point guide on the solutions for SKAN’s reporting gaps.

Get it here to unlock the secrets to using SKAdNetwork successfully, and start growing on iOS again.

Apple starts enforcing iOS 14 privacy policy by rejecting app updates; Singular not impacted

iOS 14.5 will probably drop very soon now as Apple has begun actual enforcement of iOS 14 privacy policies. The big clue: rejected updates for apps using measurement SDKs with fingerprinting.

The good news: Singular customers are not impacted.

(And no: this is not an April Fool’s joke.)

What’s the app approval problem?

Last night, mobile marketers started reporting that an unusual number of apps were being rejected. The cause: probabilistic attribution technology in embedded measurement SDKs. In other words, fingerprinting. In the rejection notices, Apple is saying that apps are collecting too much information which could be used to identify individuals and devices, violating the spirit of iOS 14’s App Tracking Transparency framework.

“Your app uses algorithmically converted device and usage data to create a unique identifier in order to track the user,” says one email we’ve seen. “The device information collected by your app may include some of the following: NSLocaleAlternateQuotationBeginDelimiterKey, NSTimeZone, NSLocaleGroupingSeparator, NSLocaleDecimalSeparator …”

The guideline in question is 5.1.2 on privacy and data sharing:

Image Source: Apple 

This should not be a surprise, and it should not be shocking. At Singular we’ve been warning about this for months.

What’s causing this, and who is impacted?

Right now what we know is that Adjust’s SDK is impacted. Other MMPs may be impacted as well, but we have no evidence of that.

We have not had a single app rejection for Singular customers, and there’s a good reason why: we’ve been very clear about fingerprinting not working as an IDFA substitute in iOS 14 without user permission from the very beginning. Using fingerprinting, we’ve said, is a good way to get your app kicked off the App Store.

Or, as it turns out, barred from being updated.

We can see the causes for the App Store updates being rejected, because Adjust’s SDK is open source on GitHub. And, as it turns out, their SDK just had a massive update in the past day: 36 changed files with 44 additions and 622 deletions.

Those deletions are full of fingerprinting technology:

  • NSString *persistedUuid = [ADJKeychain valueForKeychainKey:@”adjust_uuid” service:@”deviceInfo”];
  • (NSString *)adjDeviceId:(ADJDeviceInfo *)deviceInfo;
  • NSString *binaryHardwareName = [ADJUtil stringToBinaryString:hardwareName];
  • NSUInteger chargingStatus = [ADJSystemProfile chargingStatus];
  • NSUInteger batteryLevel = [ADJSystemProfile batteryLevel];
  • NSUInteger totalSpace = [ADJSystemProfile totalDiskSpace];
  • NSUInteger lastBootTime = [ADJSystemProfile lastBootTime];

Essentially, measurement partners who are collecting too much data — from hardware details to software versions to charging status and battery level to uptime — are problematic. All of that data allows you to form a very detailed representation of a very specific device and could be used to attribute installs and conversions and potentially track that device — and therefore that user — around the mobile ecosystem.

Right now, apps that are using SDKs that collect too much data are being rejected.

It’s important to note, however, that Apple is being restrained in iOS 14 privacy enforcement. They’re not kicking apps off the App Store; they are denying app updates. That’s disruptive to app publishers’ business, sure, but it’s a relatively minor disruption with a clear path to resolution. Apple could have been much more hard core here in ways that would have impacted app developers much more severely.

What about Singular?

At Singular we’ve been incredibly careful and conservative around what data we collect and how we ensure that stays compliant with Apple policies. In fact, sometimes we’ve wondered if we’ve gone too far … especially as we saw some MMPs apparently adding fingerprinting capabilities in preparation, perhaps, for losing the IDFA.

We are re-auditing our SDK just to be on the very, very, very safe side, and we’re continuing to monitor the situation very closely. As the first MMP to publicly announce support for SKAdNetwork on June 23, 2020, our goal has always been to be 100% aligned with Apple’s policies, and we believe we are. That ensures minimal to no disruption for our clients.

We’ll update this post as the situation evolves.

How to test SKAdNetwork: Step-by-step instructions

No IDFA? No problem. Continue to drive growth with Singular’s best-in-market SKAdNetwork solution. Click here to learn more!

Update: Originally published August 13, 2020. Updated most recently February 11, 2021 to reflect changes following the iOS 14 release and additional tips from Apple.

Since we announced our first-to-market support for SKAdNetwork and released our open-source code for its implementation, we’ve been collaborating with many advertisers, publishers, ad networks, and MMPs to integrate SKAdNetwork and start testing it.

We’ve received many questions and ideas in our Mobile Attribution Privacy (MAP) slack group, but one of the most common questions that I’ve personally been getting is how to test the framework and see actual postbacks from it – a task that many have been struggling with. Some have even started to suspect if it’s even working at all yet…

We can assure you that SKAdNetwork indeed works, and we’ve seen the live postbacks signed by Apple before our very eyes. And although it may be challenging to figure out initially, it’s definitely possible once you understand the details. So we wanted to share those tips to help you expedite the SKAdNetwork adoption and push the industry forward.

Important note:
If you’re an advertiser and a Singular client, then you don’t have to worry about any of this – we’ve got you covered. You simply need to upgrade to our latest SDK that we released as part of
Singular’s SKAdNetwork solution, and we’ll make sure that SKAdNetwork works behind the scenes.

To start, here’s a quick recap of the documented steps to get a postback in iOS 14, as summarized by Apple here:

  1. The Ad Network registers to SKAdNetwork and provides a signed ad to the publisher app
  2. The publisher app displays the ad by calling the loadProduct(withParameters:completionBlock:) method. It also must have the ad network ID (all lowercase) in its Info.plist
  3. The advertiser app calls registerAppForAdNetworkAttribution() and optionally updates a conversion value using updateConversionValue(_:)
  4. Once the 24-48 hour timer expires, a postback should be sent directly from the device to the registered SKAdNetwork endpoint

Note: For iOS 11.3 to 13.x, the postback timer is between 1 minute to 2 hours.

Apple iOS14 SKAdNetwork

Simple, right?

The problem starts when you don’t get the postback – you click the ad, download the app and launch it, wait for the timer to expire… and nothing. No error logs, no debugging tools, no way to know what went wrong. Try to repeat that process a few more times and it may drive you crazy.

But after running it again and again and using some intensive research tools, we’ve figured out all the necessary steps and summarized them all in the following definitive guide for how to get a live SKAdNetwork postback.

How to get a live SKAdNetwork postback

Step 1: Check your SKAdNetwork server endpoints

You need two endpoints to run an end-to-end test with SKAdNetwork:

  1. Ad Server – which generates the ad signatures and provides all the details to the publisher app
  2. Postback Server – which receives the signed postbacks from the device

The critical piece to note here is the Ad Server endpoint – your implementation should follow Apple’s steps for generating your signature very carefully because any small mistake or compatibility issue will cause the postback not to send.

A good practice here is to simulate how Apple would validate your signature – you can log the ad details just before displaying them, reconstruct the message, and validate its signature using your public key. We’ve noticed that when the generated signature was compatible with OpenSSL (by running the command-line below), that’s when we’ve passed that step successfully:

❯❯❯ openssl dgst -sha256 -verify public.pem -signature signature.bin message.bin

Verified OK

Step 2: Get a live Advertiser app in the App Store

This is probably intuitive since you have to provide an AppStore ID of a specific advertised app when calling loadProduct in the publisher app – you have to actually download the advertiser app from the production App Store to get an attributed postback.

Step 3: Get a live Publisher app

You can use a dev-signed Publisher app to test SKAdNetwork (loaded with Xcode to the device or distributed via TestFlight), and it doesn’t have to be live in the App Store to simulate a live postback.

Keep in mind that the source-app-id parameter in the SKAdNetwork v2.0 postback requires a production-signed app install – so if the publisher app isn’t downloaded from the App Store, the source-app-id parameter will always be 0.

Step 4: Get a physical device with the test profile

You will need a physical device to test SKAdNetwork since the iOS simulator doesn’t have access to the App Store.

Apple has released an SKAdNetwork Profile that you can install on your test device to reduce the postback timers from 24-48 hours to 5-10 minutes. This is very useful for debugging purposes. You can download it from your Apple developer account here:

Now, an important point worth highlighting is that SKAdNetwork has been supported since iOS 11.3, but support for redownloads has only been added in iOS 14 in Version 2.0. So if you’re testing a device with iOS 13, the postback will only be sent following the first install of the advertiser app.

The Ultimate SKAdNetwork Troubleshooting Guide

To summarize, here are some troubleshooting tips that may be useful to save you some debugging time:

  • First, double-check the Info.plist file in your publisher app, and make sure you have the ad network ID listed in lowercase.
  • Ensure that the loadProduct parameters are exactly what you’ve generated and signed in the Ad Server, since it can easily break if any of the parameters changed on their way. A good test would be to log the parameters just before displaying the ad and simulate Apple’s validation logic using your public key.
  • If you’re testing SKAdNetwork v1.0 on a pre-iOS 14 device, make sure this is the first time that this iTunes user has ever downloaded the advertised app. If not, you won’t be able to get its postback.
  • Keep in mind that it can take up to 48 hours to receive a postback from the device starting from the registerAppForAdNetworkAttribution() call or last updateConversionValue(_:) call. You can install Apple’s SKAdNetwork Profile to reduce the timer for debugging purposes.
  • Remember that the postback should always be sent directly from the device to the registered SKAdNetwork endpoint, but it will only include the conversion value and publisher ID in Version 2.0 if the parameters meet Apple’s privacy thresholds. If your publisher app is dev-signed, then Apple will ignore the privacy thresholds (identifying that this is a test) and always send the postback with source-app-id as 0 (zero).
  • New: ensure that your timestamps are in milliseconds, not seconds, or SKAdNetwork postbacks will not be sent. This is what Apple calls the key that represents the timestamp of an ad impression. It’s in UNIX format but based on milliseconds, not seconds as epoch is usually treated (which may be unintuitive). A brand we talked to set their timestamp in seconds and continually failed to receive postbacks until they updated to milliseconds.

Any questions or other recommendations? Send us feedback in our MAP Slack group, and we’ll update this post with new learnings!

Looks a bit daunting? Don’t worry! If you’re an advertiser, then it’s our job as an MMP to provide you a full solution using a simple SDK upgrade. Click here to schedule a call with our product team.

And if you’re an ad network, check our latest post on how to support the Secure SKAdNetwork solution with almost no effort!

SKAN: A practical standard for the implementation of SKAdNetwork

No IDFA? No problem. Continue to drive growth with Singular’s best-in-market SKAdNetwork solution. Click here to learn more!

Since we’ve announced our support for SKAdNetwork and released the open-source code for everyone to start exploring, we’ve received massive interest from the industry and had many conversations with top advertisers, publishers, ad networks and MMPs on its potential.

The industry, and we, are torn between accepting the likely loss of IDFA (that served so many positive and valuable use-cases) and getting ready for the new reality, one characterized with fragmented data, partial consent, on-device solutions and … SKAdNetwork.

SKAdNetwork has some benefits, but it also has some severe limitations, and we are actively participating in the development of alternative privacy-friendly methods with other players, and we would love to see them succeed.

Still, with so many unanswered questions and a nearing deadline, there is a void created that is currently being filled with uncertainty and confusion.

We believe that SKAdNetwork – whether we like it or not – will be part of that new reality. And in its current form, SKAdNetwork is a bare-bones framework that requires careful implementation and responsible governance between multiple entities in the ecosystem to ensure that it’s practical and useful.

That’s why we created SKAN. To try and give us a path forward in a land of uncertainty.

Introducing SKAN: A practical model for SKAdNetwork

Today, we’re excited to announce SKAN – a proposal for a standard implementation of SKAdNetwork. SKAN describes how SKAdNetwork should be used in a standardized way by the ecosystem to overcome some of its limitations and enable its adoption in a scalable and trustworthy way.

This spec is the result of many conversations with folks across the industry about the challenges and issues SKAdNetwork will present.

With SKAN, we are aiming to achieve the following:

  • Create a reference implementation plan for SKAdNetwork, to avoid fragmentation and a broken mobile advertising ecosystem.
  • Design a way for SKAdNetwork to be compatible with parallel methods like IDFA-based attribution (when consent is given).
  • Provide a way to centralize and manage the scattered SKAdNetwork postbacks.
  • Govern SKAdNetwork’s “conversion value” and define a standard implementation.
  • Provide a solution for the fraud risk presented in SKAdNetwork (such as the conversion value manipulation, repeating transaction ID attacks, and geo manipulation).
  • Define how marketers and ad networks can measure ROAS and other KPIs.
  • Define the infrastructure necessary for centralized reporting for advertisers.

Access the downloadable PDF of SKAN

Let’s collaborate

We invite everyone to join us and contribute to this spec. We’ve deliberately excluded our name, or any other company’s name from the spec, to encourage collaboration, suggestions, improvements, and most of all criticism.

We know that one player can not shape that future on their own. It’s like that old saying “it takes a village.” We will need to come together as an industry — advertisers, ad networks, publishers, and MMPs — to shape the future of marketing measurement… and we need to do it quickly with iOS 14 launching in September.

If you’d like to learn more, connect with other thought leaders, ask questions and participate in very lively discussions around IDFA and attribution privacy in general, we invite you to join the Mobile Attribution Privacy (MAP) Slack group: click here.

SKAdNetwork code: Singular releases Github repository with code for ad networks, publishers, advertisers

No IDFA? No problem. Continue to drive growth with Singular’s best-in-market SKAdNetwork solution. Click here to learn more!

 

Worried about how losing the IDFA will impact your business? Wondering how SKAdNetwork will work, and if it’ll be a viable replacement?

It’s understandable.

The IDFA is not dead yet, but it’s not dead yet in a very Monty Python way. This isn’t just a flesh wound for mobile marketing, and everyone has a lot of questions right now. Fortunately, Singular has been working on SKAdNetwork for over a year now, and we have at least some of the answers.

Plus, we’ve got your back.

Today, we’re releasing reference code for those who want to start experimenting with SKAdNetwork. This GitHub repo has sample code allowing ad networks, publishers, and advertisers to play with new SKAdNetwork capabilities and understand how they’re going to work for each party. The open-source code also demonstrates how an ad server could implement the cryptographic signatures required.

Singular was the first MMP to announce support for SKAdNetwork. Our goal is to make it scalable, simple, and seamless for mobile marketers to measure the impact of their campaigns in a privacy-safe way.

In addition, we will also release Singular’s updated SDK that works with SKAdNetwork plus more information about Singular’s ad network integration shortly.

It’s critical to get ready quickly because Apple is pushing for this to be used as widely as possible, and we expect the industry to shift to this model at some capacity. iOS 14 launches in September, and if we know anything about operating system updates on iOS it’s that they happen quickly: almost everyone updates within a month or two.

The code release contains:

  1. An advertiser sample app
  2. A publisher sample app
  3. A server that simulates an ad network API (including generating the cryptographic signatures required)

Using the code should help ad networks, publishers, and advertisers. We’ve been spending a long time looking into SKAdNetwork and we want to share our understanding so the industry can have an easier time moving forward and adopting this new tool.

Note: you will need to be using Xcode 12 to run the sample ads. Also, as we learn more and as Apple evolves SKAdNetwork, we’ll add to the code samples.

What to do now:

We invite you to watch our on-demand webinar iOS 14 & IDFA: What you need to know.
Join the Mobile Attribution Privacy (MAP) Slack group on IDFA, SKAdNetwork and iOS14.

 

Frequently asked questions about the California Consumer Privacy Act (CCPA)

The California Consumer Privacy Act of 2018, CCPA in short, is California’s new privacy law that grants California residents with new rights with respect to their personal information. It will go into effect on January 1, 2020, and is consequently top of mind for many businesses, especially for those that engage in online advertising.

Similar to GDPR, this new regulation requires that all companies collecting, accessing, and processing personal data for California residents must comply with new standards, that while similar to GDPR, introduce some new nuances.

To help address any common CCPA questions you may have, we’ve compiled the top FAQs for the CCPA. Please note that this document is not intended to be a comprehensive analysis of CCPA or guidance on whether it may apply to specific clients. We recommend that you reach out to your internal legal advisors to determine how CCPA may impact your business.

General CCPA FAQs

1. Is Singular a CCPA compliant service provider?

Yes — Singular complies entirely with the CCPA regulation. We can exercise any request received by our customers to provide or delete data, and our built-in mechanisms for managing consents easily allow compliance with Opt-out requests.

Built by security experts, Singular has always been security and privacy driven by design. We treat encryption, security, and privacy as core principles that determine how every new system is defined and built, and these are inherently embedded in the platform.

2. When is the CCPA coming into effect?

Jan 1st, 2020.

3. Who does the CCPA affect?

It applies to all companies processing and holding the personal data of California residents, also known in the regulation as California Consumers, regardless of the company’s location, and meets one or more of the following thresholds:

  • Has an annual gross revenue in excess of $25 million;
  • Annually buys, receives for commercial purposes, sells, or shares the personal information of 50,000 or more California consumers, households or devices; or
  • Derives 50% or more of its annual revenue from selling California consumers’ personal information

4. What are the key principles? 

The CCPA provides consumers with the following rights regarding their collected information:

  • The right to access data – Consumers may request a copy of the specific personal information collected about them in a readily useable format.
  • The right to know – Consumers have the right to know the categories of personal information a business has collected about them, from what sources information was collected, for what purposes the information was collected and used, as well as know about their data being sold or disclosed to a third party for any reason.
  • The right to delete – Consumers can request the deletion of their personal information collected by a business.
  • The right to opt-out – Consumers must be able to opt-out of the sale of their personal information.
  • The right to not be discriminated against for exercising CCPA rights – Consumers have the right not to be discriminated against when exercising any of the above rights.

5. What are the penalties for non-compliance?

The California Attorney General will first provide a business with 30 days’ notice to cure any noncompliance with the CCPA. If the business remains noncompliant after 30 days, it may be subject to fines. Violations of the CCPA are subject to a civil penalty not to exceed $2,500 per violation; intentional violations of the CCPA are liable for a civil penalty of up to $7,500 per violation.

6. What is the difference between a service provider and a business?

A service provider will handle the data it receives in relation to a particular customer, only to serve that particular customer and for no other secondary business purposes, neither for itself nor for any other customer, and for no purpose outside of the business relationship with the customer. On the other hand, a business may use the data it receives (however it receives it) for a business purpose.

7. Opt-in vs. opt-out?

This is presumably the biggest difference between GDPR and CCPA. While GDPR required all personal data processing to be “Opt-In”, CCPA talks about consumers and their rights to opt-out. Furthermore, there is CCPA specific language around Opt-Out applying only in cases of a business selling data, so the notion of Consent is quite different between GDPR and CCPA.

8. What about users under the age of 16?

For children under the age of 16, CCPA requires an explicit Opt-In, referred to as “Right to Opt-In” by the regulation. For children under the age of 13, a parent or guardian must affirmatively authorize the sale of information.

9. I’m not using Singular for attribution or event tracking. Does CCPA apply here?

If Singular doesn’t collect personal (user level) data for your users, it is not technically a Service Provider in the CCPA context.

10. Do you have an updated California Data Privacy Addendum I can sign?

Yes, please reach out to your Customer Success Manager to get our latest addendum created for CCPA.

11. What else is Singular doing around the CCPA?

Built by security experts, Singular has always been security and privacy driven by design. We treat encryption, security, and privacy as core principles that determine how every new system is defined and built, and these are inherently embedded in the platform.

We took great pride in preparing for GDPR which equipped our customers with easy to use interfaces, supporting both server-side and client-side requests. We are also pioneering a Mobile Attribution Privacy group called MAP, in close collaboration with leading ad networks and attribution providers, to further ensure privacy is constantly addressed as a first priority in the attribution space.

 

Looking for more information or have questions? Contact us at privacy@singular.net or dpo@singular.net

Disclaimer: The information provided by Singular is for informational purposes only and not for the purpose of providing legal advice. Please contact your attorney to obtain advice on specific issues or questions.

Mobile ad monetization solutions for traditional publishers: not just for gaming companies anymore

The business model of traditional publishers is facing a threat in every digital channel: both web and mobile. Mobile ad monetization can help.

On desktop web, instead of competing with Facebook and Google, publishers have decided to work with the big two in a revenue-sharing model. DoubleClick for Publishers (DFP) and Facebook Audience Network are the platforms that enable revenue sharing opportunity for the publishers.

The good thing on desktop mobile is that the number of publishers is large, but not anyone can have audiences at scale.

phone apps icons click validation

However, when it comes to mobile applications, every app is technically a publisher and can work with Google, Facebook, or other mediators to start serving ads. Also, there is very little entry cost and thus there are about 2.6 million apps published on Google Play so far, while Apple’s App Store reports 1.8 million apps.

So mobile ad monetization is more challenging.

Freemium gaming apps are one of the most popular category of apps. Since they’re free to play and have huge audiences, they’re ideal for ad-based monetization. So these apps compete with traditional publishers for advertising inventory. Importantly, they have built engagement hooks to keep users playing either for hours or for a couple of minutes multiple times through the day … and they keep their users coming back day after day after day.

Even worse for traditional publishers, many gaming companies are actively spending on user acquisition — in some cases to the tune of tens of thousands of dollars daily — showing that there is significant ability to make revenue on advertising even with paid acquisition.

That means that traditional publishers who are competing on mobile are struggling to maintain the financial success which they see in web and mobile web inventory. Their mobile ad monetization isn’t super-strong. And their competition — mobile game publishers — is winning in the mobile app space by paying to acquire users … and then deeply engaging their users and successfully monetizing their apps.

How can Singular help?

Mobile gaming companies win by spending to acquire users and using sophisticated tools — like Singular — to measure, optimize, and monetize those users.

If content publishers take a page out of their playbook and expand their user base by spending to acquire users (or: readers, viewers, customers) then they have an opportunity monetize a larger userbase as well.

Singular can help track the complete journey, which is:

Campaign spend >> Installs >> Revenue

In the revenue funnel the high-level reporting will look something like the following, with sources of new users (readers, viewers, customers), marketing campaigns, results (measured in installs of your app), cost, revenue, and revenue per user.

Ad Monetization Analytics
Singular’s Ad Monetization Analytics

Content publishers will also be able to see their ROI, return on ad spend, and numerous other data on the effectiveness of their creative and much more.

This daily reporting will provide publishers with exact revenue made at an average session level: exactly what you need for mobile ad monetization.

Looking for user-level data?

Singular’s Ad Monetization Analytics offers multiple different ways to measure, track, and report ad monetization revenue from a cohort basis to a calculated per-user basis, and even — depending on your ad partners — actual user-level revenue data.

How does Singular do this?

ad-monetization-combining

The Singular platform integrates with thousands of advertising sources for granular data aggregation, keeping publishers informed about the campaign spend and cost. In addition, our attribution service identifies which campaigns are delivering actual app installs and are successfully expanding the total audience for the publisher.

And finally, Singular’s ad monetization integrations bring in detailed revenue data for mediation engines like IronSource and partners like MoPub, providing insight into metrics like revenue per user and average revenue per session.

Optimize revenue reporting

Singular’s Ad Monetization Analytics allows publishers to analyze the revenue reporting for ad-based revenue of apps. In addition, that reporting allows you to break down the data for further analysis by revenue sources and right to the ad placement ID.

For an ad ops team there are innumerable insights available related to the number of ad requests, filled ad requests, and fill rate. That allows them to fine tune ad delivery and provides critical feedback about lost revenue opportunities.

revenue-reporting-mobile

Integrations for ad monetization

Finally, Singular offers Ad Monetization Analytics regardless of which ad networks you choose to use.

But if you use IronSource, we can pull in user-level revenue data from Ironsource’s mediation platform and connect it to your cost data. If you use MoPub, Singular’s integration offers impression-level revenue data. And if you choose to use a third-party ad revenue calculation service like Soomla, we integrate with them and pull in their data for analysis along with your campaign spend, providing ROI and ROAS calculations.

Which essentially means: you’re covered, no matter which direction you go.