OpenAI Ads September 2026 Update: Ads Manager Plugin, Better Matching, Audience Tools, and New Markets

OpenAI's September 2026 advertising update is less about adding one more ad format and more about changing how advertisers operate the platform. Campaign work can now move into ChatGPT or Codex, Custom Audiences can be maintained instead of repeatedly rebuilt, Pixel and Conversions API events can carry more matching signals, and product-feed carousels have a new layer of card-level reporting. OpenAI has also introduced automatic pacing for total campaign budgets, expanded ads to selected markets in India, the Middle East and North Africa, and previewed a separate conversion model that will learn from both clicks and views.

What actually changed in the September update

The update combines live product changes, a rolling geographic release and one forward-looking announcement. That distinction matters: an advertiser can act on the new audience operations today, while there is not yet a documented setup path for the new view-through optimization model.

This article concentrates on capabilities that were not fully covered in Metricfixer's earlier guides. For the underlying auction, placements, contextual and personalized targeting, see How ChatGPT Ads Targeting Works After the August 2026 Privacy Update.

ChatGPT Ads Manager plugin: campaign operations move into the conversation

The most visible change is the ChatGPT Ads Manager plugin. According to OpenAI's advertiser notice, the plugin works in ChatGPT and Codex and can turn a website or written brief into ads that are ready for review and launch. It can also create variants, change existing campaigns, troubleshoot delivery, analyze performance and produce prioritized recommendations.

The important operational control is confirmation. The plugin is designed to show the recommended changes before applying them. That makes it a conversational control layer for the advertiser account, not an autonomous media buyer that should silently change budgets or publish ads.

What advertisers can use it for

A useful first request is not “launch a campaign.” It is “create a paused draft, list every assumption, and show the proposed changes.” The advertiser can then correct the brief before any live state changes.

A practical approval workflow

1. Connect the correct advertiser account. Confirm the account name, currency and timezone before discussing a change.
2. Ask for a paused draft. Give the plugin the commercial objective, market, dates, total budget, bidding method, conversion event, landing page and brand constraints.
3. Request a field-by-field preview. Review copy, URLs, budget, bids, geography, audience, schedule and status. A polished summary is not enough for a high-impact change.
4. Protect existing winners. Where historical continuity matters, create a separate variant instead of overwriting the only proven ad.
5. Approve a limited launch. A small canary campaign or narrow change set makes unexpected behavior easier to contain.
6. Verify the stored result. Re-open the campaign in Ads Manager or read it through the Ads API and confirm that every approved value persisted.
7. Measure against the same definitions. Use the same date range, account timezone and attribution fields when comparing the plugin's explanation with raw reporting.

Confirmation protects the account transaction; it does not validate the business decision. An advertiser remains responsible for substantiating claims, choosing a lawful audience, setting consent correctly and deciding whether a recommendation is commercially sensible.

What the plugin does not appear to change

The plugin does not create a new placement, auction or targeting signal. It operates over the advertising system and its account objects. The public Ads API reference still defines fixed creative fields, review states and object rules. For example, a standard chat-card ad has an editable title, body, asset and destination URL; edited creative can return to review. A preview link expires after 24 hours, archiving is irreversible, and some campaign-level choices cannot be changed after creation.

Advertisers should therefore expect the plugin to respect platform constraints rather than bypass them. Changing an objective or the selected conversion goal may require a new campaign instead of a simple edit. OpenAI has not yet published a product-specific page that lists the plugin's exact permissions, supported mutations, account-role model, audit history or rollback behavior. These should be tested in a low-risk account before the plugin becomes part of a production workflow.

Creative customization: faster variants, not documented one-to-one copy generation

OpenAI describes the plugin as able to turn a website or brief into ads and create variants. This makes copy development and adaptation more accessible: an advertiser can provide a value proposition, audience context, tone and constraints in plain language, then ask for several controlled directions.

