Which ChatGPT Ads events actually matter for a store
All thirteen supported events sorted into the five a Shopify store needs, the two websites cannot send, and the rest.
ChatGPT Ads supports thirteen conversion events. Most Shopify stores need about five, two aren't available to websites at all, and several exist for business models that have nothing to do with retail.
Nobody tells you which is which, so stores tend to do one of two things: track only purchases, or track everything on the assumption that more data is better. Both are wrong in ways that cost you.
Here's the whole list, sorted by whether you should care.
The five that matter for a store#
| Event | Fires when |
|---|---|
page_viewed | Someone lands on a page |
contents_viewed | Someone views a specific product |
items_added | Something goes into the cart |
checkout_started | Checkout begins |
order_created | The purchase completes |
That's your funnel. Each one tells you where people fall out, and together they let the ad platform learn what a buyer looks like before they buy.
order_created is the one that must be right. Every return-on-ad-spend figure you'll ever look at is computed from it. If you only get one event correct, this is it.
page_viewed and contents_viewed are not the same thing, and the distinction trips people up. Use page_viewed for page loads generally. Use contents_viewed when someone views a specific product or content item — including when that happens after the page has loaded, like opening a quick view or switching variants. On a product page you'll often fire both, and that's correct.
items_added and checkout_started are the ones stores skip, and they're what makes optimisation work. Purchases are rare; add-to-carts are common. An ad platform learning from a hundred add-to-carts a day finds your buyers faster than one learning from three purchases.
The two you cannot use#
app_installed and app_opened are available through the Conversions API only, must be sent with action_source set to mobile_app, and are not supported by the JavaScript pixel.
If you have a native mobile app, they're for that. If you're running a website, they're not available to you and there's no workaround. Skip them.
The six for other business models#
None of these are wrong, they're just for stores that do more than sell products:
lead_created— someone submits a lead form or requests contact. Useful if you run a wholesale enquiry form or a "request a quote" flow alongside retail.registration_completed— an account or event registration finishes. Worth firing if account creation genuinely matters to you.appointment_scheduled— a booking, demo or consultation. Relevant if you sell services or fittings.subscription_created— a paid subscription starts.trial_started— a free trial starts.custom— anything the standard list doesn't cover.
If you sell subscription boxes, subscription_created is arguably as important as order_created. If you sell t-shirts, none of these apply and adding them adds nothing.
Custom events: use sparingly#
custom exists for genuinely bespoke actions — a configurator completed, a size guide opened, a store locator used. Something that matters to your business and isn't on the list.
The rules are narrow. Names use lowercase letters, numbers, underscores or dashes, between 1 and 64 characters, and must not reuse a built-in event name. Sending a custom event called purchase or order_created will not do what you hope.
My advice: don't reach for custom until the standard events are all working. A custom event on top of a broken order_created is decoration.
The data shape has to match#
Every event carries a data object with a type field, and the type is determined by the event — you don't get to choose:
| Type | Used by |
|---|---|
contents | page_viewed, contents_viewed, items_added, checkout_started, order_created |
customer_action | lead_created, registration_completed, appointment_scheduled, and the two app events |
plan_enrollment | subscription_created, trial_started |
custom | custom |
Send order_created with a customer_action shape and it's malformed. This is a common mistake when someone copies an example from the wrong section of the docs, and it fails silently.
Two rules that apply throughout:
If you send an amount, send a currency with it. An amount alone is ambiguous and will be rejected.
Amounts are whole numbers in the currency's smallest unit. $129.99 is 12999. Yen has no smaller unit, so ¥5000 is 5000. Kuwaiti dinar uses three decimal places. Get this wrong and your revenue is off by a factor of a hundred, in a way that looks entirely plausible on a dashboard.
What I'd set up on a typical store#
Start with order_created and get it completely right — correct amount, correct currency, click reference attached, and a matching event ID if you're also sending from your server.
Then add items_added and checkout_started, because that's what improves targeting.
Then page_viewed and contents_viewed for the full funnel.
Then stop, unless you actually run subscriptions, bookings or lead capture.
Five events, done properly, will out-perform thirteen events where the purchase amount is in the wrong format. More events is not better data — correct events are better data.
I build LLM Pixels, a Shopify app that maps Shopify's storefront events onto this taxonomy so you don't have to.