Meta CAPI Deduplication: Stop Counting the Same Shopify Purchase Twice (sGTM Guide)

The Dynamic Random UUID Trap

Many developers generate the event_id on the client side using a random string or epoch timestamp (e.g., UUID_98741 in the browser pixel), while the server-side tag generates its own independent identifier (e.g., CAPI_12345).

Because Meta uses the pair of event_name and event_id to evaluate whether two hits represent the same transaction, different IDs cause Meta to treat them as two distinct purchases.

Shopify Webhook Re-Delivery Storms

Shopify operates an "at-least-once" webhook delivery system. If your server endpoint takes slightly longer to respond with an HTTP 200 (for example, during a flash sale or database latency), Shopify immediately retries the webhook delivery.

If your server pipeline does not check whether that specific order has already been dispatched to Meta CAPI, multiple identical server-side conversions are transmitted minutes apart, completely bypassing Meta's real-time deduplication filters.

Collisions Between Native Shopify Apps and Custom sGTM

A common configuration error is keeping the native Facebook & Instagram sales channel active in Shopify while concurrently running Server-Side GTM.

The native Shopify app sends its own browser pixel and server CAPI events using internal, proprietary ID schemes. If your custom GTM container also sends Purchase events, Meta receives three or four streams per purchase with conflicting ID architectures.

Casing and Event Name Asymmetry

Meta’s deduplication engine is strictly case-sensitive. If your browser pixel fires fbq('track', 'Purchase', ...), but your Server CAPI tag passes event_name: "purchase" (lowercase), Meta's server rejects the deduplication match and records two separate conversion events.

Establish a Deterministic Event ID Hierarchy

Never rely on random numbers or client timestamps for e-commerce purchases. Anchor the event_id directly to the Shopify Order entity:

• Standard Purchase Event ID: purchase_{{order_id}} (e.g., purchase_10582).
• For top-of-funnel events (such as ViewContent or AddToCart), generate a single shared session identifier once per user interaction and pass it to both browser and server tags.

Configure Shopify Customer Events (Web Pixels API)

Within Shopify Admin, navigate to Settings > Customer Events. Ensure your checkout completion subscriber extracts the native order identifier and pushes it into the Data Layer:

1. Map the checkout order ID to a global GTM variable named Event ID - Purchase.
2. In your Web GTM container, configure the client-side Meta Pixel tag:
   Event Name: Purchase
   Event ID: {{Event ID - Purchase}}

Deploy Server-Side Meta CAPI with Parity Matching

Inside your Server GTM container, configure the official Meta Conversions API tag:

1. Set Event Name to Inherit from client or specify Purchase.
2. Set Event ID to read the incoming event_id from the Event Data object.
3. Map user parameters: Ensure email, phone, first_name, and postal_code are normalized and hashed via SHA-256.
4. Pass first-party cookies (_fbp and _fbc) to ensure maximum match rate.

Implement Idempotency Storage for Webhooks

If your server pipeline ingests raw Shopify webhooks (e.g., orders/create or orders/paid), establish an idempotency lock:

• When a webhook arrives, record the order_id in an in-memory database or persistent cache (e.g., Redis or database state table) with a 72-hour TTL.
• If the exact same order_id arrives a second time, immediately acknowledge the request with HTTP 200 to satisfy Shopify, but terminate the execution before dispatching a redundant CAPI hit.