The Most Important Variable in Your Analytics Implementation

There is a variable in Adobe Analytics that quietly determines whether your reports are useful or useless. It sits at the foundation of the Pages report, pathing analysis, fallout funnels, and the Visitor Click Map. Get it right and analysts can navigate reports without needing a developer to translate every row. Get it wrong and business users stop trusting the data, adoption stalls, and months of reporting become difficult to interpret.

That variable is s.pageName. And most implementations do not treat it with the seriousness it deserves.

Why This Matters More Than It Looks

When s.pageName is not set or is set carelessly, Adobe Analytics falls back to the URL. This sounds harmless until you consider what URLs actually look like in practice. The same home page served at www.example.com/ and www.example.com/index.html?ref=nav&src=header appears as two separate pages in every report. Page views are split. Visitor counts are split. Pathing becomes fragmented. And the moment your development team restructures URLs for SEO reasons, historical continuity in your analytics disappears entirely.

A well-implemented s.pageName solves all of this. Regardless of which URL a visitor uses to reach a page, everything consolidates into one clean row in reports. The URL becomes irrelevant to reporting. Development teams can restructure the site without touching a single analytics number.

Hard Limits Before You Start

Before deciding on a naming convention, there are technical constraints that shape every decision.

The maximum length for a page name is 100 bytes, not 100 characters. This distinction matters. Standard ASCII characters count as one byte each, but accented characters like é, à, or ñ count as two bytes. Cyrillic and Asian character sets can run to four bytes per character. A page name that looks comfortably short on screen may exceed the byte limit as soon as it passes through a multilingual content pipeline. If your organisation cannot guarantee consistent use of diacritics, it is safer to avoid them entirely.

Case sensitivity is another constraint that catches teams off guard. L'Oréal cosmetics and L'Oreal cosmetics are treated as two different pages in Adobe Analytics. Capitalisation inconsistencies produce the same fragmentation problem.

The most operationally significant constraint is what happens when you change a page name after data has accumulated. Renaming a page does not reassign historical data. The old name and the new name appear as separate line items in reports with no way to merge them retroactively. This is not a recoverable situation. It means trend analysis breaks at the point of the rename, and any report covering a period spanning the change becomes unreliable. Get the naming convention right before going live.

Five Criteria Every Page Name Should Meet

The best page naming conventions are built around five principles, sometimes called the five Cs.

A page name should be contextual, meaning it reflects where the page sits in the site hierarchy. A dress page within the Women’s Elegant section should carry that hierarchy in its name, not just the product title in isolation. It should be clear, immediately understandable to someone reading a report without knowing the URL or the internal content management system. Internal codes, system-generated IDs, and developer shorthand all fail this test.

It should be concise. The 100-byte limit is real, and every character used on hierarchy prefixes is a character taken away from meaningful identifiers. It should be clean, which means a single page that loads under multiple URLs produces exactly one page name. Pages that fragment across multiple rows in reports because of URL variations are a data quality problem that no amount of analysis can fix after the fact.

Finally, it should be consistent. If checkout pages follow the convention Checkout:Step 1, then every other team deploying new sections must follow the same structural logic. Inconsistency makes filtering and searching across reports nearly impossible, and it compounds over time as new sections are added by different developers working from different assumptions.

The Unique Value Problem

Adobe Analytics has a threshold of 500,000 unique page names per month. Beyond that threshold, new page names with low traffic are absorbed into a catch-all line item labelled Low-Traffic. At one million unique page names, a page must receive more than 100 views per day to remain visible as an individual line item.

On large sites, this is not a theoretical concern. If every product detail page receives its own unique page name and the catalogue contains two million products, the vast majority of those pages will disappear into Low-Traffic. This is why the naming decision for product pages is one of the most consequential choices in any ecommerce implementation.

The two approaches are aggregate and unique. An aggregate strategy gives all product detail pages the same page name, such as Tools:Screwdrivers:Product Details, and passes individual product identity through s.products alongside a product view event. This keeps unique page name counts low and allows path analysis at the category level. A unique strategy gives each product its own page name, which enables path analysis at the individual product level but significantly increases the unique count and risks pushing products into Low-Traffic on large catalogues. The right choice depends on whether individual product pathing is a genuine business requirement and whether the catalogue size makes that requirement practical to support.

Choosing the Right Level of Detail

Page names typically work alongside other variables rather than carrying all context alone. s.channel handles the top-level site section. s.pageName carries the content type or page-level identifier. Custom properties handle highly granular attributes that would be too detailed to embed in the page name itself.

The colon is the standard delimiter for hierarchy. Toys:Tricycles:Super Dooper Tricycle encodes three levels in a single value. This structure makes filtering intuitive. Searching for Women: in the Pages report returns every page in the Women’s section. Searching for Women:Activewear: drills to that subsection. The delimiter is what makes page names navigable at scale.

When deciding what belongs in s.pageName, the useful questions are: what website or site section was the user on, what template served the content, what process was the user in, what content did they see, and what conditions existed on the page such as errors or test variants. If a piece of information is necessary but would inflate unique counts significantly, it belongs in a separate variable rather than the page name.

Where the Value Comes From in a Data Layer Architecture

The correct end-to-end flow for page naming starts with the naming convention documented in the Solution Design Reference. Content developers set the value in the data layer when building the page:

var digitalData = {
    "page": {
        "pageInfo": {
            "pageName": "Toys:Tricycles:Super Dooper Tricycle"
        }
    }
};

In Adobe Launch, a Data Element reads this value using the JavaScript Variable type, pointing to digitalData.page.pageInfo.pageName. A Rule then uses that Data Element to populate s.pageName. This separation is what gives the implementation stability. Developers own the value in the data layer. The analytics layer reads it. Neither team needs to modify the other’s work when content changes.

The Mistakes That Are Hardest to Undo

Several implementation mistakes appear regularly, and most of them share the same characteristic: they are easy to introduce and expensive to clean up.

Using the HTML <title> tag as the page name is the most common. Document titles are optimised for search engines, not analytics. They change for SEO reasons, frequently contain promotional copy, and often differ across page variants in ways that have nothing to do with the page structure. They produce unstable, high-cardinality page name sets.

Including query string parameters in page names is equally damaging. A page viewed with fifty different query strings, containing filter states, sort orders, or pagination parameters, produces fifty different page names in reports, all for the same content. Query strings must be stripped before setting s.pageName.

Not setting s.pageName at all is the most direct route to fragmented reports. When the variable is absent, Analytics falls back to the URL, with all the consequences described earlier.

Including visitor-specific data is the most operationally dangerous mistake. User IDs, personalisation tokens, or A/B test variant identifiers embedded in page names immediately generate thousands of unique values, push legitimate pages into Low-Traffic, and in some cases expose personally identifiable information inside Analytics reports where it should never appear.

What Good Page Naming Enables

When the naming convention is right, page names become the lens through which everyone in the organisation reads site behaviour. Analysts can filter and search without decoding URLs. Business users can interpret pathing reports without a developer in the room. Development teams can restructure the site architecture without breaking a single trend line. New team members can orient themselves in reports by reading the page names rather than having to learn internal URL patterns.

The naming convention does not require a sophisticated technical solution. It requires a documented standard, consistent application across every team that builds pages, and the discipline to get it right before data starts accumulating.

Once the data is in production, changing course is always more painful than getting it right the first time.

See you soon.