Mobile Dev Memo https://mobiledevmemo.com Mobile advertising and freemium strategy. Mobile marketing, analytics, and monetization. Wed, 23 Sep 2020 15:43:33 +0000 en-US hourly 1 58872998 The IDFA is the hydrocarbon of the mobile advertising ecosystem https://mobiledevmemo.com/the-idfa-is-the-hydrocarbon-of-the-mobile-advertising-ecosystem/ https://mobiledevmemo.com/the-idfa-is-the-hydrocarbon-of-the-mobile-advertising-ecosystem/#respond Wed, 23 Sep 2020 15:36:46 +0000 https://mobiledevmemo.com/?p=30792

Privacy violations by consumer technology companies and advertising platforms create negative societal externalities that go largely uncompensated for: deteriorating trust in online properties and communities from users, a gray market in aggregated user data that can create opportunities for identity theft, and even the degradation of some users’ states of mental health. Online privacy protections have become a popular point of concern both for governments and for platform operators, and public apprehension has yielded legislation such as Europe’s GDPR and California’s CCPA. Apple’s deprecation of its device identifier, the IDFA, was also ostensibly motivated by consumer privacy concerns.

The IDFA is the hydrocarbon of the mobile advertising ecosystem: it is the sine qua non of the device-centric targeting paradigm that drives advertising performance on mobile. Just as burning hydrocarbons is integrated centrally into the world’s energy infrastructure, the IDFA is the indispensable input to mobile advertising measurement and targeting. And just as transitioning away from the hydrocarbon requires a formidable investment into new energy infrastructure and technology, so does transitioning away from the IDFA.

I have argued that personalized advertising is a public good. Personalized advertising allows:

  1. Advertisers to reach relevant audiences efficiently;
  2. Publishers to maximize the yield they generate by serving ads to users;
  3. Users to enjoy content for free that they otherwise would pay for.

Ahead of Apple’s decision to delay the implementation of the privacy controls that will effectively deprecate the IDFA in iOS14, I argued that the company was acting hastily and without concern for the welfare of not just advertisers and publishers but also users. Just as the entire energy economy can’t transition away from the hydrocarbon at the snap of some major company’s fingers without completely disintegrating, neither can the app economy with the IDFA.

The IDFA needs to be jettisoned systematically and thoughtfully. Advertisers will feel pain in the short term during the transition phase, but the externalities it creates exist as a sort of ticking time bomb. Consumer patience with invasive behavioral tracking has been exhausted, and rightly so. The mobile advertising industry should view this forced change as an opportunity to fundamentally transition to probabilistic models that don’t distinctly identify and track users, rather than trying to maintain the status quo using different data. And this should be done in a way that sustains personalized advertising.

Heavy-handed regulation from either governments or from platform operators is ultimately harmful for advertisers, publishers, and potentially consumers. Apple’s motivations in deprecating the IDFA are not necessarily totally benevolent with respect to user privacy. Apple operates an ad network, and the deprecation of the IDFA gives it much more editorial control over the App Store than it currently has. The deprecation of the IDFA harms Facebook, Google, et al, but does it unequivocally benefit the consumer, especially as consumers’ favorite products become economically non-viable as a result of degraded advertising efficiency?

And GDPR is a case study in unintended consequences, having granted Facebook, Google, and other large consumer technology companies with an incredible advantage over upstart challengers.

Believing that any industry will police itself in a way that constrains profits is naive and unrealistic. Further regulation of online advertising is inevitable. The negative externalities caused by privacy violations must be recognized if any sort of advocacy in that process from the advertising industry — designed to preserve the public good that is personalized advertising — is to be considered serious and genuine.

Photo by Patrick Hendry on Unsplash

]]>
https://mobiledevmemo.com/the-idfa-is-the-hydrocarbon-of-the-mobile-advertising-ecosystem/feed/ 0 30792
Updated for iOS14: The Modern Mobile Marketing at Scale Online Course https://mobiledevmemo.com/updated-for-ios14-the-modern-mobile-marketing-at-scale-online-course/ https://mobiledevmemo.com/updated-for-ios14-the-modern-mobile-marketing-at-scale-online-course/#respond Mon, 21 Sep 2020 14:28:14 +0000 https://mobiledevmemo.com/?p=30805

The Modern Mobile Marketing at Scale course has been updated to include a new module dedicated to iOS14. The module covers:

  • An overview of the privacy changes coming to iOS14 next year;
  • An analysis of Apple’s SKAdNetwork 2.0 framework for ads measurement;
  • Strategy guidelines for scaling ad spend efficiently in the post-IDFA environment.

The course is comprised of 7 modules and runs five hours in length. More info here. If you have previously purchased the course, you will automatically have access to the new content.

]]>
https://mobiledevmemo.com/updated-for-ios14-the-modern-mobile-marketing-at-scale-online-course/feed/ 0 30805
Does digital advertising create demand? https://mobiledevmemo.com/does-advertising-create-demand/ https://mobiledevmemo.com/does-advertising-create-demand/#respond Mon, 21 Sep 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30312

What role does digital advertising play in the adoption of mobile digital products? Does advertising motivate people to download apps that they otherwise wouldn’t have without an inducement, or does it simply serve as a demand fulfillment mechanism, surfacing the most relevant products to people on the basis of targeting?

David Ogilvy, in his seminal book Ogilvy on Advertising, published in 1985, writes:

It is often charged that advertising can persuade people to buy inferior products. So it can – once. But the consumer perceives that the product is inferior and never buys it again. This causes grave financial loss to the manufacturer, whose profits come from repeat purchases.

The best way to increase the sale of a product is to improve the product.
This is particularly true of food products; the consumer is amazingly
quick to notice an improvement in taste and buy the product more often.
I have always been irritated by the lack of interest brand managers take
in improving their products. One client warned me, ‘You are too prone
to criticize our products. We could find it easier to accept criticism of
our wives.’

The question about demand creation is germane in the context of iOS 14 and the broader platform momentum within digital marketing towards a privacy-centric, de-personalized ad serving environment. If efficiency is lost in the forced abandonment of ads personalization, will a concomitant — potentially even disproportionate — decrease in consumer spending result? Put another way: if ads are no longer as effectively driving mobile install and in-app purchases, does the consumer spend that is precipitated by personalized ads evaporate, or is it simply routed elsewhere?

Some people argued after WWDC 2020 that privacy controls would not be strictly implemented into iOS14 because any harm inflicted on advertising efficiency would proportionately be inflicted onto App Store revenues, which would in turn harm Apple. Socrates posited that no one would intentionally harm themselves; self harm is committed out of ignorance, not intent. Would Apple undercut its own App Store revenues — part of its increasingly-important services revenue — for the sake of increased user privacy?

