Mobile Dev Memo https://mobiledevmemo.com Mobile advertising and freemium strategy. Mobile marketing, analytics, and monetization. Sun, 02 Aug 2020 22:19:02 +0000 en-US hourly 1 58872998 What do TikTok and Grindr have in common? https://mobiledevmemo.com/what-do-tiktok-and-grindr-have-in-common/ https://mobiledevmemo.com/what-do-tiktok-and-grindr-have-in-common/#respond Mon, 03 Aug 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30332

This past Friday, President Donald Trump told a press pool aboard Air Force One that he would take action to ban TikTok, the video messaging app, from the United States. His statement was declarative and leaves little room for interpretation: “As far as TikTok is concerned, we’re banning them from the United States.”

First, a very abbreviated background on TikTok’s current precarious position: the company is a subsidiary of China-domiciled ByteDance, and Chinese companies are required to comply with data requests from the government. TikTok had been flagged as a potential national security threat as early as last November, and in recent weeks, in order to avoid a ban in the US similar to the one that is currently in place in India, ByteDance had proposed selling a majority state of TikTok to American investors (which was rejected by the Trump administration) or divesting the company to American ownership completely. Serious acquisition discussions between ByteDance and potential suitors, especially Microsoft, had apparently been progressing meaningfully before Friday, but those discussions seem to have now been paused absent further clarity from the White House.

In October 2019, Senator Marco Rubio sent a letter to Treasury Secretary Steve Mnuchin requesting that the Committee on Foreign Investment in the United States (CFIUS) review ByteDance’s 2017 acquisition of Musical.ly, which was later renamed TikTok, as that acquisition had been completed without government oversight. The CFIUS is charged with investigating foreign investment into American companies for the purpose of monitoring national security risks; the number of China-related transactions covered by the CFIUS has exploded in recent years (per the CSIS think tank):

Steve Mnuchin last week confirmed that TikTok is still under CFIUS review, and that the panel would be making a recommendation to the President soon. And while the legality of an outright ban is dubious and the mechanics are complicated, there is precedent in the CFIUS ordering divestiture: they did so with LGBTQ dating app Grindr, which was acquired by Beijing Kunlun Tech in 2018. In March 2019, the CFIUS informed Beijing Kunlun Tech, which had not submitted its plan to acquire Grindr to the committee ahead of time, that it had a June 2019 deadline to sell the app after its ownership was deemed a security risk.

One interesting wrinkle to the CFIUS review of ByteDance’s Musical.ly acquisition: Musical.ly was a Chinese company, headquartered in Shanghai when it was acquired, although it had a large Santa Monica office. This excellent legal analysis of the situation concludes that the acquisition remains within CFIUS purview.

Mobile advertising network Applovin similarly had its $1.4BN acquisition by Chinese private equity firm Orient Hontai Capital blocked by the CFIUS in 2017; the firms ultimately agreed to an $841MM debt investment. In 2018, Applovin accepted a $400MM minority-stake investment from US private equity fund KKR, valuing the company at $2BN.

The CFIUS committee is led by Treasury secretary Steve Mnuchin and is comprised of members of the Defense, State, Justice, Commerce, and Homeland Security departments. According to law firm Cleary Gottlieb, the committee has the authority to review any “covered transaction” that would result in the ownership of a US business by a foreign entity.

The committee was convened by President Ford in 1975 out of fear of Japanese acquisition of strategically important American companies, but it has received renewed relevance as President Trump amplifies his hostility with China over trade imbalances. The CFIUS can review proposed, in-process, and completed acquisitions, and it passes its recommendations onto the President, but the CFIUS’ mere rejection of a deal can be enough to stop or reverse it. The CFIUS’ review process can take between four and eight months.

Similar to Grindr, and consistent with the comments made by Secretary Mnuchin last week: the CFIUS could recommend that ByteDance’s acquisition of Musical.ly be rejected post hoc, forcing a sale. This seems like a more likely outcome than trying to orchestrate an outright ban: India (and Australia, which is considering banning the app) is able to block citizens’ access to the app using a national-level firewall, similar to that of the Chinese government’s, which effectively bans many US-based digital products. The US doesn’t have access to any such national blocking facility, and so a ban in the US would need to be enforced at the distribution (app store) level, which would require the application of legal acrobatics.

Photo by Vincent Guth on Unsplash

]]>
https://mobiledevmemo.com/what-do-tiktok-and-grindr-have-in-common/feed/ 0 30332
Facebook: iOS 14 will hurt small businesses during COVID https://mobiledevmemo.com/facebook-ios-14-will-hurt-small-businesses-during-covid/ https://mobiledevmemo.com/facebook-ios-14-will-hurt-small-businesses-during-covid/#respond Fri, 31 Jul 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30300

I received a fair amount of pushback to my recent column, IDFA deprecation is Facebook’s Sword of Damocles, much of which reduced to something along the lines of: Facebook is a huge company employing tens of thousands of the brightest engineers, data scientists, and analysts in the world. Surely they have enough data, and enough raw talent, to overcome a lack of access to device identifiers in driving efficient ad targeting.

That is an entirely fair point. Facebook employs perhaps the most powerful data science organization in the world, and a device identifier, while precise, is merely one identifier. Facebook has a treasure trove of data about every person that has ever used any of its properties, and those properties are ubiquitous. I don’t doubt that Facebook can deliver a medium-term solution that can replace the efficiency of device-centric ad targeting.

But the medium term is a long time for the companies that depend on Facebook for their apps’ growth (and we all know what happens in the long term). What happens to these advertisers in the intervening months between mass iOS 14 adoption, when the IDFA is essentially deprecated and devices can no longer be targeted precisely (neutering Facebook’s event-optimized ad campaign strategies much less effective than they are now), and this brave new world of probabilistic attribution — with which, many people argue, Facebook can target ads at the same precision as today?

One instructive exchange in Facebook’s recent Q2 earnings call on July 30th came when Justin Post of Bank of America asked about the upcoming IDFA deprecation in iOS 14 (transcription below is mine, emphasis is also mine):

“…could you talk about some of the potential headwinds in the second half in a little more detail, especially any Apple IDFA change, or how that could impact your business?”

David Wehner, Facebook’s CFO, responded candidly:

“…In addition, we did specifically call out changes on mobile operating platforms, and that, as you correctly identified, was specifically with the Apple latest announcement regarding iOS 14 in mind. This is one of the factors that is included in our outlook for Q3, but it really will have more of a pronounced impact in Q4 and beyond given the rollout begins late in Q3. We are still trying to understand what these changes will look like and how they will impact us and the rest of the industry, but at the very least, it’s going to make it harder for app developers and others to grow using ads on Facebook and elsewhere. Advertising clients are asking us how to maintain their performance and we’re working on it. Our view is that Facebook and targeted ads are a lifeline for small businesses, especially in a time of COVID, and we are concerned that aggressive platform policies will cut at that lifeline at a time when it is so essential for small business growth and recovery.”

