Oftentimes when I encounter a Google Tag Manager trigger for a single page or path, I’ll discover conditions like Page URL exactly matches or Page Path contains. While these rules can successfully fire a trigger on a given page, they don’t take into account query string parameters, which could cause triggers like these not to fire, even when a relevant page view occurs.
This understandably can be overlooked when you aren’t the end user that may encounter a query string parameter; as the person setting up GTM tracking, you may not be aware of all the potential query string parameters that might be appended during a users session.
This may not be a concern at the time of implementation if there are no query string parameters in use, but it could be an issue later down the road if parameters are introduced due to another script or function, so it’s best to set up trigger firing conditions to accommodate query string parameters from the start.
How RegEx Works
RegEx, also known as Regular Expressions, are a specific set of characters that search for a matching pattern in a string, such as a URL. This can be extremely useful when you need to narrow down rules to certain pages or paths within programs that allow them.
For marketers in particular, this can be a great time-saving and problem-solving tool when working with reports in Google Analytics, and Search Console, with audits inside Screaming Frog, or triggers in Google Tag Manager.
RegEx rules can get extremely complex. Fortunately there are many great guides and tools out there like regex101 that provide the ability to test your RegEx, and even automatically generate an explanation as you type.
Let’s take a closer look at the RegEx rule that we might want to apply to a home page with parameters so we can understand how it works.
https:\/\/domain\.com(?:\/(?:\?.*)?)?$
One of the first things you’ll notice in the string above are the backslashes next to trailing slashes in the protocol and next to the dot before the TLD (i.e .com).
Since slashes and dots are used in RegEx for other functions, the backslash is used to tell the rule ‘match this character literally’. This means that the characters after each backslash will be treated as literal slashes and dots, which in this case allows them to be read as part of the URL structure.
The next portion of the RegEx rule may seem like a mess, but it makes sense when you break it down into pieces.
(?:\/(?:\?.*)?)?$
Let’s start with the parentheses. Everything wrapped within parentheses is a ‘group construct’. So in the string above you can see that there are two group constructs.
Here’s the one in the middle of it all:
(?:\?.*)
The question mark and colon after the opening parentheses,(?:, signify that this group construct is a non-capturing group.
Groups that capture you can use later on in the RegEx rule to match or replace. Making a non-capturing group simply exempts that group from being used for either of these reasons. Since we don’t need to do anything additional with this RegEx rule, a non-capturing group makes sense to use here.
Moving along, you will notice that the backslash appears again, this time preceding a question mark \?. This is the question mark that is to be treated literally, the one that begins the query string parameter. The dot asterisk .* that follows the question mark means ‘any character that follows, any number of times’. So this allows the query string parameter to consist of any characters, and be any length, and still have the rule apply.
A question mark immediately following a character that isn’t being treated literally means ‘match zero or one instance of this character’. This should explain why it follows the smaller non-capturing group, in the overall non-capturing group. It’s saying ‘match zero or one instance of a query string parameter’.
(?:\/(?:\?.*)?)
This allows the rule to work regardless of whether a query string parameter or even a trailing slash after the TLD is present, meaning this rule will trigger on this URL whether or a query string parameter is present or not.
Lastly, the RegEx concludes with a dollar sign, signifying that the rule should match all the way through to the end of that line.
The next section will detail use cases for specific URL types using a combination of these RegEx characteristics.
RegEx Rules For Specific Pages or Paths
The RegEx rules below show how you can use the Matches RegEx (ignore case) condition in Google Tag Manager, and, depending on your target URL(s), accept URLs that contain query string parameters as part of the rule.
Be sure to replace domain.com with your domain, and the page or path with your target page or path.
For the home page
https:\/\/domain\.com(?:\/(?:\?.*)?)?$
For a specific page
https:\/\/domain\.com\/page(?:\?.*)?$
For pages under a specific path
https:\/\/domain\.com\/path\/(.*?)(?:\?.*)?$
For pages that are under multiple paths simply continue to add a new path\/ as shown below for a page three levels deep:
https:\/\/domain\.com\/path1\/path2\/path3\/(?:\?.*)?$
Did This Help?
Let us know in the comments if this quick tip helped you solve (or prevent!) a trigger issue – we’d love to hear about it!
