You Deserve an Awesome SiteCatalyst Implementation – What’s in a (page)Name?

One of SiteCatalyst’s most basic yet powerful features is the ability to use the pageName variable to help give more meaning and context to your page view, visit, and pathing metrics. With a good page naming system in place, anybody in your company from the web analyst novice to the high-powered executive will be able to tell exactly which real-life web page is being referred to in each row of the SiteCatalyst pages report. Without a good page naming system in place, however, the potential lies for confusion, ambiguity, and sorrow when your users work with SiteCatalyst. And sorrow is something we don’t want you to experience when working with SiteCatalyst.

Every page needs a page name

When you run your pages report today, you will (hopefully) see values that are understandable and “friendly” to some degree or another (e.g. “home page”, “category: women’s dresses”, “checkout: purchase complete”, etc.). However, you might also notice a few URLs in your pages report, which is a good sign that something in your implementation needs to be improved. Wait, you say you haven’t seen any URLs in your pages report before? Well, then do this:

https://blog.adobe.com/media_84d63488eead16927c30dd8dc2fceb009fd3c495.gif

  1. Log into SiteCatalyst
  2. Run the Site Content > Pages Report
  3. In the filter data box, type in “http” (without quotes, as seen above) then click on Go
  4. Wait for it… wait for it…

Voila! You’ve now most likely produced a list of URLs for pages on your site that have SiteCatalyst code but do not have the pageName variable set within the SiteCatalyst code. Horrible, right? Wrong! This is exciting because you have an immediate opportunity to improve your SiteCatalyst implementation! Go ahead and deliver this report to your development team and ask them to insert a value into the pageName variable within each URL’s page code. Remember that if the pageName variable is not set within the page code, then SiteCatalyst will automatically assign the URL as the page name at the time of data collection/report processing.

As a backup solution – but one that might not be feasible depending on the amount of work – you can setup a series of SiteCatalyst (v15) processing rules to fill in the pageName variable for these untagged pages. The value of the pageName variable can be set to whatever you want depending on the value of the URL passed in via the SiteCatalyst server call.

https://blog.adobe.com/media_4387f167e69cd5b064e1cd28ddf5f177c422385b.gif

Now, if nothing was returned from your filtered search for “http”, then congratulations, you are one of the very lucky few that have every single page tagged with a legitimate pageName value! Give yourself a well-deserved pat on the back!

Every Page Name Needs a Page Type

Besides a few URLs, you might have also seen in your pages report some ambiguous values like “Men’s”, “Checkout”, “13 inch Lawn Mower”, and so forth. From these brief descriptions, you could probably guess the specific page each value is pointing to, but without more detail and context in each value, you most likely will be off on your guess. For example, the “13 inch Lawn Mower” value could either refer to a category/browse page that shows a list of 13 inch lawn mowers or it could refer to a product detail page that features a product with the literal name of “13 inch Lawn Mower”. Who knows? Unless the pageName value contains understandable, organized, and detailed information, then you and your colleagues will never know for certain what pages are being viewed when you look at the Pages report.

So when it comes to a page naming strategy, we in Adobe Consulting recommend that every pageName value begins with at least the page **type. **Recording the type of page being viewed is essential both for organizational purposes and so that you can know from a “horizontal” perspective how people move across your site as they progress throughout their visit. Usually, the most common page types that we at Adobe Consulting have seen on every retail site include the following:

From these basic values, you might be able to derive even more smaller and granular page types. For example, the “Browse” page type might be divided into the “Department Browse”, “Category Browse”, and “SubCategory Browse” page types; “Product Detail” pages might need to be separated out from your “Product Quick View” layers; the “Checkout” page types could be split out into each individual step of the checkout process (e.g. “Checkout: Shipping”, “Checkout: Billing”); etc.

The end goal is to ensure that every web page template that your developers have used to build up your site matches up with a specific page type. Once the developers match a page template with a page type, the remainder of their work for setting the pageName variable should be relatively easy to complete.

Here is an example of an awesome implementation of the SiteCatalyst pageName variable, courtesy of beatsbydre.com (FYI – numbers have been changed). Notice how each value begins with a page type and that the context after the page type leaves no question as to what page each value is referring to, specifically. In cases where no more context is needed after the page type (e.g. the home page), the pageName simply remains equal to the value of the page type only.

https://blog.adobe.com/media_09348d4a278a8521ce97cf7c207809dd9f7485a1.gif

With a page type at the beginning of the pageName variable value, the Pages report is infinitely easier to read and analyze.****

Every Page Name Needs Context

beatsbydre.com is a relatively straightforward site and thus, its SiteCatalyst users don’t require a lot of context to the pageName values in order to understand and interpret the data. This serves the company’s purposes perfectly but for sites that have a large number of departments, categories, and subcategories, the pageName values will need to become more complex and varied in correlation with the site’s growing complexity.

Regardless of your site’s complexity, your goal is to ensure that every single page your site has a unique pageName value associated with it. To accomplish this for large sites, your developers shouldn’t have to hard code a value on each page; that approach could be way too time consuming. Rather, they should be able to set the value of the pageName variable dynamically based off of server-side code that they generate within each of your sites’ page templates.

Or in other words, the developers should make sure the pageName is set equal to:

The colon-space that separates the page type from the rest of the page context might seem like a trivial addition, but it goes a long way in helping to organize the report structure and will allow your SiteCatalyst users to easily “eyeball” the pages report when they first open it.

Sheplers.com has done a fantastic job following these page naming principles and, as a result, has been able to scale their pageName values to cover every page on their site (numbers have been changed here as well):

https://blog.adobe.com/media_95420455171233815d8a43607ec6f48069732474.gif

Isn’t that so much easier to read than what you (probably) have right now?

On a side note, you’ll notice that the “search results” value in this example report is somewhat of an “outlier”. In this case, the value is meant to cover every page view of Shepler’s internal keyword search results page regardless of the keyword used in the search. As a best practice, the keyword search results page should be the one exception to the rule that every page on the site with unique content needs a unique pageName value.

In the end, the way you implement the pageName variable could be considered a microcosm of your entire SiteCatalyst implementation. If you can get the page naming right, then most likely you will get the rest of your implementation done right as well.

Do you have any ideas that have worked for you? Feel free to post your comments/questions below!