Why your MMP still isn’t iOS 14 safe

Is your mobile measurement partner creating risk for your business?

That’s a question every major mobile developer on the planet has to ask right now.

Last week we witnessed a massive event with Apple rejecting apps due to a measurement SDK that violated Apple’s privacy rules. Ever since the release of AppTrackingTransparency, much of the discussion has been around enforcement, and more specifically: will Apple really enforce their policies, even when it comes to hard-to-identify violations like fingerprinting?

I think that after last week, we got the answer that Apple is dead serious, and companies interpreting their policies in naive ways, or simply ignoring them, will be paying a price.

As we enter a new era of marketing attribution on mobile, courtesy of Apple’s iOS 14, I thought it would be helpful to share how Singular interprets the rules, how our competitors see it, and share some tips on how to avoid getting your app kicked from the app store.

First: what Apple wants

While we can’t speak for Apple, we believe it’s been very clear that Apple has staked its brand on the promise of privacy.

With the introduction of iOS 14, and the AppTrackingTransparency framework, Apple clearly stated that brands or ad-tech companies who want to track devices or users, must obtain explicit permission. Absent that permission, Apple has provided a framework called SKAdNetwork, which is their answer to a privacy-safe form of marketing attribution.

In the past, discussions around privacy mostly revolved around the IDFA and it’s deprecation, since it has been the key identifier for tracking. With ATT however, Apple has actually broadened the scope of tracking, and stated multiple times that the technology you use does not matter. 

The tracking is what matters.

Very recently and in an unusual move, coinciding with some app update rejections, Apple sent a reminder to its developers, reiterated that ATT is indeed coming and reinforced to developers what should happen when you fail to receive the user’s permission to track:

“Unless you receive permission from the user to enable tracking, the device’s advertising identifier value will be all zeros and you may not track them.”

– Apple

The “and” is critical here. It’s not just a case of asking for permission to the IDFA and if you fail to get it — find another way to track them. It’s asking for permission to do any form of tracking, and failing to get it means “you may not track them”.

By any method available.

Every MMP’s response to Apple’s guidelines

While Apple is becoming more clear and direct about their intentions, MMPs have been interpreting Apple’s intentions quite differently from one another.

Here’s what all the MMPs agree about when it comes to iOS 14.5:

  1. Every MMP still supports IDFA-based attribution when ATT permission is granted
  2. Every MMP will support SKAdNetwork, to varying degrees and with varying quality

Aside from these points however, you will start finding different interpretations among the MMPs.

I believe those different interpretations were a natural product of the chasm we’re all crossing ever since the announcement of ATT in WWDC 2020, and in this chasm, companies have encountered a lot of gaps:

  • Gaps with the SKAdNetwork solution and the market readiness
  • Gaps with Apple’s vague/confusing guidelines
  • Gaps with how monumental and disruptive this shift could be for advertisers and the entire app ecosystem 

To provide more color, let’s walk through where each MMP is right now (April 12th 2021), as best we can determine.

AppsFlyer

AppsFlyer supports SKAdNetwork, but considers it insufficient. As such, they have launched an alternative measurement solution to overcome the gaps of SKAdNetwork, which they call “Aggregated Advanced Privacy” (AAP). AAP provides WAY more granular measurement than what SKAN offers, and AppsFlyer claims that the solution “aims to prevent cross-site tracking and the ability to uniquely identify a user or device.”.

The use of the word “aims” is critical here.

Essentially, Advanced Aggregate Privacy utilizes fingerprinting to enable user-level attribution with some margin of error (hence: “probabilistic”). The user-level data is kept internally in AppsFlyer’s servers, and the output (postbacks / reports) is redacted before being sent out to Advertisers (AppsFlyer’s customers) and Ad Networks (AppsFlyer’s partners).

AppsFlyer’s documentation explains how they redact data, and the excerpt below shows what they do to partner postbacks before sending them out:



While I think AAP is a cool concept, I think there are some fatal flaws in it:

  1. AppsFlyer’s partner postbacks include fields like: Campaign Name, Campaign ID, Creative Name, Creative ID, Event Name, Site ID, Sub-Site ID, Ad ID, Ad Set Name, Ad Set ID.

    This means that AAP provides unlimited granularity with any campaign ID, Creative ID and event name you’d like. Which is one of the main appeals of the solution… but will it fly with Apple?

    My opinion is simple: NO.

    It’s no accident that Apple’s SKAdNetwork limits you to 100 campaign IDs, and a single conversion event with a value of 0-63. In contrast, AppsFlyer’s postbacks include unlimited identifiers that enable much higher granularity of measurement, tracking, and attribution, that very easily can point to a specific device and user.

    A limited number of campaigns automatically reduces (and even eliminates, when combined with privacy thresholds) the chance that an individual user will be tracked without their permission. If you enable an unlimited number, you can essentially track people. For example: you could theoretically map every email address you have to a number, and then register each ad click as one of 100+ million campaigns.

    That’s an extreme case, granted. But it’s possible, and as such, we believe it’s against what Apple is trying to prevent.
  2. Apple has never reviewed this solution, validated it upholds their standards, or certified it. The above example would more than be enough for them to rule against this solution.

    In fact, Apple has not certified anyone but themselves to provide a privacy preserving solution. If they do, we would be thrilled, and trust me we have tried to suggest countless ideas to them, but their narrative has been the same: stick to SKAdNetwork, and we can explore alternatives and improvements later.
  3. I believe that perhaps the biggest flaw here is not whether partners or advertisers can exploit this, but the fact that there is an entity, AppsFlyer, that will be performing tracking on iOS users without consent.

    And while we can sit here and debate about whether their output is “privacy preserving,” based on Apple’s POV, one could claim their entire data set itself is obtained incorrectly, and the information is tainted, even if it’s aggregated and anonymized.

AppsFlyer’s response to this is that their probabilistic matching is only 90% accurate, and therefore not “uniquely identifying a device”, therefore not breaking Apple’s guidelines, but I believe that’s over-reaching, and Apple has clarified, and will continue to clarify that this is a clear violation.

Adjust

Adjust (which has recently been acquired by the ad network and gaming publishing giant AppLovin), was the provider whose SDK got rejected by Apple in a few app updates. They’ve since updated their SDK and removed some problematic code, and app approvals are proceeding again.

The data Adjust’s SDK initially requested included battery status, location and locale data, uptime, and a variety of other system profile parameters, which Apple said creates a unique identifier. Adjust CEO Paul Muller said the data was being collected for fraud protection purposes, and that the company has “never used these symbols for this purpose.”

Be that as it may, Adjust sees 3 main attribution methodologies going forward, Muller says.

  1. SKAdNetwork
  2. Deterministic Attribution based on ATT consent to sharing IDFA
  3. Probabilistic Attribution based on “basic device information” (AKA fingerprinting)


