---
title: "Conversions API: What It Delivers and What It Replaces"
description: "What a Conversions API sends, how pixel and server events get deduplicated, and which reporting problems server-side tracking does not fix."
canonical: https://adsbeast.pro/blog/en/conversions-api-what-it-delivers-and-what-it-replaces
language: en
published: 2026-10-15T00:08:30.504Z
updated: 2026-10-15T00:08:30.504Z
author: "ADS Beast editorial team"
translations:
  - ar: https://adsbeast.pro/blog/ar/conversions-api-what-it-delivers-and-what-it-replaces
  - es: https://adsbeast.pro/blog/es/api-de-conversiones-de-meta-que-aporta-y-que-no-reemplaza
  - he: https://adsbeast.pro/blog/he/conversions-api-what-it-delivers-and-what-it-replaces
  - pl: https://adsbeast.pro/blog/pl/api-konwersji-co-daje-i-czego-nie-zastepuje
  - ru: https://adsbeast.pro/blog/ru/api-konversiy-chto-dayot-i-chego-ne-zamenyaet
  - sk: https://adsbeast.pro/blog/sk/conversions-api-co-prinasa-a-co-nenahradza
  - uk: https://adsbeast.pro/blog/uk/api-konversiy-shcho-daye-i-chogo-ne-zaminyuye
---
# Conversions API: What It Delivers and What It Doesn't Replace

A Conversions API sends events from your server to an ad platform, so a purchase or lead reaches the platform even when the browser pixel fails. It improves which events arrive and how well they match to a person. It does not replace the pixel, and it does not decide how credit for a conversion is assigned.

## In short

- A Conversions API is a server-to-server path that reports events your backend already records, with identifiers the platform uses to match them to a person.
- The browser pixel and the server call describe the same action, so the platform needs matching event names and event IDs to count them once.
- Deduplication is not a setting you switch on. Meta matches on event name plus event_id; Google Ads matches a repeated conversion action on the same transaction or order ID.
- Server events carry what your backend knows. The browser still supplies page context, click identifiers stored on the device, and consent signals.
- A lower conversion count in the ad platform is a hypothesis about deduplication, not proof of it.

## What a Conversions API sends, and why the pixel alone misses events

A Conversions API is a server-side integration that sends event data from your own infrastructure to an ad platform, describing actions such as a purchase, a lead, or a signup. The payload pairs the event with identifiers that help the platform match it to a person. That is the whole idea: the event leaves your backend instead of waiting for a browser to finish something.

The browser pixel has a specific weakness. It runs in a page, and a page can be closed, blocked, or interrupted before the request goes out. A cookie can be missing or expired. When that happens, the action still occurred in your system, but the platform never hears about it. A server call does not depend on the browser completing anything, which is why it catches events the pixel drops.

This matters most for actions that finish away from the page. A purchase confirmed by a payment provider, a subscription renewal, a lead qualified later by a sales team, an offline deal recorded in a CRM. Those events exist in your database and nowhere in the browser. Sending them server-side is the only way the platform sees them at all. If you are still chasing missing browser events, the fixes in this [Meta Pixel troubleshooting checklist](/blog/en/meta-pixel-not-firing-troubleshooting-checklist) come before any server work.

## Does a Conversions API replace the browser pixel?

No. The two paths carry different information, and the standard setup runs both.

The server knows what your backend records: order value, currency, customer identifiers, the stage a lead reached. The browser knows things the server never sees, including which page the person was on, the click identifiers stored on the device, and the consent signals that govern what you are allowed to send. Drop the pixel and you lose that context. Match quality usually gets worse, not better.

The practical rule is consistency. The same event name and the same event ID must travel through both paths so the platform can recognize one action rather than two. That is the entire purpose of running them together.

| What you need | Browser pixel | Conversions API |
|---|---|---|
| Events that fire on a page | Yes, if the page finishes loading | Yes, if your backend records them |
| Events that finish off-site (refunds, CRM stages, renewals) | No | Yes |
| Page context and device-stored click identifiers | Yes | No |
| Consent signals | Yes | Depends on what you pass |
| Survives a blocked or closed page | No | Yes |
| Deduplication key | event name plus event ID | event name plus event ID |

## How pixel and server events get deduplicated

Deduplication happens when the platform can tell that two records describe one action. You make that possible by generating an identifier and passing it through both paths.

For Meta, including the Meta Conversions API, the match is on the event name together with an event_id you generate. There is no switch in the ad account that turns deduplication on or off, so the identifier is the only control you have. If the browser event and the server event carry the same name and the same event_id, the platform treats them as one.

For Google Ads, a repeated conversion action is deduplicated when the transaction or order ID is the same. That consistent ID has to be present in the browser tag and in the server upload. Two things follow from this. First, an identical ID does not merge two different conversion actions; it only prevents the same action from being counted twice. Second, Google supports consistent sources rather than a single mandatory one, so you are not forced to choose between browser and server.

A working sequence:

1. Pick the events you will send from both paths, and give them identical names.
2. Generate a unique ID per action in your backend, and use the order or transaction ID where the platform expects one.
3. Pass that ID into the browser tag and into the server call for the same action.
4. Log what you sent, from which path, with which ID. Without that log you cannot diagnose a mismatch later.
5. Compare the platform's received events against your own records before you change anything else.

The Facebook Conversions API and the Meta conversion API are the same integration under two names, and the same identifier discipline applies to a Shopify Facebook Conversions API setup: the platform does not care which system generated the ID, only that both paths carry it.

## Why a lower conversion count is not proof of deduplication

