If you've spent any meaningful budget on iOS app campaigns in the last two years, you already know the feeling. The dashboard says one thing, RevenueCat says another, your mobile measurement partner (MMP) says a third, and by the time SKAdNetwork (SKAN) postbacks roll in days late, the campaign you needed to optimise yesterday has already burned through half its budget.
This isn't a bug. It's the design.
Traditional app campaigns on Meta, Google, and TikTok were built around a privacy framework (SKAdNetwork) that strips out almost everything useful about a user before the data reaches you. You get aggregated, delayed, and modelled signal. The networks then layer their own automation on top, deciding placements and bids on your behalf. You're left optimising creative against a feedback loop you can't fully see and can't really trust.
At Applica Agency, in addition to traditional app campaigns and web-to-app funnels, we run a different setup for our clients' apps. It's not new technology. It's a recombination of tools that already exist, configured in a way most app advertisers haven't tried. We call it a Direct App Campaign — web-style tracking, app-style delivery.
Here's how it works, where it shines, and where it doesn't. And if you want the full implementation playbook — the exact step-by-step setup we run for clients, with screenshots and configuration details — we've put it together in a free step-by-step Direct App Campaign guide you can access at the end of this article.
What's actually broken with traditional iOS app campaigns
Three structural problems, in order of how much they hurt — and we'll work through each below.
1. Attribution is modelled, not measured. SKAN gives you a coarse conversion value and a delayed postback — typically 24 to 48 hours for the first postback, and 24 to 144 hours for postbacks 2 and 3. Meta's Aggregated Event Measurement (AEM) fills the gap with statistical modelling. Both are necessary under Apple's privacy rules, but neither tells you which user did what. You get directional truth, not ground truth.
2. Reach is capped. App campaign inventory is a subset of total network inventory. Paddle's data on the broader app vs web split suggests roughly a 15% audience overlap between web and app store buyers, which means a meaningful share of your potential audience never sees an app-only campaign. If your audience is saturated on traditional app campaigns, the network can't show your ad to people sitting in pure web inventory, even if those users would convert.
3. You've lost the steering wheel. Modern app campaigns are almost fully automated. You set a budget, an objective, and a bid cap, and the algorithm decides the rest. That's fine when signal is rich. It's a problem when signal is poor, because the algorithm is optimising against the same modelled data you can't see.
Plenty of teams have responded by going full web-to-app: build a landing page, run a personalised onboarding flow on the web, take the subscription on Stripe, then push the user into the app. It works for some apps. For most, the hidden costs (Stripe fees, tax compliance, App Store Optimization (ASO) damage from sending traffic away from the App Store, the headcount needed to maintain a web funnel) outweigh the gains. Industry data from RevenueCat's State of Subscription Apps suggests it only really pays off at meaningful scale, and even then it's not a clean win.
The Direct App Campaign setup keeps the best parts of web-to-app — deterministic tracking, expanded reach — without the parts that hurt: no website to build, no tax headaches, no ASO hit.
How a Direct App Campaign actually works
The trick is that the campaign is technically a web campaign on the ad network's side, but the user experience is identical to a normal app install. Here's the flow:
- User sees the ad on Meta, TikTok, or Google.
- Click goes to a tracking link from your MMP (Adjust or AppsFlyer).
- The tracking link redirects, behind the scenes — under a second, unnoticeable to the user — to the App Store or Play Store.
- User installs the app and converts.
- Conversion events fire back to the ad network through Conversions API (CAPI), server-to-server, using the original click ID in real-time.
To the user, this looks like any other app install ad. To Meta, it looks like a web purchase, which means you can run it as a Sales-objective campaign with all the targeting, optimisation, and retargeting capabilities that come with web inventory. To you, it means your conversions arrive in real time, tied to specific clicks, with rich identifiers attached.
We walk through each of these steps in detail — including the exact MMP configuration, tracking link setup, and CAPI event mapping — in our step-by-step Direct App Campaign guide.
A quick glossary, because three acronyms do most of the work here:
- CAPI (Conversions API): A server-to-server pipe from your backend (or your MMP) directly to the ad network. No browser, no SDK, no SKAN. Events arrive instantly with whatever identifiers you choose to send.
- EMQ (Event Match Quality): Meta's score for how well it can match your conversion events back to a specific user. Higher EMQ correlates with materially better attributed conversions, and you raise it by passing more identifiers (email, phone, IP, user agent, click ID).
- Postback: The signal sent from your MMP to the ad network confirming a conversion happened. In a Direct setup, this is server-to-server through CAPI rather than going through SKAN.
The result is what we'd call deterministic-style matching — practically, a non-privacy-invasive form of device-side fingerprinting, conceptually similar to what Google has started doing with ODM/ICM for iOS. Instead of probabilistic guesses or aggregated SKAN buckets, you're matching real click IDs to real conversion events. In some accounts we're seeing near-perfect alignment between what the network reports and what RevenueCat reports. That's almost unheard of in iOS app advertising.
What a Direct App Campaign unlocks
Four things change when you run this setup at scale.
Reach expands meaningfully. You're now bidding on web inventory, which is a much larger pool than app campaign inventory. We've seen clients reach audiences that were essentially invisible to their previous app-only setup, particularly older demographics and B2B-adjacent users.
Retargeting comes back to iOS. Because you're passing hashed identifiers (email, phone, click ID) through CAPI, you can build custom audiences and run actual retargeting campaigns on iOS. You can also use those audiences as exclusions, so you stop spending on users who already have your app. This alone is worth the migration for most subscription apps.
Paywall personalisation by ad source becomes trivial. Since you have the tracking link parameters all the way through to the install, you can show different paywalls based on campaign or ad set. Trial-only paywall for trial-objective campaigns. Higher prices for high-intent ads. Visual continuity between the ad creative and the first screen the user sees.
ASO stays intact. Users still land on your App Store page. They still install through App Store or Google Play. Reviews, rankings, and the rest of your organic surface keep compounding.
Where it gets complicated
This is where most of the existing material on this approach quietly skips. We don't.
EMQ takes time to build. When you first launch, your Event Match Quality score will likely be low. That's expected. As volume grows and you pass richer identifiers, it climbs. Worth noting that low EMQ doesn't always mean broken tracking; we've seen accounts with mediocre EMQ scores and accurate event counts. Treat EMQ as a quality signal, not a pass/fail gate.
Access tokens occasionally expire. Rare, but real — particularly on Meta. When it happens, tracking can disrupt for a few days, and ramp-up after restoration takes additional time as the algorithm rebuilds confidence. Worth flagging in your operational runbook so the team knows what they're looking at when EMQ drops without warning.
View-through conversions don't carry over. With a Direct setup running as a web event, view-through attribution isn't possible. Depending on the app and ad placements, this matters more or less — for apps where users typically convert quickly after click, the gap is small. We've seen roughly 5–7% differences between Meta-reported and MMP-reported conversions, which is acceptable variance for most subscription apps. For apps where users take longer to convert, the gap widens.
Web Subscription vs Subscription in Meta reporting. Because Meta sees the conversion as a web event, your subscription events show up under "Web Subscription" rather than the app subscription bucket. The exact label depends on how you've mapped events in your MMP. If you've also mapped Subscription generically, you'll see the same conversions counted in both places. It's not double-counting in spend; it's two views of the same event. Worth explaining to anyone reading the dashboard who isn't in the weeds.
Admin access required. To set this up properly you need admin on Meta Business Manager and the MMP, plus the ability to generate access tokens and configure event mapping. If you don't have that level of access, the integration will be partial at best.
TikTok plus AppsFlyer is currently a headache. TikTok doesn't behave like Meta here. Their Sales objective requires a "weblink dataset" with attributed events flowing in, but AppsFlyer's TikTok integration only sends postbacks attributed to TikTok itself, which means TikTok never sees enough events to let you select the dataset in the first place. Chicken, meet egg. The Traffic objective sometimes works as a workaround (run Traffic to seed attribution, then switch to Sales), but TikTok has been turning that path on and off across accounts — for some accounts, tracking URLs aren't allowed on traffic campaigns at all. Adjust works fine for TikTok Direct setups. Meta works fine across both Adjust and AppsFlyer. So the right MMP and network combination matters, and we'd rather flag this upfront than have a client find out three weeks in.
SKAN doesn't fully go away. Where the Direct setup falls back to standard App Campaigns — typically TikTok in the AppsFlyer scenario above — you inherit SKAN's attribution windows and privacy thresholds. The same applies in principle to any network and MMP combination where the Direct setup isn't viable. Plan accordingly.
When we'd still run a traditional iOS app campaign
We're not zealots. Traditional app campaigns still make sense when:
- The client has very low spend and the MMP cost doesn't pay back. (The Direct setup itself is essentially free to configure; what you're paying for is the MMP, which most teams already have.)
- The MMP and network combination doesn't support a clean Direct setup yet (TikTok plus AppsFlyer being the current example).
- The product doesn't generate enough server-side events to feed CAPI usefully.
For everyone else, especially mid-market subscription apps spending meaningfully on Meta, this is the setup we'd recommend.
Want the full build, step by step? We've documented the entire Direct App Campaign setup — tracking links, CAPI configuration, event mapping, paywall personalisation, and the gotchas to avoid — in a free, in-depth guide. Get the step-by-step Direct App Campaign guide here (just leave your details to unlock it).
What this means for your iOS UA strategy in 2026
The mobile user acquisition (UA) playbook has shifted. SKAN compliance is still required, but it's no longer the centre of your attribution stack. The teams winning right now are the ones treating SKAN as a baseline signal and building deterministic tracking on top of it through CAPI, MMP integrations, and tracking links. App Tracking Transparency (ATT) prompt acceptance is part of the same story — the higher your opt-in rate, the richer the deterministic signal feeding everything downstream.
Direct App Campaigns are one piece of that shift. They're not magic, they're not new technology, and they're not a fit for every app. But for the right client, the difference between running a traditional app campaign and running a Direct App Campaign is the difference between optimising blind and optimising with eyes open.
Frequently asked questions
What's the difference between a Direct App Campaign and a traditional iOS app install campaign?
A traditional iOS app campaign relies on SKAN for attribution — aggregated, delayed, and modelled. A Direct App Campaign technically runs as a web campaign on the ad network side (Meta Sales objective, for example), but the user still installs from the App Store. Conversions fire back through CAPI in real time, tied to the original click ID. The user experience is identical; the data you get back is dramatically richer.
Do I still need SKAN if I'm running Direct App Campaigns?
SKAN compliance is still required by Apple, and where your Direct setup falls back to standard App Campaigns (typically TikTok with AppsFlyer right now), SKAN is the attribution layer. Treat SKAN as a baseline signal and Direct App Campaigns as the deterministic layer on top.
Will my App Store Optimization suffer if I run Direct App Campaigns?
No. Users still install through the App Store or Google Play. Your conversion rate on the store listing, your reviews, your rankings — all of it keeps compounding. This is one of the main reasons Direct App Campaigns beat full web-to-app for most apps.
Can I run Direct App Campaigns on TikTok the same way as Meta?
Not cleanly yet. The combination of TikTok plus AppsFlyer has a chicken-and-egg problem with the weblink dataset (covered above). Adjust works for TikTok. Meta works across both Adjust and AppsFlyer. We'd flag the network and MMP combination before assuming the setup will work.
Three takeaways
First, traditional iOS app campaigns are designed around SKAN's privacy limits, not around what marketers need to optimise. Aggregated, delayed, modelled signal is the floor — not the ceiling.
Second, a Direct App Campaign trades the SKAN-driven app campaign model for a web-campaign model with CAPI postbacks, while keeping ASO and the App Store install experience intact. You get deterministic-style matching, expanded reach, retargeting on iOS, and paywall personalisation — without building a website or eating Stripe fees.
Third, the setup isn't universal. TikTok plus AppsFlyer, low-spend accounts, and apps without server-side event tracking are still better off on traditional app campaigns. Pick the setup that fits the constraints, not the other way around.
If your iOS user acquisition is leaking budget against SKAN modelling and you're looking for a setup that gives you real-time, deterministic attribution back, let's talk about whether a Direct App Campaign setup fits your stack. And if you'd rather build it yourself first, grab our step-by-step Direct App Campaign guide — the complete setup, free, in exchange for your details.
