Meta Server Side Tracking Setup in 2026

Description of Integration Options

Partner Integration

In the webinar, this approach is described as the fastest option when your site is already running on a partner platform or plugin, and you want to “enable CAPI” without any development work. The examples mentioned include Shopify, WooCommerce, Wix, BigCommerce, WordPress, and Webflow.

At WAMP, we recommend this option if standard events suit your needs and you want to minimize implementation time and operational support. At the same time, this typically offers the lowest level of control over the payload and deduplication logic (compared to GTM server and direct integration).

Required components:

- Pixel/Data Source (Dataset) in Events Manager;
- access to the partner’s “sales channel/plugin/integration”;
- access rights to the Business/Meta account to connect the pixel and enable data exchange.

Step-by-Step Technical Guide. Regardless of the platform, we structure the implementation the same way:

Step 1 — Stabilize client-side events (pixel).
Verify that basic events (at a minimum, PageView and key conversions such as Purchase/Lead) are recorded correctly and under the same names (event_name) across all pages/flows.

Step 2 — Connect the partner module and enable data sharing at a level that includes server-side sending.
Using Shopify as an example: the data sharing settings explicitly state that data exchange tools include the Meta pixel and Facebook Conversions API, and Standard/Enhanced/Maximum levels are available.

Step 3 — Enable/verify deduplication at the partner and/or Meta level.
If the partner sends both browser and server events, your task is to ensure they are deduplicated (by event_id/eventID or by alternative keys). On the Meta side, deduplication relies on matching identifiers and/or other keys within a specified time window.

Step 4 — Validation.
Use Test Events (and, if the partner allows it, test code) and diagnostic warnings in Events Manager.

Mini-examples by platform (based on official guides)

Shopify documents that data sharing on the “Facebook and Instagram by Meta” side governs how user data and behavior are transferred between the store and Meta, and explicitly mentions the Meta Pixel and Facebook Conversions API as tools that help track orders/events and improve targeting.

What’s required from the development team: usually nothing, except for correctly passing order parameters (currency/price) to the native checkout (if you have customizations, they may break the standard flow).

WooCommerce describes the process through installing the “Facebook for WooCommerce” plugin (install → activate → setup wizard) and directly links this to reaping the benefits of the Conversions API.

Wix explains that integrating Meta Pixel & CAPI allows you to automatically connect your site to a Meta Business Account, the pixel, and the Meta Conversions API.

WordPress — the “Meta Pixel for WordPress” plugin page states that it includes support for the Conversions API.

The webinar also emphasized: if you’re using one affiliate plugin, you shouldn’t connect another “server-side” provider at the same time—this complicates deduplication and increases the risk of double counting.

Common Issues and How to Fix Them

Issue: Double counting (an increase in Purchase that doesn’t match the backend).
Cause: Two independent integrations are enabled (e.g., native + another gateway/sgtm), and events are coming in without a coordinated deduplication scheme. Solution: Keep a single “server-side” integration and verify that event_id or alternative keys are working.

Problem: “Mismatch” warnings regarding currency/value.
Cause: Browser and server events carry different value/currency values. Solution: Standardize cost calculations (discounts/shipping/taxes) and ensure identical custom_data across both sources; currency must be ISO 4217.

Conversions API Gateway

In the webinar, the “gateway” is presented as a “no-code/low-code” option that typically mirrors pixel events and sends them server-to-server to Meta. Officially, the Conversions API Gateway is described as a self-serve configuration option in Events Manager.

At WAMP, we recommend the gateway when:

- there is no partner integration or it is insufficient;
- direct development is time-consuming or expensive;
- you want to get closer to a server-side approach without building your own event pipeline (but let’s be honest: if the input is a pixel, then the “input quality” is limited to what the browser sees).

Required components
- Pixel/Data Source in Events Manager;
- cloud infrastructure (Amazon Web Services and Google Cloud Platform are the most common hosting options mentioned in the webinar and within the gateway ecosystem);
- access to DNS (if you’re using a custom domain).

Step-by-step technical guide

Step 1 — Start the setup in Events Manager.
The official guide is launched from your pixel’s Settings: “Set up with Conversions API Gateway” → “Get started”.

Step 2 — Deploy the gateway in the cloud.
The webinar mentioned selecting a region (to reduce latency and comply with local storage requirements) and the option to use an existing cloud provider.

