Avoid the setup mistakes that lead to errors, data loss, and costly rework. Whether you're launching CJA for the first time or managing complex pipelines across multiple BUs, here's what to watch for—and how to do it right from day one.
Each component has a Component ID that is used by Workspace and APIs to retrieve the correct component. When you set these wisely, analysts can easily build and adapt projects for multiple Data Views. By default, the IDs are based on the schema path. However, when you duplicate components or create derived fields, component names can become less clear.
The top component shown in figure 1.1 is based on a derived field. The default Component ID is related to that specific derived field. The bottom component in figure 1.1 was duplicated from a dimension. Notice the Component ID is based on the schema path with an _1 added to the new ID.
Figure 1.1 – Default Component IDs can hamper cross Data View usage
Pro Tip: Use derived fields with consistent Component IDs to unify reporting across Data Views.
In both of these cases, I updated the Component ID as shown in figure 1.2. In the component settings portion of Data View settings, a pencil appears when hovering over the Component ID. Clicking that pencil allows the value to be changed.
Figure 1.2 – Updated Component IDs simplify cross Data View usage
My updated Component IDs are not only clearer, but they allow analysts to create one report and use it across multiple Data Views. As long as the selected Data View contains a component with the ID, even if based on a different derived field, different underlying components, or a different connection, the component will be retrieved as shown in figure 1.3.
Figure 1.3 – Consistent Component IDs allow visualization to work seamlessly across Data Views
If Component IDs aren’t consistent, analysts will encounter errors and must rebuild visualizations as shown in figure 1.4.
Figure 1.4 – Inconsistent Component IDs will cause end users to encounter errors
Unlike traditional Adobe Analytics, CJA datasets follow a defined schema. Data must be in the data type defined by the schema to be ingested. Always confirm your data types against the defined schema before ingestion, especially when using automation pipelines. A mismatch can drop entire rows and debugging it later can be painful.
For fields like SKUs, use string unless you need calculations. Numeric types can introduce formatting issues.
On the other hand, if a number is in a string data type, you cannot perform calculations with the value. In one case, we parsed an index from a string into its own dimension. An analyst wanted to average the values, but since they were stored as strings, calculations weren’t possible. To work around this, I had to set up a Report Builder project to bring the index values into Excel where I could use them as numeric values.
By default, numeric components are added as metrics, though they can easily be changed to dimensions. I’ve sometimes found screen width and height listed amongst the metrics based on integer data type. You can’t concatenate integers into a single string – so we can’t have a single dimension with both width & height, for example.
Next, any event must have a person ID to be ingested into CJA. Any rows without a person ID will still exist in the underlying dataset but will not be available in CJA Workspace.
Caution: CJA will try to stitch people together when place holder person IDs (such as 1234 or NA) are used. Where extremely high volumes are seen for specific user IDs, CJA will stop ingesting data for those IDs.
Before transitioning to CJA, it’s important for teams to understand that there are key differences from traditional Analytics.
First, some dimensions aren’t available. Adobe Analytics does much of its processing of data at the time of ingestion and it keeps a visitor profile. This profile has components such as visit number, customer loyalty, and days before first purchase. Because CJA is based on report time processing, which allows much of the advanced features of CJA, a visitor profile isn’t kept.
To help accommodate for this, CJA does differentiate between first-time sessions & return sessions. A 13-month lookback window is used for this determination. With the right add on, Query Service can be used to replicate some of the metrics from Adobe Analytics but updates and out of order data could complicate that.
In traditional Analytics, marketing channels expire after a period of inactivity. As a result, for visitors who come to the site often, channels can persist for months or even years.
In CJA, a lookback window is used for marketing channels. The window can be set to a session container, based on the reporting window, or a specified period up to 90 days maximum.
But any channel instances before the lookback period will not be reflected in reporting as it would have been in traditional Analytics.
Enrichment data, like device type, geo data, and bot filtering, may vary depending upon your ingestion method. When ingesting events generated by Web SDK, Mobile SDK, and Server API through data streams, there are various options for collected data to be enriched with these types of metadata. This needs to be set up and happen at the time of data ingestion. Changes are not retroactive.
Another key difference for some organizations is classifications. Lookup datasets allow for the equivalent of classification import data. Derived fields and dimension settings can use regular expressions, however, there is a limit of one regex in each. Other functions such as split and delimit can be helpful. But there’s no true replacement for classification rule builder in CJA. I’ve seen thousands of rows of regex to classify values in Adobe Analytics, and that’s not possible in CJA.
With CJA, more flexibility means more decisions and those often move from engineering to analysts or data owners. Tasks like creating and maintaining derived fields, managing components, maintaining data views, and building schema now often fall to analytics teams instead of tagging or implementation teams. Aligning on who owns what, and documenting it, is key to avoiding confusion and duplicated work.
CJA allows the ability to bring in multiple event datasets—both online and off. It’s important to understand that any event will contribute to Session and People counts. For example, if a customer service dataset is ingested, these interactions will now be events that are reported within CJA—even if the people have no online events.
When analysts are looking at metrics such as sessions and people, all event data will be included. If they want to examine only a subset of data, they’ll need to filter the data.
Although events can be filtered out from projects or Data Views, any persistence related to events that have been filtered out will still affect reporting. For example, let’s say a connection has both in-store and online events. In one Data View, you can filter the data by removing in-store events, leaving only online events. However, dimensions will still persist from in-store activity (even though those event rows are filtered out of the Data View). It’s important for end users to understand this impact on their reporting.
CJA makes it extremely easy to create a copy of a Data View. The new Data View can be based on a different time zone, fiscal calendar, starting month, or starting day for each week. Additionally, filters can be applied to the Data View - such as for different geographical regions. Components can be changed within each Data View.
And interestingly, each Data View can have a different session timeout setting. This would allow you to easily compare how session activity differs between a 30-minute timeout, a 24-hour timeout, a 1-week timeout, or a 30-day timeout. This could be especially insightful for products with a longer buying process.
However, there has been a key warning to Data Views. Once you made a copy, it was completely independent from all others. Thus, if you needed to make updates and they applied to multiple Data Views, you needed a good system to ensure consistency across them. The Adobe team recently released Shared Metrics & Dimensions which allows multiple Data Views to share components, ensuring they remain consistent.
Avoiding these common pitfalls early on can dramatically improve your CJA implementation. If you’d like support reviewing your setup or tailoring these tips to your organization, our Adobe CJA experts are here to help.
Not sure on your next step? We'd love to hear about your business challenges. No pitch. No strings attached.
