automation

From Deal IDs to Intent APIs: A Sell-Side Blueprint for Programmable PMPs

A practical, expert blueprint for SSPs and publishers to evolve Private Marketplaces from static deal IDs to programmable, intent-driven APIs for web, app, and CTV.

From Deal IDs to Intent APIs: A Sell-Side Blueprint for Programmable PMPs

From Deal IDs to Intent APIs: A Sell-Side Blueprint for Programmable PMPs

Private Marketplaces solved a real problem. Buyers needed premium supply, brand safety, and predictable delivery without the chaos of the open exchange. Sellers needed higher yield and relationship control. But most PMPs are still hand-built, static, and surprisingly fragile. The market has outgrown spreadsheets and ad hoc trafficking. This piece proposes a sell-side blueprint to move PMPs from static deal IDs to programmable, intent-driven APIs. The aim is practical. We will define the architectural components, data standards to lean on, product design guardrails, and the operational playbook that SSPs and publishers can adopt now. Along the way, we will connect the dots across OpenRTB, Curated Audiences, PAIR, PPS, sellers.json, and CTV-specific deal mechanics. The punchline is simple. PMPs should behave like software. Not paperwork. :cite[b8n,sil,bpp,dse,a9i,dsw]

Why PMPs Need to Become Programmable

For a decade, PMPs relied on a unique deal ID that buyers plugged into their DSPs to unlock a curated slice of inventory. In OpenRTB, deals live inside the pmp object and influence auction behavior for one or more impressions. :cite[b8n] Static deal IDs met initial needs. Yet three industry shifts broke the model:

  • Signal evolution: Third-party cookies and mobile device-level identifiers are constrained, pushing the market toward first-party, on-device, or cohort signals. Selling on static IDs without dynamic audience context loses punch. :cite[sil,dse]
  • CTV supply dynamics: Streaming supply is fragmented by apps, devices, and distribution. CTV buyers want content metadata, pod constraints, and brand safety rules encoded upfront. Static deals create back-and-forth friction and delivery risk. :cite[dsw]
  • Transparency and compliance: Buyers expect sellers.json, schain, and ads.txt consistency, and they want supply-path efficiency with predictable reach and measurement. These requirements change over time, which static deals do not capture. :cite[a9i,duj]

Programmability means buyers can express intent. Sellers automatically translate that intent into package definitions, controls, and activation with continuous optimization. The deliverable is not a one-off deal sheet. It is a maintained contract and a living API.

Definitions and Core Concepts

Before we get hands-on, let’s define terms with the standards in mind.

  • Deal ID: A unique identifier inside the OpenRTB pmp object representing a set of terms that govern access to inventory, floor pricing, and priority. :cite[b8n]
  • Programmable PMP: A PMP that is created, modified, and monitored via APIs that accept buyer intent parameters, map them to curated supply, and return a bound deal contract with versioning and measurement guardrails.
  • Intent API: A seller or SSP-side API that receives parameters such as audience, context, brand safety, identity mode, price targets, and channel constraints. The API returns a curated proposal, forecast, and activation handle that can be pushed to one or more demand platforms.
  • Curated Audiences (formerly Seller Defined Audiences): A framework to encode publisher-defined cohorts and contextual taxonomies aligned to IAB Tech Lab guidance. :cite[sil]
  • PAIR: Publisher Advertiser Identity Reconciliation. An emerging open standard and protocol for privacy-preserving first-party data matching across clean rooms and pipes. :cite[bpp]
  • PPS/PPIDs: Google’s Publisher Provided Signals and Publisher Provided Identifiers for activating first-party audience and contextual data in Ad Manager and partner demand channels. :cite[dse,ihd]
  • Supply transparency: sellers.json, schain, and ads.txt ensure counterpart identity and authorization across the supply path. :cite[a9i,duj]

What Buyers Actually Want When They Ask for a PMP

When a buyer requests “a PMP for high-intent shoppers on lifestyle content,” the ask typically includes five latent needs:

  • Safety and suitability: Brand safety categories, exclusion lists, MRC requirements, and IVT filtering, along with measurement eligibility.
  • Identity posture: The buyer’s target ID modes, from deterministic first-party matches via PAIR or PPIDs to cohort-based Curated Audiences and contextual fallbacks. :cite[bpp,sil]
  • Performance constraints: Target CPM ranges, reach goals, frequency preferences, historical overlap deduplication, and pacing controls.
  • Channel shape: Web display or video, in-app mobile, and CTV with specific app bundles, EPG categories, and pod rules. :cite[dsw]
  • Transparency and reporting: sellers.json completeness, schain integrity, delivery forecasts, and ongoing diagnostics.

