An alternative to using CSS for Event-Based Rules

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="">Beacon Parser Tool</a>

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 “ 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="">Beacon Parser Tool</a>

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!

6 thoughts on “An alternative to using CSS for Event-Based Rules

  1. This is a great post Jennifer! I do have one question. I am having trouble figuring out how to pull the value of the custom attribute and put it into an eVar. In your example, it would be “beacon parser.” To what would I set the eVar to grab that value when the item is clicked? Thanks in advance!

    1. Good question! You’ll have to piggy-back on the “this” object- I know for sure you could do this in the custom code for the analytics tool in the event Based Rule- something like s.eVar3=jQuery(“[data-track]”).attr(“data-track”) if your site has jQuery. You may also be able to do directly in the DTM interface for the variable you want it to pass to- definitely test it first though (and let me know if that works!) has some more examples.

      1. Thanks Jenn! I could never get it to work directly in the DTM interface, but was able to in the custom code so that was a great idea. If you don’t have jquery, you can pull the value using standard javascript using something like this: s.eVar62=(this.getAttribute(‘data-track’)); If there turns out to be a way to do this directly in the interface, I’d love to see it.

Leave a Reply

Your email address will not be published. Required fields are marked *