Search code examples
javascriptgoogle-tag-manager

Regex match event not firing in Google Tag Manager on filter click

On my website I want to fire a Google Tag Manager event anytime an element containing a particular CSS class (or more specifically a partial match for a CSS class) is clicked.

I have a Click - All Elements event defined and have it set to fire on "some clicks."

Since the element is variable with the CSS class I have it set to perform a "matches RegEx" action.

The regex is .am-filter-item-*-

When the element is clicked the output to the Tag Manager debugger is this...

HTMLSpanElement: html > body.page-with-filter.page-products.categorypath-industrial-led-lighting-commercial-building-exterior-lighting-parking-lot-lighting.category-parking-lot-lighting.page-layout-2columns-left.catalog-category-view.page-layout-category-full-width > div.page-wrapper > main.page-main#maincontent > div.columns > div.sidebar.sidebar-main > div.block.filter#layered-filter-block > div.block-content.filter-content > div.filter-options#narrow-by-list > div.filter-options-item.active > div.filter-options-content > form.am-ranges > ol.items.am-filter-items-attr_colortemp > li.item > a.am-filter-item-62fd0cc85dfb6 > span.count

Which when I ctrl+f on .am-filter-item- it does in fact turn up the element as a portion of that entire list.

When I run this though a RegEx tester it does successfully find a match. enter image description here

What am I misunderstanding about how regex matching works within Google Tag Manager?

Additionally simply setting a Click Element to contain the text .am-filter-item- would also be viable as every click I want to listen for should contain that snippet of a class somewhere within the element. However in testing this functionality/methodology does not work either.

Solution

  • The solution to this was... arduous.

    As @BNazaruk points out what Google Tag Manager represents or reports as a string is not actually a string. What it is actually showing you is the node/element path to the final element that was clicked. The gtm object then splits out a number of other pieces of data based on this element.

    As a result you can't use RegEx matching on it, you also can't use contains. You can use the CSS query selector but that has some pitfalls as well in that it wants you to know, and specify the entire path to the element. Which if you have any kind of dynamic insertion is a real paint to handle, if not impossible.

    Simo Ahava points out that in most cases the matches CSS selector is the best way to go if what you're trying to target is relatively simple.

    I have to assume though that Simo ran up on the same problem of needing more granularity or simply easier matching that would allow him to view the element path as an actual string (you know what Tag Manager says it is) as opposed to a element path that it actually is.

    As such a user on the Google Support forums for Tag Manager last year addressed this and pointed to a follow up blog post by Simo.

    His blog post "CREATE A CSS PATH VARIABLE FOR CLICK ELEMENT" explains how to and provides some code for a custom javascript element which will turn the element path into an actual string.

    Returning the string from this variable will then allow you to use actual contains or Regex Matches functions on the element path.

    SOAPBOX: This is some terrible design on Google's part. I get why they'd want to have the element not simply be a string because you get more access to more dynamic data that way. However the debugger needs to clearly indicate it is not a string, and they need to provide more robust tools to actually access the element if the intend for you to interact with an manipulate it as part of a series of nodes.