This is helpful in understanding just how much of an impact the lack of iOS device identifiers will have on ad efficiency: somewhere between more than none and the opening scene from It’s a Wonderful Life. Wehner uses the world aggressive to describe Apple’s decision to deprecate the IDFA, which suggests to me that Facebook interprets the maneuver as hostile to advertising platforms. If the deprecation of the IDFA was to have an immaterial impact on Facebook’s business, it wouldn’t make sense to use aggressive to describe it.

Of course, the appeal to COVID and the struggle of small businesses is possibly even more of a tell that Facebook believes the impact of IDFA deprecation to be dramatic. In my podcast with David Philippson, CEO of DataSeat, I actually revised (incorrectly) my prediction from February 2020 that Apple would announce the deprecation of the IDFA at WWDC because I thought doing so during COVID would further aggravate economic anxieties for app developers and the ad tech ecosystem. In appealing to Apple’s compassionate temperament by invoking COVID and the acute pain that small businesses are confronting during the pandemic, Facebook seems to be saying that iOS 14 will cause real pain to its advertisers.

Facebook’s earnings call, not to mention those of other public companies that are heavily dependent on mobile advertising revenue, was light on penetrating questions about IDFA: I feel that direct, thoughtful questions can yield more insight into how these companies plan to react to the changes coming in iOS 14 (and subsequent to that from other parties, eg. Google). I enumerated some questions which could potentially produce revelatory answers in a Twitter thread (after listening to a particularly frustrating exchange in a different earnings call):

As some people pointed out in the thread, these questions are too esoteric for most executives to be able to capably answer. But that’s the point: for most mobile-centric or mobile-first content businesses (ie. advertisers), advertising is the primary determinant of revenue. If a company is spending tens or hundreds of millions of dollars per year in advertising, its executives should understand the mechanics of its underlying advertising systems, and big changes like those coming to iOS 14 — which will dramatically reshape the mobile advertising ecosystem — should register at the executive level.

]]>
https://mobiledevmemo.com/facebook-ios-14-will-hurt-small-businesses-during-covid/feed/ 0 30300
How might IDFA deprecation have minimal impact? https://mobiledevmemo.com/how-might-idfa-deprecation-have-minimal-impact/ https://mobiledevmemo.com/how-might-idfa-deprecation-have-minimal-impact/#respond Mon, 27 Jul 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30262

In considering Apple’s decision to effectively deprecate its advertising device identifier (IDFA) in the weeks since it was announced at WWDC, I’ve come to the conclusion that the impact of this change will be enormous and transformational for the mobile advertising industry: an entirely new paradigm is being created, and completely new processes, tools, and infrastructure need to be built to accommodate it. I explain the implications of these changes in extensive detail in this post, and I won’t go into them here.

But what if I’m wrong?

What if the damage from these changes is contained in such a way so as the preserve the existing mobile advertising paradigm — that of deterministic attribution at the device level, on top of which all marketing efficiency is constructed? And assuming this is the case — how have I been wrong? Which assumptions of mine were invalid, directionally incorrect, or simply shortsighted?

I think it’s important in thinking about broad market trends over medium-term (1-3 years) timelines to attempt to rigorously challenge the underlying assumptions and guesswork that serve as change agents. One way to ensure this is to hold oneself accountable to predictions by making them public, as I do at the end of each year. I have been wrong about a lot of things — I predicted that Apple would not launch a mobile ad network, for instance — but I try to stress test the underlying components of any prediction such that the logical chassis of any prognostication is sturdy. I attempt to do that here by examining the mitigating factors that could potentially soften the blow of IDFA deprecation.

Google doesn’t follow suit and deprecate the GAID

Consensus opinion seems to be that Google will emulate Apple’s decision to deprecate the IDFA and will create a similar opt-in mechanic that will allow a user to control which apps access their Google Android IDs (GAIDs). I talk about why I believe this assumption is reasonable in this post from February, in which I explored the fallout of a hypothetical decision by Apple to deprecate the IDFA, and in this post.

While Google is by no means obligated to do so, I think it is very unlikely that Google won’t follow Apple’s lead and deprecate the GAID. Apple and Google have remained more or less in lockstep with respect to privacy controls, with banning third-party cookies in Chrome and in introducing a Limit Ad Tracking setting on Android. The optics of Google not remaining in lockstep with Apple with respect to advertising identifier access would be problematic: Google is currently being probed for an anti-trust case related to its dominance in the online advertising market. While GAID deprecation isn’t related to its market position with advertising, one could make the argument that by not deprecating the GAID, Android becomes a more attractive platform for developers (and thus advertisers), bolstering its app advertising business.

But Google might take a softer touch with privacy controls that don’t result in the effective deprecation of the GAID. If this is the case, and advertisers have broader access to GAIDs than IDFAs, more advertising money might flow to Android and the bear case around IDFA deprecation — that it leads to the total destruction of the device-identifier-centric mobile marketing model — is harder to defend.

But App Store revenue is roughly double that of Google Play. Apple deprecating the IDFA means more than Google deprecating the GAID: even if Google doesn’t follow suit, the impact of “mere” IDFA deprecation (versus deprecation of mobile advertising IDs generally), holding all other assumptions constant, is extreme.

Opt-in rates for ad tracking are very high

No one really knows with any credible clarity how users will react to ad tracking opt-in prompts. TapResearch has been conducting in-app surveys around how users will respond to opt-in prompts, and those are not very encouraging, but if opt-in rates are surprisingly high (for example, 70%+), then the impact of the opt-in mechanic will be muted and probabilistic models can simply supplement deterministic attribution.

The big open question around opt-in rates is whether the platforms will allow the incentivization of opt-in: if, for instance, an app could give a user free credits or some form of reward for opting into ad tracking. If app developers are allowed to incentivize tracking, they might be able to reach the levels of opt in that allow for scaled, device-identifier-centric app marketing.

But one thing to keep in mind on this topic is that LAT rates are already very high: the MMP Singular measured LAT rates of more than 30% in the US. Even a 70% opt in rate would put total device identifier access at less than half (70% of 70%, or 49%).

Apple doesn’t or can’t enforce its proscription of device fingerprinting

Apple has been clear that it will not allow for the fingerprinting of a device if the user has not opted into ad tracking. And we can take guidance around Apple’s attitude towards fingerprinting through the position it takes in WebKit.

