In a previous post, I walked through some of the high-level expectations you should set when making the move to Customer Journey Analytics (CJA) from any digital analytics tool. If your organization is currently using Adobe Analytics, there are some additional options to consider when making the move. For example, it can be tempting to look for ways to speed up the migration or make it less resource-intensive. Purchasing CJA is an investment in your organization’s future, addressing the impending privacy and consent crunch with a big bet on better leveraging first-party data to find insights that give you a competitive edge. Unfortunately, a careless or rushed implementation can do lasting damage to your investment that can be difficult and expensive to recover from. We’re going to discuss some of these enticing shortcuts, why you should avoid them and the most efficient and effective formula for executing a successful move to CJA.
Don’t Start With the Adobe Analytics Source Connector
What if you could enjoy the benefits of all the bells and whistles that Customer Journey Analytics offers without any development work? This is the promise of the Adobe Analytics Source Connector: flip a switch, and all your existing Adobe Analytics data can flow into the Adobe Experience Platform (AEP), ready to be picked up by CJA. Unfortunately, if you bring that data in with the default Adobe Analytics schema, it can get messy fast.
Success and failure in AEP (what CJA uses to get its data) is dependent on schema, schema, schema—or how the data is structured in a format called XDM. The Adobe Analytics data structure wasn’t designed with this in mind and when it’s forced into an XDM schema, with its props and eVars from over 20 years ago, it comes out looking ugly. All of your used and unused events, props and eVars are turned into fields that are scattered across the schema.
The lengthy list of all eVars, props, and events available in an Adobe Analytics schema
The difference in how the data is structured becomes more problematic when it comes time to sort through the schema and recreate all of the dimensions and metrics you had in Adobe Analytics, including standard ones that you previously got out-of-the-box, like Page Views and Browser Type. Yes, you even have to recreate default metrics and dimensions in CJA manually. Depending on your implementation, there are potentially hundreds of components that need to be set up with appropriate persistence, expiration, binding, deduplication, etc.
Ultimately, you’ll spend more time setting up a Data View in CJA to make it look like Adobe Analytics than you ever did setting up your original report suite in Adobe Analytics. From a maintenance perspective, you now have two places to keep your variables up to date: one in Adobe Analytics and another mirrored in CJA.
To that point, nobody’s goal is to pay for and maintain both Adobe Analytics and CJA for an extended period. Eventually, you’ll want to sunset Adobe Analytics and fully adopt CJA. Unfortunately, a CJA environment that’s set up with the default Adobe Analytics data connector schema is difficult to break away from. Since all of your dimensions and metrics are mapped to the legacy Adobe Analytics schema, very little aligns when you implement a modern Web SDK schema, including every CJA workspace that’s been created. This leaves you essentially two options: One, force your shiny new Web SDK implementation into using the 20-year-old Adobe Analytics schema, undoing one of the reasons why you moved to CJA in the first place. Or two, effectively starting over, recreating every dimension and metric mapped to the Web SDK schema and forfeiting the historical data accumulated with the Adobe Analytics schema.
From firsthand experience, starting a CJA implementation based on the default Adobe Analytics source connector results in significant lost time, provides limited value and gives a skewed CJA experience. While we will later discuss a safe way to use data from the Adobe Analytics source connector, CJA isn’t Adobe Analytics. It doesn’t process data the same way and it wasn’t built for how Adobe Analytics structures data. You’ll get the most value from your investment if you start with a modern schema designed for CJA.
Don’t Touch Your AppMeasurement Implementation
One of the most common reasons companies cite for not moving to Customer Journey Analytics is that they don’t have the engineering resources to implement new data collection on their website or mobile app. To address this, Adobe provided an option to effectively repurpose your Adobe Analytics implementation into one for CJA.
While reusing what you have may seem appealing, there are a number of reasons why I don’t recommend it for most implementations:
- It still requires substantial development time. The current options for turning your AppMeasurement implementation into one compatible with WebSDK require changes to the mapping of all variables set in the “s” object, as well as updated sendEvent calls. This means you still have to touch every data element and rule in your AEP Tags (or other tag manager) implementation.
- The data remains in the Adobe Analytics data object structure. This leaves you in a new predicament where you now have to transform the data with Data Prep to get it into a Web SDK-esque schema, constrained to the formatting decisions you made for a world of props and eVars. This adds an additional layer of complexity, development and tech debt, limiting the actual progress in modernizing your data for more effective use in Adobe Experience Platform.
- Because of the complexity and differences in the libraries when repurposing AppMeasurement into WebSDK, there will likely be lost capabilities (e.g., certain plugins, Activity Map), changes in server calls or decreased fidelity in what’s collected for Adobe Analytics.
Regardless of how you migrate, key metrics in CJA won’t exactly align with Adobe Analytics. This is caused by multiple factors including how the data is processed, using People and Sessions in place of Visitors and Visits. There will likely be skepticism among some groups of users. The worst thing you could do when trying to build trust is make changes to your Adobe Analytics implementation and affect your baseline. When you need to assure vocal users that the new Conversion Rate metric based on CJA Sessions is directionally the same as Adobe Analytics, you can’t worry about additional shifts that happened as a result of switching from AppMeasurement to Web SDK.
The last reason I recommend leaving AppMeasurement alone is that while I’m confident that CJA can exceed Adobe Analytics’s capabilities and provide superior value for an organization, there’s always a risk that something goes wrong or can’t be completed as quickly as hoped. Leaving AppMeasurement untouched allows you an escape hatch to return to Adobe Analytics without any harm. If you start repurposing the AppMeasurement implementation into one for CJA, there’s no easy way to go back without impacting Adobe Analytics.
We’ve highlighted some of the options to avoid when migrating from Adobe Analytics to CJA. On the flip side, how can your organization get a jump start on its CJA migration?
Do Run AppMeasurement and WebSDK in Parallel
Standing WebSDK side-by-side with AppMeasurement will allow you to design a forward-looking schema that can grow with your business. It will require both libraries to be in place for a period of time, but that is temporary while the WebSDK implementation is built out. When you reach a critical mass of WebSDK data equivalent to the AppMeasurement data, you can begin a process of comparison and validation to vet the data in CJA against Adobe Analytics. Once your organization is confident in CJA’s capabilities, you can begin removing the AppMeasurement library and winding down usage of Adobe Analytics.
Do Deploy and Utilize a Data Layer
The best thing you can do to speed up a CJA implementation is to have a solid data layer in place. The Adobe Client Data Layer (ACDL) will be easiest within Adobe’s ecosystem, but any data layer, even a Google Data Layer, is better than no data layer. It should be your first priority and something you can actually work on before signing with CJA. In fact, XDM schema so closely resembles a well-planned data layer, it simplifies your tag manager implementation into a simple mapping exercise. Ideally, your AppMeasurement implementation can reference the same data layer during the transition and when your Web SDK implementation is ready, Adobe Analytics can gracefully fall away.
Do Transform Historical Data into Your New Schema
Many organizations will need year-over-year metrics before being able to adopt Customer Journey Analytics fully and won’t have the luxury of time to allow the new implementation to accumulate that history. This is where the aforementioned source connector can come in handy, with one caveat: reusing the building blocks or “field groups” from your new Web SDK schema is critical. Converting the Adobe Analytics schema with a transformation method (e.g. Data Prep, Data Distiller or a data warehouse with the Adobe Analytics data feeds) is essential to ensure that your metrics and dimensions are continuous in CJA across the historical Adobe Analytics and ongoing Web SDK data.
Do Treat Your Implementation as a Data Product
Adopting agile methodologies, taking an iterative approach and treating your clickstream data as a product will all significantly speed up your CJA migration from Adobe Analytics. Start small with basic page view tracking using Web SDK in parallel with AppMeasurement. Establish the stream of data end-to-end, setting up the dimensions and metrics all the way to CJA workspaces. This is your minimum viable product or MVP.
Consider all use cases involving clickstream data, including how the Adobe Analytics data feeds may be consumed within data warehouses. Translate those use cases into user stories and collaborate to find the best ways to enable them. One of the selling points of CJA is that it can address expanded use cases, so explore bringing those use cases into CJA in addition to using raw dataset exports out of AEP.
The existing Adobe Analytics users are your internal customers. Interview them regularly, demo the CJA capabilities and get their constant feedback. Adopting the product mindset during your CJA implementation can increase speed to value, as well as setting your organization up to continue those behaviors as the product transitions past the initial implementation phase.
Do Take a Minimalist Approach
Unlike Adobe Analytics, CJA does all of its processing when you access a workspace or report. From a data and schema perspective, it means you can do more with less—you don’t need to set the same data in three different eVars to have different persistence settings. Start with data you need, adding it from the data layer to your schema iteratively. Experiment with functions like substrings, include/exclude and derived fields to take a single field like a URL or page name and turn it into a handful of metrics and dimensions that are fully retroactive. This will keep your implementation lean and focused on value.
Substring functions enable you to collect data in one field then turn them into multiple, fully retroactive dimensions
Do Ask for Help
Finally, get in contact with someone who has done it before. Leverage the communities on Adobe Experience League and Measure Slack. It can make all the difference to have someone helping you who has made missteps in Adobe Experience Platform and Customer Journey Analytics and lived through it. It’s still early in AEP’s software lifecycle and there aren’t a lot of experts who have shifted to it and proven themselves yet.
We at Adswerve believe we’ve assembled the best team of experts to play the role you need, whether designing and executing or supporting your team with advice. Feel free to contact us, and we’d be happy to have a conversation and discuss your migration to Adobe CJA.