Adobe Launch DTM Naming Convetionds

April 1, 2025

I’ve worked with Adobe Tracking Suite (which is Adobe Launch and all it’s sibblings) for quite a while and I saw many, some quite chaotic, tracking implementations and tag managers. At some point I felt the need to write down some basic rules to navigate those messy libraries. Hope that helps you, too.

naming convention

Global

Use a category and naming convention that allows you to track variables, metrics and dimension from the website over the tag manger to the backend of your analytics solution and the dashboard. Every category is also assigned a particular numeric range. This will improve your debugging and troubleshooting process.

The following basic categories should represent your default setup.

  • Page related information (for a single page view, from 1 to 19)
  • Site related information (for the whole website, from 020 to 39)
  • User related information (describing the visitor, from 40 to 59)
  • Misc information (meta information that usually is not part of an analysis or cannot be assigned to the other categories, from 59 to

Data Layer

	datalayer = {
		page: {
			category: 
			name: 
			id:
			date:
			language:
		},
		site: {
			provider:
			project:
			domain:
		},
		user: {
			status: [anonmyous, logged-in],
			behavior: [returned, new],
			language:
		},
		misc: {
			timestamp:
			debug: 
			utm: 
			interaction_details:
		}
	}

“I’ve implemented a page.category attribute, which I find invaluable. I’m surprised so many implementations omit it. It allows for quicker traffic analysis at a higher level than individual pages. Categories help maintain order as pages inevitably become disorganized over time.”

Data Elements

Your Data Element name should consist the numeric ID referring to the ID of your (Adobe) Analytics-implementation followed by a separator (like the pipe symbol |) and the address within the Data Layer object. Left pad the ID to a length of three to not mix up the “order by name” feature. The second part is the exact address of the element within the data layer. If this element does not correspond to the Data Layer, use a short description.

  • 000 | datalayer.page.name
  • 010 | datalayer.misc.utm

Dimensions

eVars, props and events are identified by a short description build from the category and the name of the information, followed by the name and the kind of variable (t for traffic variables aka props, c vor conversion variables aka eVars and e for event):

  • Page Name (t010)
  • User Status (c020)

Events

Naming Rules

You wil need three categories of rules, based on the action the perform

  • Page View rule (mostly just one, will trigger a page view)
  • Click rules (will trigger click events)
  • Misc rule (will not trigger any call, but prepare tracking or add event listeners)

Besides that, you will have three main attributes for page view and click rules that should be available in the component name itself:

  • the according event id (custom success event, even page views can have an event ID)
  • a brief description
  • how a rule will be triggered (Page Top, Document Ready, Click, Direct Call, …)

Name your rules using those three information (I prefer the pipe symbol as a separator)

[TYPE]|[TRIGGER]|[EVENT ID]|[BRIEF DESCRIPTION]

If your rule covers more than one event, post them all as a comma separated list (50,51,52). If there are too many rules, you may overthink your strategy.

For example:

  • PV | DocReady | 10 | All Pages
  • PV | DocReady | 20 | Search Pages
  • CL | Trigger | 50,51,52 | Click
  • CL | Click | 60 | Bookmark Page
  • MISC | Helper Functions

Reason

In the rules overview this helps you to get a good first impression of all existing rules and it allows you to quickly filter the list for wanted rule types. Also, if you lookup a particular event, you quickly see the particular component that somehow works for this event.

Naming Components

A component can be a trigger/event, condition or action. When you create a component, Adobe suggests a default name. Never use this name. The name should start with the exact sequence you defined for the rule name.

For example:

You have a rule to trigger page views:

PV | DocReady | 10 | All Pages

This is how you name the components of the rule

  • trigger/event: PV | DocReady | 10 | All Pages | page top
  • condition: PV | DocReady | 10 | All Pages | user is logged in
  • action: PV | DocReady | 10 | All Pages | set variables
  • action: PV | DocReady | 10 | All Pages | send beacon
  • action: PV | DocReady | 10 | All Pages | clear variables

Reason

If you look up a particular event ID, you quickly see all according components. If you look up particular variables that belong to different events, you know quickly identify, where this variable is being used, without clicking into the component itself.

Error Handling

If you have custom code, you should always implement try/catch error handling that also refers to the parent rule:

let rule_name = '`PV | DocReady | 10 | All Pages';
try {


} catch (e) {

	_satellite.logger.error(rule_name + ' | ' + e);

}

If your code grows and get more complex, you should and can, add multiple try/catch lines into your code. In this case you should add a brief description of the current area to the error message:

let rule_name = '`PV | DocReady | 10 | All Pages';
try {



} catch (e) {

	_satellite.logger.error(rule_name + ' | init something | ' + e);

}

try {


} catch (e) {

	_satellite.logger.error(rule_name + ' | calculate another metric | ' + e);

}

Reason

Now, if you face errors in the debug console, it’s easier to find the source, even if you handle long code blocks. You don’t need to click through the stack trace.

Logging and Documentation

The same goes for logging. Always logg what you are doing. I don’t need to mention, how important inline documentation is. ;) Logging works the same as error handling:

_satellite.logger.info(rule_name + ' | calculate another metric');

Reason

Now, if you filter the browser console, it’s easier to get rid of the noise and debug a problem.

Inactive Rules or Data Elements

You will and cannot avoid to have inactive/disabled rules. You should keep that amount low, because they pollute your library. If you have inactive rules, add a prefix “INACTIVE” to the rules name and, preferably also to it’s components.

Reason

If you look up code parts, data elements or anything, the search will return you rule and component names. From those component names you will not see, if a result belongs to an inactive rule. The prefix INACTIVE will help you to quickly identify those results.