Best Practice for Adobe Analytics Page Name Strategy (Multilingual Site) | Community
Skip to main content
P
priyankagupta20
Level 4
June 18, 2025
Solved

Best Practice for Adobe Analytics Page Name Strategy (Multilingual Site)

  • June 18, 2025
  • 4 replies
  • 721 views

Hi everyone,

We’re currently in the process of defining the page naming strategy for our Adobe Analytics implementation, particularly for a multilingual website, and would love to hear your thoughts and best practices from the community.

There are a few possible approaches we're considering:

Option 1: Consistent English Page Names Across All Languages

Examples:

  • https://prod.com/en-EN  - My Prod | Home Page

  • https://prod.com/fr-FR  - My Prod | Home Page

  • https://prod.com/de-DE  - My Prod | Home Page

Pros:

  • Simplifies global reporting with a consistent naming convention (e.g., total views of “Home Page”)

Cons:

  • Limits visibility into language-specific performance unless filtered with an additional variable (e.g., language or site section)

Option 2: Localized Page Names Based on Language

Examples:

  • https://prod.com/en-EN  - My Prod | Home Page

  • https://prod.com/fr-FR  - Ma page d'accueil Prod

  • https://prod.com/de-DE  - Meine Prod | Startseite

Pros:

  • More intuitive for local teams and stakeholders

Cons:

  • Increases complexity in global reporting and dashboards

Option 3: Use Clean URL as Page Name (Temporary Setup)

Examples:

  • https://www.example.com/home  - Valid page name

  • https://www.example.com/home?utm_source=google 

  • https://www.example.com/home?ref=campaign123 

Why Clean URLs?

  • Avoids duplication due to query parameters like utm_source, sessionID, etc.

  • Maintains cleaner dashboards and avoids fragmenting page view metrics

Option 4: Hybrid Strategy (Recommended)

Use a combination of:

  • Primary pageName: English title for global consistency

  • Secondary dimension (e.g., localizedPageName or language): for regional analysis

Benefits:

  • Enables unified reporting across all markets

  • Supports deep dives into region-specific content performance when needed

Option 5: Breadcrumb-style Page Name

Example:

  • https://www.prod.de/therapiegebiete  - www.prod.de  > therapiegebiete

Pros:

  • Reflects the site hierarchy and may help with structured reporting

Cons:

  • Could result in very long values

  • May not be intuitive for global rollups

Our Question:

Which of these approaches do you recommend as best practice, and why?
We’re aiming for a balance between global reporting consistency and regional relevance.

Thanks in advance for your insights and experience!

 

Let me know if you'd like a shorter or more technical version as well!

Best answer by Jennifer_Dungan

It really comes down to what works for you and your business... for the few sites we had with multiple languages, we always deferred to an English version of the name, since most of the employees are English, alternate languages were good for users, but less so when it came to trying to analyze the traffic.

 

That said, I always made sure to capture additional dimension data about the language or language specific items so that we could still see the distribution across the variants.

 

Personally, if you care about "page views" on Product X, to me (personally), I don't think it makes sense to have multiple page names.... this makes it harder to consolidate the data.... and while yes, you could pull a product by an ID, what about home, section, search, etc pages which don't have a specific identifier? Trying to consolidate traffic is always harder than breaking it down.

 