Step 3 — Set up a custom domain (recommended).
Meta explicitly recommends a custom domain and notes that you’ll need access to your DNS provider to add records.

Step 4 — Connect data sources (pixel/dataset) and verify the event flow.
Next, you’ll validate that events are actually being received and review diagnostics/coverage.

Common issues and how to fix them

Issue: The gateway “doesn’t see” the event.
Common cause: The pixel isn’t sending events (website errors, blocking, incorrect container). In this architecture, the gateway doesn’t create an event “out of thin air”—it needs an input signal.

Problem: DNS/domain is not verified or traffic is “bypassing.”
Solution: Check DNS records, TLS/certificates, and the correctness of the Server URL/endpoint routing (this is critical in the gateway; Meta separately emphasizes the importance of DNS access).

Server-side Google Tag Manager

Server-side tagging in Google Tag Manager is a separate architecture where you set up your own server container that receives events, processes them, and sends them to the relevant systems (including Meta). Officially, Google positions server-side tagging as a way to improve privacy control and data quality by using server-side containers with the same elements (tags/triggers/variables) but with additional capabilities.

At WAMP, we recommend server-side GTM when:

- you advertise on multiple platforms and want a single “router” for events;
- you need medium to high control over which fields are sent to which systems and under what consent;
- you are ready to adopt cloud infrastructure and operations (cost/logging/updates).

Required components
- a Google Tag Manager account and containers (Web + Server);
- a Google Cloud project with billing;
- your chosen deployment method (Cloud Run is recommended; App Engine is supported);
- A dedicated subdomain (e.g., sgtm.example.com) and access to DNS.

Google documents the steps and prerequisites for Cloud Run: you need a GCP account/billing/roles, then provision a preview/tagging server, and finally add the server URL to Container Settings.

Step-by-step technical instructions (Cloud Run as the recommended approach)

Step 1 — Create a Server container in GTM and select “manually/auto provision.”
The provisioning steps are described in detail in the Cloud Run guide (including the preview server).

Step 2 — Deploy the tagging server to Cloud Run and configure scaling/cost.
Google provides a rough estimate: approximately $45/month per server in the specified configuration and recommends a minimum of 2 instances to reduce the risk of data loss; setting up a billing alert is also recommended.

Step 3 — Add the server URL to the server container settings.
This is a mandatory step for Preview/Debug to work correctly.

Step 4 — Connect the web container to the server container.
Technically, this is done by sending requests to your server endpoint (often via GA4/gtag or through special data clients). The specific implementation depends on your measurement scheme (GA4-first or Pixel-first).

Step 5 — Configure sending to the Meta Conversions API from the server container.
Practical minimum: An “HTTP Request” (or a ready-made template) in the server container that sends a payload to https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events?access_token=....

Debugging

- Preview/Debug: Google explicitly describes “Validation” via Preview after server configuration.
- Cost and logging: For App Engine, Google states that a server in a production configuration costs about $40/month, recommends a minimum of 3 servers, and warns that logging every request can be expensive with high volumes (and suggests disabling logs).
- Regressions after updates: Google recommends updating the tagging server version for security fixes and new features.

Direct server-side integration via the Graph API

This is the most controllable and “engineering-oriented” approach: your backend (or CRM/POS system) generates an event and sends it to the Graph API endpoint /events. The official documentation describes the submission as a POST request to https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events?access_token=....

At WAMP, we recommend direct integration if:
- you want maximum control (events, fields, sending rules, consent, retries, logging);
- you have a reliable server-side source of truth (order/booking/lead in the backend/CRM), meaning you don’t “mirror the browser” but send the event where it is actually recorded;
- you are ready to invest in development and support.

Required components
- a server/backend (or middleware) that records conversions (e.g., order creation);
- Pixel ID (Dataset);
- access token (generated in Events Manager under Conversions API: “Generate access token”).
- Implementation of SHA-256 hashing and field normalization (email/phone, etc.).
- (Recommended) Consistent generation of event_id, accessible to both the frontend (pixel) and backend—for deduplication.

Step-by-Step Technical Guide

Step 1 — Define events and their truth sources.
Typical minimum: ViewContent, AddToCart, InitiateCheckout, Purchase, Lead. Events affecting optimization must be consistent between the pixel and the server (same event_name for the same action).

