Linking Authenticated Visitors Across Devices [Adobe SiteCatalyst]

In the last few years, people have become accustomed to using multiple digital devices simultaneously. While watching the recent winter Olympics, consumers might be on the Olympics website, while also using native mobile or tablet apps. As a result, some of my clients have asked me whether it is possible to link visits and paths across these devices so they can see cross-device paths and other behaviors. This type of linking has long been available using advanced tools like Adobe Data Workbench (formerly known as Visual Sciences or Discover on Premise or Adobe Insight), but in this post I wanted to share some things you can do in SiteCatalyst (Adobe Reports & Analytics) as well.

Authenticated Visitors Only

The first thing to note, is that it is not easy to link visitors hitting your website and native apps if they are not authenticated via some sort of identifier (ID). As you probably know, visitors have different SiteCatalyst Visitor ID’s on each device, so it is hard to know which ID’s represent the same person. However, if your website/native app allows visitors to login using a customer ID or loyalty ID, you have more options available to you. Adobe has one approach called “visitor stitching” that you can read about here, but I have not seen many clients use that successfully. The reason I don’t see this working is that it requires a large change to your SIteCatalyst implementation involving replacing the out-of-the-box Visitor ID with your own Visitor ID. This can have some major ramifications (i.e. distorted unique visitor counts) and many of my clients aren’t ready for that type of risk.

However, this solution can be modified a bit to be a bit more useful and that is what I am going to discuss here. Instead of replacing the Visitor ID on your main report suite, I advocate creating a new “Authenticated Only” report suite in SiteCatalyst in which you send only authenticated traffic. This new report suite would most likely be populated using a VISTA Rule. When data is sent to this new report suite, the s.visitorID would be set to your own authenticated ID so it matches up across any device.

Let’s look at an example. Imagine that Joe Smith visits your website and views a few pages as an anonymous (non logged-in) visitor. Then on the fifth page of the visit, he authenticates. From that point on, you can send all of his traffic to a multi-suite tagged Authenticated Only report suite as a secondary server call. Next, let’s assume that Joe takes a break from your website and begins using one of your native mobile apps. Upon using the native app, he authenticates so all of his data also goes to the Authenticated Only report suite as a secondary server call. Since both of these actions are time-stamped, in the Authenticated Only report suite, you would see activity from both of Joe’s sessions, and in the order they took place. For example, in a path report you might see a series of pages Joe viewed while on the website and then in the next page flow report, see a path from a page on the website to a page found in the native app. Obviously, there is no direct link between these pages, but by passing both data elements to the same report suite, SiteCatalyst sees them as being consecutive. This can provide insights into when people are moving between different devices and what content they view on each. When it comes to pathing, you might want to consider setting a new version of the page name variable in which you pre-pend the digital channel to the page name (i.e. web:home page vs. app:home page) so when you see pages in pathing reports, you know which device the visitor was on when they viewed the page:

Seeing paths across multiple devices is cool, but that is only the tip of the iceberg! Since data coming from both platforms have the same Visitor ID, all eVars that you set will retain their values across devices since eVar values are tied to the Visitor ID. For example, if a visitors’ City is passed to eVar4 on the website, its value will persist for all actions taking place on the native app. This means that any Success Events set on the native app can be attributed to the visitor’s City, even though they never input the city within the mobile app! The same is true in reverse, as eVars captured in the native app will be available to the website. This eVar persistence can be very powerful when you think about things like Campaign Tracking Codes, which can be collected in either platform and extended to the other.

Another cool aspect of this solution is that you can do cross-device Segmentation. For example, you might want to build a “Visit” segment in which visitors viewed more than one device and XYZ actions took place. This would now be possible using the Authenticated Only report suite since the behavior on both devices looks to SIteCatalyst as if it all took place in one session (which it did!).

Another bonus of this solution is the ability to use the SiteCatalyst feature of Participation. Participation is only visit-based, so you can only see which pages within the visit led to Success Events (i.e. Orders). But when visitors switch devices, they are creating a new visit, which breaks Participation. But with this solution, any pages viewed on one device would show as having contributed (Participated) to success taking place on the other device, since both devices are included in the same visit!

Caveats

As always, there are a few caveats to any solution. The following are a few things to keep in mind before getting overly excited:

• Sending traffic to another report suite will use additional secondary server calls which has a cost implication. To estimate how much this solution would cost, look at how many page views you have for authenticated pages (pages viewed by people who are logged in) and you will get a good approximation of how many additional server calls you will have to pay for
• VISTA Rules also cost a few thousand dollars so that is another cost you would have to incur
• Using this solution assumes that all of your report suites are set-up consistently, meaning that the same Success Events, eVars and sProps are used for your website and native app suites. You should be doing this as a best practice anyway for creating global report suites, but in case you are not, be sure to only pass in the variables that are common to both via the VISTA rule or you will get different numbers or values in the Authenticated Only report suite. Keep in mind that you can use VISTA rules to change the Event/eVar/sProp numbers on the fly if it is too difficult for you to sync up your implementations right away (though I don’t recommend doing this in VISTA as a long-term solution since it can be easily broken)
• Any pages view before visitors authenticate will not be captured in the new Authenticated Only report suite. This means that you will not be getting the full picture of the visit in this new report suite. For example, you may not get the accurate entry page or miss the passing of some campaign tracking codes, but there are some more advanced techniques you can use to store this information and pass it on the first authenticated page
• Using this approach with native mobile apps that store offline data is not recommended since the offline data timestamps can mess up your data collection and eVar attributions

Outside of these few caveats, if you want to see cross-device behavior, this is a relatively simple (and cheap) solution. Obviously, if you want to get much deeper into cross-channel behavior, you may want to investigate Adobe’s Data Workbench or tools like Causata (now owned by NICE). If you are interested in seeing how your visitors float between your digital channels/devices, feel free to give this approach a try…