How I'm Going to Get Around the iOS14 IDFA Changes
My master plan in detail
A lot of people look forward to WWDC. Me, I kind of dread it. It means more features that I have to build into my app, new libraries I need to learn, new areas of compliance, yadda yadda. Well, if every year prior was a little annoying, this year is really problematic. The IDFA thing is so, so unfortunate. I had invested quite a bit of time into having what I would consider a nearly perfect advertising tracking system.
My Precious Return on Ad Spend System
Using AppsFlyer and RevenueCat, I built a system that accurately tracked advertising ROI for all of my campaigns. This is what that looks like for the month of July:
I can zoom in even further, and see which specific ad sets are generating ROI.
The way it works is RevenueCat will automatically send revenue-related events to AppsFlyer, then AppsFlyer will post them back to all the ad networks. This means that we can run purchase-optimized ads that specifically look for people who will spend money. Also, the Facebook dashboard shows more or less accurate ROAS so the ad team I work with can accurately manage the campaigns. Adding new ad networks is easy, simply configure it in AppsFlyer and that was it. AppsFlyer will also pull in cost data for every ad network so it can calculate ROI. It’s a delicate system, but it works really well.
And then Apple announced the end of the IDFA. Shit. As I started digging into the implications of these changes, the magnitude of the problem became apparent. I don’t think the SKAdNetwork stuff is sufficient. So I’ve devised a way, with the help of some friends, to stop using IDFA, get nearly 100% advertising attribution, and get around App Store fees.
The Flow
Here’s the flow.
1) User sees an ad for my app on Instagram or Facebook
2) Tapping the ad will redirect to a website with URL parameters that contain all the important information about the ad (i.e. campaign name, campaign ID, ad set, ad id, etc.)
3) User will view the landing page and sign up for an account on the website. This means I will need to build out the onboarding flow into the website via a basic web-app.
4) Part of the onboarding flow will prompt the user to subscribe on the website via Stripe, so I’ll get 97% of the revenue instead of 70%.
5) After signing up on the website, the user will get a 6 digit code that they can use to login to the app and be redirected to the App Store to download the app. The code will be copied to the user’s clipboard.
6) The user opens the app, puts their code in, and then they are authenticated. With this, I know exactly what ad this person came from and their subscription is managed via Stripe and not Apple. I have 100% attribution and I get more money, without using IDFA at all.
Let’s unpack that a little bit. I’ve mocked up this flow for my app Caption Expert where I’m planning to test it. This will be the website users see after tapping on an ad.
The call to action is the “Sign Up” button. The goal of the landing page is to sell the user on the app and get them really excited about it so that they’d be willing to pay for it before even using it. I do something similar in my app Hashtag Expert where users who come from ads are required to subscribe before accessing any of the core features of the app, and it works very well.
Once the user taps sign up, they will go through this onboarding flow:
Pretty straight forward, right? Now, because this is a website, I can enable all the advertising network pixels here, like the Facebook, Snapchat, and TikTok website pixels. That means I can log events to those ad networks when the user signs up, pays, and even gets redirected to download the app. Further, I can build advertising audiences based on people who trigger these events.
One issue is that it becomes tricky to send events after the user leaves the website. Facebook luckily has a server-to-server events API where I can send events like “Subscription Renewed” or retention-related events. Basically, every time I receive an event from a RevenueCat webhook (i.e. subscription canceled, subscription renewed, trial converted), I will forward these events to Facebook. Snapchat and TikTok do not have a similar server-to-server API, but I imagine it is in the pipeline.
For this reason, I’ll probably not offer a trial when users are going through this web flow—$19.99/year no trial. I want to be able to optimize my ad sets for conversion events so I can find people who are willing to pay immediately.
Will it Be Worth it?
This might seem like quite a bit of work—is it really worth it? I see a number of advantages from this route.
First, I’ll get pretty close to 100% attribution. Even with my current set up, users who sign up for the app with Limit Ad Tracking enabled are lost and counted as organic downloads. Presumably, this new setup will get me a much higher percentage of users properly attributed. Though, I will lose out on users who view the ad and then download the app on their own, without going through the web onboarding flow.
Second, I get to own the subscription finally, and not manage it via Apple. This will supercharge my customer support, enabling me to refund customers much easier and change their plans for them. Also, I’ll get paid within days of when the transaction occurs instead of having to wait 45 days for Apple to pay me.
Third, it makes my app more competitive in advertising. Think about it—if all of my competitors are running direct-install ads, not getting 100% attribution, and having to pay Apple 30%, I can undercut them. I can target better and offer cheaper prices. I also have a much bigger cushion to achieve 1.0 or higher return on ad spend because I don’t owe Apple a cut.
Finally, I won’t need to pay Appsflyer anymore. Right now, I’m paying them $1800 a month for attribution tracking. With this new method, I can cut that expense out completely.
What Are The Disadvantages?
No view through attribution - I will only be able to attribute users who specifically sign up on the website and log in via the code.
The flow to get a user signed up is arguably more complicated. Ad -> Web -> App. My hypothesis is that web sign up is a lot lower friction than having someone download an app. By the time the user has to download the app, they will have already paid so the likelihood of losing them there is lower. This flow will definitely seem a bit weird, it’s very untraditional.
Overall, I don’t see many other options. SKAdNetwork is not a solution that will work for anyone running serious ad budgets. I’m currently spending over 100k per month on advertising. I need to know exactly what my ROI on that advertising is or else I won’t be able to pay my invoices.
I’d like to give a special shoutout to Jake Mor, who has helped me navigate all the complexities of IDFA. Definitely check him out!
Have you ended up implementing this?
I think James has a valid point. For example in EU, we have a MOSS for submitting quarterly VAT reports. MOSS basically allows you to submit (and pay) your reports on one place and the system forwards the reports (and VAT paid) to each EU member state. If you don't (or can't - I think there are limits who can use MOSS) use MOSS, then you have to register with each EU state tax administration and report and pay VAT separately.
But for example Norway is not part of EU and they have their own VAT system where you have to register, submit reports and pay VAT. Now with Brexit, UK is going to become a more complex matter as it is going to be excluded from the EU MOSS system. Many countries have different VAT rates. And this is just EU + Norway.
I'm not sure how this works outside of EU and many countries don't care for digital sales of non-resident companies, but many do - for example recently Turkey announced a system similar to the Norway's system.
It is manageable, but it adds some overhead. On the other hand, when using AppStore, Apple is the merchant on record and the only thing I have to do for our AppStore sales is to upload an invoice to Apple in the ITC.