Honestly, I find this surprising, to put it lightly. Apple had literally just rejected the Adjust SDK for “algorithmically converting device and usage data to create a unique identifier in order to track the user.”, and yet Adjust reiterates their intention to continue utilizing device information for tracking purposes.

The immediate pushback we’re hearing from supporters of this approach is that fingerprinting is only 90% accurate. (Similar to what AppsFlyer has been saying). The thing is – if you are 90% correct, those 90% of the users are still tracked without their consent, so that argument seems quite invalid to me.

This silly claim is derived from taking a single line of Apple’s developer FAQ out of context. Apple says that “you may not derive data from a device for the purpose of uniquely identifying it.”, and the over-reaching interpretation is that “fingerprinting is not really uniquely identifying a device” … at least not very accurately.Honestly, I just don’t see how this is going to fly.

Branch and Kochava

I’m lumping Branch and Kochava here together because they have remarkably similar story arcs with regard to SKAdNetwork.

Originally – both were huge proponents of building massive billion-plus device graphs or data collectives using IDFA and fingerprinting. And both, after some time, have internalized Apple’s messaging and swung away from fingerprinting towards SKAdNetwork.

As Kochava said recently, “Apple has drawn a line in the sand, removing ambiguity and bringing specificity where it was previously lacking.” And that MMPs that cross this line are putting their customers’ businesses in jeopardy.

Branch is clearly on the same page, saying that “it’s absolutely clear that if a user has not accepted ATT, no one – not even the advertising app or its CRM tools – can attempt to join an app install to an advertising click for attribution. They must use Apple’s SKAdNetwork (SKAN) framework or get permission via ATT.”

Both Kochava and Branch, therefore, appear to be adhering to Apple’s rules: both the letter and the spirit of the law.

Singular

Every mobile marketer who’s paying attention to iOS 14 knows what Singular’s stance is on this, and knows what my stance is.

We started working on privacy-safe attribution a year before iOS 14 was released. We were the first MMP to announce support for SKAdNetwork. In June 2020 we said fingerprinting was antithetical to what Apple was doing. In November we said using fingerprinting for tracking was a good way to get your app kicked off the iOS App Store. And we have reiterated it multiple times since.

Instead of fighting the policy, inventing shaky workarounds, or trying to do something under the table, Singular has thrown its weight behind compliant solutions and invested in building the best, most secure, and most complete SKAdNetwork solution on the market. One which will allow mobile app publishers to safely live on the App Store and allow mobile app marketers to continue to optimize for growth.

I firmly believe that.

Singular’s SKAdNetwork solution incorporates:

  • Best-in-class analytics with ROAS and cohorts for SKAdNetwork
  • World-class automatic conversion management and amazing SKAdNetwork conversion strategy testing
  • Tough anti-fraud measures with Secure-SKAN (we were the first to pioneer using 307 redirects to get raw device data)
  • Centralized data with everything else you’re measuring
  • All available on-platform, via API, or via ETL

And all with full compliance with platform guidelines from Apple, which means worry-free app updating. There’s a reason Rovio and countless other massive mobile publishers are choosing Singular.

The cat and mouse game

That cat and mouse game that we’re seeing played out in public here is one of privacy and enforcement. Everyone can technically do fingerprinting. Everyone can technically do some form of probabilistic marketing measurement, device tracking, user targeting, and more.

But what will Apple, ultimately, allow?

In a recent article, David Philippson, once the CEO of one of the first MMPs (Ad-X) and now the CEO of DataSeat said:

“As fingerprinting gives marketers a far superior solution to that offered by Apple SKA, who would adopt SKA if they were still allowed to fingerprint? We suspect no one. Which is the exact reason we should all prepare ourselves for Apple to act quickly and aggressively to enforce a ban on fingerprinting shortly after ATT.”

I completely agree with that. If you could get away with fingerprinting via Adjust or AppsFlyer, why on earth would anyone adopt SKAdNetwork? That’s a whole lot of work for something that will, in most cases, get you less data than fingerprinting. And if that’s the case, I doubt Apple would leave it up to chance. They will act strongly and quickly.

In a recent interview with Kara Swisher of the NY Times, Apple CEO Tim Cook said that “privacy is one of the top issues of the 21st century” and that “we’re in a crisis.” He also said that Steve Jobs believed that individuals should own their own data and own the ability to say who gets it, what they get, and how they use it. Specifically about ATT, Tim Cook said it’s about limiting the ability of companies to track people, create profiles of them, and surveil them across the internet. 

It could not be more clear, therefore, what principles are at stake for Apple. And that means that fingerprinting, already banned by policy, likely has a limited technology-enabled life span.

What AppsFlyer and Adjust are doing, in my opinion, breaks App Tracking Transparency. It’s pretty clear that it goes against what Apple is telling us, and therefore it’s only a matter of time until Apple takes action.

Our goal is to help our customers succeed. We’re building the technology and engaging with the ecosystem in ways that enable that as opposed to risking it. And that’s what we’re going to continue to do.

Charting your iOS 14 course?

You have to chart your course in the emerging world of privacy-safe marketing measurement. We’ve been helping brands and publishers get ready for months now.

If you’d like to chat, we’re here to talk.

Apple on SKAdNetwork: View-through attribution, fingerprinting, and app-to-web measurement

Today is Data Privacy Day, and Apple has released a huge amount of new information about what it’s doing around privacy, transparency, and how iOS 14 will give people unprecedented control over which apps and services can collect and share their data. Now we know that the very next iOS 14 beta (14.5) will include the App Tracking Transparency pop-up requirement, and the next full iOS version will release it to the public. That’s probably a March time-frame.

All of this is huge.

And a lot of it settles major debates in the industry.

Fingerprinting and ATT on iOS 14.5

Starting with iOS 14.5, Singular will not support probabilistic matching or fingerprinting.

For us, the writing was on the wall.

We knew it last summer. We said it again, and again, and again … including in this blog post about 10 ways to get your app banned from the iOS App Store. Instead of wishing that fingerprinting would stick around and investing in something fundamentally flawed from a privacy standpoint, we treated fingerprinting as a “dead man walking” and decided our best investment was to put our full weight and innovation behind SKAdNetwork.

As a result of that decision, we are offering our customers the most advanced SKAdNetwork solution in the market. Coupled with Apple’s intention to keep evolving SKAdNetwork, we wholeheartedly believe marketers will continue to drive effective user acquisition and growth for their businesses on iOS 14 and beyond.

We’ve already launched SKAdNetwork integrations with major partners like ironSource, Snap, Vungle, Unity, Liftoff, and more, and are continuing to roll out new integrations weekly. Thanks to Facebook’s recent announcements and Google’s update from a few days ago, we know we’ll be ready to support our customers there.

The upshot: Singular customers can be assured that they will be fully able to measure iOS conversions via SKAdNetwork on all major platforms.

