An event timestamp is the exact moment a conversion happened, recorded in milliseconds since the Unix epoch, attached to every event you send to a platform like the ChatGPT Ads Conversions API. It records when the action actually occurred, which differs from when you send the event to the platform.
For conversions to land on the right day and the right campaign, the timestamp has to reflect reality, because the platform uses it to place each conversion in its reporting. Send a stale timestamp and OpenAI rejects the event, so your ChatGPT Ads performance looks worse than it really is.
Measured in milliseconds since the Unix epoch, an event timestamp is the single time field on each conversion you report to an answer-engine ad system, fixing exactly when the action occurred. In the ChatGPT Ads Conversions API, OpenAI requires it on every event as a 13-digit millisecond value.
The value has to describe the real moment of the action. The time your server sends the request does not belong in this field. OpenAI validates each timestamp against a fixed freshness window and rejects anything that arrives too old or dated too far in the future. Because one bad event fails the whole batch, a single mis-dated timestamp can block up to 1,000 events at once.
An event timestamp sits inside the broader measurement stack that connects ChatGPT Ads clicks to outcomes, working alongside the click reference, event id, and user-matching fields. It controls when a conversion counts, while attribution windows decide whether a click earns credit for it. AirOps helps teams measure how AI search and AI ads influence pipeline, keeping reported timestamps aligned with the visibility data you track.
An event timestamp is set when the conversion fires and travels with it all the way into OpenAI's reporting.
Capture. When the conversion fires, your site or server reads the time in milliseconds since the Unix epoch and stores it as the event's timestamp.
Attach. You add that value to the payload as timestamp_ms, next to the event id and type, in the pixel call or server Conversions API request.
Validate. OpenAI checks the timestamp against its freshness window and rejects any event dated too far in the past or future, failing the whole batch if one event is out of range.
Deduplicate. The event id and timestamp help OpenAI recognize the same conversion arriving from both the pixel and the Conversions API, so it counts once.
Report. OpenAI files the conversion on the day the timestamp names and matches it to the ad interaction inside the attribution window.
The timestamp tells you when each conversion happened and lets the platform slot it into the right reporting day. It does not tell you whether a conversion is new or which ad deserves credit; dedup and attribution windows handle those.
Event timestamps decide whether your ChatGPT Ads numbers are trustworthy enough to spend real budget against. If the timing is wrong, you either lose conversions the platform refuses to record or you credit them to the wrong day, and both push your budget decisions off the real data.
Clean reporting: Accurate timestamps place each conversion on the day it actually happened, so your cost-per-conversion and ROAS reflect what truly drove results instead of when your server happened to send the data.
Lost conversions: Send an event with a timestamp older than OpenAI's window and the platform rejects it, and because one bad timestamp fails the whole batch, it quietly erases conversions you actually earned.
Reliable optimization: OpenAI's bidding and conversion-optimized campaigns learn from the events you feed them, so mis-dated timestamps teach the system the wrong patterns, waste spend, and distort your future bids.
SEO managers use event timestamps to confirm that ChatGPT Ads conversions land on the correct day before comparing them against organic AI-search visibility trends.
Growth marketers use event timestamps to send offline and CRM conversions within OpenAI's freshness window so late-stage pipeline still reaches the ad platform.
Demand gen leads use event timestamps to reconcile server-side conversions with pixel events so reported ChatGPT Ads performance matches their own revenue records.
An event timestamp must be a 13-digit Unix value in milliseconds, and a common mistake is sending a 10-digit value in seconds, which is too short for OpenAI to read, so the event silently fails to attribute to any campaign.
OpenAI accepts an event only when its timestamp falls inside a recent freshness window, which caps how late you can report offline sales, CRM stage changes, and other delayed conversions before the platform refuses them entirely.
The timestamp has to record when the conversion actually happened, because logging the moment your server fired the request instead will shift the conversion onto the wrong reporting day and distort both daily performance and campaign comparisons.
Keep ChatGPT Ads reporting accurate by dating every conversion to the moment it happened.
Protect conversions from rejection by sending timestamps inside OpenAI's freshness window.
Feed cleaner signals to OpenAI's conversion-optimized bidding so it learns from real timing.
Match server-side and pixel events to the same conversion using a shared event id and timestamp.
Reconcile ChatGPT Ads conversions against your own revenue data by comparing when actions actually occurred.
Record the timestamp at the moment the conversion fires, because reading it later drifts the event off its true time.
Send timestamps in milliseconds as a 13-digit value, since a seconds-based value is too short and will not attribute.
Report offline and CRM conversions quickly, because OpenAI's freshness window rejects events that arrive too late.
Use the same event id and timestamp across the pixel and Conversions API, so OpenAI counts each conversion once.
Validate a test batch before going live, because one out-of-window timestamp fails every event sent with it.
Store timestamps in UTC, so time zone handling on your servers does not shift conversions to the wrong day.
Avoid the common shortcut of stamping events with the time your server sends them instead of the time the action happened; it is easy to code and it quietly moves conversions onto the wrong day, which corrupts the daily numbers you optimize against.
AirOps: connects your ChatGPT Ads conversion data with AI-search visibility signals so you can see how answer-engine discovery turns into pipeline.
OpenAI Ads Manager: generates the Pixel ID and Conversions API keys and shows an event stream where you can confirm incoming timestamps during setup.
Google Analytics 4: records server-side conversion events with their own event timestamps, giving you a second source to reconcile against ChatGPT Ads reporting.
Map your conversions. List the actions worth tracking, such as signups, leads, and purchases, and note where each one fires. You can do this today in a spreadsheet with no budget approval.
Set up measurement. In OpenAI Ads Manager, create your Pixel ID and a Conversions API key so you have somewhere to send events and their timestamps.
Capture the real event time. Update your site or server code to read the moment each conversion happens in milliseconds since the Unix epoch and store it on the event.
Attach and validate timestamps. Add the value as timestamp_ms on every event and run a validation-only test batch to confirm OpenAI accepts your timing before you go live.
Monitor and reconcile. Watch the event stream and your reporting for rejected or mis-dated events, and compare conversion days against your own revenue records to catch timing drift.
An event timestamp is the exact time a conversion happened, sent with every event to a platform like the ChatGPT Ads Conversions API.
It is recorded as a 13-digit value in milliseconds since the Unix epoch, captured when the action fires.
OpenAI only accepts timestamps inside a short freshness window, so late offline conversions cannot always be reported with their true date.
A single out-of-window timestamp fails the whole batch it travels in, quietly erasing conversions you earned.
Capturing the real event time at the source is the highest-leverage habit, because every downstream report and bid depends on it.
An event timestamp records when a conversion happened; an attribution window decides whether an ad click can take credit for it. The two are easy to confuse because both deal with time, but they do separate jobs. The timestamp is a single moment you attach to each event you send, measured in milliseconds, and OpenAI uses it to place the conversion on a reporting day. The attribution window is a configured period after an ad interaction during which an outcome can still be credited to that interaction. You can report a conversion with a valid, recent timestamp and still have it fall outside the attribution window, in which case the conversion is recorded but not credited to your ChatGPT Ads. Keeping the two ideas separate stops you from blaming the timestamp for an attribution result, or the reverse.
An event timestamp has to be recent: OpenAI accepts conversion events only when the timestamp falls within the last 7 days and no more than 10 minutes into the future, and rejects anything outside that range. This is a freshness limit on when the platform will ingest the event, and it is separate from how long a click stays eligible for credit. The practical effect is that you cannot sit on conversions. If a lead converts on a Monday, you have until the following Monday to report it with its real date, after which OpenAI refuses the event. For offline or CRM conversions that trickle in, send them on a short, regular schedule. Teams often process their event queue every few minutes so nothing ages out and a clock-skew issue does not push a timestamp into the future.
Conversions land on the wrong day when the timestamp you sent describes the wrong moment, and the platform simply files the event where that timestamp points. The most common cause is logging the time your server processed or sent the event instead of the time the customer actually converted; those can differ by minutes or hours around midnight and tip a conversion into the next day. Time zone handling is the other frequent culprit: if your servers report local time while the platform expects UTC, every conversion can shift by several hours. Batching also plays a role, because a conversion held in a queue and stamped at send time inherits the send moment, hiding the true action time. Clock drift on the sending machine can do the same on a smaller scale. The fix in every case is to capture the real event time at the source, in UTC milliseconds, the instant the conversion happens.
Yes, the event timestamp is entirely under your control, because you set it in the code that sends each conversion. Unlike the click reference that the pixel captures from the landing page URL, the timestamp is not something OpenAI generates for you; your system decides what value to put in the timestamp_ms field. That control is exactly why it matters: a mistake in your code becomes a mistake in your reporting. To use that control well, read the system clock at the moment the conversion event fires, convert it to milliseconds since the Unix epoch, and write it immediately onto the event object before any queue or batch step can overwrite it. Keep your servers synced to accurate time and work in UTC so the value is consistent. If you send the same conversion from both the browser pixel and the Conversions API, use the same timestamp and event id on both so OpenAI treats them as one.
A healthy event timestamp setup is one where every conversion carries the real action time, in UTC milliseconds, and almost none get rejected for being out of range. Practically, that means your rejection rate in the OpenAI event stream sits near zero, your reported conversion days match what you see in your own systems, and offline conversions reach the platform well inside its freshness window. A good setup also captures the timestamp at the source instead of at send time, so queuing and batching do not distort it, and it uses the same timestamp and event id across the pixel and Conversions API so nothing double-counts. There is no published industry benchmark for timestamp accuracy, so treat your own reconciliation as the standard: if conversion counts and dates line up between OpenAI and your revenue records day after day, your timestamps are doing their job. Persistent gaps or rejected events are the signal to audit your capture code.