However, “customization” needs a careful definition. Public documentation confirms advertiser-controlled editing of a chat-card title, body, creative asset and destination. It also supports product-feed templates that substitute catalogue values such as product title, body or price. It does not currently document unrestricted generation of a different ad message for each individual user at serving time.

These are three distinct mechanisms:

• Plugin-generated variants: draft alternatives created before delivery and reviewed as separate ads or edits.
• Advertiser edits: fixed changes to the creative stored in the account and subject to the normal review process.
• Product-feed substitution: deterministic insertion of catalogue fields into a product ad template.

None of them should be described as confirmed real-time generative personalization. That distinction matters for creative governance, experiment design and privacy expectations.

A better creative prompt

A short brief can produce attractive but repetitive copy. A useful production request should specify:

• The single action the campaign should generate.
• The market, language and customer situation.
• Approved proof points and claims that must not be made.
• Brand terms, spelling, capitalization and tone.
• The landing page and the promise it actually fulfills.
• Whether variants should test an angle, proof point or call to action—not merely synonyms.
• The protected control ad and the naming convention for new variants.

Custom Audiences become maintainable data assets

The earlier Custom Audience workflow encouraged periodic replacement or new uploads. The expanded API makes an audience behave more like a maintained first-party data asset: members can be added, removed or replaced while the audience ID remains stable. Existing campaign references do not need to be rebuilt just because the CRM list changed.

The official Custom Audiences guide now describes five practical operations:

Mixed identifiers, GAID and larger files

Advertisers can mix raw email, raw phone, hashed email, hashed phone and Google Advertising ID in one file when automatic identifier resolution is used. A populated cell is treated as an independent match candidate; a row is not proof that all values belong to the same matched person.

A conventional single-identifier upload supports up to five million identifiers. Automatic identifier resolution allows larger mixed-identifier audiences within the 500 MB file limit. That is a processing limit, not a promise of equivalent matched reach.

Audience-size reporting is also more useful, while remaining privacy-protected. The standard ranges now extend from under_25k through 5m_plus, and a granular mode provides finer bands for sufficiently large audiences. Exact match counts remain hidden. A value such as none means the size is unavailable, not necessarily zero.

Small exclusions are useful—but do not remove inclusion thresholds

A ready audience below 25,000 matched users, including an empty audience prepared for later updates, can be used for exclusion. This is valuable for suppressing recent purchasers, employees or customers who have opted out. Inclusion and bid-multiplier use generally still require approximately 25,000 matched users. The threshold applies to matched users, not uploaded rows.

Exclusions take precedence over inclusions. Advertisers should test a small audience separately as an exclusion and an inclusion instead of assuming that a successful upload makes it eligible for every campaign use.

Operational safeguards

• Use a unique Idempotency-Key for each new mutation and reuse it only when retrying that same operation.
• Track membership_revision and send expected_revision so two CRM jobs cannot silently overwrite one another.
• Poll the mutation operation as well as the audience; processing is asynchronous.
• Use inline identifiers for small updates of up to 10,000 values and a file for larger jobs; the inline request limit is 16 MiB.
• Use incremental add/remove jobs for daily changes and a periodic replace job to reconcile with the source of truth.
• Do not paste raw customer lists into a plugin conversation. Use the documented audience upload path and the organization's approved data controls.
• Keep consent, suppression and deletion logic upstream in the CRM or warehouse rather than treating an ad-platform list as the master record.

Custom Audiences must be based on permitted first-party data; hashing is not permission to use a record. They remain unavailable for campaigns targeting the European Economic Area or Switzerland. The distinction between contextual and personalized delivery, including this regional restriction, is covered in Metricfixer's targeting and privacy guide.

Conversion matching expands across the Pixel and Conversions API

The measurement update gives advertisers more ways to connect an ad interaction with a conversion when one identifier is missing or changes. It does not create a new conversion, and it does not guarantee that a conversion will match. The practical effect is a better chance of attribution when the event includes accurate, consistently normalized first-party signals.

