A custom event name is the label you assign to a ChatGPT Ads conversion when the action you want to measure falls outside OpenAI's list of standard events. It is not a standard event like lead_created or order_created; it is a name you invent for a conversion OpenAI does not define, such as quote_requested.
If your real conversion sits outside the standard taxonomy, a custom event name is how it reaches reporting and, paired with a standard event, bidding. Name it inconsistently across your pixel and Conversions API and the platform splits one conversion into two, so your counts inflate and optimization starves.
Inside ChatGPT Ads conversion tracking, a custom event name is the identifier that tells OpenAI which self-defined action a measured event represents when the event type is set to custom. You reach for it whenever the thing you count has no match in OpenAI's standard event list, so the name itself becomes the key the platform groups and reports those conversions under.
The name follows strict rules: 1 to 64 characters, letters, numbers, underscores and dashes only, starting and ending with a letter or number, and it must not reuse a standard event name. You pass it in the dedicated custom_event_name field, which sits in the event options, separate from the event data, on both the browser pixel and the server-side Conversions API.
A custom event name sits next to two adjacent pieces: the event type, which flags the event as custom, and the event ID, which handles deduplication. AirOps tracks how your ChatGPT Ads conversions and AI visibility move together, so a named custom event becomes a measurable line in your answer-engine reporting instead of a loose tag.
Resources: See how to structure ChatGPT Ads conversion tracking and campaign setup
A custom event name only works when the same string travels cleanly from your site through to Ads Manager. The mechanism runs in order.
Define it. In Ads Manager, create a conversion event, choose the custom type, and enter the name along with its attribution window and source.
Fire it. When the action happens, your pixel or Conversions API call sends the event with the name placed in the custom_event_name field, separate from the event data.
Match it. Send the identical name on both the pixel and the Conversions API so OpenAI recognizes them as one event.
Attribute it. OpenAI connects the event to an eligible ad click using the preserved click reference within the window you set.
Report it. The named conversion appears in reporting, grouped under that exact string.
The output tells you which self-defined actions converted and from which campaigns. It does not confirm the event is firing correctly, and a custom event alone cannot serve as a bidding optimization target.
Choosing to track a custom event name is a measurement decision that changes what your ChatGPT Ads budget is allowed to optimize toward. Standard events cover common outcomes, but the moment your real conversion sits outside that list, the custom name is the only way the outcome enters the platform at all.
It captures outcomes the taxonomy misses. A quote request, a configurator completion, or a high-intent page view has no standard event, so without a custom name the conversion never reaches Ads Manager.
It protects reporting accuracy. A name typed differently on the pixel and the Conversions API splits one conversion into two signals, inflating counts and corrupting the numbers you report upward.
It bounds what bidding can do. A custom event cannot be an optimization target on its own, so a measurement plan built only on custom names leaves automated bidding with nothing to optimize against until a standard event fires alongside it.
SEO managers use a custom event name to track pricing-page or documentation visits that signal high intent from ChatGPT Ads traffic.
Content strategists use a custom event name to measure which gated assets convert visitors arriving from answer-engine placements.
Growth marketers use a custom event name to log product-qualified actions, like a configurator finish, that no standard event covers.
Standard events are OpenAI's predefined conversions with fixed names and required data shapes, while a custom event is any action outside that taxonomy, identified only by the string you assign to it and reportable only under that exact name.
When the same conversion fires from both the pixel and the Conversions API, OpenAI matches on Pixel ID, event name, and event ID, so the custom name and the shared identifier must be identical on both sides, or the platform counts one real conversion twice.
The attribution window you set on the event determines how long after an ad click a matching custom event still counts as a conversion, which directly shapes how many of these conversions ever appear in your reporting.
Measure conversions that OpenAI's standard event list does not cover.
Group related actions under one consistent, reportable label in Ads Manager.
Feed accurate counts into reporting by keeping the name identical across the pixel and Conversions API.
Support automated bidding when paired with at least one standard event firing in parallel.
Audit which campaigns rely on each named event before retiring it.
Name the event for the real outcome, so the label reads clearly in reporting months later without a lookup.
Keep the name identical on the pixel and the Conversions API, because deduplication matches on that exact string.
Follow the format rules up front: 1 to 64 characters, letters, numbers, dashes and underscores, starting and ending with a letter or number.
Pair every custom event with a standard event firing alongside it, so conversions bidding has a valid optimization target.
Verify the event is actually arriving in Ads Manager before you assign it to a live campaign, since a defined setting does not prove delivery.
Document each name and the campaigns using it, so retiring one does not quietly break bidding elsewhere.
Avoid treating a custom event name as proof that tracking works. A setting can exist in Ads Manager while the pixel is missing, the server call is silent, or the string is misspelled on one side, and the conversion will never match.
AirOps: Connects your ChatGPT Ads conversion signals with AI visibility data, so a named custom event becomes a tracked line in your answer-engine reporting instead of an isolated tag.
Google Tag Manager: Fires the pixel or Conversions API call and places the custom event name in the correct event-options field without hand-editing site code.
Google Analytics 4: Mirrors the same conversion into your analytics stack so you can reconcile ChatGPT Ads counts against your own event data.
Confirm the gap. Check OpenAI's standard event list this week and decide whether your target action genuinely has no standard match before inventing a name.
Choose the name. Write a clear, format-valid string that describes the outcome, and record it where your team can find it.
Create the setting. In Ads Manager, add the conversion event as a custom type, set its source, and set an attribution window.
Implement the call. Fire the event from the pixel or Conversions API with the name in the custom_event_name field, matching it exactly on both sides.
Verify and pair. Confirm the event arrives in Ads Manager, then make sure a standard event fires alongside it so conversions bidding has something to optimize toward.
A custom event name is the label you assign to a ChatGPT Ads conversion that falls outside OpenAI's standard event list.
It is measured by firing the named event from the pixel or Conversions API and matching the string on both sides.
The main constraint is the format: 1 to 64 characters, limited character set, no reuse of a standard event name.
The main risk is an inconsistent name, which splits one conversion into two and inflates reported counts.
The leverage is pairing a custom event with a standard one, which enables automated bidding the custom name alone cannot support.
A standard event is one of OpenAI's predefined conversion types, each with a fixed name and a required data shape, while a custom event name is a label you create for any action the standard list does not cover. The practical difference is where each one can be used. Standard events plug directly into conversions bidding, so the platform can optimize delivery toward them. A custom event enters reporting under the name you choose, but it cannot act as an optimization target on its own. That means custom names are best for capturing outcomes the taxonomy misses, while a standard event still needs to fire somewhere in your measurement plan for automated bidding to work at all. Choose a standard event whenever one genuinely matches your outcome, and reserve custom names for the actions that have no standard equivalent, such as a quote request or a specific high-intent page view that matters to your business.
Create as few as cleanly describe the distinct outcomes you actually act on, never one for every click on the site. Each custom event name you define becomes a line you have to implement correctly, keep consistent across the pixel and Conversions API, and audit before retiring, so volume adds maintenance without adding insight. A good rule is to name only the conversions that change a decision: how you judge a campaign, where you shift budget, or what you report upward. If two actions always lead to the same decision, one name usually covers both. Before adding another, check whether a standard event already represents the outcome, since reusing a standard event is simpler and makes the conversion eligible for bidding. Keep a short, documented list that shows each name and the campaigns relying on it, and prune names that no campaign uses so the account stays legible and your reporting does not fill with events nobody reviews.
The most common cause is the name itself not matching exactly on both sides. OpenAI deduplicates using the Pixel ID, event name, and event ID, so if the pixel sends one spelling and the server sends another, the platform sees two different events instead of one, and your counts diverge. Beyond naming, timing and delivery explain variance: browser events can be blocked by consent settings or ad blockers, while server-side events through the Conversions API often arrive when the pixel does not, so the two sources rarely report identical totals even when configured well. Attribution windows and event IDs also matter, because a mismatched or missing ID prevents the platform from collapsing duplicates. To narrow the gap, confirm the custom event name is byte-for-byte identical in both calls, send a shared event ID on both, and verify each source is actually firing. Some variance is normal; a large, persistent gap usually points to a configuration mismatch worth fixing.
Technically you can rename or create a new custom event name at any time, but doing so mid-campaign breaks continuity, so plan it carefully. Because the platform groups conversions under the exact string, a new name starts a fresh, empty bucket: historical conversions stay under the old name and new ones accumulate under the new one, which fragments your trend data and can disrupt any bidding that depended on the original signal. If you must change it, treat it as a migration instead of a quick edit. Update the name in Ads Manager and in every pixel and Conversions API call at the same time, so the two sides stay matched, and expect a short window where reporting looks thin while data rebuilds under the new label. Where possible, settle on a durable, outcome-based name before launch so you never need to rename. If the goal is only a cleaner report label, consider whether living with the original name is less disruptive than migrating.
A good setup is one where every named event maps to a real business outcome, fires reliably, and reports a number you trust. In practice that means the name is clear and format-valid, it is identical on the pixel and the Conversions API, and a shared event ID lets the platform deduplicate across both sources. The event sits inside an event setting with a deliberate attribution window and a known source, and you have verified actual delivery in Ads Manager instead of assuming the setting alone proves tracking. Crucially, at least one standard event fires alongside your custom events, so conversions bidding has a valid optimization target. You should also be able to point to which campaigns use each name, so retiring one does not silently break bidding. If you can answer what each custom event measures, confirm it is arriving, and show it reconciles with your own analytics, the setup is in good shape.