Modeled conversions: filling tracking gaps

What modeled conversions are

Modeled conversions are figures Meta includes in reporting that were not directly observed through a pixel fire, app event, or server-side signal, but were instead estimated using statistical modeling. When a conversion cannot be directly matched to an ad due to missing cookies, a blocked device identifier, or a user declining tracking permission, Meta can still estimate the likelihood that a conversion happened and attribute a modeled share of it to the ad, based on patterns from observed, comparable conversions.

These numbers sit inside the same reported totals as directly observed conversions, usually without a visible label distinguishing one from the other unless you dig into breakdowns or documentation.

How it works

Meta builds the model using conversions it can observe directly as training data. It looks at the relationship between ad exposure, audience characteristics, and confirmed conversions among users with intact tracking, then applies that relationship to estimate outcomes for users where direct tracking failed. The exact methodology is not fully public, but the general approach is standard in the industry: use the observable population to infer the behavior of the unobservable one.

The proportion of modeled versus observed conversions in your account depends heavily on your traffic mix. Accounts with a large iOS user base, or in regions and browsers with more privacy restrictions, tend to have a higher share of modeled conversions. Accounts with mostly Android traffic and full Conversions API coverage rely on modeling less.

Why it matters

Modeled conversions exist so reported numbers do not simply collapse when tracking is blocked. Without modeling, Meta’s reporting would sharply understate performance for any audience segment with high tracking loss, potentially causing advertisers to pull back budget from campaigns that are actually working fine. Modeling smooths over that gap, but it also means a portion of every reported total is an estimate rather than a hard count, and estimates carry error.

This matters most when comparing performance across time periods or audience segments with different tracking coverage. A campaign that shifted toward more iOS traffic might show similar total conversions to before, but a larger share of those numbers is now modeled rather than observed, which changes how much confidence you should place in the reported total.

How to act on it

Do not assume every reported conversion number is a directly observed fact. When precision matters for a big budget decision, cross-check reported numbers against your own backend data or CRM records where possible, since those reflect actual outcomes independent of any platform’s modeling assumptions. Improve your directly-observed signal by implementing the Conversions API properly, since a higher rate of observed events reduces the model’s reliance on inference and generally improves accuracy for the modeled portion too.

Use incrementality tests, like conversion lift studies, as an independent check when modeled conversions make up a significant share of your reporting.

Common mistakes

Treating a reported conversion count as an exact, audited figure ignores that a meaningful portion may be modeled. Comparing performance across campaigns or time periods with very different tracking coverage, without accounting for the different modeling share, can produce misleading conclusions. Skipping Conversions API implementation, which would reduce reliance on modeling, is a common and avoidable gap. Panicking over a reported drop in conversions without checking whether tracking coverage changed first often leads to unnecessary campaign changes.

How YieldBI helps

YieldBI tracks pixel and Conversions API coverage alongside campaign performance, making it easier to spot when a large share of reported conversions may be modeled rather than confirmed, and its incremental attribution models factor that uncertainty into the numbers it surfaces.