Analytics Best Practice Guide: Going Through a Redesign

Redesigning even a single website can have a major impact from an analytics perspective, and should be prepared for, evaluated on, and acted on from multiple aspects.

The objective of this post is to detail how your website or brand can 1) prepare, 2) evaluate, and 3) act on what is necessary for a redesign from an analytics perspective. These steps should be repeated for every site that is being redesigned (individually by property).

Making the Google Analytics (GA) Property Decision

When redesigning a website, choosing whether to keep a current GA property or migrate to a brand new property is an important (and should be one of the very first) decisions made as you prepare for relaunch.

There are two options:

1. Maintain the same GA properties post-redesign, keeping a continuous single property of GA data for each site.
2. Create new GA properties for each site, splitting out data pre and post redesign for each.

Below, you’ll find the Seer Analytics teams’ recommendations for making the GA property decision.

Option #1: Maintain Properties

This is the default preferred option, except for very specific cases. The reasons for keeping things in the same property are as follows:

Pros

1. Keeps all data in a single location, allowing for historical comparisons in a single area.
2. Eliminates work in GTM from having to completely shift over all pageview and event tracking to new properties.
3. Maintains all event and goal tracking under one area, assuming the site(s) will largely function in a similar manner pre and post-redesign (overall the same business objectives, user actions, etc.)
4. Allows for easier data visualization, using one data source (i.e. one view under one property) will be inherently simpler then trying to combine two data sources overall
5. No need to change user management or access to data.
6. All linking to additional areas (GSC, AdWords, etc.) will not need to be changed.

• Any type of custom dimension or custom metrics at the property level will be maintained.

1. All view settings can likely be carried over (site search, query parameters, bot exclusion, etc.).
2. All content groupings and filters will be carried over.
3. All segments, annotations, custom alerts, and scheduled reports will be carried over as well.

Cons

1. If any major site sections change, we won’t have direct 1:1 comparisons in data
2. Will need to do a full re-evaluation of goal set-ups for all areas upon relaunch - could start fresh in a new property
3. Can’t look at the new site performance in isolation without sectioning off the date range time period to only post-redesign

Option #2: Create New GA Properties

There are very specific instances in which it makes sense to start fresh with brand new GA properties. Here are the situations in which creating a new GA property makes sense post-redesign:

1. All (or nearly all) of the website layout, functionality, and desired user actions change - i.e. it is almost a new website in and off itself entirely
2. The experience across devices drastically changes - i.e. the way that mobile is displayed switches from a mobile site to responsive
3. The ways in which you want to approach tracking overall for the site drastically change - i.e. the difference in user experience is so great that inherently most of the old tracking will be irrelevant
4. The experience for conversion and/or purchase will be so drastically different that comparing metrics like transactions, product quantity, or revenue will not line up across pre and post redesigned areas.

How to Prepare for a Redesign with Analytics In Mind

Once you know whether you’ll be keeping your current property or migrating, it’s time for the critical redesign analytics next steps to take place.

Analytics Redesign Requirements

1. A comprehensive document detailing how URL structure is changing
   • This will allow you to have as much of a 1:1 mapping of site sections are possible to compare information pre and post-redesign
2. Detailed notes on new functionality and features that are being added to the site
   • This will allow you to prepare for new areas that need to be tracked
   • This should also be approached the other way - what functionality is changing, and how are you planning to adjust tracking overall
3. Detailed timelines for redesign execution
   • This will allow you to properly prepare, QA, and annotate Google Analytics (GA) on the implications for each step
4. Notes on objectives of the redesigns
   • This should include traffic goals (note, most sites see traffic decreases around redesigns - this should be anticipated and expected going into the redesign), how business objectives translates to KPIs (and how this will impact GA goals themselves, and areas that your company wishes to improve overall for these areas [How will each be measured? What will determine “success” for each area?])
5. Benchmark data
   • Based on your objectives, you should benchmark traffic (as well as any critical subsections of traffic channels/content types), user engagement, and conversions for reference at 1, 3, 6 and 12 month intervals after the redesign to show impact of the redesign itself.

Tracking Evaluation Checklist

The items that are contained in Google Analytics and Google Tag Manager are key to evaluate to ensure that any company is prepared for each area. Below we will break out by both GA and GTM:

Google Analytics

1. Account-level: User management
   • Will everyone that previously had access to analytics still need it? Will others need to be added?
2. Account-level: Filters
   • Ideally all filters should always be set-up at the GA account level to allow for the most flexibility. What filters are in current use, and will those continue? What filters will need to be added (new hostnames if site changes, new IP exclusions with redesign companies, etc.)

1. Property-level: Property Settings
   • What is the hit-level for each? Will this be likely to increase or decrease post-redesign? 10 million/month is the pre-sampling limit for non GA360 customers.
2. Property-level: Tracking Info
   • Are all data collection/data retention/settings/lists set-up in a way that will be flexible for the new redesign? Will potential security changes impact the desired settings for data retention?
3. Property-level: Product Linking
   • Will the linking for AdWords and/or Search Console need to be adjusted at all for each area?
