Page viewed (page_viewed) is a standard conversion event in ChatGPT Ads that records when someone lands on or opens a page after clicking or seeing your ad, fired through OpenAI's measurement pixel or Conversions API. It signals that a visit happened and stops short of outcome events like order_created and lead_created, which record a purchase, lead, or sign-up.
If you advertise on ChatGPT, page_viewed is the baseline that tells you whether your ad clicks reach a working landing page before you judge deeper conversions. Skip it and you spend against a green-looking pixel with no proof traffic arrived, so a broken redirect can drain budget for a week unnoticed.
The page viewed (page_viewed) event is the signal OpenAI logs each time a tracked page loads for a visitor tied to your ChatGPT Ads account. It uses the contents data type and can carry optional contents, amount, and currency fields. Because the base pixel snippet includes a page_viewed call, it fires automatically wherever the pixel loads.
Two pieces make it work: the OpenAI measurement pixel (oaiq) placed in the head of your pages, and a Pixel ID generated in the Conversions tab of Ads Manager. You can also send the event server-side through the Conversions API and join the two with a shared event identifier, so OpenAI counts the pair once. A click reference called oppref on your landing URL lets the pixel tie a later view back to the ad click.
Among the standard events, page_viewed sits at the top of the funnel, below contents_viewed for specific product views and far below purchase or lead events. Treat it as your reach and delivery check before you layer the conversions that prove revenue. AirOps connects your ChatGPT ad activity to the organic prompts you already track.
Resources: a practical guide to running ChatGPT Ads, from targeting to conversion tracking
The event runs the same path every time, from pixel load to a counted conversion in Ads Manager. Here is the sequence a single page_viewed follows.
Install. Place the oaiq pixel in the head of every page and initialize it with your Pixel ID from the Conversions tab of Ads Manager.
Click tag. When a visitor clicks your ad, OpenAI appends an oppref click reference to the landing URL, which the pixel stores in a first-party cookie.
Fire. On page load the base snippet sends a page_viewed event with the contents data type, automatically and without extra code.
Dedupe. If you also send the event through the Conversions API, a shared event identifier lets OpenAI merge the browser and server copies into one.
Attribute. OpenAI matches the event to your campaign and its attribution window, then reports it in Ads Manager.
The output tells you a tracked page loaded and which ad click it followed. It does not tell you a visitor bought, booked, or signed up, so pair it with outcome events before you read it as performance.
ChatGPT Ads is a young channel, and the first decision you make is whether your spend is even reaching a working page. page_viewed answers that before you commit budget to deeper conversions, which is why it belongs in your setup from day one of the campaign.
Proves delivery: It confirms that clicks from your ad actually load the page you paid to send them to, so a broken redirect or blocked tag shows up as missing page views instead of silent wasted spend you would otherwise miss for days.
Anchors attribution: Because the pixel reads the oppref click reference on the first page view, every later conversion can trace back to the ad click that started the session.
Baselines your funnel: It gives you the top-of-funnel count you divide into to measure how many visitors go on to view products, start checkout, or convert.
SEO managers use page viewed (page_viewed) to confirm that landing pages built for ChatGPT ad clicks load and resolve correctly before a campaign scales.
Growth marketers use page viewed (page_viewed) to baseline top-of-funnel traffic so they can calculate how many ad visitors move toward checkout or signup.
Demand gen leads use page viewed (page_viewed) to verify attribution is wired end to end before they trust ChatGPT Ads reporting in their pipeline.
page_viewed is one of OpenAI's standard events, which means it can serve directly as an oCPC optimization goal that the bidding system targets, something a custom event cannot, which matters when you want the campaign to optimize toward real visits.
When the same page view arrives from both the browser pixel and the server-side Conversions API, a shared event identifier tells OpenAI to merge them and count the view once instead of inflating your totals.
OpenAI credits a page_viewed to an ad through a click-through attribution window you configure in Ads Manager, and it reports view-through conversions on a separate, shorter window so the two are never mixed in one number.
Confirms that ChatGPT ad clicks reach a live, crawlable landing page.
Captures the oppref click reference so later conversions stay attributable.
Fires automatically from the base pixel snippet, with no extra code to maintain.
Feeds both the OpenAI pixel and the Conversions API from one event definition.
Gives you a top-of-funnel denominator for every downstream conversion rate.
Works through a 1×1 image tag on pages where JavaScript cannot run.
Install the pixel in the head of every page, so page_viewed fires before a visitor can bounce.
Send the event through the Conversions API as well as the pixel, because server-side delivery survives ad blockers and browser limits.
Pair the two sources with a shared event identifier, so OpenAI merges them instead of double-counting.
Reserve page_viewed for pages that matter, since tagging every trivial view buries your signal in noise.
Fire a real test event and confirm it lands in Ads Manager, because a green pixel is not proof the data arrived.
Merge OpenAI's required sources into your Content Security Policy without weakening it, so a strict policy does not silently block measurement.
Avoid the most common trap: seeing page_viewed fire and assuming conversion tracking is done. page_viewed is automatic, but your purchase, lead, and signup events only exist if you add explicit measure calls on the pages where those actions complete.
AirOps: connects your ChatGPT ad activity and page_viewed signals to the organic prompts you already track, so paid delivery and AI visibility live in one workspace.
Google Analytics 4: cross-checks your OpenAI page_viewed counts against GA4's own page_view event to spot tagging gaps and traffic you are missing.
Google Tag Manager: deploys and versions the oaiq pixel across your pages without touching source code, so page_viewed fires consistently everywhere.
Create a data source. In the Conversions tab of Ads Manager, generate a Pixel ID and a Conversions API key; this takes only minutes and needs no spend or approval.
Install the pixel. Add the oaiq snippet to the head of every page and initialize it with your Pixel ID so page_viewed begins firing on load across your whole site.
Verify the fire. Load a page, open your browser network tab, and confirm the page_viewed event reaches OpenAI before you trust the data in your reporting.
Add the server side. Send the same page_viewed through the Conversions API with a shared event identifier, so blocked browsers still report the view reliably.
Layer real conversions. Add explicit measure calls for order_created, lead_created, or registration_completed on the pages where those actions finish, then watch them against your page_viewed baseline to gauge how many visitors convert.
Page viewed (page_viewed) is a standard ChatGPT Ads conversion event that records when a tracked page loads for a visitor tied to your ad account.
You capture it with the OpenAI pixel in your page head, optionally mirrored server-side through the Conversions API.
Its main constraint is scope: it proves a visit happened, so it cannot tell you anything about revenue or intent.
The main risk is false confidence, because page_viewed fires automatically whether or not your real conversion events are wired.
Its leverage is attribution: the oppref reference captured on the first view ties every later conversion back to the ad click.
page_viewed and contents_viewed both use the contents data type, but they mark different moments. page_viewed records that a visitor landed on or opened an important page, making it a broad traffic and delivery signal. contents_viewed is narrower: it records that someone viewed a specific product, listing, or content item, including interactions that happen after the page has already loaded. In practice, you fire page_viewed on arrival at a key page and reserve contents_viewed for the moment a shopper actually inspects an individual product. Using them interchangeably blurs your funnel, because you lose the distinction between people who reached a page and people who engaged with something on it. Keep page_viewed as your top-of-funnel count and let contents_viewed measure genuine product interest, so your later conversion rates describe real behavior instead of raw page loads.
page_viewed fires on every page load where the OpenAI pixel is installed, so if you place the base snippet site-wide, it triggers on essentially every view. That is by design: the base snippet includes a page_viewed call, so it runs automatically without extra code. If you prefer not to count every page, you can remove the automatic call from the base snippet and fire page_viewed only on the specific pages that matter, such as pricing or key landing pages. How often it should fire depends on your goal. For a pure delivery check, site-wide firing is fine. If you plan to use page_viewed as an optimization or baseline metric, limit it to meaningful pages so the count stays interpretable. Either way, confirm in Ads Manager that the volume you see matches the pages you intended to tag, because a misplaced snippet can silently over- or under-count.
Differences usually come down to what each path can capture. The browser pixel depends on JavaScript running in the visitor's browser, so ad blockers, strict Content Security Policies, privacy settings, and abandoned loads all suppress some page_viewed events. The Conversions API runs on your server, so it captures views the browser misses, but it only fires for the pages where you built the server-side call. When the two numbers diverge, it usually means one source is seeing events the other cannot. This is why OpenAI treats a shared event identifier as essential: it lets the system recognize a browser event and a server event as the same page view and merge them. If you have not wired deduplication, the same view can count twice and inflate your totals. Check that both paths send the identical event with a matching identifier, and expect the server side to report the more complete figure.
Yes, you control page_viewed more directly than most conversion events, because you decide where the call fires. Since the event is driven by the pixel snippet and your own measure calls, you choose which pages carry it. Leave the automatic call in the base snippet and every page counts; remove it and place explicit page_viewed calls only on pricing, demo, or campaign landing pages, and only those count. You also control the optional data you attach, such as a value or currency, though most teams leave page_viewed bare. What you cannot control is OpenAI's attribution logic: once an event fires, the platform decides whether it falls inside your configured window and ties to an ad click. So shape the inputs you own, which pages fire and what data they carry, then let OpenAI handle matching. Test any change on a staging page before you push it live, so you do not distort an active campaign's numbers.
There is no single published benchmark, so treat "good" as high coverage and clean attribution instead of a fixed percentage. A healthy setup shows page_viewed volume that roughly tracks your real traffic to tagged pages, with the Conversions API reporting at least as many events as the pixel, since server-side delivery is more resilient. If the two sources are close after deduplication, your event identifiers are working. If the pixel count is far below your analytics page views, something is suppressing it, often a blocker or a Content Security Policy. A strong signal also means most ad-driven sessions carry the oppref click reference, so conversions stay attributable. Instead of chasing a number, watch trends: a stable ratio between page_viewed and downstream events, and a server count that holds up when browser tracking degrades. If those hold, your measurement is sound enough to judge campaign performance on.