ReadyStore
Meta tracking

Meta Pixel and Conversions API for COD stores

Send the same events from the browser and from the server, with a shared event_id so Meta deduplicates them, and attach the right Pixel to each product.

Illustration: sample data
In short

ReadyStore sends PageView, ViewContent, InitiateCheckout, Lead and Purchase through the Meta Pixel (browser) and the Conversions API (server) using the same event_name and event_id, so Meta can deduplicate. Each product can have its own Pixel, and attribution (UTM, fbclid, fbp, fbc) is stored with the order.

How it works

Two channels, counted once

The Pixel runs in the browser: it can be blocked by an extension, a restrictive browser or declined consent. The Conversions API sends the same event from your server, without depending on the visitor’s browser.

ReadyStore generates an event identifier (event_id) and uses it for both copies. Meta recognizes they are the same event and counts it once. When a send is retried, the event keeps its original event_id and timestamp.

  • Same event_name and event_id in browser and server
  • Customer data hashed (SHA-256) before server sends
  • The order response is never delayed by sending to Meta

Events sent

The steps of a COD sales journey and the channel used for each.

EventTriggered whenChannels
PageView, ViewContentThe product page is displayedBrowser + server, in parallel
InitiateCheckoutThe customer starts filling the order formBrowser + server
LeadDepending on your setup: order saved or order abandonedBrowser + server
PurchaseAfter the order is actually savedBrowser (after the response) + server via a durable queue

Lead and Purchase are sent only after the order or abandonment is persisted, never before.

Beyond sending

What makes tracking usable

One Pixel per product

A store can manage several Pixels (Pixel ID, Dataset ID, CAPI access) and each product is linked to its own. Events don’t mix from one product to another.

Attribution preserved

UTM (source, medium, campaign, content, term), fbclid, gclid, ttclid, fbp and fbc are stored with the order, along with the landing URL, referrer and device.

Durable queue and retries

Server sends go through a persistent queue: on failure (network, Meta delay, restart) they are retried automatically with the same event_id, up to eight attempts.

Data quality

Orders flagged as suspected fraud (same IP, several orders within an hour) don’t send a Purchase. Blocked-IP lists add protection.

Setup

Connect your Pixel in three steps

  1. 1

    Add your Pixel

    In the dashboard’s Pixels section, enter the Pixel ID, Dataset ID and Conversions API access. Sensitive credentials are encrypted server-side.

  2. 2

    Link it to your products

    Choose each product’s Pixel. You can separate campaigns, brands or tests.

  3. 3

    Verify in Meta

    Check in Events Manager that events arrive through both channels and are deduplicated.

Pixel and Conversions API questions

What’s the difference between the Pixel and the Conversions API?

The Pixel sends events from the visitor’s browser; the Conversions API sends them from your server. Using both with a shared event_id improves coverage without double counting.

Will my events be counted twice?

Not when deduplication works: both copies carry the same event_name and event_id, and Meta keeps one. Check deduplication status in Events Manager.

Can I use several Pixels in one store?

Yes. Each product can be linked to its own Pixel, with its own ID and Conversions API access.

Does ReadyStore guarantee a percentage of events received?

No. Results depend on your audiences, their browsers, consent and Meta. ReadyStore sets up the dual channel, deduplication and retries to reduce avoidable causes of loss.

Measure your campaigns all the way to the order.

Create your store, add your Pixel and link it to your products.