But perhaps Apple will choose to not enforce this position — it’s possible that Apple will allow some form of fingerprinting to be done at the device level, and these fingerprints will create the opportunity to do device-level ad targeting even when a user has not opted into tracking.

Apple allows third-party Single Sign On even if a user has opted out of ad tracking

The primary pushback I received from my analysis of Facebook’s vulnerability to IDFA deprecation is that Facebook isn’t dependent on IDFA since it has its SDK integrated into many apps: it has full access to the device and, with Single Sign On, can very effortlessly tie any given device to a Facebook ID without IDFA.

I don’t think this is credible. Firstly, Facebook Login rates in many types of apps (especially games) are incredibly low: it’s not easy to force a user to register an account after install, and registration and log-in mechanics increase churn. For some apps, like subscription products, registration mechanics aren’t as imposing, but for many types of games they are a non-starter.

The question, though, is whether Apple even allows for third-party SSO if a user has not opted into ad tracking. And we have some guidance around how Apple is likely to approach this: Apple launched Sign in with Apple at last year’s WWDC, likely as a means of reducing Facebook’s reach across the app ecosystem via Facebook login. Could Apple limit SSO to just Sign in with Apple if a user has opted out of ad tracking? Or might it prevent SSO completely if a user has opted out of ad tracking? This is all unclear, but it doesn’t seem likely that Apple would go to the trouble of introducing an opt-in mechanic to then allow developers (and Facebook) to sidestep it via SSO.

One wildcard here: Facebook has the phone number of each of WhatsApp’s 1.5BN monthly active users, and a phone number is a much more precise identifier than anything else that Facebook could potentially use for matching a device to a Facebook account: back in 2014, I posited that Facebook’s motivation in acquiring WhatsApp was to acquire those phone numbers. How a phone number could potentially be gleaned by Facebook via an app is unclear: the app would have to request the phone number from the user if they’ve opted out of ad tracking, which is suspect.

I think one key consideration in all of this, with respect to the assumptions above and any application of a workaround or loophole, is the total control over the ecosystem that Apple commands through its review process. Apple can keep an app in jail for any infraction of its terms: as the gatekeeper to the App Store, Apple can ensure that all apps are in absolute compliance with not just the letter of its terms but also the spirit. Any proposed workaround to the privacy protections coming to iOS 14 assumes that either Apple won’t be able to detect what the developer and its ad partners are doing or that Apple simply won’t care.

Photo by Wyron A on Unsplash

]]>
https://mobiledevmemo.com/how-might-idfa-deprecation-have-minimal-impact/feed/ 0 30262
How to Build and Scale successful apps without the IDFA https://mobiledevmemo.com/how-to-build-and-scale-successful-apps-without-the-idfa/ https://mobiledevmemo.com/how-to-build-and-scale-successful-apps-without-the-idfa/#respond Mon, 27 Jul 2020 05:25:00 +0000 https://mobiledevmemo.com/?p=30266

I have developed a one-hour workshop that gives guidance on how app developers and advertisers can adjust to the new app economy paradigm coming with iOS 14. In the workshop, I provide:

  1. An overview of the changes coming to iOS 14;
  2. Guidance around how to design an app economy in a way that fully accommodates SKAdNetwork;
  3. Guidance around direct response advertising strategy and optimization within the SKAdNetwork framework;
  4. An overview of non-deterministic advertising measurement;
  5. Guidance around how non-deterministic measurement can be utilized to drive ad spend efficiency.

The majority of this workshop will be dedicated to product and advertising strategy, with just a brief overview of eg. what the IDFA is and what changes are being introduced in iOS 14. For that background, I recommend that all participants read this post: Apple killed the IDFA: A comprehensive guide to the future of mobile marketing.

Given that the workshop is strategic in nature, it is best suited for: executive teams, institutional investors, product leads, and marketing leads.

The entire workshop is 1.5 hours: 1 hour of content, 30 minutes of Q&A. I will be holding these workshops for groups of up to 10 people, and the cost of the workshop is $1500 (total, not per person). The workshops will be held via Zoom, and I am scheduling them over a two-week period starting on Thursday, July 30th. In order to register for a group workshop, fill out this form.

]]>
https://mobiledevmemo.com/how-to-build-and-scale-successful-apps-without-the-idfa/feed/ 0 30266
IDFA deprecation is Facebook’s Sword of Damocles https://mobiledevmemo.com/idfa-deprecation-is-facebooks-sword-of-damocles/ https://mobiledevmemo.com/idfa-deprecation-is-facebooks-sword-of-damocles/#respond Mon, 20 Jul 2020 05:35:00 +0000 https://mobiledevmemo.com/?p=30211

The impending privacy changes coming to the iOS 14 through the deprecation of the IDFA disproportionately harm companies that have built deep user profiles for the purposes of ad targeting. Facebook, having built extremely sophisticated, precise targeting infrastructure, will perhaps suffer more than any other mobile advertising platform as a result of IDFA deprecation: all of its optimization mechanisms are built atop user-centric profiles that rely on in-app events being tagged with device identifiers. Without being able to attribute in-app events to a particular device, and thus a Facebook account, Facebook’s advanced, hyper-precise ad serving machinery is weakened.

The Sword of Damocles is meant to represent the unpredictable, potentially existential risks faced by those in power: Damocles hung a sword above his throne with a mere strand of horse’s hair. Facebook’s hyper-precise ad targeting is its power — it is the advantage it has over all other advertising platforms (apart from Google UAC). And IDFA deprecation is Facebook’s Sword of Damocles: a risk it always faced for becoming too skilled at targeting ads at users via aggregated behavioral profiles.

Facebook has grown its advertising revenue considerably since 2017, when it introduced the event-optimized App Event Optimization (AEO) and Value Optimization (VO) campaign strategies: all of that revenue growth is attributable to Facebook’s ability to calculate the probability of a specific user clicking on an ad, installing an app, and ultimately, making one or more purchases. With iOS 14, Facebook’s ability to do that is diminished: it can know which users click ads, but it can’t tie in-app events to individual user profiles, at least not in real time and in a reliable way. The changes introduced in iOS 14 were always a possibility, and the more money that Facebook made with its ability to target ads to users with stunning precision, the more likely these changes were to be enforced.

In understanding just how important these event-optimized campaign strategies have been for Facebook, it’s helpful to go back to 2017, when they had only just been rolled out. In Facebook’s App Event Optimization tool showcases the power of its data in Q1 earnings, published in May 2017, a little less than a year after AEO had been introduced, I wrote:

