What sources do Pixel and CAPI use?
When reviewing the measurement implementation, associate Pixel with browser activity on the website and CAPI with a server, website platform or suitable CRM source. CAPI supports different sources; this does not mean every platform connector automatically sends every supported event type.
A browser may observe page, product and basket steps while a server holds confirmed transaction records. These can complement each other. A server integration alone does not observe every page behaviour or ad impression. Browser blocking, network faults and consent are distinct issues; a reporting discrepancy cannot establish its cause by itself.
| Comparison | Meta Pixel | Conversions API |
|---|---|---|
| Transmission point | Browser code on the website | Server, platform or suitable system integration |
| Example signal | Product-page viewing | Confirmed order or appropriate CRM stage |
| Required controls | Trigger, page and permission behaviour | Source record, transmission and retries |
| Combined use | Can send the same business occurrence | Corresponding events require duplicate handling |
| Legal boundary | Permission and sharing conditions apply | Server transmission does not remove these conditions |
Define the actual business occurrence first
In the store measurement plan, state which business status Purchase represents. Entering checkout, creating an order and confirming successful payment are different stages. Failed payment and a page refresh should not appear as completed sales.
Define the source, triggering condition, time, identifier, value and currency for each event. Explain which charges the order amount includes and how company reporting treats cancellations and refunds. Do not assume an event already sent to Meta automatically changes to reflect the latest order status.
For services, clicking a form button differs from successfully receiving an enquiry. If CRM discussions or completed sales are measured, verify their definitions, records and appropriate transmission method separately. Phone, subscription and store processes should not simply inherit a website Purchase recipe. Adding more event names in a low-volume business does not create better data.
FROM READING TO A NEXT STEP
Define the measurement source and maintenance scope
Review the existing event map, platform connections and permission flow to identify implementation and validation requirements.
Prevent one transaction being counted twice
The duplicate review should identify which business occurrences are transmitted through both browser and server. Different occurrences are not duplicates. A new purchase needs a new identifier; do not generate a random replacement when retrying the same transaction.
Meta’s recommended method matches Pixel eventID with CAPI event_id and matching event names. For the same Pixel, a corresponding duplicate within 48 hours can be discarded. When content does not meaningfully differ, the general preference is the first received event, rather than always CAPI or the highest match score.
For example, browser and server can share the same transaction identifier for one order. A product code or one fixed identifier for all customers is unsuitable. Browser/server duplicate handling should not be treated as a universal solution to repeated server records; validate the sending workflow itself.
Choose an implementation with a maintenance owner
When designing the system workflow, inspect whether an existing platform connector, server tagging, gateway or custom backend actually supports the required occurrence. Easier installation still requires correct event meaning, permission and duplicate checks.
For platforms such as Shopify or ikas, verify current integration scope, subscription requirements, applications and configuration. Adding a custom sender beside a native connector can duplicate existing events. Bespoke software is not mandatory for every company; source reliability and team capacity matter alongside technical budget.
Delivery should include an event map, access roles, error records, change procedure and named maintenance owner. Specify which checks follow changes to the platform, payment provider or backend. Keep access tokens out of browser code and exposed logs, with permissions limited to necessary responsibilities. Working once does not establish ongoing correctness.
Preserve permission and data boundaries in both routes
Measurement ownership should assess collection, use and sharing with Meta as separate purposes. CAPI is a transmission route rather than an automatic legal basis or consent mechanism. A privacy notice and consent are also different actions.
Meta’s Business Tools Terms cover necessary rights, specified handling of contact information and sensitive-data limits. Keep health or financial circumstances out of event names, URLs, custom parameters and submitted form answers. Hashing creates neither sharing rights nor automatic anonymisation.
Implement the appropriate permission flow for nonessential advertising cookies under applicable requirements. Test how a user’s choice affects browser and server transmission; routing rejected tracking through the server is not a remedy. Send only necessary, lawfully shareable fields. Do not transmit whole free-text answers, payment details or internal CRM notes.
Complete testing against acceptance criteria
Before using the campaign measurement, compare a known test transaction with its source and record. Events Manager test and diagnostic views can help; one healthy status does not establish correct sales, values and permissions throughout the workflow.
Separate test records from actual customer outcomes. For missing events, inspect triggers, consent, network and transmission errors; for delays, inspect source time and queues; for excess events, examine reloads, payment notifications and additional integrations. Company orders and Meta totals need not match exactly because attribution and coverage differ.
Verify the occurrence
Confirm that an incomplete transaction is not sent and an appropriate test is recorded with the correct source and stage.
Compare event contents
Check identifiers, names, timestamps, values and currencies against source records. Missing or invented fields do not constitute completed validation.
Test duplicates and permissions
Examine refreshes and retries for the same transaction. When user preferences change, verify both transmission routes together.
Hand over maintenance
Document error and delay monitoring, the responsible owner and checks following implementation changes.
Do not confuse match quality with business outcomes
In the growth assessment, track technical accuracy separately from commercial outcomes. EMQ diagnoses how customer parameters in server website events help match events to Meta accounts. It does not establish that a purchase happened correctly or that a campaign was profitable.
Meta’s current explanation uses a 0–10 score and notes that improved matching can increase additional reported conversions. A higher ROAS after implementation therefore should not immediately be presented as additional sales. Instead of prescribing a universal score of seven or nine, inspect missing fields, source quality and sharing rights.
Disclose changes in event coverage and attribution definitions when comparing earlier periods. Company orders, appropriate enquiries, new customers and retained contribution provide business checks. Removing Pixel or adding CAPI does not recover every loss. Measurement needs reliable delivery, consistent permission behaviour and documented maintenance to remain useful.
BEFORE YOU DECIDE
Frequently asked questions
Should Pixel and CAPI be used together?
Meta recommends combined use, while suitability and implementation still need assessment. Verify duplicate handling when both routes transmit corresponding events.
Does CAPI eliminate every effect of browser blocking?
No. It provides another route rather than automatically resolving missing sources, permissions, matching or transmission faults.
Is event_id alone sufficient for deduplication?
The recommended method matches browser eventID, server event_id and event names for the same Pixel. Correct transaction-identifier generation also matters.
Does a higher EMQ prove more sales?
No. Matching and reporting coverage may have changed. Verify actual orders and commercial outcomes separately.
Does every store need custom CAPI software?
No. A suitable platform integration may suffice. Inspect supported events, subscription scope, permission behaviour and maintenance ownership.
Can server transmission ignore user consent?
No. Applicable legal basis, consent and platform terms still matter. Server delivery and hashing do not remove these boundaries.
LET’S DEFINE THE SCOPE
Define the measurement source and maintenance scope
Review the existing event map, platform connections and permission flow to identify implementation and validation requirements.
Discuss the measurement scope