CAPI Event Quality Checklist to Raise Match Strength on Shopify

A CAPI event quality checklist is the fastest way to find why a Meta Conversions API integration reports low Event Match Quality, because the gap between a CAPI setup that matches ninety percent of Pulses and one that matches sixty percent is almost never the connection; it is the customer information parameters inside each purchase Pulse. Meta scores every server event against the identity fields it carries, and a Pulse with accurate email, phone, browser ID, and click ID will match far more often than one with a single unformatted field. This guide lays out the event quality checklist you run before launch and whenever Match Strength drifts, so the Fields Meta uses to connect each purchase Pulse to a Facebook user stay complete.

If you are new to the recovery side of this, the complete Shopify signal recovery guide covers the full strategy this checklist feeds into, and what Meta CAPI is explains how the Conversions API receives server events in depth. The checklist below is the field-level piece of that recovery plan: connection health gets Pulses delivered, event quality gets them matched.

The Event Quality Checklist in One Take

The checklist has six checks: confirm every purchase Pulse is sent from the server; verify each Pulse carries email and phone, plus name, gender, date of birth, and address where collected; forward the browser ID and click ID from the pixel to the server event; pass a stable external event ID for deduplication; hash identity fields to the format Meta expects; and confirm the current consent state reaches the Channel. When all six pass, Match Strength on the Overview typically sits above eighty percent. When even one identity field is missing or malformed, the match rate drops and the store’s optimization data decays without any visible error.

What Event Quality Means for CAPI

Event quality is the degree to which each CAPI event carries enough correct identity data for Meta to associate the purchase with a Facebook user. Meta calls the score Event Match Quality, and it is expressed as a percentage: the share of events Meta successfully matched to a user profile. It appears in the Overview as Match Strength, which is the merchant-readable version of the same number.

Meta hashes the identity fields you send, combines them with the click and browser identifiers, and runs a probabilistic match against known users. The match either succeeds and the conversion enters the optimization algorithm, or it fails and the purchase is written off as unmatched. There is no partial credit. A Pulse with four strong fields matches; a Pulse with one weak field does not. Because the algorithm optimizes only against matched conversions, a store with low event quality pays for clicks it cannot see the return on, and its cost per purchase rises.

Julian Juenemann of MeasureSchool has documented that client-side pixel loss for the average Shopify store runs forty to sixty percent concentrated in iOS and Safari traffic. Server-side CAPI recovers that delivery loss, but only to the extent that the server events carry enough identity data to match. A store that moves server-side but sends a bare email field can still sit at sixty percent Match Strength, which is why the checklist starts at the field level rather than the connection level.

Why Match Strength Fails Even When CAPI Is Connected

Merchants usually discover event quality problems the same way: CAPI is running, Clarity Score reads healthy because Pulses are delivered, yet Match Strength sits below seventy percent and either stays flat or drifts down. The causes are consistent and fixable, and every one is visible in the Stream of Pulses.

Check 1: Every Purchase Pulse Is Sent From the Server

The audit begins with the delivery layer. If a store still relies on the browser pixel for a share of purchases, those events are subject to iOS App Tracking Transparency, Safari Intelligent Tracking Prevention, and ad blocker filtering, and no field editing will fix a Pulse that never arrives. Confirm every purchase Pulse originates at the order confirmation point on the server and that none depend on the buyer’s browser. The server-side tracking guide for Shopify walks through this setup when it is not yet in place.

Check 2: Customer Information Parameters Are Complete

The customer information parameters are the identity fields Meta matches on, and completeness is the biggest single driver of Match Strength in the audit. The full parameter set includes email, phone, first name, last name, gender, date of birth, city, state, zip code, and country, plus the two browser identifiers covered in Check 3.

Email and phone are the load-bearing fields. Phone is the most stable matching parameter because users change email addresses more often than phone numbers, and a phone number is more likely than any other field to be tied to a Facebook account. Many Shopify stores already collect phone for shipping and never transmit it, leaving the strongest signal unused. Name, date of birth, and gender add context that helps Meta disambiguate between profiles that share an email domain or a common phone prefix. Address fields matter more for branded searches and less for lower-funnel traffic, but they cost nothing to include when they are collected.

The practical rule is to transmit every field the checkout collects. If the checkout asks for phone, ship it. If it captures date of birth, include it. A Pulse that carries email and phone plus name and zip matches at a materially higher rate than a Pulse carrying email alone, and the difference compounds across every purchase the store sends.

Check 3: Browser ID and Click ID Forward to the Server Event

The browser ID and the click ID together are the strongest session signals Meta has. The browser ID is a unique identifier Meta sets in the browser, and the click ID is attached to the ad click that brought the visitor in. When the browser pixel captures both and the server Pulse forwards them, Meta can tie the purchase to a specific session and user even when no contact field matches a profile.

