Is the Meta-enabled Conversions API enough?

An option in Meta's Events Manager, announced on April 15, 2026. Meta describes it as a one-click setup, with no technical skills and no cost. It creates a server-side connection that passes your web data to Meta in addition to your pixel.

Three points, all written by Meta:

• it is on by default: Meta says it will turn on the Meta-enabled Conversions API for all the datasets of your Business ID. So you may already have it without having chosen it;
• it covers only the web: no mobile app, no in-store sales;
• it cannot be tuned: the events and information sent are the pixel's, deduplicated automatically with it. You choose neither.

Everything your pixel does not see. Meta indicates that the pixel is the only resource needed, and that what is sent is what the pixel shares. In practice, if the pixel does not load, there is nothing to pass on:

• an ad blocker that keeps the pixel script from loading;
• a cookie banner that blocks the pixel until the visitor has accepted;
• a buyer who closes the tab before the confirmation page has finished loading;
• a sale confirmed later by your server: payment validated after the visitor has left, a bank transfer received the next day. The browser is gone, and so is the pixel.

Meta itself writes that data sent through the Conversions API is less affected than the pixel by loading errors, connection problems and ad blockers. That is true of a send that really starts from your server. A version that copies the pixel inherits its gaps.

Meta's gateway (Conversions API Gateway), the other no-code option, works the same way: the pixel sends it the events, and you host it on your own AWS or Google Cloud account.

A send from a server does not let you get around a refusal. Meta says it: the Conversions API is not designed to circumvent European privacy rules, such as the ePrivacy Directive.

Oriva does not either: without the visitor's consent for advertising, Oriva sends nothing to Meta. A tool that promises to recover the sales of visitors who refused is promising you something illegal.

Three things, and only these:

• the sales the browser does not see. A sale confirmed by your server goes out from your server, whether or not a pixel loaded;
• fewer losses at load time. Oriva's script is served from a subdomain of your site (for example t.yourstore.com), not from a known advertising domain. Blocklists that target Meta's domains do not touch it. That does not make it invisible to every blocker;
• one installation for all your platforms, with proof of each send and the reason for each failure in a log.

What it does not change: visitors who refused advertising. See above.