Hello world,
I have been quite silent on the analytics front over the last months. Several reasons can explain it but one big reason is that I moved to a new role supporting the Adobe Experience Platform deployment as a consultant.
Working on a brand new tool is always bringing a lot of excitement but also a lot of learning.
My goal for this blog always was to share whatever I know so you can make informed decisions on your implementation or analysis.
In the beginning, this was a lot to take as Adobe Experience Platform and Customer Journey Analytics are very huge tools to master. The idea is to bring back some experience from the field and do not repeat the incredibly complete documentation on that matter: https://experienceleague.adobe.com/docs/customer-journey-analytics.html
Even though I have a step on that process and my role is now evolving, I am still following the Adobe Analytics community (a bit less the GA one to be honest).
One element I can see coming over and over is the move from Adobe Analytics to Customer Journey Analytics.
This is the big question mark from the customer I interact with, should you do the move? What does it take to realize the move? How can you move from one to another?
Many questions are coming and I have the very ambitious goal to answer most of them… for 2021.
Disclaimer on veracity
The thing with Adobe Experience Platform, and Customer Journey Analytics, is that these beasts evolve very very fast. Many bloggers (including me) got burned by announcing something that turns to be deprecated or replaced a few months later.
Here comes a huge kudo to the technical writing team that is trying its best to document everything, new, updated or deprecated so you can have the latest information available.
I will probably for sure need an update on that blog post, but I am fairly confident that this nonetheless is useful to many people.
As you will confirm in the next paragraphs, I am not a sales guy and my idea is not to sell the product but to make sure I am not ending up with impossible expectations if you buy the product ;).
Why you should move ?
There are many good arguments to get started on Customer Journey Analytics and I will try to list most of them here.
Unlimited amount of variables, events… everywhere.
This is one of the strongest selling points so far, a very underestimated one as you will see that CJA can bring more fancy stuff live and we tend to spend too much time on these.
However, I find that this argument is simple and is the only path forward if you have a fundamental problem with your current analytics solution;
You have reached the limit on either of these:
- maximum numbers of dimension (eVar/props) or events on your implementation
- maximum number of values being reported (the infamous “(low-traffic)”)
Both of these problems completely disappear with Customer Journey Analytics.
Think about it for a minute. Let it sink.
There is no limit on the number of dimensions you can report one and there is no limit on the number of items you can see in your report.
I know that majority of customers are actually not out of dimensions or events, or do not reach the 500k-1M value limit (that you can raise) but for those that are, it is actually a big news.
Your global company wants to understand the long tail of your internal search keywords.
Chances are that you will never be able to report on these directly in a Workspace report (except funky Data Feed or Data Warehouse export but that is not optimal)
Now you can report, filter, and extract such granular information, even create filters (a.k.a. segments) for very low performance keywords.
More Flexible Data Structure
Because Customer Journey Analytics is reading from the Adobe Experience Platform Data Lake storage, you can take advantage of the schema creation process to represent the data the way you want.
Forget about eVar1, prop20, and event3.
Everything can be following your business structure (should?).
A better business representation is always nice for increasing understanding on your report.
You have a name variable that makes sense for you and it is a very nice bonus.
It also help a lot on keeping all of the websites implementation aligned. “articleName” should normally be easier to make consistent across your implementation than eVar23.
However, the biggest point is that you can represent very much complex structure in the Data Structure that was not possible in Adobe Analytics.
Everything was flat in Adobe Analytics…. except for Merchandising evar that was a sublevel of a product.
In the schema creation process, you can represent object that serves as a container of an event or a representation of a business element.
Such representations are not a dream anymore:
{"pageInfo":{
"pageName":""
},
"productInfo":[
{
"prodName" : "X",
"price" : 10.00
},
{
"prodName" : "y",
"price" : 5.25,
"insurances":[
{"InsuranceName":"basic"},
{"InsuranceName":"complement"}
]
}
]
}OK, these may not be a dream for many people 😀 but it better represents the relationship between objects.
CAREFUL: This permits advanced analysis but has some major caveats related to Profile enabling, Filters and Query Service.
Overall, arrays are not optimized on AEP / CJA yet.
More Flexible Views for users
Because most of the data lie in AEP Data Lake, you can actually decouple the data collection from the data representation in your reports.
Customer Journey Analytics works with connections to AEP (more info), from these connections you can load the data, and once you have the data in CJA, you can create several views from it.
It is like Virtual Report Suite in Adobe Analytics Analytics… but much more powerful.
- You can setup different attribution methods for each of your dimensions
- You can add or remove dimensions or metrics and change their names (obvious stuff but worth mentioning)
- You can include some value or not depending on a filter (Demo here for metric & demo here for dimension)
- Rename the “no value” value
- etc…
In the same way, as for Virtual Report Suite, you can assign one Data View to a specific group of people, so you can enforce compliant access to data to your user via this method.
Classification / Lookup with metrics
One thing that I am very happy about, and still never understood why Adobe Analytics deprecated this feature, is the ability to realize classification with metrics information.
You can add event metrics (revenue, margin, cost, etc…) to your product data.
Even though the classification lookup (new name) files must stay flat (no Object or Arrays) for the moment, this is already a huge improvement from what is possible to do with Adobe Analytics.
Stitching Service
One additional service that can come from the Customer Journey Analytics contract is the ability to have stitched service.
What is the stitched service?
It is a way for you to link the user between their identified and unknown profile (thanks to the ECID).
Once the user is logged in, it can be attached to its anonymous ID and then deduplicate the users between devices.
This is very interesting if you have a quite high login rate, so you can finally have a better picture of your audience.
I have worked closely with the team delivering such service, it is quite powerful and I have seen many customers trying to do such implementation without success for years.
Here, it is an addendum to the contract.
Combining different event datasets
Last but not least, is the ability to load in the same connection Event datasets from different sources and link them by their Customer ID.
This is the thing that most of the Customer Journey Analytics presentations are going to focus on so I am not going to give you many details. Many videos on the internet will be showing it.
A cool thing is that it means that you could load past data on the AEP Data Lake and have these events automatically mapped in the user journey.
In Adobe Analytics, if you send a data after 30mn time window, you will not link its attribution or visit to the rest of the hits in that journey. This is not the case anymore in CJA anymore.
Again: How powerful is that?
Why should you not move to CJA ?
Before we move to the next section of this article, on how to move. I want to spend some time on reasons for you not to move.
There are some and this may be the most interesting part of the article for some.
Limited support on Marketing Channels
You have a Marketing Department that is breathing the Marketing Channel report and only live and dies by it? Then Customer Journey Analytics may not be the right move for now.
There are some possibilities (see later) but overall, the Marketing Channel capability is not fully supported by Customer Journey Analytics.
You can still move as I do not see this as a show blocker, but at least prepare your marketing department and define a new way to identify and report on your channels.
Migration effort
With all of the new features and new ways to represent the data, you need to consider the move from Adobe Analytics to Customer Journey Analytics as a migration process.
There is a way to avoid a complete migration or reimplementation (see later), but at the end of the day, you will want to migrate to take advantage of all of the new features.
The migration effort is going to be significant and if you do not have the bandwidth for that in your different teams, then you better stay on Adobe Analytics easy implementation.
Better to have a good implementation with a good tool than a bad implementation with an excellent tool.
Real-Time focus
If your company is focused on real-time data, it may not want to move to Customer Journey Analytics yet. There are some real-time capabilities coming but overall the time for the data to load in the CJA is between 1h and 2h. So (a bit) longer than what it used to be for Adobe Analytics (30mn).
Data being usually more complex in CJA than in Adobe Analytics (only flat), you have to account for that additional processing.
At the same time, more possibilities are offered before ingestion on CJA.
You can see a great number of articles on the number of elements you can define bein the Data View panel before reporting (videos):
Missing predefined elements
Because Customer Journey Analytics is not focused on Web Analytics, it is still missing some elements if you are not realizing a default implementation.
Such elements may be missing in your implementation:
- Time of day
- Day of week
- Geolocation elements
Most of them are coming over the next months but if you are building important rules around them, you may want to think of a workaround for time being and until the release are set.
Also, you do not have Bot Traffic rule-setting yet. It will also come but that is an important piece if you are using these rules intensively. Bots can represent a huge part of a website traffic.
Multi Currency limit
If you have an implementation of Adobe Analytics that relies on currency conversion to display a single currency from multiple countries, then this option has not been implemented yet.
You can always realize conversion on your website during tracking or via Query Service later on but this is an additional setup required, contrary to what Adobe Analytics offers.
Another way to set it up is to have one DataSet per currency setup and display them in different Data Connection and, or Data View. But the overview of all of your implementation is made more difficult.
How can I move to Customer Journey Analytics ?
You are now interested in CJA and want to know which options are better for you in order to move there.
There are quite some and they do not offer the same level of commitment in the migration process but also do not provide the same level of features.
Adobe Analytics Connector
(The easy path)
By enabling the Adobe Analytics connector, you can directly load your Adobe Analytics data into AEP and then connect that dataset into Customer Journey Analytics.
This path has several advantages:
- No need to change your implementation of Adobe Analytics
- No big change in the naming
- Add more information than default AEP Web SDK implementation (Marketing Channel, Time Parting, A4T,etc…)
However, for me, this is not a path you should consider for some reasons:
- Give you a mix implementation of Adobe Analytics on AEP (Where do these values come from? from your AA implementation? From AA to AEP transformation? From CJA Data View Configuration?)
- Doesn’t provide flexibility of the schema
- Push AA constraint to the AEP Data Set
- Even Longer time to report (Goes to AA then to AEP)
This may be nice for a POC, testing out CJA connector and data views but it doesn’t bring you much value from the default AA (except the unlimited values in reporting, which I admit is quite nice already).
It is like you are purchasing a Ferrari and put a Ford motor in it. It will work but this is not what you should do.
AEP Web SDK
The AEP Web SDK is the default implementation and most of the features that are missing in the data collection at the moment will come there, thanks to the konductor layer (see article on debugging AEP Web SDK to see a simple representation of the architecture).
Moving from AA implementation to AEP Web Web SDK is a different discussion altogether but it brings some additional benefits:
- Faster time to report
- Full fledge AEP Schema capability
- Bring Your Own ID capability (coming soon!)
but has some drawbacks (on top of migration effort):
- Marketing Channel not present
- (much) More complex implementation
- Support for legacy solutions (AA / AT / AAM) not optimal
- A4T type of report not possible
By default, I think that this is the way to go for your normal implementation. The BYOID feature will most probably be a new standard for advanced implementation teams.
And if you happen to have Launch, you can also check this article from Benedikt Wedenik on his best way to combine everything (with ACDL) into a neat client side implementation.
Server Side Route
I am a big advocate of doing server-side implementations, even Launch or GTM has some Server Side features (as long as you have their script on your page + AEP Web SDK for Adobe).
For AEP Web SDK, I heard that they are even working on full Server Side SDK for the future.
The thing is, that you cannot really go full server-side yet for tracking website interaction, you need a middle man, aggregating value and connecting them together.
I used to think that the event-merged-ID from the AEP Web SDK would help to solve that problem but it seems that this feature is doomed since its release.
Too much hype probably kill it.
However, if you manage to realize some implementation that works and you need a server-side option to send these data to AEP (and then to CJA), you can use the AEP Streaming Service. This is robust and works fine.
You can also add a Data Prep service to it, that helps you modify the default message you are sending to AEP.
Important note: The Data Prep layer will also come later for the AEP Web SDK and will decouple the XDM schema from your data representation that you sent to AEP. This will make it easier to use the AEP web SDK, even though it will add a layer of complexity (like Processing rules). I will do an article when the time come.
I would believe that this is a service that Adobe should offer, as the clients will probably move more and more there, but I am not a Product Manager to make that happen.
Summary
I hope this article was helpful to you in order to help in deciding if you should go to CJA or not.
At the end, a very advanced product, that can bring a lot of value for your organization, you just need to consider that this is a new product, not an Adobe Analytics 2.0.
I have to also note the nice documentation provided officially regarding Adobe Analytics and CJA capability parity: https://experienceleague.adobe.com/docs/analytics-platform/using/cja-overview/cja-aa.html
Appendix
Following the article release, I received some follow-up questions about the different elements or the implication of such elements in CJA. I will try to cover most of them below.
Data Warehouse in CJA
At the moment of the writing, 2021, there is no such capability in place. There is most likely going to be a way to export data directly to AEP, as a dataset in the future.
At the same time, there is already the capability to download a CSV with 50K results directly from Workspace. Will that limit of 50K be lifted for the UI ? Probably at some point.
In the meantime, there is not a Data Warehouse, but worry not my friends, you have the API at your service. Because (low traffic) does not apply there, you can use the API to loop through the 50K limit and receive all data from your report.
It just happens that I built a python wrapper cjapy in order to simplify your work there. Check it out.
Merchandising eVar allocation
As it is possible to create sort of Merchandising eVar in your object, the attribution of these dimension in the same way that merchandising eVar works (binding it to a product and to a specific event) is not yet available in CJA today.
It is definitely coming as I have participated in calls to discuss its deployment. The goal would be to make generic enough so you can apply such logic to any type of dimension, if you wish to.
This is no small feat so be patient but this is going to be quite awesome.
And by the way, I believe the plan is for 2022, so in any case, if you do not have CJA yet, by the time you get it, you will have access to that feature probably.
Reporting time
With the fact that there is no limit to the number of dimensions reported (no (low-traffic)), a fair question was asked about the performance of the reports.
It is common knowledge in Adobe Analytics that when you are reporting on a dimension that possesses 5 000 values vs one that possesses 500 000, the reporting time is increasing.
In CJA, the reporting time is not that much impacted by such high cardinality. This is mostly thanks to the reporting engine that CJA is built on top, which is, as you probably guessed, quite different from what Adobe Analytics is using.
I have run reports with very large of cardinality in the dimensions and it was surprisingly fast.
Obviously, if you are running a report that returns the top 400 values for the whole year, it will take longer that 10 values for the last 7 days. But performances have been accounted for so that you do not blow yourself up normally.
Sub Hit usage
For those of you that understood the nested object capability, you also had the question of the filter application for these subHit reporting.
At the moment of this writing, in 2021, there is no Filter capability for sub hit level. The same way that for Merchandising eVar, you can only filter on the Hit level.
Therefore, the only way to realize sub-hit filtering is to use breakdown or the specific dimension, which increases reporting load. (each breakdown is an API call).
Nevertheless, this is a planned development for Workspace in CJA and it is probably coming soon, as this use-case is more and more developed.