You can use a Flow visualization with the Mobile Device Type dimension.
The Mobile Device Type example illustrated above allows you to see how people move between mobile device types and desktop device types. However, it does not allow you to distinguish desktop browsers from mobile browsers. If you would like this insight, you can create a custom variable (such as a prop or eVar) that records if the experience happened on a desktop browser, mobile browser, or mobile app. You can then create a Flow diagram as described above, using the custom variable instead of the Mobile Device Type dimension. This method provides a slightly different view on cross-device behavior.
CDA’s cross-device stitching occurs in two concurrent processes.
The first process is called “live stitching”, which occurs as the data streams into Adobe Analytics. During live stitching CDA does the best it can to restate the data at a person level. However, if the person is unknown at the time of live stitching then CDA falls back to the visitor ID to represent the person.
The second process is called “replay.” During replay, CDA goes backwards in time and restates historical data, where possible, within a specified lookback window. This lookback window is either 1 day or 7 days, depending on how you requested CDA to be configured. During replay, CDA attempts to restate hits where the person was previously unknown.
If using a device graph, Adobe keeps device mappings in the Co-op Graph and Private Graph for approximately 6 months. An ECID that has no activity for more than six months is removed from the graph. Data already stitched in CDA is not affected, but subsequent hits for that ECID are treated as a new person.
Adobe treats timestamped hits as if they were received at the time of the timestamp, not when Adobe received the hit. Timestamped hits older than 1 month are never stitched since they are outside the range Adobe uses for stitching.
Using a custom visitor ID is a legacy method to connect users across devices. With a custom visitor ID, you use the
visitorID variable to explicitly set the ID that is used for visitor logic. The
visitorID variable overrides any cookie-based IDs that are present.
Custom visitor IDs have several undesirable side effects that CDA overcomes or minimizes. For example, the custom visitor ID methodology has no replay capabilities. If a user authenticates in the middle of a visit, the first part of the visit associates with a different visitor ID than the latter part of the visit. The separate visitor IDs results in visit and visitor inflation. CDA restates historical data so unaunthenticated hits belong to the correct person.
Customers already using Custom Visitor ID can upgrade to CDA without any implementation changes. The
visitorID variable is still used in the source report suite. However, CDA ignores the
visitorID variable in the virtual report suite if a user authenticates.
In some situations it is possible that multiple people log in from the same device. Examples include a shared device at home, shared PCs in a library, or a kiosk in a retail outlet.
In some situations, an individual user can associate with a large number of ECIDs. This can occur if the individual uses a lot of browsers or apps, and can be exacerbated if they frequently clear cookies or use the browser’s private or incognito browsing mode.
Both People and Unique Visitors metrics aim to count distinct visitors (individuals). However, consider the possibility that 2 different devices can belong to the same person. CDA maps the 2 devices to same person, while the 2 devices are recorded as 2 separate ‘Unique Visitors’ outside of CDA.
These two metrics are roughly equivalent to each other. Differences between the 2 metrics occur when:
See Unique Devices for more examples and details around how it works.
Yes. Analysis Workspace uses the 2.0 API to request data from Adobe’s servers, and you can view API calls Adobe uses to make your own reports:
Yes. If an individual sends hits from two separate devices within your virtual report suite’s visit timeout (30 minutes by default), they are stitched into the same visit.
Both of these identifiers are calculated by Adobe at the time the report is run, also known as Report-time processing. The nature of Report-time processing means that it is not compatible with Data Warehouse, data feeds, or other export features that Adobe offers.
Switching from device graph to field-based stitching or vice versa can be requested via Customer Care. However, making such a switch can take a couple of weeks or more to complete and historical stitched data from the previous method is lost.
CDA pulls the identifier variable dimension items before they are optimized for reporting. You do not need to worry about unique limits for the purposes of CDA. However, if you tried using that prop or eVar in a Workspace project, you can still see the (Low-traffic) dimension item.
Multiple report suites may be enabled, however each additional report suite will increase the overall provisioning time if multiple report suites are requested at once. CDA does not merge report suites. Each report suite enabled for CDA needs to be cross-device in nature (containing data from multiple surfaces such as desktop web, mobile web, mobile app, etc.)
No. For the same org, only one region can have CDA enabled.
The advantage of the 7-day replay lookback window is that CDA is able to go back further in time to try to associate previously anonymous events with some person who later logged in within those 7 days. The disadvantages of the 7-day lookback window are 1) replay only runs once per week, and 2) the most recent 7 days are subject to change.
The advantages of using the 1-day replay lookback window are 1) replay runs every day and 2) only yesterday is subject to change. The disadvantage of the 1-day lookback window is that CDA is only able to go back 1 day to try to associate previously anonymous events with a person who logged in yesterday.
If a customer downgrades from Ultimate, they will no longer have access to stitched data. All previously stitched data will be removed. This means the CDA virtual report suites will now reflect no cross-device stitching. Data will look similar to the original unstitched report suite.
CDA uses a complex parallel processing pipeline, with multiple dependent components. A data mismatch of approximately 1% for the total number of hits between the original report suite and the CDA virtual report suite is expected. It has minimal impact on the cross-device capabilities.
The number of the ‘Identified People’ metric can be slightly higher if the identifier prop/eVar value runs into a hash collision.
For Field-based stitching, the identifier custom variable is case-sensitive. The number of the ‘Identified People’ metric can be significantly higher if identifier values do not match case. For example, if
Bob are sent and expected to be the same person, CDA interprets these two values as distinct.
This situation usually occurs when a visitor generates both authenticated and unauthenticated hits in the reporting window. The visitor belongs to both ‘Unidentified’ and ‘Identified’ in the Identified State dimension, causing an attribution of unidentified hits to an identifier. This scenario can change after Replay runs, depending on replay frequency and success rate.