ChatGPT Ads Product-Feed Campaigns Are Country-Level Only — and custom_label Is Not Geo-Targeting

On 2026-09-22 OpenAI's Advertiser API documentation changed two pages at once — Campaign Targeting and Product Feeds — and between them they close a gap that has quietly been costing catalog advertisers money.

The short version: product-feed campaigns on ChatGPT Ads target countries and nothing narrower, and the custom_label_0 = WA pattern that every Google Shopping advertiser has muscle memory for does not restrict delivery to Washington. It never did. The documentation just said so out loud for the first time.

This matters more than a normal wording change because the old text actively invited the mistake.

What the documentation said before

The Campaign Targeting page previously carried a conditional:

Use country-level geographic inclusion and exclusion for product-feed campaigns. Verify account support before relying on more granular locations.

Read that as an advertiser. "Verify account support before relying on more granular locations" says, fairly plainly, sub-country targeting may be available to you — go and check. It frames country-level as a default with a possible upgrade, and it puts the burden of discovery on the advertiser's account team.

What it says now

That hedge is gone. The section now reads:

### Product-feed campaigns

New product-feed campaigns support geographic targeting and exclusions only at country level.

Campaign targeting determines which users are eligible to receive ads. To select which products an ad group can use, apply product filters, including supported custom labels in ads_metadata. See Product Sets & Filters. A product label does not itself restrict delivery to users in that location.

Three things changed, and each one is doing work:

1. The conditional became a statement. "Verify account support before relying on more granular locations" → "support geographic targeting and exclusions only at country level." There is no longer a documented path to ask for more.
2. The word "New" is carrying weight. The restriction is scoped to new product-feed campaigns. OpenAI does not say what happens to existing ones. We would not read that as a promise that legacy campaigns keep sub-country targeting — only that the documented rule is written for what you create today.
3. A new sentence separates two systems that look like one. "Campaign targeting determines which users are eligible to receive ads… A product label does not itself restrict delivery to users in that location."

The same restriction was mirrored into the Product Feeds walkthrough, where the campaign-creation step previously just said to use country-level targeting "for this walkthrough" — an aside that read like a simplification for the example. It now says:

New product-feed campaigns support geographic targeting and exclusions only at country level. Follow the campaign targeting guide to configure these settings.

That is the tell that this is a real product rule and not an editorial convenience: the same sentence now appears on both pages, and the walkthrough defers to the targeting page instead of hand-waving.

The custom label trap, in OpenAI's own example

The Product Feeds page gained a new paragraph under Product Sets & Filters, and it is unusually direct about a mistake:

To organize your catalog with custom labels, add the labels inside each product's ads_metadata using keys supported by your integration. Then apply filters on those fields in the ad group's product_set. Different ad groups can select different subsets of the same catalog.

For example, set custom_label_0 to WA inside a product's ads_metadata, then filter on ads_metadata.custom_label_0 to select products carrying that label. This selects eligible products; the label itself does not restrict delivery to users in Washington. Configure user-location targeting through campaign targeting.

Note what OpenAI chose as the example value. Not clearance, not high-margin, not summer — WA, a US state code. Documentation teams do not pick an example like that at random. They pick it because it is the thing people are getting wrong.

Put the two pages together and the trap is complete:

• You label your catalog by state, because that is how Shopping feeds are organised.
• You filter an ad group on ads_metadata.custom_label_0 = WA, and the ad group correctly narrows to Washington inventory.
• You assume the ad group now serves Washington users.
• It does not. It serves the whole country on the campaign's country targeting, showing Washington-only products to buyers in Florida.

Nothing errors. The API accepts it. The ad group's product set is valid. You simply pay for national delivery of regional inventory, and the only symptom is a conversion rate that quietly underperforms with no obvious cause.

Why this catches good advertisers

The pattern is imported, and the import is almost right.

In Google Shopping, custom_label_0 through custom_label_4 are also pure product-grouping attributes — they do not target anyone either. But in Google the habit is safe, because the campaign wrapped around that product group can be geo-targeted down to a postal code. Advertisers learned the pairing "label the products, geo-target the campaign" as a single move, and it works because the second half is always available.

ChatGPT Ads keeps the first half and removes the second. The muscle memory transfers; the safety does not.

There is a second-order reason this is easy to miss: the restriction is specific to product-feed campaigns. The same Campaign Targeting page documents that ordinary campaigns can carry geographic inclusion and exclusion lists of up to 2,500 IDs. So an advertiser who has run standard ChatGPT Ads campaigns with granular geo lists, and who then launches their first catalog campaign, will reasonably assume the capability came along. It did not.

