Google Analytics Regular Expression Negative Look Ahead Workaround
BY Doug Hall ON February 20, 2012 | IN Thought Leadership
This is a alt
Doug Hall
Doug has 20+ years industry experience working with global brands on Web Analytics and Conversion Rate Optimization projects. A frequent conference speaker on CRO, Google Analytics, and Tag Management, he has published a wide range of authoritative articles on the subjects.


Have you ever come across a situation in Google Analytics reports where you want to see a segment of users who did go to a page (or set of pages) but did not go to another page or set of pages?

This kind of question requires a particular type of regular expression – a negative look ahead.
Here’s a realistic example, a demonstration of the issue and a technique to work around.


You want to see all the users who went to product pages AND the sale page but nowhere else on the site. So you need to use an advanced segment including pages that match the regular expressions:



^\/(sale|products.*\.php) page matchproduct expression lookup

Because you only want to see the segment of users who saw only products or the sale page, you’ll also need to use the regular expression below to exclude users who saw other pages during their visit – exclude anything that is not /products or /sale.php:


sale expression results no matchproduct expression results no match

So, two valid regular expressions there but try those in an advanced segment like this:


Advanced segment lookup

And you’ll get a response like this:


Resource error message

Work Around

Rather than include pages based on a negative look ahead, try excluding based on a page URI not matching a regular expression.

Try this for size:



URI search

So, all URIs starting with /s will be excluded. This will exclude views on anything apart from /sale but what about /products?:


So, match any URI that doesn’t start with /s or /p. Try that in an advanced segment:


Advanced search URI

This advanced segment doesn’t fail when you add it as no look ahead is used. The keen-of-mind among you will know your data and will be concerned about users who may visit ‘purchase.php’ for example. They won’t be excluded by ^\/([^s|p].*).*\.php How do we handle exceptions like these?

I’d consider two options. Either use a virtual pageview to make your include and exclude regular expression building easier or (better for historical data) add a set of further, more explicit exclusions using regular expressions or ‘matching exactly’ clauses:


Purchase advanced lookup

So, not perfect. Certainly not as elegant as a negative look ahead but this is not a perfect world. This is a working solution that might help – we hope so!