A server event is a conversion signal your own server sends directly to an ad platform's conversions API, such as OpenAI's Conversions API for ChatGPT Ads, instead of firing it from the user's browser. It differs from a browser pixel event, which runs in the visitor's browser and breaks when ad blockers, cookie limits, or lost sessions get in the way.
If you advertise on ChatGPT and judge campaigns on conversions, server events decide whether OpenAI sees the sales, signups, and leads your ads actually produced. Skip them and your reported conversions undercount real results, so the platform optimizes toward the wrong audiences and you shift budget on bad numbers.
Server events are the server-to-server half of a conversion-tracking setup, sending event data from your backend systems straight to the ad platform without passing through a web page. In the ChatGPT Ads context, they post to OpenAI's Conversions API, the endpoint that records what happened after someone clicked your ad.
A single event payload carries the conversion type, hashed user identifiers like email and phone, the click reference OpenAI appends to ad traffic, and a unique event ID. That event ID lets OpenAI deduplicate, so a conversion tracked by both the pixel and your server counts once. Hashing lets the platform match the event to a user without exposing raw personal data.
Server events sit alongside the browser pixel, and most teams run both so the platform merges them into one conversion count. The pixel captures live browser actions; server events capture conversions the browser never sees, like a CRM stage change or an offline sale. AirOps helps teams plan and measure ChatGPT Ads so this conversion data lines up with the rest of their AI search reporting.
Resources: how to set up ChatGPT ads conversion tracking before your first impression
A server event travels a short, defined path from your systems to OpenAI's reporting. The flow mirrors Meta's and Google's conversions APIs, so the setup will feel familiar if you have run server-side tracking before.
Provision the source. In Ads Manager's conversions tab, create a data source to get a Pixel ID and an API key.
Capture the click. When someone clicks your ChatGPT ad, OpenAI appends a click reference to the landing URL; store it so your server can attach it later.
Build the payload. On conversion, your server assembles the event type, timestamp, hashed user data, the click reference, and a unique event ID.
Post to the API. Your server sends the event to OpenAI's Conversions API endpoint, authenticated with the API key.
Deduplicate and report. OpenAI matches the event ID against any pixel event, drops duplicates, and credits the conversion to your campaign.
The reporting then shows which campaigns and ads drove each conversion type. What it will not tell you is why a user converted, so pair the numbers with your own qualitative read.
Resources: how AirOps tracks where your ChatGPT ads appear across AI search
Server events are part of the buying decision for ChatGPT Ads. Whether the channel earns more budget depends on conversion numbers, and those numbers are only as complete as the events your server sends. Underreport them and the channel looks weaker than it is, which costs it budget it earned.
Accurate budget calls: Clean server events give you the true cost per conversion, so you scale or cut ChatGPT Ads on real results instead of browser-limited guesses, and you defend those calls to finance with numbers that hold up.
Recovered conversions: The browser pixel loses events to ad blockers, cookie limits, and cross-device journeys; server events recover those so your reported volume reflects what actually happened.
Better optimization: OpenAI's system learns from the conversions you report, so thin or missing server events train it toward the wrong buyers and quietly waste spend before you notice.
SEO managers use server events to feed offline and CRM conversions into ChatGPT Ads reporting so paid and organic performance sit in one view.
Growth marketers use server events to recover conversions the browser pixel drops, giving campaign optimization a fuller signal to learn from.
Demand gen leads use server events to pass qualified-lead and pipeline stages back to OpenAI so bids chase revenue instead of raw form fills.
Sending the same identifier as the pixel's event ID and the server event's ID lets OpenAI keep one copy of a conversion that both sources report, which stops the double-counting that would inflate your results and mislead campaign optimization.
OpenAI appends a click reference to ad traffic that your server must capture and attach to each event, because without it the platform cannot connect a conversion to the ad click that earned it, and attribution breaks down entirely.
User details like email and phone are hashed with SHA-256 before they leave your systems, so the platform can match a conversion to a user while the raw personal data stays private and consent choices are respected.
Recover conversions the browser pixel misses to ad blockers, cookie limits, and lost sessions.
Feed offline, CRM, and subscription events into ChatGPT Ads that a browser never sees.
Deduplicate against the pixel so each conversion counts once in OpenAI's reporting.
Protect user privacy by sending only hashed identifiers to the platform.
Improve OpenAI's optimization with a fuller, more reliable conversion signal.
Run the pixel and server events together: the pixel captures live browser actions while the server fills gaps, giving the most complete signal.
Share one event ID across both sources: matching IDs let OpenAI deduplicate, so a single conversion never counts twice.
Capture and pass the click reference: your server needs it to tie each conversion to the ad that drove it.
Hash user identifiers before sending: SHA-256 on email and phone keeps personal data private and still lets the platform match users.
Send events close to real time: OpenAI expects recent timestamps, so delayed batches can fall outside the accepted window and go uncredited.
Reconcile reported conversions against your source systems weekly: regular checks catch dropped or duplicated events before they skew decisions.
Avoid firing server events without a shared event ID and then also running the pixel, a mistake even experienced teams make: OpenAI counts the same conversion twice, your cost per conversion looks artificially low, and you scale spend on numbers that were never real.
AirOps: plans and measures ChatGPT Ads campaigns so the conversions carried by your server events line up with your wider AI search reporting.
Google Tag Manager Server-Side: hosts a server container that forwards conversion events to OpenAI's Conversions API without custom backend code.
Google Analytics 4: supplies the event definitions and conversion data many teams map into the server events they send to ChatGPT Ads.
Audit your current tracking. This week, list every conversion you care about and check which ones the browser pixel already captures and which ones it misses. No budget or approval needed.
Create a data source. In ChatGPT Ads Manager's conversions tab, set up a data source to generate your Pixel ID and API key.
Capture the click reference. Make sure your site stores the click reference OpenAI appends to ad traffic so your backend can attach it to each conversion.
Build and send the payload. Have your server, or a server-side tag manager, assemble each event with a type, timestamp, hashed user data, the click reference, and a shared event ID, then post it to the Conversions API.
Verify and reconcile. Confirm events arrive in Ads Manager, check deduplication against the pixel, and reconcile reported conversions against your source systems before scaling spend.
A server event is a conversion sent server-to-server from your systems to an ad platform's conversions API, bypassing the browser.
In ChatGPT Ads, server events post to OpenAI's Conversions API with an event type, hashed user data, a click reference, and a unique ID.
A shared event ID is the constraint that makes pixel and server data combine cleanly without double-counting.
The main risk is inflated or missing conversions that push the platform to optimize toward the wrong buyers.
The leverage is recovering conversions the browser cannot see, giving OpenAI a fuller signal to spend against.
A server event is sent from your own servers to OpenAI's Conversions API, while a browser pixel event fires from the visitor's browser. That difference matters because the browser is an unreliable messenger: ad blockers, cookie restrictions, Safari and iOS limits, and abandoned sessions all stop pixel events from reaching OpenAI. A server event leaves your backend after the conversion is confirmed, so it survives those obstacles and can also report conversions that never touch a browser, such as a phone sale, a CRM stage change, or a subscription renewal. The two are complements, and OpenAI describes the server-side path as the more reliable source. Most teams run both and tie each pair together with a shared event ID so OpenAI keeps one record. The practical rule: use the pixel for live browser signals and server events for completeness and resilience, then deduplicate so nothing counts twice.
Send a server event as soon as the conversion is confirmed, and keep the timestamp recent. OpenAI's Conversions API expects events from close to real time, so a purchase, signup, or lead should post within minutes or hours instead of days later. Delayed events risk falling outside the accepted timestamp window, and anything that arrives too late may go uncredited to your campaign. For online actions, fire the event the moment the order or form submission completes. For offline or downstream actions, like a sales-qualified lead or a renewal, send the event when your system records the status change, and include the original click reference you captured earlier so OpenAI can still match it to the ad. If you batch events for efficiency, keep batches frequent, posting on a short cycle, and confirm each one lands. The goal is simple: report conversions quickly and accurately enough that OpenAI's optimization learns from fresh, complete data.
Server event and pixel counts vary because the two sources see different slices of the same activity. The pixel only fires when a browser loads it, so ad blockers, privacy settings, quick exits, and cross-device journeys all cause it to undercount. Server events run from your backend and catch conversions the browser missed, including offline and delayed actions, so they often report more. Deduplication then reconciles the overlap: when both sources send the same event ID, OpenAI keeps one record, which can make the combined total lower than adding the two raw numbers. Variance also comes from timing, since a late server event may land in a different reporting window than its pixel counterpart, and from match quality, since events with weak or missing identifiers are harder to attribute. Some gap between the two is normal and healthy. A large, persistent gap usually points to a pixel that is blocked or a server feed that is dropping events.
Yes, you directly control server events more than almost any other part of ChatGPT Ads measurement, because you own the code and data that send them. You decide which conversions to report, how to structure each payload, which hashed identifiers to include, and whether the click reference is attached correctly. That control is also the responsibility: OpenAI only credits what your server sends and can match, so a missing identifier, a dropped click reference, or a malformed event means a real conversion goes uncounted. What you do not control is OpenAI's attribution model, the lookback windows, or how the platform ultimately assigns credit across touchpoints. The practical move is to get the inputs right: send complete, correctly hashed, well-timed events with a consistent event ID, and verify they arrive. Do that, and you influence reported performance as much as the system allows. Neglect it, and you hand the platform incomplete data to optimize against.
A healthy server event setup shows most of your real conversions arriving and matching to a click, with only a small, stable gap from the pixel. OpenAI does not publish a single universal match-rate benchmark, so treat completeness and consistency as your targets instead of chasing a fixed percentage. Practically, aim for server events that recover the conversions the pixel misses, a deduplication rate that keeps combined totals sensible, and match quality high enough that most events carry a valid click reference and hashed identifiers. Watch the trend more than any one number: a match rate that holds steady week over week is a good sign, while a sudden drop signals a broken click capture, a consent change, or a feed that stopped sending. Reconcile reported conversions against your own source systems to set a baseline you trust, then flag any swing beyond your normal range. Good looks like stable, explainable numbers you can defend.