Newly supported and expanded fields

The Conversions API uses only the first three valid unique entries in each plural list and silently ignores later values. Put the most current, best-supported identifiers first. OpenAI documents Android GAID but not an equivalent Apple IDFA field; an all-zero GAID is ignored.

Browser Pixel events do not cover the mobile-app events app_installed and app_opened. Those events require the Conversions API, which is also where the new android_advertising_id field is available.

Illustrative Pixel initialization

The Pixel accepts the user object during initialization. Hashed-designated values should already be normalized and SHA-256 hashed; geographic fields are normalized but sent as raw values. The placeholder hashes below are illustrative and should be produced from permitted first-party data.

// Run only after the consent manager confirms measurement permission.
oaiq("consent", true);

oaiq("init", {
  pixelId: "PIXEL_ID",
  user: {
    email_sha256: "SHA256_NORMALIZED_EMAIL",
    phone_number_sha256: "SHA256_NORMALIZED_PHONE",
    external_id_sha256: "SHA256_INTERNAL_CUSTOMER_ID",
    first_name_sha256: "SHA256_NORMALIZED_FIRST_NAME",
    last_name_sha256: "SHA256_NORMALIZED_LAST_NAME",
    country: "us",
    region: "ca",
    postal_code: "94107"
  }
});

The Pixel's measurement consent defaults to true unless the advertiser explicitly sets it to false or the Pixel finds a stored denial. In opt-in jurisdictions, set consent before initialization instead of relying on the default. Events blocked while consent is denied are not replayed later.

If a user signs in after the first page load, initialize the Pixel again with the complete permitted user object. Do not send a partial object and assume previous values will be combined. Where multiple pixels are present, specify the intended pixelId.

Automatic advanced matching can detect supported customer information and hash it in the browser. That reduces manual implementation work, but the advertiser should still inspect the actual form fields and network requests. A browser-side hash is pseudonymous data, not anonymous data and not a substitute for consent.

Illustrative Conversions API user object

{
  "validate_only": true,
  "events": [
    {
      "id": "order_12345",
      "type": "order_created",
      "timestamp_ms": 1788753600000,
      "source_url": "https://example.com/order-confirmation",
      "action_source": "web",
      "user": {
        "emails_sha256": [
          "SHA256_PRIMARY_EMAIL",
          "SHA256_RECENT_SECONDARY_EMAIL"
        ],
        "phone_numbers_sha256": [
          "SHA256_NORMALIZED_PHONE"
        ],
        "external_ids_sha256": [
          "SHA256_INTERNAL_CUSTOMER_ID"
        ],
        "first_names_sha256": [
          "SHA256_NORMALIZED_FIRST_NAME"
        ],
        "last_names_sha256": [
          "SHA256_NORMALIZED_LAST_NAME"
        ],
        "countries": ["us"],
        "regions": ["ca"],
        "postal_codes": ["94107"],
        "android_advertising_id": "123e4567-e89b-12d3-a456-426614174000"
      },
      "data": {
        "type": "contents",
        "amount": 12900,
        "currency": "USD",
        "contents": [
          {
            "id": "sku_123",
            "name": "Starter plan",
            "content_type": "product",
            "quantity": 1
          }
        ]
      }
    }
  ]
}

The example focuses on the new matching fields; a production event still needs the full required event and business data defined by OpenAI's Conversions API documentation.

Matching is not deduplication

More customer identifiers improve the probability of matching. They do not prevent a browser Pixel event and a server event from being counted twice. Hybrid implementations should send the same event identifier with the same Pixel and event name through both paths; the first accepted copy wins.

The existing oppref click reference and obref browser reference can also help attribution, but they have different roles from the new identity fields. For a broader implementation model connecting OpenAI Ads with GA4, a CRM and a warehouse, see Metricfixer's OpenAI Ads dynamic parameters and UTM tracking guide.