Facebook’s AEO product is another example of the advertising giant utilizing its massive data set on users as a competitive advantage that is almost structurally unbeatable. Other networks can optimize around in-app events, and some do, but they don’t have the first-party engagement data or the deterministic profile data that Facebook does to cluster players together based on propensity to spend. Absent those data sets, AEO is hard to do: since very few people spend money in apps, a lot of data is needed in order to build robust proxy signals for spending. Facebook has that data and almost no one else does.

ARPU in Facebook’s most important market (North America) increased 9.75% and 9.81% quarter over quarter in Q2, when AEO was introduced, and Q3 of 2016, versus 4.85% and 6.43% worldwide. Yet the quarter-over-quarter increase for North America was roughly equivalent to that of worldwide from Q1 2016 to Q2 2016, before AEO was launched.

It’s important to keep in mind that the introduction of the AEO campaign strategy was a means of improving per-user monetization in high-ARPU geographies for Facebook: AEO is designed to focus a campaign’s reach on users that are likely to complete some event, meaning costs of installs increase, but the value of each acquired user increases enough to create viable unit economics. In other words: AEO campaigns are designed to be, relative to campaigns that simply optimize for installs, low volume and high ARPU.

It bears pointing out that there are really only three ways for Facebook to increase its revenue: to scale its user base, to increase ad load, or to increase the value of its ad inventory. In North America, Facebook only increased DAU by 35% between Q4 2016 and Q4 2019 while its (global) revenue more than doubled from 2016 to 2019. And while ad load has certainly increased in that period, Facebook’s CFO noted in 2016 that ad load would reach a natural limit across its core portfolio of apps at some point in the near-term future. It seems likely that the source of Facebook’s revenue growth from 2016 until today was its ability to increase the value of its inventory through event-optimized campaigns like AEO — which, as the diagram above points out, are heavily dependent on user profiling.

The primary beneficiaries of AEO and VO campaigns, and generally Facebook’s increased capacity for precision ad targeting, have been smaller advertisers and SMBs: they were given access to the types of sophisticated targeting machinery that would have been wholly inaccessible to them otherwise. The point I made when Google subsumed all of its mobile app advertising inventory into the UAC product was that, while the lack of transparency of UAC might have irritated larger advertisers, the product gave small companies the ability to advertise by leveraging Google’s incredible advertising tools. These event-optimized, algorithmic targeting tools not only drove ARPU increases but they created opportunities for efficient advertising for smaller companies who otherwise wouldn’t be able to spend money on performance marketing at all.

Some caveats. It should be noted that IDFA deprecation only impacts app advertising campaigns, not web advertising. Although Facebook revealed that 94% of its 2019 advertising revenue was generated on mobile, the company doesn’t break that out between mobile web advertising (eg. a user clicks on an ad and is taken to a website) and mobile app advertising (eg. a user clicks on an ad and is taken to an app store). It’s also worth mentioning that, as of now, only the iOS device identifier has been deprecated (and even then, only effectively deprecated: some percentage of users will elect to opt into ad tracking, and their IDFAs will be exposed to Facebook), and the GAID on Android devices is still accessible to all apps for ad tracking.

But my best guess is that the majority of Facebook’s mobile advertising revenue is driven by app advertising, and I believe that Google will deprecate the GAID within six months. So the changes introduced in iOS 14 represent real, immediate problems to Facebook’s revenue growth. With IDFA deprecation, the strand of hair dangling the Sword of Damocles above the throne has snapped. Facebook might expect to see its revenue decrease by some meaningful percentage: just a few days before WWDC 2020, Facebook published a white paper in which it revealed that ad personalization accounts for 50% of CPM prices on Facebook’s Audience Network (the aggregated inventory across 3rd-party apps for which it manages ad targeting and serving). The conclusions in the article are withering:

It seems nearly impossible that advertisers won’t face deteriorating economics on Facebook in the short term as IDFA deprecation materially impairs Facebook’s ability to precisely target users. Over the long term, I believe that Facebook will find a path to its current level of ad serving efficiency without needing advertising identifiers. But the content of its own white paper underscores very clearly how important personalization is for ad targeting, and IDFA deprecation damages Facebook’s ability to deliver that kind of personalization.

Photo by Ricardo Cruz on Unsplash

]]>
https://mobiledevmemo.com/idfa-deprecation-is-facebooks-sword-of-damocles/feed/ 0 30211
Why is Apple rebuilding the App Economy? https://mobiledevmemo.com/why-is-apple-rebuilding-the-app-economy/ https://mobiledevmemo.com/why-is-apple-rebuilding-the-app-economy/#respond Mon, 13 Jul 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30161

What motivated Apple to deprecate the IDFA? In order to get there, it’s important to try to understand what kind of a future Apple wants for the App Store and the app economy more broadly.

Gauging the impact on the mobile ecosystem of Apple’s recent decision to deprecate the IDFA, it seems that the tendency to minimize the scale of what this decision accomplishes — that is, to believe that IDFA deprecation won’t have a significant impact on the mobile ecosystem, and that simple workarounds will be found to provide user-level attribution — is commonly predicated on a belief that Apple fundamentally supports a robust mobile app advertising industry. Apple increasingly sees services revenue as its primary growth vector, and platform fees from the App Store make up some substantial component of that.

Many arguments I’ve heard around why the IDFA deprecation is actually not going to have a tremendous impact on the mobile app economy center around the idea that Apple would not cripple the industry, mobile app advertising, that drives almost all app adoption because doing so would harm its services revenue growth. Surely Apple wouldn’t cut off its nose to spite its face — it wouldn’t cause great injury to a very important revenue stream just because it systemically holds strong antipathy towards advertising and the freemium business model. Right?

My sense is that understanding the what of IDFA deprecation — that is, how it will be implemented and what its consequences will be — requires understanding the why. I believe that there are four broad motivations that explain why Apple deprecated the IDFA:

User privacy. This is obvious: with the IDFA deprecated via the tracking opt-in mechanic, users have more granular control over what data is collected about them and used for ad targeting purposes. Given that Limit Ad Tracking (LAT) rates on iOS currently stand at 30%, and the LAT setting is relatively difficult to find, it stands to reason that consumers actually care about their privacy and appreciate the power to control how companies use data about them.

Growing its own advertising network. As I wrote about back in May, Apple has increased the scope of its Apple Search Ads network to include placements in owned-and-operated apps. It’s unclear to me how IDFA deprecation could give Apple a competitive advantage in targeting ads except that, since Apple operates the storefront and the last point of contact with the user in the app discovery journey, perhaps ASA ads are seen as more attractive than those from other providers and ASA revenues increase as a result. To be clear, I don’t believe that this was the primary motivation behind deprecating the IDFA, but surely it factored into the decision.

