What is signal engineering, and what does it fix after ATT?

You are probably here because

None of these are media buying problems. They are signal problems, and most of them are fixable.

• Meta reports one ROAS, RevenueCat reports half of it, and finance believes neither. They will never agree, and nobody on the team can say why.
• Your SKAN conversion values come back empty on most campaigns and nobody knows why.
• Meta scales fine. Google and TikTok stall on the same creative.
• You switched to value optimization and it got worse.
• Trial starts are cheap and paid conversions never follow.
• Three SDKs are in the app. Nobody can say which one owns the conversion value.

What signal engineering fixes

Five layers, in the order I build them.

• The event layer. One canonical event taxonomy for your app, mapped explicitly to Meta standard events, Google conversion events, TikTok events and your MMP. Trial start, first payment, renewal, cancellation, refund. Each with a value, a currency and an ID.
• Server side delivery. Meta's Conversions API for app events, TikTok's Events API and Google's app conversion setup through your MMP or Firebase, wired to your subscription backend so renewals, refunds and trial conversions reach the platforms even when the app is closed. Deduplicated by event ID so nothing counts twice.
• The iOS conversion value schema. The small value Apple lets you send back is the only post install signal you get for users who declined tracking. I design it around your funnel and your volume, so campaigns clear Apple's privacy thresholds instead of returning nothing. One SDK owns it. When two SDKs write it, the last call wins, and right now that is usually an accident.
• Value signals for bidding. Purchase value, margin or predicted LTV, sent to every platform, not only Meta, and only once I have checked that the value actually correlates with what users go on to pay. A bad value teaches the algorithm to buy the wrong users faster.
• The reconciliation view. One monthly comparison of platform, MMP, RevenueCat and store payout numbers with the expected gaps written down, so the next time the numbers disagree you know in five minutes whether it is structural or a bug.

What it cannot fix after ATT, and why I say so

Since iOS 14.5, users who decline App Tracking Transparency cannot be attributed at the user level. Apple's SKAdNetwork and AdAttributionKit return delayed, aggregated postbacks with no device identifier, and they withhold detail on low volume campaigns on purpose. No Conversions API integration, no MMP feature and no attribution recovery tool changes that. Meta routes those events through Aggregated Event Measurement. Google models them. TikTok models them.

So I do not promise deterministic attribution. I promise that the signals you can control are right, that the platforms get the best possible input to optimize on, and that you will know which discrepancies are normal. Platform ROAS and subscription revenue will still disagree after the work is done. They will disagree for reasons you can explain. If a vendor tells you otherwise, ask them where the user ID comes from.

Which system reports what on iOS?

Five systems count installs and conversions from the same iOS campaigns, and when they disagree none of them is necessarily wrong. They count different things, over different windows, on different delays. I built the table from each vendor's own documentation, checked on 29 September 2026.

Google's iOS picture takes work on your side. For Integrated Conversion Measurement, Google lists an active iOS App campaign for installs, your MMP's first_open and post install events imported into Google Ads, on device measurement with event data, and a current MMP SDK. On device measurement with event data needs iOS 12 or later, the Google Analytics for Firebase SDK from version 11.14.0, and the Analytics property linked to Google Ads, and Google says it "will be inactive" for users in the EEA, the UK and Switzerland. So Google Ads, the MMP and SKAN disagree by design, and Google's own guidance is to read the ICM view if you implemented it, and Google Ads or SKAN if you did not. The ICM setup for each integration route and how I reconcile Google Ads, the MMP and SKAN each have their own article.

Some gaps have nothing to do with definitions. On one Google account I ran, the revenue event sent $1 instead of $0 when a conversion had no value, which inflated Google's reported ROAS across the board and most on iOS. It is the account behind my bid strategy test, and this is the kind of bug the reconciliation view exists to catch.

How do SKAN 4 and AdAttributionKit work for Meta campaigns on iOS?

Apple decides what comes back: up to three delayed postbacks per winning ad, each with a conversion value your app writes on the device, and less detail the smaller the campaign. On Meta, each iOS app promotion ad set uses either that SKAdNetwork attribution or Meta's own Aggregated Event Measurement, depending on which one your optimization event is eligible for.