A programmable PMP translates these intent signals into a machine-readable package that is monitored and refined. Static deals rarely keep up.

A Practical “Intent API” Spec Sellers Can Implement

Think of an Intent API as a thin layer on top of your curation engine and trafficking substrate. It receives human legible parameters and returns programmatic artifacts a buyer or DSP connector can use. The API does not replace OpenRTB. It configures how your supply will be offered through OpenRTB and direct pipes. Here is a minimal, illustrative spec.

Request

{
"buyer": {
"name": "Acme Retail",
"domain": "acme-retail.com",
"dsp": "DV360",
"seat_id": "12345"
},
"objective": {
"goal": "reach",
"kpis": ["completed_views", "on_target_impressions"]
},
"channels": ["web", "app", "ctv"],
"formats": ["display", "video"],
"inventory": {
"include_domains": ["example.com", "news.example"],
"exclude_domains": ["not-safe.example"],
"ctv_app_bundles": ["com.ctv.app1", "tv.hbo.max"],
"content_taxonomy": ["IAB1", "IAB9-30"]
},
"brand_safety": {
"garm": ["misinformation", "adult-excl"],
"ivt": "strict",
"measurement_partners": ["moat", "ias"]
},
"identity": {
"modes": ["pair", "ppid", "sda", "contextual"],
"pair_config": {
"clean_room": "ads_data_hub",
"publisher_namespace": "publisher.com",
"advertiser_namespace": "acme-retail.com"
}
},
"pricing": {
"target_cpm": 12.00,
"floor_type": "dynamic",
"currency": "USD"
},
"delivery": {
"start": "2025-01-01T00:00:00Z",
"end": "2025-02-01T00:00:00Z",
"daily_cap_imps": 2000000,
"freq_cap": {"imps": 3, "days": 7}
}
}

Response

{
"proposal_id": "rvpmp_92f7c",
"status": "proposed",
"summary": {
"estimated_imps": 60000000,
"estimated_unique_reach": 15000000,
"avg_cpm_range": [10.5, 14.0],
"coverage": {
"web": 0.6,
"app": 0.25,
"ctv": 0.15
}
},
"controls": {
"brand_safety": "strict",
"identity": ["pair", "sda", "contextual"],
"exchanges": ["SSP_A", "SSP_B"]
},
"activation": {
"deal_id": "RVP-2025-INTENT-CT-0001",
"pmp_terms": {
"auction_type": "second_price",
"whitelist_domains": ["example.com", "news.example"],
"schain_required": true
},
"dsp_push": [
{
"platform": "DV360",
"line_item": "Acme_Retail_RVP_Intent_0001",
"status": "pending_acceptance"
}
]
},
"observability": {
"sellers_json": "https://ssp-a.com/sellers.json",
"ads_txt_coverage": 0.98,
"schain_depth_avg": 2.1
},
"version": 1
}

This is intentionally compact, yet it embodies the key shift. Buyers declare intent. Sellers return a programmable contract and a living activation handle. Updates are handled with versioning and audit logs.

The Architecture: From Discovery to Automated Deal Activation

An Intent API assumes you have a curation and activation backbone. The building blocks look like this.

1) Inventory Graph and Taxonomies

You need a normalized, cross-channel inventory graph. Domains, apps, and CTV app bundles are mapped to owners, sellers.json entities, and content metadata. Your graph should carry:

  • Ownership and authorization: ads.txt and sellers.json tie-outs, supplychain object integrity, and resellers mapped to their principals. :cite[duj,a9i]
  • Content and context: IAB content taxonomy, app store metadata, and CTV channel and episode attributes where available. :cite[sil]
  • Technology stack: header bidding adapters, SDKs, analytics tags, and server-side platforms to anticipate latency and signal availability.

2) Identity and Addressability Layer

Support multiple identity modes and compose them per deal:

  • PAIR clean-room matching for high-fidelity first-party overlap without PII leakage. :cite[bpp]
  • PPIDs and PPS to activate publisher-authenticated traffic in Google Ad Manager workflows. :cite[dse,ihd]
  • Curated Audiences to encode cohorts with consistent labels across buyers. :cite[sil]
  • Contextual backstops for privacy-first reach.

