Governing Event Names and Parameters Across Many Sites and Accounts

Editorial team Spend Ledger

Why shared event definitions matter

When a business runs several websites and advertising accounts, the same customer action can be recorded in different ways. One team may call a completed purchase OrderComplete, another may use Purchase, and a third may track a thank-you page view. These labels can all seem reasonable locally, but they do not necessarily describe the same thing.

That inconsistency makes reporting harder to interpret. A business may compare results that represent different actions, overlook conversions because reports group them under separate names, or count more than one signal for a single customer journey. Teams can also make poor decisions about campaign performance when they assume that identically named events have identical definitions.

A shared event dictionary is a practical reference for what each event means, when it should be recorded, and which parameters describe it. It gives internal teams and external partners a common vocabulary without requiring every site to have identical technical implementation. The aim is consistent meaning, not uniformity for its own sake.

A dictionary also helps clarify what an advertising account is for: it is a work tool within a wider business process, not a substitute for clear measurement practices. Whether an account is prepared internally, managed by an agency, or obtained as a business asset, event governance should be documented and should remain within the platform’s rules. Account ownership or purchase does not change those responsibilities.

Start with business actions, not labels

Before choosing event names, define the actions the business needs to understand. Examples might include a visitor submitting a qualified enquiry, beginning checkout, completing a purchase, or registering for a service. Describe the action in ordinary language first, including what must happen for it to count.

This step prevents a technical label from becoming the definition by accident. A form submission, for example, might record a customer’s details without confirming that the form was accepted. A purchase event might be triggered when someone reaches a confirmation page, even if the underlying transaction has not been completed. Teams should identify which business state they intend to measure and what evidence confirms that state.

Separate actions that matter to the business from events that are merely convenient to collect. A page view may be useful for analysis, but it should not be treated as a completed lead or sale unless that is genuinely what the page represents. Where an action cannot be reliably verified, document that limitation rather than presenting the signal as definitive.

It is also useful to distinguish an event’s business meaning from its technical firing method. A site may use a confirmation page, a server-side signal, or another approved implementation. The dictionary should explain the intended meaning and point to the responsible implementation record, rather than making the event name depend on one particular technical method.

Build a shared event dictionary

Keep the dictionary in a location that the relevant teams can access and maintain. It can be a controlled document or another shared record, provided there is a clear way to identify the current approved version. Avoid maintaining separate, unofficial copies for each site or account; those tend to drift apart.

A useful entry includes the event’s canonical name, plain-language definition, triggering condition, exclusions, expected parameters, responsible business owner, technical contact, applicable sites or account contexts, and current status. Record the date of approval or change if useful to your internal process, but do not confuse an internal date with a platform requirement.

A placeholder layout might look like this:

| Field | Placeholder | |---|---| | Canonical event name | ACTION_COMPLETED | | Business meaning | [Describe the customer action] | | Trigger condition | [State what must be true before recording] | | Exclusions | [List similar actions that do not qualify] | | Required parameters | [PARAMETER_A], [PARAMETER_B] | | Optional parameters | [PARAMETER_C] | | Sites or contexts | [SITE_GROUP] | | Account use | [ACCOUNT_CONTEXT] | | Business owner | [ROLE OR TEAM] | | Technical owner | [ROLE OR TEAM] | | Status | [PROPOSED / APPROVED / RETIRED] | | Change record | [SUMMARY AND INTERNAL REFERENCE] |

Use placeholders until the business has agreed on the real definitions. Do not fill gaps by copying assumptions from another site. If an event’s meaning differs across customer journeys, make that difference explicit and decide whether distinct events are needed.

Define parameters with equal care

Parameters provide context about an event. Depending on the business action, they may describe a value, currency, product category, lead type, or another relevant property. The dictionary should state what each parameter means, its expected format, whether it is required, and what should happen when the value is unavailable.

Avoid parameters that are vague, redundant, or likely to be interpreted differently by separate teams. For instance, a field labelled value is not useful unless the dictionary says what value it represents and how it is calculated. Similarly, a field labelled type needs a defined set of meanings or an explanation of how values are assigned.

Only collect information that is appropriate for the purpose and allowed under applicable platform terms and privacy requirements. Do not put sensitive personal information into event names or parameters. When the business is unsure whether a field is permitted or how it should be configured, check the relevant platform’s official documentation and seek suitable privacy or compliance advice.

