Conversion forwarding
Give Meta and Google the conversions they are missing.
Ad platforms optimise on the conversions they can see. Quantiv sends them the ones the pixel misses, server-side and deduplicated, and makes sure nothing sensitive goes with them.
Delivery ledger
last 4 deliveries
| Order | Destination | Matched on | Status |
|---|---|---|---|
| ord_88213 | Meta CAPI | email · fbc | delivered |
| ord_88213 | Google EC | email · gclid | delivered |
| ord_88207 | Meta CAPI | deduplicated | |
| ord_88199 | Google EC | - | retrying |
Every delivery is recorded, deduplicated against the pixel, and retried until it succeeds or is explicitly dropped.
Illustrative data
Why it matters
The case for server-side conversions.
20-40%
+15-30%
48% → 72%
How it works
From your event store to the ad network.
- 01
Deduplicate
Server-side conversions are matched against pixel events so each purchase is counted once.
- 02
Filter
The egress filter checks every property's classification. Only allowlisted identifiers leave, hashed. PHI never leaves.
- 03
Deliver
Conversions are sent to Meta Conversions API and Google Enhanced Conversions.
- 04
Record and retry
Every delivery is logged in a ledger and retried until it succeeds or is explicitly dropped.
Egress filter
Forwarding that knows what is sensitive.
Meta and Google prohibit health and other sensitive data in conversion uploads, and regulators enforce it. A platform that forwards everything it receives puts the brand at risk.
Quantiv's filter is driven by the classification in your taxonomy. It is not a review step that can be skipped. A property classified PHI has no path out.
- Allowlisted identifiers only, hashed before they leave
- PHI-classified properties are never eligible
- Consent signals travel with each event
Egress filter · purchase
→ Meta CAPI
- order_idforwarded
- order_valueforwarded
- emailPIIhashed
- gclidforwarded
- condition_codePHIblocked
A property classified PHI is not forwardable. Not by policy, not by a reviewer remembering - the filter has no path that lets it leave.
Illustrative data
Delivery ledger
Every delivery accounted for.
The ledger shows what was sent, where, matched on which identifiers, and what happened. When something fails, the signal health agent groups the failures and proposes the fix.
Delivery ledger
last 4 deliveries
| Order | Destination | Matched on | Status |
|---|---|---|---|
| ord_88213 | Meta CAPI | email · fbc | delivered |
| ord_88213 | Google EC | email · gclid | delivered |
| ord_88207 | Meta CAPI | deduplicated | |
| ord_88199 | Google EC | - | retrying |
Every delivery is recorded, deduplicated against the pixel, and retried until it succeeds or is explicitly dropped.
Illustrative data
Questions
Common questions.
Will this double count conversions?
No. Server-side conversions are deduplicated against pixel events before delivery, using the identifiers each network expects.
We are a health brand. Can we forward conversions at all?
Yes, within the limits the networks and regulators set. The egress filter forwards only allowlisted, hashed identifiers and never forwards anything classified PHI.
What happens if a network rejects a delivery?
It is recorded in the ledger and retried. Persistent failures are grouped by the signal health agent with a probable cause and a proposed fix.
See it on your own numbers.
A two-week pilot runs your conversions through Quantiv alongside what you report today. The difference between the two is the business case.