And yes, I collect URL information as well as specific page names, but I do so with a custom eVar with a Hit expiry, so that I can leverage the 255 character limit (rather than be limited to the Page's 100 character limit)... but this depends on how complex and long your URLs might become.

 

You could always make "Page" in English (or your primary team's language) and set up a custom Dimension for "Language Specific Name"... nothing says you can't do both. I always have a "duplicate" Page Name dimension (another Hit Level eVar) that I collect on every page view and action so that I can see exactly what page any of my action tracking belongs to.... (since Page is only available on Page Views, and not on Actions like Clicks or Conversions, etc)

 

 

As for site hierarchy, I would make use the the hierarchy dimensions... and these don't even have to follow your URL structure either... sites often have exceptions, so I make hierarchies that deal with this to properly break the site down in a meaningful way. You can have up to 5 hierarchies.

4 replies

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
June 18, 2025

It really comes down to what works for you and your business... for the few sites we had with multiple languages, we always deferred to an English version of the name, since most of the employees are English, alternate languages were good for users, but less so when it came to trying to analyze the traffic.

 

That said, I always made sure to capture additional dimension data about the language or language specific items so that we could still see the distribution across the variants.

 

Personally, if you care about "page views" on Product X, to me (personally), I don't think it makes sense to have multiple page names.... this makes it harder to consolidate the data.... and while yes, you could pull a product by an ID, what about home, section, search, etc pages which don't have a specific identifier? Trying to consolidate traffic is always harder than breaking it down.

 

And yes, I collect URL information as well as specific page names, but I do so with a custom eVar with a Hit expiry, so that I can leverage the 255 character limit (rather than be limited to the Page's 100 character limit)... but this depends on how complex and long your URLs might become.

 

You could always make "Page" in English (or your primary team's language) and set up a custom Dimension for "Language Specific Name"... nothing says you can't do both. I always have a "duplicate" Page Name dimension (another Hit Level eVar) that I collect on every page view and action so that I can see exactly what page any of my action tracking belongs to.... (since Page is only available on Page Views, and not on Actions like Clicks or Conversions, etc)

 

 

As for site hierarchy, I would make use the the hierarchy dimensions... and these don't even have to follow your URL structure either... sites often have exceptions, so I make hierarchies that deal with this to properly break the site down in a meaningful way. You can have up to 5 hierarchies.

    Vinay_Chauhan
    Community Advisor
    Vinay_ChauhanCommunity Advisor
    Community Advisor
    June 19, 2025

    Hi @priyankagupta20 

    As per my suggestion, for multilingual websites, a hybrid approach generally offers the best balance between global consistency and local relevance.

    Here’s a recommended setup:

    • 'Primary pageName' (e.g., in English or your global reporting language): Use this for consistency across reports, dashboards, and cross-market rollups.

    • 'Secondary dimension' (e.g., localizedPageName or language code): Capture the language-specific or translated version separately for local analysis.

    This approach keeps global metrics unified, for example, “Home Page” views across all languages, while still allowing regional teams to slice by language or region as needed.

    To avoid data fragmentation caused by query string parameters (e.g., utm=, ref=, cid=), it’s also a good idea to:

    • Store a clean URL in a separate eVar using hit-level expiry.

    • Normalize or strip query strings at the time of capture via Launch or server-side logic.

    If needed, breadcrumb-style page names can be captured as an additional custom dimension or in a hierarchy, but it's best to keep your primary pageName concise for easier use in dashboards and segmentation.

    Using hierarchy variables can also help structure reporting without relying strictly on URL paths, helpful if your site has exceptions or custom flows.

    In short:

    • Keep the main pageName consistent.

    • Add language/context through separate dimensions.

    • Use hierarchies and clean URLs for structure and detail.

    This setup supports both high-level global visibility and detailed local insights without compromising the integrity of your data.
    Hope that helps!

      Sukrity_Wadhwa
      Community Manager
      Sukrity_WadhwaCommunity Manager
      Community Manager
      June 27, 2025

      Hi @priyankagupta20,

      Were you able to come to a decision with the help of the provided suggestions, or do you still need further assistance? Please let us know. If any of the replies were helpful in moving you closer to your decision, even partially, we encourage you to mark the one that helped the most as the 'Correct Reply.'

      Thank you!

      Sukrity Wadhwa
      jeff_bloomer
      Community Advisor and Adobe Champion
      jeff_bloomerCommunity Advisor and Adobe Champion
      Community Advisor and Adobe Champion
      July 1, 2025

      Hi @priyankagupta20,
      This is definitely a challenge we had when I worked at Kroger, particularly because we had so many different brands (or banners) of different stores, and because of that, we needed to find a consistent way of referring to all of the page names consistently, regardless of whether you were on the home page, or sub-page of kroger.com, dillons.com or bakersplus.com.
      The idea was to use a hierarchy, based on the URL you saw, which always substituted a word in place of the initial domain, and then broke out the different sections, so you could easily get a full breakdown.  For example, if I went to the Gift Cards page (https://www.kroger.com/o/gift-cards), you would get something like this:
      page: "bnnr:topic:gc"
      Then, you would capture the actual name of your domain in a different dimension so you could easily filter your results to break out your visitors.  This would work very well for languages, and then you can capture your clean URLs in a different dimension as well, which I recommend using both eVar and prop for different types of reporting.
      I believe my answer is along the same track as @jennifer_dungan's, as I've just been skimming, but choose what you feel is best from everything and go from here.  Best of luck to you!



        Terms & ConditionsAccessibility statement

        Loading footer...