The marketing team calls the action a quote request, the website sends a custom event named enquiry_sent and the report filters for quote_submitted. Each name is plausible, yet the chain no longer describes one reliably identifiable event. Naming governance prevents this drift before it becomes a missing-conversion investigation.
For ChatGPT advertising, govern both the event’s technical name and its business meaning. A stable name attached to a changing definition can be just as misleading as an accidental spelling change. The objective is a measurement contract that remains understandable as websites, campaigns and teams evolve.
Choose the action before choosing the label
Describe the observable trigger in business terms. A lead might mean a successfully accepted enquiry, not a click on the submit button. A purchase might mean an order has been created, not that the confirmation page was visited. Be precise enough that two developers would trigger the event at the same point.
List exclusions beside the trigger. Validation failure, a reopened confirmation page or a draft enquiry should not quietly become the same action. These exclusions give testing something concrete to verify and reduce the chance that a later redesign broadens the event without anyone noticing.
OpenAI conversion tracking recommends standard events where they fit the action and custom events where no suitable standard event exists. Check the documented semantics before inventing a custom name. A more distinctive label is not a benefit if it discards a standard event that accurately describes the business action.
Maintain a compact event register
For each action, record the technical type, any custom name, business definition, trigger, source, sender routes, owner and version. Add the campaign settings that use it and the reports that explicitly select it. This is a dependency register, not a list of attractive naming suggestions.
A hypothetical entry could define an enquiry as a server-accepted request containing the required contact and service fields. Its custom name might be service_quote_requested if that action has no suitable standard equivalent. The register should explain what acceptance means and who owns changes to that definition.
Keep human-facing display labels separate from identifiers. A client can prefer a different report heading without requiring a new technical event. Conversely, retaining a familiar report heading must not conceal that the underlying trigger has changed from form submission to sales qualification.
Coordinate browser, server and setting names
When both browser and server describe the same action, compare the documented event identity fields across the routes. Custom naming must remain consistent with the corresponding event setting. A sender update deployed without a setting review can leave events arriving under a name the campaign does not use.
The event-ID contract governs identity for repeated deliveries of one action. Naming governance governs the kind of action. Maintain both: identical names with unstable IDs can produce duplicate problems, while stable IDs with inconsistent names can fragment the measurement population.
Do not create a new event name for every campaign, ad or minor page revision when the underlying action is unchanged. Campaign identity belongs in campaign reporting. An uncontrolled collection of nearly identical event names increases selector maintenance and makes cross-campaign comparisons harder to interpret.
Treat semantic changes as migrations
If an event changes from any enquiry to a verified business enquiry, the population has narrowed. Record the effective date and decide whether a new event definition is needed. Preserve the old meaning in historical reports rather than rewriting its description to match the new behavior.
In a hypothetical redesign, an enquiry form begins requiring a business registration field. A fall in recorded leads after launch may reflect the stricter action definition, not weaker advertising. The report should show the definition boundary and avoid an unqualified before-and-after conversion-rate comparison.
Check campaign restrictions before changing a setting used for optimization. The goal migration guide covers the operational decision when the desired action changes. Renaming a field in an internal document does not make an unsupported campaign-goal edit possible.
Rename a label or change the action?
- New display label
The same action can retain its technical identity.
- New definition
Document a new version and preserve the comparison boundary.
- New custom name
Coordinate sender, setting and report selection.
Verify adoption and retire intentionally
Before release, identify all senders and selectors that depend on the name. After release, confirm the intended event arrives and that the corresponding setting and report selection behave as expected. Keep an explicit rollback or transition record if old and new implementations coexist temporarily.
Use selector-error diagnosis when a reporting request rejects a name. A received action and a selectable event name can involve different publication stages, so repeated blind renaming is a poor repair strategy. Check the actual recognized name and its configuration history first.
Retire unused names by documenting their last active version and historical meaning. Do not erase that history simply because current campaigns no longer reference them. A future analyst reading last quarter’s results needs to know whether an event represented the same action that today’s team measures. With that record, naming becomes a dependable part of measurement rather than a collection of labels that only the original implementer understands.
Sources and scope
Govern event semantics, standard-event selection and custom-name changes across senders and campaign settings.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.