SKAN 4 and AdAttributionKit both return three postback windows, and only the first can carry a fine value. Apple drops to coarse or to nothing when a campaign is too small to protect the crowd. A 7 day trial's first payment lands on day 7 or 8, in the second or third window, as a coarse value, days later. That is why the schema has to be designed around your funnel and your volume, not copied from a template, and why too many geo and creative splits push every campaign under the threshold at once. Which window each trial length lands in, and who writes the value, is in whether SKAN can measure the payment after a free trial.

Who can fix CAPI and event mapping for Meta?

Someone who owns the whole event path, from the app SDK and the MMP to the subscription backend and Events Manager, because most Meta signal bugs sit where two of those meet. On a retainer that is me, with an attribution engineer from my network for the SDK and server work and one developer on your side who can ship changes.

The Conversions API for app events sends the same events from your server that the SDK or the MMP sends from the device, and Meta deduplicates them by event ID. Its job is completeness and value: renewals, refunds and conversions that happen when the app is closed, each with a value and a currency. It does not restore attribution for users who declined tracking; those events still flow through Aggregated Event Measurement. Worth doing, not a workaround. When an event reaches Meta and is still marked ineligible for AEM, the checks for each route are in why trial and purchase events are ineligible for Meta AEM.

pLTV and value optimization

A model predicts each new user's value from the first day or two of behavior. That number goes to the platform as the purchase value, or on iOS is compressed into the conversion value. The platform then bids for users who look like your high value predictions. Which event and which bidding mode fit which app is written up from $1.2M of Meta spend.

On Videa that layer, a custom CAPI purchase signal and predicted LTV in bidding, is what took D0 ROAS from 20% to a 43% record week. A $606K test settled that day zero value predicts D28 ROAS better than cost per purchase does.

Which event should you optimize on?

These are the three questions I ask, in order, before an account moves deeper. The full ladder, from install upward, is in which event a subscription app should optimize for.

1. Do paid events clear the platform's learning threshold at your volume? Meta's guidance is about 50 results per ad set in the week after its last significant edit. If they do not, optimize on trial start plus an activation event. If they do, go to question 2.
2. Is trial to paid healthy? If not, stay on trial start plus an activation event. Both conditions have to hold before you move. If it is, move to purchase and go to question 3.
3. Does the value you would send correlate with what users go on to pay? If it does not, stay on purchase. If it does, send the value. Predicted LTV needs three more things: the prediction is calibrated against cohorts that have actually matured, there is enough volume, and the platform gets it before the attribution window closes. Switched on early, it optimizes toward the wrong users with great confidence.

Reconciling platform ROAS with subscription revenue, across countries

Platforms count attributed and modeled conversions inside their own window, at gross price, on the click date. RevenueCat counts receipts on the transaction date, net of refunds, in one currency. Store payouts arrive on a fiscal calendar, net of commission and local tax. Those are structural gaps, and they are expected. A gap that changes size from one month to the next usually has a bug behind it: a duplicated purchase event, a currency mismatch, a value that reaches one platform and not the other.

Multi country ROAS adds cohort maturity. A country whose users pay annually looks worse at day 7 and better at day 90 than one that sells monthly, so I compare cohorts at equal age, in one currency, net of commission, before deciding which country gets budget. The $383K audit is what that looks like on a real account, and how many purchases a ROAS needs before it means anything sets the floor for each cut.

How the work runs

Signal engineering is part of the retainer, and it comes first. The read starts with the growth audit: what every platform currently receives, what it is optimizing toward, and the four way comparison with the expected variance written down. After the read, some teams implement the fixes themselves from the prioritized list, with the engineering effort estimated per item. Some ask me to run the accounts. Both are fine.

For SDK work and anything that runs on your servers I bring an attribution engineer from my network. I design and own the layer; the engineering hands are specialists. You need one developer who can ship changes during the engagement, and read access to Events Manager, the MMP, RevenueCat or your subscription backend, and the ad accounts.

If you are earlier than a retainer and want the diagnosis without the engagement, a paid 90 minute session covers your setup and what to fix in which order. It is booked through the same calendar as the intro call.

Questions people ask