Using PadiTrack to Measure Site Navigation

PadiTrack is an easy to use, free tool that enables you to extend Google Analytics with more flexible goal funnels and other navigation path tracking.

PadiTrack offers several advantages over Google Analytics for setting up goal funnels:

1. Historical data – with Google Analytics, setting up a goal funnel means the data is reported starting the day the funnel is set up, so no historical data is available. With PadiTrack, you can set the date range as far back as your Google Analytics data goes.

2. Segmentation – advanced segments can’t be applied to funnels in Google Analytics, but PadiTrack provides the opportunity to apply segments, including custom advanced segments that you have set up in your Google Analytics profile! (Late-breaking: the *new* Google Analytics now in beta allows for segmentation of goal funnels – but it’s not fully rolled out yet.)

These strengths make PadiTrack a powerful tool for monitoring progress down the goal funnel, but also make it very useful for understanding navigation from one page to another.  This especially applies if you have a dynamic site and want to understand the movement of visitors from one page ‘type’ to another. For example, you may have ‘product category‘ pages with URLs like ‘‘ and ‘product detail‘ pages that have URLs like ‘‘. If you want to know frequently visitors go from category to product pages, you have several options:

  1. Simple calculation: If the only way a visitor can get to a product detail page is via a category page, the calculation is straightforward, based on unique pageviews of each type in the Content Report. But modern sites are rarely so strictly laid out, since we usually want prospects/customers to be able to get to product detail pages via search (off-site or on-site) or other convenient means.
  2. Set up a Google Analytics Goal Funnel either with with product detail pages as end goal, or as part of larger goal. Sensible approach, but doesn’t help if you want to see last month’s results in order to make a decision on testing priorities. Also, only the first step can be set as required, so it is not uncommon to see leakages in to the funnel steps from pages that are not previous steps. And you can’t segment the funnel data – at least not until you have access to the new features currently in Beta.
  3. Use the ‘Navigation Summary’ report, which is helpful in getting a sense of flow through a given page. But it only applies to individual pages (including previous and next), is based only on clicks, and only shows a limited number of pages in the ‘next’ list. The ‘class’ of pages we want to measure may be dispersed over a large number of individual pages.
  4. Use ‘In Page Analytics’: again, only one page at a time and, while it can be a helpful visualization, tends to be an unreliable data source.
  5. PadiTrack gets around all these issues! You can use various match type options or regular expressions to identify page types by URL or Page Title (bonus!), select your desired date range, and *boom* dat’s it. For more granularity, you can filter by top referrer or top keyword or apply GA advanced segments.
Paditrack select page

Example: setting up first step in PadiTrack

Once you set up your steps – as few as 2 or as many as 5 – PadiTrack will create the funnel on the fly for your chosen date range:

PadiTrack conversion funnel

PadiTrack Funnel/Navigation Path

So we can see in this case that about 15% of those visiting a category page went on to a product detail page during their visit. Depending on our expectations/goals, this may warrant testing changes to the category page design in order to improve flow-through to product details. Or you can extend the funnel by adding more steps (up to a total of 5) to assess further progress toward the end goal. Or you may compare this to other key navigation steps on your site to prioritize testing efforts. All easy to do, with results available in minutes.

Care to share any thoughts or experience with PadiTrack or other conversion funnel/navigation tools? Please do!

Google Analytics: Rewriting Page URLs to include ‘WWW’

Avoid disaggregating page data in Google Analytics by applying a filter to force all ‘www’ domains to be displayed in Content reports as ‘www’ version ( as opposed to

Out of the box, Google Analytics displays URLs in Content reports without using the domain name (‘page1.html’ instead of ‘‘) . This makes sense in most cases, since it is redundant and you probably know what your domain name is. However, there are a variety of situations where you may want to display the full domain name, most commonly when your site is spread across multiple subdomains. (,,, etc.)

It is easy enough to add a filter to your profile that will cause the full domain/subdomain to show up in your Content reports. (And, of course, if you want to track across multiple domains and subdomains, you’ll need to modify your GA tracking code to accommodate this.)

Potential Issue: Page Data Split Between Two Versions

All well and good, but there is an issue that arises when the full URLs are displayed in Content reports on sites where visitors can access the site at both ‘’ and ‘‘. As a result of these two versions of  the domain, the same page may be reported on separately, in the ‘www’ and ‘non-www’ versions:

Page data split between www and non-www

In the example above, the same page is shown in two separate versions, one with 16 pageviews and one with 6 pageviews. Not cool.

For search engine optimization,  this causes canonicalization issues and is best dealt with via 301 redirect. However, this may not always be possible – at least in the near term, particularly if you don’t have access to your server settings – and you may want to have your data as accurate and relevant as possible NOW.


By applying an additional filter ahead of the filter that adds the domain to the adds the domain to the URI, we can force Google Analtyics to include the ‘www’ at the beginning of the domain in cases where it is not already present. The desired result:

Page data consolidate as 'www'

Here we can see that the data for ‘default.aspx’, previously split between two ‘pages’ in the report, is now consolidated to give us a more relevant picture of what is happening with visitors to the site: 22 pageviews of this page (16 + 6). Aaahh…that feels better!

Two Filters Used: one to add ‘www’, one to show full URL

This solution was reached by applying two straightforward filters to the GA profile:

1. A filter to recognize situations where the hostname starts with the ‘raw’ domain without ‘www’ (‘’ in this example) and then adds ‘www’ at the beginning of the hostname in these situations. This filter will not add ‘www’ in cases where it is already present, nor will it add ‘www’ in cases where the page is on a subdomain. It does assume that you have a single domain, so it would have to be modified in the case of cross-domain traffic. It also assumes that you want to add ‘www’ to all URLs, as opposed to removing ‘www’ from all URLs. If you prefer no ‘www’, just flip the fields around.

Filter 1: Add the WWW

2. The usual filter for displaying the full URL including domain. I have included a leading ‘/’ in the Output To -> Constructor – this is not typically recommended in official documentation, but I did see it recommended somewhere by one of the big names in the field, so I figured I should try it and have seen no adverse affects.

Filter 2 - included domain

That’s all there is to it. Works for me and I hope it will work for you, but let me know if you have any feedback.

This post goes out to my friends at (or if you prefer 🙂 ).


One approach that I had high hopes for didn’t pan out. Not sure why:

Filter attempt with search and relpace that didn't work