Page Names with and Without Locale in Adobe Analytics

Have you found yourself in a situation where your pages in Adobe Analytics are specific to a locale but you would like to aggregate them for a global view? It really isn’t uncommon to collect pages with a locale. If your pages names are in a URL format then two localized version of the same page may  look like so:

/us/en/services/security/super-series/

/jp/jp/services/security/super-series/

Or if you are using a custom page name perhaps it looks like this:

techco:us:en:services:security:super-series

techco:jp:jp:services:security:super-series

For this example we’re going to use the URL version of the page name. This could have been put in place to provide the ability to see different locales of the same page next to each other. Or maybe it was just the easiest or most practical approach to generate a page name at the time. Suppose that you just inherited an implementation with this setup but now you are getting questions of a more global nature. Your executives and users are wanting information on a global level. At the same time we still have the need for the locale-specific information. In order to meet their needs, you now need to have a version of the pages combined but still have the flexibility to break out by locale. To do this we’ll keep our original report with pages like “/us/en/services/security/super-series” but create a version that combines those into something like “/services/security/super-series/”. This new value would represent the total across all locales such as /us/en, /jp/jp, or any others we have.

Since we need to do this retroactively, classifications are going to be the best approach here. We’ll set this up so that we have a new version of the pages report without a locale and use the rule builder to automate the classification. Here’s how it would work…

Classification Setup

If you have worked with classifications before then this will be easy. First, go to your report suites under the admin tab, select your report suites, and navigate to the traffic classifications

The page variable should show by default in the dropdown of the Traffic Classifications page. From here select the icon next to Page and click Add Classification. Name your new classification something like “Page w/o Locale” and Save.

Your classification schema should now look something like this:

Classification Automation

Now let’s automate the population of this new classification by using the Rule Builder. To do so, navigate to the Admin tab and then click on Classification Rule Builder. Select the “Add Rule Set” button and configure the rule set like so:

Purple Arrow: this is where you select the report suite and variable where you want the classification applied. In this case we are using the Page variable.

Green Arrow: when this process runs for the first time this is how long it should look back to classify old value. For something like this I would select the maximum lookback. On future runs it will just use a one-month lookback which works great.

Red Arrow: Here is where you set up the logic for how each page should be classified. The order here is important as each rule is applied to each page in sequence. In a case where multiple rules apply to a value the last case will win since it is later in the sequence. We are going to use that to our advantage here with the following two expressions:

1. (.*) This will simply classify all pages with the original value. I’m doing this because many sites also have non-localized content in addition to the localized URLs. This ensures that all Page values are represented in our new report.
2. ^\/..\/..(\/.*) This expression actually does something for our localized pages. There are several ways to write this expression but this one tends to be more simple and shorter than others I’ve thought of. This will look for values starting with a slash and two characters, repeated twice (e.g. “/us/en”). It will then extract the following slash and anything after that. That means it would pull out the “/services/security/super-series/” from “/us/en/services/security/super-series/”.

Other considerations

If you have copied your page name into an eVar (hopefully so) then be sure to set up the same classification there.

If the Classification Rule Builder already has a rule set doing something for the page variable then you may need to add these rules to the existing rule set.

If you want to remind users that “Page w/o Locale” has the locale removed you can also prefix the new values with some value that indicates the value was removed. That might be something like “[locale removed]” or “/**/**” or whatever works for you. To do this you would just use “[locale removed]$1” instead of “$1” in the second rule of the rule set.

If you are using a custom page name like “techco:jp:jp:services:security:super-series” then the second rule in the Rule Builder would need to be modified. Instead of the expression I outlined above it would be something like “^([^:]*):..:..(:.*)” and you would set the “To” column to “$1$2”. This will pull out the locale from the middle of the string and give you a final value such as “techco:services:security:super-series”