Expand my Community achievements bar.

SOLVED

cross domain causing session reset

Avatar

Level 7

Hi all,

Need some help identifying an issue with cross domain tracking, when a visitor loads up an application form which is hosted on a different domain the visit seems to be getting reset and/or not set to the marketing channel that the visitor landed on the site to, as a result application start and complete metrics are being attributed to the internal traffic source. Can anyone help with this at all? I've doublechecked all out settings and everything appears to be correct, visitor does get the same visitor ID when they cross domain as well.

1 Accepted Solution

Avatar

Correct answer by
Level 4

I had a quick look and noticed your cookie domain periods is set incorrectly for the application form.  It is set to "3" when in should be "2" as it is a dot com domain.  Not sure if this will fix the problem, but certainly a good place to start.

Good luck!

View solution in original post

7 Replies

Avatar

Level 4

Hi there - do you have your Internal URL Filters set up correctly?  You'll need to have the domain specified here, otherwise the referring traffic source will be set incorrectly.

If yes, maybe you can post the URL of the sites. It's the easiest way to troubleshoot!

More detail here -https://helpx.adobe.com/analytics/kb/linkinternalfilters-and-internal-url-filters.html

Avatar

Level 7

Thanks for the help! I've double checked the internal url filters so many times now:

URLs are:
Customer enters site on: http://www.cbonline.co.uk/landing-pages/cc/
Customer clicks on apply now which opens up the application on a different domain: https://www.nagcreditcardapplication.com/cb/start.do?cardtype=MG

In internal URL Filters I have both the following listed:
nagcreditcardapplication.com
cbonline.co.uk  

Here is the setup of my processing rules in marketing channels:

It doesn't seem to always happen which is what I can't get my head around, not every application is being attributed to session refresh but the vast majority are, this is also reflected in the next/previous page path reports.

Any help greatly appreciated.

Avatar

Correct answer by
Level 4

I had a quick look and noticed your cookie domain periods is set incorrectly for the application form.  It is set to "3" when in should be "2" as it is a dot com domain.  Not sure if this will fix the problem, but certainly a good place to start.

Good luck!

Avatar

Level 7

Thanks, I'm not sure why they are coming up as there was no code defining it in DTM but I have defined cookie periods explicitly as 2 so will see how this affects things, many thanks for taking the time to look.

Avatar

Level 1

Try looking at the domain that the cookies are being set on.. chances are that the form, even though it recognizes the visitor ID, is setting the form cookies in another domain (specially if you're using custom plugins..)

Avatar

Level 7

Hmm that sounds like an interesting theory, should the cookies be set on the first domain or the second one?

Avatar

Level 1

Thats the thing, you can only set cookies from the domain of the page. If the visitor is on www.mydomain.com/page.html you can only set cookies for mydomain.com from this page. I too have the same problem , the visitor id service recognizes the same visitor across different domains, but when my custom plugins ( previous page for example) run, the custom values are stored in domain specific cookies, which means that when the visitor goes to www.otherdomain.com , that this page can not read the cookies that were previously set on www.mydomain.com. Now , this may not be exactly what you were asking for, but its something people dont always realize when they read "cross-domain visitor tracking.." . One thing is the adobe marketing solutions recognizing the Visitor across domains, the other is having all of your custom data carry through from one domain to another.

I think this is one of the easiest solutions for this problem: http://subinsb.com/set-same-cookie-on-different-domains . I have not implemented this though.