Lucas Moscon was a senior acquisition manager at Monkey Taps, advises companies including Life360, and founded Appstack, a mobile analytics and measurement platform. That means he can describe the attribution pipeline rather than just the dashboard. He joins the Price Power Podcast with strong opinions about Apple, about MMPs, and about which numbers deserve your trust.

Ten Tips from the Episode

1. ATT forced everyone to look at the whole picture

Lucas's read on what changed is broader than the usual signal-loss story. ATT pushed teams toward aggregated data, toward matching a source to a user through onboarding questions rather than identifiers, toward testing web-to-app and app-to-web, and toward retention, because remarketing got hard. It also moved control of the attribution pipeline away from the legacy MMPs.

His verdict on Apple's handling is blunt. The technology made sense. The execution did not, and the industry has drifted back toward IP-based fingerprinting as a result.

2. Optimize for ROI, not ROAS

When apps tell Lucas they want to know whether an iOS campaign hit a day-7 ROAS of 100 percent, his answer is that this is not how it works anymore.

ROAS is the metric he has least confidence in on iOS, because without IDFA it depends on probabilistic matching and on how wide your conversion value mapping is, either of which can inflate or deflate the number. He would rather look at total revenue.

One large health and fitness client he advises makes most decisions from a single ROI chart: ad spend pulled from the networks, revenue from the store consoles and the subscription platform, divided by install date. That tells them whether a cohort is profitable at the network or company level by day 60.

3. A longer payback period is a growth lever

Everyone optimizes to get money back faster, and then discovers that scaling ROAS is close to impossible, because more spend pushes it down.

Lucas's argument: a team that can wait until day 180 for payback, while competitors need day 60, can simply buy more than they can. The constraint is cash flow rather than strategy, and the reward exists precisely because it is risky.

4. Build a waterfall of early proxies

The obvious objection to a long payback is that you spend six months finding out you were wrong. The answer is layered proxies.

Lucas describes a company that checked each cohort against benchmarks on every one of the first ten days. A miss on day three lowered confidence. Another miss on four and five lowered it again. By day eight to ten they could call it, rather than waiting for day 180. For subscription apps, cancellation rates in the first 15 days after a trial conversion work the same way.

5. Three layers, and how web-to-app is wired

For a self-attributing network like Meta, events reach them either through the Conversions API or the Facebook SDK, and three layers then do the attribution. The IDFA cohort, meaning users who consented. AEM, the probabilistic layer, using IP and other signals. And SKAdNetwork, the deterministic layer.

Web-to-app is worth understanding because you can build it yourself. The user clicks an ad, which hits a links API that records fingerprint ID, IP and country. They are redirected to the store, install, and open the app. Your SDK generates a user ID and calls the same links API, which matches it to the earlier attribution parameters, and that install is sent to Meta through the Conversions API.

6. Probabilistic matching is mostly the IP address

Appstack ran an internal test comparing match accuracy with and without the IP address, and IP accounted for more than 90 percent of matches. OS version, battery level and the rest contribute very little.

Lucas has been arguing to Apple that they should block the device IP, through Private Relay or something like it, on the grounds that this is a user privacy question rather than an advertiser one.

7. You need an MMP less often than you think

Lucas lists the genuine cases. Running AppLovin-style DSPs, which require the middleman. Web-to-app on Google, which needs certified link infrastructure. Flutter or React Native apps, because of SDK language support. Corporate requirements like server-to-server integrations and data clean rooms. And avoiding the work of maintaining the same conversion value mapping schema across every network yourself, which is a real cost.

Outside those, his view is that a lot of apps are paying out of inherited habit. He describes advising a company doing around $20M a month, asking for MMP access, and finding the team did not recognize the term. When they located the account, the last login was six months earlier and the invoice was $350,000 a year. Nobody could name a single thing it was used for.

8. Pick a source of truth per metric, then triangulate

On iOS, the more granular you go, the less accurate the data gets. So be deliberate about which number you use for what.

Total revenue should come from the store or your subscription platform, on the simple logic that Apple is the one paying you. Installs are worth comparing across App Store Connect, Meta, the networks and your product analytics. For in-app events, where you look depends on whether you want attributed or total.

Then stack them against each other and accept a range. Triangulate rather than hunting for the real number, because there is not one.

9. Keep your conversion values simple

A conversion value is the single in-app event that matters most to you, passed back as an optimization signal. On Meta you only get to optimize for one.

Lucas's recommendation is deliberately unglamorous. Do not use the full 63-value range. Set 63 to your primary purchase or subscription event and 62 to trial start. If you want an intermediate layer, a paywall view works as a proxy, triggered client-side when someone taps continue.

One mechanical detail matters: keep the low value tied to a session event, an app open, so the conversion value always fires from a client-side trigger.

10. Your trial conversions are capped by retention

A conversion value only updates when the user opens the app. For the second and third SKAN windows, that means your reporting is bounded by retention.

If day-10 retention is 15 percent, most of the people who converted from trial never reopened the app and so never triggered the update. SKAN shows you a fraction and you may read it as the whole.

You can work backwards: if you know your retention rate and how many conversions were reported, you can extrapolate the real number. But that is math you do yourself. It does not come through the reporting APIs.

Key Takeaway

Stop looking for the real number, because there is not one. Pick a source of truth for each metric, stack your sources against each other, and work with a range you trust rather than a figure you do not. Then spend your effort on the parts you actually control: the conversion value you send, how fast you send it, and whether your payback window is a choice or an accident.