Action Source is a parameter on every conversion event you send to ChatGPT Ads that declares where the action happened, using values such as web, mobile_app, physical_store, or phone_call. It labels the origin of a conversion for OpenAI's measurement system, and it is separate from the event type, which describes what the action was.
Set it wrong and OpenAI can misclassify or reject your conversions, so your campaign optimization learns from a distorted picture. Get it right and your reporting and conversion-optimized bidding both see clean signals, which is what lets oCPC steer spend toward clicks that actually convert.
Within ChatGPT Ads conversion tracking, Action Source is the field named action_source that you attach to each event so OpenAI knows the channel the conversion came from. You set it to a fixed value like web for website events or mobile_app for app lifecycle events such as installs and opens. The value travels with the event whether you send it through the browser Measurement Pixel or the server-side Conversions API.
Action Source works alongside a few companion fields. When you declare web, OpenAI requires a source_url naming the page where the action occurred, and app events like app_installed and app_opened must carry mobile_app because the Pixel does not support them. The event type and data shape describe what happened; Action Source describes where, and the two are validated together before an event counts.
Action Source sits upstream of every conversion report and optimization decision in the platform. OpenAI uses it to classify events, and a mismatched value can push an event into the wrong bucket or drop it entirely. AirOps helps marketing teams keep this kind of measurement setup consistent as they expand into AI-native ad channels.
Resources: See practical guidance for running and measuring ChatGPT Ads campaigns effectively
Action Source is applied at the moment you build a conversion event, and the platform reads it as the event moves from your site or server into reporting.
Capture the action: When a user completes an action like a purchase or lead form, your Pixel or server code fires a conversion event.
Set the value: You assign action_source a fixed value such as web, mobile_app, or physical_store to match where the action actually happened.
Attach required fields: For a web value you include source_url; app events use mobile_app through the Conversions API because the Pixel cannot send them.
Send and validate: OpenAI receives the event, checks Action Source against the event type and data shape, and rejects or accepts it.
Classify and report: Accepted events are grouped by their source and flow into conversion reporting and, for oCPC campaigns, optimization.
The source value tells you which channel each conversion came from, so you can read performance by origin. It does not tell you whether the conversion was truly incremental, only where OpenAI recorded it.
Whether you keep investing in ChatGPT Ads depends on trusting the conversion numbers the platform reports back, and Action Source is one of the fields that decides whether those numbers are clean. Because the channel is new and still in beta, most teams are still proving it works, which makes measurement accuracy the difference between scaling the budget and shutting the channel off.
Accurate optimization: oCPC bidding steers delivery toward conversions, so a wrong source value feeds the model misclassified events, and it learns to chase the wrong clicks while you keep paying for them.
Reliable reporting: Labeling each conversion by origin lets you compare web, app, and in-store performance instead of reading one undifferentiated total, which is where real budget decisions get made.
Rejected conversions: If you send web without a source_url, or send app events outside the Conversions API, OpenAI drops those events and they silently vanish from your results, so your true performance looks worse than it is.
SEO managers use Action Source to separate website conversions from app and offline events so ChatGPT Ads reporting matches the channels they own.
Growth marketers use Action Source to feed clean, correctly labeled events into oCPC bidding so the system optimizes toward real purchases.
Demand gen leads use Action Source to confirm that lead form submissions are tagged as web events with a valid source_url before scaling spend.
Action Source records where a conversion happened, while the event type records what the action was, and OpenAI validates the two together, so a plausible-looking event can still be rejected when the declared source and the event type or data shape do not line up.
Each source value carries its own requirements, so declaring web means you must also pass a source_url naming the page, while app lifecycle events such as installs and opens have to travel through the Conversions API with a mobile_app value because the browser Pixel cannot send them.
When you send the same conversion from both the Pixel and the Conversions API, keeping the source value consistent and sharing one event ID lets OpenAI recognize the two reports as a single action, so you measure one conversion instead of double-counting it.
Keeps your ChatGPT Ads conversion reporting accurate by labeling each event with its true origin.
Lets oCPC bidding optimize on clean signals so spend follows clicks that convert.
Separates web, mobile_app, and physical_store conversions so you can read performance by channel.
Prevents rejected or misclassified events that would otherwise disappear from your results.
Supports deduplication so the same conversion sent through the Pixel and Conversions API counts once.
Match the source value to where the action truly happened, because a mismatch can get events rejected or miscounted.
Always pass a source_url with web events, since OpenAI requires it and drops web events that arrive without one.
Send app installs and opens through the Conversions API with mobile_app, because the browser Pixel cannot carry them.
Use the same source value and event ID when you double-send, so the Pixel and server events deduplicate into one.
Audit recent events after any tracking change, so you catch a wrong source value before it pollutes weeks of data.
Document which source value each event uses, so new team members label future events consistently.
Avoid treating Action Source as a field you set once and forget. The common mistake is leaving a default value in place after moving an event to a new channel, so app or in-store conversions keep arriving tagged as web and quietly corrupt your reporting.
AirOps: helps marketing teams build and QA the content and measurement workflows behind AI-native ad channels like ChatGPT Ads so conversion setups stay consistent.
ChatGPT Ads Manager: the OpenAI interface where you create data sources and conversion event settings and confirm each event's source value through recent-events monitoring.
Google Tag Manager: fires the Pixel and passes the correct action_source value on the right pages without hard-coding tags into your site.
Map your conversions: List every action you want to count and note where each one happens, whether on your website, in your app, or offline. This takes an afternoon and no budget approval.
Create a data source: In ChatGPT Ads Manager, create a Pixel data source and save its Pixel ID so events have somewhere to land. You can reuse an existing source if you already track this site.
Set the source value: For each event, assign action_source the value that matches its origin, using web for site actions and mobile_app for app installs and opens.
Add required fields: Attach a source_url to every web event and route app lifecycle events through the Conversions API so OpenAI accepts them.
Verify and monitor: Fire a test event, check recent events to confirm the source value arrived correctly, then watch your reporting for rejected or misclassified conversions in the first days.
Action Source is the action_source field that tells ChatGPT Ads where each conversion event happened.
You set it per event to a fixed value like web, mobile_app, or physical_store that matches the action's origin.
Web values require a matching source_url, and app lifecycle events must be sent through the Conversions API with a mobile_app value.
A wrong or default source value can get conversions rejected or misclassified, quietly distorting your reporting and bidding.
Clean, consistent source values are what let oCPC optimization and channel-level reporting actually be trusted.
Action Source and the event type answer two separate questions about the same conversion: Action Source names where the action occurred, and the event type names what the action was. The event type is a value like order_created, lead_created, or app_installed, and it comes paired with a data shape that describes the fields OpenAI expects. Action Source is a short channel label such as web or mobile_app. OpenAI checks them against each other when an event arrives, so an app_installed event that claims a web source, or a web event missing its source_url, can fail validation even though each piece looks correct on its own. In practice you choose the event type based on the business action you are counting, and you choose the source based on the surface where that action physically happened. Keeping the two aligned is what lets the platform record the conversion and credit it to the right campaign.
Check the Action Source value any time you change your tracking setup, and spot-check it on a regular cadence after that. There is no fixed schedule the platform enforces, so the honest answer is that frequency should follow risk: right after you launch a new conversion event, move an event to a new channel, or change your tag manager configuration, verify the source value immediately using the recent-events view, which surfaces a sample of events from roughly the last fifteen minutes. Once a setup is stable, a monthly review is usually enough to catch drift, such as a developer deploying a change that resets a value to a default. If you run both the Pixel and the Conversions API for the same conversions, check both paths, because they can diverge independently. The cost of checking is minutes; the cost of not checking is weeks of conversions quietly landing in the wrong channel before anyone notices.
The Action Source value varies because your conversions genuinely happen in different places, and each place has its own correct label. A purchase completed on your website is a web event, an install recorded by your app is a mobile_app event, and a sale closed in a store is a physical_store event, so a single account can legitimately show several source values at once. Variation becomes a problem only when the value does not match reality, which usually traces to one of a few causes: a default left in place after an event moved channels, a tag manager rule applying the wrong value, or server code hard-coding a source for events that actually originate elsewhere. The platform treats each value as a factual claim about where the action occurred. Every event should carry the value that is true for it, even when that means your account shows a mix of sources. Diversity across sources is expected; mismatch is the signal to investigate.
Yes, Action Source is fully under your control, because you set it explicitly on every event you send. Unlike metrics the platform calculates for you, this value is an input you choose when you build the event in your Pixel snippet or your Conversions API payload. That control comes with responsibility: OpenAI takes the value you declare at face value and expects it to be accurate, so you are the only safeguard against a wrong label. To exercise that control well, decide the correct value for each conversion during setup, encode it in your tag manager or server code, and avoid leaving it to a default. If you work with developers, give them a clear mapping of which events use which source value so the setting does not drift as code changes. Because you own the value directly, fixing a mistake is usually fast once you spot it; the hard part is noticing, which is why monitoring recent events matters so much.
A healthy Action Source setup is one where every conversion carries a value that matches where it truly happened, and where almost none of your events are rejected for source-related errors. There is no public benchmark number OpenAI publishes for this, so judge it by behavior instead of a target percentage. In a clean setup, the recent-events view shows each event arriving with the expected source, web events always include a valid source_url, and app events consistently come through the Conversions API as mobile_app. Rejected-event counts stay near zero, and your channel-level reporting adds up to your totals without a mystery bucket of unclassified conversions. When you run the Pixel and Conversions API together, deduplication works and you do not see inflated counts. If you can pull up any conversion and explain, in one sentence, why it carries the source value it has, your setup is healthy. Persistent rejections or unexplained values are the sign that something needs attention.