Pixel and Conversions API for peptide stores: ROAS you can actually trust

Every return figure in your panel is a fraction. The bottom half is spend, and Meta knows it to the cent because Meta charged it. The top half is purchase value, and Meta only knows it if your store reports it — completely, once, and with enough detail to link the sale to an ad. Miss pieces and ROAS reads low, so you pause ads that were working. Count twice and it reads high, so you scale ads that were not.

What the Pixel is, and where it goes blind

The Meta Pixel is a small script in your customer's browser. When someone views a product, adds it to the cart or reaches the thank-you page, it sends an event to Meta with identifiers that help Meta recognise the person who clicked the ad. That was the whole measurement story for years, and it worked because browsers let it.

They no longer do, at least not reliably. On iOS, people who decline tracking cannot be matched the way they once were. Safari limits how long the Pixel's cookies live, so a customer who clicks on Monday and buys on Friday can look like a stranger. Ad blockers stop the script outright, and a script that never loads sends nothing. The sale still happens; Meta just never hears about it, so the return reads lower than it is — and because delivery learns from the purchases Meta can see, weaker measurement becomes weaker optimisation.

What the Conversions API adds

The Conversions API — CAPI — is the same events sent from a different place: your store's own server reports them to Meta directly. There is no script to block, no cookie to expire and no tracking prompt to decline, because nothing happens on the customer's device. If the order exists in your store, the server can report it.

Each server event carries the event name, the time, the order value and currency, an order identifier, and customer identifiers such as email and phone. Those identifiers are hashed — turned into a fingerprint that cannot be reversed — before they leave your server, so Meta can match the buyer to an ad viewer without receiving the raw address. Shopify, WooCommerce and most modern platforms send these events natively; a custom store needs a little backend work. None of it is a way around consent: a customer who declined tracking on your site is not sent from the server either.

Why you need both, not one instead of the other

The two carry different information. The browser knows which ad was clicked, through a click identifier Meta attaches to the landing URL; the server knows that the order really completed, what it was worth, and who bought it. Sent together, Meta merges them. It also grades every event stream on how many matching identifiers arrive with it, and that grade decides how many of your purchases Meta can attribute at all.

The double-counting trap

Now the opposite failure. If the browser and the server both report the same purchase and Meta cannot tell they are the same, it records two. Attributed value doubles, ROAS doubles, and every decision downstream rests on a number twice the size of the truth — the costliest measurement mistake a peptide store can make, because it looks like success.

The fix is deduplication, and the mechanism is a shared label. Both events carry an event_id, and for the same purchase that value must be identical on both sides; Meta keeps one and discards the other. The order number is the natural choice: the browser has it on the thank-you page, the server has it in the database, and nobody invents anything. It goes wrong in the details:

• Each side generates its own random event_id instead of sharing the order number, so nothing ever matches.
• The event names differ — Purchase in the browser, Order on the server — and Meta treats them as unrelated.
• The server sends its copy hours after the browser, outside the window Meta uses to pair them.
• The thank-you page fires Purchase again on every refresh, and the server has nothing to pair the extras with.
• Value or currency differ between the two — deduplication still works, but the surviving event may carry the wrong amount.

How the two sources are proven to agree

This is why we install the Pixel and the Conversions API with you, and why no money moves onto an account before the test is done. The test is plain: place real test orders, then look at what Meta received. Each order should produce exactly one Purchase, received from both browser and server with one copy deduplicated away, carrying the value and currency your store's admin shows and the order number as its event_id.

A hypothetical, to make the shape concrete: place ten test orders with an ad blocker active on some. The server should report all ten, the browser fewer, and Meta should show ten purchases with the overlap deduplicated — not ten plus whatever the browser managed. Only that picture means later numbers count each sale once.

We also refund a test order to confirm no phantom purchase remains. Only when all of it holds is the account funded; when it does not, it is fixed first, because a campaign that starts on broken measurement produces a week of numbers nobody can use.

Spend is a fact Meta owns. Purchase value is a claim your store makes. ROAS is only as honest as the weaker half.

Where the ROAS in your panel comes from

Every figure in the panel is read live from Meta's reporting and shown in your currency. Spend is what the account was charged. Purchase value is the events above, after deduplication, that Meta could attribute to your ads inside its attribution window — by default, seven days after a click or one day after a view. ROAS is that value divided by spend. Nothing is estimated or modelled by us; the figures are Meta's own.

Note what that means: panel ROAS is not your store's revenue divided by ad spend. Store revenue includes orders from email, from typed addresses, from customers who came back on their own; Meta's attributed value includes only what it could link to an ad. The two should move together over time, and comparing them is the honest cross-check — but they will never be equal.

You can verify the pieces without a Meta login: the Pixel fires on your own storefront, where a browser extension shows each event as it leaves; server events go out from your own backend; active ads are visible in Meta's public Ad Library under your Page. The panel is a window onto Meta's numbers, and the inputs live where you can see them.

Notes for peptide stores in particular

Subscriptions and repeat orders

A renewal is an order the browser never sees, because nobody visits a page to place it; only the server knows. That makes it the clearest case for CAPI — and the easiest way to distort acquisition numbers, because a renewal sent as a Purchase is attributed to whatever ad click sits inside the window. Send the first order as Purchase and renewals under a distinct event name, so they are counted in their own column without inflating the figure you judge new-customer ads by. Customers who return on their own are claimed the same way through the view window; that is attribution working as designed, so keep your store's repeat rate in its own report.

Order value

Decide once whether the value you send includes shipping and tax, and never change it quietly. Consistency matters more than the choice: a store that includes shipping in one release and drops it in the next has moved its ROAS without touching an ad, and will hunt for a cause in the creative. Send the currency your store charges in; the panel shows the result in yours.

Before the first campaign

Get both sources sending. Share the order number as the event_id on both sides. Place test orders and confirm one purchase each. Decide how renewals are labelled and what value includes, and write it down. Then fund the account, not before. It is the least glamorous hour in the operation, and the one that makes every later number worth reading.