Page, Section, Site Naming Best Practices

Recently on Twitter, there was some discussion about the best way to name your pages in SiteCatalyst. Therefore, I thought I would share some thoughts on the best way to set names for Pages, Sections, etc… when using SiteCatalyst. Hopefully, you are already doing most of what I will mention here, but just in case, here are my suggestions. Also, keep in mind that many people have different styles of naming pages (and feel very strongly about it!) so what is shown here are my personal preferences…

Naming Pages
If you don’t manually apply a “friendly” page name to the s.pagename Traffic variable (sProp) in SiteCatalyst, Omniture will capture the URL by default. This is not ideal for the following reasons:

1. URL’s can be very long and exceed the sProp character limit (normally 100 characters)
2. URL’s can be hard to understand by end-users
3. URL’s can have querystring parameters that get cutoff which means that many pages get treated as one page name in SiteCatalyst (which ruins Pathing reports)
4. URL’s can have a http:// and https:// versions which means two versions of each URL which subdivides Pathing, Unique Visitors, etc…

Therefore, it is highly recommended that you name your pages the way you would like to see them in the Pages report. I generally recommend naming pages based upon directory structures or manually by adding fields to your content management system. Once you figure out how you will name your pages, the key question is what should you name your pages. Here are my recommendations:

• Make sure all pages within each unique website have a common identifier. For example, if you have three distinct websites that serve different purposes, I like to assign a value in the page name for each website so I can easily filter those pages in a global report suite (one that has data from all websites). For example, for the Omniture website, I would have an identifer for the public (marketing) website (i.e. “omtr:”) and a different identifier for say the Idea Exchange (i.e. “ideas:”).
• I like to include the section in the page name when possible. For example, if the Omniture public website has a section for “Products” and another for “Services,” I would include those in the page name (i.e. “omtr:products:” or “omtr:services”). This allows you to easily filter Page reports to get all of the pages within a section. Some companies also include the sub-section in the page name which is fine as long as you don’t hit the sProp character limit.
• Make sure all pages have a unique name. If you have two pages with the same exact page name, SiteCatalyst will treat them as a single page and all stats for that page will be merged (including paths).
• Be mindful of case-sensitivity. sProps are case-sensitive, so if you have the same pagename value, but in different cases, you will get two distinct page names. A common best practice is to force upper or lower case in the JS file to avoid any issues.

So if you put all of these ideas together, a list of your pages might look like this:

One wrinkle that can emerge are cases where you have multiple geographic websites. For many companies, this results in a similar version of the website, but translated into different languages. If you have this situation, I recommend tweaking the above page names to include a site locale indicator. For example, each page in the UK site should have “uk:” in the page name and so on. When this is done, your page names might look like this:

[Advanced User Alert – If you have multiple site locales, I also recommend passing the page name without the site locale to a different sProp (with Pathing enabled) so you can see how a page does across all site locales (i.e. Participation). I also like to pass the site locale by itself to a separate sProp so in a global report suite I can create correlations between sProps and other variables (i.e. Internal Search Terms).]

One other item related to site locales is the use of different languages or translated pages. While I do recommend different page names for each site locale, I do not recommend that you have different page names for the same page translated into different languages. You can read more about this in my old Foreign Language post.

As you can see, this doesn’t look all that hard to implement, but by using the above items you can easily:

• Filter pages for a website (i.e. omtr: vs. ideas:)
• Filter all pages for a specific section (Search contains :services:)
• Filter all pages for a particular site locale (Search contains “:uk:”)
• Filter on a combination of the above items. For example, let’s say you wanted to see all UK Product pages (Search contains “:uk:products:”)

When you look at this it makes common sense, but I can’t tell you how many clients I ran into that had incomprehensible page naming which made everything more difficult. Even if it means losing some historical page data, I always recommend that clients have good page names as it pays great dividends down the road…

Site Sections (s.channel)
After dealing with Page Names, the next thing I like to tackle is Site Sections. These are useful if you want to see how visitors are navigating your website at a higher level than pages. If you have good page names, you really should be able to build your Site Sections by setting it equal to the page name minus everything past the last “:” symbol. For example, in the example above, if the page name is “omtr:us:services:consulting” then the section would be “omtr:us:services” (you choose whether you want to include the “:” at the end or not). I have seen many clients that can set Site Section values automatically based upon good page names which saves a lot of development work and ensures consistency.

Site
One variable that many clients forget to include is the Site variable. Essentially, what you are doing here is to pass in a value for the website by itself into an sProp. In the example above, this would mean values of “omtr” or “ideas” by themselves in an sProp. Doing this allows you to see total Visits and Unique Visitors by site in one report and when Pathing is enabled, allows you to see how people are navigating from one website to another. Again, if you have good page names, you can set the Site variable by simply grabbing everything before the first “:” symbol in the page name.

Page Type
Those of you who have read my previous blog posts know that I am a fan of setting a Page Type on each page that represents the function of the page. I won’t rehash this topic, but recommend you check out my prior post on this.

Advanced Stuff
For those who are a bit more advanced in their SiteCatalyst usage, you can check out the following page related advanced topics:

• Setting a Page View Event
• Passing Page Name to an eVar
• I recommend passing the URL to a custom sProp. This is a good thing to do since URL is not available in DataWarehouse by default. There are also cases where being able to segment on the URL can get you out of a jam…

So there are a few items related to naming Pages, Sections, etc…Let me know if you find these tips helpful and/or if you have come up with best practice suggestions of your own you’d like to share…