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. ages 25-44 also works on Google Ads because it is the exact union of two closed native buckets. A range that cuts through a bucket, or a closed range such as 65-99 projected onto Google’s open-ended 65+ bucket, is never approximated.

Snap: Australia minimum age

Snap prohibits reaching people under 16 when a media buy targets Australia exclusively. If a Snap media buy targets Australia only and the brief has not requested an age range, Interchange automatically applies an 18+ audience before sending the buy to Snap — so if you target Australia and don’t say 18+, Snap will get an 18+ audience. This only applies when Australia is the sole targeted country; combining Australia with another country does not trigger it. If you explicitly request ages 13-17 on an Australia-only Snap buy, the media buy is rejected before it reaches Snap rather than having that request silently overridden.

Requests that need clarification

An ambiguous, excluded, or open-ended age request needs clarification. An exact but unsupported age range receives a counter-pitch instead: a composition storefront returns products that fit the rest of the brief and includes an additive limitations entry. The proposal is composed from inventory without age targeting; fixed-age inventory is excluded rather than silently delivering to a different age audience. Its message says this explicitly, requested preserves the requested range, excluded_ranges lists fixed ranges omitted from the counter-pitch, and supported_ranges lists the exact ranges the seller can execute (or is empty when none are declared). The storefront never broadens, approximates, or inverts the age request.
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 and Google Ads

Meta and Google Ads 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 provider targeting object, and checked on readback. 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. On Google Ads, every constrained request writes positive criteria for the selected age buckets and negative criteria for every omitted bucket. This includes a negative AGE_RANGE_UNDETERMINED criterion unless the brief explicitly includes unknown ages; an include-unknown choice instead writes it as a positive criterion. Exact readback verifies the complete positive and negative set. Other platforms reject an include-unknown request unless their row above says otherwise.

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.
Signal-based path: Age targeting through product-level signals (described in this guide) is carried by the selected product via ext.scope3_product_targeting.demographics. It is not a targeting_overlay field; the paths are separate.AdCP 3.2 overlay path: overlaySupport.demographics is the permission signal for demographic overlays, and demographicTargeting is the companion product-scoped compiler contract for supported age bounds and unknown-age handling. save_media_buy rejects targetingOverlay.demographics before dispatch while the application seller transport remains on AdCP 3.1. Treat these fields as discovery/readback data for now, and use signal targeting or omit demographics when staging a media buy.

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.