Hurting Facebook. Apple has been engaged in something of a Cold War with Facebook since at least 2017, which I detail in this long article.

Taking back control over app distribution. This is, I feel, Apple’s primary motivation in deprecating the IDFA: ads have become the foremost mechanic through which apps are discovered, and Apple has lost total editorial control over content distribution. Related to the point above, Facebook is the primary beneficiary of this dynamic: Facebook ads front-run organic search and discovery, and Facebook effectively serves as the principal point of app discovery.

Apple is obsessed with the consumer experience in its products, yet it has no control over which apps are popular or even which apps appear in the Top Charts because it has ceded editorial control to ad platforms. Deprecating the IDFA helps Apple to regain some of that control.

None of the motivations above suggest that Apple will not fully and aggressively police both the spirit and the letter of its new ad tracking policy (implemented via the opt-in mechanic). Taken together, as a whole, they suggest that Apple sees this decision as an opportunity to completely rebuild the App Economy: to fundamentally change the way in which apps are discovered and attain popularity by impairing the kind of precision targeting that currently drives app adoption.

The whys provided in the above four motivations don’t seem likely to be accomplished with a half-hearted, milquetoast implementation of limited ad tracking: for example by allowing ad tech companies to fingerprint users. The whys that inspired the deprecation of the IDFA speak to a modernization of the app economy that targets its very foundation.

Photo by Scott Blake on Unsplash

]]>
https://mobiledevmemo.com/why-is-apple-rebuilding-the-app-economy/feed/ 0 30161
Podcast: Surfing in a Squall: the future of mobile without an IDFA, with Maor Sadra https://mobiledevmemo.com/podcast-surfing-in-a-squall-the-future-of-mobile-without-an-idfa-with-maor-sadra/ https://mobiledevmemo.com/podcast-surfing-in-a-squall-the-future-of-mobile-without-an-idfa-with-maor-sadra/#respond Wed, 08 Jul 2020 19:44:55 +0000 https://mobiledevmemo.com/?p=30141

In this episode of the Mobile Dev Memo podcast, I speak with Maor Sadra about why the deprecation of the IDFA (announced at this year’s WWDC event) should not have been surprising to people who follow the mobile ecosystem, why deterministic app install attribution wasn’t as reliable as people thought in the first place, and what the future of mobile looks like without the IDFA.

]]>
https://mobiledevmemo.com/podcast-surfing-in-a-squall-the-future-of-mobile-without-an-idfa-with-maor-sadra/feed/ 0 30141
Dear Apple: These changes will improve SKAdNetwork for advertisers https://mobiledevmemo.com/dear-apple-these-changes-to-skadnetwork/ https://mobiledevmemo.com/dear-apple-these-changes-to-skadnetwork/#respond Mon, 06 Jul 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30106

Dear Apple,

The privacy protections you are implementing in iOS 14 are indisputably good for consumers: these changes will give iOS users a level of granular control over their data that amplifies trust. In the short term, these changes present challenges to mobile advertisers, most of which have built infrastructure for which the IDFA is integral to advertising measurement and analytics. Advertisers will feel some pain as they transition away from this infrastructure, but I believe that the long-term consequences to advertising performance of user-level attribution being abolished are exaggerated.

As an analyst of the mobile ecosystem, I find it more beneficial to think about the durable solutions to changes that will persist three to five years from now than devoting energy to thinking about short-term workarounds or loopholes that will only be viable for some number of months. It is for this reason that I believe all advertisers would benefit from planning their infrastructure around SKAdNetwork, which is the long-term solution to advertising measurement on iOS. You have made it clear that fingerprinting will not be allowed if a user has opted out of ad tracking, and other similar, awkward shortcuts are unlikely to be workable for enough time to be interesting.

It is also for this reason that I believe it worthwhile to propose changes to SKAdNetwork that will benefit advertisers while still preserving Apple’s core commitment to user privacy. SKAdNetwork can be an incredible tool for mobile advertising measurement, but in the incarnation described in its technical documentation, it lacks some critical functionality.

A spirited discussion is taking place on the Mobile Dev Memo Slack around how SKAdNetwork will be implemented and how advertisers will be able to transition to this new paradigm. Allowing advertisers’ voices to be heard now will likely alleviate the need to police loopholes and workarounds later. Most advertisers with whom I’ve spoken in the weeks since WWDC20 want SKAdNetwork to succeed as the permanent solution for mobile measurement on iOS; allowing advertisers to become invested in its development is a win for the entire ecosystem. This ecosystem, including Apple, should be aligned around a privacy-centric measurement solution that facilitates advertising growth, and the concomitant increases in developer and platform revenues that result.

That said, I believe there are improvements that can be brought to three functional components of the SKAdNetwork workflow: conversion measurement, campaign tracking, and data retrieval.

SKAdNetwork Conversion Measurement

The current SKAdNetwork conversion measurement logic is overwrought and complex, and the way that conversion identifiers are implemented doesn’t provide enough value to the advertiser. A conversion event should be useful to an ad network in optimizing its targeting within the context of some optimization objective. The current implementation of the conversion identifier only allows for one event — the highest value recorded via the 6-bit field within some cycle of a resettable timer — to be associated with an install attribution, meaning the source network receives no insight into the number or magnitude of the events fired by the user.

A more helpful approach would be to create a second postback type specifically for conversion events. Ad networks use conversion events to target the most engaged users: the magnitude and frequency of events are important considerations of campaign success. Further, the construction of the current conversion event timer logic incentivizes app developers to concentrate their monetization mechanics very early in the user lifecycle so as to produce meaningful monetization signals as quickly as possible. This will result in a degraded user experience: users will feel like their pockets are being picked with aggressive sales tactics, especially with subscription apps, which will need to find ways to incentivize immediate subscriptions so as to feed their ad networks with conversion events in order to capture any monetization data.

Sending conversion events as separate postbacks will allow ad networks to track the magnitude and frequency of these events at the campaign level without incentivizing app developers to front-load the user experience with monetization hooks. And privacy would still be preserved: the ad networks that receive these events back wouldn’t be able to tie them to individual users since they have no insight into the cohort to which the installs belong, and thus they would be prevented from using this information to build device graphs.

SKAdNetwork Campaign Tracking

There are a number of issues with the existing incarnation of SKAdNetwork that prevent campaigns from being optimized effectively. The first and most obvious of these is the arbitrary limit of 100 tracked campaigns. I understand that advertisers can micro-target campaigns in such a way that could lead to near-deterministic attribution, but 100 campaigns is simply too few to allow for adequate segmentation, especially in this new paradigm that reverts campaign management strategy back to circa 2014-2015 best practices. A limit of 1,000 campaign identifiers would achieve the same privacy objective while also giving advertisers enough agency to segment traffic competently.

