Shopify Meta Conversions API: Server-Side Tracking Explained

The Meta Pixel was designed for a web where every browser ran every script. That web is gone. Safari's tracking prevention shortens first-party cookies and content blockers strip pixel requests. The result is that a Shopify store relying on the browser pixel alone under-reports purchases and, more importantly, under-feeds Meta's delivery system. Server-side tracking through the Conversions API (CAPI) is the fix, and it still follows your store's cookie-consent settings. This guide explains what it is, how the PixlBridge Shopify app implements it, and how to verify it.

What "server-side tracking" actually means

With the browser pixel, the shopper's browser tells Meta "a purchase happened". With CAPI, your server tells Meta, over an HTTPS call to graph.facebook.com/{pixel_id}/events, carrying the same event name plus customer information parameters that help Meta match the event to an account. The browser is no longer in the critical path, so blockers and cookie limits do not decide whether the event exists.

Meta's recommended architecture is redundant: keep the browser pixel and send server events, and give both the same event_id so Meta can deduplicate them. You get the best coverage of each without double counting.

How PixlBridge collects Shopify events

PixlBridge uses two sources that Shopify provides to apps, and merges them:

1. A web pixel extension in the storefront

When you connect a store, PixlBridge installs an app-owned web pixel. Web pixels run in Shopify's sandbox and subscribe to standard customer events: page_viewed, product_viewed, collection_viewed, search_submitted, product_added_to_cart, checkout_started, payment_info_submitted and checkout_completed. For each one the pixel sends a tiny beacon to PixlBridge with Shopify's event id, the _fbp and _fbc cookies when present, the page URL and the user agent. It does not need theme edits and keeps working with checkout extensibility.

2. Order and checkout webhooks from Shopify Admin

The app also subscribes to orders/create, orders/paid, orders/updated, checkouts/create and checkouts/update. Webhooks are signed with an HMAC that PixlBridge verifies on every delivery, and each delivery id is processed at most once. Webhooks are where the authoritative commerce data comes from: order value, currency, line items, and the customer's email, phone, name and address.

Merging the two into one event

A purchase seen by the pixel and the same purchase delivered by the webhook are stored as one row, keyed by the store and a deterministic event id built from the checkout token (purchase:{checkout_token}). The webhook wins for money fields; the pixel fills in browser identifiers. PixlBridge holds checkout and purchase events for about 30 seconds before sending (visits and other events go out right away), so that whichever source arrives second can enrich the event. One purchase in, one Purchase out.

Hashed match keys

Every event carries as many of Meta's customer information parameters as the source data allows. Personal fields are normalised the way Meta's specification requires and then SHA-256 hashed before they are stored:

• em: email, lowercased and trimmed
• ph: phone, digits only with country code (inferred from the address country when the number is national)
• fn, ln, ct: name and city, lowercase letters only
• st, zp, country: state code, postal code (US: first five digits), ISO-2 country
• external_id: a hash of the Shopify customer id
• fbc and fbp: the Meta click and browser identifiers, sent as-is, recovered from cookies, from the checkout's note attributes, or from the fbclid on the order's landing page
• client_ip_address and client_user_agent: from the checkout's browser details

PixlBridge never stores raw email addresses, phone numbers or names from your orders; the hashes are the only thing written to the database. Whether Shopify includes customer fields in order webhooks depends on its protected customer data approval for the PixlBridge app, which we handle; there is nothing for you to set up. Without those fields, purchases still arrive and still merge, but only em from the pixel and the fbc/fbp identifiers remain as match keys. The Event Match Quality guide explains how much each parameter is worth.

Which events are sent

The full funnel maps onto Meta's standard events:

Each event type can be switched off per store. All events are sent with action_source: "website", the page URL as event_source_url, and an event_time no older than seven days, which is Meta's limit.

Deduplication in practice

Meta deduplicates a browser event and a server event when they share the same event_name and event_id within a 48-hour window. Because PixlBridge's ids are derived from Shopify's own identifiers, a theme that also fires the browser pixel with Shopify's event ids will not double count. Stores with no browser pixel at all receive CAPI-only events, which is perfectly fine for optimisation.

There is one overlap you must decide about: Meta's own Facebook & Instagram sales channel. With its "Maximum" data-sharing level it already sends Purchases with its own ids. Running both means duplicated purchases. Either lower the channel's data sharing or disable Purchase in the store's PixlBridge settings. The per-store health page flags the situation.

Delivery, retries and health

PixlBridge checks every few seconds for events that are ready to send (with a once-a-minute run as a backup) and posts them to Meta in batches of up to 1,000, so visits reach Meta in seconds and sales within about a minute. Transient failures (rate limits, 5xx, network) back off exponentially: one, two, four, eight and sixteen minutes, then the event is marked failed with Meta's message attached. A permanent error in a batch is isolated to the offending event; the rest still go through. Every run is logged, and the store's health view shows event counts by type and status for the last 24 hours and 7 days, the percentage of purchases carrying each match key, and warnings such as pixel not firing or webhooks missing.

Verifying the setup in Events Manager

1. In Events Manager create a test event code under Test events.
2. In PixlBridge open the store and use Send test purchase with that code. The event shows up in the Test events tab, with the parameters Meta received.
3. Place a real test order. Shortly afterwards the Overview tab shows a Purchase from the Server connection method. If your theme also fires the pixel, the Deduplicated column confirms the two were merged.
4. Check Event Match Quality for Purchase once some orders have come in. Purchases from checkout normally carry email, phone, name and address, which puts EMQ in the upper range; PageView and ViewContent carry only browser identifiers and will score lower by design.
5. Remove the test event code from the store settings. While it is set, every event is tagged as a test.

Privacy and compliance

Because the app touches customer data on your behalf, it implements Shopify's mandatory compliance webhooks: customers/data_request, customers/redact and shop/redact. A customer erasure request removes their hashed identifiers; uninstalling the app clears the store's token immediately and its data after the retention period. The web pixel follows your store's cookie-consent settings: where your store asks visitors for consent, it only runs for those who allow analytics and marketing. You remain the data controller; PixlBridge processes on your instructions under the data processing addendum. Your privacy policy should disclose that hashed purchase data is shared with Meta for ad measurement; see the PixlBridge privacy policy for the wording we use.

Summary

Server-side tracking is not exotic anymore; it is the baseline Meta expects. The work is in the details: two sources merged into one event, deterministic ids for deduplication, properly normalised hashes, retries, and diagnostics you can actually read. The PixlBridge Shopify integration packages all of it behind a one-click install, with plans starting on the Starter tier.