It’s important here to consider the dynamics at play when Apple’s new privacy controls go into effect and how they impact Apple’s revenue:

  • Mobile advertising becomes less efficient, meaning App Store revenues decrease (most advertising is done at very thin margins: if efficiency drops, not much profit exists to absorb that drop, and so spend must decrease. I describe this phenomenon in this article). Apple takes less from its 30% platform fee for apps that grow through advertising in this case, meaning its App Store services revenue drops;
  • Apple’s own ad network potentially becomes more attractive, since it offers contextual (versus behavioral) targeting, meaning its ad network services revenue increases. This is supported by the fact that Apple exempted its own ad network from iOS14 privacy controls;
  • Apple regains editorial control over the App Store, meaning it better curates the App Store experience and decides which apps become successful. Apple likely believes it can hand-craft a better App Store experience than what is being delivered now through paid advertising, potentially increasing brand loyalty and adoption, meaning its hardware sales potentially increase. This is a little tenuous, and it is certainly more abstract of a benefit than ad network revenues, but I think it played a major role in Apple’s decision to deprecate the IDFA.

I added a qualifier to the first bullet that must be unpacked:

Apple takes less from its 30% platform fee for apps that grow through advertising in this case, meaning its App Store services revenue drops.

The qualifier is important because it highlights what Facebook, Google et al have become very adept at over the past few years: not creating demand, but routing demand based on monetization potential. Facebook’s auction takes a user’s historical behavior into account when evaluating whether an ad should be exposed to them. If historical behavior didn’t play a part in Facebook’s (and Google’s, and other networks’) auction mechanics, then the deprecation of the IDFA would be immaterial.

What the IDFA facilitates is a real-time events stream from every mobile app back to Facebook, where Facebook uses its visibility into in-app behavior to build monetization and engagement profiles on its users for the purposes of ad targeting. That data helps Facebook connect users to ads for the products they are most likely to spend money in. All of Facebook’s advertising machinery is designed around matching previously-exhibited demand with relevant products.

Obviously new products get launched all the time, and those products are advertised for, but Facebook’s bread and butter is providing advertisers that have built very effective monetization machines (apps, DTC products, etc.) with an avenue to relevant users that have a proven affinity for some type of product. Facebook is able to reach these users with the right messaging, using real-time creative testing against sub-groups of the target audience, at a price dictated by the monetization potential of the destination product. This process effectively front-runs organic discovery: users don’t need to search for products on the App Store because they are exposed to relevant products on Facebook and elsewhere before they perceive any sort of need for what they’re ultimately looking for.

Because Facebook connects users with the products with which they’re most likely to monetize to the greatest possible extent, Apple will lose some platform revenue with the IDFA deprecation, because those optimal connections won’t be made and organic search might produce a lower level of overall monetization.

But monetization won’t go to 0. If ad efficiency drops by 50%, it’s not as if everyone spends 50% less going forward: they might end up organically searching for apps in which they only spend 70%, or 80%, or 90% of what they potentially could.

Because ads aren’t creating demand but optimally routing demand, install activity likely won’t change, it’ll just be driven by an increased amount of organic search. And while that organic search may not link users with the apps in which they’ll monetize most, users will continue to monetize. Demand won’t dissipate with the deprecation of the IDFA and the deterioration of ad efficiency, it will just be served by different fulfillment mechanisms.

Photo by Jess Bailey on Unsplash

]]>
https://mobiledevmemo.com/does-advertising-create-demand/feed/ 0 30312
The right thing for the wrong reasons: the TikTok and WeChat ban https://mobiledevmemo.com/the-right-thing-for-the-wrong-reasons-the-tiktok-and-wechat-ban/ https://mobiledevmemo.com/the-right-thing-for-the-wrong-reasons-the-tiktok-and-wechat-ban/#respond Fri, 18 Sep 2020 15:04:45 +0000 https://mobiledevmemo.com/?p=30779

On Friday, September 18th, the US Commerce Department announced what amounts to a ban of TikTok and WeChat in the United States. The scope of the ban is explained fully in the below set of tweets:

View Post

Essentially, WeChat and TikTok will no longer be available for download in the United States starting on September 20th (for WeChat) and November 12th (for TikTok).

This is the right thing to do, and it’s being done for the wrong reasons. The Chinese government demands that all Chinese-domiciled companies share commercial data with them upon request. It’s simply indefensible that a scaled social media product be allowed to operate in the US without any sort of restrictions placed on the data it collects from users if that product’s owner is compelled to share data with the government of the country in which it is domiciled. TikTok’s user base grew by 75% in the US from the beginning of the year: according to App Annie, it has nearly 54MM weekly active users in the United States, for almost 17% of the American population.

But these bans are clearly being instated for political reasons. The circus that was the original forced brokerage of TikTok’s US operations ended up doing nothing but gifting Oracle, a company helmed by a vocal supporter of the current administration, with a sweetheart cloud services deal. The national security interest was not bolstered; instead, a vociferous advocate for the administration’s policies was handed a lucrative contract for managing hosting and delivery in the US, despite his company, Oracle, having no ostensible expertise in social network delivery.

It appears that the proposed Oracle-TikTok deal, which tentatively passed regulatory scrutiny, was not weighty enough to appease the administration, and thus the proposed bans today. Is the Commerce department attempting to force an outright sale? Or is this simply posturing at the prelude of a trade war?

Either way, it’s reckless. If these rules are to be conjured and these boundaries are to be delimited, then those things should be so done systematically and with a sober sense of import. The dizzying volatility and capriciousness that has animated this entire episode is a scandal. The outcome of this moment will define the American commercial environment, especially as it concerns the technology sector, going forward: it needs to be constructed thoughtfully and with a sense of seriousness, without the dark shadow of venality and inside dealing that the Oracle deal casts.

Heightened scrutiny and data harvesting standards should be applied to products that share data with the governments of their domiciled countries, but the right thing for the wrong reasons isn’t something that can be celebrated.

]]>
https://mobiledevmemo.com/the-right-thing-for-the-wrong-reasons-the-tiktok-and-wechat-ban/feed/ 0 30779
What will Google’s deprecation of GAID look like? https://mobiledevmemo.com/what-will-googles-deprecation-of-gaid-look-like/ https://mobiledevmemo.com/what-will-googles-deprecation-of-gaid-look-like/#respond Mon, 14 Sep 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30719

Consensus opinion within the mobile advertising ecosystem suggests that Google will follow Apple’s lead with IDFA deprecation and deprecate its own proprietary, device-level advertising identifier, the GAID. Google has mostly stayed in lockstep with Apple regarding privacy:

Assuming that Google does emulate Apple’s strategy with respect to device identifiers, it’s interesting to consider whether Google’s platform policy change will differ substantively from Apple’s. In How might IDFA deprecation have minimal impact?, I consider whether Google might institute privacy controls that don’t mechanically mirror those announced by Apple at WWDC. If Google implements privacy controls that are functionally different from Apple’s, what might they look like?

Before attempting to answer that question, it’s first important to consider two other aspects of the situation:

  • Why does Google have to take any action? The short answer: because it historically has taken direction from Apple on privacy (or, at least, it has tried to match its initiatives), and because Google is almost certainly facing an imminent anti-trust lawsuit from the US Justice Department focusing on the company’s Search and Advertising businesses. The optics of falling behind Apple on privacy controls would be troublesome for Google;
  • Why might Google not simply institute the exact same privacy control mechanics as Apple has? Google is, first and foremost, an advertising company. It has to preserve the efficacy of its advertising engine, and the implications on its other businesses are problematic if it completely deprecates the GAID. Note that Google granted itself a two-year timeline for eliminating third-party cookies in Chrome: taking a softer approach than Apple on privacy-related issues is not unprecedented for Google.

