Meta Conversions API: 7 Fields That Change Match Rate the Most

Meta's Conversions API documents thirteen customer-information fields that can be sent with every event: em (email), ph (phone), fn (first name), ln (last name), ct (city), st (state), zp (zip), country, external_id, fbc (click ID), fbp (browser ID), client_ip_address, and client_user_agent. Not all of these are created equal. Meta's own Customer Information Parameters documentation describes how match keys are hashed and used — but the document is non-committal on which keys move match rate the most.

This post walks through the seven keys that, in our experience, disproportionately move match rate for a typical DTC merchant. It is methodology-first, citing Meta's own docs throughout. We do not publish a "match rate is X% with field Y" benchmark; we walk through the mechanism so you can measure your own match rate by isolated field on your own data.

The technical reality — how Meta matches a CAPI event to a user

Meta's CAPI matching is a probabilistic graph join. When your server POSTs a Purchase event to /v25.0/{pixel_id}/events with a user_data block containing hashed identifiers, Meta's match system attempts to attribute that event to a Meta user by looking up each provided identifier in Meta's user graph.

Each identifier has a different "weight" in the join — Meta's documentation does not publish the weights, but the structure of the system tells you most of what you need to know:

• High-precision deterministic keys (email, phone, external_id) are direct user lookups. If the user gave Meta the same email or phone on their Facebook or Instagram account, the match is exact.
• Cookie / device keys (fbp, fbc) are session-level identifiers Meta itself issued. If the cookie is still present and unexpired, the match is near-perfect for the device, but tells Meta nothing about the cross-device user identity.
• Name + geography keys (fn, ln, ct, st, zp, country) are probabilistic — they are useful for the partial join when the high-precision keys are absent or stale.
• Network keys (client_ip_address, client_user_agent) are weakest — Meta uses them, but a shared household IP or a generic UA string is a low-confidence join.

The number of keys you send increases match rate roughly multiplicatively up to a point: each additional key adds a chance of a fallback match when the others are absent or stale. Meta's Event Match Quality score (visible in Events Manager under each event source) summarizes this into a 1–10 scale.

The seven fields that disproportionately move match rate

In our work with DTC merchants on Meta CAPI, these seven fields have been the highest-leverage adds. The order reflects the conditional probability of a match lift, not an arbitrary ranking.

1. em (email)

Hashed (SHA-256) lowercase trimmed email. This is the single highest-leverage match key for any post-checkout event. The vast majority of Meta users have a verified email on their Facebook or Instagram account, so the match probability is near-deterministic. If your CAPI event is for a logged-in customer or a checkout-completed event, em should always be present.

2. ph (phone)

E.164-normalized hashed phone. Less universally available than email, but for events where you have a phone (Shopify checkout, account creation, SMS-opt-in surfaces), ph is a near-equal partner to em. Meta's documentation explicitly recommends sending both when both are available.

3. external_id

Hashed customer ID — your platform's stable identifier for the customer (Shopify customer ID, your internal user ID, etc.). This is a critical key for two reasons: (1) it lets Meta join events for the same customer across devices and sessions, and (2) it is the join key for offline conversions if you ever upload offline event data.

4. fbc (click ID)

The _fbc cookie value, which encodes the original click that brought the user to your site — formatted fb.1.{timestamp}.{fbclid}. This is the most fragile of the seven (iOS 17 Link Tracking Protection can strip fbclid from shared links, see our iOS 17 attribution post), but when present, it is the strongest possible attribution signal because it ties the conversion directly to a specific ad click.

5. fbp (browser ID)

The _fbp cookie, Meta's first-party browser identifier. It survives iOS ITP in most cases (first-party context) and provides a stable browser-level identity. For high-volume events where em or ph may be absent (e.g. ViewContent on a PDP for an anonymous visitor), fbp is the workhorse match key.

6. zp (zip / postal code)

Hashed normalized postal code. Combined with country, it is a strong probabilistic key — at the granularity of a US 5-digit zip, it slices the population to a few thousand users, which is enough to disambiguate name-only collisions. For checkout-completed events where you have the shipping zip, always include it.

7. client_ip_address + client_user_agent (server-fetched, not browser-fetched)

The seventh slot is the client_ip_address + client_user_agent pair, captured from the actual user's browser request, not from your server's outbound IP. Meta uses these to deduplicate browser-side and server-side events for the same session and to provide a fallback when no other keys match. If your CAPI sender is a server-side process that fetched the data from your DB, you must explicitly pass the original req.headers['user-agent'] and the original client IP — otherwise Meta sees your server's IP and a generic Node.js or PHP UA, which is essentially useless.

Why it matters for DTC attribution

Meta's aggregated event measurement framework ranks events by priority and reports up to 8 events per domain. Match quality affects which events are credited at the deduplication step and how Meta builds your custom audience for retargeting. The compounding effect is:

1. Higher match rate → more conversions attributed → better optimization for the bidder.
2. Higher match rate → better lookalike audience seeds → cheaper acquisition.
3. Higher match rate → fewer "dropped" events at AEM's privacy threshold → less reporting volatility.

The marginal gain of moving from 5/10 to 7/10 Event Match Quality is meaningful at scale. The marginal gain of moving from 7/10 to 9/10 is smaller in absolute conversion volume but matters more for the lookalike-audience and bidder-feedback channels.

Methodology — measuring per-field match-rate lift on your own data

You can run a per-field ablation study using Meta's "Event Match Quality" diagnostic.

