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.