3) Decisioning and Packaging Engine

You need a rules engine that translates intent into a package:

  • Eligibility rules: domain and app inclusion, category filters, brand safety and IVT policies, and measurement eligibility.
  • Pricing strategy: static floors for guarantees and responsive floors for biddable PMPs based on viewability and competition.
  • Forecasting: reach by channel, overlap controls, and delivery risk alerts.
  • Podding and video constraints for CTV, including min and max ad durations and competitive separation. :cite[dsw]

4) Activation Connectors

Translate the output into push actions:

  • DSP connectors: DV360, The Trade Desk, Yahoo, Amazon, and others, either through native APIs or buyer-run configuration scripts with a validation checksum.
  • Server-side trafficking: GAM, FreeWheel, or SSAI integrations for CTV.
  • Bidstream enforcement: OpenRTB with pmp.deals, schain inclusion, and content signals delivered at request time. :cite[b8n,a9i]

5) Observability and Governance

Programmability without accountability is chaos. Bake in:

  • Data freshness: ads.txt and sellers.json crawling SLAs and alerts for drift. :cite[duj,a9i]
  • Deal health monitoring: fill rates, bid rates, win rates, viewability, and IVT, segmentable by identity mode.
  • Supply path diagnostics: schain depth, resold vs direct, and DSP-specific rendering anomalies.

CTV-Specific Notes on Programmable PMPs

CTV has its own physics. Programmable PMPs can solve several chronic pain points.

  • App-centric curation: CTV deals often start with app bundles and channel-level metadata. An Intent API should accept and validate app IDs, device families, and distribution partners.
  • Podding constraints: Include target ad durations, max ads per pod, competitive separation, and mid-roll placement rules.
  • Measurement readiness: SSAI watermarking and VAST tracking alignment, with disclosure of supported verification vendors in the proposal. :cite[dsw]
  • Programmatic guaranteed alignment: Treat PG as a sibling to PMP. The Intent API should route to PG when the buyer’s objective or inventory constraints make a guarantee more efficient.

Buyers want less ceremony and more certainty. Programmability lets sellers encode certainty without five email threads.

The Policy Model: Human Readable, Machine Enforceable

Behind the scenes, we recommend storing package definitions in a policy document that is both human readable and machine enforceable. YAML is a good fit.

package_id: RVP-CT-INTENT-0001
version: 3
channels: [web, app, ctv]
formats: [display, video]
inventory:
include_domains: [example.com, news.example]
exclude_domains: []
ctv_app_bundles: [com.ctv.app1, tv.hbo.max]
content_taxonomy: [IAB1, IAB9-30]
brand_safety:
garm: [misinformation, adult-excl]
ivt: strict
measurement_partners: [moat, ias]
identity:
modes:
- type: pair
clean_room: ads_data_hub
- type: sda
taxonomy: iab
- type: contextual
pricing:
target_cpm: 12.0
floor_type: dynamic
delivery:
freq_cap:
imps: 3
days: 7
start: 2025-01-01T00:00:00Z
end: 2025-02-01T00:00:00Z
observability:
require_schain: true
sellers_json_url: https://ssp-a.com/sellers.json

This policy can be signed, versioned, and attached to every activation. It eliminates ambiguity and reduces reconciliation time when something breaks.

OpenRTB Mechanics: The Deal Object That Shows Up in the Auction

The PMP and Deal sections of OpenRTB define how your curated deal manifests in the bid request. At minimum, your impression objects should include pmp.deals with the dealid and auction rules. :cite[b8n] Here is a representative snippet.

{
"imp": [
{
"id": "1",
"video": {"mimes": ["video/mp4"], "minduration": 15, "maxduration": 30},
"pmp": {
"private_auction": 1,
"deals": [
{
"id": "RVP-2025-INTENT-CT-0001",
"bidfloor": 10.5,
"at": 2,
"wseat": ["dsp_seat_12345"],
"wadomain": ["acme-retail.com"]
}
]
},
"ext": {
"schain": {/* supply chain object */},
"data": {
"segment": [
{"name": "curated_audience", "value": "sda:shop_intent_high"},
{"name": "context_taxonomy", "value": "IAB9-30"}
]
}
}
}
]
}

