What 3,602 Early ChatGPT Ads Reveal About Delivery

What OpenAI announced

OpenAI’s August 18 announcement names Germany, France, Spain, Italy, Sweden, Norway, Denmark, the Netherlands, and Austria as examples inside a 31-country European rollout. The company does not provide the complete list of 31 countries on that page. A buyer should therefore verify a target country directly rather than treating every European market as confirmed.

OpenAI also says conversations remain private from advertisers, ads are labeled and separate from answers, and advertising does not influence ChatGPT’s answers. Those are platform-policy statements. Buyers should still review the contract, targeting controls, consent setup, creative review, and market-specific legal duties that apply to their own campaign.

Access is not the same as inventory

There are at least four separate states in this rollout:

1. market announced: OpenAI includes a country in its expansion;
2. advertiser approved: a business has a usable account or partner route;
3. campaign eligible: the creative, audience, objective, billing, and measurement setup pass review;
4. ad delivered: eligible Free or Go users actually receive impressions.

A press release proves the first state. It does not prove the next three for a specific advertiser. Ask the sales or agency contact to confirm the target country, available objective, billing currency, minimum commitment, supported conversion event, reporting latency, and inventory estimate in writing.

This distinction matters when a channel is new. A campaign can be technically enabled but too small to spend at the planned rate. It can also deliver clicks before server-side events are reconciled. Our comparison of the ChatGPT Ads Pixel and Conversions API explains why browser and server measurement need one event contract, while the oCPC billing guide separates conversion optimization from click-based charging.

What “tens of thousands” does not prove

OpenAI says tens of thousands of marketers have advertised on ChatGPT. It does not disclose the counting method, time window, active-campaign threshold, spend distribution, repeat rate, or how many of those marketers bought outside the United States. Treat the figure as a first-party platform statement; not as evidence that a typical European campaign will reach scale or meet a performance target.

The same caution applies to the phrase “actively exploring, comparing, and making decisions.” It describes the product’s intended commercial context. It is not a published lift study. A useful launch report should keep platform-attributed outcomes beside first-party validated outcomes and preserve zero-conversion campaigns.

A budget-readiness checklist

• Confirm that every target country is officially supported; save the dated confirmation.
• Record whether access is direct, agency-led, or technology-partner-led and identify who owns the account and data.
• Freeze the campaign objective, eligible conversion event, billing model, and attribution window before forecasting.
• Test the Pixel and Conversions API with a stable event identifier and documented consent behavior.
• Separate impressions, valid clicks, platform conversions, validated conversions, revenue, and refunds.
• Use a small bounded test with an explicit stop rule; do not transfer a U.S. benchmark into Europe without evidence.

For a first test, the useful question is not “Does ChatGPT Ads work?” It is “Under this country, access route, audience, creative, objective, attribution rule, and measurement setup, what outcome did a defined budget produce?”

Source, method, and limits

Primary source: OpenAI: ChatGPT Ads expands across Europe, published August 18, 2026 and checked August 24, 2026.

Method: We separated geographic announcement, advertiser access, user-plan inventory, buying interface, measurement capability, and performance evidence into distinct fields. No third-party market list or benchmark was used to fill a gap in OpenAI’s announcement.

Limits: OpenAI names only nine example countries in the announcement and publishes no Europe-specific performance dataset. Current Ads Manager eligibility can differ by account and market, and product terms can change after publication.

The four states you need to record

Indexing and eligibility sit between acknowledgement and delivery. A title can be accepted but later fail a policy or data rule. Availability can be stale if a later update overtakes an earlier one. A product can be correct and eligible but never receive an impression.

What Delta Feeds can change

OpenAI documents Delta Feeds as an account-enabled feature for changing variant availability and titles through PATCH /feeds/{feed_id}/products. It is deliberately narrower than a full feed:

• Use a full feed or product workflow to create the catalog and new products.
• Use Delta Feeds for time-sensitive corrections to existing variants.
• Do not send a complete catalog as if the endpoint were a replacement feed.
• Do not infer creation when an unknown identifier is acknowledged at the request layer.

The operating benefit is freshness. The operating risk is silent divergence between your commerce database, the last accepted patch and the downstream ad state.

Build a reconciliation ledger

Store one row per attempted change with the feed ID, product and variant identifiers, old value, new value, source timestamp, request timestamp, response, retry count and reconciliation result. Make the source timestamp monotonic so a delayed worker cannot overwrite a newer availability value.

Useful alerts are about state gaps, not raw request counts:

• accepted updates not reconciled within the normal window;
• repeated failures for one identifier or field;
• inventory marked unavailable in commerce but still eligible downstream;
• out-of-order updates;
• a sudden drop in product eligibility after a title release.

For bulk runs, canary a small set before sending the full queue. Preserve exact request and response bodies with sensitive fields redacted. Replaying from logs should be possible without inventing the prior source state.

A practical runbook

1. Confirm the account is enabled and the base feed already contains the target variants.
2. Validate identifiers and allowed title/availability values locally.
3. Send a canary patch and record the acknowledgement.
4. Poll or export the relevant downstream state when the product provides it.
5. Check eligibility separately from data propagation.
6. Check serving separately from eligibility.
7. Retry only idempotent changes, with backoff and an age limit.

For the broader commerce context, read ChatGPT product feeds, organic shopping and ads. For measurement, use the Ads Pixel vs Conversions API comparison.

Primary source and limit

OpenAI: Delta Feeds.

