Integration · destination
AdRoll
AdRoll Pixel plus Conversions and Events API.
How events reach AdRoll
Every path ends in the same place: the policy engine checks the consent purpose this destination requires, strips what may not leave, and the worker delivers with the shared event id.
- Browser tag — loaded by the Track snippet after consent; the vendor script never sits in your template and is never loaded without the required purpose.
- Server API — delivered by the worker with retries, health checks, error classification and a redacted payload preview for every attempt.
- Hybrid — browser tag and server request share one event id; the platform deduplicates on event_attributes.order_id.
Vendor prerequisite
What is sent
Only what you configure in the event mapping, and only after the policy engine has allowed the event for this destination.
- Event name and timestamp, mapped from Track's standard events to the platform's event names.
- The shared event id in the platform's event_attributes.order_id field, so browser and server deliveries count once.
- Click ids this platform may receive: adroll_clid. Other vendors' click ids are never forwarded.
- Order id, value, currency and items for purchase-type events.
- SHA-256-hashed identifiers (e-mail, phone, external id) for matching — only with the required consent and only if captured.
- The consent state the event was collected under, where the platform accepts consent signals.
Never sent
- Raw e-mail addresses, phone numbers or names — identifiers are hashed on ingest.
- Inferred values: unknown stays unknown, nothing is guessed.
- Events collected without the purpose this destination requires.
- Secrets: tokens live in the encrypted vault and never reach the browser, the assistant or a log.
Technical facts
- Deduplication field
event_attributes.order_id— event id- Click ids
adroll_clid- Consent purpose
- Marketing
- Pinned API version
s2s-beta- Implementation status
- Implemented · verified against the vendor documentation · verified 2026-09-03
- Vendor documentation
- AdRoll API documentation
What you need
Public identifiers can be typed in chat or the wizard; secrets go through the secure credential card or OAuth and are stored encrypted.
Public identifiers
- advertiser_id
- Advertisable EID
- pixel_id
- Pixel EID
Credentials
- API access token
access_token— stored in the encrypted vault
Consent
Requires the marketing purpose. Without it nothing is loaded in the browser and nothing is sent from the server. Inferred consent is never exported, and Global Privacy Control opt-outs block delivery.
Setup in a few steps
The assistant runs the detailed checks. You see the milestones that need a decision from you.
Enter identifiers
Add the public IDs from the platform. Formats are validated against the vendor's documentation before anything is saved.
Connect credentials
Paste the token into the secure card or connect the account via OAuth. Secrets go straight into the encrypted vault.
Map and test
Standard events are pre-mapped to the platform's event names. A flagged test event runs through the real pipeline and shows the vendor's answer.
Publish
Review the diff, approve, publish a signed configuration version. Roll back with one click if needed.
From Tracking Knowledge
No dedicated article yet — the Tracking Knowledge hub covers server-side tracking, deduplication and consent in general.
Questions
Can I run server-only?
Yes. Choose server mode in the wizard; the vendor script is never loaded and matching relies on hashed identifiers and click ids captured by the tracker.
How are duplicates avoided?
The browser tag and the server request carry the same event id, and purchases add the order id. The worker also deduplicates repeated source events before delivery.
What if the vendor API changes?
API versions are pinned centrally with the verification date; sunset warnings appear in the destination health long before an endpoint is retired.
Connect AdRoll
Set it up with the guided wizard or let the assistant do it in chat.