Meta Conversions API: an implementation guide for eCommerce

What is the Meta Conversions API?

The Meta Conversions API is a direct connection between an online shop's server and Meta. It sends events such as product views, add-to-carts and purchases without going through the user's browser. The browser is where ad blockers and privacy restrictions step in and cause the pixel to lose signal.

The pixel is still needed, because it collects browser signals the server cannot see. That is why the set-up Meta recommends is redundant: the same events are sent through both channels and the platform keeps only one. For a shop with steady investment in Meta Ads campaigns, that redundancy is the foundation of reliable measurement.

Why does it improve campaign performance?

It improves performance because Meta's algorithms bid and choose audiences based on the conversions they receive. If some purchases never arrive, the system learns from an incomplete sample. It undervalues creatives and audiences that do sell, allocates the budget less effectively, and cost per purchase rises even though nothing has changed in the shop.

Nor is the signal loss evenly spread. It weighs more heavily on Safari and iOS, on people who use ad blockers and on purchases made several days after the click.

• It recovers conversions the pixel misses and improves campaign attribution.
• It gives the algorithm more data to learn from, which tends to stabilise cost per purchase.
• It lets you send events that happen outside the website, such as confirmed orders, returns or subscription renewals.
• It lets the server decide which data is sent to Meta and which is not.

The same principle governs Google's automated campaigns: Performance Max depends on the quality of the conversions it receives, and so does Meta Advantage+.

When it pays off and when it can wait

It pays off for any shop that invests in Meta on an ongoing basis and uses purchases as its campaign objective. With small budgets and only a handful of sales a month, the priority is usually elsewhere. The first step is to make sure the pixel measures correctly and the consent banner works.

Which implementation method should you choose?

The method depends on the shop's platform, the technical resources available and how many advertising platforms need to be fed. A standard Shopify shop can usually rely on the native integration. If it also advertises on Google Ads, TikTok or Pinterest, a shared server-side container tends to be the most cost-effective option in the medium term.

Criteria for deciding

Three questions frame the decision. The first is whether there are events only the backend knows about, such as an order paid by bank transfer or a cancelled subscription. If so, direct integration or server-side tagging are the only complete options.

The second question is who will maintain the solution a year from now, when the shop's theme changes or a new payment method is added. The third is how many advertising destinations need to be fed. A well-designed server container sends the same data to Meta, Google and TikTok through a single consent layer. It is the approach we take in analytics and measurement for online shops.

How do you avoid duplicating events with the pixel?

You avoid it by sending the same event name and the same event ID from both the pixel and the server. With those two values, Meta recognises that both submissions describe a single purchase and discards one. If the IDs do not match, the purchase is counted twice and the reports show performance that is not real.

The event name is sent as event_name, for example Purchase. The ID is sent as event_id from the server and as eventID from the pixel. For purchases, the order number is the natural candidate, because it exists on both sides and is never repeated. Meta removes the duplicate when both events arrive less than 48 hours apart.

// Browser (pixel)
fbq('track', 'Purchase', { value: 89.90, currency: 'EUR' }, { eventID: 'order-10482' });

// Server (Conversions API)
{ "event_name": "Purchase", "event_id": "order-10482", "action_source": "website" }

For events before the purchase, such as AddToCart, there is no order number yet. The usual solution is to generate a unique ID in the browser, store it in the data layer and pass it to the server along with the other parameters.

Event match quality

To attribute an event, Meta needs to link it to a person. It does so using the customer parameters that accompany the event: email, phone number, name, city, IP address, user agent and the IDs from the _fbp and _fbc cookies. Events Manager scores each event from 0 to 10 based on the quantity and quality of that data.

In the audits we carry out, a low score on the purchase event almost always has a specific cause. Either the email is captured at checkout but never reaches the server, or the server sends its own IP instead of the customer's. Both issues are quick to fix.

Consent and GDPR with the Conversions API

Sending events from the server does not remove the need to ask for consent. In the European Union, data from a user who has declined advertising cookies must not reach Meta through either channel. The implementation has to read the status from the consent management platform and make every submission conditional on that decision.

The typical failure occurs when the pixel respects the banner and the server does not. The shop appears compliant, because nothing loads in the browser, yet the backend keeps sending purchases with hashed emails and phone numbers. A SHA-256 hash does not anonymise that data for GDPR purposes, because it remains pseudonymised personal data.

For users who decline cookies, the prudent option is not to send the event. On the technical side, the server needs to know the consent status at the exact moment of sending. To achieve that, it has to be passed from the browser or stored with the order.

Step-by-step implementation

The workflow we follow in shops that already have the pixel installed has seven steps. Each one leaves a result that can be checked before moving on to the next.

1. Inventory the pixel's current events, their parameters and any integrations already sending data to Meta from a server.
2. Choose the sending method based on the platform, the advertising destinations and who will maintain the solution.
3. Define the ID rule for each event, using the order number for purchases.
4. Map the customer parameters available at each stage of the funnel and how they are normalised before hashing.
5. Connect the consent status to the server-side submissions.
6. Validate with the Test Events tool in Events Manager, then publish.
7. Monitor deduplication, match quality and the gap between actual orders and events received for two weeks.

The last check is the most revealing. If the purchases received in Events Manager come close to the shop's orders without exceeding them, deduplication is working. If they exceed them, there are duplicates; if they fall well short, submissions are missing or consent is blocking more than expected.

• Standard events defined: PageView, ViewContent, AddToCart, InitiateCheckout and Purchase.
• Shared event ID in the pixel and on the server.
• Value and currency on every purchase event.
• Customer parameters normalised and hashed, together with the cookie IDs.
• Sending conditional on user consent.

Common mistakes when implementing the Conversions API

The same failures recur from one shop to the next and are rarely obvious in the dashboard. These four appear in a good share of the accounts we review.

Two integrations sending the same purchase

The native Shopify or WooCommerce integration is still active when someone later adds a server container. Each channel generates its own ID, so Meta cannot deduplicate and purchases are inflated. Before making any change, check which partners appear as connected in Events Manager.

IDs that do not match

The pixel generates a random ID and the server uses the order number. Both submissions arrive, neither is discarded and the report shows twice as many purchases. With a random ID, every reload of the thank-you page also counts as a new purchase.

Inconsistent value and currency

One channel sends the amount including VAT and the other excluding it, or the currency is missing. The conversion value is no longer comparable and value-based bidding learns from incorrect figures. It is worth setting a single rule, such as the amount excluding tax and shipping, and documenting it.

The server's IP instead of the customer's

In some implementations, the IP field captures the address of the machine calling the API. Every purchase appears to come from the same place. Match quality drops and attribution worsens without any visible error in the dashboard.

Where to start

If the shop already has the pixel, start with a short review of Events Manager. Note which integrations are sending data, which events are being deduplicated and what match score the purchase event has. The method is chosen on the basis of that diagnosis, not the other way round.

Anyone who also advertises on Google Ads can reuse the work for offline conversions in Google Ads. They are based on the same principle of sending first-party data from the server, always subject to consent. If the diagnosis reveals duplicates or purchases without customer data, it is advisable to request a review of the implementation before increasing spend.

Frequently asked questions