If your company employs multiple domain addresses you have no doubt found yourself asking: “Is it too much to ask to be able to stitch a single user’s behavior across two different sites that happen to be hosted on separate domains?” Unfortunately for marketers, that answer in many cases comes back “Yes.” This isn’t for lack of want to though, identifying a single user across multiple domains might be one of the most appealing concepts to implement for marketers. So how can it be done? Can it be done?
As the old saying goes: where there’s a will, there’s a way and, with a little extra elbow grease and a blank page on your primary domain, you can begin to do just this. Being able to do so effectively will provide you with a critical advantage for your business as you will be able to track unique users across multiple domains (an element of Visitor Stitching). This will ultimately allow you to more effectively engage with your users and solve challenges that they are encountering across your domains.
The Situation(s)
So, what’s the rub? Admittedly, some scenarios for cross-domain tracking are fairly simple. A user may progress through a one-way flow that temporarily moves to a different domain, then either ends on that domain or transitions back. However, this scenario is rarely the case. Take, for example, another scenario where a company’s web architecture includes various microsites, separate divisions with unique domains, or other complex structures. This is where you need a more sophisticated solution to effectively connect users across multiple domains.
To help visualize the different scenarios that could occur, consider the 3 following behavioral scenarios:
User A
- Visits abc.com, views 3 pages.
- Visits def.com the next day, views 3 pages.
User B
- Visits abc.com, views 3 pages.
- Clicks a link from abc.com to def.com within the same session, views 3 pages on def.com.
User C
- Visits def.com, views 3 pages.
- Visits abc.com by entering the address manually in the browser immediately after def.com, views 3 pages on abc.com.
Without any cross-domain tracking, all three of these unique scenarios result in the same aggregate metrics: 2 unique visitors are counted, each with 1 session of 3 pages, totaling 6 unique visitors and 6 sessions at 3 page views/session.
Typically, the primary way to stitch these sessions across domains would be to append query string or hash parameters to any links that carry the user from one domain to the next. Assuming these new parameters do not end up breaking the page request entirely, a few issues still tend to arise:
Redirections can strip these parameters before the user lands on a page
If a link from one domain to the next employs any sort of redirection mechanism, it will have to be modified to carry along these unique parameters. This issue has the potential to become a major roadblock.
A user must click a link that takes them from one domain to the next
In the above set of user scenarios, only User B would be identified as a single user spanning two domains. Both User A and User C would still each be identified as two unique visitors: one on abc.com and one on def.com.
Clearly, utilizing this method of tracking users across domains leaves some noticeable gaps in your reporting. For example, what if no links exist from one domain to the other, but you are still interested in identifying that user singularly across domains? Or, what if a link exists but the user does not click on it to traverse between the domains and lands on the two domains via separate methods? These are common enough occurrences that another solution is needed to provide you with the actionable insights in your user’s cross-domain experiences.
Enter frame messaging.
Utilizing Frame Messaging to Track Users Across Multiple Domains
If only abc.com and def.com could talk to one another, the problem of tracking a user across them would be well on its way out the door. This is where frame messaging can be used to kickstart the conversation process by having all pages on def.com load an IFrame that requests an ideally blank page from abc.com. Unfortunately, JavaScript executing on def.com cannot crawl into the IFrame because it loaded content on a different domain and browsers block this traversal for security purposes. The solution is near though and, at this point, the easiest method for conveying the solution is a simple analogy.
Imagine you are baking a cake at home and realize you need sugar. Sure, you could go to the store and buy your own sugar, but what if the neighbor has some you could simply borrow? You just need a little bit for this cake. Here are a couple of scenarios that mirror our situation above.
Scenario 1: You (def.com) could walk yourself over to your neighbor’s house (abc.com), and, if they kept their house unlocked, you could walk in, find the sugar, take what you need, and walk back out. This option may be convenient for you, but unfortunately, it poses a substantial security risk for your neighbor. As a result, the door will be locked, so this scenario won’t cut it.
Scenario 2: You decide to call your neighbor. Seeing that the incoming call is coming from you, the neighbor picks up the phone, and you ask them if they can send over some sugar. They say no problem, commenting they’ll be right over. You wait at the door, and when you hear a knock, you open the door and politely accept the sugar, then bake your cake.
In spirit, the second method is exactly how two frames can communicate with one another on a single page. If a user is on def.com, the page can load an IFrame on abc.com, which represents a phone call to the neighbor. As long as abc.com is listening, the two domains can send messages back and forth with any data they’d like, allowing def.com to request a cookie and abc.com to deliver the appropriate values back. Ideally, abc.com would also have logic to ensure the request is coming from a known source, otherwise it can choose to simply not respond.
Though further optimizations are possible, this solution will bypass the need for a user to interact with anything on the page to achieve tracking across multiple domains. If you control the code being placed on both domains, you have the power to implement this solution.
The Net Result
Now that cross-domain tracking is being accommodated behind the scenes automatically, let’s review our initial scenario with users A, B, and C. In all 3 scenarios, each user would be identified as a single unique visitor. User A would still have 2 sessions at 3 page views each given the time delay between the two, but users B and C would both be considered a single session of 6 page views each. The aggregate data would then become 3 unique visitors with 4 unique sessions, 2 of which contain 3 page views and 2 of which contain 6 page views.
You can quickly see in this simple example that only spans 3 page views per site, just how quickly the data you’re seeing from your users will evolve and how you’ll be able to better connect the dots across all of your web properties and the entire user experience going forward.
Want to learn more about connecting datasets to drive more efficient user experiences? Check out our guide to Visitor Stitching and subscribe to our blog.