So what might GAID deprecation look like on Android? I think a good place to start in contemplating that is Firebase, Google’s mobile analytics suite. Firebase natively offers ad campaign attribution, although the adoption of that functionality has been relatively limited given the inherent conflict in having an ad platform manage measurement for an advertiser. But nonetheless, that functionality exists: it seems like an excellent foundation on which to build privacy controls in a form that mirrors Apple’s SKAdNetwork framework but retains more information. Google could implement privacy controls by preventing any SDK except Firebase from accessing the GAID and forcing developers to use Firebase as a measurement solution.

As a platform-owned measurement solution that sits on the device via SDK, Firebase could send GAID-indexed event streams to ad networks while only making aggregated campaign-level data available to advertisers via API. This would allow ad networks to continue to optimize campaigns based on user-level event streams while withholding the GAID from advertisers and publishers and preventing campaign-level attribution.

Firebase can access the GAID even if it isn’t available to the advertiser or the advertising app given that Firebase is owned by Google and its SDK sits on the device. Firebase could capture the GAID from the publisher’s app and the advertiser’s app, manage attribution exactly as it does now, and transmit GAID-indexed events to source ad networks while withholding the GAID from both the publisher and the advertiser — and from other SDKs installed in both apps.

The GAID-indexed postback sent to ad networks, containing event identifiers and event values, might look like the below:

What’s interesting about this approach is that no real information is lost, and the data relationship remains specifically between Firebase and the ad network. For advertisers, event-level data isn’t needed if the advertising network is capturing it: the ad network knows how much revenue is generated per user, and it can aggregate that revenue data at the campaign level in reporting to allow the advertiser to calculate campaign-level ROAS. Yet the ad network has access to the full device-indexed events stream and can continue to build device-level behavioral profiles for targeting purposes.

And this approach solves an important problem with Apple’s privacy controls that is particularly acute for Google: that of view-through attribution, which is impossible with Apple’s SKAdNetwork. Ad impressions are able to be linked to specific GAIDs via the Firebase SDK on the publisher’s app in this framework: the publisher itself won’t see GAIDs because that access is restricted, but Firebase will, and so it will be able to attribute views on the advertiser’s app via the Firebase SDK integrated there.

The lack of view-through attribution in the new privacy paradigm on iOS is painful for Google. I understand that a very large proportion of the conversions that Google’s UAC attributes are for ad views (absent clicks) on YouTube; without view-through attribution, Google is unable to monetize much of its most valuable inventory. In the above configuration, Google the publisher (YouTube) would lose access to the GAID, and the advertiser would lose access to the GAID, but Google the measurement platform (Firebase) wouldn’t, and so view-through attribution would still be feasible for Google the ad network. And Google the ad network would retain the GAID-indexed events stream — provided by Google the measurement platform — allowing it to continue to aggregate monetization data for users for the purpose of optimizing ad campaigns, even if advertisers have no direct access to that data.

The above framework is slightly convoluted, and Google could likely find a more elegant way to institute additional privacy controls. But this framework accomplishes:

  • Removing intermediaries from the advertising process. Firebase would replace MMPs for attribution, and data custody would be reduced to just Firebase (Google the measurement platform) and ad networks;
  • Withholding GAIDs from advertisers. Advertisers would no longer be able to “track” users on the basis of their GAIDs — for instance, with re-targeting campaigns or through programmatic advertising targeting. Of course, ad networks would retain access to the GAID and would continue to be able to aggregate user events;
  • Continuing to optimize ad campaigns for advertisers. None of the complicated logic present in SKAdNetwork is needed here (eg. the timer system, limited conversion values) because Firebase handles all attribution and event triggering, and the ad network receives all events. If SKAdNetwork is perfectly designed to harm ad networks, then this framework is perfectly designed to preserve the efficiency of ad delivery and targeting without allowing the advertiser to build user profiles;
  • Streamlined, consolidated reporting. As the nexus of ad campaigns, Firebase could make all campaign-level data, across all traffic sources, available to the developer via an API. This would eliminate the need for advertisers to ingest campaign performance data from a number of different sources.

Note that I think the above solution (or something similar to it, with Firebase sitting between advertisers and publishers and managing measurement) is what Google is likely to pursue out of self preservation. But I don’t think it’s the best solution for the mobile ecosystem: I have called device-specific advertising identifiers the hydrocarbon of mobile advertising, and I think the industry at large should move past them in a way that fundamentally preserves user privacy and inspires trust while facilitating effective advertising.

]]>
https://mobiledevmemo.com/what-will-googles-deprecation-of-gaid-look-like/feed/ 0 30719
Apple is winning the war for control over iOS https://mobiledevmemo.com/apple-is-winning-the-war-for-control-over-ios/ https://mobiledevmemo.com/apple-is-winning-the-war-for-control-over-ios/#respond Thu, 10 Sep 2020 17:35:37 +0000 https://mobiledevmemo.com/?p=30576

Two recent developments within the mobile ecosystem seemed independent of each other at first but now appear to be correspondent consequences of a new world order having taken root on mobile:

  1. Apple announced the deprecation of its device identifier, the IDFA, at WWDC. The IDFA is fundamental to mobile advertising technology: advertisers, publishers, and ad platforms alike have been left scrambling to implement new advertising infrastructure ahead of the implementation of privacy changes coming to iOS14, which were recently postponed;
  2. Epic Games integrated its own native payments system into Fortnite, causing the game to be promptly banned from the App Store (among other things). Epic subsequently (immediately) sued Apple, seeking to have the company labeled as a monopoly over its App Store practices. Yesterday, it was revealed that Apple is counter-suing Epic Games over breach of contract, with Apple having disabled its single sign-on functionality from all Epic Games following the shuttering of Epic’s iOS developer account last month.

What unifies these incidents into a theme is the extreme control that Apple exerted in both cases over the form and function of its App Store. The new world order is one in which Apple enjoys total authority over the iOS ecosystem, from editorial curation to distribution to in-app monetization.

Something of a Perestroika appeared to be taking root over the past few years:

But what Apple is showcasing through deprecating the IDFA and engaging Epic Games in total war is an abandonment of the reformation mentality that many hoped was progressing via the examples above, albeit at a glacial pace. I’ve written at length about why Apple was motivated to deprecate the IDFA for the purposes of regaining editorial control over the App Store, and I won’t rehash those arguments here. But I do think the Epic Games case study exemplifies how a developer’s zeal and naked self interest can reverse the progress towards openness that a marketplace is experiencing.

Epic gambled massively when it instrumented its own, proprietary payment system into Fortnite: it knew that it was contravening App Store guidelines — specifically, section 3.1.1 — but it bet that a groundswell of developer support would pressure Apple into relenting and changing those guidelines. Epic cannot win its legal fight with Apple; the company was hoping that Apple would be swayed by developer (and consumer) opinion and acquiesce over the bad PR wrought by Epic’s lawsuit.