Implementation limits that matter in production

• A Conversions API request can contain up to 1,000 events.
• One invalid event can reject the entire batch, so validate small samples before increasing batch size.
• An event timestamp cannot be more than seven days old or more than ten minutes in the future.
• Only the first three valid unique values in each new plural matching field are used.
• Pixel/CAPI deduplication depends on the same Pixel, event name and event ID—not merely the same customer.
• Location, device IDs, IP addresses and user agents can remain personal or device-linked data even when names and contact details are hashed.

A safe rollout sequence

1. Gate browser initialization and event transmission through the site's consent logic.
2. Test normalization with known vectors before hashing; a correctly hashed incorrectly normalized value will still fail to match.
3. Use the Conversions API validation mode on representative events before production delivery.
4. Send one controlled conversion and reconcile it with the backend order or lead.
5. Test Pixel/CAPI deduplication with the same event ID.
6. Test consent denial, later consent and withdrawal as separate paths. Do not assume denied events will be replayed automatically.
7. Add fields gradually and compare accepted events, attributed conversions and backend outcomes independently.

More matching fields can increase reported attribution without increasing incremental sales. The correct validation question is not only “did match rate rise?” but also “did the reported change reconcile with real business outcomes?”

Carousel card reporting separates product visibility from billable delivery

Product-feed campaigns can appear as a multi-product carousel. The new reporting identifies whether an individual card became viewable and whether it received a click. A carousel card impression is counted when that product card becomes viewable; it is separate from the billable impression for the overall ad unit and is not added to the billable impression count.

This creates two levels of analysis:

Because one ad can make several product cards viewable, card impressions can exceed billable ad impressions. They should not be summed with ordinary impressions and should never be used to recalculate billable CPM.

In the public Insights API, advertisers can request product segmentation and work with product impressions, product clicks and product metadata such as feed ID, item ID, title, target URL, image, brand, seller, price and availability. The September email is the primary source that connects the newly named carousel card metrics to viewable cards and states the availability window.

The rolling 30-day window changes the reporting workflow

Complete data is available from August 20, 2026 on a rolling 30-day basis. Teams that need longer trends should export or ingest the product-level data regularly before older days fall outside that window. The warehouse table should keep the account timezone, extraction time and metric definition alongside every record.

Questions the new data can answer

• Was a low-click product rarely viewable, or was it visible and unpersuasive?
• Do products in later carousel positions receive less exposure?
• Are price, availability, image or product title associated with stronger card engagement?
• Does the feed contain products that receive views and clicks but cannot be tied to downstream sales?
• Do product-level results in Ads Manager reconcile with an Insights export for the same dates and timezone?

Product-level exposure and clicks improve diagnosis, but they are not automatically product-level revenue attribution. That connection requires reliable item or order data in the conversion and backend systems.

Total campaign budgets now receive automatic pacing

Campaigns using a total, or lifetime, budget now have platform-side pacing intended to spread spend more evenly between the start and end dates. This is a meaningful change from treating the total budget only as a hard campaign cap.

Pacing is not a fixed daily budget. Actual spend can still move above or below a straight-line plan because of available delivery opportunities, auction conditions, review status, pauses, bid settings and audience size. OpenAI has not published a pacing formula, refresh interval, user-facing toggle or guarantee that the full total budget will be delivered.

How to monitor it

For a simple diagnostic, calculate a reference curve rather than a promised quota:

• Reference elapsed share: elapsed eligible campaign time divided by total eligible campaign time.
• Observed spend share: cumulative spend divided by the total budget.
• Pacing ratio: observed spend share divided by reference elapsed share.

A ratio below or above 1.0 is a signal to investigate, not proof that the platform is malfunctioning. Exclude paused periods, disapprovals and intentional schedule changes, and check the account timezone. Also distinguish smoother spending from full utilization: a campaign can be evenly paced and still underdeliver.

