Home/Blog/How to Use the Meta Conversions API and Pixel Deduplication Spec Prompt to Stop Double Counted Purchases
Blog

How to Use the Meta Conversions API and Pixel Deduplication Spec Prompt to Stop Double Counted Purchases

P
promptstudio

Write the implementation spec a developer needs to send the same purchase and lead events from the Meta Pixel and the Conversions API without double counting: event_name and event_id pairing, which user_data fields to hash and which to send raw, timing limits, consent gating, and a Test Events checklist.

How to Use the Meta Conversions API and Pixel Deduplication Spec Prompt to Stop Double Counted Purchases

Sending events from both the Meta Pixel in the browser and the Conversions API on the server is a common setup for ecommerce stores. It helps when browsers block or drop the Pixel, but it creates a new problem: if the two sources are not matched, Events Manager can count the same purchase twice. Reports look better than reality, and campaigns optimize toward numbers that are not real. The Meta Conversions API and Pixel Deduplication Spec: event_id Matching, user_data Hashing, and Test Events Checks for an Ecommerce Store prompt writes the spec a developer needs to send both sources and have Meta treat them as one event.

What the prompt produces

  1. An event matrix with event names, triggers on each side, and where the shared event id comes from.
  2. Browser code for the Pixel track call with the event id included.
  3. A server payload with event time, event id, action source, source URL, user data, and custom data, marking which fields are hashed and which are sent raw.
  4. Normalization rules to apply before hashing each customer field.
  5. Consent gating so the server does not send what the browser was refused.
  6. A test plan using the Test Events tool, plus a diagnosis of the symptoms you see now.

How to fill the inputs

PixelSetup describes your platform and how the Pixel is installed, whether through a native integration, Google Tag Manager, or theme code. ServerPath is how server events will be sent: a platform integration, the Conversions API Gateway, server side GTM, or your own backend.

EventList names each event and where it fires. CustomerData lists what you know about the shopper at each event, such as email, phone, address, customer id, IP address, and user agent. ConsentSetup describes your cookie banner and regions where consent is required. Symptoms is what looks wrong in Events Manager today, such as purchases far above real orders.

Reading the example output

The example is a WooCommerce store whose Events Manager shows about twice as many purchases as real orders. Lessons worth copying:

  • Only dual source events need deduplication. Purchase is sent from both sides, so it gets a shared id. Other events stay browser only for now.
  • The order id becomes the event id. Both the thank you page and the payment webhook already know the order, so both use the same value.
  • Refreshes are guarded. A flag on the order stops the Pixel from firing again if the shopper reloads the thank you page.
  • Hash the right fields. Email, phone, names, city, zip, country, and customer id are normalized and hashed. IP address, user agent, and the browser cookie values are sent as they are.
  • Use the shopper's details, not the webhook's. A payment webhook may come from the payment provider, so the store saves the shopper's IP, user agent, and cookies at checkout and sends those.
  • Consent applies to both sides. If a visitor declines marketing cookies, the server skips the event too.
  • The symptom has a likely cause. Double purchases usually mean the Pixel event has no id or the server sends a different one, or a plugin is sending its own server events alongside the custom hook.

Tips for better results

Pick one id source per event. Order ids and lead ids work well because both the page and the server know them.

Test with a test event code. Send a test order and confirm one purchase shows both browser and server with a deduplicated status, then remove the test code before going live.

Check field names in current docs. Meta updates its developer documentation, and the prompt marks names to confirm.

Look for duplicate integrations. Many stores have a plugin sending server events already. Two server senders cause their own duplicates.

Mistakes to avoid

  • Sending raw email or phone numbers.
  • Hashing the IP address or user agent.
  • Using different event names on the two sides.
  • Sending server events for visitors who declined consent in the browser.

Who it is for

This prompt fits ecommerce marketers, analytics and tracking specialists, agency developers setting up client stores, and founders who want their ad reporting to match their order system. It works for WooCommerce, Shopify, and custom stores, as long as you describe the setup.

Related PromptDig links