Meta CAPI on a second checkout domain.

Moving checkout to a second domain breaks default Meta Pixel attribution because the Pixel cookie _fbp is scoped to the domain that set it. A buyer who lands on acme.com, gets a Pixel-set _fbp, then completes checkout on checkout.acme.com shows up in Meta as two separate journeys unless you actively bridge the identity. Meta's Conversions API (CAPI) on the checkout subdomain — with the same _fbp passed through and a shared event_id deduplicated across browser and server — restores full attribution. This post is the specific wiring.

Why default attribution breaks

The Meta Pixel writes a first-party cookie called _fbp on the origin that loads it. Cookie scope defaults to that exact origin. When the buyer navigates from acme.com to checkout.acme.com, the browser does not send the _fbp cookie from acme.com because the cookie was not set with a wildcard domain. The checkout subdomain sees a fresh visitor with no Pixel identity.

The workaround at cookie level is to set _fbp with the Domain=.acme.com attribute so it flows between root and subdomain. Some Pixel configurations do this by default; many do not. Even when the cookie flows, the browser Pixel on the checkout subdomain now has to fire its own PageView and Purchase events, which Meta will attribute to a different session by default.

The two-layer fix

Layer 1: browser Pixel on the checkout subdomain, sharing the same Pixel ID. Add the Pixel base script to checkout.acme.com. Fire InitiateCheckout on page load. Fire Purchase on the thank-you page. Because the Pixel ID is the same as the one on acme.com, Meta will attribute the two events to the same Pixel — but they will not automatically be linked to the same user session unless the _fbp cookie is also flowing.

Layer 2: Conversions API on the server, with shared event_id. When the browser fires Purchase, also POST a server-side Purchase event to Meta's CAPI endpoint. Include the same event_id Meta assigned to the browser event. Meta deduplicates events with matching event_id across browser and server, so the two events count as one. Include hashed email, hashed phone, IP, user-agent, _fbp, _fbc to give CAPI enough match signal to attribute the conversion even when the browser Pixel was blocked by an ad blocker or iOS ATT opt-out.

The specific wiring

1. Cookie domain. On the root domain's Pixel init, set the _fbp cookie with a domain attribute of .acme.com so it flows to checkout.acme.com. Some tag managers do this via a manual cookie-set step. Meta's own Pixel base code accepts a custom cookie-domain option.
2. Pass _fbc through the URL. The click-attribution cookie _fbc is set from the fbclid URL parameter that Meta appends to ad clicks. When the buyer navigates from cart to checkout, append _fbp and _fbc as query params so the checkout subdomain has them even if the cookie did not carry.
3. Shared event_id. Generate a UUID at the moment of purchase on the browser. Fire the Pixel Purchase event with that event_id. POST the same event_id to Meta's CAPI endpoint (typically via your server-side function). Meta's dedup runs across browser and server on event_id.
4. Hash user data server-side. Email SHA-256 lower-case. Phone SHA-256 in E.164. Include IP + user-agent from the buyer's session. CAPI's match rate improves substantially with these fields.
5. Test with Meta's Test Events tool. The Events Manager Test Events panel shows browser + CAPI events landing side by side. Confirm dedup is working before considering the wiring done.

Common mistakes

Different Pixel IDs on the two domains. Half the merchants who complain that "our attribution broke after moving checkout to a subdomain" have accidentally installed a second Pixel ID on the checkout subdomain, so Meta treats the two funnels as unrelated. Same Pixel ID on both domains.

Missing _fbp forwarding. Setting the cookie with domain .acme.com at the Pixel init is the reliable path. Falling back to URL params is a good belt-and-braces move.

CAPI event without shared event_id. CAPI fires but does not dedupe with the browser Pixel because each event has its own random event_id. Meta counts both, inflating Purchase counts.

Firing Purchase on the wrong page. If the checkout flow has a thank-you page, that is where Purchase fires. Firing it earlier (on capture success but before redirect) risks double-count when the buyer refreshes the thank-you page.

What Cascade specifically handles

CascadeCheckout wires the checkout subdomain with Pixel + CAPI relay out of the box on every plan. Purchase events fire browser + server with a shared event_id, hashed user data is included, and the setup is verifiable through Meta's Test Events panel during onboarding. This is baseline for a checkout subdomain that needs to keep Meta attribution intact after moving off the primary domain's native checkout.

Related reading: All integrations (including Meta CAPI) · Own-domain checkout for Shopify · How it works