But consumers don’t care about a 30% fee that they never see. There’s little evidence to suggest that IAP prices would decrease by 30% if Apple ended its platform fee: IAPs are priced to maximize revenue, because they incur no marginal cost of production. Similarly, consumers don’t actually dislike closed, sandboxed app ecosystems — it’s why Epic brought Fortnite to Google Play after initially releasing it with a stand-alone launcher.

I don’t think anti-trust arguments against Apple hold up to scrutiny. Epic is fighting an impossible battle through the courts that it hoped would never manifest: it wanted Apple to cave to developer and consumer pressure, which never materialized.

And now Apple has dug in, counter-suing Epic Games and showing no signs of relenting. If Epic Games truly cared about the mobile app ecosystem at large, it wouldn’t have aggressively flaunted App Store rules and would simply have supported and encouraged the slow and measured trajectory of change along which Apple was moving.

With Apple retrenched, it seems unlikely to capitulate to any developer demands. Because if Epic Games, a company worth billions of dollars that oversees one of the biggest hit games of all time, can’t influence Apple, then Apple surely believes that no company can. Why should Apple relent at all? The 30% fee will never go away or be reduced once this precedent — of a developer suing Apple over anti-trust concerns and losing — is set.

The payout of Epic’s gamble will be meaningful for Epic if it wins because Epic is actually pushing for competitive app stores to exist on iOS. If Epic wins, it will launch an Epic Store on iOS and charge developers some percentage of revenue for the privilege of publishing their games.

But if Epic loses, the consequences will be dire for the entire app ecosystem. Apple will feel emboldened by its victory and will rigidly defend its practices. Perestroika will end; Apple will have no incentive to make concessions to developers because its legal victory will stand as a symbol of its unassailable authority on iOS. Epic’s reckless gamble is bad for the app economy.

Photo by Stephanie LeBlanc on Unsplash

]]>
https://mobiledevmemo.com/apple-is-winning-the-war-for-control-over-ios/feed/ 0 30576
Apocalypse Later: IDFA deprecation is delayed. Now what? https://mobiledevmemo.com/apocalypse-later-idfa-deprecation-is-delayed-now-what/ https://mobiledevmemo.com/apocalypse-later-idfa-deprecation-is-delayed-now-what/#respond Mon, 07 Sep 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30660

In a developer update last week, Apple disclosed that the new privacy changes announced for iOS14 at this year’s WWDC would be postponed until “early next year.” The disclosure, which confirmed a rumor that began circulating two weeks ago, was welcomed by app developers: while many see the IDFA as something of an anachronism in the modern marketing environment, complying with and adapting to the new privacy protections coming to iOS14 was a more onerous task than most developers could complete by iOS14’s September 15th release date.

So many developers breathed a sigh of relief on Thursday, when Apple granted them a few months’ reprieve on compliance with the new privacy changes. But this respite raises a question: what now?

The IDFA will be deprecated; that isn’t changing. Developers have a few additional months to not only accommodate IDFA deprecation but to fully embrace Apple’s SKAdNetwork framework. The SKAdNetwork framework is the future of measurement on iOS; the primary difficulty in transitioning away from the IDFA is implementing a measurement strategy that provides for marketing efficiency without requiring a persistent, device-centric identifier (although I argue that the persistent, device-centric horse left the barn a while ago). Building out the infrastructure required to integrate with SKAdNetwork is easy; re-orienting all marketing analytics around the data provided through SKAdNetwork is difficult and demanding.

So how should developers make the most of the time that has been granted by Apple to fully incorporate SKAdNetwork into their marketing operations? How can developers avoid simply kicking the compliance can down the road and scrambling at the beginning of 2021 to execute against an impending deadline, as most have been doing since WWDC — despite SKAdNetwork having been introduced in 2018, and industry premonitions as late as the beginning of this year that Apple might deprecate the IDFA at WWDC?

I think developers should focus their attention — starting right now — into three broad strategic activities to prepare for the upcoming privacy restrictions that will be instated at some point in 2021:

  1. Architect a new, SKAdNetwork-centric advertising tech stack;
  2. Optimize in-app content for advertising efficiency;
  3. Prepare for a world in which ads personalization is limited.

Architect a new, SKAdNetwork-centric advertising tech stack

Advertisers will need to understand how their data is aggregated, and from which sources, in the post-IDFA environment. My sense is that many advertisers believe that this function will be fulfilled by MMPs going forward, but one passage from Facebook’s recent iOS14 Advertiser FAQ calls that into question:

My interpretation of this statement is that Facebook doesn’t want MMP SDKs integrated in advertiser apps, and to dissuade advertisers from integrating them, it is only making App Event Optimization (AEO) campaigns available when an advertiser integrates the Facebook SDK for activating the updateConversionValue method in their app.

Many MMPs are now pivoting to data aggregation and analysis services, which map SKAdNetwork conversion values to in-app events and trigger the updateConversionValue method via in-app SDK when those events are observed. This allows developers to simply map in-app events to conversion values and to not have to institute any other in-app logic for firing the updateConversionValue method.

But it appears that Facebook doesn’t want that to happen: it wants its SDK to fire the updateConversionValue method, and it is incentivizing developers to allow for that by only making AEO campaigns available when Facebook manages SKAdNetwork logic. Additionally, upon release of its iOS14 SDK, Facebook is planning to define a list of conversion values that should be used for very specific in-app events, similar to how AEO events are defined now. Facebook currently utilizes 15 “standard events” for the AEO campaign strategy: it remains to be seen how many “standard events” it will require advertisers to map to SKAdNetwork conversion values.

This means that advertisers need to decide whether to include an MMP SDK at all for their iOS traffic — since mapping in-app events to conversion values potentially won’t require dynamic interpretation (as Facebook is defining those mappings) and because Facebook will trigger the updateConversionValue method via its SDK. And if an MMP SDK isn’t included in the app — should the advertiser build its own aggregation tool to connect to each ad network partner and aggregate all SKAdNetwork postback data?

Optimize in-app content for advertising efficiency

In How to scale and optimize marketing spend with SKAdNetwork, I discussed a framework for thinking about conversion value usage in producing actionable, credible insights around potential user monetization and engagement. Going through that process will be critical in scaling advertising campaigns in the post-IDFA environment.

But building those triggers in the app requires specifically engineering “moments” that produce predictive power. It’s not enough to exhaustively instrument the existing user experience with very many events that can be used to gauge monetization or engagement potential; that approach utilizes the “measure everything” paradigm that is dying with the IDFA. Now, developers should aim to curate experiences that are predictive themselves.

Expounding upon this idea: the current event-optimized advertising paradigm allows advertisers to outsource all personalization to ad platforms by sending them every in-app event that is triggered by a user. The platforms collect this data, build very specific segments out of the users that trigger different events (especially purchases) using shared characteristics, and then find other users that fit those profiles and target them with ads. In the process of doing that, advertising is optimized because ad creative variants are tested at the level of the sub-groups, meaning each different segment is seeing the ad creative to which it is most likely to respond:

In the new, post-IDFA paradigm, ad platforms will be unable to build specific segments of users that are likely to engage or monetize based on shared characteristics at the individual level because, with the event stream broken, the ad platforms won’t know which users actually monetize or engage. Ad platforms will only know which campaigns produced conversion values, and those campaigns will be targeted broadly based on demographic and platform features (eg. US iPhone). This means that segmentation will no longer take place at the advertising layer, and so advertisers will need to do it at the content layer:

Put another way: since advertisers will no longer receive vetted, qualified traffic based on the ad platforms’ abilities to segment users, the advertisers will have to do that segmentation themselves within the app based on early behavioral signals. An advertiser will need to observe a user’s first few interactions with in-app content and come up with an estimate of their future “value” (either in terms of engagement or monetization) to the app. Even better than that: specifically designing experiences in the app that allow those estimates to be made with even more predictive power.

This is deep product work, but it leans into the SKAdNetwork framework by producing conversion values that deliver powerful insight into the performance of ad campaigns. One of the themes I have repeatedly emphasized over the past two years as event-optimized ad campaigns rose to prominence is that of the tail wagging the dog in terms of advertising events informing (or dictating) product design, especially the early product experience. Ironically, with the event stream dying along with the IDFA, this dynamic becomes even more important because advertising networks only receive one feedback event via the SKAdNetwork postback. All possible signal around user value must be captured with that one conversion value.

Prepare for a world in which ads personalization is limited

This is a mostly philosophical exercise. Developers should expect that their ability to reach highly targeted audiences for their mobile products will be extremely curtailed going forward (on Android as well as iOS). Acknowledging this likely means answering the following question:

What products should I build if I know I can’t reach a very specific audience with targeted advertising?

What Facebook, Google, and some other ad networks became very good at over the past few years was routing users to the apps that could monetize them to the greatest possible extent via ads. That ability is being diminished with the deprecation of the IDFA. Users will be exposed to ads that are less laser-targeted to them on the basis of their monetization potential, and they’ll likely also revert to more organic discovery. What kind of apps thrive in that environment? What kind of apps die?

I discuss this idea in How iOS14 might change consumer behavior on mobile: when ads are less targeted, apps need to be more broadly appealing. It’s probably not possible, post-IDFA, to build a very successful business that thrives with tens or low-hundreds of thousands of DAU that all monetize very heavily: reaching the specific audiences that respond to niche products won’t be as efficient. App developers should consider how these changes are going to impact the viability of their product catalogue. In the aforementioned article, I talked about a “move to the middle” for gaming, but all app categories will be affected.

“Early next year”

Apple didn’t provide much guidance around timing in its announcement of the privacy delay. What if “early next year” means January? That would give developers just three months to achieve the above. Although Apple’s announcement was universally received with great enthusiasm across the mobile landscape, it’d be unwise for any advertiser to appreciably relax the intensity with which they were progressing towards iOS14 compatibility. Apple isn’t likely to have much sympathy for unpreparedness next year.

]]>
https://mobiledevmemo.com/apocalypse-later-idfa-deprecation-is-delayed-now-what/feed/ 0 30660
Announcing the MDM Investment Syndicate https://mobiledevmemo.com/announcing-the-mdm-investment-syndicate/ https://mobiledevmemo.com/announcing-the-mdm-investment-syndicate/#respond Mon, 07 Sep 2020 05:25:00 +0000 https://mobiledevmemo.com/?p=30667

A little more than two years ago, in The mobile app economy’s second act, I analyzed how a confluence of currents was creating a dynamic of renewal on mobile: emerging business models, ascendant new product categories, new tactics for distribution, user acquisition, and engagement were all converging to create incredible opportunity on mobile. The impending deprecation of the IDFA will accelerate some of these changes along their trajectories and allow for whole new categories of consumer mobile apps and advertising technology to take root and flourish.

In the time since that post was published, Mobile Dev Memo — encapsulating both the blog and the Slack community — has grown tremendously. Mobile Dev Memo is now a tribe of deep domain experts around monetization, product design, and performance advertising across mobile.

I’m proud to announce today the launch of the Mobile Dev Memo investment syndicate, which will invest in a handful of mobile-centric start-ups each year at the pre-seed and seed stages. As the syndicate sponsor, I will source investment opportunities from my network and from the Mobile Dev Memo community and present them to the syndicate. Members of the syndicate can decide whether they want to invest in any given deal or not. The size of investments made by the syndicate will range from $50k – 100k, and the minimum investment contribution for syndicate members for any given deal is $2,500. The Mobile Dev Memo Investment Syndicate has one deal ready for investment, with others prepared throughout the remainder of the year.

The Mobile Dev Memo Investment Syndicate will operate as a private channel within the Mobile Dev Memo Slack team. In order to apply to join the Mobile Dev Memo Investment Syndicate, please fill out this form. For more information, see the brief FAQ below:

What are the requirements for joining the MDM Investment Syndicate?

All members (including non-US nationals) must qualify as accredited investors as defined by the SEC. More information on that qualification may be found here.

I may also exclude employees from certain vendors from joining the syndicate, or exclude them from access to specific deals.

How can I join the MDM Investment Syndicate?

Fill out this form.

What is an investment syndicate?

A syndicate is an investment vehicle that is formed amongst investors to make a single investment. Each individual deal surfaced to the MDM Investment Syndicate will actually require the formation of a new investment vehicle to make an equity investment in that individual company. I define the MDM Investment Syndicate here as the group of people that may participate in any given deal. More information on investment syndicates can be found here.

What kinds of companies will be surfaced to the MDM Investment Syndicate for investment?

I am open to considering any company that operates “mobile first,” or exclusively / primarily on mobile. This can span:

  • Consumer content apps (eg. games, dating apps, travel apps, etc.);
  • Mobile ad tech;
  • Mobile-first fintech (mobile banking, mobile payments, etc.);
  • Streaming services;
  • Commerce (money transfer, marketplaces, shopping);
  • Mobility (urban transport, spare capacity monetization, etc.).

What non-monetary benefits can a portfolio company expect from the MDM Investment Syndicate?

I am working on an office hours platform in which portfolio companies can schedule time with myself and various participating members of the MDM Investment Syndicate to discuss issues of strategy around growth, market sizing, competitive landscape, monetization, etc. This should launch in Q1 2021.

I am also hoping to launch a yearly MDM Investment Syndicate “portfolio day” in 2021.

If an MDM Investment Syndicate member wishes to participate in a deal, what is the minimum investment commitment?

$2,500

Who manages the mechanics of each deal surfaced to the MDM Investment Syndicate?

A third party manages the investment process, from the formation of the SPV to the receipt of funds to the distribution of profits and circulation of tax information.

As a member of the MDM Investment Syndicate, will I be obliged to participate in every active deal that is surfaced?

No. Members can choose in which deals they participate.

What are the economics of each deal for the MDM Investment Syndicate?

I will invest into every deal that I surface to the MDM Investment Syndicate at an amount that will be specified in each deal memo (but at least at the minimum level of $2500). I will receive 20% carried interest on the proceeds from any exit.