When it comes to the past six months of confusion around fingerprinting – even though Apple had a consistent message for the past two years – there always seemed to be a few loopholes or unclear language that created hope that fingerprinting would be allowed, or that enforcement would be impossible. That perceived lack of clarity led to a lot of confusion around fingerprinting.

Today, however, Apple laid it out in black and white, once and for all.

With the latest update to Apple’s FAQ, fingerprinting or probabilistic matching is definitely out. Apple is even calling out IP address (“user’s network connection”) and User-Agent (“user’s web browser”) — which are the base parameters for probabilistic matching — and calls their utilization tracking.

Up until today, some companies in our space thought that they would be able to use fingerprinting to provide mobile attribution services without an IDFA and without asking users for tracking permission via ATT. While we immediately adopted and built a solution around SKAdNetwork, some continued to build device graphs and data marketplaces.

Today, clearly, that all ends. (And you’ll see announcements from all the industry players who are finally admitting that. In some cases, those announcements are a complete 180-degree turn from previous statements.)

It doesn’t matter if your fingerprinting is only 90% accurate. It doesn’t matter if you’re just using it once to connect a click and a device. It doesn’t matter if you hash the data to provide some level of obfuscation or privacy. Apple has very clearly laid it out: fingerprinting is not OK.

View-through attribution and creative optimization in SKAdnetwork

Another huge update for app marketers is that SKAdNetwork, Apple’s solution for privacy-safe deterministic mobile attribution, will now include view-through attribution (VTA)!

Singular was the first mobile measurement partner to adopt SKAdNetwork, and we’re fans of the concept, but we can’t ignore that SKAdNetwork 2.0 clearly has some drawbacks still. One of the most notable gaps in the first version was the lack of support for view-through attribution. Getting it back is great news for marketers and publishers alike. Apple’s language suggests that marketers will be able to measure creative performance, which is also new and exciting.

It’s still unclear exactly how SKAdNetwork will implement impression tracking, and how Apple will verify that publishers aren’t just reporting fake “impressions” to SKAdNetwork and therefore stealing attribution credit. I envision there might be some secure container that ad networks must use to show ads, and Apple may also start to verify viewability.

It’s also unclear whether this VTA support will work for all types of ads (e.g. text). We assume it will, but it’s not entirely clear since the text specifically highlights video, audio, and interactive ads.

Further complexity ahead: App-to-web

Finally, Apple shared their plan on introducing “private click measurement,” which is a concept developed as part of WebKit’s ITP. Interestingly enough, Apple plans on using it to enable more private measurement for “app-to-web” flows.

Today the “app-to-web” flow is easily measured with UTM params, but is not as private. Apple’s will fortify this data flow as well, and it’ll have a big impact on web analytics software that will have to adapt in order to capture users that come from a mobile app.

Perhaps most importantly: Apple is listening

But there’s something much more important than just getting view-through attribution back in today’s announcement, or getting 100% clarity on fingerprinting.

Apple’s announcement means that Apple is listening. Listening to the market. Listening to marketers. Listening to app developers and publishers who need to let the world know about their offerings.

That matters, because it means that while Apple is not going to compromise people’s privacy for marketing purposes, Apple does care that the publishers, brands, and companies that do business on its platforms are able to continue their operations.

There’s a lot more to talk about

Keep tuned to the Singular blog over the next week. We’ll be updating with additional insights on fingerprinting, SDKs, ATT, SKAdNetwork, and the role of MMPs.

Interested in learning how Singular can help you stay privacy-compliant and grow your business in a post-IDFA world? Talk to an expert.

Key takeaways from Facebook’s major iOS 14 updates today

Facebook released two major updates today in the form of blog posts.

One was an update to a general iOS 14 developer guideline, and the other was a brand new article talking about iOS 14 mobile web measurement that was quite surprising and revealing on its own.

There are lots of golden nuggets in both, but because we’re all impatient readers (I know I am), here are the most important changes and insights right upfront. I’ll add my analysis on each below.

  1. MMPs, SANs, and SKAN
    Facebook is releasing their work on the Facebook SKAdNetwork integration with MMPs, highlighting the collaboration with MMPs as a critical component. MMPs will continue to be the peacekeepers during the SKAN era.
  2. IDFA permission pop-up in Facebook apps
    Facebook said for the first time they will implement the App Tracking Transparency popup. This is huge.
  3. Mobile web impact
    Mobile Web advertising (FB Native App -> Advertiser’s Website) is being affected. That one is a really big surprise since most assumed there wouldn’t be any impact.
  4. Single sign-on via Facebook
    Facebook’s SDK will offer the company’s Single Sign On (SSO) capability in a way that will keep working even if people opt out of IDFA tracking.
  5. Number of ad campaigns
    Facebook released more details on SKAdNetwork ad sets functionality and limitations: Advertisers can have 9 campaigns with 5 ad sets per campaign, meaning you’ll have 45 permutations.
  6. Attribution windows, MAI and AEO: changes
    Seven-day, 14-day, and 28-day attribution windows are dead. But MAI (mobile app install) campaigns and AEO (app event optimization) will be supported.

Before we dive in deeper:

If you are reading this and are curious about iOS 14 and want some help with your technology and/or marketing strategy, we are here to help and we would be happy to talk to you. Click here to schedule a demo with one of our experts.

The MMP’s role

If you heard me speak about iOS 14 in the last 6 months (in any of the gazillion webinars, podcasts, panels, fireside chats we’ve hosted or participated in) – you’ve seen that our view about MMPs was consistent: the measurement world is complex, now more than ever, and marketers will still need help.

Despite having less granularity to work with due to IDFA being restricted (but perhaps not dead, keep reading!), the world of SKAdNetwork is super complex, and advertisers will need help navigating this maze, especially since SKAdNetwork conversion models must be a global setting across all ad partners.

Today Facebook clearly laid out their plans. We’re excited because we’ve been collaborating with Facebook (and many others) for a while on Singular SKAN that allows advertisers to have a single SDK, a single reporting infrastructure, and a centralized SKAN conversion model that can be utilized across all partners.

(You can read more details here about our partnership with Facebook)

Facebook is now implementing ATT

Facebook’s decision to show the AppTrackingTransparency popup for their customers is a pivotal moment in the iOS 14 saga:

  • Major precedent
    Facebook is setting a precedent. They’re the first really big company to declare they’ll support it, and this could encourage other developers to follow suit.
  • Huge consumer familiarity and education
    Facebook has massive penetration, which means that billions of smartphone users will start getting used to this pop-up, and that might increase overall opt-in rates (similar to how all of us are used to seeing prompts for location sharing or push notification permission).
  • Trusted brands gain a data advantage
    If Facebook users choose to opt-in for tracking en masse, that gives Facebook a data advantage that could help the company be a preferred media partner for advertisers.