Limit: This is a documentation-led operational guide, not a live feed experiment. Downstream status surfaces and enablement can vary by account. The word “accepted” should be interpreted exactly as documented: accepted for processing.

Optimization and billing are different

An ad platform needs two separate contracts. The optimization contract tells the delivery system which future event to prefer. The billing contract defines what creates a charge. In OpenAI’s documented beta, the campaign can optimize toward a selected conversion while the advertiser pays for each valid click.

Custom events are not eligible as the optimization event. OpenAI also says a campaign must have exactly one active standard conversion event, and the optimization goal and event cannot be changed after creation. That makes preflight validation more important than dashboard experimentation.

Choose a conversion the system can learn from

The deepest business event is not automatically the best learning event. A rare subscription or qualified sale may have strong value but too little volume or too much delay. A checkout start may provide more signal but optimize toward people who never pay.

Score candidates across five fields:

1. Business proximity: how close the event is to revenue or another real outcome.
2. Frequency: how often it occurs in the campaign’s expected traffic.
3. Delay: how long after the click the event becomes observable.
4. Reliability: whether pixel/API delivery survives browser and backend failure.
5. Reversibility: whether cancellations, spam leads or refunds can be identified in first-party reporting.

Because the selected event is immutable after campaign creation, test its measurement path first. Our Pixel vs Conversions API guide shows the failure cases to include.

Forecast costs with click math

A useful planning model stays explicit:

spend = valid clicks × average cost per valid click

attributed CPA = spend ÷ attributed conversions

business CPA = spend ÷ validated first-party outcomes

The last two denominators can diverge because attribution windows, consent, duplicates, refunds and unqualified events differ. Report both rather than treating a platform conversion as a completed business outcome.

Run a holdback or at least a stable comparison campaign when possible. Record creative, audience, budget, event definition and measurement release dates. A falling platform CPA after a tracking change is not necessarily a delivery improvement.

Launch gates

• The standard conversion event is valid, active and tested end to end.
• The team has accepted that billing remains click-based.
• The event has enough expected volume for a bounded experiment.
• Server and browser duplicates are reconciled.
• The reporting view separates click-through and eligible view-through attribution.
• Stop rules use spend, business outcomes and measurement health; not only dashboard CPA.

This is an ads optimization surface, not proof of broader answer-engine optimization. Keep paid delivery metrics separate from organic retrieval, citations and referrals.

Primary source

OpenAI: Conversion-optimized campaigns.

Limit: The feature is an open beta. This article explains the documented contract as reviewed on August 16, 2026; it does not report campaign performance or predict eligibility.

What each method actually does

The pixel uses the browser SDK and its oaiq("measure") call. The API is a server-to-server endpoint. That difference matters because a browser confirmation can disappear before the order system commits the transaction, while a server event can arrive without enough attribution data to connect it to an ad interaction.

OpenAI’s supported-event list includes page views, content views, checkout starts, orders, leads, trials, subscriptions, registrations, appointments and app events. Monetary values are integers in ISO 4217 minor units: for example, 19.99 USD is represented as 1999. Treat that rule as a schema test, not a formatting preference.

Build one event contract before installing either path

Start with the business event, then map the delivery methods to it. An order_created event should mean the same thing whether the browser or server sends it. Write down the trigger, required fields, clock, value rule, currency rule, identifier source, retry policy and cancellation treatment.

1. Name the source of truth. A thank-you page is not necessarily an order; the commerce database usually is.
2. Choose one stable event identifier. Generate it once and carry it across browser and server calls when both paths report the same action.
3. Preserve attribution identifiers. A reliable backend event that cannot be joined to an ad interaction may still be unusable for campaign reporting.
4. Queue server events. Retries should be idempotent, observable and bounded.
5. Quarantine invalid batch rows. Because one invalid event can reject a full API batch, validate locally before sending and split failures for repair.

This is the same discipline described in our AI visibility measurement crosswalk: keep the observed platform event separate from the first-party outcome it is supposed to represent.

View-through is a separate measure

Eligible accounts can receive view-through attribution through either implementation. OpenAI documents a fixed one-day view-through window and says click-through takes precedence. It also says view-through appears as a separate campaign metric, is not included in the Conversions column, and does not change optimization or billing, which remain click-through based.

That prevents a common reporting error: adding view-through results into click conversions and then comparing the inflated total with first-party orders. Keep four columns instead; click-attributed, view-attributed, deduplicated platform conversions and first-party outcomes.

Consent is another boundary. The pixel initializes consent as true unless you explicitly set it otherwise. Events blocked while consent is false are not replayed later. Your consent manager therefore has to set state before measurement calls and reinitialize accurately when the visitor changes a choice.

A release checklist that catches real failures

• Test one valid and one invalid payload for every enabled event.
• Confirm that a duplicate browser/server pair produces one business outcome in your reconciliation table.
• Send zero-value, multi-currency, refund and delayed-conversion test cases where applicable.
• Verify that consent-denied sessions do not send browser events.
• Alert on API rejection rate, queue age, missing identifiers and the gap between accepted events and first-party outcomes.
• Run the same checks after tag-manager, checkout, consent or backend releases.

For campaign optimization, continue with how ChatGPT conversion-optimized campaigns are billed. For broader attribution discipline, see how to track AI referrals in GA4 without inventing certainty.

Sources and limits

• OpenAI Ads Pixel documentation
• OpenAI Conversions API documentation
• OpenAI supported conversion events

Method note: This guide translates the documentation into an implementation and QA model. We did not run a live advertiser account, and eligibility, endpoints and fields may change during rollout. Verify the current account documentation before deployment.