Step 2 — Implement the generation and passing of the event_id.
Meta shows how to pass the eventID in the pixel (the fourth argument of fbq(‘track’, ...)) and emphasizes that the eventID must match the event_id of the server-side event.

Step 3 — Collect user_data correctly.
For web events, Meta lists the customer information parameters and specifies which ones should be hashed and which ones should not (for example, client_ip_address, client_user_agent, fbc, and fbp must not be hashed).

The webinar also emphasized the need to provide at least one user_data key (e.g., email or phone number) for attribution.

Step 4 — Normalize and hash PII before sending.
The official description of customer info parameters specifies: trimming spaces and converting to lowercase before SHA-256.

Step 5 — Construct the payload with the required web event fields.
Meta specifies that for website events sent via CAPI, client_user_agent, action_source, and event_source_url are required (this improves event quality).

event_time is a Unix timestamp in seconds; sending “backdated” events up to 7 days is allowed; otherwise, the entire request is rejected.

Step 6 — Send a POST request to /events.
The endpoint and “events edge” format are described in the documentation: https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events?access_token=.. ..

Step 7 — Testing via test_event_code.
test_event_code is a top-level parameter in the request body; it is used to verify event delivery to Test Events.

Example: Pixel + server deduplication by event_id

Pixel example (browser):


javascript
// Generate an event_id on the front end or retrieve it from the backend
const eventId = crypto.randomUUID();
fbq('track', 'Purchase',
{ value: 123.45, currency: 'EUR' },
{ eventID: eventId }
);

Механізм та приклади використання fbq('track'...) з eventID, а також вимога щодо збігу eventID та event_id описані на сайті Meta (включно з 48-годинним вікном дедуплікації).

Приклад: виклик між серверами (curl)

curl -X POST \
"https://graph.facebook.com/v{API_VERSION}/{PIXEL_ID}/events?access_token={ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"data": [{
"event_name": "Purchase",
"event_time": 1736800000,
"event_source_url": "https://example.com/thank-you",
"action_source": "website",
"event_id": "550e8400-e29b-41d4-a716-446655440000",
"user_data": {
"em": "sha256_hex_email",
"ph": "sha256_hex_phone",
"client_ip_address": "203.0.113.10",
"client_user_agent": "Mozilla/5.0 ...",
"fbc": "fb.1.XXXXXXXXXXXXXXX.XXXXXXXXXX",
"fbp": "fb.1.XXXXXXXXXXXXXXX.XXXXXXXXXX"
},
"custom_data": {
"currency": "EUR",
"value": 123.45
}
}],
"test_event_code": "TEST12345"
}'


The requirements for required fields/hashing and the meaning of fbc/fbp are described in the Meta parameters.

Mini-pseudocode for normalization and SHA-256

function normalize_email(email):
return trim(lowercase(email))

function normalize_phone(phone):
digits = keep_only_digits(phone) // including the country code
return digits

function sha256_hex(value):
return SHA256(value).to_hex_lowercase()

em_hash = sha256_hex(normalize_email(email))
ph_hash = sha256_hex(normalize_phone(phone))


Normalization (trim + lowercase) and the SHA-256 requirement for certain customer information parameters are described in the Meta documentation.

Common Issues and How to Fix Them

Issue: Events are not appearing / are appearing with errors.
Check: the validity of the access_token, the correctness of the event_time (no older than 7 days), the presence of required web event fields (action_source, event_source_url, client_user_agent), and at least one identifier in user_data.

Issue: Deduplication is not working.
Check: Whether the eventID in the pixel matches the event_id in the server-side event; note the 48-hour window.

Issue: Poor matching quality.
Check: Are you hashing fields that should not be hashed (client_ip_address, client_user_agent, fbc, fbp)? Are you normalizing email/phone numbers correctly?

Privacy, consent, deduplication, mapping, and testing

Consent and Data Minimization

At WAMP, we take a firm stance on this: server-side tracking does not exempt you from the consent requirements for marketing trackers in the EU. For cookies/trackers that require consent, you must provide users with clear information and the opportunity to give separate consent for tracking cookies.

The principle of data minimization requires collecting only the adequate and necessary minimum of personal data for the purpose of processing.

In practice, for CAPI, this means:

- sending only those user_data fields that actually improve matching quality and for which you have a legal basis;
- Whenever possible, give preference to persistent identifiers without “excessive” PII (e.g., external_id as an internal user_id—provided the policy is correct and when necessary), and send email/phone numbers strictly in accordance with hashing rules and consent.

opt_out and data processing options

Meta supports the following at the parameter level:

- opt_out as a flag meaning “do not use the event for ad delivery optimization; use only for attribution”;
- data_processing_options / data_processing_options_country / data_processing_options_state to enable data processing modes (e.g., LDU).

WAMP recommendation: if the user does not have consent for marketing tracking—in most scenarios, it is safer not to send the event at all (or to send it only within the permitted mode, as agreed with your legal/compliance team). The opt_out/data processing options parameters are a mechanism, not a “get-out-of-jail-free card.”

Deduplication: How to Do It Right

There are two main practical deduplication workflows:

Workflow A — eventID (pixel) ↔ event_id (server).
Meta provides explicit examples of setting eventID in fbq(‘track’, ...) and requires a match with event_id on the server; the deduplication window is 48 hours.

Approach B — “user keys” (fbp/external_id) for automatic deduplication.
Meta explains that when sending external_id and fbp via both the browser and the server, deduplication can occur automatically.

WAMP Recommendation: For e-commerce/leadgen, it is almost always worth implementing Scenario A (event_id) as the primary method, and fbp/fbc/external_id as matching enhancers and a backup.

Event Mapping and Measurement Quality

Key requirements for web events via CAPI:

- client_user_agent, action_source, event_source_url for website events;
- currency (ISO 4217) for purchase events and a correct value;
- event_time as a Unix timestamp in seconds; sending data up to 7 days “back” is allowed;
- at least one user identifier in user_data (otherwise attribution quality will be poor or impossible).

Testing and validation

Level 1 — Meta Test Events + test_event_code.
The documentation states that the test code is generated in Test Events and can be sent as test_event_code so that events are routed to the test stream.

Level 2 — Infrastructure Debugging (for GTM Server).
Google explicitly recommends validation via Preview after configuring the server container and adding the server URL.

Additionally:

- Compare the number of orders/leads in the backend and in Events Manager on a test sample;
- Check Diagnostics warnings (e.g., currency/value mismatch);
- Verify that the same user action produces a single event_id in both sources, rather than two different UUIDs.

Comparison of Options and WAMP's Recommendations for Selection.

Below is our summary of the comparison of integration options. Ratings are relative; costs are listed as typical cost structures.

1. Partner Integration (Shopify/Wix/WooCommerce/WordPress, etc.)

Complexity - Low
Cost - Low (often included in subscription/plugin)
Control - Low–medium
Delay - Low
Data fidelity - Medium (depends on the partner)
Recommended use cases - Quick start, standard events, limited resources

2. Conversions API Gateway

Complexity - Low–medium
Cost - Medium (cloud + support)
Control - Medium
Latency - Low
Data fidelity - Medium (often “mirrors” the pixel)
Recommended use cases - Requires server-side implementation without development, but has access to cloud/DNS; requires a custom domain

3. Server-side GTM (Cloud Run/App Engine)

Complexity - Medium–High
Cost - Medium (cloud + engineering)
Control - High
Latency - Low–Medium
Data fidelity - High with good mapping
Recommended use cases - Multi-platform tracking, field/consent control, advanced routing; consider the cost of servers and logs

4. Direct integration (your server → Graph API)

Complexity - High
Cost - High (development + support)
Control - Maximum
Latency - Low
Data fidelity - Maximum (server as the source of truth)
Recommended use cases - Custom events/parameters, complex funnels, CRM/offline, strict compliance and quality control

WAMP Recommendations

If you’re on Shopify/Wix/WooCommerce and the standard setup works for you—start with a partner, but make sure to get deduplication and testing to “green” status.

If you’re advertising across multiple networks and want a unified control layer—use server-side GTM (Cloud Run as Google’s recommended approach), but budget immediately for infrastructure, logging, and support.

If you have a robust backend/CRM and want “data straight from the server” rather than a “browser mirror”—go for direct CAPI integration with a standard event_id scheme, retries, and consent management.

An important practical tip was shared during the webinar, which we fully endorse: do not stack multiple independent integrations at the same time (e.g., a partner + another gateway) until you understand the exact deduplication scheme and have validated the tracking in Test Events and through real-world syncs with the backend.