The Trial Started event (trial_started) is a standard ChatGPT Ads conversion event that fires when someone begins a free trial on your site after clicking an ad in ChatGPT. It reports a specific funnel action with a plan_enrollment data shape, so it is narrower than a generic page view or a lead form submission.
For a marketer running trial-led acquisition, choosing this event as your optimization goal tells OpenAI which clicks to favor, which directly shapes who sees your ads. Skip it and you optimize toward traffic that never enters your trial, spending budget on clicks that never signal real intent.
A Trial Started event marks the moment a user enters a free trial, recorded against your ChatGPT Ads Pixel ID so OpenAI can attribute it to an ad click. It uses the plan_enrollment data shape and accepts optional fields such as plan_id, amount, and currency to describe the trial being started.
You can send it two ways. The browser pixel fires it with an oaiq("measure", "trial_started", ...) call when the trial confirmation loads, and the server-side Conversions API posts it from your backend once the trial is created. Running both and joining them on a shared event ID gives OpenAI a more complete, deduplicated signal, since the Conversions API is the more reliable of the two sources.
It sits alongside the other standard events like subscription_created and registration_completed, each mapping to a different funnel stage. A custom event modeling the same action cannot serve as a campaign optimization goal, while trial_started can. AirOps helps teams track which content and campaigns drive ChatGPT referral traffic into trial sign-ups, so the signal you send back connects to the pages doing the work.
Resources: see practical tips for setting up and optimizing ChatGPT Ads conversion campaigns.
Tracking a trial start runs from a user action on your site back to OpenAI's attribution system. Each step has to line up or the conversion never counts.
Install the pixel: Add the oaiq loader near the top of your site and initialize it with your Pixel ID so events can fire.
Map the action: Decide exactly what counts as a trial start, usually the confirmation page or the backend event that creates the trial record.
Fire the event: Send trial_started with the plan_enrollment data and any optional fields like plan_id and amount, from the pixel, the Conversions API, or both.
Deduplicate: OpenAI matches on Pixel ID, event name, and a shared event ID, keeping the first event it receives and ignoring later copies.
Attribute and optimize: OpenAI ties the event to the originating ad click and, if you nominated it as your conversion goal, biases delivery toward clicks likely to start a trial.
The result tells you how many trial starts your ChatGPT Ads drove and which clicks earned them. It stops short of showing whether those trials convert to paid plans, which you measure separately with subscription_created.
Whether you fund ChatGPT Ads from a performance budget depends on seeing real trial sign-ups, and raw click counts alone will never settle that question. The Trial Started event is the signal that turns a trial-led funnel into something you can optimize and defend.
It feeds conversion optimization: when you nominate trial_started as your campaign goal, OpenAI uses it alongside ad quality and click likelihood to favor clicks more likely to start a trial, instead of spreading budget evenly across everyone who sees the ad.
It proves ad value: without a trial start signal, you cannot tell which clicks generated real funnel movement, so trial-led campaigns get cut in the next budget review even when they were quietly working.
It keeps the funnel honest: mapping trial_started to one precise action keeps your ChatGPT Ads reporting consistent with how you already define a trial in your own analytics, so the numbers reconcile across tools.
Growth marketers use the Trial Started event to optimize ChatGPT Ads campaigns toward the clicks that actually begin a free trial.
Demand gen leads use the Trial Started event to prove ChatGPT-sourced traffic enters the trial funnel and earns continued performance budget.
SEO managers use the Trial Started event to connect ChatGPT referral visits with the downstream trial sign-ups on pages they optimize.
The Trial Started event carries the plan_enrollment data shape, which lets you attach optional fields like plan_id, amount, and currency so OpenAI records not just that a trial began but which plan and value it represents.
Because the same trial start can fire from both the browser pixel and the Conversions API, OpenAI deduplicates using the combination of Pixel ID, event name, and a shared event ID, keeping the first copy it receives and discarding the rest.
Only standard events like trial_started can be selected as the conversion goal for an oCPC campaign, so a custom event modeling the same action will not appear as a selectable option when you build a conversion-optimized campaign in Ads Manager.
Optimize ChatGPT Ads delivery toward clicks likely to start a free trial.
Attribute trial sign-ups back to the specific ad click inside ChatGPT.
Capture plan and value detail with optional plan_id, amount, and currency fields.
Deduplicate pixel and Conversions API signals into one reliable conversion.
Prove performance so trial-led ChatGPT Ads campaigns survive budget review.
Align OpenAI's reporting with the trial definition in your own analytics.
Fire trial_started only at genuine trial creation, so the signal stays clean and optimization has accurate data to learn from.
Send the event from both the pixel and the Conversions API, since the server-side source is more reliable and the pair deduplicates into one event.
Reuse a single event ID across both sources, because deduplication keys on Pixel ID, event name, and that shared ID.
Attach plan_id, amount, and currency where you have them, so value-based reporting and future optimization have richer data.
Confirm you have enough weekly trial volume before choosing trial_started as your oCPC goal, because thin signal starves the optimizer.
Keep your trial_started definition identical to the one in your own analytics, so numbers reconcile across tools.
Avoid locking a conversion campaign to trial_started when only a handful of trials start each week. The objective and the event are permanent after campaign creation, so a low-volume goal leaves the optimizer with too little signal and no way to switch without rebuilding the campaign.
AirOps: connects ChatGPT referral traffic and content performance to trial sign-ups, so you can see which pages and campaigns drive the Trial Started events you optimize toward.
Google Tag Manager: fires the trial_started pixel call on the right trigger without hard-coding it into your site, keeping event rules manageable.
Google Analytics 4: cross-checks trial starts recorded in your own funnel against what ChatGPT Ads attributes, so you can reconcile the two.
Define the trigger: Decide exactly which action counts as a trial start, usually the trial confirmation page or the backend record that creates the trial. You can do this today with no budget.
Install the pixel: Add the oaiq loader with your Pixel ID near the top of your site so events can fire on the pages that matter.
Fire trial_started: Implement the measure call or Conversions API post with the plan_enrollment data and any optional fields like plan_id and amount.
Verify and deduplicate: Confirm the event arrives from both sources with a shared event ID, and check it appears in your ChatGPT Ads conversion source.
Select it as a goal: Once weekly volume is steady, nominate trial_started as your conversion objective so OpenAI optimizes delivery toward trial starts. Remember the objective locks at campaign creation, so confirm the event is firing cleanly before you commit to it.
The Trial Started event is a standard ChatGPT Ads conversion that fires when a user begins a free trial after an ad click.
It is measured by firing trial_started from the browser pixel or Conversions API, carrying the plan_enrollment data shape.
The main constraint is signal volume, since optimization needs enough weekly trial starts to learn from.
The main risk is permanence, because the objective and event lock at campaign creation and cannot change without a rebuild.
The leverage sits in choosing trial_started as your conversion goal, which steers delivery toward clicks that actually start trials.
They mark two different points in the same funnel, so they answer different questions. The Trial Started event fires when someone enters a free trial, while subscription_created fires when a paid plan begins, which is often days or weeks later. If you optimize ChatGPT Ads toward trial starts, you push for volume at the top of the trial funnel and accept that some of those trials will never convert. If you optimize toward subscription_created, you push for paid revenue but usually have far less signal to work with, because fewer people reach that stage each week. Most trial-led teams track both: trial_started as the early, higher-volume signal that an optimizer can learn from, and subscription_created as the proof that trials turn into revenue. Mapping each event to one precise action keeps the two measurements clean and comparable.
Fire it at the exact moment a trial is created, never on an earlier page view or a vague load. In practice that means the trial confirmation screen for a browser pixel call, or the backend event that writes the trial record for a Conversions API post. Firing too early, such as on a pricing page, inflates your count with people who never actually start a trial and teaches the optimizer the wrong pattern. Firing late or inconsistently loses conversions and weakens attribution. If you send from both the pixel and the Conversions API, fire both for the same trial and give them a shared event ID so OpenAI treats them as one. For server-side sends, remember the event timestamp has to fall within the last seven days, so do not batch trial events on a long delay.
Counts vary mostly because of attribution scope and timing, and a gap rarely means tracking is broken. Your ChatGPT Ads reporting only counts trial starts it can attribute to an ad click within the attribution window, while your internal analytics counts every trial from every source, so your own number is almost always higher. Deduplication also shapes the count: if the pixel and Conversions API send the same trial without a shared event ID, you can double-count, and if event IDs collide you can under-count. Timing adds more drift, since server-side events must arrive within a few days and late sends get dropped. Consent and ad-blocking reduce browser pixel firing, which is part of why the server-side source is treated as more reliable. The fix is to reconcile definitions, align event IDs, and expect a steady, predictable gap instead of an exact match between the two systems.
Partly, and the parts you control are worth pressing on. You cannot force OpenAI to serve your ad to a given person, so you do not control trial volume directly. What you do control is whether trial_started is your campaign's conversion goal, which tells the optimizer to favor clicks likely to start a trial, and the quality of the landing experience that turns those clicks into trials. You also control the accuracy of the signal: a clean, correctly timed event with good plan_enrollment data gives the optimizer better material to learn from. Beyond the ad, your trial offer, page speed, and sign-up friction move the conversion rate more than any targeting lever. So the honest answer is that you influence trial starts indirectly, by sending a precise signal and removing friction, and then letting OpenAI's optimization do the matching it is designed to do.
A good volume is enough weekly trial starts for OpenAI's optimizer to find a pattern, and that threshold matters more than any absolute number. As a working rule, a conversion event needs steady weekly signal before it can reliably steer delivery, so an event that fires only a handful of times a week is usually too thin to optimize on. If your trial starts are sparse, optimize toward a higher-volume upper-funnel event such as lead_created or registration_completed and treat trial_started as a reporting metric until volume grows. There is no public universal benchmark number from OpenAI, so judge it by whether your campaign's performance stabilizes instead of swinging week to week. Watch for the optimizer settling into consistent cost per trial, because that stability is the real sign you have enough signal. When volume is thin, borrow signal from the stage above and keep trial_started as the goal you graduate to.