This is the check that fails most often on Shopify because the forwarding requires a small config step between the pixel and the CAPI integration. Without the browser ID and click ID, a share of Pulses that carry perfect email and phone still fail to match because Meta cannot connect them to the session that produced them. The fix is forwarding both identifiers from the browser event to the server event so the identity bridge is closed.

Check 4: A Stable External Event ID for Deduplication

When the same purchase flows through both the pixel and the server, the external event ID lets Meta count it once. A stable ID, usually the Shopify order ID, is generated for each order and passed in both transmissions. Without it, Meta may double count a conversion. The event ID check is quick but matters more than it looks, because underreporting and overreporting both distort the Clarity Score and make the delivery health read unreliable.

Check 5: Identity Fields Are Hashed to Meta’s Format

Meta expects identity parameters to be normalized and hashed with SHA-256. Emails are lowercased and whitespace-trimmed, phone numbers are reduced to digits with the country code, and names and city are lowercased before hashing. A field sent in the wrong format, a phone number with dashes and spaces intact, or an email with a trailing space can make the whole parameter unusable, which lowers event match quality even when the data is present and correct.

A signal layer handles this normalization automatically because it is part of building the event payload for each Channel. For a hand-rolled integration it is the easiest place to introduce an invisible quality defect, which is why the checklist includes it explicitly.

Check 6: Current Consent State Reaches the Channel

Google Consent Mode v2 expects the consent signal to travel with the conversion event, and Meta’s own ecosystem respects that the decision belongs to the site. When consent state is absent or stale, the platform may hold or drop conversions, which reads as signal loss even though the Pulse was delivered. Confirm each Pulse reflects the current consent decision, not a cached default from an earlier session. This check keeps the audit honest about what the platform is allowed to count, not just what the store sent.

How to Apply the Checklist to a Live Integration

Run the checklist at setup and then on a cadence, because event quality is not a one-time configuration. The tracking rules shift with each platform change, and identity data collection drifts when a theme update or checkout change alters what the store captures.

Start in the Overview and read Match Strength per Channel. If it is below seventy percent, open the Stream and inspect a sample of recent purchase Pulses. Check the identity fields on the last fifty events and note how many carry email, phone, and both browser identifiers. A pattern where email is present on nearly every Pulse and phone or identifiers are missing on most is a collection gap, not a delivery one, and points to the form or the forwarding config rather than the connection.

After any fix, re-measure against the prior week rather than against the launch baseline. Identity improvements show up in Match Strength within a few cycles of purchases, and comparing consecutive weeks isolates the change from traffic noise. When Match Strength rises and the store’s platform conversions move toward Shopify order volume, the checklist has done its job.

Merchants running a manual integration repeat this audit by hand once a month. Merchants on a signal layer can read Clarity Score and Match Strength on the Overview and use the Hawk assistant to inspect the Stream for the specific identity gaps the checklist would find, turning the monthly manual audit into an automated watch. Either way, the same six checks apply: the field names Meta scores against do not change based on who sends them.

A Weekly Five-Minute Event Quality Check

The one field that predictably decays is phone collection, because a checkout redesign or a new sales channel can quietly stop capturing it. The weekly check is short: confirm the Overview shows all Channels healthy on Clarity Score, confirm Match Strength on the purchase Channel has not dropped more than a few points, and spot-check a handful of Stream entries to confirm email, phone, and the browser identifiers appear on recent Pulses. If a theme update shipped that week, re-run the full six checks because checkout changes are the most common cause of silent identity loss.

FAQ

What is event match quality in Meta CAPI? Event Match Quality is Meta’s percentage score for how well it can match each CAPI conversion event to a Facebook user, based on the customer information parameters the event carries. It appears to merchants as Match Strength on a signal layer’s Overview.

Which customer information parameters matter most for CAPI? Email and phone are the highest-signal fields, with phone being the most stable because users change email addresses more often than phone numbers. The browser ID and click ID matter equally because they connect the purchase to the original ad session even when contact fields do not match a profile.

Why is my CAPI Match Strength stuck below seventy percent? The most common causes are incomplete identity fields, missing browser ID or click ID forwarding, unformatted hashing, or a checkout change that stopped collecting phone. Compare the identity fields across recent Pulses in the Stream to isolate the gap, then fix the field collection or forwarding rather than the connection.

Do I need to hash CAPI customer information parameters myself? Meta expects identity fields normalized and hashed with SHA-256. A signal layer handles hashing automatically, including lowercasing emails, trimming phone digits, and hashing names before they reach the Channel.

Related Resources

• The complete Shopify signal recovery guide ties event quality into the full recovery strategy.
• The Shopify signal loss audit covers the twelve tracking leaks that degrade Match Strength at every layer.
• What Meta CAPI is explains how the Conversions API receives and matches server events.