OpenAI's API represents the cap through budget.lifetime_spend_limit_micros. No separate public pacing field is documented, so advertisers should treat the new behavior as automatic rather than a configurable daily-control mode.

Metricfixer's earlier Europe guide described the budget types and the previous operating behavior. The September change supersedes the earlier expectation for total-budget distribution; the guide remains useful for the surrounding campaign and access context: OpenAI Ads in Europe: Geo-Targeting, the 31-Country Rollout, and What Advertisers Can Use.

Coming soon: conversion optimization that includes ad views

OpenAI also announced a new conversion optimization model that will learn from conversions following both ad clicks and eligible ad views. The campaign will be billed on impressions while delivery optimizes toward the advertiser's selected conversion goal.

This should be treated as a separate campaign model, not a silent upgrade to current optimized CPC. The public Ads API does not yet expose a new campaign enum, configuration field, eligibility rule, bid definition or rollout date for it.

In today's reporting, view-through conversions use a fixed one-day window where available, click attribution takes precedence when both are eligible, and the view-through figure is kept separate from the main Conversions metric. It does not currently enter CPA, post-click conversion rate, billing or click-through optimization.

Why the new model needs a stricter test

A view can influence a later conversion, but it can also be incidental. High-converting users may have purchased without the impression. When the optimizer learns from view-through outcomes and billing is impression-based, a campaign can report more attributed conversions without producing the same increase in incremental sales.

A credible launch test should:

• Use a capped budget and a clearly defined standard conversion event.
• Keep the current click-through model as a comparison rather than replacing it immediately.
• Report click-through and view-through conversions separately.
• Use backend revenue, qualified leads or another business outcome as the primary result.
• Where spend justifies it, add a holdout, geo experiment or another incrementality method.
• Do not assume the current one-day reporting window will be the future optimization window until OpenAI documents it.

What advertisers still need OpenAI to document

• The campaign type or API value and its eligibility criteria.
• The view-through attribution and optimization windows.
• Bid controls and how an impression-billed campaign interprets the advertiser's target.
• Support for standard campaigns, product-feed campaigns and different conversion sources.
• Reporting fields that separate optimization credit from ordinary attribution.
• Rollout timing and whether the model is optional for every eligible account.

ChatGPT Ads reach selected markets in Europe, India, the Middle East and North Africa

OpenAI says ads began rolling out during the week of September 3 to selected countries across Europe, India, the Middle East and North Africa. India and the MENA expansion are the most important additions relative to Metricfixer's previous regional coverage. The notice does not provide a complete country list, and “ads are live” should not be read as universal self-service availability.

Advertisers should verify four separate layers:

1. Consumer inventory: can eligible ChatGPT users in the country see ads?
2. Advertiser access: can the business create and pay for campaigns from its account and billing country?
3. Targetability: does the country appear in the campaign UI for that account?
4. Feature parity: are the desired objective, format, measurement method and audience type supported there?

The distinction is especially important in Europe. Ad availability does not override the existing limitation on Custom Audiences in the EEA and Switzerland. A campaign can reach a region contextually without gaining personalized-audience features there.

Market-readiness checklist

• Confirm the country in the live campaign interface rather than inferring it from a regional announcement.
• Check advertiser-country eligibility, currency, billing, tax and policy requirements independently.
• Localize the ad and landing page together; translation without local pricing, delivery terms or support is not full localization.
• Check language and cultural fit for each country instead of treating MENA as a single audience.
• Validate consent and data-transfer requirements before enabling matching fields or device identifiers.
• Start with a controlled budget because inventory depth and performance can differ sharply between newly opened markets.

A practical rollout plan for advertisers

First 48 hours: protect the account and definitions

