Which ad stacks clearTag understands, where the enrichment lands in each, and what it is guaranteed never to touch. This list is generated from the adapters running in this build and their live host allowlists — it cannot describe support that is not there.
pubads.g.doubleclick.net, securepubads.g.doubleclick.netEnrichment is merged into cust_params, which is itself a query string URL-encoded inside the tag URL. Your existing keys survive; only the keys clearTag manages are written. ppsj is the documented path to buyers — Google passes it in eligible bid requests to Google demand and to eligible Authorized Buyers, Open Bidding and SDK Bidding partners. The ct_* video parameters are also written, but those are read inside Ad Manager for reporting and demand facilitation, not by external bidders.
search.spotxchange.com, sync.search.spotxchange.comFollows the documented Magnite Streaming integration used by contextual providers. Which c-value a partner's context lands in is assigned by Magnite, so confirm the exact keys with your Magnite rep during onboarding — that is a data edit here, not a code change.
*.fwmrm.net, *.v.fwmrm.netA FreeWheel request is divided into semicolon-delimited sections: global params, key-values, then one per ad slot. Enrichment goes into the key-value section only. caid and csid are keyed identifiers that must match your asset and site-section configuration inside FreeWheel — overwriting them would break ad selection, so clearTag reads them as input signals and leaves them exactly as they arrived.
Your endpoint is not listed? Host matching is a data edit, not a release: an operator
adds it to data/adservers.json and reloads. That covers ad servers that speak one of
the transports above under a different hostname. A genuinely different transport is a new adapter
— roughly a day, and the pipeline around it does not change.
If you do not run tags — if the traffic is already OpenRTB inside your own stack — the tag path is the wrong shape. Call the enrichment API instead: post the bid request's content object and get back the segments, taxonomy and content fields to merge into it. Same resolution, same data, no redirect involved.
POST /v1/enrich
{"content":{"channel":{"name":"Sport1"},"livestream":true},
"device":{"geo":{"country":"DE"}}}
That path runs inside your infrastructure and adds no hop to the auction. It is documented in the API reference, and it is the route for a Prebid Server deployment: a module calls it once per request and every downstream bidder sees the enriched content object.
Identical across every ad server above — only the transport differs. This deployment currently emits:
Each of these is an ad ops decision rather than a technical one, so each is a switch an operator sets per deployment. The IAB taxonomy is the standardised buyer path and is always carried. Try the switches on the bench to see what withholding a signal costs before committing it.