The third party servicing company that manages the formation of SPVs for the syndicate charges a variable fee for the operational effort required in each deal. This fee is taken out of the amount of money raised for the deal.

How can I submit my company for consideration for investment?

To pitch your company, email Eric Seufert and include your pitch deck and all information relevant to an investment decision.

How quickly will the MDM Investment Syndicate make investment decisions?

Investment commitments will be gathered from the syndicate over the course of 14 days after allocation agreement. Time to wire may vary by deal.

How many deals are expected to be executed per year with the MDM Investment Syndicate?

Likely 1-2 per quarter.

Where will communication take place for the MDM Investment Syndicate?

All communication will take place within a dedicated channel in the Mobile Dev Memo Slack Team.

How can I get more information about the MDM Investment Syndicate?

DM Eric Seufert on the MDM Slack Team.

]]>
https://mobiledevmemo.com/announcing-the-mdm-investment-syndicate/feed/ 0 30667
Why Apple should delay its iOS14 privacy features https://mobiledevmemo.com/why-apple-should-delay-its-ios14-privacy-features/ https://mobiledevmemo.com/why-apple-should-delay-its-ios14-privacy-features/#respond Tue, 01 Sep 2020 19:00:57 +0000 https://mobiledevmemo.com/?p=30629

EDIT: On September 3rd, 2020, Apple confirmed that the new privacy guidelines coming to iOS14 would be delayed into 2021. More information here.

Last week, after hearing nearly identical accounts from multiple people whose connections and judgment I trust, I posted to Twitter about the rumored possibility that Apple might delay the rollout of its IDFA-related privacy features in iOS14 by six months:

The enthusiastic, thundering response to that Tweet was not something for which I was prepared, given the limited size and specific scope of my Twitter following. Clearly this rumor struck a nerve with mobile advertisers.

What I want to accomplish with this post is to make the case for why Apple should delay the iOS14 privacy features announced at WWDC by six months. What I mean by this is that, for the six months following the release of iOS14 (which is still scheduled for September 15th, 2020, as of this writing), regardless of whether an app has instantiated the requestTrackingAuthorization method to present the ad tracking opt-in dialogue, Apple should:

  • Allow app developers to continue to access the IDFA;
  • Allow app developers to use the SKAdNetwork 2.0 API to generate postbacks that are sent directly from user devices to source ad networks;
  • Allow MMP solutions to continue to access a user’s IDFA for marketing attribution at the point of click and app open;
  • Allow app developers to continue to send IDFA-indexed in-app events to various ad platforms via integrated SDKs.

I believe that in delaying the rollout of the IDFA-related privacy features coming to iOS14, which I’ll broadly define as the limiting of access to the IDFA, Apple will be acting in the long-term best interests of advertisers, consumers, and itself, for the following reasons:

Developers aren’t ready.

Of the roughly 50 app advertisers to whom I have spoken directly since WWDC about the coming privacy changes in iOS14, I’d guess that 10% have a plan in place to transition away from IDFA-based advertising in a way that fully embraces the SKAdNetwork framework for optimized advertising spend. Of the remaining advertisers:

  • 25% are implementing SKAdNetwork conversion values into their apps, but don’t understand how these conversion values can be used to optimize campaign ad spend;
  • 50% understand what SKAdNetwork is and acknowledge that it will form the basis of advertising optimization going forward, but these developers don’t know how to accommodate it and are simply waiting until the dust settles after the launch of iOS14 in order to plan their next steps;
  • 25% don’t understand what SKAdNetwork is and, while broadly aware of the privacy changes coming to iOS14, don’t understand how their advertising campaigns will be impacted by iOS14.

Very few advertisers are prepared to accommodate SKAdNetwork. These advertisers will either reduce spend on iOS or cut it completely upon the launch of iOS14. These advertisers’ revenues will contract as a result.

This is an unfortunate outcome, especially at the onset of Q4, which is traditionally the biggest quarter for digital advertising. Is it in anyone’s best interest — that of developers or of Apple — to reduce ad spend, revenue, and engagement on iOS heading into Christmas?

Ad networks aren’t ready.

I haven’t seen a single announcement about iOS14 preparedness from any ad network apart from Facebook’s. As of this writing, ad networks have exactly two weeks to prepare for iOS14 and to communicate whatever changes they are making to advertisers. My sense is that most ad networks don’t understand yet how they’ll be able to optimize campaigns on behalf of users via SKAdNetwork.

Some of the changes that Facebook is implementing in order to optimize campaign spend on behalf of advertisers are extreme, such as requiring the creation of new ad accounts for iOS14 campaigns and limiting the number of ad campaigns within those accounts to just nine (of the 100 possible campaign IDs). As I state in this summary of Facebook’s announced changes, the campaign limit is probably part of an experimentation / exploitation approach to campaign management that very few other networks have the internal domain expertise to implement in order to achieve efficient campaign spend.

Additionally, considering the scope of changes that Facebook is requiring from advertisers in campaign management, most advertisers can expect similar such procedural changes from all of their other networks. Advertisers simply won’t have the time between today — when only Facebook has publicly published iOS14 transition recommendations — and September 15th to implement all of these changes for all of their ad network partners.

Ad tech platforms aren’t ready.

The mobile advertising ecosystem is built on an already delicate foundation of independent SDKs. Every mobile ad tech provider is currently in the process of updating its SDK for iOS14 compatibility, but few of these SDKs are available to be tested at the moment.

In the coming days, developers will be confronted with a deluge of SDK updates from their ad tech partners. Many of these SDKs will have been hastily developed; it is likely that many of them will cause crashes and / or poor performance when published into app updates, especially when integrated alongside the hastily developed SDKs of other ad tech vendors. Consumers may face the unpleasant experience of their favorite apps crashing or behaving in unintended ways after updating them ahead of the launch of iOS14.

Consumers aren’t ready.

Consumers are used to seeing ads in their favorite free apps that are personalized based on some preference profile. Putting aside the appropriateness of such a preference profile, consumers haven’t been informed of these privacy changes and will be jarred when, after updating to iOS14, they are exposed to wholly irrelevant, seemingly random advertisements.

There is an effective way to educate consumers about the role that ads personalization plays in the modern digital product landscape, and that education process hasn’t yet taken place. I think giving control over ads personalization to users at the level of the individual app is an effective means of empowering users with their own privacy, but explaining the ramifications of losing ads personalization requires a broader effort than the one line of text that developers can control with NSUserTrackingUsageDescription.

What happens when consumers’ favorite apps disappear from the App Store because they are no longer economically viable absent ads personalization?

Six months would make all of the difference.

Giving app developers and advertisers six months to fully digest the privacy changes announced at WWDC — and, more importantly, to build scaleable strategies around them — would likely mean the difference between life and death for many developers. This isn’t an exaggeration: many developers’ revenue is a direct function of ad spend. Some developers may not recover if they are forced to scale ad spend back dramatically, in Q4 no less, because they haven’t been able to devise a strategy for advertising optimization using SKAdNetwork.

I fully accept that SKAdNetwork is the future of efficient advertising spend on iOS: I think SKAdNetwork is elegantly designed and, through systematic, analytical product design, it serves as a privacy-centric mechanism for advertisers to efficiently deploy ad spend for product growth.

