A lot of the magic that happens in DTM is based on CSS (cascading style sheets) and CSS Selectors (using the styles applied to HTML elements as a map to your site). Even if you have a data layer to avoid relying on CSS for your data elements, Event-based Rules still rely on CSS Selectors to figure out which elements to listen to. For instance, if I want DTM to listen for clicks on my blog menu, which looks something like this:

<li id="menu-item-82" class="menu-item menu-item-type-custom menu-item-object-custom menu-item-82">
     <a href="http://digitaldatatactics.com/beaconParser/">Beacon Parser Tool</a>
</li> 

I might tell it to listen to link/anchor tags (“a” tags) that are within list items (“li” tags) that have a class of “menu-item”.  The CSS Selector for this would be “li.menu-item a”, so I might create this rule in DTM:

This should work, BUT there are a few potential problems:

• it relies on the CSS of my site staying the same, and on my ability to interpret CSS selectors to get one with the right level of granularity.
• Developers wouldn’t know that Analytics is relying on that “menu-item” class, and they might change it without notice.
• An implementation may have dozens of these Event-based rules, which could require a lot of time to set up and test.
• Lastly, if I want to pass a value like “nav click:beacon parser” I have to figure out a way to dynamically grab the value “beacon parser” from the surrounding HTML.

There is an alternative: instead of relying on classes, we could work with developers to add another attribute to the elements we want to listen to. This attribute would be completely arbitrary- I’m going to use “data-track” for this post. So I might ask developers to add “data-track=’nav click'” to that element:

<li id="menu-item-82" class="menu-item menu-item-type-custom menu-item-object-custom menu-item-82" data-track="nav click:beacon parser">
     <a href="http://digitaldatatactics.com/beaconParser/">Beacon Parser Tool</a>
</li>

Then in DTM, I could set up a rule that listens not to CSS, but for clicks on any item that has “data-track” on it:

Or if I wanted, I could have this particular rule only fire on clicks where “data-track” started with “nav click”: “[data-track^=’nav click’]”.

This approach has some benefits:

• Developers aren’t likely to accidentally change the ‘data-track’ attribute
• Setting up rules in DTM doesn’t require deep knowledge of CSS
• You don’t have to rely on the HTML around the element to provide dynamic values (like “beacon parser” in my example above.) Whatever values I want in my reporting, I can have put in friendly wording into my data-track attribute.

As well as a few potential downsides:

• I’d need to get my developers to add this attribute to all elements I want to track.
• I’d need some sort of management on the values of those attributes (I may want to document that we’re using “nav click” and keep some standards and consistency across how data-track is used across the site.)

Ultimately, for many clients, the benefits of having control and flexibility far outweigh the upfront work of adding those tags.

Hopefully this approach can provide a solution to some folks out there, or at least can serve as a starting point for discussing the different options for setting event-based rules. I’d love to hear about folks who have used this solution or other solutions to keep CSS selector dependency to a minimum!