Meta Conversions API and Server-Side Tagging, Explained

The Meta Conversions API sends conversion events, such as leads and purchases, from your server, e-commerce platform or CRM straight to Meta, so you are not relying only on the browser pixel. Server-side tagging is the wider practice of routing tracking through a server you control. Together they recover conversions that ad blockers, Safari's tracking protections and short cookie lifetimes hide. They are not a way around privacy rules, and if set up badly they double-count every sale. This guide explains the moving parts in plain language, with India's DPDP rules in mind.

What is the Meta Conversions API?

The Conversions API (CAPI) is Meta's interface for sending web, app, offline and messaging events from a server rather than from a visitor's browser. Instead of a JavaScript pixel firing a "Purchase" event on the thank-you page, your backend, store platform or CRM sends the same event directly.

Meta recommends running CAPI alongside the pixel, a setup often called redundant tracking. The pixel captures browser context such as cookies and page behaviour; the server captures events the browser missed and events that never happen in a browser, such as a lead becoming a customer in your CRM.

The key fields in each server event, according to Meta's server event parameters documentation:

• event_name: a standard event such as Lead or Purchase, or a custom name.
• event_time: a Unix timestamp up to 7 days old. If any event in a request is older, Meta returns an error for the entire request and processes none of it.
• event_id: technically optional but recommended for deduplication, ideally an order or transaction ID.
• action_source: where the conversion happened: email, website, app, phone_call, chat, physical_store, system_generated, business_messaging or other.
• user_data: customer information used for matching, covered below.
• event_source_url: required for website events.

How does event deduplication work?

Meta treats a pixel event and a server event as one conversion when they share the same event name and event ID and arrive within 48 hours of each other. Meta's deduplication documentation describes two methods:

1. event_id plus event_name (recommended). The pixel sends the ID as eventID, the server sends the same value as event_id, and both use the same event name. Events received within 48 hours of the first are treated as one.
2. fbp or external_id. A fallback that generally works only when the browser event arrives before the server event, and never when you send from a single source.

The first method is the one to build around. The common failure is generating the ID twice, once in the browser and again on the server. Create it once, when the order or lead is created, and pass it to both.

A quick deduplication checklist

• Same event name in both channels, with identical spelling and capitalisation.
• One event_id per conversion, shared by browser and server.
• Both events sent to the same pixel or dataset ID.
• Deduplication checked in Events Manager after launch, not assumed.

What is Event Match Quality and how do you improve it?

Event Match Quality (EMQ) is a 0 to 10 score in Events Manager showing how well the customer information on an event lets Meta match it to an account. Better matching means more conversions can be attributed and used for optimisation. Stape's guide to improving EMQ notes there is no official "good" threshold, ranks email and click ID as high-priority identifiers and phone, external ID and browser ID as medium, and points out that IP address, user agent and browser ID need no hashing.

For Indian lead generation, phone number is often the most valuable field you have, because many leads never give an email. Store numbers with the 91 country code and without spaces, dashes or a leading zero before hashing, or they will not match. Capture fbclid on the landing page and keep it with the lead, so CRM events sent days later still carry the click ID.

How do you host server-side tracking?

Pick the simplest route that covers the platforms you advertise on. There are four common options:

Meta's Conversions API Gateway documentation says the Gateway runs in a cloud account the business owns, on AWS EKS, AWS ECS Express or Google Cloud, and that its only cost is the cloud resources or partner fees. The same page describes a simpler "Conversions API with Meta" option, switched on in Events Manager, for businesses that only need website events and want nothing to host.

Server-side Google Tag Manager (sGTM) is a Tag Manager container that runs on a server. Google's infrastructure planning guide estimates Cloud Run costs at about USD 50 per instance per month, with your minimum cost equal to your minimum instances times that figure, and advises moving tracking into a first-party context through your own DNS, typically a subdomain such as data.yourbrand.in. Managed hosts offer cheaper entry plans. The advantage of sGTM is one clean event stream feeding Meta, Google Ads and GA4 at once.

What does India's DPDP framework mean for server-side tracking?

Moving tracking to a server changes where data flows, not whether you may collect it. India's Digital Personal Data Protection Rules were notified in November 2025 with a staggered rollout: some rules applied immediately, consent manager registration after 12 months (November 2026) and most substantive obligations, including notice, consent, security and breach rules, after 18 months (May 2027). Penalties can reach ₹250 crore per breach, as YourStory reported. Media reports in 2026 suggested the government might shorten the timeline, but as of Mondaq's May 2026 review no formal change had been made, so check for updates.

Practical implications for a CAPI or sGTM setup:

• Consent travels with the event. Forward personal data for marketing only when the user has agreed, and respect withdrawal.
• Notice must name the purpose. If phone numbers from a lead form are shared with Meta for ad measurement, say so in plain language.
• Minimise. Send the fields that improve matching, not the whole CRM record.
• Retain deliberately. Tagging server logs contain personal data and need a retention rule.

Our DPDP Act guide for marketers covers consent notices in detail. This is general information, not legal advice.

What does server-side tracking not fix?

It improves data completeness; it does not create consent, repair a broken funnel or prove causation.

• It does not create consent. If a visitor declines marketing tracking, sending their data from a server is still sending it.
• It does not fix a broken funnel. If the CRM never records the sale, there is no event to send.
• It does not make attribution causal. Better matching lets Meta attribute more conversions, but not tell you which ones the ads caused.
• It needs maintenance. API versions change, cloud bills arrive monthly and tags drift as websites are redesigned. Someone has to own it.

Common setup mistakes

• Sending the server event without event_id, so every conversion is counted twice.
• Hashing phone numbers stored as "098470 12345" instead of "919847012345".
• Back-filling CRM sales older than 7 days in one request, which then fails entirely.
• Forwarding personal data for users who declined marketing cookies.

In what order should you implement this?

1. Audit current tags and decide which events matter: usually Lead, qualified lead and Purchase.
2. Fix consent capture and the privacy notice first.
3. Choose the hosting route that matches your team's skills.
4. Generate event_id once, at the source.
5. Send the user_data fields you have consent for, normalised and hashed.
6. Verify deduplication and EMQ in Events Manager over the following week.
7. Add CRM stage events so platforms can optimise for quality, as described in our Meta ads guide.

How we approach this at Old Port

We fix consent and the CRM record before touching tags, because server-side tracking only amplifies whatever data you already collect. We generate one ID per lead or order at the source, choose the lightest hosting route that covers the client's ad platforms, and schedule a monthly health check: server event counts against CRM leads and orders, the deduplication rate and EMQ in Events Manager, and any drop after a website release. Good tracking underpins honest attribution in 2026 and fits into a minimum viable MarTech stack. Our MarTech and automation team builds these setups, and our UAE colleagues apply the same approach through website development in the UAE.