Server-side Meta Conversions API: what it actually changes

What CAPI does differently

The Conversions API sends events from your server directly to Meta's API, bypassing the browser entirely. When a customer converts, your server fires the event — with no browser involvement, no tracker to block, no data missing.

The result is a more complete picture of who's converting. And because Meta's targeting algorithm is trained on conversion data, a more accurate conversion signal means better targeting over time — not just better numbers in Events Manager.

This is the part most CAPI implementations miss: the benefit is not the reporting. It's what the algorithm does with better data over the following weeks as it relearns the audience that actually buys.

The architecture: both, not either

The common mistake is replacing the browser pixel with CAPI. The correct architecture is running both simultaneously.

The pixel handles what it handles — it fires immediately on page events, captures first-party cookies, and sends click IDs. CAPI fires from the server for every conversion, regardless of browser state. Meta deduplicates using the event_id field, so the same conversion doesn't get counted twice.

Belt and suspenders: if the pixel fires and CAPI fires, Meta gets the event once with the best available data. If the pixel is blocked, CAPI still fires and the conversion is captured.

// Server-side CAPI event (Node.js)
const { Facebook } = require('facebook-nodejs-business-sdk');

async function sendConversionEvent(req, purchase) {
  const userData = new Facebook.UserData()
    .setEmail(hash(purchase.email))
    .setPhone(hash(purchase.phone))
    .setClientIpAddress(req.ip)
    .setClientUserAgent(req.headers['user-agent'])
    .setFbc(req.cookies._fbc)
    .setFbp(req.cookies._fbp);

  const customData = new Facebook.CustomData()
    .setValue(purchase.total)
    .setCurrency('EUR')
    .setOrderId(purchase.id);

  const event = new Facebook.ServerEvent()
    .setEventName('Purchase')
    .setEventTime(Math.floor(Date.now() / 1000))
    .setEventId(`purchase_${purchase.id}`)  // for deduplication
    .setUserData(userData)
    .setCustomData(customData)
    .setActionSource('website');

  const eventsData = [event];
  const eventRequest = new Facebook.EventRequest(PIXEL_ID, eventsData);
  await eventRequest.execute();
}

The fields that actually move the dial

Not all CAPI fields have equal impact on match quality. In order of importance:

Hashed email is the strongest identifier. If you have it at conversion time — which you do for any logged-in purchase — send it. It's consistently the highest-impact field.

fbc and fbp cookies — Meta's click ID and browser ID cookies — are critical for connecting CAPI events back to ad clicks. They need to be read server-side before the event fires, which means your server needs access to the first-party cookies set by the pixel.

IP address and user agent are weaker individually but meaningful in aggregate, especially for matching anonymous browsing sessions.

Phone number matters if your acquisition channel is phone-based. For most web purchases, email dominates.

The Event Match Quality score in Meta's Events Manager (0–10) reflects how much of this data you're including and how cleanly it's formatted. Scores above 7 typically indicate a solid implementation. Below 5 suggests missing fields.

The timeline for results

CAPI doesn't improve results on day one. The Meta algorithm needs time to relearn the conversion audience with the corrected, more complete data signal.

In practice, meaningful targeting improvements show up in 3–4 weeks as the model updates its audience profile. You'll typically see it as a gradual improvement in conversion rate at the campaign level — the algorithm is showing your ads to people who more closely resemble the corrected conversion data rather than the noisy, incomplete data it was working with before.

The way to measure it: compare the conversion audience (from CAPI) to the audience your campaigns were targeting before implementation. If they're different, the algorithm was working from bad data.