• Connect the Ads Manager plugin to a low-risk or test workflow and confirm the account, role, currency and timezone.
• Create one paused canary campaign; save the proposed change preview and compare it with the resulting object.
• Ask which actions trigger confirmation, including activation, budget increases, archiving and audience replacement.
• Document who may approve live changes and which campaigns or budgets are protected.
• Record the exact metric definitions that will be used for billable impressions, card impressions, clicks and conversions.

First two weeks: validate data paths

• Test audience add, remove and replace operations with seeded records while confirming that the audience ID remains stable.
• Retry one audience mutation with the same idempotency key and test a deliberate revision conflict.
• Verify a sub-25,000 audience separately as an exclusion and as an inclusion.
• Test Pixel and Conversions API normalization, consent, validation, deduplication and the first-three-values behavior.
• Compare carousel card metrics in Ads Manager with a product-segment Insights export for identical dates and timezone.
• Start exporting carousel data on a schedule that preserves the rolling 30-day history.

First 30 days: judge business value

• Compare plugin-produced recommendations with the changes the team accepted, rejected and later reversed.
• Measure whether creative variants provide distinct hypotheses rather than more versions of the same wording.
• Monitor cumulative spend against a reference pacing curve and separately monitor end-of-flight utilization.
• Reconcile attributed conversions with backend orders, qualified leads, cancellations and margin.
• Review whether additional matching fields changed reported attribution more than observed business outcomes.
• Keep the future view-through model out of operating forecasts until eligibility, configuration and attribution rules are published.

Open questions advertisers should track

The September release is operationally significant, but several details remain undocumented in public materials:

• The Ads Manager plugin's exact scopes, supported actions, account roles, audit log, retention behavior and undo path.
• Whether every proposed account mutation requires confirmation and how multi-action approvals are displayed.
• The exact country list and per-country differences in advertiser access, formats and objectives.
• The lifetime-budget pacing algorithm, refresh interval and underdelivery safeguards.
• The configuration and attribution rules for view-through-inclusive optimization.
• Whether every public product-impression field maps one-to-one to the carousel card definition in the email.
• Retention, deletion and data-subject-request procedures for expanded matching identifiers and plugin interactions.

Final assessment

OpenAI Ads is becoming easier to operate and more demanding to govern at the same time. The plugin can remove interface friction, but it makes clear briefs, permissions and approval records more important. Editable audiences reduce rebuild work, but require reliable revision and consent controls. Expanded matching can improve attribution, but can also make platform reporting look better without proving incremental growth.

The clearest immediate gains are practical: maintain one audience ID, send better-structured measurement data, distinguish card visibility from paid delivery, preserve product-level reporting before the 30-day window closes, and monitor total-budget campaigns against a reference curve. The announced view-through optimizer deserves a more cautious response. Its value will depend on the implementation details and on whether advertisers evaluate it with business outcomes rather than platform-attributed conversions alone.

Methodology and sources

This review was prepared on September 7, 2026. The September 3 product-update email supplied by an OpenAI advertiser is the primary source for the Ads Manager plugin, the August 20 start and rolling 30-day availability of carousel card data, automatic total-budget pacing, the future view-through-inclusive optimization model and the regional rollout. These details were treated as first-party release information, but as account- or rollout-dependent where the notice used language such as “rolling out” or “coming soon.”

Technical behavior was checked against OpenAI's public Ads developer hub, including the Custom Audiences guide, Measurement Pixel documentation, Conversions API documentation, Insights API reference, Campaigns API reference and conversion-optimized campaign guide. General installation and connection behavior was compared with OpenAI's plugin documentation.

We also reviewed Metricfixer's existing coverage of targeting and personalization, European availability, bidding and budgets, dynamic URL parameters, Pixel/CAPI measurement and product-feed tracking. Repeated background material was condensed or linked rather than reproduced. No live advertiser account, Ads Manager plugin session or production campaign was available for independent feature testing, so undocumented permissions, market availability and future-model behavior are identified as open questions rather than inferred as facts.