Remember the IBM announcement back in April to sunset NetInsight? The truth is on-premises web analytics is a dying art. The only other well-known vendor that provides on-premises solutions is WebTrends. It is destined to suffer a slow death – there have not been any new releases for the last few years and customers are encouraged to move to the SAAS version. So, the next best thing is to prepare and plan for inevitable – migration to SAAS.
- Assess Web Analytics vendors. Sunsetting the on-premises solution presents a good opportunity to reassess the web analytics landscape instead of blindly sticking with the same vendor and moving your data from on-premises to SAAS.
- Documentation. Documentation. Documentation. I said it three times and I meant it. No one likes to create it. I get it – it’s a boring, monotonous task to write every variable, every processing rule, every customization. However, switching your web analytics tool without documentation is like going into battle and forgetting your ammunition. You need to ensure you have documented the following:
- A List of Key Custom Built Reports and Layouts. This is your foundation for stakeholder expectation management and therefore the golden key to your sanity during migration. This task can become a project on its own since going through such an exercise will confirm what reports and metrics are critical and important for the business and which ones you can delete because no one is using them anyway.
- Current Tool Configuration rules. This is a big one and can cost you dearly. I had many urgent calls from clients desperately trying to understand why their data tanked 20 – 30% when they switched to a new tool or data collection method. In 99.9% of all cases the answer was due to configuration such as page view definition, filtering, visitor tracking methods, etc. The configuration topic certainly warrants a separate post, so check back in a while.
- Site/Metric Matrix. List all custom collected metrics per site, including metric definition, collection method and syntax. This exercise should be completed hand-in-hand with report documentation to ensure every single custom metric is documented. This is your bible. Keep it on your nightstand and refer to it often. If you need a sample template, come back in a few weeks – I will be posting further on this subject.
- A Project Manager and a Project Plan. Web Analytics migration is like surgery – you need to make sure that your patient (aka reporting) will not die during the surgery (migration). You may get away without a plan if you a dealing with a simple site and basic data collection (wart removal), but if you a dealing with multiple sites, channels, applications and vendors (open heart surgery), a solid plan is required for successful execution.
- Assessment against Current Reporting Capabilities. Migration from on-premises to a SAAS solution (or one vendor to another) almost always results in loss and/or gain of features. E.g., SAAS solution is likely to have greater social and mobile tracking capabilities but you may need to make some data collection tradeoffs in order to adhere to your company’s data collection policies, especially if you are in the healthcare or financial industry. Create a loss/gain matrix and use it to manage change. No one likes to give up things that they already have. Over communicate any changes to stakeholders in advance, quantify impact of such changes on business and help to define mitigation plan, if necessary.
- Assess Current Roles, Responsibilities and Processes. Switching from on-premises to SAAS will impact current roles and processes, e.g., there will be no need to maintain servers. Process-wise, you will not be able to re-analyze collected data, which will have an impact on new report deployment as well as the ability to apply new reporting requests to historical data. Don’t wait for a bear to get you – review current roles and processes, outline necessary adjustments and manage change before the migration occurs.
Feel free to comment or add to my list!