Consistency does not mean forcing every site to send every parameter. A parameter can be marked optional where a site does not have the relevant information. The important point is to distinguish an unavailable value from a different meaning. A blank or omitted field should not silently stand for a business concept that another team records under a different name.

Assign ownership and review changes before release

A dictionary needs an owner with authority to keep it coherent. That owner might be a measurement lead, analytics team, or another designated role. The owner does not have to implement every event, but should be responsible for reviewing definitions, resolving naming conflicts, and ensuring that approved changes reach the teams working on each site and account.

Each event should also have a business owner who can confirm that the recorded action matches the intended customer outcome. Technical contacts can explain how an event is implemented and where it fires. These responsibilities may sit with different people or teams, but they should be explicit. For agency-managed accounts or externally supported sites, agree in writing who proposes changes, who approves them, who implements them, and who checks the result.

Require review before a new event goes live. The proposal should explain why an existing event is insufficient, what business action the new event represents, which sites and accounts it affects, and whether it changes reporting or campaign optimisation. The review should also consider whether existing events might already record the same action.

After approval, test the event in an appropriate non-production or validation process where available, and confirm that its name and parameters match the dictionary. Then update the shared record and notify affected teams. If a platform’s current rules, interfaces, or requirements are unclear, consult its official help and policy pages; current values and procedures are published there. Do not treat an internal review as a way to bypass platform review or verification.

Prevent naming conflicts across teams

Naming conflicts often begin with reasonable local decisions. A web team might call an enquiry LeadSubmitted, while an advertising team uses Contact, and a regional team labels the same action FormSuccess. If the triggers differ as well as the names, combining reports can create false comparisons. If the triggers are identical, separate labels can still fragment reporting and make it difficult to see the full picture.

A dictionary solves the vocabulary problem by assigning one canonical name to one defined business action. Teams can keep local implementation notes, but those notes should map back to the approved event and explain any variation. A name should not be reused for a different action simply because it is familiar or convenient.

When two existing events appear to represent the same action, compare their definitions before merging them. Check what triggers each event, what is excluded, which parameters are sent, and how the resulting data is used. If the underlying actions are genuinely different, preserve separate definitions and make the distinction clear. If they are equivalent, document the approved mapping and decide how to handle the old labels.

This avoids a common reporting trap: assuming that matching names prove matching meaning. A common label is useful only when teams agree on its definition and apply it consistently.

Record retired events and preserve context

Do not simply delete an event from the dictionary when it is no longer used. Mark it as retired and record why, when the change took effect internally, what replaced it if anything, and which sites or accounts may still contain historical data under the old name. This helps analysts interpret past reports and prevents a later team from reintroducing an obsolete event.

Retirement should be deliberate. Confirm that the event is no longer needed for an active customer journey, reporting requirement, or approved integration. Check whether dashboards, campaign settings, or internal analysis depend on it, and coordinate the change with the relevant owners. The goal is to stop creating new ambiguity, not to erase useful history.

For a transition, keep a clear mapping between the retired event and its replacement where the meanings are comparable. If they are not directly comparable, say so. Do not imply that historical figures can be combined cleanly when the definitions or triggers changed. Note any limitations in reporting documentation so that later analysis does not treat the transition as a seamless series.

A retirement log is especially useful when staff, agencies, or account arrangements change. It allows a new team to understand why an event exists in old records without assuming it is still approved for use.

Make governance part of routine account work

Event governance is most effective when it is part of ordinary site and account management rather than a cleanup project after reports become confusing. Include the dictionary in onboarding for teams that create campaigns, maintain websites, manage analytics, or support advertising accounts. Before launching a new site or account structure, check whether existing event definitions apply and record any justified differences.

Review the dictionary when customer journeys, measurement needs, or platform requirements change. The review should focus on whether definitions remain accurate, whether parameters are still appropriate, and whether retired events are truly inactive. Keep access and change permissions suitable for the people involved, and retain a record of decisions so that a later team can understand the reasoning.

If accounts are prepared internally or sourced as business tools, agree who controls the measurement documentation and how it follows the work. If an agency provides account services, put responsibilities for event changes, approvals, access, and handover in writing. These arrangements should support legitimate business operations, not attempts to avoid restrictions, verification, or other platform rules. If an account is restricted, use the platform’s official appeal and support channels and address the underlying issue.

The practical standard is straightforward: one agreed meaning for each shared event, clear parameters, an accountable owner, review before release, and a record of what has been retired. That structure gives teams a more dependable basis for reading results across sites and accounts while making changes easier to explain and govern.