Implementing Adobe Analytics Predefined Traffic Variables

Most people start an Adobe Analytics implementation with s.pageName, and rightly so, because the page name is the backbone of page-level reporting. But it is only one of five predefined traffic variables that together form the standard set every implementation should carry. The other four, site sections, server, hierarchies, and the 404 flag, are not custom variables you invent. They have fixed names and fixed jobs built into the Analytics reporting structure, and using them well gives analysts several clean ways to slice page data without cramming everything into the page name. This article walks through each one, plus the data element naming conventions that keep a real implementation maintainable.

The core set at a glance

Alongside s.pageName, four predefined traffic variables round out page-level collection. s.channel records the site section a page belongs to. s.server records the domain or server that delivered it. s.hier1 through s.hier5 map a page’s full position in the site structure, though this one is now legacy. And s.pageType exists for a single narrow purpose, flagging 404 error pages. The first thing to know is that hierarchies are largely redundant in modern Analytics, because Analysis Workspace lets you break any dimension down by any other, achieving the same drill-down without a dedicated variable. Most implementations skip s.hier entirely and encode hierarchy inside s.pageName with colons instead, so the real working set is page name, channel, server, and the 404 flag.

Site sections with s.channel

The channel is the high-level grouping that sits above the page name. Where s.pageName identifies the individual page, s.channel identifies which top-level section of the site that page lives in. The cleanest mental model is the main navigation: the channel is the nav tab, Women, Electronics, Jewellery, and the page name is the specific page within it. That also tells you the easiest way to define your channel values, which is to look at the site’s primary navigation, because each nav item is usually one channel.

// Every page in the Women's section carries this value
s.channel = "Women";
// The full set of channel values for the Summit Outdoors site
s.channel = "Women";
s.channel = "Men";
s.channel = "Jewellery";
s.channel = "Home and Garden";
s.channel = "Children";
s.channel = "Electronics";
s.channel = "Company";

Set on every page in a section, the channel makes the Site Sections report, found under Traffic and Site Content, a direct mirror of your top-level navigation, with all the page views, visits, and unique visitors for a section rolling up to one row. A few technical properties matter: the value is capped at 100 bytes like the page name, it is case sensitive so “Women” and “women” are two different sections, and it should be populated on every page that belongs to a section, including high-traffic ones like the home page, which can be its own channel. The terms channel and site sections are simply the code name and the report name for the same thing, and you should define your channel values at the same time as your page naming convention, since the two work together at different levels of granularity.

Site and server identity with s.server

The server variable records the domain or server that delivered a page, populating the Servers dimension. It has a few uses, from recording a literal hostname to applying a friendly regional label, and it can even read the domain straight from the browser.

// A literal server hostname
s.server = "mainserver.summitoutdoors.ca";
// A friendly label identifying a regional site
s.server = "Summit Outdoors United Kingdom";
// Or read the actual host dynamically from the browser
s.server = window.location.host;

The most valuable use is in global report suites, where several country or regional sites feed their data into one suite. Setting s.server to identify the site lets you keep the page name clean and universal while the server dimension carries the site’s identity.

// Home page on the UK site
s.pageName = "Home Page";
s.server   = "Summit Outdoors United Kingdom";

Here the page name stays a simple “Home Page” rather than something like “UK:Home Page”, and the country lives in the server dimension instead, which you can then filter and segment by. This pairing also feeds virtual report suites, since you can build a VRS filtered to a single server value to give the UK team their own view of the data. The variable is again 100 bytes and case sensitive. One caveat worth heeding: do not use it for load balancing analysis on large sites, because it does not account for differences in file type, so a server delivering fifty heavy video files will show inflated numbers next to one serving lightweight HTML, and server-side logging is the right tool for genuine load analysis.

Hierarchies with s.hier, and why to skip them

The hierarchy variable maps a page’s full position in the site using a pipe-delimited string, with up to five hierarchy variables each supporting up to five levels.

// Full path for a news article
s.hier1 = "UK|Economy|News Articles";

