What is server-side enrichment?
Server-side events are reliable but sparse. APlaced Order sent from your backend is guaranteed to fire for every purchase, but it arrives with almost none of the browser context that ad platforms and analytics tools need to match a conversion to a click.
Enrichment is how Converge fills that gap. Once a server-side event is stitched to a profile, Converge automatically adds everything it already knows about that profile to the event. A bare order event inherits the user’s browser identifiers, click IDs, and attribution context, so the data you forward looks as if it had been tracked on the browser all along.
Why it matters
A server-side conversion that can’t be matched to a browser session causes the same downstream problems as an unstitched event:- Lower match rates at your destinations. Meta, Google, and others rely on identifiers like
fbp,fbc, IP address, and user agent to attribute a conversion. Without them, the event is forwarded but poorly matched, which weakens optimization. - Missing attribution. The order can’t be tied to the campaign, landing page, or channel that drove it.
How it works
Enrichment happens automatically at ingestion. There’s nothing to configure, but it does depend on two other concepts: (which stitch the event to a profile) and (which supply the browser context that gets merged in).The event is stitched to a profile
Converge uses the event’s to resolve which profile it belongs to. This is the prerequisite for enrichment: an event that can’t be stitched has no profile to draw context from.
Stored profile data is merged in
Converge looks up the collected earlier in the journey, mostly from browser events, and merges them onto the event.
cart_token or checkout_token alias passed early in the journey matters so much: it’s what links the eventual server-side order back to the browser session that holds all the useful context. For more on choosing reliable aliases, see
What gets enriched
When the Converge Pixel runs on the browser, it stores a set of profile properties automatically. After stitching, these become available on your server-side events:| Property | Description |
|---|---|
$user_agent | The browser’s user agent |
$cookie_id | The Converge first-party cookie identifier |
$screen_resolution | The device’s screen resolution |
$is_mobile | Whether the session was on a mobile device |
$timezone | The browser’s timezone |
$language | The browser’s language |
$fbp and $fbc for Meta, and $gbraid and $wbraid for Google. Any profile properties you pass yourself, like $email, $first_name, or $phone_number, are enriched the same way.
Enrichment only adds data that’s missing. Properties already present on the incoming server-side event are kept as-is, so an explicit value you send always wins over a stored one.
Enrichment and re-identification
Enrichment is also what makes Converge’s longer cookie lifetime useful. Browsers like Safari wipe browser-set cookies after 7 days, but a reliably re-identifies a returning customer for up to a year. When Converge recognizes a returning profile, enrichment restores the third-party cookies stored against it, so destinations can still match the conversion well after the browser would have forgotten the user.Related concepts
Enrichment ties the other source concepts together:- determine which profile an event belongs to. No stitching, no enrichment.
- are the data that gets merged in.
- makes sure an enriched conversion isn’t counted twice.