Cross-Device Linking – what Adam said

Last week, Adam Greco wrote his excellent article called Linking Authenticated Visitors Across Devices, which is the first really good and complete description I have seen of how to tackle “the cross-device issue”.

In short, people are using more than one device to interact with your online presence, and because visitor identification is primarily based on cookies, it is hard to follow.

But get your visitors to log in, and you have a good chance using the approach Adam suggests.

And I’d like to add to it saying that his caveat number 3 is not that much of an issue — the report suites do not all have to be configured identically. Instead, you can use Context Data.

The idea is that instead of aligning “variables” across all report suites, you switch to using Context Data & Processing Rules on those that are different, allowing for an easier integration.


So one tiny issue left: how do you attribute things that happened before login?

Adam very casually mentions that “there are some more advanced techniques you can use to store this information and pass it on the first authenticated page”.

Can we elaborate? Create the complete blue print for what is currently one of the biggest issues in our market?

Sure thing!

It is easier than you might think, and I actually told you how it’s done way back, in the posting on “variables”.

[…] cookies, HTML5 storage, Flash LSOs and similar technologies can be used client-side, or you can use server-side storage, usually session-based, if your CMS can do that.

You could also make this part of your Data Layer. Let’s look at an example.


We’ll look at campaign tracking because that is where the marketing money goes and your friendly marketer want’s to know whether they do it right.

Remember how we did it?

  1. Make sure all links to your site have tracking codes (the marketer will do that)
  2. When a visitor clicks through and lands on your site, grab that tracking code and put it into the s.campaign variable (your code will do that)

Now all you need to do is add two more steps:

  1. Persist the tracking code locally (your code – put it into a cookie, a session variable or whereever suits you)
  2. Once the user logs in, pass the tracking code one more time (your code)

You might also want to “remember” important activities and send those as Success Events using one or more calls once the visitor has logged in — activities like account creation or newsletter sign-ups are strong candidates for this treatment.

The important part ot understand here is that persistence in Adobe Analytics is tied to the visitor ID.

Each visitor is assigned a visitor ID and the system kind of puts up a white board with that ID and starts making notes on it.

When you pass the tracking code in s.campaign, it gets noted on the white board. Pass an event on sign-up, the system will note it on the same white board, taking into account that there is already a tracking code on there.

All of the conversion variables that you are passing into the system (the eVars), are noted down. And whenever you send an event, the system puts a mark behind all those notes.

So while browsing your site, the visitor slowly fills her white board.

But now she logs in!

You now know who she is, so you send your own visitor ID into an eVar, from where it is copied into the actual visitor ID by the VISTA rule Adam suggests.

That means that she now has a different white board!

That is bad, because everything that has happened so far is now “lost” as in no longer linked to her, out of scope, so to speak. But it is also good, because we are now using “her real white board”, the one that is tied to her, personally, and that can be found and reused whenever she logs in, no matter where.

Now you know why Adam suggests sending “logged-in traffic” into a separate report suite. That report suite will give you only “her” data, unspoiled by anonymous noise.

Does that all make sense?

If it doesn’t, let’s hear the questions.

3 thoughts on “Cross-Device Linking – what Adam said

  1. Nice approach, you also can use a cookie for your ‘not-logged-in-customer’ and hand over the status and/or (own)visitorID into an evar / two evars. If the visitor isn’t deleting his cookies, you’ve all the information which you can divide into those done as a visitor and those as a customer.


    1. Hu, that would be an article, I think!

      Simplistically, cdvi has a very specific use case, while Adam’s approach is pretty generic.

      I guess cdvi will be developped further and turn into a generic solution at some point. For now I prefer Adam’s approach.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.