It’s a common scenario: after many years of working with one digital analytics suite, your global organization realizes that it may be time to change measurement platforms. Perhaps the business is not seeing the return on investment they’d like on its digital analytics efforts, the suite of tools in place is no longer keeping up with the organization’s needs, or a change in leadership means it’s time to reexamine vendors.
Regardless of the rationale, the thought of migrating from one suite of digital measurement, optimization and analysis tools to another can be overwhelming for large enterprises. Perhaps you have already spent years investing in and growing a large-scale Adobe Analytics implementation, and now you have made the decision to start fresh with a new Google Analytics 360 implementation as part of your migration to the Google Marketing Platform suite of tools.
The good news is this type of migration project doesn’t have to be overwhelming, even for a global organization, with the right planning in place. In this post, we’ll break down 12 items to consider to ensure your enterprise analytics migration project is a success:
Let’s begin by assuming you’ve already researched platforms, selected the Google Marketing Platform and have received executive buy-in on the migration project. With disparate business units and multiple departmental needs to consider, where do you begin?
Long before drafting timelines or making changes to code, it’s critical to designate a primary decision maker who will have the final say on the many decisions that will be made over the course of the project. To be successful, this person needs a strong understanding of the organization’s needs, a clear vision for the project’s final outcome, the support of leadership, and the ability to lead other individuals through the process.
While he or she will have the ultimate say in how the project progresses, it’s also important that this person is open to soliciting the input of others within the organization. Before project kickoff, the decision maker should identify a handful of key business stakeholders who will provide feedback and guidance along the way.
The most successful project teams, in Cardinal Path’s experience, are comprised of individuals from multiple departments, divisions, disciplines. If your organization has a global presence, you might consider including representatives from each of your key regions, as their needs might differ from those of your headquarters. In addition, it’s likely you’ll want to include perspectives from those in business roles like marketing or product management, and those in technology roles like marketing technology, information technology, or development. As you are considering who to include, think about who will implement, enable and govern your digital analytics suite, such as your technology teams.
Once you’ve selected your decision maker and key stakeholders, clearly define each person’s role as your prepare to kick off the project.
The next step is where the fun really begins: the discovery phase. Once your migration project team is in place, it’s time to develop a deep understanding of what each group needs and wants from your new and improved digital analytics implementation.
You’ll want an objective person, or people, to undertake the important work of seeking out and compiling this critical information, as it will ultimately serve as the basis your measurement strategy. At Cardinal Path, this is where we often begin working with clients on migration projects. This process can take many forms, including stakeholder surveys, interviews, workshops, or document reviews. Most often, requirements gathering will involve some combination of these activities.
Whichever methods are chosen, the objective is to determine the ideal state of the future digital analytics implementation. Be sure to speak with stakeholders who are working on parallel initiatives in related areas, such as data science. Because digital analytics makes up a single part of an organization’s many data sources and tech platforms, consider how it will integrate with these other systems and data sets. The digital analytics implementation should be completed with a thought to the future: for example, if another internal team hopes to do advanced analysis on customer lifetime value using multiple data sets, understanding this requirement at the beginning is key to ensuring the right digital analytics implementation is put in place to aid in this effort and ensure adherence to data governance initiatives across the organization.
It’s important to remember that some stakeholders may not yet be familiar with the new analytics systems selected, which can make it difficult to verbalize exactly how they envision the ideal state of analytics at the organization. It’s often helpful to ask questions from a macro perspective rather than a micro one. For example, a stakeholder might know that they would like the new analytics implementation to provide attribution reporting but may not be able to provide precise detail on the attribution models they would like to be able to compare or how the implementation would be customized for their needs. For those stakeholders who do know a specific level of detail, they will typically volunteer that information when discussing the topic at a high level.
Another approach that we find helpful is to ask questions that examine where the current implementation had major shortcomings or pain points versus where it delivered on or stakeholder exceeded expectations. Understanding these types of likes and dislikes can uncover key information that is applicable to the migration project.
A digital analytics migration project, especially one for an enterprise organization, can impact many groups within the company. Before launching the project in earnest, developing a roadmap with anticipated timelines, dependencies and resources required is key to ensuring that participants are aware of the phases of the project and what is required of each group to make it a success.
The roadmap can be created prior to requirements gathering, or just after. If it’s drafted before the requirements gathering phase, it may be rough draft that is revisited following requirements to add additional detail. For example, before the requirements phase, you may understand that the project will have a few distinct phases such as discovery, strategy and implementation, which each have rough timelines associated with them. However, during discovery, you might realize that there are components of the project that will impact your expected timelines, such as technical integrations that you were not originally aware of, resource availability issues, or other dependencies that might cause you to rethink the first draft of the project plan. After the discovery phase is completed, it is a good time to either draft for the first time, or revisit and add additional detail, to the project roadmap, as well as plan for the internal resources needed to complete the implementation.
For extremely large implementations or those that have requirements that will require some heavy lifting by the organization’s technical resources, approaching the implementation in distinct phases can be extremely helpful. For example, perhaps high priority components can be implemented first, followed by lower priority items. Or, perhaps less technical items, such as overall account structure and basic configuration, can be implemented quickly, followed by more advanced configurations that integrate third-party data, such as CRM integration.
With your discovery phase completed and your project plan in place, it’s time to dive into the nitty gritty work of defining your new digital analytics strategy. There’s no one-size-fits-all approach to creating a successful measurement strategy, but there are some common considerations you’ll want to put thought to:
Tying your measurement strategy to business key performance indicators is critical to ensure that your analytics implementation helps answer business questions. Though it can be tempting to measure everything, or measure things simply because they are interesting data points, it’s important to keep your focus on measuring the things that can create business impact. By documenting your KPIs at the start of your strategy, you will have a frame of reference to refer back to you as you outline how you will meet the requirements that are most important to the business.
You next need to take stock of all of the items uncovered as part of requirements gathering and group them together into common themes. Perhaps you heard from multiple stakeholders that they want to maintain some self-service control over their analytics implementation for individual business units, while the organization as a whole wants to maintain strict user controls. These sort of requirements can be grouped as account administration requirements, then prioritized against others based on how relevant they are to business KPIs and critical management needs. It may be that not all requirements gathered ultimately make it into your final measurement strategy.
Now that you have a list of priorities, it’s time to start outlining the solutions you’ll implement to meet your top requirements. At this point in the process, it is important to confer with technical experts who have experience in solving for the types of business questions you’re asking in a digital analytics implementation. Start by documenting ideas, but be sure to vet their viability before sharing the final solution more broadly within the organization. For example, perhaps a requirement is to track impressions of all calls to action embedded on the company’s website. You may initially suggest adding event tracking to capture these views, but there may be additional, or better, ways to meet the requirement, such as using Enhanced Ecommerce product impressions instead.
Analytics solutions are typically part of a much larger technology stack that an organization employs. Given this, it’s important to consider how the analytics platforms and solutions selected work together both with one another and also with other elements of the tech stack. How will your digital analytics data for your website and mobile apps align or directly integrate with data from your digital marketing initiatives or your customer relationship management (CRM) software? Put thought to how your analytics solutions fit into your larger technology environment to ensure that you are making the most out of your available resources.
In addition, consider how your implementation will comply with privacy rules and regulations that apply to your business, like Europe’s General Data Protection Regulation (GDPR). It is important to ensure that your analytics implementation follows your organization’s guidelines and has been approved by internal trust or security teams that govern these areas across the full tech stack.
As you consider individual solutions on a micro level, don’t forget to keep the macro view in mind, too. Let’s say, for example, that you’ve decided to measure the cost of paid search campaigns within Google Analytics by linking it to various AdWords accounts different business units across the organization use. Perhaps each business unit has some local control over their marketing budgets, and thus, manages these accounts on their own using the local language and currency. How will you account for these differences when it comes to your global reporting? Do you need to update settings in all of the AdWords accounts and analytics accounts to align using a global standard, such as English and the US dollar, or is it okay for your reporting to roll up disparate data points from each business until? Seemingly small choices made at the local level can have a big impact on your ultimate global analytics outcome.
The analytics implementation you’re creating today is not the same implementation you’ll have a few years from now. Over time, your analytics solution will grow and change with the organization. As the business grows, it’s important to have a framework in place that can scale with it. Consider how the choices you are making for your current implementation might have to change as you acquire new businesses, add new products and solutions, or launch new campaigns. Would the structure you are putting in place today still make sense if your company broadened its reach into new markets or introduced a large number of new product lines? How easy or difficult would it be to add measurement solutions for these types of changes based on what is being implemented now? It’s worth keeping an eye toward the future as you determine solutions for today’s business needs.
At the end of the migration project, all digital analytics users who access reports from the user interface or export data into another platform will have to learn a new set of tools and a new, slightly different reporting language. To assist those users in understanding the shift as they ramp up on the new platform, it can be helpful to map out how solutions in the new platform relate to those in the old platform. It could be as simple as listing out the custom items being tracked in each platform, or more complex, such as mapping out how to complete common tasks or run similar types of reports in each platform. For example, as detailed in this post on migrating from Adobe Analytics to Google Analytics, you might consider creating documentation that outlines key features of the previous platform to the closest equivalent in the new platform, along with key differences between them. This gives end users a helpful reference guide as they get acquainted with the new solutions and the business record of what was done during the migration.
Once there’s a measurement plan drafted, it’s time to get the okay to move forward with the migration project from the broader team. Present the plan to the key stakeholders on the project and solicit feedback on the proposal. We find that generally, most stakeholders are on board with the final plan if they’ve been consulted throughout the process and changes are minimal. You may have a round or two of edits to make, as some things may have changed since the initial requirements gathering process, or some stakeholders may decide they no longer need some of their initial requirements once they have seen the full plan. Take feedback into account, draft a final version and get everyone’s approval to move forward with the migration. If disagreements happen amongst the broader team, remember that ultimately, you’ve selected one final decision-maker who will determine the path forward.
At some point in an enterprise digital analytics migration project, managing all of the moving parts might still feel overwhelming. That’s okay! You don’t have to, and shouldn’t, go it alone. Hiring an expert, either in-house or with an outside consulting firm with expertise in large-scale enterprise analytics projects, to provide guidance and support along the way can help make the process less stressful and ensure a positive outcome. If this sounds like you, contact us to see how we can help.
As consumers become increasingly digitally savvy, and more and more brand touchpoints take place online,…
Marketers are on a constant journey to optimize the efficiency of paid search advertising. In…
Unassigned traffic in Google Analytics 4 (GA4) can be frustrating for data analysts to deal…
This website uses cookies.