Purchase Event

Also known as: Purchase pixel event, Conversion event Purchase

What is a Purchase event?

The Purchase event is the Meta Pixel standard event that fires when a customer completes a paid order on your website. It is the single most important event in the Meta tracking stack.

Per Meta's Standard Events documentation, Purchase carries the order's monetary value, currency code, the SKUs purchased, and a unique event ID. Meta uses that payload for three jobs.

• Attribution. Match the order back to the ad click that drove it.
• Optimization. Train the delivery algorithm to find more buyers.
• Reporting. Populate ROAS, CPA, and revenue columns in Ads Manager.

Get the Purchase event right and Ads Manager numbers match Shopify. Get it wrong and every downstream decision is built on bad data.

Where to fire a Purchase event

Fire the Purchase event on the order-confirmation page. Not the cart page. Not the checkout page. Not the payment-method page.

The order-confirmation page is the page a customer sees only after the payment processor returns success and the order is written to your database. In Shopify it is /checkouts/.../thank_you. In WooCommerce it is the order-received endpoint. In a custom stack it is the route your backend redirects to after payment_intent.succeeded.

Why so strict. The cart page fires on every "Add to cart" click. Half of those carts are abandoned. A Purchase event on the cart page reports phantom revenue, inflates ROAS, and trains Meta's algorithm to chase window-shoppers instead of buyers.

Per Shopify's Meta Pixel implementation guide, the platform fires Purchase only on the order-status page. Custom builds must enforce the same rule manually.

Required parameters for a Purchase event

A well-formed Purchase event carries five parameters. Two are required by Meta. Three are required by anyone who wants their data to actually work.

Parameter	Required by Meta	Type	Example
value	Yes	number	89.00
currency	Yes	ISO 4217 string	'USD'
content_ids	Recommended	array of strings	['SKU-1234', 'SKU-5678']
content_type	Recommended	string	'product'
event_id	Required for CAPI dedup	string	'order_98231_2026-04-25'

A minimum-viable Purchase event call.

fbq('track', 'Purchase', {
  value: 89.00,
  currency: 'USD',
  content_ids: ['SKU-1234'],
  content_type: 'product',
  num_items: 1
}, {
  eventID: 'order_98231_2026-04-25'
});

Skip currency and Meta assumes USD. International accounts running EUR or GBP campaigns lose 15 to 30 percent of attributed revenue this way. Skip content_ids and dynamic product ads stop working.

Skip event_id and CAPI deduplication is impossible.

Why Purchase event accuracy matters more than any other

Every event in the funnel feeds the Meta algorithm. The Purchase event feeds it directly into the bidder.

Advantage+ Shopping campaigns optimize against Purchase volume and Purchase value. The bidding model uses every Purchase event as a labeled training example. Wrong values produce wrong bids. Missing Purchase events produce starved campaigns that cannot escape the learning phase.

Three downstream systems break when Purchase data is wrong.

1. ROAS reports lie. A Purchase event with value: 89 instead of 89.99 is a 1 percent error. Across 10,000 orders the error becomes a five-figure miscount. Optimization decisions made against the wrong number compound monthly.
2. Lookalike audiences degrade. Lookalikes seed off the Purchase audience. If the seed is polluted with abandoned carts firing fake Purchase events, the lookalike chases the wrong buyer profile.
3. Attribution windows misfire. Meta's 7-day-click window depends on a clean Purchase timestamp. Late-firing Purchase events from a server batch job get attributed to the wrong ad.

A 10 percent error on PageView is noise. A 10 percent error on Purchase moves the entire account.

CAPI deduplication for Purchase events

The browser-side Purchase event is unreliable. iOS App Tracking Transparency, Safari ITP, and ad blockers all suppress fbq calls. The fix is the Conversions API.

Send the Purchase event twice. Once from the browser via the pixel. Once from your server via CAPI. Meta deduplicates the pair using two fields.

• event_name. Must match exactly. 'Purchase' on both sides.
• event_id. A unique string per order, identical on both calls.

