Perhaps the most contentious aspect of user acquisition strategy is the payback window -- and the decision to extend it. Often, extending the payback window is seen as an easy way to scale spend, but doing that is fraught. I'll explain why (1/X)
2/ First, I've written at length about payback windows and why recoup timelines should be dictated by cash flow concerns. In this post I propose a framework for marketing
P&L management using LTV and ROAS windows mobiledevmemo.com/ltv-roas-marke…
3/ When a marketing team reaches a point of stasis with spend -- or, more commonly, when spend begins to decline at a CAC that is acceptable to it -- it is tempting to simply extend the payback window to allow for an increase in budget quantmar.com/255/What-point…
4/ What's the benefit of this? If the 15-month LTV for a given segment is 10% higher than its 12-month LTV, then it allows the advertiser to bid 10% more on traffic mobiledevmemo.com/ltv-cpi-vs-cas…
5/ But doing this introduces three problems. First, by definition, 3 fewer monthly cohorts have progressed through 15 months in the product than 12 months. The product's retention curve might reduce the number of users that have aged to that point further mobiledevmemo.com/much-data-need…
6/ Second, extending the payback window puts stress on cash flow: more money is expended upfront and it is returned over a longer period of time. Not all companies have the cash reserves to fund this. mobiledevmemo.com/optimizing-cam…
7/ But perhaps most importantly: the less data the advertiser has for the longer frontier in the timeline, the more volatile the projections are going to be. Often an advertiser trades extreme volatility for some single-digit increase to bid prices.
8/ This could actually ultimately reduce the amount of spend: if the volatility in the predictions increases meaningfully and the absolute error rate changes (when most advertisers are working against thin margins -- 10%ish), then wins could start looking like losses more often
9/ One reason that it's difficult to build LTV models is that doing so requires a lot of data to produce reliable predictions, and data availability for later-stage windows is diminished by the retention curve mobiledevmemo.com/much-data-need…
10/ This is one of the reasons that I dont like using the LTV metric for marketing budgeting / performance optimization. I prefer starting from a short payback window and increasing that frontier as doing so is supported by the data mobiledevmemo.com/retire-the-lif…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The black box inside the black box: Google announced yesterday the availability of its Generative AI-based creative tools in Performance Max campaigns. What considerations should marketing teams make in expanding total campaign automation to creative production? (1/X)
2/ First, dispelling two myths. The first: marketing teams view Generative AI as a novelty or a toy that is not yet practically useful. This simply isn't true: I've seen marketing teams that have radically improved their workflow with Generative AI tools already.
3/ Second, wholly automated campaign optimization tools like Advantage+ and PMax are naturally hostile to advertiser goals. This isn't true, either. These tools can present competing incentives, but many advertisers benefit materially from their use. mobiledevmemo.com/google-pmax-me…
The control exerted by Apple & Google over the consumer internet is often expressed in terms of content discovery / distribution & payments. But a more subtle and esoteric form of control is emerging: advertising attribution. (1/X)
2/ Both Apple & Google have launched native advertising attribution frameworks for their mobile platforms & browsers. These dictate how and, crucially, how accurately digital advertising can be evaluated, based on rules set by these companies.
3/ These frameworks have been introduced alongside, or as components of, privacy policies that were authored by the platforms themselves. Moreover, it seems that the platforms' privacy restrictions don't consistently apply to their own advertising products.
Meta announced changes to its Aggregated Event Measurement (AEM) protocol this May. Meta introduced AEM a few months after Apple revealed (but before it rolled out) the App Tracking Transparency (ATT) privacy policy. (1/X)
2/ AEM was initially modeled on Private Click Measurement, Apple's own privacy-focused attribution framework for web-to-web and web-to-app advertising campaigns. Meta stated as much in an early version of its documentation for AEM.
3/ But I noted when Meta first announced the changes coming to AEM that the reference to PCM had been removed from its documentation. I interpreted this as meaning that AEM would no longer be tethered to the PCM design imperative.
Yesterday, The Verge reported that Meta will introduce a direct-to-install advertising product on Android in the EU once the DMA goes into effect next year. Some thoughts on the efficacy of such a product and its impact. (1/X)
2/ First, I believe the DMA will be systemically disruptive (in the EU). It has broad implications for all "gatekeepers" / large platform operators, not just on mobile. To my mind, the DMA represents a fundamental reset on competition in consumer tech. mobiledevmemo.com/a-deep-dive-on…
3/ Meta says that its ad product will allow consumers to install apps on Android directly from an ad click, sidestepping the intermediate step of visiting Google Play. This has the potential to meaningfully improve conversion rates (and thus decrease acquisition costs).
Yesterday, Apple announced its new Privacy Manifests feature, which takes direct aim at device fingerprinting on iOS. Privacy Manifests will hold SDK publishers and app developers accountable for how user data is collected and utilized. (1/X)
2/ Apple explicitly stated in its blog post announcing Privacy Manifests that their intended purpose is to disrupt device fingerprinting to force app developers to indicate a legitimate use case for data collection by potentially non-compliant SDKs. From the post (emphasis mine):
3/ Apple's approach here is, to my mind, ingenious: by effectively segmenting SDK permissions from general app permissions and forcing developers to certify that SDKs are behaving in accordance with App Tracking Transparency, Apple places the onus of compliance on developers.
Apple seems to be saying that app developers will be held liable for the validity of SDK data use attestations through the privacy manifest system. Will a BigCo legal team be willing to sign off on data usage claims by a third party that it knows to be practicing fingerprinting?
I’d characterize this list of SDKs as “commercially sensitive.”