Obviously, the big question is whether Facebook and Instagram will get good opt-in rates. I tend to think that the general population does trust Facebook, though some in the tech community might disagree with me.

App to Web flows: new and interesting complexities

Changes in-app to web flows were quite surprising, as many assumed app to web campaigns would be safe from any impact. As it turns out, that is not entirely the case: ATT will have an impact on web campaigns.

However, the link is not trivial.

I’ll try to explain it here, but please note that this is my current theory on some of the reasons behind Facebook’s changes. As we all know, this space is evolving very quickly, and things could change.

First, let’s look at the advertiser’s setup

  • On web campaigns, Facebook’s iOS App will serve ads that point to the advertiser’s website.
  • The standard practice for tracking web campaigns is through URL parameters (UTM parameters or custom ones). Facebook supports dynamic URL parameters such as {campaign.id} and {adset.id} that gives you extreme granularity at the point of click.
  • Unlike mobile app ads, when someone clicks on a website ad, they go to the website directly, and that click carries the attribution information with it. This enables the website owner to perform extremely accurate attribution.
  • Advertisers then use Facebook pixels on their website to track conversions. These pixels rely on “fbclid,” or their third-party facebook.com cookie to identify the user visiting the advertiser’s website to the actual Facebook user

Now looking at the user flow:

  • Bob opens the Instagram app, sees the ATT popup, and clicks “No”
  • Bob sees an ad on his Instagram feed from “really-nice-shoes.com”
  • Bob clicks on the ad, and his mobile browser navigates to really-nice-shoes.com with some URL parameters attached (including the fbclid parameter)
  • Bob buys the shoes
  • really-nice-shoes.com uses the Facebook pixel to send Facebook the conversion data
  • At this point, Facebook now knows that Bob bought shoes, but technically they’re not supposed to since he declined the ATT popup

As such, Facebook decided to make changes to prevent cases where they “accidentally track” customers who opted out of tracking on iOS. This greatly limits the ability of Facebook to receive web conversion events and optimize these web campaigns.

Interestingly enough, this creates a really unusual asymmetry since the advertiser will still get super-granular attribution by utilizing UTM parameters and storing that information in a first-party cookie. The only limitation is that they can’t pass it back to Facebook (and it’s rare that advertisers have more data than Facebook). I wonder if Apple will ask Facebook (and other apps) not to pass any data on web URLs coming from their apps (not sure it’s possible to control and audit that…).

(Note: Apple is also trying to address this from another angle with Webkit and ITP – see this article Ad Click Attribution on the Web. So it’s possible we’ll see more from Apple here in subsequent months and years.)

Other updates

  • Facebook will offer their SSO functionality (single sign-on) under the same SDK, but will build mechanisms not to use that data in any way if the user did not opt-in for tracking.

I’d be curious to see what Facebook would be allowed to send off the device, because some of it must be sent for SSO to work, and Apple does acknowledge that as a legitimate use-case.

  • You don’t need a separate Facebook Ad Account for iOS 14 campaigns, but you can’t have multiple ad accounts for the same app
  • Advertisers can have up to 9 campaigns and 5 ad sets each: 45 permutations. Facebook says the SKAdNetwork data they receive is aggregated at the Facebook campaign level, and that and reporting on adset/ad will be “modeled.” So, it’s possible that not all 45 permutations of campaign to adset are mapped 1:1 to the SKAdNetwork campaign_id parameter.

There’s obviously a lot to dig into here, and things are likely to still evolve somewhat well into January 2021. Keep tuned to the Singular blog and our mobile attribution privacy Slack group for more updates and live discussions.

 

Singular selected as a finalist for App Growth Awards 2020

We are beyond pleased to share that Singular has been selected as a finalist for the App Growth Awards 2020 in the App Analytics Platform category.

The App Growth Awards are presented by App Promotion Summit, and include finalists such as App Annie, SensorTower, MoPub, and much more in 20 categories, including app store optimization, innovation, engagement, data, and analytics. There are also categories for best campaigns on Facebook, Google, Apple Search Ads, Snap, and TikTok.

Singular is nominated in the analytics category, where the award is given to “the mobile analytics, app analytics, ad tracking and attribution platform that has delivered the most value and understanding of big data analytics in the past 12 months.” It’s a broad category, but we’re happy to be part of it.

“Our international panel of 20 expert judges whittled down over 250 submissions from around the globe to 62 finalists in 20 different categories,” App Promotion Summit says. “The vast array of entries from a myriad of companies highlights the growing size of an increasingly sophisticated app growth ecosystem.”

One thing we’re particularly proud of in 2020?

Singular built the industry’s first-to-market support for SKAdNetwork, Singular SKAN, making it scalable, simple, and seamless for mobile marketers.

As you know, MMPs are designed to provide unbiased third-party measurement of your mobile marketing efforts. Up to now, much of that promise was facilitated with the aid of mobile ad identifiers like Apple’s IDFA on iOS and GAID (Google’s Advertising ID) for Android. Moving forward, we face a significant challenge: finding new ways to keep that promise and help marketers optimize their campaigns … while preserving end-user privacy. Singular is leading that charge, and it’s great to see even more external validation of that effort.

There’s been a lot going on in 2020, but one other thing we’re thankful for is the opportunity to deliver class-leading fraud prevention for mobile app marketers. This has been a game-changer for clients who have literally saved six figures, and as we see massive new sources of potential fraud opening up, we’re continuing to innovate on this front.

There’s a lot of change coming, but marketers have dealt with change before, and we’ll continue to deal with it in the future. Based on what we’ve already shipped and are continuing to deliver, we have no fear that mobile marketers will continue to be able to get smart insights for out-sized growth.

Huge thanks to the App Promotion Summit for recognizing Singular as a finalist. Ultimately, the only reward we seek for our efforts is the continued success of our clients.

But it’s always nice to get a pat on the back once in a while too.

 

Apple’s IDFA gift: More time to prepare for SKAdNetwork (so don’t waste it!)

As the whole mobile marketing world has heard by now, Apple is delaying the implementation of some of the privacy measures in iOS 14. And we’ve also confirmed: the IDFA is available in iOS 14 beta 7.

This is great news.

While we were the first to support SKAdNetwork officially and openly advocate for it, the reality is that a huge percentage of mobile publishers and marketers are just not ready yet. And as we just saw from Facebook, the consequences of the shift to per-app opt-in for IDFA were monumental.

So getting more time to prepare is valuable.

But make no mistake: Apple is 100% committed to privacy. Here’s the company’s announcement with the details of the delay (emphasis added):

“Apps will be required to receive user permission to track users across apps or websites owned by other companies, or to access the device’s advertising identifier. We are committed to ensuring users can choose whether or not they allow an app to track them. To give developers time to make necessary changes, apps will be required to obtain permission to track users starting early next year. More information, including an update to the App Store Review Guidelines, will follow this fall.”

