RFC: typed browser-family targeting

[bokelley]

Summary

Add typed browser-family inclusion and exclusion to AdCP targeting without exposing browser versions or seller ad-server keys.

This is the browser-specific follow-up split from #4239. It should use the targeting-aware discovery contract in #6203: known values affect the offered product's availability, price, and forecast; future package-level control is requested and disclosed per product.

Proposed schema

• targeting.browser: non-empty array of canonical browser-family values
• targeting.browser_exclude: non-empty array using the same enum
• new browser-family enum, initially:
  • chrome
  • safari
  • firefox
  • edge
  • opera
  • samsung_internet
  • android_webview
  • other
  • unknown

Browser versions are intentionally out of scope for 3.2. Seller-native browser/version taxonomies change too frequently and do not map reliably enough for an interoperable external contract.

Semantics

• Exclusion wins when the same family appears in both fields.
• Inclusion and exclusion support are independent product capabilities under required_overlay_support and overlay_support.
• Known browser values in get_products.targeting_overlay constrain availability, price, and forecast.
• Exact support needs no targeting echo.
• During discovery, a seller that can offer only a different executable browser constraint returns sparse targeting_resolution.modifications; selecting that configured product accepts the disclosed change.
• During create or update, a seller that cannot enforce the exact requested constraint rejects it instead of silently broadening delivery.
• Products for which browser targeting is unavailable simply omit the corresponding overlay_support fields.

Trust boundary

This RFC does not allow buyers to pass browser strings, backend segment IDs, or arbitrary key/value expressions. Sellers map the typed family enum to their platform controls internally. Any future browser-engine or version support requires a separate typed proposal.

Acceptance criteria

• Add and document the canonical browser-family enum.
• Add browser and browser_exclude to targeting.
• Add both fields independently to overlay requirements and support.
• Define overlap, unknown, resolution, forecast, and rejection behavior.
• Add schema tests for canonical and invalid values.
• Add compliance coverage for exact discovery and later package-level support.
• Confirm mappings against at least GAM, Microsoft/Xandr, and DV360 terminology.

Open taxonomy questions

• Is android_webview the right interoperable family, or should embedded webviews remain other?
• Should privacy-reduced or unrecognized user agents always map to unknown, reserving other for recognized but non-enumerated families?
• Do any major sellers require samsung_internet to map differently from Chromium-derived browser families?

Industry references

• Google Display & Video 360 browser targeting
• Microsoft/Xandr system targeting
• Google Ad Manager targeting types

Related: #4239, #6203. Supersedes the browser portion of #4239 only.

[bokelley]

Triage

Classification: RFC — feature proposal
Bucket(s): spec / protocol, media-buy
Status: deferred

The proposal is well-scoped — typed browser-family enum, inclusion/exclusion semantics, trust boundary, and open taxonomy questions are all clearly framed. However, this RFC explicitly builds on the targeting-aware discovery contract being introduced in #6203, which is still open. The resolution / targeting_resolution.modifications path described in the semantics section can't be fully evaluated until that contract is finalized.

Blocked-on: #6203 — resurfaces on merge

---

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

---

Generated by Claude Code