Per Meta's deduplication documentation, Meta keeps the higher-quality event and discards the duplicate within a 48-hour window. The browser event usually wins on attribution data. The server event usually wins on Event Match Quality.

The event_id should be deterministic. Use the order ID, not a random UUID. If the browser fires order_98231 and the server fires order_98231_v2, Meta treats them as two separate Purchases. Reported revenue doubles. CPA targets collapse.

Common Purchase event mistakes

Most accounts that look "broken" in Ads Manager have Purchase event problems, not creative problems.

The five mistakes that ruin Purchase data.

1. Firing on the cart page. The single most common mistake. Reported Purchases run 3x to 5x actual orders. ROAS looks incredible. Stripe revenue does not match.
2. Including tax and shipping in value, then comparing to net revenue in your CFO's spreadsheet. Pick one. Document the choice. Per Meta's value parameter guidance, most accounts send the order subtotal excluding tax and shipping.
3. Mismatched content_ids between browser and server. Browser sends ['1234'] as strings. Server sends [1234] as integers. Meta treats them as different events. Deduplication breaks silently.
4. No event_id. Browser fires Purchase. Server fires Purchase. Both count. CPA reports show half the truth.
5. Firing Purchase on a refund webhook. Refunds need their own custom event. Negative Purchase values are not supported by the standard pixel.

A 30-minute audit using the Meta Pixel Helper plus a test order catches all five.

Real-world example with numbers

A direct-to-consumer apparel brand spends $42,000 a month on Meta. Reported ROAS sits at 4.8. Stripe revenue tells a different story. Actual ROAS is 2.9.

The audit finds three Purchase event problems.

Problem	Impact
Purchase fires on cart page (legacy GTM tag)	Reports 3,400 Purchases vs 1,950 actual orders
value includes tax and shipping	Average reported order value $112 vs actual $89
No event_id on browser pixel, CAPI active	Server adds 18 percent more duplicate Purchases

Fixes ship in two days.

• The cart-page tag is removed. Purchase fires only on /checkouts/.../thank_you.
• value is rewritten to send the order subtotal. Tax and shipping move to optional parameters.
• A deterministic event_id (shopify_order_{id}) is added to both browser and server calls.

After 14 days of clean data, reported Purchases drop from 3,400 to 1,960. Reported ROAS drops from 4.8 to 2.93. The number now matches Stripe within 1 percent.

The campaign was not underperforming. The conversion tracking was overcounting. With clean Purchase data, the brand reallocates budget away from two campaigns that looked profitable but were not, and return on investment on the remaining spend climbs 22 percent in the next 30 days.

The creative did not change. The Purchase event did.

Related terms

• Meta Pixel Events
• Pixel
• Conversion
• Conversion Tracking
• Attribution Window Meta
• Return On Investment Roi

Frequently asked questions

Where should the Purchase event fire?

On the order-confirmation page only. Never on the cart page, never on the checkout page. The event must fire after the payment processor returns success and the order is written to the database. Firing earlier inflates revenue and trains the algorithm on abandoned carts.

What parameters does the Purchase event require?

Per Meta's Standard Events docs, a Purchase event requires value and currency. Strongly recommended: content_ids, content_type, num_items, and event_id for Conversions API deduplication. Skip currency and Meta assumes USD, which silently breaks international ROAS reports.

How does Purchase event deduplication work with CAPI?

Send the same Purchase event from the browser pixel and from your server. Pass an identical event_id and event_name on both. Per Meta's CAPI deduplication docs, Meta keeps the higher-quality event and drops the duplicate within a 48-hour window.

Why does the Purchase event matter more than other events?

It is the only event tied to revenue. Meta's Advantage+ Shopping campaigns optimize directly against Purchase events. ROAS, CPA, and lookalike audiences all depend on Purchase accuracy. A 10 percent error on PageView is noise. A 10 percent error on Purchase moves the entire bid strategy.

Can you fire multiple Purchase events for one order?

No. One order equals one Purchase event. Subscription renewals fire their own Purchase events on each renewal date. Refunds do not fire a negative Purchase event in the standard pixel. To handle refunds in reporting, send a custom Refund event via Conversions API and reconcile in your warehouse.