Second, a campaign identifier isn’t sufficient for optimizing and iterating on ad creative. Advertisers really need an advertisement identifier to be able to build creative production processes that allow them to hone messaging.

SKAdNetwork Data Retrieval and Aggregation

The current workflow, in which a postback is sent to the ad network that generates an install, allows ad networks to optimize campaigns, but it creates some complications by granting first party ownership of attribution data to the ad networks. Users don’t have relationships with ad networks, they have relationships with apps: is it not more seamless and sensible to give advertisers first-party access to install data and let them decide with whom they share it?

Consider making attribution data available to advertisers directly via API. Advertisers could connect directly to the API and ingest all of their attribution data, across all ad networks, in one place, as opposed to the current solution which requires advertisers to ingest data from each of the advertising network that they work with. The current flow of data — from the SKAdNetwork SDK in the app to the ad network — gives ad networks an incredible level of power in determining how that data is subsequently transmitted. Advertisers should have a means of accessing their attribution data without depending on the ad network sending it to them (or any other party).

The current flow of data also burdens app advertisers with a daunting amount of overhead, requiring them to build connections to every one of their ad partners’ APIs in order to ingest siloed advertising data. As anyone who has ever built a cost aggregation system for advertising spend knows, these APIs change and break frequently, causing data availability issues that occur with frustrating regularity.

Conclusion

SKAdNetwork is the future of mobile attribution on iOS, and it will play a critical, focal role in mobile advertising measurement. But an ounce of prevention is worth a pound of cure with SKAdNetwork: by engaging with advertisers and app developers around what they need in an attribution system, Apple can avoid the cat-and-mouse game that will inevitably emerge as ad tech companies create workarounds for user-level attribution that violate the spirit of the changes introduced in iOS 14.

The next few months present a valuable opportunity to re-cast mobile advertising with consumer privacy as a fundamental precept. I think SKAdNetwork can both allow advertisers to perform the measurement necessary to grow their revenue through performance advertising and protect consumer privacy, but it’s currently missing core functionality if it is to replace install attribution on iOS completely.

Photo by Nizzah Khusnunnisa on Unsplash

]]>
https://mobiledevmemo.com/dear-apple-these-changes-to-skadnetwork/feed/ 0 30106
Introducing the Modern Mobile Marketing at Scale online course https://mobiledevmemo.com/introducing-the-modern-mobile-marketing-at-scale-online-course/ https://mobiledevmemo.com/introducing-the-modern-mobile-marketing-at-scale-online-course/#respond Wed, 01 Jul 2020 05:29:00 +0000 https://mobiledevmemo.com/?p=29778

Modern Mobile Marketing at Scale was an in-person, 8-hour workshop that I presented in New York, San Francisco, and London last year and had intended on presenting three more times over the course of 2020. I spent nearly 3 months developing the content, which is a comprehensive review of mobile marketing: analytics and reporting, creative strategy, cohort analysis, and specific tactics and strategy for Facebook and Google UAC marketing.

Due to COVID, I have canceled the remaining workshops that were scheduled to take place over the rest of the year and adapted the content into an online course. The online course runs at more than four hours over six modules. The modules are:

  1. Modern mobile ad platforms
  2. Ad creative strategy
  3. Recoup analysis
  4. Analytics and reporting
  5. Facebook
  6. Google UAC

Modern Mobile Marketing at Scale is a great fit for people who want 1) a deep conceptual foundation in mobile marketing as well as 2) a broad primer on tactics that successful companies use to scale their marketing spend profitably to millions of dollars per month.

This course can benefit product managers, user acquisition managers who are being promoted to team lead positions, company executives, finance / accounting managers, creative directors, etc. The course provides an overview of the entire mobile marketing function, so students should leave with a very strong understanding of how user acquisition teams operate and systematically grow spend.

The course can be found here.

]]>
https://mobiledevmemo.com/introducing-the-modern-mobile-marketing-at-scale-online-course/feed/ 0 29778
Apple killed the IDFA: A comprehensive guide to the future of mobile marketing https://mobiledevmemo.com/mobile-advertising-without-the-idfa-a-comprehensive-overview/ https://mobiledevmemo.com/mobile-advertising-without-the-idfa-a-comprehensive-overview/#respond Mon, 29 Jun 2020 05:00:00 +0000 https://mobiledevmemo.com/?p=30032

Tremors from Apple’s bombshell revelation at WWDC last week that the IDFA will effectively be killed continue to reverberate. iOS 14 will be released in September, and if past iOS releases are any indication, more than half of all iOS devices will run iOS 14 by October. WWDC 2020 featured Apple’s Thanos moment: with a snap of its fingers, Apple obliterated a large proportion of the mobile ad tech ecosystem.

A brief overview of the IDFA-related changes that will be introduced in iOS 14:

  • Device IDFAs will be made available to specific apps on the basis of user opt-in via a pop-up at app open. LAT as a setting will continue to exist at the device level, meaning no apps will have access to the device IDFA if LAT is turned on;
  • Apple will use the SKAdNetwork API to receive meta data from ad clicks and to send postbacks from the app client to advertising networks that drive app installs. As of iOS 14, new parameters will be added to SKAdNetwork that provide information around the source publisher, and a conversion event;
  • The postbacks to ad networks can include ad campaign IDs, but only 100 values (labels 1-100) per ad network are available to be mapped;
  • The postbacks to ad networks can also include up to 64 conversion event IDs via a 6-bit conversion value;
  • The postbacks to ad networks will also include a “Redownloaded” flag that indicates whether the app is being downloaded by a user for the first time or not;
  • Postbacks will be sent based on a sequence of timers (the logic is somewhat complicated — more information on this below) and will include just one conversion event per attributed install. This means that advertisers won’t get absolute counts of events but rather counts of highest value events that users complete within the conversion measurement period;
  • IDFV, or ID For Vendors, will continue to be made available for publishers per device for all of their apps. What this means is that a publisher will have a unique device identifier available to it across its apps on any given single device. That is, if a user has installed three of my apps on her iPhone, I will have access to a unique IDFV for that user that is the same as accessed from all three of my apps.

In Apocalypse Soon, which I published in February, I outlined a hypothetical chain of events that began with Apple deprecating the IDFA at WWDC 2020. The IDFA has been living on borrowed time since the introduction of Limit Ad Tracking; its elimination was wholly foreseeable. I posted my thoughts on how the death of the IDFA will impact the mobile advertising ecosystem in this Twitter thread, which still represents my latest understanding. Below is more detail on the topics covered in the thread, as well as a few additional topics.

