Table of Contents
How Signal Works: Inside the Machinery
- Modern ad delivery runs in two stages. A retrieval model narrows millions of ad candidates down to a shortlist, then a ranking model predicts conversion probability and prices the auction. Conversion events feed both.
- A Conversions API event is not "a sale." It is a structured payload of an event name, a timestamp, an action source, a deduplication key, a set of hashed identity parameters, and transaction metadata. Each field does specific work.
- Event Match Quality is a 0 to 10 score of how well your identity parameters resolve to real accounts. Meta labels 8.0 and above as Great. For Purchase events specifically, practitioners target 8.5 and up, because checkout is where you hold the most identifiers.
- The deepest problem is not volume. It is selection bias. A model trained only on DTC purchasers learns the distribution of DTC purchasers and goes looking for more of them, no matter how much you spend.
Introduction
Most explanations of signal start and end in the same place: send more conversion data, and the algorithm gets smarter. That is true. It is also where the explanation usually stops.
This article goes a layer deeper, explaining:
- what the algorithm actually does with an event
- why one event is worth more than another
- why a brand doing 85% of its volume at retail can run a technically flawless Conversions API setup and still watch its Marketing Efficiency Ratio flatten.
We cover what the machine is, what you are transmitting to it, how it decides whether to believe you, and what happens to the model when the data you send represents only a fraction of your business.
If you want the strategic overview first, start with our guide to signal.
How Meta’s Algorithm Works
The mental model most marketers still carry is from the pixel era: you define an audience, the platform finds those people, an auction decides the price.
That model is obsolete. Meta and Google both now run multi-stage recommendation systems, and the stages have different jobs.
Stage 1: Retrieval
Meta's retrieval layer is Andromeda, rolled out through 2025 and effectively the default behavior across ecommerce accounts by early 2026. Its job is to take the tens of millions of eligible ad candidates in the system and narrow them to a shortlist of roughly a few thousand for a specific person in a specific moment.
Andromeda inverted the old question. It no longer asks "who should see this ad." It asks "which ad should this person see right now."
If your ad does not survive retrieval, your bid is irrelevant. It never enters the auction, and budget cannot buy its way past this stage.
Stage 2: Ranking and Auction
Candidates that survive retrieval move to ranking, where Meta's Lattice models and the GEM foundation model estimate expected value for each candidate: predicted click-through, predicted conversion probability, predicted value of the conversion, weighted against the bid. The winner is selected from a pool of roughly a thousand survivors.
Google's Performance Max works on the same architecture even though the naming differs. PMax pulls inventory eligibility across Search, Shopping, YouTube, Display, Discover, Gmail, and Maps, then Smart Bidding sets bids per auction based on a predicted conversion rate for that user, that query, that context.
Where Conversion Events Enter
Both stages are trained on outcomes, and outcomes are the conversion events you send. Retrieval learns which kinds of people converted on which kinds of creative. Ranking learns the conditional probability that this specific person converts if shown this specific ad.
That is the whole reason event data has become the primary lever. You are not tuning an audience anymore. You are supplying the labeled training data for the model that selects your audience for you. Creative is the other input. Everything else is a constraint you place on a system that would rather have fewer constraints.
What a Conversions API Event Actually Transmits
"Sending data to Meta" is a phrase that hides a lot of structure. Here is the anatomy of a server-side Purchase event and what each part is for.
Event-Level Fields
- event_name carries the standard event type, for example Purchase. It must match the event your campaign optimizes on, or the model never sees it as a positive training label.
- event_time is the Unix timestamp of the transaction. It governs attribution windows and how heavily the model weights the event for recency.
- action_source declares where the purchase happened: website, app, physical_store, or system_generated. It tells Meta this was not a web session, so the platform does not evaluate the event against browser parameters it could never have.
- event_id is your unique key for the transaction. It is what allows Meta to deduplicate a server event against a pixel event firing for the same purchase.
- event_source_url carries the page URL. Web events only, not applicable to retail.
Identity Parameters
These are the fields that decide whether the event matches anyone at all. Every one is normalized first (lowercased, trimmed, phone formatted to E.164) and then hashed with SHA-256 before transmission. The raw values never leave your systems.
Ranked roughly by matching weight:
- Email (em) is the strongest single identifier. Most Meta accounts have a verified email attached.
- Phone (ph) is close behind, especially for mobile-first accounts.
- Click ID (fbc) carries very high weight when present, but it only exists if the person arrived from a Meta ad.
- Browser ID (fbp) is high value and web only.
- External ID (external_id) is your own stable customer identifier, hashed. It is underused and genuinely valuable, because it lets Meta connect repeat events to the same person even when other fields vary.
- Name, city, state, ZIP, and country (fn, ln, ct, st, zp, country) are moderate individually and meaningful in combination.
- IP address and user agent (client_ip_address, client_user_agent) are high value for web and unavailable for in-store purchases.
With retail purchases, there is no fbc, no fbp, no browser IP, no user agent. Four of the strongest matching inputs are structurally absent. Everything therefore rests on em, ph, external_id, and the name and address block.
This is the single most important technical fact about offline signal, and it dictates what a capture mechanism has to collect at the point of the retail purchase to be worth anything.
Transaction Metadata
Value and currency are what make value-based optimization possible. Without them the model can only optimize for conversion count, which pushes it toward your cheapest buyer rather than your most valuable one. content_ids, content_type, and order_id support catalog matching, product-level learning, and reconciliation against your own records.
Event Match Quality & Why It Matters
What EMQ Measures
Event Match Quality is a score from 0 to 10 that reflects how effectively the customer information attached to your events resolves to real Meta accounts. It is computed per event type, not per account, and it is surfaced in Events Manager. Meta's published bands are Great at 8.0 and above, Good from 6.0 to 7.9, with lower ranges indicating meaningful signal loss.
Two things are commonly misunderstood.
It is not a count of parameters: EMQ is a weighted measure of which parameters arrived, how cleanly they were formatted and hashed, and what proportion of your event instances actually matched against Meta's graph. Sending five weak fields does not beat sending email and phone correctly.
It varies legitimately by event type: PageView scores low because anonymous browsers hand you almost nothing. Purchase scores highest because checkout is where you collect the most. A PageView at 6.5 and a Purchase at 9.0 in the same account is normal and healthy.
Why 8.5+ EMQ is the Target for Purchase Events
Meta's official threshold for Great is 8.0. In practice, for the Purchase event, the band worth aiming at is 8.5 and above, for three reasons.
First, Purchase is the event your campaign optimizes on. Every point of match loss on Purchase is a positive training label the model never receives. Loss on upper-funnel events costs you far less.
Second, operators consistently find that pixel-only setups cap in the 4.0 to 5.9 range, because the browser cannot reliably forward IP, user agent, and first-party cookie context in every environment. Getting to 8.0 generally requires a server-side connection. Getting past 8.5 requires the identity fields to be complete and clean, not merely present.
Third, returns compress sharply above 9.0. The interval from 6.0 to 8.5 is where nearly all the recoverable match rate lives. Chasing 9.8 on a small event volume is a worse use of engineering time than getting a large, currently invisible event stream to 8.5.
EMQ as a score in Events Manager is calculated for web events. For offline and in-store events, the diagnostic you should be reading is the match rate on the event set: the share of uploaded events Meta successfully resolved to an account. It measures the same underlying property, and it is the number to hold a retail signal vendor accountable to.
Across brands using Brij Signal, the average match rate on forwarded offline purchase events is 99.7%.
How Matched Events Become Audiences
This is the part that costs brands the most money and gets discussed the least.
The Model is Trained on your Positives
Strip away the branding and Advantage+ and Performance Max are supervised learning systems. Every matched conversion event is a labeled positive example. The model learns a representation of what a converter looks like, expressed across thousands of behavioral and contextual features, then scores the eligible population against it.
Modern lookalike expansion works the same way, just automatically. Advantage+ Audiences uses your conversion signal as the targeting input rather than requiring you to build a seed list. Google's Customer Match segments and PMax audience signals do the equivalent on their side.
Selection Bias is the Failure Mode
Here is the mechanism, stated plainly. A model trained on a sample learns the distribution of that sample, not the distribution of your business. If the only purchases visible to the platform are the ones that happened on your Shopify store, the model builds its representation of "your buyer" from DTC purchasers only.
For most consumer goods brands, DTC is 10 to 20% of total volume, and it is not a random 10 to 20%. DTC buyers skew toward people who already knew the brand well enough to seek out the website, who were comfortable paying full price rather than buying on a retail promotion, who tolerate shipping timelines, and who often arrived through a channel that already found them. The retail buyer who picked you up in a Target aisle on a Tuesday is a different person with different behavior.
Feed the model the first group and it will faithfully go find more of the first group. It is doing exactly what you asked. The output looks like the model plateauing. What is actually happening is the model converging correctly on a target that represents a fifth of your business.
Three compounding effects follow.
1. Retrieval never surfaces your retail buyer: The people who buy you at retail are not in the shortlist the retrieval model builds, so your ads never enter the auction for them.
2. Value-based bidding optimizes the wrong value: If DTC average order value differs from retail basket value, Smart Bidding and value optimization price your auctions against a number that is not your real economics.
3. You cap your own scale: As the model saturates the small addressable pool it has learned, incremental spend buys progressively worse matches inside that pool. This is the classic signature of rising CAC on flat creative performance.
No amount of creative testing corrects a training set problem. Creative changes which ads get retrieved. It does not change who the model believes your customer is.
How Google and TikTok Receive Signal
Google's path for offline purchase data has consolidated. Offline conversion imports and enhanced conversions for leads have migrated to the Data Manager API, with the legacy Google Ads API UploadClickConversions path blocked for new adopters as of June 15, 2026.
Accounts with an active import history in the months before the cutoff were given a migration runway. Accounts without one hit a not-allowlisted error if they try to start now.
The business function did not change. Only the pipe did. Data Manager is now the single ingestion point for both conversion imports and Customer Match audience data, and Google has been explicit that it is the recommended path going forward.
Google has also signaled that from Q3 2026, including IP addresses with observation timestamps can improve Customer Match rates.
Downstream, the effect is identical to Meta's. Imported conversions become the outcome data Smart Bidding trains on. Customer Match segments become audience inputs for Performance Max.
A brand importing only DTC transactions is teaching Smart Bidding a DTC-shaped conversion function.
TikTok
TikTok's Events API accepts server-side conversion events with hashed identifiers and runs the same match-then-model loop. TikTok also exposes an event match quality equivalent on the same 0 to 10 logic.
The through-line across all three platforms: server-side transmission, hashed deterministic identifiers, a match against the platform's user graph, and a model that trains on whatever survives the match.
What a Complete Signal Layer Must Do
Given the above, the requirements for making a retail purchase usable as signal are specific and non-negotiable.
Capture Identity at the Moment of Purchase
Since fbc, fbp, IP, and user agent do not exist for an in-store transaction, the capture mechanism has to collect email or phone directly from the shopper. That means giving them a reason: a rebate, a warranty registration, a sweepstakes entry, product content. T
he incentive is not a marketing flourish. It is the only way the strongest matching parameters get created at all.
Verify the Purchase
A registration without a verified transaction behind it is a lead, not a conversion event. Sending it as a Purchase event pollutes the training set with false positives, which is worse than sending nothing.
Receipt validation or a verified retailer transaction record is what makes the event deterministic.
Normalize and Hash Server-sSde
Lowercase, trim, format phone to E.164, then SHA-256. Hashing in the browser leaks the raw value into a context you do not control.
Type the Event to the Campaign Objective
An event sent as a custom event when the campaign optimizes on Purchase is invisible to the optimizer. This is one of the most common silent failures.
Set action_source Correctly and Deduplicate
Retail events should carry physical_store. If the same buyer also transacts on your site, event_id and order_id prevent double counting.
Respect Latency
Meta and Google both weight recency. An event batched and uploaded weeks later carries far less optimization value than one sent within hours of the transaction.
Brij Signal
Brij Signal exists because the hard part is not the API call. It is producing a verified, well-identified purchase event for a transaction that happened on a shelf you do not own, in a store whose POS you have no access to.
The flow:
- A shopper buys the product at retail or on a marketplace.
- They scan a QR code on packaging, a display, or an insert, or follow a link, in exchange for a rebate, warranty registration, sweepstakes entry, or content.
- Brij captures identity and validates the purchase, via receipt upload or retailer transaction data.
- Identifiers are normalized and hashed with SHA-256 server-side.
- The event is typed to the standard event your campaign optimizes on, tagged with the correct action source, valued, and deduplicated.
- It is transmitted through Meta's Conversions API, Google's Data Manager API, and TikTok's Events API, and into your CRM and email or SMS platform in parallel.
Two key results come from this:
Immediately, platforms begin crediting purchases they previously could not see. Reported attribution and ROAS rise because measurement coverage expanded.
Over time, the training set changes shape. The model stops learning from a DTC-only sample and starts learning from your actual buyer base. That is the compounding effect, and it is slower and more valuable than the first.
The distinction that matters against receipt and rebate networks like Fetch or Ibotta: those platforms anonymize the shopper into their own graph. Brij reclaims the identity into yours.
Your customer, your signal, your Conversions API connection, your CRM.
Run This Diagnostic
- Open Events Manager. Read EMQ on your Purchase event specifically. Below 8.0 means you have a match quality problem before you have a coverage problem.
- Divide the purchase events your ad platforms received last month by your actual total units sold across all channels. That ratio is the share of your business the model can see.
- Check whether value and currency are populated on every event. If not, you are optimizing for count.
- Check action_source on any offline events. Miscoded events get evaluated against web expectations they cannot meet.
- Confirm your Google offline import path has migrated to the Data Manager API.
- Compare DTC average order value to retail basket value. A large gap means your value-based bidding is calibrated to the wrong economics.
If step two returns a number under 30%, the ceiling on your ad performance is a data coverage ceiling, and creative iteration will not move it.
Ready to see what your model is missing? Book a 15-minute call with our team.
FAQ
What is a good Event Match Quality score?
Meta labels 8.0 and above as Great and 6.0 to 7.9 as Good. Because EMQ is calculated per event type, the number that matters most is the score on the event your campaign optimizes on, usually Purchase. For Purchase, 8.5 and above is the practical working target, and returns compress above 9.0.
Does the Conversions API replace the Meta Pixel?
No. They are complementary. The pixel captures browser context that the server cannot, and the server captures events the browser misses. Send both and deduplicate with event_id. For retail purchases there is no browser session at all, so the Conversions API is the only path.
Can I send retail purchases to Meta without a customer email or phone?
Not usefully. Offline events have no click ID, browser ID, IP, or user agent, so hashed email and phone carry nearly all the matching weight. Without at least one of them, the event will not match and will not train anything.
Why did my ROAS jump the week we turned on offline conversions?
Because the platform began crediting purchases it previously could not observe. That first lift is a measurement coverage effect. The performance effect, where the model retrains on a fuller picture of your buyer, follows over subsequent weeks.
How does this differ from MTA, MMM, or incrementality testing?
Those are measurement frameworks that model the contribution of your marketing. Deterministic offline signal is the underlying event data all of them are trying to reason about. Better signal makes each of those frameworks more accurate. It does not replace them.