Who is affected, concretely

This lands hardest on catalogs whose inventory is regional even when the brand is national:

• Retailers with store-level or warehouse-level stock. Products that can only be fulfilled from certain regions now advertise nationally unless you split campaigns by country.
• Category-regulated goods. Anything whose legality or shipping eligibility varies below the country line — alcohol, certain supplements, some electronics, regulated services. A label is not a compliance control, and this documentation now says so explicitly.
• Price- or currency-split catalogs. If your feed carries regional pricing variants distinguished by label, the campaign cannot keep each variant in its own market below country level.
• Anyone who built their ChatGPT Ads feed by exporting their Google Shopping feed, labels and all, which is the most common way these feeds get created.

If you are running any of the above, the audit is short: for each product-feed campaign, list the ad groups, look at their product_set filters, and ask whether any of those filters encode a place. If they do, the campaign is serving that inventory to the entire country.

What to actually do

Ordered by how much it recovers.

1. Separate the two questions in your own head, and in your naming. Product filters answer what can this ad group sell. Campaign targeting answers who can see it. Rename ad groups so a label-based filter never reads like a geography — catalog-wa-stock invites the confusion; stock-pool-a does not.

2. Split by campaign where you need to split by market. Targeting lives on the campaign. If you need Canada separated from the United States, that is two campaigns with two feed selections and two budgets, not two ad groups. Below the country line, ChatGPT Ads currently gives you no lever at all on a product-feed campaign.

3. Do not use labels as a compliance boundary. If a product must not be shown in a jurisdiction smaller than a country, a product-feed campaign cannot enforce that today. Either keep that SKU out of the feed entirely, or run it as a non-product-feed campaign where the 2,500-ID geographic exclusion list is available.

4. Preview your product set before you launch. The Product Feeds page documents querying the feed with your intended filters before creating or updating an ad group. That preview tells you which products matched — which is exactly the check that reveals a filter you believed was geographic.

5. Re-check existing campaigns rather than assuming they are grandfathered. The rule is written for "new" product-feed campaigns and OpenAI has not documented the behaviour of older ones. Treat an existing campaign's sub-country targeting as unverified until you confirm it in your own account.

The source situation, stated plainly

Two things are worth being precise about, because they affect how much weight to put on this.

This is developer-documentation-only. As of 2026-09-22 the change appears at developers.openai.com/ads. The ChatGPT Ads help centre at help.openai.com carried no corresponding wording change in the same window — its ads articles moved only in their relative "updated" timestamps. If your team works from the help centre, this rule is currently invisible to you. That is not unusual for ChatGPT Ads: the developer docs have repeatedly carried mechanics that the help centre never picked up.

There was no advertiser email announcing it. OpenAI's advertiser product-update emails are a genuine third source and they do carry things the docs miss — but the most recent one landed on 2026-09-16, and nothing in this window mentions product-feed geo targeting. So this change arrived silently, in documentation only.

We are also being careful about one thing we are not claiming. A documentation change is not proof that the underlying API behaviour changed today. The new text may be a correction — the platform may have been country-level-only all along, with the old "verify account support" line simply being wrong. The removal of a hedge, rather than the addition of a limit, reads more like a correction than a regression. Either way the operational conclusion is identical: do not plan a ChatGPT Ads product-feed campaign around sub-country targeting.

Where Soku fits

Soku runs ChatGPT Ads as one of its ad surfaces, and the thing that helps here is not a clever targeting trick — there isn't one available. It is catching the mismatch before spend starts.

When Soku builds a product-feed campaign it treats the product set and the audience as two separate decisions, because the platform does. If a feed's labels encode geography, that is surfaced as a structural question — do you want this split as separate campaigns? — rather than silently accepted as an ad-group filter that looks like targeting. And because Soku reads the campaign back after it writes it, a targeting configuration that the API accepted but did not apply the way you meant shows up as evidence rather than as a slow conversion-rate decline three weeks later.

That is the whole value in a case like this: the API will happily accept the wrong mental model. Something has to notice.

Sources, all verified 2026-09-22:

• Campaign Targeting — Product-feed campaigns, OpenAI Advertiser API documentation
• Product Feeds — Product Sets & Filters, OpenAI Advertiser API documentation
• Ad Groups reference, for supported filter fields, operators and validation rules

Facts above are quoted from OpenAI's official documentation. Analysis of the Google Shopping habit, the affected catalog types and the recommended campaign structure is Soku editorial and is labelled as such.