Opt-in rates for IDFA access

My belief is that user opt in rates for IDFA access will fall between 10-20%. Opt in rates will dictate the impact of these privacy changes on all aspects of the mobile advertising ecosystem, but with opt-in rates at the 10-20% level, the IDFA is effectively dead.

In an informal poll conducted in the Mobile Dev Memo Slack team, the majority of respondents indicated that they believe opt in rates for ad tracking will fall between 0-20% (see below). The language presented within the opt-in popup is intimidating: App X would like permission to track you across apps and websites owned by other companies (note that a second string of text underneath this one can be customized by the developer). This verbiage seems specifically designed by Apple to deter users from accepting tracking.

Attribution

I believe that deterministic, user-level app attribution will cease to exist once SKAdNetwork adoption reaches critical mass — likely by the end of the year or throughout Q1 2021.

I’ve heard the argument that some advertisers might continue to use MMPs to attribute the small (10-20%) subset of users that opt into ad tracking, because that sample of users could be used to extrapolate composition ratios to the broader set of acquired installs. For instance, if 30% of the opt-in users were acquired via Facebook ads, then that ratio might be applied to the cohorts of opt-out users whose provenance is unknowable — this knowledge could help advertisers budget ad spend, and would justify MMP tracking for the opt-in users.

But there is sampling bias inherent in this: the group of users that opt into tracking are unlikely to behave like those that don’t. We see this now with LAT users: LAT users for many advertisers tend to monetize better than non-LAT users, with the hypothesis being that they are more technically savvy (because they managed to find the LAT setting).

And even if the opt-in subset of users was useful for the purpose of extrapolating ratios, this small volume of attributions would not support the MMP industry at the scale that it currently exists: either dramatic consolidation would take place or a few of the major firms would simply fail as MMP budgets evaporate to 10-20% of their current level.

Another factor that will determine the fate of user-level ad attribution is Google’s adoption of opt-in tracking for Android. If Google doesn’t create an opt-in tracking mechanism for Android, then install attribution could continue to exist to serve the Android market. But this seems unlikely: Google and Apple operate more or less in lockstep with respect to privacy. Google introduced its LAT equivalent (Ads personalization) one year after Apple introduced LAT. Furthermore, Google has had attribution services in its crosshairs since at least 2017, when it introduced install attribution to Firebase.

It seems possible that MMPs adapt to this change by serving as auditors: receiving install receipts from ad networks, aggregating them, and reconciling campaign and event identifiers against naming conventions and revenue values, and using cost data to present probabilistic ROAS reporting.

This functionality would be useful and is almost certainly something that few advertisers want to build themselves, but it’s also mostly administrative: an accounting service of sorts that doesn’t unlock much value. Put another way: this isn’t a service that advertisers would be willing to pay tens of thousands of dollars per month for, and it wouldn’t support the current size and scope of the mobile ad attribution market. MMPs will need to pivot into lines of business that provide commercial insight if they want to continue to charge MMP prices.

Re-targeting and Custom Audiences / Lookalike Audiences

Re-targeting on mobile is currently done via advertising identifiers: an advertiser provides Facebook or a re-targeting DSP with a list of advertising identifiers that it wants to target, and those channels serve ads to those devices when a matching impression or bid request surfaces.

Without an advertising identifier to use in serving a specific device, it seems unlikely that re-targeting DSPs will be able to function as they currently do: they simply won’t be able to accurately identify a given device. Facebook will be able to facilitate re-targeting, since it can use any number of user-specific (versus device-specific) identifiers to target individuals: email addresses, phone numbers, etc. Back in 2014, I posited that Facebook acquired WhatsApp specifically to amass a large bank of phone numbers, which are perfect identifiers because they rarely change and are tied exclusively to a device (versus an email address, which is tied to an account that can be accessed from any number of devices).

This reality is likely to impact product design: developers will seek to either incentivize or simply require users to register accounts using their email addresses or phone numbers so that those identifiers can be stored and used for re-targeting and lookalike list construction. The ad platforms that don’t already offer lookalike and custom audience construction directly from lists (notably, Google UAC) will also likely roll these products out to compete with Facebook.

Of course, all of this assumes that Apple and Google are amenable to email being used as a proxy for the advertising identifier when users have explicitly opted out of ad tracking. A user might be horrified to know that they restricted an app’s access to their advertising identifier — which can be reset — only to have their email address, which is attached to many other aspects of their life, used for the same purpose. Note that Apple introduced its privacy-centric Sign in with Apple authentication service at last year’s WWDC; it could potentially enforce use of it as an alternative for user registration in apps to prevent exactly this scenario.

Managed DSPs

In discussing mobile DSPs in the new, IDFA-less environment, a distinction must be drawn between in-housed or self-serve DSPs, which facilitate advertiser-led programmatic media buying, and managed DSP services, which are utilized by advertisers essentially as ad networks.

As discussed in the recent MDM Podcast, How a bid becomes a DAU, the core value proposition of managed DSPs are their device graphs, or their lists of device advertising identifiers paired with knowledge around which of those devices have monetized, and in what apps. Once these device graphs become irrelevant, managed DSPs will lose competitive advantage over other programmatic solutions, even in-house DSPs. My former colleague Nebojsa Radovic summarized this dynamic in a Twitter thread:

It’s unclear what path forward exists for managed DSPs without advertising identifiers. Managed DSPs can of course optimize advertising campaigns at the publisher and placement level, but that level of granularity tends to not be efficient for advertising optimization: programmatic supply suffers from an adverse selection bias as most programmatic inventory is backfill. And if advertisers can in-house programmatic spend and be on equal footing with managed DSPs, why would they pay hefty fees to managed services?

updateConversionValue(_:)

The Conversion flag in an SKAdNetwork postback will allow the advertising network to receive notification that some conversion event has taken place from within traffic acquired by a campaign. This flag will allow ad networks to count events at the level of the campaign cohort, eg. Campaign X generated 15 counts of Event Y. But this is worth clarifying further.

Advertisers will be able to map up to 64 in-app events to identifiers (via the 6-bit conversion ID parameter in the SKAdNetwork postback) that will be sent to SKAdNetwork via the updateConversionValue method when executed. Whenever an install is attributed by SKAdNetwork, a rolling 24-hour postback timer begins counting down to 0, and each time a mapped event is fired, the timer resets. Once the timer reaches 0, the postback is fired to the ad network that supplied the install.