Note the inclusion of curated audience labels and content taxonomy. These should align with IAB Tech Lab guidance for data transparency and taxonomy labeling. :cite[sil]

Prebid and First-Party Signal Activation

On the web and in app, a lot of seller-side signal generation flows through Prebid and mobile SDKs. You can standardize first-party data using Prebid’s ortb2 convention and Curated Audiences. :cite[aaw]

// Prebid.js configuration to set standardized first-party data
pbjs.setConfig({
ortb2: {
site: {
domain: "example.com",
page: "https://www.example.com/lifestyle/fitness",
content: {
cat: ["IAB9-30"],   // Fitness and Health subcategory
keywords: ["wellness","yoga","homegym"]
}
},
user: {
data: [
{
name: "curated_audience",
segment: [
{ id: "sda:shop_intent_high" },
{ id: "sda:health_enthusiast" }
]
}
]
}
}
});

The goal is simple. Align on identifiers and labels that can reliably pass through multiple demand endpoints and maintain semantic integrity. :cite[sil]

Forecasting Intent: A Minimalist Model

Programmable PMPs live or die on delivery truth. Forecasts need to be sober, not salesy. Here is an example SQL pattern to build weekly intent indices from log-level data for planning. It blends viewability, click propensity, and dwell time to produce a composite intent score by domain or app.

WITH base AS (
SELECT
supply_node,                         -- domain or app bundle
date_trunc('week', ts) AS week,
COUNT(*) AS imps,
SUM(CASE WHEN viewable = true THEN 1 ELSE 0 END) AS viewable_imps,
SUM(clicks) AS clicks,
AVG(dwell_seconds) AS avg_dwell
FROM impression_logs
WHERE ts >= now() - interval '90 days'
GROUP BY 1,2
),
rates AS (
SELECT
supply_node,
week,
imps,
viewable_imps::float / NULLIF(imps,0) AS v_rate,
clicks::float / NULLIF(imps,0) AS ctr,
avg_dwell
FROM base
),
scored AS (
SELECT
supply_node,
week,
imps,
v_rate,
ctr,
avg_dwell,
-- Simple normalized score. Replace with a proper model as needed.
0.5 * (v_rate) + 0.3 * (ctr * 10.0) + 0.2 * LEAST(avg_dwell / 60.0, 1.0) AS intent_score
FROM rates
)
SELECT *
FROM scored
ORDER BY week DESC, intent_score DESC;

Use these indices to steer curated deal composition for performance-oriented buyers. Make the methodology transparent in your proposal so the buyer knows what they are getting.

Governance: Transparency and Compliance by Default

Sellers and SSPs should embed transparency checks at every step.

  • ads.txt and app-ads.txt coverage and verification. Automated diffing and alerts when authorized sellers change. :cite[duj]
  • sellers.json and schain validation and exposure. Buyers need to trace the path to decide on trust and fees. :cite[a9i]
  • Logging and audit: Maintain a signed ledger of policy versions and activation events.
  • Privacy: Treat PAIR and PPIDs as privileged and auditable. Do not commingle with inferred user-level IDs. :cite[bpp,dse]

Transparency avoids deal meltdowns and accelerates reconciliation when there is a discrepancy.

The Business Case: Why This Matters for the Sell Side

Programmability is not just a tech upgrade. It is a revenue and retention strategy.

  • Higher close rates: Buyers can request, test, and iterate without waiting on traffickers. Time-to-first-impression shrinks from days to hours.
  • Improved yield: Dynamic floors and identity-aware packaging find the price point different buyers will bear. Performance buyers will pay for reliability.
  • Lower ops cost: Standardized policy definitions and API activation reduce manual trafficking and the error surface.
  • Stronger relationships: With visibility into transparency and measurement readiness, buyers expand rather than churn.

CTV Playbook: From Upfronts to Scatter, Then to Software

CTV teams already speak the language of packages by show, by genre, by daypart. Your Intent API should be their superpower.

  • Programmatic guaranteed routing: When a buyer’s target reach and pacing imply a guarantee, your API should propose PG with appropriate rate cards and cancellation terms. :cite[dsw]
  • Scatter curation: Use your inventory graph to surface quality scatter that fits a buyer’s suitability profile. Package, forecast, and deliver with the same policy artifacts. :cite[fj4]
  • Verification disclosure: Buyers want IAS, MOAT, or DoubleVerify. Propose deals that are ready and provide the expected impact on CPM and available scale.

