Browser and server events can improve resilience and matching, but sending the same business event through two channels without consistent identifiers can double reporting and distort optimization. Start with an event specification and one ownership map.
What this guide covers
Define events and parameters, align browser and server identifiers, respect consent, validate diagnostics and reconcile events against the source transaction or lead system.
Write an event specification
Describe the business action, trigger, required parameters and source of truth before implementing Pixel or CAPI.
Use standard events accurately
Choose the event that matches the visible user action rather than the one with the most attractive reporting label.
- Map page views, leads, checkout and purchases.
- Define required value and currency rules.
- Exclude sensitive or unnecessary personal information.
Assign event ownership
Document which integration, plugin, tag manager or server sends each copy.
- List browser and server senders.
- Remove overlapping legacy integrations.
- Keep development and production datasets distinct.
Design reliable deduplication
Meta typically needs matching event name and event ID for browser and server copies of one event.
Generate a stable event identifier
The identifier should represent the business event, not a random value generated independently by each channel.
- Create the identifier at a shared point.
- Pass it unchanged to browser and server.
- Use transaction identifiers where appropriate and permitted.
Test retries and repeated views
Server retries and confirmation-page reloads can create extra events.
- Make server processing idempotent.
- Test back, refresh and retry behavior.
- Review event diagnostics for duplicate patterns.
Handle consent and matching data carefully
CAPI is not a route around user choice or privacy obligations.
Connect consent to both channels
Browser and server decisions should represent the same applicable preference.
- Map CMP signals to event processing.
- Test rejection and preference changes.
- Document retention and deletion responsibilities.
Use permitted matching fields securely
Only collect data needed for a documented purpose and protect it in transit and at rest.
- Review data use and notices.
- Normalize fields according to current Meta guidance.
- Restrict logs and operational access.
Validate quality without chasing one score
Event Match Quality is a diagnostic input, not a reason to collect every available field.
Use Test Events and diagnostics
Confirm event name, timing, parameters, source and deduplication in realistic journeys.
- Test normal and failed conversions.
- Inspect warnings and processing delays.
- Verify value and currency consistency.
Reconcile with business records
Platform event totals should be monitored against orders or lead records.
- Set an expected tolerance and explanation process.
- Investigate sudden divergence.
- Retest after checkout, plugin or CMP changes.
Primary sources
Platform features and policies change. Review the current primary documentation before implementation.