Two builds, not one
It is easy to conflate "capture the agent sale" with "tell my ad platform about it" - they are different problems with different failure modes. Capturing the event server-side, including the true zero-JS API-only case, is covered on Capturing agent checkout via CAPI and is a prerequisite for everything on this page. This page is the second half: once you have a conversion event, in what shape does it need to reach Meta, Google, or TikTok for their systems to do anything useful with it.
Delivery and attribution are also distinct. Delivering a conversion event tells the platform an event happened, for reporting and optionally for bidding optimization. Attribution - crediting that revenue to a specific channel, campaign, or touchpoint in a broader model - is a modeling question covered on agentic commerce attribution (ecomm.webclat.com). A conversion can deliver cleanly and still not attribute to anything, which is the matching problem below.
The matching problem specific to agent conversions
A standard CAPI or Enhanced Conversions event matches against one of two things: a click ID from a paid ad click (gclid, fbclid, ttclid), or hashed personal identifiers (email, phone) the platform can match against its own signed-in user data. Agent-referred conversions frequently arrive with neither in the form a platform expects:
- If a shopper reached you because an agent surfaced or recommended your product in a conversational answer, with no underlying paid ad click, there is no click ID to send - full stop. The event can still deliver (see below), but the platform has nothing paid-media to credit it to in its own attribution view.
- If the agent's recommendation itself originated from a paid feed - a Google Shopping listing an agent surfaced, for instance - check whether the redirect link preserved the click ID before assuming it was lost. [hypothesis, not verified against a live redirect chain] it depends entirely on whether the agent's redirect mechanism forwards query parameters; some do, some strip them.
- For the true API-only checkout path (see /capi/agent-checkout for what qualifies), you are matching purely on hashed order-record identifiers - whatever email or phone was captured as part of the payment mandate or account setup, nothing more.
Platform notes (delivery mechanics, not re-explained here)
The install-consent-gate-dedupe-verify framework and the platform-specific setup for each of these already live on the CAPI service overview and its platform pillars - this section covers only what changes when the event is agent-driven.
| Platform | Delivery path | What changes for an agent event |
|---|---|---|
| Meta | Conversions API (see /capi/meta-conversions-api.html) | Same endpoint, same dedupe rule when a pixel exists. Attach a custom event parameter to flag the event as agent-referred for your own reporting - Meta's own optimization does not natively distinguish it. |
| Enhanced Conversions (GTM/GA4) or offline conversion import via the Google Ads API | Enhanced Conversions for Leads does not require a click ID; standard Enhanced Conversions for Web still prefers one when available. Offline import is the more reliable path for the true API-only checkout case, since it is built for exactly this kind of delayed, click-ID-less match. | |
| TikTok | Events API (see /capi/tiktok-events-api.html) | Same server-first delivery pattern as Meta; no native agent-conversion distinction here either as of this writing. |
Dedup rules carry over from the capture layer
If the underlying sale went through a redirect-completed browser checkout, the standard pixel-plus-CAPI dedup rule applies unchanged (see /qa/capi-pixel-dedupe-not-working.html for the exact event_id mechanics). If it was a true API-only agent transaction, there is no pixel-side event to deduplicate against - sending both a server event and a synthetic client event to "match" it creates a phantom double-count, not a correctly deduplicated pair. Getting this backwards is exactly the failure mode covered on agent events double-counting: pixel + CAPI dedup (gtm.webclat.com).
How to verify it worked
- Confirm the event appears in the platform's own event diagnostics carrying whatever custom parameter or separate custom-conversion action you used to flag it as agent-driven - if you did not tag it, you cannot separate it from ordinary CAPI volume later, and this is the most common gap we see.
- Reconcile total delivered-conversion count against your own backend's count of agent-attributed orders for the same window, not against the platform's own campaign-attributed total, which will legitimately be lower for click-ID-less events.
- For redirect-completed sales specifically, spot-check whether the click ID (where one should exist) actually survived the agent's redirect - a silent drop here looks identical to "the agent doesn't send traffic," the exact miscount this cluster exists to correct.
- Once delivery and dedup both check out, move the question up a level to whether the resulting numbers actually change a spend decision - that is the attribution-modeling layer on ecomm.webclat.com, not this page.