Given that reality, we remain committed to SKAdnetwork. But mobile marketers in general and our customers specifically should know that this is not just because it’s about to become the only game in town and there are no alternatives. As we continue to build out our Singular SKAdnetwork solution, we are more and more convinced that mobile marketers can effectively grow and optimize marketing campaigns at scale with SKAdNetwork.

We’re talking ROAS. We’re talking predictive LTV. We’re talking all the goodies that you need to know how your marketing is performing. Minus, of course, granularity on individuals and creatives.

Our message to the market right now is clear: get ready.

Use this time to prepare.

SKAdNetwork is still coming. IDFA is still (mostly) going away. You now have perhaps a five-month gift from Apple, and the question is: how are you going to use it? Our recommendation is that you implement (we can help). That you test (we can also help with that). You can test IDFA opt-in. You can test ROAS measurement. You can test LTV and predictive LTV measurement to guide marketing investments. You can test cohorts, and different ways of using the six bits of post-install conversion data SKAdNetwork delivers.

Here’s the best part: now you can run SKAdNetwork tests side-by-side with iOS13-style attribution and marketing measurement.

I honestly cannot emphasize enough how important it is that you get on this train immediately to enable side-by-side testing.

In Apple’s original timeline, you would have had historical data and iOS 14 data, maybe with some messy mixture of not-yet-upgraded-to-iOS-14 data. You would not have had the ability to play around with SKAdNetwork measurement and compare accuracy. You would not have had the ability to change your SKAdNetwork post-install conversion strategy and compare that with traditional IDFA-available measurement.

Here’s the danger: if you don’t jump on this train today, you still won’t have that ability. And that means that when SKAdNetwork does get fully implemented and Apple does completely enforce all the planned privacy measures for iOS 14, you will be flying blind.

The opportunity now is to plan, implement, test, and optimize so that when the new reality hits, you already have the confidence that you can still do mobile user acquisition at scale profitably. You’ll know that you can trust your SKAdNetwork-based marketing measurement models. You’ll know that they’ve been stress-tested.

Singular will work with each of our clients on testing IDFA-based marketing measurement versus SKAdNetwork marketing measurement over the next five months so that you’re certain you have the data and insights you need to enable mobile growth.

We’re working with partners on standardization of SKAdNetwork terms and methodology. We’re serving the ecosystem to help everyone prepare. This delay gives us more time to provide you and other marketers with the full support that you may need, and to help you make sure that you are 100% ready to go. Ultimately, when you deploy a new app, framework, or tool, you want to do it gradually and not all at once. That’s the responsible thing, and Apple gave us the chance to do it the right way.

Now is your opportunity to take advantage of that time … to dot all your I’s and cross all your T’s.

One other note: there are not a lot of details in Apple’s announcement. Even though IDFA is available without consent in iOS 14 Beta 7, the announcement doesn’t say explicitly that the IDFA will remain available without consent.

So apply a bit of caution. This is not a business-as-usual announcement. This is a ready-set not-quite-go. But the “go” is coming soon.

If you’re wondering how to tackle iOS 14, SKAdNetwork, and how to minimize the messiness of this transition, you can get more details here. Plus, we’d love to chat with you. I would be happy to connect with you personally, and you should also join our Mobile Attribution Privacy group on Slack, where we discuss all these changes.

You’ll find me on that Slack channel!

Secure SKAdNetwork 2.0: A seamless setup for establishing trust

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

 

When we released our first-to-market solution for SKAdNetwork back in June 23rd, we recognized two critical issues that existed in SKAdNetwork exposing advertisers to ad fraud:

  • Conversion values are not signed by Apple
    This creates an opportunity for networks to change the values and self-report higher ROI, which can make SKAdNetwork completely untrustworthy.
  • Country information is not part of the postback payload
    The first recipient of the postback can identify the country based on the sender’s IP, but this data is lost at that point, and we need the network to forward it … which is again susceptible to changes.

We chose to address these issues as part of our Secure-SKAN product. In addition, we shared this solution as part of our open-source SKAdNetwork spec called SKAN, where we devised a “Secure SKAdNetwork setup:”

  • Ad Networks and DSPs co-register to SKAdNetwork with each MMPs (e.g. “Singular+Ad Network”).
  • MMPs will become the initial recipients of the postbacks, and then forward them to the ad networks.
  • This eliminates all concerns of data manipulation and makes reporting dramatically easier.

Since launching this solution, we’ve received incredible feedback and interest from customers, and true collaboration from ad networks. But the one thing that remained a challenge was the need for multiple SKAdNetwork registrations, which works, but not as streamlined. So we challenged ourselves to find an easier way to achieve the same level of trust and security.

Today we’re excited to announce a new and dramatically easier way to achieve a secure SKAdNetwork setup.

The solution works in the following way:

  1. Ad networks, who are the initial recipients of the SKAdNetwork postbacks, will return an HTTP 307 response, which designates a temporary redirect.
  2. This HTTP response instructs the device to retransmit the exact same HTTP message to the Singular endpoint.
  3. Singular will first verify this message is unique, and not a duplicate.
  4. Then we will verify this message is indeed cryptographically signed by Apple.
  5. Lastly, we will verify the IP address of the sender is reasonably unique to prevent malicious parties from sending modified postbacks from their servers.
SkAdNetwork Secure Step

We’re very excited that the solution is elegant, simple for networks to implement, and provides a lot of benefits. It took some time to validate the new setup since SKAdNetwork is very challenging to test, but we can confirm we have verified this on a real device and it works exactly as we expected!

The Secure-SKAN solution offers some major advantages:

  • Fraud-free
    The device is sending the exact same payload to the network and Singular. It is therefore impossible to manipulate the data.
  • Simplified setup
    This doesn’t require a new SKAdNetworkIdentifier leveraged in the SKAdNetwork signature process, nor does it require a new list update on the publisher’s side.
  • Easy to implement
    This almost completely removes the need for ad networks to implement APIs for providing the SKAdNetwork data – since we will get the data directly from a user’s device.
  • Privacy-safe
    This solution involves zero PII and requires no policy change or code updates from Apple (which has always been our litmus test for separating real solutions from mere ideas).

 

In the following weeks, we’ll continue to promote the secure implementation of SKAdNetwork with our ad network partners. We’re very excited at the journey ahead with our customers and partners, and we thank them for their support.

The future of iOS Attribution: Visualizing the crossroads for mobile measurement

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

At Singular, we reacted quickly as we’ve been preparing for it for over a year. We formed the Mobile Attribution Privacy Coalition (join the slack channel here) in June of 2019 with less than 20 members, and now it has over 1000 participants! We monitored ITP to predict where probabilistic attribution will go and we reverse-engineered SKAdNetwork before there were any public docs to understand how it works. And lastly, we released various pieces of content that we believe are informative and pragmatic, as well as some sample code in Github.

