Tracking & Conversions

Two paths for one event

Every conversion can reach a platform two ways: from the visitor's browser, or from your server. The browser path is easy to install and easy to lose — ad blockers, privacy settings and cookie limits all cut it. The server path is harder to set up and far more durable. Modern setups send both and let the platform de-duplicate.

Path	Meta	Google	Fails when
Browser	Pixel	Google tag (gtag.js), usually via GTM	Ad blockers, tracking prevention, short cookie lifetimes
Server	Conversions API (CAPI)	Enhanced conversions / server-side tagging	Your backend is down or the payload is malformed

Sending both without a shared event ID means every sale is counted twice. De-duplication is not automatic — it depends on you sending the identifier that lets the platform match the two copies.

De-duplication, concretely

Meta matches a browser event to a server event when both carry the same event_name and the same event_id. Generate that ID once, per event, and send the identical value down both paths.

Same event, both paths

# Browser (Pixel)
fbq('track', 'Purchase', {value: 249.00, currency: 'EGP'}, {eventID: 'ord_10432'});

# Server (Conversions API)
{
  "event_name": "Purchase",
  "event_id": "ord_10432",
  "event_time": 1755000000,
  "action_source": "website",
  "user_data": { "em": "<sha256 of lowercased email>" },
  "custom_data": { "value": 249.00, "currency": "EGP" }
}

Use your own order ID as the event ID. It is unique, stable and already exists.
Hash email and phone with SHA-256 after lowercasing and trimming, exactly as documented.
Send the same currency and value on both paths, or reporting will disagree with itself.

Match quality is a number you can raise

A server event with nothing but an IP address barely matches anyone. The more identifying parameters you send, the more conversions get attributed to the right click — which directly improves the optimisation signal the auction uses.

Send email, phone, first and last name, city, country and external ID where you legitimately hold them.
Include the click identifier from the landing URL — fbclid for Meta, gclid for Google — captured at first touch and stored with the order.
Check Event Match Quality in Events Manager after changes; treat it as a metric you own, not a diagnostic you read once.

Collect and send only data you have a lawful basis to process, and respect the visitor's consent choice. A high match rate built on ignored consent is a liability, not a win.

UTMs are for you, not for the platform

Platform reporting tells you what the platform believes. UTM parameters are how the same click shows up in your own analytics, where you control the definitions. Fix the scheme once and never rename a field again.

UTM scheme

utm_source   = meta | google | tiktok | linkedin | x
utm_medium   = cpc | paid-social | display
utm_campaign = {campaign-name-from-your-naming-convention}
utm_content  = {ad-name}
utm_term     = {keyword-or-audience}

Example
?utm_source=meta&utm_medium=paid-social&utm_campaign=meta_eg_sales_petfood_202608
&utm_content=video_c118_price-anchor_v2

Lowercase everything. Meta and meta become two rows in every report you will ever run.
Keep utm_campaign identical to the platform campaign name so the two systems join cleanly.
Use the platform's dynamic parameters where available so names stay in sync automatically.

The UTM builder in the site's tools section generates this scheme and keeps the field order consistent across platforms.

Features covered here

UTM parameters GA4 measurement Meta Pixel Conversions API Pixel/CAPI deduplication Event match quality Google tag Enhanced conversions

Check your understanding

3 questions. Wrong answers explain themselves.

1.You send Purchase from both the Pixel and the Conversions API. What prevents double-counting?

2.What is the most effective way to raise Event Match Quality?

3.Why should utm_campaign mirror your platform campaign name exactly?