A lower number in the ad platform is a hypothesis, not evidence. The same drop can come from a broken event, a changed identifier, a shifted attribution window, or a reporting change.

Consider the window alone. Google Ads conversion windows run 30 days by click by default and can be set from 1 to 90 days. Change that setting and reported totals move without anything about your tracking changing. An event that stops firing produces the same visible effect as successful deduplication. So does a renamed parameter, or a consent banner that starts blocking a signal it used to pass.

To tell these apart, check three things in order. First, the events the platform actually received, not the totals in the report. Second, the identifiers and event IDs across both paths, to confirm they line up. Third, your own backend records for the same period. If the platform's received events match your backend and the totals are lower than before, deduplication is a reasonable explanation. If the received events are missing, you have a tracking break, not a fix.

## What server-side events do not fix about attribution

They improve which events reach the platform. They do not decide how credit for a conversion is assigned.

Attribution still depends on the platform's model and its window, and on how you label conversion actions. In Google Ads, primary and secondary actions determine what enters the Conversions column and what feeds bidding, while secondary actions appear in All conversions. Custom goals follow their own rules. Because of that, separate actions for one purchase can distort the total. The presence of two sources by itself does not prove double counting, and the absence of a jump does not prove clean deduplication.

The reliable check is reconciliation. Put your order or CRM data next to the platform's numbers and explain the difference before you trust either figure. If you route leads through a CRM, the same discipline applies to the identifiers you carry through: [UTM tagging that survives to the CRM card](/blog/en/utm-tagging-that-survives-to-the-crm-card) covers how those values stay attached to a record instead of being lost between the form and the deal.

## Where the server path fits in your tracking stack

The server path is one layer, and it sits between the browser and your reporting.

Below it, the browser still needs clean campaign parameters so the click is attributed to the right source. Above it, your analytics and CRM need to receive the same events with the same identifiers. A server integration that sends events but leaves the campaign parameters broken produces accurate event counts attached to the wrong traffic. [UTM link tracking for a minimal end-to-end setup](/blog/en/utm-link-tracking-minimal-end-to-end-analytics-setup) is the layer that keeps source data intact, and a correct [campaign link built with a UTM builder](/blog/en/utm-builder-how-to-create-the-right-campaign-link) is what makes that layer readable later.

If calls are part of your funnel, they need the same treatment. A phone lead that never becomes an event in the platform is invisible to bidding, no matter how well the server integration works for web actions. [Call tracking that links calls to campaigns](/blog/en/call-tracking-how-to-link-calls-to-campaigns) explains how those calls get attached to a source.

Server-side conversion work is also where a tool earns its place. If you want the events from your CRM stages to reach your ad accounts without building the integration yourself, the tracking features described on the [server-side conversion tracking page](/features/en/tracking) cover that path along with budget control and reporting.

## What to check before you call the integration done

Completion is not a successful deployment. It is a set of verifiable conditions.

- Every event you send has a name and an ID that both paths carry identically.
- Your backend log of sent events matches the platform's received events for the same period.
- Conversion actions are labeled deliberately, so you know which ones feed bidding and which only report.
- The attribution window is a decision you made, not a default you inherited.
- Consent handling is consistent across both paths, so you are not sending server-side what the browser was told not to send.

If any of these is unverified, the integration is running but unproven. That distinction matters more than the count in the report.

## Next step

Take one conversion action, the one that matters most to your revenue, and trace it end to end: find the event ID in your backend, confirm the same ID arrives from the browser and from the server, and compare the platform's received events against your own records for the last full attribution window. If you would rather not build that comparison by hand, start with the server-side tracking setup and let the platform side of it be handled.

## Questions and answers

### What does a Conversions API actually send to an ad platform?

It sends server-side events: a purchase, a lead, a signup, whatever your backend already records, along with identifiers that help the platform match that event to a person. The browser pixel can be blocked, lose the cookie, or never fire if the page closes early; a server call from your own infrastructure does not depend on the browser finishing anything. Both paths describe the same action, so the platform needs a way to recognize them as one event rather than two.

### How does a platform deduplicate a pixel event and the same server event?

By event name plus an event ID that you generate and pass through both paths. Meta matches on the event name and event_id, and there is no switch in the ad account that turns deduplication on or off. Google Ads deduplicates a repeated conversion action when the transaction or order ID is the same, and that consistent ID has to be present in the browser tag and the server upload. If the IDs differ or one path omits them, the platform has no reason to treat the two records as one.

### Does a Conversions API replace the browser pixel entirely?

No. Server events carry what your backend knows, while the browser still supplies context the server never sees, such as the page, the click identifiers stored on the device, and consent signals. Running both with matching event names and IDs is the standard setup, not a fallback. Dropping the pixel usually costs you match quality rather than improving it.

### Can I prove deduplication worked just by watching the conversion count drop?

No. A lower number in the ad platform is a hypothesis, not evidence, because the same drop can come from a broken event, a changed identifier, a shifted attribution window, or a reporting change. Check the events actually received, confirm the identifiers and event IDs line up across both paths, and compare against your own backend records. Google Ads conversion windows run 30 days by click by default and can be set from 1 to 90, so a window change alone moves reported totals.

### Will server-side conversions fix my attribution and reporting?

They improve which events reach the platform; they do not decide how credit is assigned. Attribution still depends on the platform's model and window, and on how you label conversion actions: primary and secondary actions determine what enters the Conversions column and what feeds bidding, while secondary actions show up in All conversions. Separate actions for one purchase can distort the total, but two sources by themselves do not prove double counting. Reconcile against your own order or CRM data before trusting any single number.