Written by 4SYSTEMPublished on Updated on
8 min read
Pixel Meta and Conversions API can transmit the same action by the browser and by the server. To avoid counting these transmissions as two conversions, the corresponding events must share a consistent event ID and name, using the deduplication method recommended by Meta.[36] The control must start from an identifiable business action, then follow its transmissions to the Event Manager. Installing an integration is not enough to prove that the counting is correct.
Start with a purchase or a test quote request, with the necessary permissions. Check what triggers the event, which system creates its identifier, and whether it arrives intact in both channels. Consider ad collection, deduplication, and attribution separately: these controls don't answer the same question.
Key points
- A single action can have two transmissions without constituting two business results.
- The identifier must designate the event, not just the person.
- The server does not remove data and tracker obligations.
- A successful diagnosis on an event does not validate all site integrations.
Trace collection chain
List the tools that can send events: theme code, tag manager, e-commerce module, partner application and server integration. For each tool, note the events sent, their trigger, and the destination. An old module can continue transmitting after adding a new integration.
The starting point must be an action confirmed by your business system. Clicking on “pay” is not necessarily an accepted purchase. Likewise, opening a confirmation already displayed does not represent a new request. Write down the expected trigger before looking at the numbers.
Meta describes redundant configuration as sending the same events by the Pixel and by API. She recommends deduplicating these events to avoid duplicate reporting.[53] Redundancy seeks to complete the collection, not to artificially multiply the observed actions.
To specify the actions selected, rely on the guide dedicated to measurement plan and useful events. The Meta names and settings remain specific to Meta; the business definition method is what you reuse.
Pixel Meta and Conversions API: understanding identifiers
In the recommended method, the eventID of the Pixel must match the event_id of API, and the browser event name must match the event_name server.[36] The difference in writing parameters is real. Ask the technical lead to verify the fields actually transmitted, not just the wording displayed in a module.
The event ID answers the question "what action is this?" ". A customer identifier answers the question “which person or record is this?” ". Using the same customer ID for all purchases would make it impossible to distinguish actions. Conversely, creating a new identifier for each channel would make two shipments relating to the same purchase appear different.
Meta also specifies that the match must be on the same Pixel and that, for this method, matching events must be sent within the documented 48 hour window.[36] This delay is not a voluntary storage instruction: favor transmissions close to the action, then control delays and resumptions.
Organize generation and restarts
Designate the system that creates the identifier and the one that stores it. The architecture depends on your platform: the event can be prepared on the site side then shared to the server, or defined from an action validated in the business system. The important point is the continuity of the same identity between corresponding transmissions.
Document behavior in case of network failure. A technical repetition of the same action must not be treated in your own integration as a new action. On the other hand, another command must be given a distinct identity. Have this mechanism reviewed before adding a second tracking application.
Avoid placing readable personal data in credentials or diagnostic logs. Keep the information necessary for the investigation with appropriate access. The collection plan must specify the fields, their purposes and their recipients; “submit everything to improve the score” is not a reasonable measurement decision.
Receive deduplication on an action
Prepare a test event recognized as such in your environment. Note the time, route and internal business reference. Review the testing tools available in Event Manager and your integration logs. Interfaces are evolving; keep useful fields and results rather than a procedure tied to a button location.
| Control | Expected result | Anomaly to search for |
|---|---|---|
| Trigger | Business action actually validated | Event on click before confirmation |
| Name | Same event in both channels | Different names for the same action |
| Identifier | Common value for matching shipments | Identifier created separately by each tool |
| Destination | Same Pixel Intended | Old destination still active |
| Business parameters | Amount and currency consistent if used | Value recalculated with another convention |
| Reloading | No new business action | New uncontrolled transmission |
| New action | Distinct identity | Identifier reused for several purchases |
Then perform a second separate action. This control prevents a solution supposed to remove duplicates from merging different purchases. Also test the return on confirmation and a server recovery. Do not use the appearance of two raw lines as immediate evidence of a counted duplicate: the tool may show transmissions before they are processed.
Check consent in both channels
The CNIL indicates that the advertising trackers concerned require prior information and consent; it also recalls the possibility of refusing and withdrawing this consent.[31] Therefore check the loading of the Pixel before choice, after refusal, after acceptance and after withdrawal.
An event sent from a server does not necessarily read the terminal itself. This does not make all the data it carries free to use. Its collection may depend on trackers, and Meta requires you to have the necessary legal authorizations and consents before sharing information with third parties.[53] Have the actual setup analyzed rather than presenting Conversions API as a workaround for the denial.
The acceptance testing must check what is sent in both channels for each applicable state. If the choice only concerns browser tags but not server integration, the presence of a banner does not attest to the operation of the device. Document the deviation, its scope and the correction to be retested.
Fictitious example: a purchase transmitted by two integrations
This example is fictitious. An imaginary store uses an app that sends purchases to the server and a Pixel tag on the confirmation page. The team makes a test purchase and sees that each channel creates its own identifier, even though they describe the same action.
The technical manager chooses a common event reference, kept for the corresponding transmissions. It checks the name, destination and business parameters. It then controls another order and the reloading of the first confirmation. The objective is to distinguish two real commands while recognizing the two transmissions of the same command.
No advertising gain is deducted from this correction. It aims for signal coherence. The store keeps proof of receipt and also reviews the behavior after refusing advertising collection, because correct deduplication does not resolve an authorization defect.
Read deviations without confusing diagnostics
Match quality concerns the reconciliation of information with Meta accounts; deduplication concerns transmissions of the same action.[53] An improvement in the first indicator therefore does not prove that the second is correct. Review the diagnostics separately.
Your order count and conversions attributed by Meta may differ for other reasons: event scope, attribution windows, collection permissions, and deadlines. First reconcile the business actions and events actually sent, then analyze the attribution. Seeking equality at all costs can lead to sending too much data or changing a fair count.
After changing the theme, application or payment, replay the scenarios. Keep a device owner and record of active integrations. It is often more useful than a green dashboard whose perimeter no one knows.
Frequently asked questions
Can we use the order number as an identifier?
It can serve as a basis if your architecture guarantees a stable identity, distinct for each action and shared between the channels concerned. Have the constraints of your integration and the confidentiality of the value checked. Do not automatically use it for other events linked to the same command: they do not all represent the same action.
Should the Pixel be deleted when the server is running?
Not just to avoid duplicates. Meta recommends a redundant configuration accompanied by deduplication.[53] Your decision depends on the collection system, authorizations and actual needs. Before deleting a channel, identify what it is sending and verify that you are not masking an integration issue that will remain present elsewhere.
Does a good match score prove compliance?
No. This score relates to the quality of technical reconciliation, not to the legality of the collection nor to respect for choices.[53] You must check the purposes, the information given, the necessary authorizations and the concrete behavior of the integrations. Don’t add personal data just to improve a platform metric.
Request proof on a specific scenario
Choose an action, list its integrations, and require a acceptance testing showing its IDs, triggering, and collection choices. If several service providers are involved, the 4SYSTEM services can help define the scope of control. The expected deliverable remains a verifiable chain, not a promise of perfect attribution.
Sources
- Cookies et traceurs : que dit la loi ? | CNIL (accessed 2026-10-08)
- Meta : déduplication Pixel et Conversions API (accessed 2026-10-08)
- Recommandations relatives à l’API Conversions visant à améliorer les performances publicitaires | Pages d’aide Meta Business (accessed 2026-10-08)
