AdCP, the Ad Context Protocol published by AgenticAdvertising.org, handles audience data through two separate routes. Data a buyer owns, such as a customer list, goes to a seller through sync_audiences as hashed identifiers that the seller matches against its own users. Data a buyer does not own, from data providers, retailers or publishers, is treated as a signal: a buyer agent discovers it with get_signals and pushes it to a DSP or sales agent with activate_signal.

TL;DR. According to the AdCP documentation, audiences are data a buyer owns and uploads, while signals are named targeting dimensions defined by others. First-party lists travel hashed, are matched on the seller side and are scoped to one seller account. Third-party signals are published by data providers in an adagents.json file, so a buyer can check that a signal agent is authorised to resell them. AdCP specifies what each task carries, not consent capture, retention or data-subject rights, which stay with the parties and their contracts.

What is the difference between an audience and a signal in AdCP?

An audience in AdCP is a list the buyer owns and uploads; a signal is a targeting dimension someone else defines, found through a seller's product options, a provider's published definitions or get_signals.

The distinction is enforced in the media buy itself. A synced audience is referenced in create_media_buy through audience_include or audience_exclude in the package targeting overlay. A signal belongs in signal_targeting_groups, and the documentation tells implementers not to copy a signal identifier into the audience fields. Audience IDs are scoped to the seller account, so a list matched by one seller cannot be reused at another.

How does sync_audiences bring first-party data into a buy?

sync_audiences lets a buyer agent upload hashed customer lists to a seller account, check matching status and then use the result for targeting or suppression. Each member needs a buyer-assigned external_id plus at least one matchable identifier: a SHA-256 hash of a normalised email address, a hash of a phone number in E.164 format, or a universal ID. The schema does not accept cleartext email or phone.

Matching is asynchronous and, according to the AdCP documentation, takes from one to 48 hours depending on the seller. Each audience moves through processing to either ready or too_small. A seller must report too_small whenever the matched count falls below its minimum, rather than returning ready on an audience that cannot be targeted.

Lookalike expansion is requested in the campaign brief, and the documentation notes that lookalike intent cannot be verified through the protocol, only through seller-side reporting. An experimental option lets the seller read the list from a shared dataset instead, so member data never passes through AdCP.

How do get_signals and activate_signal work?

get_signals is discovery. A buyer agent describes what it needs in natural language, or looks signals up by reference, and the signal agent searches across the data-provider signals it is authorised to resell and its own. Each result states a value type (binary, categorical or numeric) and can include pricing options, a coverage forecast and whether the signal is live on each requested destination.

activate_signal is delivery. The buyer names a destination, either a platform such as a DSP or a sales agent, and the signal agent pushes segment membership there and returns an activation key for targeting. Activation can take minutes to days. The request carries the selected pricing option, which the documentation describes as recording the buyer's pricing commitment at activation time, and an idempotency key prevents duplicate activations on retry.

Signal activation counts as a spend commitment, so on accounts with a registered governance agent the buyer must call check_governance first, and the signal agent must reject an activation without valid approval. activate_signal can also deactivate a signal, which the documentation says removes segments from downstream platforms for data governance purposes.

What does a combined campaign look like?

Consider a hypothetical home insurer running an acquisition campaign. Its buyer agent uploads existing policyholders through sync_audiences and, once the audience is ready, places it in audience_exclude so current customers are suppressed. It then calls get_signals for people who have recently moved house, checks the provider's adagents.json, activates a numeric propensity signal on the insurer's DSP, and the campaign targets scores above a chosen threshold. If cost per acquisition drifts, the agent deactivates the signal without touching the suppression list.

What does the signals protocol mean for data providers and publishers?

For data providers, the mechanism is a published catalogue. A provider lists its signal definitions in /.well-known/adagents.json on its own domain, the same file publishers use to declare inventory, and authorises signal agents either by signal ID or by tag. Buyers can then check authorisation at the source instead of trusting the intermediary.

Definitions can also declare governance metadata. restricted_attributes names any GDPR Article 9 special categories a signal touches, such as health data, and policy_categories flags regimes such as children_directed, so a governance agent can block a signal without guessing from its name. When a seller passes on another provider's declared consent_basis, the specification says it must not substitute its own.

For publishers, the ecosystem guide suggests they can add contextual and subscriber signals, such as content category or engaged readers, to the same adagents.json. Publishers that sell inventory also receive buyers' synced audiences, and the privacy guidance notes that a seller may be a controller for its own inventory data and a processor for buyer-scoped campaign data.

IAB Tech Lab's AAMP framework covers similar ground through its own agentic-audiences component, so buyers working across both should ask vendors which they support and at which version.

What privacy and control questions should buyers ask?

AdCP's privacy reference describes a wire protocol that does not specify consent capture, data-subject rights workflows, residency or retention; for Media Buy and Signals, confidentiality rests on contractual terms rather than protocol-level separation. The documentation also states that unsalted hashed emails and phone numbers are pseudonymous personal data, not anonymous. None of this is legal advice; these are questions to put to counsel, sellers and signal agents:

What is the lawful basis for each uploaded audience, and is it passed in consent_basis where the seller requires it?
What does the seller's data processing agreement say about retention and deletion of uploaded hashed data?
Does the data provider's adagents.json list this signal agent, and where do data-subject requests for the signal route?
Does the signal definition declare restricted attributes or policy categories, and does the campaign plan check them?
When a signal is deactivated, how are removal and the end of billing confirmed on each destination?
Which model providers process the brief and audience data, and may they retain it or train on it?

Those questions settle who a campaign may reach. What both parties agreed to buy is a separate record. Alkimi's marketplace is neutral: it works within IAB Tech Lab's AAMP framework today and is being built to be AdCP compatible, and agreed deals sit on a shared DealSheet both parties hold, with humans keeping approval rights at the deal level.

Frequently asked questions

What does sync_audiences do in AdCP?

It uploads a buyer's hashed first-party customer lists to a seller account, reports matching status, and lets the buyer reference the matched audience for targeting or suppression in a media buy with that seller.

Can a buyer verify where a third-party signal comes from?

Yes, for provider-published signals. The buyer fetches the data provider's adagents.json and checks that the signal exists and that the signal agent appears among its authorised agents.

Is hashed email data anonymous under AdCP?

No. The AdCP documentation states that unsalted hashed emails and phone numbers are pseudonymous personal data and must be treated as personal data for consent, retention and access requests.

Does AdCP capture consent?

No. According to the AdCP documentation, consent capture, data-subject rights, residency and retention sit outside the protocol. It does carry a consent_basis field so a buyer can tell a seller the GDPR lawful basis for an audience.

How Does AdCP Handle Audiences and Signals?