Skip to main content

​
Overview

Add one closed age range to a get_products brief when a campaign must reach a specific adult audience. For example:
The storefront copies the two numbers from the brief. It does not ask a model to choose an age range, translate a generation label such as “Gen Z” into ages, or widen the request to fit a platform. This applies during product discovery and media-buy creation. It does not change targeting on an existing media buy. In chat, ask for ages 21-35; your agent uses this path automatically and does not guess when the platform cannot represent the range. No setup change is required for an existing brief that already contains one exact supported range.

​
Platform support

Each storefront must prove that it can execute the requested range exactly. ages 21-35 therefore works on Meta and Spotify. It returns no product from a bucket-only or unsupported adapter because approximating the request would change the audience.

​
Requests that need clarification

Product discovery returns no matching product when the age request cannot be executed without guessing or broadening. A composition storefront reports that it cannot satisfy the requested age targeting; it does not describe the result as missing inventory. Rewrite the brief as one explicit, closed, supported adult range when it contains:
  • An open endpoint, such as ages 21+, under 35, or up to 35.
  • More than one or a disjoint range, such as ages 21-24 or 35-44.
  • An exclusion, such as exclude people ages 21-35.
  • A minimum below 18.
  • Conflicting or ambiguous bounds.
  • A descriptive label without numbers, such as young adults or Gen Z.
This fail-closed response is expected. It prevents a storefront or model from silently choosing a different audience.

​
Unknown ages on Meta

Meta can deliver to people whose age is unknown. A constrained-age request excludes them unless the brief explicitly says to include them:
You can also state that they must be excluded. The choice is stored with the product, written to the Meta ad set, and checked on readback. Other platforms currently reject a request to include people whose age is unknown. Meta may omit the unknown-age field when its effective value is false. In that case, readback still preserves your explicit exclusion under the requested controls and reports an exact match. A provider value of true never satisfies an exclusion or an age-constrained request that did not opt in.

​
Read the applied targeting

A returned product with verified age targeting includes the applied range at:
Use the returned product for media-buy creation. The storefront checks the stored product declaration again before publishing it or writing provider state. On Meta, requested and provider controls also show whether unknown ages were included.
Age is currently carried by the selected product. It is not a targeting_overlay field, and adding age to an overlay does not activate this behavior.

​
Seller impact

Sellers using a built-in adapter do not need a new configuration field. A custom or upstream sales agent must return the exact ext.scope3_product_targeting.demographics.age declaration or its product is filtered from that brief. As an alternative, an ad-server-backed seller can map existing ad-server targeting to a first-class age signal: The product declaration does not have to come from a user-level age signal. A wholesale product can declare that its inventory itself represents the exact age cohort—for example, from survey evidence or modeled audience composition—by including determinationMethod and the responsible dataProvider beside its age range. Chef can then select that inventory directly without attaching an age signal. Descriptive copy such as “great for young adults” is not enough; the structured bounds and provenance must be present.
Start from the selected ad-server targeting candidate’s complete adapterConfig; the abbreviated object above only illustrates the age fields. The age meaning comes exclusively from the age signal type and its range. A signal named “Adults 25-54” without those fields is not treated as an age signal. Signal Manager supports three semantic types:
  • generic is ordinary buyer-selectable targeting.
  • age is buyer-selectable targeting with a required closed adult range and determination method.
  • property is inventory addressing only and never enters the buyer-selectable signal catalog.
Every age signal also declares one determination method:
  • survey_based: the person reported their age in a survey.
  • assumptive: the provider inferred or modeled the age.
  • user_provided: the person supplied their age, without identity verification.
  • user_verified: the supplied age was verified against an identity source.
dataProvider separately names who supplied the dataset. It may name the seller, a first-party registration system, or a third-party data provider; the provider name does not substitute for the determination method. When a brief asks for the same closed range, the storefront can select products from that signal’s source and automatically applies the signal on the buy. A different or partially overlapping bucket is not accepted, and signal-backed age buckets do not include unknown ages. Product declarations and mapped age signals describe targeting that will be applied, not the full range the source might be capable of creating. For example, a product or signal declaring ages 18-65 does not prove that ages 25-54 will be applied. The source must return a product or explicit signal declaring the requested range exactly.

​
Restrict acceptable age determination

Until AdCP 3.2 supplies native provenance fields, a buyer can add the temporary Scope3 extension below to the same get_products request:
When this allow-list is present, the storefront only returns a product whose exact age mapping declares one of those methods. Missing, unknown, or disallowed provenance fails closed; it is never treated as approval. A product with age targeting baked into its inventory metadata declares the same fact as ext.scope3_product_targeting.demographics.age.determinationMethod.