Treat CTV PMPs as living bundles that learn from actual delivery, not static bookings that go stale.

Measuring Success: KPIs That Matter

Programmable PMPs should be evaluated on buyer value, operational efficiency, and supply integrity.

  • Time to first impression after a request
  • Forecast accuracy vs actual delivery
  • Deal health: bid rate, win rate, viewability, IVT rate, and completion rate for video
  • Identity lift: incremental performance from PAIR and PPID traffic vs contextual-only cohorts :cite[bpp,dse]
  • Transparency coverage: ads.txt, sellers.json, schain completeness :cite[duj,a9i]
  • Buyer expansion: number of new buyers using the API and their quarter-over-quarter spend

Common Pitfalls and How to Avoid Them

Programmability adds sharp edges. Guard against these mistakes.

  • Silent taxonomy drift: If your Curated Audience labels change, downstream segments break. Version your taxonomies and communicate deprecations early. :cite[sil]
  • Overfitting to one DSP: Abstractions that mirror one platform’s API too closely will limit portability. Keep a neutral policy layer and build connectors.
  • Opaque pricing rules: Buyers need to understand when and why floors adjust. Tie rules to measurable quality signals like viewability or completion rates.
  • Identity mishandling: PAIR and PPIDs are not generic user IDs. Enforce clean-room boundaries and do not store raw join keys. :cite[bpp,dse]
  • Neglecting supply transparency: If sellers.json or schain breaks, deals break. Automate checks and alerting. :cite[a9i]

Putting It All Together: A Reference Flow

Here is a compact end-to-end flow to make this real.

  • Discovery: Buyer hits your Intent API with parameters. You validate feasibility and return a proposal with forecasts and constraints.
  • Acceptance: Buyer accepts the proposal. Your system persists the policy document and generates activation tasks.
  • Activation: Push to DSPs and ad servers. Enable schain and data signals in the bidstream. :cite[b8n,a9i]
  • Monitoring: Track delivery, identity-mode split, transparency coverage, and measurement readiness. When thresholds are crossed, propose an updated policy version.
  • Reconciliation: Provide a signed ledger of policy versions, activation changes, and delivery metrics per day and per DSP seat.

Code Addendum: A Minimal Client to Request and Accept a Proposal

A small script buyers can run reduces friction.

import requests
import json
BASE = "https://seller.example/api/intent"
request = {
"buyer": {"name": "Acme Retail", "domain": "acme-retail.com", "dsp": "DV360", "seat_id": "12345"},
"objective": {"goal": "reach", "kpis": ["completed_views", "on_target_impressions"]},
"channels": ["web", "ctv"],
"formats": ["video"],
"inventory": {"content_taxonomy": ["IAB1-6"], "ctv_app_bundles": ["com.ctv.app1"]},
"brand_safety": {"garm": ["misinformation"], "ivt": "strict"},
"identity": {"modes": ["pair", "sda"]},
"pricing": {"target_cpm": 18.0, "currency": "USD"},
"delivery": {"start": "2025-01-01T00:00:00Z", "end": "2025-01-31T23:59:59Z"}
}
# Request proposal
proposal = requests.post(f"{BASE}/proposals", json=request).json()
print("Proposal:", json.dumps(proposal, indent=2))
# Accept if within budget and forecasted reach
if proposal["summary"]["avg_cpm_range"][1] <= 20.0 and proposal["summary"]["estimated_unique_reach"] >= 2000000:
accept = requests.post(f"{BASE}/proposals/{proposal['proposal_id']}/accept").json()
print("Accepted:", json.dumps(accept, indent=2))
else:
print("Counter or adjust parameters")

Offer SDKs or Postman collections so buyers can run this with minimal effort.

The Road Ahead: Deals Inside Protected Audiences and OpenMedia

The deal concept is evolving inside on-device auctions too. Google’s Protected Audience describes how deals and deal IDs can be represented natively within privacy-preserving auction workflows. Sellers should track how deal semantics translate across auction types to keep programmability consistent. :cite[ej2] On the specification front, IAB Tech Lab’s OpenMedia landscape aims to rationalize how standards fit together. That simplifies the seller’s integration burden and helps programmable PMPs travel cleanly across pipes. :cite[a31]