4. Property-level: Custom Dimensions/Custom Metrics
   • Will the way that these newly redesigned sites function impact the type of data that you want to capture? Map out any additional dimensions you’d wish to capture and map out how GTM can produce this information to populate in GA.
5. View-level: Exclude URL Query Parameters
   • Will there be any new query parameters be generated by the newly redesigned site? Which should you include and which should you exclude? Will this impact internal site search tracking?
6. View-level: Goals
   • What type of goals are currently set-up? Which are on (recording data) and which are off (why are they off?). Document all goal types, goal set-ups, goal values and goal funnels. How will these differ once the site is redesigned? Do all goals have relevant goal values set-up? Set aside time to QA all goals once the site is relaunched.

1. View-level: Content Grouping
   • How are content groupings being currently leveraged? Will new content group opportunities arise with the redesign? How should these be properly tracked? Are they being leveraged directly in GA or through GTM?
2. View-level: Channel Grouping
   • How are channel groupings being currently leveraged? Are any new marketing channels planning to be introduced with the redesign or to help aid the expected overall traffic drop? How can these areas be modified to account for this?
3. View-level: Ecommerce Settings
   • Does your site use eCommerce? If so, Is ecommerce enabled for each view? Is enhanced ecommerce? Are you prepared from a technical perspective to implement that level of tracking?
4. View-level: Custom Alerts
   • Ideally, any company should set-up additional custom alerts to help monitor traffic post-redesign to ensure that traffic areas, event areas and goal areas don’t drop off drastically.
5. In-data: Events
   • In turn with how these events are being sent via Google Tag Manager (GTM), the way that events are structured from the perspective of event category/event action/event label should be documented. In turn with GTM, this should be noted to show what is currently tracked, evaluate if that method of tracking will carry over for the redesign, and find gaps in tracking that will need to filled in overall.

Google Tag Manager

1. Account-level: User management
   • Will everyone that previously had access to analytics still need it? Will others need to be added?
2. Account-level: Container usage
   • How many GTM containers are created? Are they all currently in use? Are new containers needed to be created to account for the new sites? Will any new publications be needed when the redesign occurs? Plan this out from a timeline perspective.
3. Container-level: Version and workspace states
   • What version is the current GTM container set on? What was last published and why? Are there any pending changes that need to be removed and/or published?

• Container-level: Tag evaluation

1. What tags are currently set-up and what systems do they serve? What areas outside of Google Analytics have tags set-up? Are they all still in use? Will any new tags need to be added upon the site redesign?
2. Do all tags have firing triggers set? Will all in-use firing triggers still be relevant post-redesign?
3. Do any tags have blocking triggers/exceptions set? Will all of these still need to be set-up in the future? Will any new blocking triggers/exceptions need to be set-up?
4. Are there any tags that serve the same purposes as others? Can any tags be eliminated?

• Container-level: Trigger evaluation

1. Which triggers are set-up and why? How does this drive event data collection in GA? This should be detailed 1:1 for each container/site for the redesign.
2. Are any triggers reliant on Page View or Click interactions? Will changes to page URL structure and/or on-site page set-up impact the usage of any of these triggers?
3. Are any triggers reliant on on-page markup? Will any of these areas change with the redesign?
4. Are there any triggers that serve the same purposes as others? Can any areas be eliminated?

• Container-level: Variable evaluation
  • Are all built-in variables enabled? If not, enable all built-in variables (this creates more long-term analytics flexibility).

1. What user-defined variables are set-up? What is the use for each? Can any be eliminated?
2. Are there any data layer variables set-up? Will the set-up of the future data layer mirror the current data layer (if it is used)?
3. If any variables rely on Page Elements, will these elements be the same on the new site?
4. Is the Google Analytics Settings variable in use for the container? If not, this should ideally be set-up and leveraged to make referencing this information for all GA tags much simpler.
5. Are any Lookup or RegEx tables in use? If so, will any elements within these tables change upon the redesign?

• Container-level: Folder usage
  • Is organization by folder currently used at all? If not, this should be implemented with redesign updates to completely organize your tags, triggers, and variables.

On-Site Code

• GTM Placement
  • Is GTM code placed both in the <head> and <body> as described in the GTM Install Google Tag Manager area? Is this uniform across the site? Are there any reasons this would change when redesigning the site completely?
• Data Layer Placement
  • If that data layer is used - will all snippets carry over for the redesign? Will any alterations be needed?
• Optimize Placement
  • If Google Optimize is used - ensure that this on-page set-up matches up with Google’s specifications.

Key Takeaways

If these steps are performed across each site during the redesign process, you will have an analytics setup that is prepared to properly capture the data that is necessary (on-page and GTM) and in turn analyze it in a way that will make it actionable (GA) to judge performance upon relaunch.

This will also create an overall analytics foundation that will allow you to build off of to create new events, leverage new features, and allow you to not have to play catch-up in fixing other items. This process will prepare you to be actionable with your data long-term, and head into the post-redesign data set-up prepared from an analytics perspective.

If you need assistance for your redesign for analytics, please reach out to us at Seer. We are here to help if needed! Also check out some prior tips we’ve had for redesigns as well!