A mapped event identifier will only be recorded for the postback if either no conversion event has yet to be recorded for the attributed user or if the identifier is larger than that which is previously recorded for the attributed user. According to the SKAdNetwork documentation, it seems that the postback timer can be reset up to 64 times, so long as increasing event identifiers are being recorded. Once the initial timer completes, Apple begins another timer on a random length of time between 0 and 24 hours to obfuscate the source of the event, and the postback is fired when that second timer completes.

This postback logic will dramatically alter app monetization design: advertisers will aspire to strike a meaningful balance between minimum elapsed time between install and postback receipt and maximum monetization and / or engagement signal contained within the postback (ie. higher values of the conversion event carrying important information about the value of the user).

Developers will strive to instrument their apps such that the most valuable users fire as many of the 64 events as possible within the first few sessions of app use to facilitate the postback being received in a timely manner. This new dynamic will accelerate the existing trend of integration between app monetization and user acquisition: the user acquisition team of the very near future will play a central role in designing the content path that users take before a conversion event is fired via SKAdNetwork.

Event-optimized campaigns

Since networks receive conversions, they can optimize campaigns against them, albeit not at the granularity level of individual user identifiers, and not with exact event counts: if a network receives a conversion identifier, it will only know that the event mapped to that identifier executed at least once, but it won’t know whether that event executed more than once or if any other events with lower identifier values were executed.

Facebook, for instance, could use these conversion receipts to optimize targeting with broad demographic features as well as to build correlations between targets and app types. This won’t be as efficient as its current method, which uses the features of individual users — especially monetization history — to hone targeting for the App Event Optimization (AEO) campaign strategy, but it will still allow for event-optimized targeting.

The Value Optimized (VO) campaign strategy is harder to execute without advertising identifiers because it relies on the magnitude of monetization expected from an individual user — if the advertiser is unable to post all revenue events back to Facebook with user identifiers attached, and Facebook can only receive the one event signal per user per campaign (absent any revenue data), then Facebook has no way of gauging magnitude of monetization or engagement. All of this similarly applies to tCPA / tROAS campaigns on Google’s UAC.

I believe that the shift to SKAdNetwork-tracked conversions might actually benefit ad networks that compete with the Self Attributing Networks (SANs). Currently, many advertisers withhold conversion events from non-SAN ad networks in an attempt to hide the identities of their most valuable users from them: if an ad network knows that User X monetized in App A, the network might specifically target User X for App B‘s campaigns in order to improve their conversion efficiency. Given that revenue context is excluded from the SKAdNetwork postbacks, there’s no reason for any advertiser to withhold that information from ad networks, and they are put on equal footing with Facebook and Google.

In-app ad monetization

In-app monetization is governed by the same forces that change the economics of DSP advertising. Header bidding especially will be fundamentally impacted by a lack of advertising identifiers: header bidding provides for a programmatic unified auction that allows advertisers to bid on inventory at the ad level (versus ad waterfalls, which bid on CPM values that are set intermittently based on historical averages).

It seems likely that the eradication of advertising identifiers depresses CPMs across the board because performance will only be measurable at the campaign level. It is very difficult to make the economics of programmatic buying work if individual users can’t be targeted based on proprietary information. If bid logic reverts back to historical campaign performance (via the conversions logged with SKAdNetwork postbacks), then header bidding — which, again, provides the ability to bid at the level of an individual impression — won’t really confer any advantage over CPM-based waterfall ad mediation.

Cross promotion

One interesting tidbit found in the updated SKAdNetwork documentation is the fact that the Identifier For Vendors (IDFV) will remain accessible regardless of whether a user has opted into ad tracking. The IDFV is a unique device identifier available to app developers across its own apps on a given user’s device. For example, a User X might have three of Developer A‘s apps installed on her phone: App 1, App 2, and App 3. In this case, Developer X would have access to a unique IDFV for User X within its own apps on User X‘s phone: it could use this to store engagement and monetization data for User X across all three of its apps.

The IDFV cannot be used for acquisition attribution, but it can be used to great effect for cross promotion, which might provide a competitive advantage to developers that oversee portfolios of apps that feature large MAU. And the IDFV might become an important vector of M&A: a developer might not be able to transparently acquire high-value users, but it can acquire developers with large but declining user bases and cross promote those users across its existing portfolio on the basis of monetization history. I discussed the power of an intelligent cross promotion mechanism for developers with large portfolios in my 2016 GDC presentation about my efforts in building an internal ad network at Rovio.

What’s the net impact?

More important than how the privacy changes to iOS announced at WWDC 2020 impact the mobile ad tech ecosystem is how they impact consumers. My personal opinion here is that an app-level tracking opt in mechanism provides users with an even more granular level of control over their personal data, and in that respect, this is a welcome and positive change to the ecosystem.

I think the net impact of these privacy changes to advertisers is neutral to slightly negative. Advertisers won’t have attribution transparency at the user level, but as I argued in the beginning of this piece and in Media mix models are the future of mobile advertising, that transparency in the current paradigm is, to a large degree, a facade: last-click attribution provides advertisers with the veneer of control and measurability, but the reality is that the pool of users swirling throughout the overlapping fields of vision of the major ad networks has rendered value attribution impossible. And Google and Facebook had an unfair advantage in poaching the last click for most ad interactions, anyway.

Many sophisticated advertisers have been moving towards top-down, macro-level incrementality models over the past 12-24 months. The loss of device-level identifiers will hasten that transition out of necessity, but that doesn’t also mean it’s not the most prudent approach to advertising. Fast forwarding two or three years, I don’t think the mobile advertising ecosystem — from an advertiser’s perspective — looks meaningfully different now than it would have if Apple had announced business as usual for the IDFA at WWDC 2020. This trajectory had already been established.

Obviously the impact of tracking opt-in on much of the mobile ad tech terrain will be more severe, and the outlook for companies residing in those outposts is not as rosy.

Caveat lector

Apple’s privacy announcement from WWDC 2020 is only one week old, and the documentation they have released about the updates coming to SKAdNetwork are, in many places, incomplete or vague. The above represents my best guess at what will happen to the mobile advertising ecosystem, which is complex and multi-faceted, over the next 6-24 months. My opinion has been informed by exhaustive study of Apple’s documentation and through talking to a large number of people across the ecosystem, but my perspective is limited by the amount of information available. I believe that I approach this topic objectively and without any inherent bias, but readers should judge that for themselves.

Thank you

I have gained very valuable perspective around the changes coming to iOS 14 by speaking with people over the past few months whose opinions and insight I value greatly. Thank you to: Gadi Eliashiv, Nebojsa Radovic, Thomas Petit, David Barnard, David Philippson, Dick Filippini, Maor Sadra, and John Koetsier.

]]>
https://mobiledevmemo.com/mobile-advertising-without-the-idfa-a-comprehensive-overview/feed/ 0 30032