POINT OF view
Migrating Analytics Platforms: A Comprehensive Guide By Gagandeep Singh Bhatia, Senior Associate, Marketing Strategy and Analysis
Every business, regardless of size, requires multiple tools to understand website performance and customer satisfaction—and to gain key context from competitors. Web analytics tools can help you accomplish that by collecting, measuring, and analyzing Internet data and site visitor records to understand and optimize web usage. They are also wonderful tools for market and business research. If you’re considering migrating one analytics platform to another, this document will help you understand many of the challenges and discuss best practices to ensure a flawless migration. What Does Migrating Analytics Mean? Migration from one analytics platform to another is a business-initiated process. A flawless migration is critical to ensure that there is no blackout period within your data, whenever business opts for the same. Keep in mind that each platform has a different way of capturing data, and as a result, data may vary vastly from tool to tool. However, during the migration, historical data should be conserved in order to check any data variance between the two platforms. Although the figures may be different, there should be some correlation. Having expertise in a variety of web analytics tools such as Google Analytics, Adobe SiteCatalyst, Webtrends, or Coremetrics will help in understanding the impact of migrating between tools before the migration process begins. The main objective should be that the migrations go smoothly, and there is no loss of data or lack of confidence in new data once the migration is complete.
Š Sapient Corporation, 2013
POINT OF view
Reasons for Migration The decision to migrate to another analytics platform can be influenced by a number of factors: Scalability. Depending on the growth of traffic to the site, it may be decided to go for a better analytics tool. Cost. Depending on budget, it may be decided to upgrade to a paid version of the tool or move to a free or lower cost platform. Redundancy. Migrating to another tool may become necessary if an existing tool becomes redundant in the market. Enhanced features. Vendors may recommend that clients move to an enhanced version of the tool to reap further benefits or advanced features. Business requirement. The business may mandate migration to another tool to fulfill an analytics need that cannot be accomplished through the current solution (e.g., multivariate testing). Roadblocks to Migration The following factors might counter-influence analytics migration: Fear of change. Unfamiliarity with the new tool altogether or new features of the tool in an advanced version may create a fear of change among the stakeholders, and they might resist this change. Cost and licensing. A new analytics platform may involve arranging budgets and costs for new licenses. In the case of migrating to another tool, it can be beneficial if there is an overlap period between the two tools before reaching a stable state. This may lead to an increased cost since the business will be required to pay both analytics vendors for a certain period. Data variance. Depending on the differences in functionality of the new platform, there may be a variance of data between both platforms. To resolve this, the business should agree on an acceptable percentage of data variance. Each analytics tool is unique in the sense that it has its own KPIs, metrics, and approach to track click-stream data. Implementation time. Migrating to another tool is not straight-forward. It may take months for a complicated website that is divided into several microsites supported by multiple vendors having their own IT release cycle. In the case of migrating to an advanced version of the same tool, the implementation time will be less in comparison to moving to a new tool altogether. Approach for Migration The approach to be followed for migration can be broadly summarized in the process chart below:
Š Sapient Corporation, 2013
POINT OF view
1. Planning. Planning for migration is initiated well in advance of management’s final decision. This includes an evaluation of other competitive analytics tools available in market or features that the upgraded version of the tool will provide. This also involves getting the people with the right skill set on board to support the migration, and rolling out a testing plan. 2. Benchmarking. Once a plan is finalized, the team starts working on benchmarking reports for pre- and post-comparison and sign-off perspective. The business should choose a lull period for benchmarking so that any factors contributing to high or low traffic on site can be ruled out. Also, it would be beneficial to close on a certain set of business-critical KPIs rather than trying to cover everything.
Š Sapient Corporation, 2013
POINT OF view
3. Testing and training. Tagging should be validated in a pre-production environment before rolling it out. Kicking off training sessions at the same time would be a good idea since stakeholders will get more time to interact with the new platform. Also, training should be supplemented with a rich documentation about the new analytics platform, which can be used in case of any queries post training. 4. Post go-live support. It is imperative to run an exhaustive list of test scripts to ensure that everything is working as expected from a reporting perspective as soon as the new tool or version goes live. Vendor support must be available during the go-live period so that they can quickly investigate and fix any issues encountered during migration. 5. Data reconciliation. With reporting, issues are often not quickly identifiable, and it may take months to identify major data variation. Migration completes after reaching a stable state where the business is happy with the data and analysis using the new analytics platform. This means that data getting tracked can be either co-related directly with previous data or is within the threshold variance limit set by the business before the migration. Types of Migration The following sections outline the processes that should be adhered to while moving from one analytics platform to other. Bear in mind that analytics migration is not limited to a new analytics tool only. Depending on the business need, a migration activity may be required even if the analytics tool remains the same. In essence, we can divide analytics migration into three types: 1. Migrating to an advanced version of the same analytics tool. Often, a business is not moving to another analytics tool but to an advanced version of same tool. For example, migrating from Adobe SiteCatalyst version 14 to version 15 or from Google Analytics Standard version to Premium version. Even though migrating to an advanced version within the same analytics tool sounds simple, it has its own challenges. Having a fool-proof plan will help ensure a flawless migration. 2. Migrating to another analytics tool. When the functionality or technology of the site is not changing, and it is just the analytics tool that is being migrated, the complexity increases. Since each tool is different in terms of tracking data and its usage, higher skill sets may be required to manage the new tool. An example is migrating from Webtrends to Adobe, which requires a completely different set of skills to migrate and manage the new tool post go-live. 3. Migrating to another technology with the same analytics tool. Sometimes a business needs to ensure the sanity of reporting even though nothing is changing from a tools perspective. This may be due to a business decision to migrate to another technology to host the website (e.g., from WebLogic to Web-Centric Portal). This will require the migration of analytics-related code and tags from one application to another. So, it is crucial to ensure that the analytics code has not regressed post migration.
Š Sapient Corporation, 2013
POINT OF view Best Practices for Analytics Migration To minimize migration issues, the following best practices should be followed when possible: Set a clear baseline prior to migration. Benchmarking existing data for various business critical reports or dashboards can help in evaluating how data behaves post migration. In absence of a baseline set prior to migration, it becomes difficult to challenge data reflected in the new version of the tool. Agree on acceptable data variance. The business should agree on acceptable data variance since two different analytics platforms will never work in the same way. Post migration, one can expect changes in data trends. Also, it is natural that the number of visits for the first month will increase when migration happens from one tool to another. Review current business requirements for reporting. Asking every stakeholder who is a recipient of any dashboard or report if they will need similar reporting post migration will help clean the long list of scheduled dashboards and reports. Getting a picture of all mandatory business requirements will result in prioritizing the critical pieces of the reporting. Revisit analytics tags. Since the format of tags is different across analytics tools, it may be a good opportunity to revisit the tagging and get rid of tags that were never used while on the previous platform. Also, new tags that cater to recent business requirements must be added at this time. Creating a phased-migration plan, which prioritizes the implementation of the new platform on the most business-critical websites, will help in a quick rollout. Revisit governance process. Migration can be used as an opportunity to improve the governance processes in any analytics project. This can be further categorized into two parts if the migration does not involve another analytics tool:
Fill the gap: If governance processes are not flawless, this can be a good opportunity to fill those gaps and come up with a robust process prior to migration.
Strategize: If there is no set process around governance of the analytics tool, this can be a good opportunity to set up a new one per the updated version or tool.
If migration involves another analytics tool, the governance process should undergo a revamp to ensure it is aligned with the new tool. This may include user management as well as product or campaign classification. Conduct robust testing. Robust testing should be done in a development environment to ensure tags across all microsites are as expected. Once the data audit and tag validation have been completed, a sign-off is provided for taking the migration live. Train before go-live. Training on the new analytics platform for web analysts and business stakeholders as soon as the new development environment is available can help in understanding the new tool interface (in the case of migration to a new tool) or help in understanding the new features of the tool (in the case of migration to an advanced version of the same tool). This training must be finished before migration actually occurs. This should be followed with documentation of the new product and Q&A sessions with vendors before the migration to resolve any queries around tool usage.
Š Sapient Corporation, 2013
POINT OF view Identify the ideal time to migrate. It is advisable to go live with migration when there is no big marketing campaign running for the business or during seasons like Christmas because the website will always have high traffic during those periods. Also, planning migration to go live on the first day of the month will give a complete picture of data variance. Develop a communication plan. Communication is key, and each stakeholder must be given at least a month’s notice before the migration actually happens. This may be followed by another reminder a week before the migration. It might also be worth adding an announcement on the landing page of the analytics tool that is used by business stakeholders or adding a notification at the end of every email (as part of the signature) being sent out to business stakeholders. In the case of a change in the website application platform, although there is no change in analytics, it is good practice to give a heads-up to each analytics user so that one can correlate any trend changes with the migration. Ensure vendor support. If the analytics tool is not changing, support from the vendor of the analytics tool must be in place for a couple of weeks so that any obvious issues can be addressed and fixed quickly. They will also help in triaging whether a raised issue is actually an issue or is due to a new feature of the advanced version of the tool, which has to be accepted as a mandate. In the case of migration to a new analytics tool, it is ideal if there is an overlap period for which both these tools are run side-by-side so that any major data variance for out-of-the-box metrics can be investigated thoroughly. Having support from both vendors will help in understanding different ways in which data is being tracked and in ruling out any need of investigation if the variance is due to a difference in the approach or metrics definitions. Validate post go-live. There should be a dedicated development and analytics team to investigate any issues on the website post migration. This may range from a JavaScript error on a homepage to a major data discrepancy in the reports. In the case of migration to a new tool, a stability period must be ensured where the development team is available to make any code change required to fix any reporting issues. Conclusion A migration gone wrong can turn into a nightmare for any business. Having a flawless migration will keep the confidence and accuracy levels high and intact on the reports and analysis that form the basis for many business-critical decisions. By following certain best practices, one can ensure that the migration will happen successfully, and that the business will be happy with the new set of reporting. Planning migration early and developing a long-term vision can help tremendously and can be a good opportunity to improve on the existing analytics processes.
Š Sapient Corporation, 2013
POINT OF view
Gagandeep Singh Bhatia is a Senior Associate, Marketing Strategy and Analysis at SapientNitro with experience in web analytics implementation and maintenance. He currently leads the web analytics enablement team from onshore for Vodafone UK and is an Adobe Certified professional with SiteCatalyst Implementation as well as Processing Rules.
Š Sapient Corporation, 2013