RFC: audience activation method (Snowflake / LiveRamp / direct API / clean rooms)

[bokelley]

Background

The audience-targeting capability today describes what kinds of identifiers a seller accepts (supported_identifier_types, supported_uid_types, supports_platform_customer_id) but says nothing about how the data moves. AdCP-native sync, TMP identity match, cloud bucket dropoff, vendor-mediated dataset queries, clean room matches — these are the integration realities that determine whether activation is one config switch or three weeks of engineering work for a buyer.

The gap

A buyer with a Snowflake-based audience pipeline and a seller that only takes direct-API audience sync are technically compatible (both speak sync_audiences) and practically incompatible without rebuilding the buyer's pipeline. Today this is discovered at integration time, or worse, at activation time when a campaign starts and audiences don't sync.

Today's nearest fields:

• audience_targeting.supported_identifier_types — kinds of IDs (email, phone).
• audience_targeting.supported_uid_types — UID frameworks (RampID, UID2, MAID).
• audience_targeting.supports_platform_customer_id — platform-native customer IDs.

None answer "where does the data move and how."

Proposed addition

A new audience_activation block on core/product.json and a supported_activation_methods summary on the audience_targeting capability. Each activation method declares a pattern plus pattern-specific fields. Two patterns are AdCP-canonical and first-class; three cover non-AdCP integration realities.

AdCP-canonical patterns (preferred)

sync_audiences — bare. Seller declares "I accept audience pushes via the AdCP sync_audiences tool." Any AdCP-speaking buyer can use it.

tmp_identity_match — declares specific buyer agents the seller integrates with for TMP runtime identity match. Seller must list each buyer agent it has configured. The integration isn't generic; the seller has set up TMP calls to specific buyer agents.

{ "pattern": "sync_audiences" }
{ "pattern": "tmp_identity_match", "buyer_agent": { "agent_url": "https://buyer.scope3.com" } }
{ "pattern": "tmp_identity_match", "buyer_agent": { "agent_url": "https://buyer.interchange.com" } }

Non-AdCP patterns (legacy / vendor-specific)

cloud_bucket — raw cloud storage push or pull. Requires direction and cloud_provider (a BrandRef).

{ "pattern": "cloud_bucket", "direction": "push_to_seller",  "cloud_provider": { "domain": "amazon.com" } }
{ "pattern": "cloud_bucket", "direction": "pull_from_buyer", "cloud_provider": { "domain": "amazon.com" } }
{ "pattern": "cloud_bucket", "direction": "push_to_seller",  "cloud_provider": { "domain": "cloud.google.com" } }

direction is push_to_seller (buyer writes to seller-hosted bucket) or pull_from_buyer (seller reads from buyer-hosted bucket). These have different security/legal posture and aren't interchangeable.

dataset_query — vendor-mediated query access (Snowflake Secure Data Sharing, Databricks Delta Sharing, BigQuery authorized views). Seller queries a dataset the buyer makes available through the vendor's sharing mechanism. Requires vendor (BrandRef).

{ "pattern": "dataset_query", "vendor": { "domain": "snowflake.com" } }
{ "pattern": "dataset_query", "vendor": { "domain": "databricks.com" } }

clean_room — privacy-preserving match. Neither party sees the other's raw rows. Requires vendor (BrandRef). The vendor identifies the clean room product (AMC = amazon.com, Snowflake DCR = snowflake.com, LiveRamp clean room = liveramp.com, etc.).

{ "pattern": "clean_room", "vendor": { "domain": "amazon.com" } }
{ "pattern": "clean_room", "vendor": { "domain": "snowflake.com" } }
{ "pattern": "clean_room", "vendor": { "domain": "liveramp.com" } }
{ "pattern": "clean_room", "vendor": { "domain": "habu.com" } }

Why vendor identity is a BrandRef domain (not an enum)

The schema already uses BrandRef ({ domain, brand_id? }) for vendor identity in measurement reporting ((vendor.domain, vendor.brand_id, metric_id)). Reusing it here:

• New entrants (Alibaba Cloud, OpenAI, Databricks Delta Share, vendor-X clean room) declare a domain and they're in. No spec PR, no enum bottleneck.
• TMP unifies cleanly: a buyer agent's agent_url is the natural identity for tmp_identity_match integrations.
• Verifiable: a vendor's brand.json can attest to its activation role; buyers can confirm declarations.

cloud_provider is a separate slot from vendor because cloud providers (AWS, GCP, Azure) are infrastructure platforms, not products. AMC is vendor: amazon.com because it's a specific Amazon product; raw S3 push is cloud_provider: amazon.com because it's the cloud's storage primitive. The pattern field disambiguates ("Amazon" means different things in clean_room vs cloud_bucket context).

Per-product and per-seller declarations

Per product (core/product.json):

"audience_activation": {
  "methods": [ /* array of activation method entries */ ],
  "preferred_method": { /* optional, single entry */ },
  "notes": "free-text caveats"
}

Required when the product accepts buyer audiences; absent otherwise.

Per seller (get-adcp-capabilities-response.json → audience_targeting):

"supported_activation_methods": [ /* union of per-product methods */ ]

Source of truth is per-product. The seller-wide field is a union for fast-fail discovery: a buyer can read this once and skip the catalog walk if there's no overlap with their pipeline.

Filter integration

Add audience_activation_method to core/product-filters.json so get_products can narrow results to activatable inventory using existing filter infrastructure. No new filter mechanism — just a new key. Sellers exclude products whose audience_activation.methods doesn't intersect the filter; buyers detect via filter_diagnostics.excluded_by.

Validation rules

pattern	required fields	forbidden fields
sync_audiences	(none)	all others
tmp_identity_match	buyer_agent.agent_url	vendor, cloud_provider, direction
cloud_bucket	direction, cloud_provider	vendor, buyer_agent
dataset_query	vendor	cloud_provider, buyer_agent, direction
clean_room	vendor	cloud_provider, buyer_agent, direction

Open questions for WG

1. SFTP / non-cloud legacy paths. Not modeled in this proposal. SFTP doesn't fit cloud_bucket (no cloud provider). Three options: (a) drop entirely, since AdCP sync_audiences is the canonical push and the spec shouldn't bless legacy paths; (b) add a file_transfer pattern with a transport field; (c) document SFTP as out-of-band custom integration with no schema entry. Lean (a).
2. Reporting symmetry. The same pattern + vendor/cloud_provider model maps directly to delivery reporting back to the buyer ("seller pushes reports to buyer's S3" vs "seller publishes via Snowflake share"). Sibling RFC for reporting_method writes itself with the same shape. Should land separately to keep WG agendas tight.
3. Per-pricing-option variance. Activation method may vary by pricing tier (Snowflake share carries data-egress fees). v1 keeps at the product level; revisit if real cases show variance.
4. Identifier-type intersection. A product might support dataset_query for emails but sync_audiences for MAIDs. v1 ignores this; extend audience_activation.methods[] entry to optionally carry identifier_types: [] if real cases need it.
5. Vendor verification. A seller declaring vendor: liveramp.com should be confirmable by reading liveramp.com's brand.json. Out of scope for v1 schema, but worth flagging — same trust model as the broader AdCP vendor pattern.

Out of scope

• Activation pricing (lives in pricing-options).
• Authentication / credential exchange specifics per method.
• Buyer-side spend-uplift preferences ("I'll spend more with sellers supporting X") — separate artifact, lives near buy-terms negotiation.

Related

• audit: align vendor / cloud-provider mentions on BrandRef domain pattern #4330 — schema audit for vendor / cloud-provider mentions across the rest of the spec.

🤖 Generated with Claude Code

[EvgenyAndroid]

Consolidated WG review of #4324 (audience activation method)

