%20(1).png?width=2500&height=1667&name=Portal%20Drop%20Down%20(1)%20(1).png "Take a Tour of Adswerve Connect")
Share
A common scenario plays out on your website: a user shows up for the first time, casually browses around, then mid-session logs in and becomes a known user. Not a big deal, right? In traditional Adobe Analytics, this is easy. There are multiple hits spanning across one unique visitor, one visit, maybe with a dimension to break down the changes in the authentication state. Piece of cake. This is Digital Analytics 101.
It gets a little stickier measuring at the person level in Adobe Customer Journey Analytics (CJA). When you set up CJA and create your first Connection, you will have to select one field per dataset to be the Person ID. This Person ID is used to tie your events together into a journey. In the scenario above, as the user moves from the anonymous to an identified state, the events will have different sets of IDs on them. You have a few different options to choose as your Person ID, each with its own implications in the above scenario:
Great, so we can use identityMap to handle the changing levels of identification! Not so fast. Keen observers will spot a new problem. Since the unique Person ID will change namespaces through the user’s session, those events will not represent a continuous journey. In fact, the groups of events with varied ID namespaces will count as two people and two sessions in CJA.
So where does that leave us? Within the CJA user interface, there is no obvious way to actually reconstruct the full customer journey without either dropping anonymous events or breaking the journey in half when someone becomes identified. Unfortunately, this is the case, but you have options before loading the data into Adobe CJA.
This sounds pretty good, but there are some limitations:
It gets a little stickier measuring at the person level in Adobe Customer Journey Analytics (CJA). When you set up CJA and create your first Connection, you will have to select one field per dataset to be the Person ID. This Person ID is used to tie your events together into a journey. In the scenario above, as the user moves from the anonymous to an identified state, the events will have different sets of IDs on them. You have a few different options to choose as your Person ID, each with its own implications in the above scenario:
- Visitor ID (device or cookie-based): This could be Adobe ECID or a first-party visitor cookie. Regardless, it would effectively recreate the top-level Visitor container in traditional Adobe Analytics without any of the cross-device journey capabilities. Due to cookie deletion, new devices, etc., cookie-based IDs can limit the value of using CJA for journey analysis and would be advised against in most cases.
- Customer ID: This is where the magic of linking together a customer journey across devices and systems starts to take shape. A Customer ID that connects across online and offline systems is the most ideal ID to use here. If your organization already has some kind of universal or global ID, you have a head start. You can also use a hashed email address or other unique identifier. There's a catch, though; all of the events that you bring into CJA must populate the selected field with a Customer ID and if events do not contain that ID, they will be dropped. For some organizations that have high identification rates, this can be an acceptable trade-off, but for others, that mid-session log-in scenario is a bigger problem. Those anonymous events before the user logged in will be completely dropped if you choose a Customer ID as your Person ID. Not only that but events from prospects who never log in or create an account will also be entirely dropped.
- Identity Map: Within a dataset's schema in Adobe Experience Platform (AEP), the identityMap is a special field that allows you to set a list of IDs that exist when an event occurs. Each ID gets its own namespace within the identityMap, and you’ll need to declare which ID is the “primary” ID. Whichever namespace has the “primary” designation will be treated as the Person ID within CJA for that event.
"identityMap": { |
Great, so we can use identityMap to handle the changing levels of identification! Not so fast. Keen observers will spot a new problem. Since the unique Person ID will change namespaces through the user’s session, those events will not represent a continuous journey. In fact, the groups of events with varied ID namespaces will count as two people and two sessions in CJA.
So where does that leave us? Within the CJA user interface, there is no obvious way to actually reconstruct the full customer journey without either dropping anonymous events or breaking the journey in half when someone becomes identified. Unfortunately, this is the case, but you have options before loading the data into Adobe CJA.
Stitching it Back Together
Adobe offers Identity Stitching to address this issue and create a more continuous journey. To simplify, the stitching process finds those log-in events where someone becomes known, then looks back (either one or seven days) to find anonymous events with the same Visitor ID and replaces it with the Customer ID from the log in.How Identity Stitching Works
This sounds pretty good, but there are some limitations:
- As new ID relationships are detected, metrics in CJA will shift within the one or seven day lookback window.
- To update the stitched dataset, it will add a small amount of latency from when the data is collected to when it’s available in CJA
- It requires a support ticket and Adobe engineering to set it up.
- In its current state, it does not support identityMap.
- You have to maintain two schemas in AEP. If you add a field to your data collection, you have to remember to add it to the stitched schema.
Do-It-Yourself Stitching
For some organizations, the limitations within Adobe’s stitching solution may necessitate a last resort: a custom identity stitching process. With the help of some handy data engineers, it is entirely possible to create data transformations that can stitch and output a new ID on your event datasets. Some of the benefits of a custom stitching process can include:- Multi-step stitching: If there are multiple Customer IDs that you want to utilize to stitch on, you can create your own waterfall process that descends down the available IDs (e.g., Customer ID, then hashed email, then Visitor ID).
- identityMap: Make the output of your custom stitching cleaner and easier to troubleshoot with the output as an identityMap data type.
- Flexible lookback window: Modify the lookback to either maximize the amount of history being stitched or minimize the time that metrics will shift in reports.
- Control your own destiny: Identity within CJA will continue to evolve, and controlling your own stitching process can allow you to pick and choose where to leverage those future features as Adobe makes them available.