It’s now been exactly a month since Apple announced the deprecation of the IDFA in iOS 14, and the number of questions about what it means for marketing measurement is continuing to grow at an exponential rate. Customers and prospects we talk to are constantly asking about the different possible outcomes for mobile attribution, and I thought it would be a valuable exercise to try and build a decision tree outlining the possible solutions and scenarios – including adding our own view on the probability of these events happening. Simply click on the Miro board below, and explore away.

Note: Click the below board to display the decision tree. For the best experience, view the decision tree on desktop. This decision tree is updated regularly with new developments.

IDFA iOS 14 FAQ: What’s true, what’s fake, and what’s total fantasy

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

My personal goal for Singular for the past two years has been to get ready for this scenario: the deprecation of the IDFA.

Well, it happened.

At Singular, we’ve been writing and speaking about IDFA deprecation for a long time. We’ve formed the Mobile Attribution Privacy group with top brands to plan out a PII attribution future, and we’ve been speaking to as many people as possible.

It has been a crazy week so far, and it’s only the beginning. Fortunately, Singular has a SKAdNetwork solution for marketers that you’ll be able to see and test very soon. But I have to say I am quite surprised that an event so dramatic as this one — throwing an $80 billion market into upheaval — is getting very little publicity, and I also see very little content on this topic outside of Singular.

In what has been published, I’ve seen some interesting thoughts and claims, and some obvious falsehoods. I want to share my educated opinions on those.

I’ll start by saying that this all depends on whose point of view we’re taking. In this case, I’m trying to take Apple’s POV, which, based on everything I’ve seen them do on the web and now on mobile, is very (VERY) privacy oriented. I may also refer to them as the “law” since they are pretty much the law when it comes to iOS.

Finally, be aware that this is my opinion based on the facts at hand, and things may change. I will, however, try to update this every couple of days with what I’m learning.

The IDFA iOS 14 FAQ

Claim: “This is not the end of the world.”
Assessment: True

I think the next few months will be challenging for the entire mobile ad ecosystem (publishers, advertisers, ad networks, mobile measurement partners) and anyone in adjacent spaces since we’ll have to adjust to yet-another-new-normal.

Seeing how Apple kept iterating on its parallel solution for the web (ITP), I am convinced that there will be more iterations on SKAdNetwork that will make it better. Our job as a leading MMP is to define how marketers can still get unbiased measurement and understand their ROAS, and that’s where we’ll spend most of our energy.

Claim: “Device identifiers are never used across different app publishers for attribution.”
Assessment: Incorrect

I think this is incorrect because the way mobile attribution works today does involve sharing a device ID between the publisher app to the advertiser app. In fact, just connecting a click to an app open is a connection that’s created between user activity in two different apps. And it’s certainly something that goes from a personal device to a third-party company as well as the app publisher.

Claim: “But we’re a GDPR and CCPA compliant MMP/network/etc.”
Assessment: Irrelevant

I don’t think Apple cares. Apple takes GDPR and CCPA as the baseline. It’s table stakes, and they are now raising the bar, according to their own standards.

Claim: “The IDFA is not going away completely.”
Assessment: Functionally False

Look, here’s my thinking on the topic:

  • You need people to opt-in. The message is scary, and while you can customize at least some of it, most people will say no. I think Apple doesn’t want people to click it.
  • But let’s say, by some magic, you do get people to click it, and your app can now access the IDFA: it is likely still useless because people are just as unlikely to click it in other apps, and then you’ll start having partial views of people.
  • And that means that the IDFA is basically useless… you can’t use it to target, or attribute, or anything else. It’s almost equivalent to IDFV at this point.

Claim: “Fingerprinting will always be an option to provide compliant attribution.”
Assessment: False

I would love for fingerprinting to “always be an option,” and I’m not a complete privacy zealot by any means, but it’s incorrect:

  1. In this video released as part of WWDC, they describe that fingerprinting is indeed a form of tracking this applies for:
  2. Also – In the past two to three years, Apple did a lot of work on Safari, their browser, to reduce cross-site tracking by imposing aggressive limits on cookies and other website data. This project is called ITP, and I believe it was the precursor to all the work Apple did on the IDFA.If you read this ITP article about “Privacy Preserving Ad Click Attribution For the Web” – you will see it bears a lot of resemblance to some mechanisms they added to SKAdNetwork 2.0. And if you look at ITP’s Tracking Prevention Policy, they are very clear about fingerprinting:

Besides, I don’t think that’s the spirit of the law. Or, in other words: in what universe would Apple be cool with fingerprinting when they’re making these very apparent steps towards privacy?

Claim: “There’s no role for the MMP in iOS.”
Assessment: False

While some of the mechanisms have changed, the role of the MMP stays exactly the same: provide unbiased measurement that leads to actionable decisions about media buying and mobile marketing efforts.

That job has not changed one bit. SKAdNetwork is going to cause more mess than before, where you’ll now have those “apple-signed install notifications” sent to all sorts of endpoints, and you’ll need a third party to ingest them and validate them.

You’ll also have to deal with details like:

  • How do I assign campaign IDs in such a small space (a number between 0 to 99, a total of 100 options)?
  • How do I translate these IDs to something meaningful?
  • How do I associate cost to it?
  • How do I translate my “conversionValue” from a 6-bit number (64 options only) to something meaningful?
  • How do I then translate that to ROAS?

All that mess is the job of your measurement provider. That’s where Singular comes in, and I’m sure other MMPs will follow suit (they also don’t have that much time to figure things out because in October iOS 14 will have 50%+ adoption in the market).

IDFA Alternative: “iOS Referrer, similar to the Google PlayStore Referrer.”
Assessment: Unlikely

This is a nice idea that everybody wished for, but I can’t see Apple going for it.

Why? For the simple reason that it lets the advertiser’s app know exactly where a user came from. And that means that even if you can’t access the IDFA, there’s still some cross-app tracking taking place … which is against the spirit of the law. So I can’t see how it would be compliant with Apple’s push for privacy.

IDFA Alternative: “Mandatory or incentivized opt-ins will work”
Assessment: Not going to work

First of all, mandatory opt-ins will certainly anger Apple. And they probably won’t like incentivized opt-ins either. But that’s not even the biggest problem.

The biggest problem is that you need opt-in everywhere for this to have any meaning:

  1. Let’s say that I play “CoolGame 3” and they did a great job forcing/incentivizing me to opt-in. Great for them.
  2. Let’s say that now I see an ad for Uber in CoolGame 3.
  3. I go on and install Uber.
  4. Uber wants my ride $$$, so they won’t force me to opt-in. So I would probably opt-out given that scary popup.
  5. Uber can’t attribute me.
  6. CoolGame 3 doesn’t get paid.
  7. CoolGame 3’s great attempts to get me to give them my IDFA didn’t help.
  8. Fail.