The segments read as country, then section, then content type, drilling from broad to specific. Useful as that sounds, Adobe now treats this variable as largely redundant, because Analysis Workspace can break any dimension down by any other and reproduce the same drill-down without a dedicated variable. The modern practice is to skip s.hier and encode hierarchy in the page name with colons instead, which keeps your implementation simpler and your reporting just as flexible.

Catching broken links with s.pageType

The last predefined traffic variable has exactly one valid value, "errorPage", and one job, flagging 404 Page Not Found errors so broken links can be diagnosed. It goes only on your 404 template, paired with a deliberately blank page name.

// Place ONLY on the 404 error page template, nowhere else
s.pageName = "";
s.pageType = "errorPage";

Leaving the page name blank is the whole trick. When s.pageType is set to "errorPage", Analytics falls back to the URL for the page name, which means the address the visitor actually tried to reach becomes the recorded value and lands in the Pages Not Found report. That is exactly what you want for diagnosis, because it captures the broken URLs rather than a useless generic label. The report then shows every URL that returned a 404, and right-clicking a line item to break it down by the Referrer dimension reveals which external site or internal link sent the visitor there, surfacing retired links still sitting in your own navigation as well as broken links on partner sites and in old campaigns. A few rules keep it reliable: only ever implement this on the dedicated 404 template, match the value "errorPage" exactly including its capital P, and remember the page name captures only the first 255 characters of a URL, with anything beyond truncated. The erroneous URL also appears in the regular Pages report in addition to Pages Not Found.

Naming data elements so you can find them

A production Launch implementation can hold dozens of data elements, and without a convention, building rules becomes slow and error-prone. Two conventions solve this. The first is a category prefix, grouping elements by the kind of data they hold so they sort and search together in the Launch interface.

Page: Page Name
Page: Site Section
Product: Product Name
Product: Purchase ID
Customer: Login Status

A Page: prefix covers everything about the current page, Product: covers product attributes, and Customer: covers visitor attributes like login or registration status, so related elements cluster alphabetically and stay easy to scan. The second convention is a camelCase version for use in code, because spaces and colons break when you reference an element inside custom JavaScript. So “Page: Page Name” becomes pagePageName and “Customer: Login Status” becomes customerLoginStatus, with no spaces or punctuation and each later word capitalised. In practice teams use both, the readable form in the Launch dropdowns and the camelCase form when pulling a value in code, for example through _satellite.getVar('pagePageName'). The important thing is to agree the convention before creating any data elements and to record it in the SDR, so you never end up with pageName, page_name, and Page Name all coexisting and quietly doing different things.

How they fit together

The point of the set is that each variable operates at a different level, giving analysts multiple lenses on the same page. A single page view might carry a detailed colon-delimited page name, a broad channel, and a server identifying the site.

s.pageName = "Women:Activewear:Fur Trim Ski Jacket";  // most granular
s.channel  = "Women";                                  // section grouping
s.server   = "Summit Outdoors United Kingdom";         // site identity

In reporting you can start from Site Sections by channel, drill into individual Pages by page name, and filter by Server to isolate a domain, slicing the data several ways without forcing all that detail into one variable. Choosing which variable to use is straightforward once you frame it as a question: the specific page is the page name, the top-level section is the channel, the site or domain is the server, a full structural path is the legacy hierarchy you should generally avoid, and a 404 is the page type set to "errorPage" with a blank page name.

Mistakes to be mindful of

A handful of mistakes recur. Forgetting to put the home page in a channel leaves a high-traffic page unclassified, so a common fix is a dedicated s.channel = "Home". Inconsistent capitalisation in the channel splits one section across multiple report rows, which is why the exact string belongs in the SDR and the data layer. Setting s.pageType = "errorPage" on a page that is not a 404 floods the Pages Not Found report with false broken-link alerts, so it stays only on the error template. Forgetting to blank the page name on the 404 page defeats the whole mechanism, because a value like “Error Page” means the broken URLs are never captured. Using the server variable for load balancing on a media-heavy site produces misleading distribution data, so reach for server logs instead. And skipping a data element naming convention guarantees a sprawl of near-duplicate elements that slow every future build. Get these variables and their conventions right early, document them in the SDR, and the standard traffic data underpinning your whole Adobe Analytics implementation stays clean and trustworthy.

See you soon.