Step 1 — Baseline event match quality

In Meta Events Manager → your Pixel → Conversions API → Event Match Quality, note the current 1–10 score for your top events (Purchase, AddToCart, InitiateCheckout).

Step 2 — Audit your current field coverage

Use Events Manager's "Test Events" tab and send a sample event. The response payload includes which match keys Meta received and which were normalized successfully. Common omissions we see: external_id not sent at all, fbc not captured because the merchant doesn't persist fbclid from the landing URL, client_ip_address accidentally set to the merchant's server IP instead of the user's IP.

Step 3 — Add one field at a time

Roll out one missing field per week. Compare the Event Match Quality score and the AEM "Total Events" volume before and after. Meta's match-rate reporting has a 24–48 hour latency, so do not expect to see the lift within an hour of deploying.

Step 4 — Validate against your CRM truth

For em and ph specifically, validate that you are hashing correctly: lowercase + trim for email, E.164 normalize (with country code, no separators) for phone, SHA-256 hex output. Meta will silently drop badly hashed keys and you will see no lift — Events Manager will report the field as "not received" even though you sent something.

Illustrative scenario

A DTC supplement brand starts with a Meta Pixel + CAPI integration that sends only the four fields its Shopify-native integration set up out of the box: em, fbp, fbc, and client_user_agent. Event Match Quality reports 6/10. The brand sequentially adds:

• Week 1: external_id (Shopify customer ID) → small lift.
• Week 2: ph (Shopify checkout phone field, E.164-normalized) → larger lift.
• Week 3: zp and country (from shipping address) → meaningful additional lift.
• Week 4: corrected client_ip_address (was leaking the merchant's server IP; switched to req.headers['x-forwarded-for'].split(',')[0]) → small but real lift.

By the end of week 4, Event Match Quality moves into the 8–9/10 range. The brand's Meta Events Manager "Total Events" count for Purchase converges to within ~5% of its Shopify Orders count for the same period. Total Meta-attributed revenue is no longer the wildly under-reported number it was at month start.

These numbers are illustrative. The structure — sequential per-field rollout with measurement gates — is what generalizes.

What we do at Admaxxer

Admaxxer ships server-side tracking with the seven match keys pre-wired:

• em and ph from Shopify checkout, hashed at ingestion.
• external_id from Shopify customer ID, persisted across sessions.
• fbc from the _fbc cookie, with fbclid fallback if the cookie has expired.
• fbp from the _fbp cookie, never the server-issued one.
• zp and country from the Shopify shipping address.
• client_ip_address correctly de-proxied through x-forwarded-for, and client_user_agent from the original request.

We also publish a CAPI match-rate feature page that breaks down which keys are present per event and the Event Match Quality history over time. If you are evaluating the broader server-side tracking landscape, see our cost-math breakdown vs Stape, Datafast, and Triple Whale.

FAQ

Do I need to hash email and phone before sending to Meta CAPI?

Yes. Meta's hashing guidance requires SHA-256 hex for em and ph (and most other PII keys). Email must be lowercased and trimmed before hashing; phone must be E.164-normalized (country code + national number, digits only). If Meta receives an unhashed value, it will reject the field — and your match quality will look identical to "field not sent."

Why is my client_ip_address showing my server's IP instead of the user's?

This is the single most common CAPI implementation bug. When your server-side process fetches the event payload and POSTs to Meta, the IP Meta sees on the request comes from your server, not the user — unless you explicitly extract the original client IP from the inbound HTTP request and pass it in the user_data.client_ip_address field. The correct source is req.headers['x-forwarded-for'] (taking the leftmost IP if behind a CDN) or req.connection.remoteAddress. Many merchants get this wrong on the first deploy.

Does sending more match keys hurt anything?

No — Meta's CAPI does not penalize over-coverage, and there is no rate-limit or quota cost per key. The only reason not to send a key is if you don't have it for that event. For an anonymous PDP view, you will only have fbp, fbc, client_ip_address, and client_user_agent. For a checkout-completed event, you should have all thirteen.

What is the difference between fbc and fbclid?

fbclid is the URL parameter Meta appends to ad-click landing URLs (e.g. ?fbclid=AB12...). fbc is the _fbc cookie that the Meta Pixel sets on the user's browser after reading fbclid from the landing URL — formatted as fb.1.${timestamp_ms}.${fbclid}. CAPI takes fbc (the formatted cookie value), not the raw fbclid. If your server-side pipeline has the raw fbclid but no cookie, you can construct fbc yourself using the documented format.

How long is fbc valid?

The _fbc cookie has a default lifetime of 90 days from issuance. After that, Meta's match system treats it as stale and the click-attribution leg degrades. This is part of why server-side identifiers (em, ph, external_id) matter more than click identifiers for events that fire long after the original click (e.g. delayed Purchase events on a high-AOV / long-consideration product).

Is external_id required to use offline conversions?

Yes. Meta's offline conversions flow joins uploaded offline events to online events by external_id (and email / phone as fallback). If you plan to upload offline conversion data at any point in the future, you should start sending external_id on every online event today, so the join history is intact when you need it.

What is the minimum viable CAPI implementation?

Three keys: em, fbp, and event_id (the deduplication key, separate from match keys). With those three, you have enough to deduplicate against the browser-side Pixel and enough to match a meaningful share of users. The remaining four-to-ten keys are how you push Event Match Quality from "viable" (5–6/10) to "production-grade" (8–9/10).