But most developers simply aren’t ready to fully utilize SKAdNetwork, at least not in a way that is as performant as their current measurement framework. Providing advertisers with six months to understand and implement SKAdNetwork would allow them to thoughtfully, methodically implement SKAdNetwork into their advertising regimen such that ad efficiency is mostly preserved within the broader context of increased user privacy. The positive impact on advertisers and consumers would be immense.

]]>
https://mobiledevmemo.com/why-apple-should-delay-its-ios14-privacy-features/feed/ 0 30629
Analyzing Facebook’s iOS14 advertising changes https://mobiledevmemo.com/analyzing-facebooks-ios14-advertising-changes/ https://mobiledevmemo.com/analyzing-facebooks-ios14-advertising-changes/#respond Mon, 31 Aug 2020 05:30:00 +0000 https://mobiledevmemo.com/?p=30597

After announcing last week that the company would completely abandon the IDFA for iOS14 advertising campaigns, Facebook released a FAQ document to advertisers that provides guidance around how they should prepare for updates to the platform.

The FAQ is rife with insight — and it reveals just how dramatically different the iOS14 marketing environment will be from that of today. Any illusions that Facebook will find workarounds to the IDFA restrictions, or that the company has enough data about each user to maintain the device-centric advertising status quo on mobile, are dispelled in reading the FAQ document. Advertising to iOS users on Facebook will fundamentally change with the release of iOS14; in this article, I will surface and analyze the most noteworthy revelations from the document.

Preparing for iOS14

The document opens with a list of staggering recommendations for advertisers in preparing for iOS14:

Going through each of these on its own:

Update to the latest version of the SDK to support iOS 14. Facebook is publishing an entirely new SDK to facilitate iOS14 advertising; presumably, this SDK will effectively terminate any data transmission if the user has not opted into ad tracking except for what is permissible through SKAdNetwork.

Use non-IDFA match methods such as adopting Facebook Login or using Advanced Matching to share (with applicable permissions) hashed customer contact information (e.g., email address). I’ve seen this recommendation be misinterpreted: what Facebook is telling advertisers in this statement is that Facebook Login (SSO) or hashed email addresses will be the identifiers that are sent when the user has opted into ad tracking because Facebook is abandoning use of the IDFA.

One common misconception around iOS14 is that SSO (eg. Facebook Login) can be used to evade ad tracking opt in: if the user opts out of ad tracking, direct them into an SSO login that associates their state in the advertiser’s app with their Facebook ID, preserving the event stream between the app and Facebook and enabling advertising measurement. But Apple has been very clear about SSO requiring opt in, per the App Tracking Transparency documentation:

Likewise, Apple was very clear at WWDC around in-app profile data being bound by opt-in if it is shared with an ad platform:

What Facebook is declaring in this line from the FAQ is that instituting SSO or the collection of emails should be done in the app for when a user has opted into ad tracking so that any data transmitted back to Facebook can be anchored with a useful identifier (again, which can’t be the IDFA, because Facebook is abandoning the IDFA on its platform).

To help preserve the fidelity of app install campaign measurement, we will require the creation and usage of a dedicated iOS 14 ad account. This line reveals just how seriously Facebook is taking its commitment to iOS14 privacy constraints: not only will advertisers need to use an entirely new SDK to prevent data leakage when the user has opted out, they will need to create wholly new ad accounts to avoid previously-collected data from being used to target campaigns to users that opt out of tracking after upgrading to iOS14.

There are a few details worth unpacking in this idea. The first is that there are essentially two broad buckets of data that are useful in targeting advertising campaigns. The first bucket is the user-specific data that Facebook uses to build profiles of its users: who monetizes, who engages, who clicks on ads, etc. This data doesn’t go away with the introduction of iOS14; user profiles are indexed to users’ Facebook IDs and remain valuable after the release of iOS14, although they degrade quickly. One of the primary indicators that a user is a high-potential monetizer is that they have monetized recently. Facebook loses the timeliness component of its knowledge of its users’ monetization histories after iOS14 (because it will no longer receive user-specific events streams from all iOS apps), and so while it might know that a user has monetized heavily in the past, it won’t know whether they have done so recently.

The second bucket of data that is useful for targeting purposes is campaign-specific data: when Campaign X has been targeted to users with some set of specific profiles, it has generated an optimal density of conversions for the advertiser (which is how Facebook gets paid: by generating conversions). Facebook loses this campaign performance data completely when it forces advertisers to create new ad accounts.

My best guess as to why Facebook is doing this: iOS14 campaigns will use SKAdNetwork conversion events as success signals for optimization and not the full stream of events that Facebook currently uses for iOS13 campaigns, and the optimization models required in each of these cases are so different that transitioning the campaigns from one model to the next would simply break ad targeting. Facebook currently targets at the user level using event histories; in iOS14, Facebook will have to target much broader segments of users using demographic and interest data. The loss of granularity at the targeting layer, in addition to the sparseness of event signals in iOS14 (only one conversion value is possibly sent per acquired user in the campaign), means that the two campaign types (iOS13 and iOS14) require totally different parameter sets.

Facebook provides a modest amount of context around the above topic in the FAQ portion of the document:

Campaign Limits and Reporting

In a later section, Facebook provides some interesting guidance around changes to reporting on the platform:

The SKAN API will report back data aggregated at the campaign level…reporting at the ad level will be modeled based on aggregated data received from the SKAN API, unless there is only one ad for a given campaign. This is important. In the new iOS14 campaign environment, Facebook only allows nine campaigns per ad account, with each campaign containing just one ad set (more on that later; the structure of the document is a little disjointed). Since the SKAdNetwork postback only includes a campaign ID parameter, then the relationship between campaign and ad set on Facebook needs to be one-to-one.

But it wouldn’t be practical to only include one ad per ad set, and given that SKAdNetwork reporting is aggregated at the campaign level, Facebook needs to “model” (estimate) the performance of each ad in the ad set based on campaign performance. I’ll offer more analysis on this point in a later section, but the broader point here is that ad-level performance won’t be directly measured for iOS14 campaigns but rather estimated.

This disclosure answers a question about how MMPs might take ownership of SKAdNetwork data, given that it is transmitted directly from Apple to ad networks: the ad networks will give it to them. Advertisers can enable a setting that instructs Facebook to transmit their SKAdNetwork receipts to their MMP.

But this insight also reveals that advertisers will need the Facebook SDK integrated into their apps in order to run AEO campaigns, and the MMP SDK will only allow for MAI campaigns to be run. This further calls into question the role that MMPs will play in the new ad tech landscape being excavated by Apple with iOS14: increasingly at the periphery of the primary, three-party relationship that exists between advertiser, ad network, and Apple.

This segment of the FAQ provides more context around reporting:

Facebook is mostly acknowledging here that campaign data will not be available in real time (as a result of the conversion value timer logic implemented into the SKAdNetwork postback flow), that performance data will be modeled (estimated) at the ad level unless each ad set only contains one ad, and that performance data will not be segmented by demographic features (because Facebook will only have demographic targeting features available at the campaign level, but it won’t actually know anything about the individual users that install apps or complete conversion events).