What Red Volcano Brings to the Table

Programmable PMPs depend on accurate supply intelligence, stable taxonomies, and transparent governance. This is where a specialized supply-side data layer pays off.

  • Publisher discovery and analysis: Identify premium web, app, and CTV inventory aligned to your buyer’s intent profile.
  • Technology stack tracking: Understand SDKs, adapters, and server-side components to predict signal availability and latency impact.
  • ads.txt and sellers.json monitoring: Detect drift before it breaks deals and automate remediation. :cite[duj,a9i]
  • Mobile SDK and CTV data: Map inventory, device families, and content signals to accelerate packaging.
  • Sales outreach enablement: Turn the Intent API into a repeatable go-to-market motion with prebuilt templates and playbooks.

Programmability is a team sport. Data intelligence is the connective tissue.

Conclusion: Make PMPs Behave Like Software

The sell side has a lot to gain by moving PMPs from static deals to programmable, intent-driven contracts. Buyers get repeatable outcomes. Sellers get higher yield, lower ops costs, and stronger relationships. The blueprint is not science fiction. Standards exist for the pipes and labels. PAIR, Curated Audiences, PPS, sellers.json, and OpenRTB already give us a shared grammar. :cite[bpp,sil,dse,a9i,b8n] The next step is product discipline. Define a clean Intent API. Version policies. Automate activation and monitoring. Measure honestly. Iterate. When PMPs behave like software, everyone wins.

References

  • OpenRTB 2.5 – pmp and deal structures :cite[b8n]
  • IAB Tech Lab Curated Audiences – formerly Seller Defined Audiences :cite[sil]
  • IAB Tech Lab PAIR Protocol – privacy-preserving first-party matching :cite[bpp]
  • Google Publisher Provided Signals – first-party activation in GAM :cite[dse,ihd]
  • sellers.json and SupplyChain – supply transparency controls :cite[a9i]
  • Index Exchange – CTV deal types and deal ID usage :cite[dsw]
  • IAB Tech Lab OpenMedia Landscape – standards coherence :cite[a31]
  • IAB Ads.txt Specification – authorization of sellers :cite[duj]
  • Privacy Sandbox – deals in Protected Audience API :cite[ej2]

Appendix: Additional Snippets

Policy Diff for Versioning

- identity.modes: [ "pair", "sda", "contextual" ]
+ identity.modes: [ "pair", "sda" ]  # removed contextual per buyer request
- pricing.target_cpm: 12.0
+ pricing.target_cpm: 13.5
- brand_safety.garm: ["misinformation", "adult-excl"]
+ brand_safety.garm: ["misinformation", "adult-excl", "spam"]

Deal Health Alert Rule

alert_id: deal_health_001
deal_id: RVP-2025-INTENT-CT-0001
triggers:
- metric: win_rate
comparator: lt
threshold: 0.05
duration: "6h"
- metric: viewability
comparator: lt
threshold: 0.55
duration: "24h"
actions:
- type: email
to: ["revops@publisher.com","trader@buyer.com"]
- type: autopolicy
patch:
pricing.floor_type: "static"
pricing.target_cpm: 11.0

Bid Request Integrity Check

{
"checks": [
{"path": "$.imp[0].pmp.deals[0].id", "exists": true},
{"path": "$.ext.schain", "exists": true},
{"path": "$.imp[0].ext.data.segment[?(@.name=='curated_audience')]", "exists": true},
{"path": "$.app.bundle || $.site.domain", "exists": true}
]
}

These addenda are not mandatory. They simply illustrate how to make the system observable and resilient. Citations:

  • OpenRTB API Specification Version 2.5 – iab.com :cite[b8n]
  • Curated Audiences (formerly SDA) – IAB Tech Lab :cite[sil]
  • PAIR Protocol – IAB Tech Lab :cite[bpp]
  • Publisher Provided Signals – Google Developers and Google Ad Manager :cite[dse,ihd]
  • Sellers.json and SupplyChain – IAB Tech Lab :cite[a9i]
  • CTV deal types – Index Exchange :cite[dsw]
  • OpenMedia specification landscape – IAB Tech Lab :cite[a31]
  • Ads.txt Specification – IAB Tech Lab :cite[duj]
  • Deals in Protected Audience – Privacy Sandbox :cite[ej2]