IDFA Alternative: “More granular tracking permissions with attribution as an exception.”
Assessment: Doubt it’ll make iOS 14

That’s great, and I’d love for it to become a reality, but so far, it seems that attribution doesn’t fit the criteria that Apple put in place for exceptions. Additionally, IDFA is simply not accessible by the API without an opt-in.

It’s possible that Apple would expand SKAdnetwork to support more attribution use-cases, but in my opinion, an outright exception to use identifiers would be off the table. Looking at how they handled ITP, they made no exception and considered all of this as collateral damage:

Claim: “This will impact the SDK ad networks more than the SANs.”
Assessment: I think both are equally impacted

SANs are the most powerful networks out there, with extremely precise targeting, and according to our data and ROI Index, they are the top-performing channels that capture the lion share of the spend.

That being said, unless SANs like Facebook and Google get special access, this impact could change things for them just as much as it’s changing things for the SDK Ad Networks, and potentially even more because much of their superiority lies with accurate data, the kind of data Apple will be taking away by anonymizing everything. Also – SANs may also have a large dependency on View-Through attribution, which these changes impact too.

Claim: “Apple already provided exceptions to obtain IDFAs without user opt-in.”
Assessment: Seems false in the beta so far

We tested iOS 14, and the method that gives the app the IDFA is returning 0s in case the user didn’t opt-in. This also aligns with Apple’s documentation, IDFA wouldn’t be accessible without a user opt-in.

I don’t think Apple ever said that you could obtain IDFA without opt-in, and what I do see in their docs doesn’t speak about IDFA:

Idea: “Let’s hash IDFAs, and so the actual IDFA will never leave the device.”
Assessment: Doesn’t solve for privacy

Doing a one-time hash creates a really easy way to utilize the IDFA still. If everybody could collect IDFA, and hash it, then you now essentially got a new IDFA (let’s call it HIDFA – Hashed IDFA).

To illustrate:

  • CoolGame 3 takes my IDFA and hashes it. They now have my HIDFA, and they send it to CoolGame’s servers.
  • Uber takes my IDFA and hashes it. They send my HIDFA it to Uber’s servers.
  • Uber and CoolGame 3 can now track me across apps.

So we ended up with the IDFA again.

Claim: “We’ve done fine when Apple deprecated UDID and MAC addresses.”
Assessment: I think it’s irrelevant this time

Yes, we have gone through a lot as an industry, but I don’t think this one is the same. I’d love to be wrong, but in the past, when permanent device identifiers went away, temporary ad IDs gave us what we needed. This is a different scenario entirely, where the OS has stepped into the attribution flow.

Claim: “Facebook will not be affected.”
Assessment: Not sure

Apple has been known to give Facebook an unfair advantage before, whether it’s native integration into the OS or other things. But, in this move, Apple seems to have impacted their own ad network (Apple Search Ads), and play by the same rules.

There is an open question about whether ASA will be able to track installs on LAT users and bill you based on that, but they’re making such a big deal about privacy, it would be SO WEIRD if they just gave ASA or Facebook some magic access… but who knows.

Claim: “This will push all the ad dollars to Android.”
Assessment: I think it’s unlikely

There may be some initial push towards Android where things “simply work,” but I don’t think that’s sustainable. iOS revenue share in most western markets is 65%+, and I doubt app developers will give up that revenue stream. Some of the UA/Advertising capabilities will be impacted on iOS; there’s no doubt about it… but there will be some tools and capabilities that will still enable the advertisers to do their job, and I think these will get much better over time.

Join the conversation

Have questions? You’re not alone. Our entire industry needs to adapt to these new privacy enhancements, and we have to do it fast. We invite you to join our community coalition, Mobile Action Privacy (MAP), on Slack to connect with other thought leaders, ask questions, and share ideas.

You can also watch our on-demand webinar, iOS 14 & IDFA changes: What you need to know, where I reviewed what losing the IDFA means for marketers and what data-driven marketing will look like in the very near future. Stay tuned! More to come. 😊

Singular announces first-to-market SKAdNetwork support to replace the IDFA

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

For the past couple of years we’ve been preparing for the eventuality that Apple would deprecate the IDFA. What was once an unfathomable scenario will now become a reality this September when iOS 14 launches publicly.

While the IDFA isn’t completely gone, Apple created an opt-in mechanism that will effectively render it useless, and as a result, thousands of companies and millions of developers are scratching their heads and wondering what’s next.

We’ve given it a lot of thought here at Singular, as this fundamentally redefines the role of Mobile Measurement Partners (MMPs).

MMPs are designed to provide unbiased third-party measurement of your mobile marketing efforts. Up to now, much of that promise was facilitated with the aid of mobile ad identifiers like Apple’s IDFA on iOS and GAID (Google’s Advertising ID) for Android. Moving forward, we face a significant challenge: finding new ways to keep that promise and help marketers optimize their campaigns … while preserving end-user privacy. Even in the middle of massive market shifts like the one we’re going through now.

That is why I’m very excited to announce Singular’s first-to-market support for SKAdNetwork, making it scalable, simple, and seamless for mobile marketers.

Yesterday’s announcement at WWDC is a tectonic shift for mobile marketers. Some are probably wondering how they can optimize ad campaigns in the future. It will still be possible, and you will be able to understand which marketing inputs are driving the results you need.

Context: what is SKAdNetwork?

SKAdNetwork is a library provided as part of iOS to help marketers attribute marketing in a privacy-safe way.

Apple’s been working on it for some time. Thankfully, we’ve also been working on how to support it for over a year now. But in iOS 14, Apple has given SKAdNetwork some major renovations that made it a whole lot more useful and usable. And it definitely feels like Apple listened to us and other marketers in the Mobile Attribution Privacy Coalition who spent time analyzing its strengths and weaknesses.

The key concept in SKAdNetwork is that the iOS operating system will now play a central role in facilitating marketing attribution.

If SKAdNetwork is enabled in an app, the App Store will now receive attribution parameters when it’s opened due to a click on an ad. Then, if this click results in a conversion — an app download — iOS itself will send a postback accompanied by those attribution parameters.

(And, potentially, some important post-install conversion data, which we’ll cover later.)

This may sound somewhat similar to Google’s Play Referral mechanism, but what makes SKAdNetwork privacy-preserving is the fact that the attribution parameters cannot contain any device IDs or personally-identifying information. In addition, the install postback is sent by the operating system itself, and not by the installed app. As such advertisers will know that an install has happened, but they won’t be able to connect a specific install with a specific device, thus preserving privacy.

SKAdNetwork 1.0 was initially released over two years ago, and it offered very limited granularity plus no support for post-install measurements, making it practically unusable for optimization purposes.

The good news is that in SKAdNetwork 2.0, Apple added “publisher-app” granularity. In other words, marketers can now get data on which publisher drove which install. That’s critical: now we can provide publisher-level insights to marketers. In addition, Apple also added limited support for post-install tracking with their new updateConversionValue and registerAppForAdNetworkAttribution methods.