The next section in the FAQ is seismic: it is where Facebook states that only nine campaigns will be supported per iOS14 ad account, even though the SKAdNetwork provides 100 campaign IDs per advertised app, per network:

This is important, not only because it signifies a very real limitation on advertisers with respect to campaign breadth, but because it provides some helpful guidance around how Facebook is utilizing the SKAdNetwork framework for optimizing campaigns.

What I interpret from the nine campaign limit is that Facebook will utilize 10 campaign IDs per live, advertiser-designated campaign for experimentation (9 + 9*10 = 99). The idea here is that the advertiser will establish nine campaigns, each of which contains no more than one ad set but potentially many ads, and Facebook will use 10 reserved campaign IDs per live campaign to dynamically experiment with ad performance and adjacent demographic targeting in order to optimize those campaigns fully.

I actually proposed something similar to this for ad creative testing in my recent workshop series, How to Build and Scale successful apps without the IDFA, except that I suggested flipping the ratio: using just 10 campaign IDs for testing, with the remaining 90 being used for scaling live campaigns.

The performance principal in Facebook’s campaign limit approach is that an advertiser establishes a campaign with some sort of demographic targeting constraints, uploads a number of ads to the ad set for that campaign, and then Facebook uses the 10 “phantom campaigns” to test the various permutations of targeting parameters and ads that exist in order to find the one that produces the most cost effective conversions (as measured through conversion values from SKAdNetwork postbacks). Facebook will dynamically cycle these combinations of ads and targeting subsets through the available Campaign IDs, optimizing performance by allocating disproportionate budget to the combinations that drive the most efficiency.

Some approach like this will represent the new “learning phase” for Facebook campaigns, with the combinations of targeting parameters and ads settling into stable state as combinations are tested and performance is discovered.

Marketing API

Later in the document, Facebook summarizes the new limitations that are imposed on advertisers in the iOS14 environment (again, the ordering of these disclosures feels disjointed, but I wanted to maintain the structure of the document in the analysis):

This is mostly summary, with one important piece of new information:

Ads Manager only (no support for Marketing API to create and edit campaigns targeting iOS 14). Facebook is announcing here that it is not offering Marketing API support to iOS 14 campaigns; the Marketing API is what allows advertisers to create and edit Facebook campaigns programmatically. This blocks the SaaS tools that have emerged to automate Facebook campaign management (as well as the proprietary initiatives that many advertisers have launched in the past few years as marketing automation received significant investment across the mobile ecosystem).

Conversion Value management

The document then proceeds to relay some information (and subtext) about SKAdNetwork conversion value management:

There are two important revelations in this block of text:

  1. Facebook will only capture conversion values from within a 24-hour period after initial app launch. This means that the Facebook SDK won’t allow for the conversion value timer to be reset endlessly: Facebook will observe named conversion value events only within a 24-hour window after initial app open and stop firing the updateConversionValue() method once that period has lapsed;
  2. Facebook will provide advertisers with a standardized list of in-app events that should be mapped to 6-bit conversion values and instrumented within the app.

While both of these developments are significant, they were both predictable. The 24-hour window for capturing conversion values is a logical approach to optimizing performance within the tradeoff between SKAdNetwork postback turnaround time and in-app value signal. And a standardized library of defined events already exists within Facebook’s optimization schematic: it is the set of AEO events that Facebook suggests advertisers optimizes toward.

Why is a standardized event catalogue important? Because Facebook uses the accumulated performance of all apps, aggregated around the specific events in the AEO events library, in optimizing campaigns. To not use the standardized catalogue of events is to ask Facebook to build a performance history for some new event for some targeting segment for a single app, which would be slow, expensive, and not very performant. Keep in mind that most revenue and deep engagement events are very rare: by aggregating event history for all apps and all users within the confines of a standardized library, Facebook can leverage the entirety of its audience to optimize any given app’s advertising campaign.

The same logic applies to the conversion value mappings that Facebook will propose advertisers map to defined in-app events (eg. Tutorial Complete, Account Registration, etc.). By aggregating this data across its entire userbase in a standardized format, Facebook can scale campaigns on the basis of those events quickly and efficiently. Some campaigns, on their own, might never accumulate enough events in the requisite period of convergence time to optimize their own campaigns — leveraging an aggregated, audience-wide event history is critical for Facebook in driving efficient ad spend. The equivalent of not mapping Facebook’s prescribed 6-bit conversion values to specific in-app events would be to run AEO campaigns against “custom events,” which, while possible now, is extremely uncommon, for the reasons cited above.

Note that Facebook hasn’t actually revealed what this event list is yet — nor has it released the iOS14 SDK. Presumably both of these things will be made available in the next weeks.

Lookalike audiences

Finally, Facebook’s advertiser FAQ ends with a fittingly weighty revelation about lookalike audiences for iOS14 ad accounts:

What the above says is that lookalike audiences won’t be built from custom audiences, which are essentially user lists, for iOS14 accounts, but rather from existing campaigns or conversion values. Lookalike audiences are a core component of digital marketing, and they’re often built on Facebook from lists of high-value users uploaded as custom audiences. If marketers can no longer build lookalike audiences from custom audiences but rather have to use existing campaigns or in-app events (conversion events), then they lose the magnitude of monetization of high-value users in establishing targeting: conversion values will be captured within 24 hours of initial app open (as per above) and will only contain limited scope of monetization (because even very high-LTV users can only monetize so much within their first 24 hours of app usage).

This is a fairly devastating development, especially for advertisers whose apps feature long-tail monetization distributions. Custom audiences allow advertisers to build lookalike targeting on the basis of their most valuable users; with iOS14 campaigns, the ability to quantify that value is attenuated dramatically, with lookalikes being established on the basis of early-stage conversion value completion.

Of course, it bears repeating that user-level profiles won’t be possible in iOS14 anyway, and so targeting on the basis of any specific user’s propensity to spend is not possible in the first place. In iOS14, lookalike targeting will be done on the basis of the demographic and interest targets that deliver conversion events for already live campaigns. This is another reason why it will be critical for advertisers to instrument Facebook’s standardized conversion value catalogue.

In closing

Facebook is making substantive changes to its ad platform to accommodate iOS14. This wasn’t necessarily the expected course that Facebook would take; at least, it certainly wasn’t the prevailing expectation. In speaking to institutional investors, journalists, and other marketers since WWDC, my sense was that most people believed that Facebook could find a way — using its sophisticated infrastructure and massive data set — to maintain the device-centric status quo on mobile.

What Facebook’s announcement last week reveals is that it can’t: it is fully embracing the SKAdNetwork measurement framework and is excising the IDFA completely from its advertising machinery. Many things will likely change in the coming months about how Facebook accommodates SKAdNetwork (Facebook admits as much in its advertiser FAQ), but advertisers should be aware of how Facebook plans to update its platform to become SKAdNetwork and iOS14 compliant, as these changes don’t all take place below the surface.

]]>
https://mobiledevmemo.com/analyzing-facebooks-ios14-advertising-changes/feed/ 0 30597