Tuesday Tech Bytes - Customer Journey Analytics - Week 1 - Golden Nuggets
CJA Golden Nuggets
When beginning any CJA implementation, there are some foundational building blocks that will help streamline the maintenance and expansion of the tool into the future. Here we’ll look at approaches that will help organize your implementation and streamline future growth.
Set Component IDs wisely
Component IDs have many important uses. Workspace projects, APIs, report builder, and more use the IDs to reference components. Component IDs are also searchable both in the Workspace and Data View interfaces. We’ll look at two important use cases to be aware of that should influence how Component IDs are set.
Multiple data view consistency
When component IDs are consistent, a panel can be built for one data view and later easily adapted to another data view. If component IDs are present in both data views, the appropriate components will be returned just by selecting another data view from the dropdown. This is true even when the component name and settings differ.
Here’s an example from demo data.
The component IDs for these components are as follows:
|
Component |
Component ID |
|
Orders |
Orders |
|
Cart Additions |
commerce.productListAdds.value |
|
Cart Views |
commerce.productListViews.value |
|
Product Name |
product_name |
Now, let’s assume that you have a variety of data views. Perhaps you have data views for geographic areas, separate brands, online only, in store only, etc. In each of those use cases where Component IDs are identical, the appropriate components will be returned.
On the other hand, if the Component IDs differed between data views, you’d get an error and need to rebuild your table. This would be in issue, for example, if old eVar, prop, or event numbers were used in Component IDs and weren’t consistent across data views.
If schema paths and field names will be consistent, this will be useful.
For more information, see CJA’s documentation.
BI Extension
Another important use of component IDs is in the BI Extension. When using Tableau or Power BI, for example, the Component ID will be the initial part of the dimension and metric names. Clear, meaningful names will simplify use of the tool and help reduce errors.
Derived Fields & Filtered Components
Using clear, consistent Component IDs is especially important for derived fields and filtered components.
By default, when you pull in a derived field, a long string of seemingly random numbers and letters are set as the component ID. When these components are duplicated, values such as _1 and _2 are appended. See these examples from a demo data view.
Likewise, when creating a metric from a dimension, the Component ID reflects the original dimension. Here’s an example where I filtered page_name for only instances where landing is included. Note the component name isn’t very intuitive. Instead, you should set the component name to something clear such as landing_page_instances. This will simplify use of tools such as BI extension.
Identifying custom and out of the box components
There are several ways to highlight or differentiate components. We’ll touch on three approaches –emojis, capitalization, and tags.
Did you know that emojis can be used in component names? Frederik Werner, one of the Adobe Champions, who provided feedback on this material shared this great tip! Using emojis can help highlight key components. For example, you could use
Adobe’s out of the box components are capitalized. Using all lower case for custom components can make it clear to users which type of component they’re using. In the example below, users can know that People and Sessions are out of the box components while online orders is custom to this implementation. Consistency in capitalization, in addition to admin approval of vetted components, can be helpful to both creators and consumers of CJA analysis.
Finally, using tags can help keep components organized and make them easy to find. Tagging components by type and use case can help make it easier for users to find the right components. While in the component search field, typing # allows you to search by tags. If desired, using all lower case for custom tags can provide useful context for users.
Use consistent persistence for derived fields/classifications
When using component settings or derived fields, be sure that you’re mindful of persistence. For example, let’s say you have a Campaign ID field, and you want to parse out certain elements. When you build out new components to capture each element, be sure that the persistence matches the original component. Likewise, if you use a derived field in a similar way, ensure that its persistence is set to match the use case.
Teaching users how to look at component settings is vital in understanding persistence. In the example below, users can easily see that the Marketing Channel will default to Last Known and persist for the Session.
In most cases, analysts should use custom metric settings to modify persistence. However, if multiple versions of dimensions are created, the name should clarify differences. For example, names such as, first touch channel | 30 days, or first touch channel | session, provide clarity.
Related Conversations