A high level flow looks like this:

SKAdNetwork 2.0 attribution flow using the updateConversionValue or registerAppForAdNetworkAttribution methods

What does this mean for marketers?

Currently, marketers have two main sources of data for measuring marketing campaigns:

  1. From MMPs: metrics on installs and post-install cohorted metrics
  2. From ad networks: metrics on impressions, clicks, video-views, spend

As things currently stand, Singular combines those two datasets together. Then marketers can get both granular and high-level insights on the results of their marketing investments. With those insights, they can optimize acquisition and retargeting campaigns, test new networks, and more.

With iOS 14, everything changes.

For starters, the data flow for mobile app attributions will change. Instead of apps sending postbacks to Singular, now Apple will be sending install postbacks to ad networks whose ads caused the app install. These postbacks include information about the install that is cryptographically signed by Apple, and can be verified using Apple’s public key.

Another key issue with iOS 14: measuring post-install activity. SKAdNetwork includes functionality for an app to send a small amount of post-install conversion data back to the ad networks, but this is limited in both scope and timing. (More details on this shortly in our next post.)

There’s a significant positive here, by the way. In iOS 14, Apple vouches for app installs, which dramatically reduces the likelihood of ad fraud.

All of this means major change for marketers. Whereas previously MMPs collected all the data they needed, now iOS advertisers will need to collect all install postbacks (and any post-install conversion data) from every ad network they run campaigns with. Plus, advertisers will need to validate these postbacks, store them, translate the attribution parameters to human readable data, and then connect it to campaign spend data to determine return on ad spend. Oh, and the closer you can do it real-time, the better you can be at optimizing your future ad spend.

That’s exactly where Singular comes in.

Singular’s solution: making SKAdNetwork simple and scalable

idfa-skadnetwork-apple-singular

Singular is the leader in aggregating data from thousands of data sources. We collect more data from more sources in more ways than anyone else, which we then standardize, aggregate, and present. And that’s perfectly aligned with our MMP attribution product, which has gained incredible momentum in the last two years with many of the world’s best brands switching from legacy MMPs to Singular as a unified aggregation and attribution solution.

Our primary advantage as a platform becomes even stronger in this new SKAdNetwork reality.

We already are by far the best in the world in gathering full data sets from every single channel. After all, that’s our core strength. In supporting SKAdNetwork, we will be adding the role of collecting the various Apple-generated postbacks from all of your ad network partners. We’ll then verify them, de-dupe them, parse them, and connect them to your ad spend to report on ROI.

And Singular will still help you achieve publisher-level granularity for marketing reporting (what some in the industry have called sub-publisher granularity).

Plus, of course, the SKAdNetwork stack will have to work side by side with the existing MMP capabilities of the Singular stack, including continued support for:

  • iOS fingerprinting (adhering to any Apple updates)
  • iOS deeplink support (still fully supported)
  • iOS deferred deeplink support (reliant on fingerprinting)
  • Android attribution (yeah, apparently Android is kind of a big deal)
  • Web and cross-device attribution (growing in importance)
  • Spend and ROAS reporting (critical for marketing optimization)

SKAdNetwork is going to introduce new challenges and complexities. There’s no doubt about that. However, we commit to helping you navigate these challenges.

And we will ensure you have the ability to do your job … while preserving user privacy.

Interested in continuing the conversation? Join us and other industry experts in the Mobile Attribution Privacy (MAP) Coalition Slack group, to exchange ideas and ask questions.

iOS 14: IDFA is not dead yet, but it’s definitely on life support

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

 

Today at WWDC 2020, Apple announced several new privacy enhancements in iOS14 that will debut in September. We’ve been long anticipating these changes, and have been working to prepare for this since our announcement a year ago on the formation of the Mobile Attribution Privacy group. (See more details here, and join the Slack group here).

The good news for consumers: more privacy.

The good news for marketers: it’s not game over for data-driven marketing.

Some of the changes to Apple’s SKAdNetwork framework are extremely promising. Apple’s SKAdNetwork improvements suggest that not only are they listening to what app publishers need, but that we will still be able to provide tools for sophisticated marketers.

In addition, Singular has a number of upcoming privacy-preserving solutions that we will announce shortly.

Opt-In for IDFA

Starting with iOS 14, apps will need to receive permission from users in order to use the Identifier for Advertisers, the IDFA. To be clear, this is explicitly granting permission to track users across apps and services.

Straight from the documentation:
“Your app needs to request permission to track sometime before tracking occurs. This could be at first launch or when certain app features are used. For example, when signing on with a third-party SSO.”

IDFA permission request iOS14
Looking at the documentation for iOS 14, we can confirm that when the “Ask App Not To Track” button is clicked, the app will not be able to access the device’s IDFA, and receive the same value as if the Limit Ad Tracking mechanism is turned on. In short, until a user grants authorization, all identifiers will be zeroed out.

One piece of good news if you want to use the IDFA and believe it’s something that your users will want?

The message will be customizable. “App developers need to provide custom text, known as a usage description string, which is displayed as a system-permission alert request,” Apple’s documentation says.

That means you’ll be able to make the case to your users that opting in is a good thing for them.

Let’s be frank, however.

The vast majority of people who see a message like the above are not going to opt in. When they see that a publisher wants permission to track them across apps and websites owned by other companies … forget about it.

So you’re going to have to be ready to live without IDFAs.

Checking for IDFA status

Apple is deprecating the isAdvertisingTrackingEnabled function. In order to check if a user has actually enabled measurement, developers will need to check the AppTrackingTransparency framework.

Changes to SKAdNetwork

SKAdNetwork in iOS14 apple

Apple has also made multiple changes to SKAdNetwork, the class that validates advertiser-driven app installations. We’re going to go in-depth on this in a follow-up blog post tomorrow — and a webinar — but here’s the quick overview:

  1. Apple added timers, which likely means that the conversion notification won’t be immediate. This is probably a privacy-enhancing move.
  2. Apple added a mechanism to update a conversion value. This may be an initial method to attach limited post-install KPIs to the conversion notification, which of course is crucial for optimizations.
  3. Apple added Redownload/Reinstall support, which is always nice to know.
  4. Apple added Source App ID to recognize the publishing app (this is huge because we can now facilitate publisher-level granularity).

There are quite a few more changes, but we’ll continue researching them and update on those later in our in-depth follow-up post.

Finally: new App Privacy section

Later this year, your app’s App Store product pages will start to feature summaries of your self-reported privacy practices, plus a link to your privacy policy. That includes both data gather via the app that is used to track users elsewhere plus data that publishers might access outside the app and link to users’ profiles in the app. Example: purchases, web browsing history, location data, and other demographic information.

app privacy page in app store