Agreed this is a real gap. The current audience_targeting describes identifier compatibility but not activation-path compatibility — a buyer and seller can both "support audiences" and remain practically incompatible if one is built around Snowflake sharing and the other only accepts API pushes.

Suggesting the RFC adopt an explicit five-layer model in its body, since most of the review disagreement on this thread collapses once it's stated:

1. Capability declares what is possible.
2. Account/auth resolves who is allowed.
3. Runtime tasks move the data.
4. Pricing options capture economic variance.
5. Vendor BrandRef identifies who enables the path.

A product declaration carries (1) and (5). It must not carry (2) (buyer-specific onboarding state) or (3) (deployment-time choices). From that, the changes follow:

1. audience_activation absence = unknown / not declared.
Not "default to sync_audiences," not "explicit non-support." Buyers should treat unknown as "needs clarification" rather than silently excluding the product — otherwise we recreate the visibility problem in reverse, where undeclared sellers vanish from filtered queries. Disallow methods: [] in v1 (third state, no use case yet). Field is SHOULD in this version, with a path to REQUIRED in a future major.

**2. tmp_identity_match should be bare — no per-buyer list.**json
{ "pattern": "tmp_identity_match" }
If the seller speaks TMP, the product says it speaks TMP. Whether a specific buyer is onboarded resolves through account setup, auth, sync_accounts, adagents.json, or runtime authorization. Encoding buyer1.com and buyer2.com as separate entries puts a bilateral relationship into a unilateral capability declaration and forces a product schema update for every new buyer.

3. file_transfer with explicit transport, replacing cloud_bucket.
SFTP is common enough that forcing it into cloud_bucket will produce bad declarations. Generalize:json
{
"pattern": "file_transfer",
"transport": "s3",
"directions": ["push_to_seller", "pull_from_buyer"],
"vendor": { "domain": "amazon.com" }
}
Supported transports: s3, gcs, azure_blob, sftp. Once transport carries the storage-primitive signal, the cloud_provider vs vendor distinction collapses — vendor: BrandRef identifies the enabling platform uniformly across all patterns.

4. directions as array, not scalar.
A seller supporting both push and pull shouldn't need duplicate entries. Direction is a deployment choice within a file-transfer path, not a reason to fork the declaration.

5. BrandRef for vendors — strong agree.
Aligns activation with reporting/measurement vendor identity, avoids enum churn, lets new entrants (Databricks Delta, future clean rooms) declare a domain without a spec PR. #4330 is the right follow-up.

6. Filter semantics need to be explicit in the RFC.
Without this the field will be interpreted inconsistently:

• OR across requested methods — buyer asking for ["sync_audiences", "tmp_identity_match"] matches sellers supporting either.
• AND within a method object — every specified field on a method must match.[2:01 PM]- Omitted fields as wildcards — buyer not specifying transport matches any transport.
• directions matching by intersection — non-empty overlap matches.
• Methods array as unordered OR set of independent activation options.

7. Per-pricing-option variance: optional override.
Product-level audience_activation is the default; pricing options may override when activation method materially changes economics (clean-room compute, dataset-query egress). Don't require it where it doesn't vary (sync_audiences, tmp_identity_match are typically uniform once available).

Sibling RFC for delivery reporting back to buyers — the same shape transfers cleanly. Worth being explicit they're parallel-structured but separate (different lifecycle, different consent posture).

Pre-req flag: vendor verification via brand.json only works for vendors that publish brand.json. Worth calling out in the RFC as a dependency, not a current capability.

— Evgeny Popov (No Fluff Advisory) @EvgenyAndroid and Addie

[bokelley]

Triage

Classification: RFC
Bucket(s): spec / protocol, signals
Status: ready-for-human — WG review received; two design decisions remain for @bokelley

What the experts said:

• ad-tech-protocol-expert: Revisions on directions array, BrandRef, filter OR/AND semantics, and sibling RFC split are sound. Two blockers: (a) bare tmp_identity_match omits the uid_types/countries/agent_url data that trusted_match.providers[] already carries — buyers need a normative discovery path; (b) SFTP cannot share the same required fields as S3/GCS/Azure Blob (bucket/prefix/region vs. host/port/remote_path) — needs a oneOf discriminated by transport, not a flat enum. Absence filter semantics resolved by existing convention: RFC must add "sellers MUST exclude products where audience_activation is absent when audience_activation_method filter is specified" — same as required_vendor_metrics.
• adtech-product-expert: Bare tmp_identity_match is a blocker — strips the per-buyer TMP compatibility signal buyers use at product selection; pushing discovery to auth/adagents.json/runtime reintroduces the three-week integration surprise. SFTP concern mirrors protocol analysis. Per-pricing override is real but v2 — an ext hook covers v1.

My take: The WG resolves five of seven points well — incorporate directions as array, BrandRef uniformity, filter OR/AND semantics (with explicit wildcard/required-field distinction in spec text), sibling RFC split, and per-pricing as v2 with an ext hook. Two points need @bokelley's call before the RFC can proceed to draft.

---

Decision 1 — tmp_identity_match: keep buyer_agent or go bare?

The WG's 5-layer model is correct that per-buyer onboarding is layer 2 (account/auth), not layer 1 (capability). The problem is that buyers need layer-1 signal about which specific buyer agents a seller has wired — and that signal is already in trusted_match.providers[]. Option A preserves that at activation declaration time; Option B requires a normative pointer to a different schema surface.

Option A — keep buyer_agent (original RFC design):

{ "pattern": "tmp_identity_match", "buyer_agent": { "agent_url": "https://buyer.dsp.com" } }

Buyer filters on their own agent_url at get_products time. Matches trusted_match.providers[].agent_url shape already in product.json.

Option B — bare declaration + normative pointer:

{ "pattern": "tmp_identity_match" }

RFC must add: "Buyers determining per-buyer TMP readiness MUST consult trusted_match.providers[] for uid_types, countries, and agent_url registration." Reduces product-schema churn per new buyer relationship; shifts discovery to a different protocol surface buyers may not be consulting during product selection.

---

Decision 2 — file_transfer: discriminated oneOf or drop SFTP from v1?

The WG's flat transport enum (s3 / gcs / azure_blob / sftp) conflates two structurally different protocol families. S3/GCS/Azure Blob are bucket-addressed (bucket, prefix, region, IAM). SFTP is session-oriented (host, port, remote_path, auth_method). The existing cloud-storage-protocol.json enum excludes SFTP for this reason.

Option A — discriminated oneOf (transport as discriminator):

{ "pattern": "file_transfer", "transport": "s3",   "vendor": { "domain": "amazon.com" },    "directions": ["push_to_seller"] }
{ "pattern": "file_transfer", "transport": "sftp",  "host": "sftp.seller.com", "port": 22,   "directions": ["pull_from_buyer"] }

Covers SFTP in v1; schema correctly branches on transport with distinct required fields per variant.

Option B — drop SFTP from v1, flat enum:

{ "pattern": "file_transfer", "transport": "s3",        "vendor": { "domain": "amazon.com" } }
{ "pattern": "file_transfer", "transport": "azure_blob", "vendor": { "domain": "microsoft.com" } }

Simpler v1 schema; SFTP enters as a separate pattern or via ext in v2. Matches the existing cloud-storage-protocol.json precedent.

---

On absence semantics: No decision needed — existing filter convention resolves it. RFC text should add one MUST statement (see protocol expert above). The seller-level exhaustiveness signal the product expert suggests is a reasonable future addition but not a v1 blocker given the MUST-exclude rule.

@bokelley — two calls: (1) buyer_agent vs. bare TMP, (2) discriminated oneOf vs. drop SFTP from v1. The rest of @EvgenyAndroid's WG synthesis is sound and ready to fold in.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_0169Rz6uAjQrdW5GRkQXofDo

---

Generated by Claude Code