It’s been about 6 months since I posted, and my own pledges to publish at least 1 topic every month are frequently broken. I am unable to blog frequently owing to time limitations, and my experiment phase towards Adobe Experience Platform makes it even more difficult. However, I am happy with the amount of effort I am investing into these contexts so that in the future, whenever feasible, I could bundle the experience and write multiple topics in a short period of time.
My blogging time is primarily influenced by three factors: my professional experience, expert authentication, and my personal viewpoint. Except for a few, almost all my blogs follow the pattern, and this one might be one among them. This is because I prefer to ignore my experience and the authentication ingredient to provide everyone with a comprehensive understanding of the solution’s foundations. While it might appear that the topic is not absolute if you have a solid understanding on Adobe Experience Platform, I still want to write it to dispel everyone’s vacillations and put an end to the impulse to compare Adobe Experience Platform with Adobe Analytics. Before continuing, I strongly recommend everyone to read my first blog on Adobe Experience Platform, which might provide a more thorough picture of the topic. With that, let’s get the conversation started.
A debate on Adobe Analytics
Adobe Analytics, in my opinion, is a solution (not a tool) that collects data (primarily digital), stores it, automatically processes it, and provides an interface to view the data for reporting and analysis.
Our primary focus as digital marketers or architects is largely on data collection and not on the rest of the workflows. Since Adobe Analytics already has a defined methodology for data collection, we simply need to follow it based on the predefined taxonomy. The result of the taxonomy (or schema) is what we see in Adobe Analytics; it comprises predefined & custom traffic dimensions (props), predefined & custom conversion dimensions (eVars), and predefined & custom events. It is impossible for us to modify this taxonomy at any point to reflect industry standards such as adding new predefined variables, updating custom variable types other than the options offered, changing the marketing channel approach, and so on.
On the other hand, once the data is collected, we cannot meddle with its processing procedures; we may extract the data before or after processing using defined approaches such as workspace extract, data warehouse requests, data feeds, and so on, but we can never interfere with the processing methods and customize them to meet our needs. Only after the data export, we can transfer, merge, or tamper with the data based on our business requirements; we usually call it ETL (Extract, Transform and Load).
Finally, we have Workspace and other UI options that enable us to visually represent the data processed by Adobe for reporting and analysis. Again, these components and visualizations are pre-built and cannot be tailored to fit individual business requirements. Even if we leverage API to build our own visualization outputs, I might interpret them as data export and then do an ETL on top of the data outside of Adobe Analytics while still not colluding with Adobe Analytics directly.
Representing the discussion in a simple functional stack diagram, below is how the Adobe Analytics as a solution will look like.
Note that the services layer is not necessarily native to the solution such as Segmentation, because services such as Identity Service and Privacy Service can be used in conjunction with Adobe Experience Cloud.
A debate on Adobe Experience Platform
Adobe Experience Platform, in my opinion, is a data lake (not a solution nor a product) that collects data and stores it. In short, without its applications (Customer Journey Analytics, Realtime CDP, Journey Optimizer, etc.) and services (Segmentation, Identity, Query Services, etc.) Adobe Experience Platform is only a foundation for storing data.
I’m not sure if the platform architecture is complicated or if Adobe by itself made the naming & information complicated because we are frequently unclear about whether to include services and applications layer when branding Adobe Experience Platform. In the real world, when we state Adobe Experience Platform, we should invariably include services and their application layer. Consider CJA, RT-CDP and AJO are AEP’s licensing versions; if you purchase an Adobe Experience Platform CJA license, it will include data lake, services + application CJA, if you purchase an Adobe Experience Platform RT-CDP license, it will include data lake, services + application RTCDP and so on. Please keep in mind that when I say services, I do not mean that all services are offered by default for all licensing versions.
However, in an ideal world, if you ask whether we can purchase Adobe Experience Platform without its applications such as CJA, RT-CDP, AJO, and so on, it is still possible for the business to opt only for the foundation (Data lake + a few services defaults to data lake) and build their own solutions on top of it. Let’s refer to this as AEP’s foundation and for the discussion here, we are comparing AEP’s foundation to Adobe Analytics, not AEP’s CJA licensing version. There are a few blogs that compare CJA versus Adobe Analytics, and I will leave it to you to research.
To begin the comparison, unlike Adobe Analytics, Adobe Experience Platform will collect data from several channels (not just digital), which is why it is commonly referred to as the Customer Data Platform. We can design our taxonomy for the data that is being gathered depending on business requirements; there are no limitations. Rather than a clean canvas for taxonomies, Adobe offers defined taxonomies based on industries; however, if organizations do not wish to comply with the taxonomy, they can design their own. As digital marketers or architects, now our primary focus is not only on data collection but also on taxonomy design to ensure that data is ingested properly in the platform.
The collected data is however not automatically processed, and it is neither substantially represented through UIs for analysis or insights. So, AEP’s foundation is merely a data storage unit with a few essential services. Consider the Adobe Experience Platform Query Service; it can empower us in reading data from the Adobe Experience Platform and writing it on the same platform after computation or utilizing the computed data for analysis & insights.
Representing the discussion in a simple functional stack diagram, below is what the Adobe Experience Platform as a foundation will look like.
It is worth noting that the application layer does not include any in-built applications such as CJA, RT-CDP, AJO, and so on; however, if we want to build our own applications, we can certainly do so depending on our requirements i.e., we can build our own application for data processing & visualization, but it isn’t provided by default.
Adobe Analytics versus Adobe Experience Platform
You may now realize that comparing Adobe Analytics to AEP’s foundation is not absolute. Both serve distinct roles and thus comparing them or presuming that AEP’s foundation can replace Adobe Analytics is not optimal. Marketers and architects debate or jot about this because they prefer to have all their data in one place rather than multiple places for seamless and effective processing. Having digital data in one place, customer data in another, and marketing data in yet another is extremely difficult and time-consuming to process/integrate for a better customer experience across multiple channels. Data is data regardless of channel, and more data with tie-ups means better analysis and insights to solve relatively large use cases. So, rather than comparing Adobe Analytics and Adobe Experience Platform Foundation, we must look at how these two operate together, which is pivotal.
Migration Considerations from Adobe Analytics to Adobe Experience Platform
On-boarding Adobe Experience Platform Foundation or migrating from Adobe Analytics to Adobe Experience Platform Foundation is only dependent on two factors:
(1) the subscriptions the organizations have and
(2) the use cases the organizations going to handle.
If the organization does not have Adobe Analytics or Adobe Experience Platform and the use case extends beyond just the digital channel, implementing AEP’s CJA licensing version is the preferable option. Adobe Analytics is ideally not necessary here as CJA will replace it completely and the CJA’s licensing version will take care of data processing and visualization. However, if the use cases are restricted only to digital channels, having Adobe Analytics is the best choice and Adobe Experience Platform is auxiliary.
Suppose the organization has an Adobe Analytics active subscription and intends to migrate from Adobe Analytics to Adobe Experience Platform (Foundation) for wider use cases, what are the considerations to look after? Here are the primary 5 considerations based on my opinion.
– Is the organization centered on visitor/customer data across all channels rather than simply digital?
If a business just has digital data, Adobe Analytics is more than adequate. To some extent, we can also import offline/third-party data using various import options (with known limitations), and thus Adobe Experience Platform is not required. However, no organization in the world can do wonders with simple digital data, therefore gradually shifting to a Customer Data Platform is vital.
– Is the organization’s goal to provide a quality experience to its customers and visitors across channels?
If the data collection is exclusive to the digital channels, experiences are also restricted to the digital channels. If data is exclusively collected digitally, experiences are also restricted to digital. Omnichannel experiences will be a pipe dream, and enterprises who want to deliver enhanced customer experiences to their visitors/customers will have no alternative but to start moving from analytics solutions to customer data platforms.
– Is the organization prepared to invest time and efforts in upgrading methods of data collection?
It is necessary that the organizations fine-tune their implementation. They should spend time developing schemas for various datasets, including digital, move from AppMeasurement to AEP Web SDK (optional, but recommended for improved website performance and real-time data flows), and have adequate validations/configurations in both Adobe Analytics & AEP’s foundation and so on.
– Is the organization using a visualization tool or relying on Adobe Analytics Workspace for data analysis and insights?
Considering that AEP’s foundation lacks a visualization UI, determining how the pool of data streaming into AEP’s data lake is represented for analysis and insights is critical. Regardless of whether the tool is paid or open source, connecting it through pre-built or custom-built visualization destinations enables businesses to replace Adobe Analytics Workspace for visualizations.
– Is the organization sufficiently familiar with the transformation of AEP’s raw data into processed data for analysis and insights?
While having a visualization tool is important, it is impossible to visualize raw data without first processing it. In Adobe Analytics, the processing is handled by Adobe, but in AEP’s foundation, processing should be managed by the organization because AEP’s foundation is just a data lake with services that can assist organizations with data processing.
For me, all other considerations are secondary. However, if an organization has both Adobe Analytics and Adobe Experience Platform Foundation, the combination can match nearly all the business objectives.
Conclusion
This should be apparent by now, Adobe Analytics serves a different purpose than AEP’s foundation, and hence migration is not simply about opting from one solution to another. And, without the applications built on top of Adobe Experience Platform, such as Customer Journey Analytics, Real-time CDP, Journey Optimizer, and so on, Adobe Experience Platform is merely a data lake. From the implementation front, steps to implement Adobe Experience Platform or steps to migrate from App Measurement to Adobe Web SDK are often discussed by experts. If you know WHAT and WHY, HOW is just relating WHAT and WHY with appropriate Adobe documentation. Happy learning and exploring!
