A pattern shows up across attribution audits often enough to be predictable. A team connects a new ad channel, opens the event mapping screen, sees a list of supported events, and maps every single one of them, on the reasonable-sounding logic that more data is better.
Six weeks later the campaign is delivering installs at an attractive cost and almost none of them are worth anything. The algorithm did exactly what it was told. It was told to find people who open apps.
Event mapping is the least glamorous part of setting up ChatGPT Ads and the part that determines whether any of the attribution is usable. Getting the link right, covered in the ChatGPT Ads install tracking setup guide, makes the channel measurable. Getting the events right makes it optimisable. This post is about the second one, as of September 2026.
Why event mapping decides your campaign quality
When you map an event to a ChatGPT Ads standard event, you are doing two separate things at once, and most teams only think about the first.
The first is reporting. Mapped events appear in Ads Manager, so you can see how many people did the thing after clicking your ad. This is passive and harmless.
The second is optimisation. Events you send back become the signal the delivery system learns from, and it learns fast. If your signal is app open, it will find people who open apps and stop. If your signal is a completed purchase, it will find fewer people and better ones.
Optimisation event: The in-app action a campaign is instructed to maximise. The delivery algorithm treats it as the definition of success, so it defines the audience the channel finds for you.
This is why "map everything" is not a neutral choice. It is a choice to optimise for whichever event fires most often, which is always the shallowest one in your funnel.
The twelve standard events
Here is the full set, as documented in September 2026, with the data type each one carries and what it maps to in an app funnel.
| Event name | Data type | What it represents | App funnel role |
|---|---|---|---|
app_installed | customer_action | A user installs an app | Install |
app_opened | customer_action | A user opens an app | Too shallow to optimise against |
registration_completed | customer_action | A user finishes an account or event registration | Weak activation candidate |
lead_created | customer_action | A user submits a lead form or requests contact | Activation, lead-gen apps |
appointment_scheduled | customer_action | A user books a meeting, demo or consultation | Activation, services apps |
contents_viewed | contents | A user views a product, listing or article | Too shallow to optimise against |
page_viewed | contents | A user lands on an important page | Web-oriented, rarely useful for apps |
items_added | contents | A user adds items to a cart, bundle or selection | Activation, marketplace and eCommerce |
checkout_started | contents | A user starts checkout | Mid-funnel |
order_created | contents | A purchase is completed | Value event |
trial_started | plan_enrollment | A free trial starts | Activation, subscription apps |
subscription_created | plan_enrollment | A paid subscription starts | Value event |
custom | custom | Anything the standard taxonomy does not cover | Fallback |
Two details in that table matter more than the names.
app_installed and app_opened are Conversions API only. They are not supported by the JavaScript pixel, and they must be sent with action_source set to mobile_app. If you are running a pixel-only setup, your app installs are not reaching ChatGPT Ads at all, whatever else is configured. This is the technical reason the agency setup guides written for websites do not work for apps.
Monetary values are integers in the currency's minor unit. Send 12999 with currency: "USD" for $129.99. For Indian apps that means paise, not rupees: a ₹499 subscription is 49900, not 499. Get this wrong and every revenue figure you report to the channel is out by a factor of a hundred, in the flattering direction, which is exactly the kind of error that survives a review.
The mapping rule: two events on day one
The rule that survives contact with reality is simple. Map install, map one activation event, and stop.
Install is app_installed, sent through the Conversions API by your measurement platform once your SDK is live and your tracking link is in the campaign. Nothing to decide, but do confirm it is actually being forwarded, since a pixel-only setup cannot send it.
Your activation event is the earliest action that reliably separates a real user from a curious tap. Not the first thing a user does. The first thing a user does that a time-waster would not.
The test for whether you have chosen correctly is uncomfortable but effective: if a bot farm or an incentivised install could produce your activation event at scale, it is too shallow. Signup usually fails this test. Account verification usually passes it.
Add a value event, typically first purchase or first subscription, once the first two are confirmed working and you have enough volume for it to fire more than a handful of times a week. At the ₹725 daily floor most Indian teams are testing with, that will take several weeks, and optimising against an event that fires twice a week teaches the algorithm nothing.
The broader discipline here is not channel-specific. If your event structure has grown organically over a few years and nobody has audited it recently, the framework in designing a mobile app event taxonomy that lasts is the right place to start, and the validation steps in the complete event taxonomy implementation guide will catch the events that fire in the wrong order.
Vertical mappings
The right activation event is a property of your funnel, not of the channel. Four worked examples, using the shape of funnel each vertical typically has.
Fintech and lending
| Layer | Your event | ChatGPT Ads event | Why |
|---|---|---|---|
| Install | First open | app_installed | Automatic via CAPI |
| Activation | KYC or identity verification completed | custom | Requires real documents and real effort, so it filters almost everything artificial |
| Value | First transaction, deposit or loan disbursal | order_created | The revenue-bearing action |
Note that verification has no standard event, so it goes to the custom fallback. Resist the temptation to use registration_completed instead just because it exists: signup is the wrong activation event here, since a phone number and an OTP cost a user nothing. Verification is the first genuinely expensive step, which is exactly why it discriminates. The fuller event list for this vertical is in the ten critical events every fintech app should track.
Marketplace and eCommerce
| Layer | Your event | ChatGPT Ads event | Why |
|---|---|---|---|
| Install | First open | app_installed | Automatic via CAPI |
| Activation | First add to cart | items_added | Demonstrates purchase intent rather than curiosity |
| Value | First completed order | order_created | The revenue-bearing action |
This is the vertical where the standard taxonomy fits an app funnel most cleanly, so no custom events are needed. The trap is contents_viewed, which is tempting and too shallow: almost every install produces at least one product view, so optimising against it is close to optimising against install. Keep checkout_started mapped for reporting, but do not optimise against it, since abandoned checkouts will inflate the signal. The wider set is covered in the seven critical events every eCommerce app should track.
OTT and streaming
| Layer | Your event | ChatGPT Ads event | Why |
|---|---|---|---|
| Install | First open | app_installed | Automatic via CAPI |
| Activation | First playback exceeding 30 seconds | custom | Distinguishes watching from browsing |
| Value | Trial started, then paid subscription | trial_started, then subscription_created | Both carry plan_id, so plans stay separable |
The threshold matters more than the event name. Playback started fires when someone taps a title and leaves. Thirty seconds of continuous playback does not, which is why this needs a custom event rather than contents_viewed.
Optimise against trial_started while volume is low and switch to subscription_created once conversions are frequent enough to learn from. See the seven critical events every OTT app should track.
Gaming
| Layer | Your event | ChatGPT Ads event | Why |
|---|---|---|---|
| Install | First open | app_installed | Automatic via CAPI |
| Activation | Tutorial completed, or level 3 reached | custom | The first point at which retention becomes predictable |
| Value | First in-app purchase | order_created | The revenue-bearing action |
Gaming is the vertical where the gap between install and value is widest, which makes the activation event the one doing all the work, and where the standard taxonomy helps least. Progression events have no equivalent in the standard list, so expect to run one custom event and to name it carefully. The seven critical events every mobile game should track has the full progression.
The custom fallback, and how to name things
The custom event is the escape hatch for anything the standard list does not cover, and it is where taxonomies go to die.
Three rules keep it usable.
Respect the platform's constraints first. Custom event names must use lowercase letters, numbers, underscores or dashes, run between 1 and 64 characters, and must not reuse a built-in event name. A custom order_created sitting beside the standard one is rejected rather than merged.
Name for the user action, not the screen. verification_completed survives a redesign. kyc_screen_3_submit does not, and in six months nobody will remember what screen three was.
Use one convention everywhere. Lower case, underscores, verb in the past tense, which is also what the platform's own taxonomy uses. It matters less which convention you pick than that ChatGPT Ads, Meta, Google and your own analytics all use the same one, because the first time you compare channels you will be doing it in a spreadsheet.
Never create a custom event that duplicates a standard one. If a standard event fits, use it. A custom purchase_done sitting next to the standard purchase event means two numbers that should be identical and are not, and you will spend an afternoon working out which to trust.
Whatever you choose, write it down somewhere a new joiner will find it. The convention is only worth having if it outlives the person who set it.
Three mapping mistakes that survive review
These are the ones that pass a casual check and cause damage over months.
Mapping the same in-app action to two different standard events. It usually happens when one person maps events for the web pixel and another maps them for the app, and both reach for the closest standard event without comparing notes. The result is one user action producing two conversion records, an inflated count, and a cost per conversion that looks better than reality. This is the same class of problem that shared event identifiers exist to solve, and it is worth agreeing the mapping in one document before either implementation starts.
Mapping a server-side event that fires on retry. Payment confirmations, verification callbacks and subscription renewals are often implemented with retry logic. If the event fires on every attempt rather than once on success, a single conversion can arrive three or four times. The symptom is a conversion count that exceeds your own revenue records, which nobody notices until someone reconciles against finance.
Mapping an event that fires before the user has done anything. Some SDKs emit a session or app-open event on every launch, including relaunches. Mapped to a standard event, that produces a conversion count roughly equal to your daily active users, which looks like extraordinary performance for about a week. Check what triggers an event before mapping it, not what its name suggests.
The common thread is that all three inflate rather than deflate. Faults that make numbers look worse get investigated immediately. Faults that make numbers look better can run for a quarter, because nobody opens a ticket about a campaign that is apparently working.
The guard is a reconciliation. After week one, compare the ChatGPT Ads count for your value event against your own database for the same period. If Ads Manager shows meaningfully more purchases than your records do, you have one of the three above.
How to sanity-test the mapping in week one
Do this before you raise budget, not after a monthly review raises questions.
- Fire each mapped event manually on a test device. Install from your tracking link, complete the activation action, and confirm the event appears against ChatGPT Ads specifically rather than only in your app-wide totals.
- Check the ordering. Activation events that arrive before install, or purchases before activation, mean a timestamp or session-attribution problem that will corrupt every cohort you build later.
- Compare counts after 48 hours. Your platform and Ads Manager will not match exactly, and are not meant to. A gap of ten to twenty percent is normal on a new channel. A gap of ninety percent means an event is not arriving at all.
- Confirm only your intended optimisation event is set. This is the check people skip. Open the campaign and verify the delivery system is actually optimising against the event you meant, not the first one in the list.
- Look at the activation rate, not the install count. If ChatGPT Ads installs activate at half the rate of your Meta installs, the mapping is fine and the traffic quality is the problem. If they barely activate at all, the mapping is broken.
Point five is the one that repays the effort. Install counts tell you almost nothing on a new channel. Activation rate against your existing channels tells you whether to continue.
The Linkrunner events capture API reference covers the implementation side, and the SDK integration testing guide covers the end-to-end validation that steps one and two describe.
Frequently asked questions
How many events should I map to ChatGPT Ads?
Two on day one: install and a single activation event. Add a revenue event once volume supports it. Mapping the full standard list at launch means optimising against whichever event fires most often, which is always the shallowest.
Which event should I optimise ChatGPT Ads campaigns against?
The earliest action a time-waster would not perform. For fintech that is usually identity verification, for marketplaces first add to cart, for OTT thirty seconds of playback, for gaming tutorial completion. Signup and app open are almost always too shallow to be useful.
What is the custom event fallback for?
Anything the twelve standard events do not cover. Use it sparingly, never to duplicate a standard event, and name it for the user action rather than the screen so it survives a product redesign.
Do mapped events affect ChatGPT Ads delivery, or only reporting?
Both, and this is the point most teams miss. Events you send back are the signal the delivery system learns from, so the event you map defines the audience the channel goes and finds for you.
Can I change the optimisation event after a campaign has been running?
You can, but treat it as starting a new test rather than tuning an existing one. The delivery system will re-learn against the new signal, and performance data from before the change is not comparable to data after it.
Where Linkrunner fits
The mapping discipline above is platform-agnostic. Any measurement tool that lets you define events and map them to a partner's standard set can run it.
What differs is how much of the checking is manual. Linkrunner is the first MMP in India to go live with ChatGPT Ads, and attributes those installs alongside Meta, Google and TikTok in a single dashboard, without an enterprise contract or a minimum volume commitment, and event mapping for the channel sits in the same place as the mapping for the channels you already run. That matters mostly for step five of the sanity test, where comparing activation rates across channels is the whole exercise and doing it in a spreadsheet is how it stops happening.
Key takeaways
- Mapped events drive delivery, not just reporting, so the event you choose defines the audience the channel finds.
- Map two events on day one: install and one activation event that a time-waster would not produce.
- Add a value event only when volume supports it, which at floor budget takes several weeks.
- Signup, app open and product view are almost always too shallow to optimise against.
- Name custom events for the user action rather than the screen, and use one convention across every channel.
- Judge the channel on activation rate against your existing channels, not on install count.
What to do this week
If your ChatGPT Ads campaign is already live with the full standard event list mapped, reduce it. Pick your activation event, set it as the sole optimisation target, and accept that the first week of data after the change is a fresh baseline rather than a continuation.
If the campaign has not launched, decide your activation event before you build the link rather than after. It takes ten minutes of arguing with your product team and it is the difference between a channel you can read and a channel that produces cheap installs of no value.
Then run the five-point sanity test at the end of week one. Most mapping faults are visible within 48 hours and invisible thereafter, because by month two you will have stopped questioning the numbers.
To map ChatGPT Ads events alongside the channels you already measure, request a demo from Linkrunner.