ECID resets mid-session (WEB)

[skhcg]

Hello,

There is one weird scenario happening intermittently (see the attached image).

ECID just resets to new one. 

Regards 

[skhcg]

Its a tough one. Not sure if I can get any answers.

[Sumit-Kumar]

IP remains same but domain changes mid flow. ECID reset indicates cross domain identity is not persisting. Pls test it and validate same ims org id, consistent launch/web sdk config, cookie domain scope (.allstate.com) and correct cross-domain ECID transfer (visitor.appendVisitorIDsTo() if using appmeasurement). Also check browser ITP / cookie restrictions like on safari for the affected domains

[skhcg]

It's not cross domain issue. We have same CNAME across all domain.

I think, I have found the issue. The traffic is coming from unknown browser id 1686914150. Likely cause is that it's a BOT traffic.

Thanks 

[Sumit-Kumar]

OK, it can be a bot, but if in your testing ECID persists across domains like in chrome, it means ECID service is working and cross-domain ID transfer is correctly done..also along with CNAME if you are using (appendvisitorIDsTo()), this approach also supports cross domain, but browsers with stricter tracking prevention (ITP) may still cause ECID resets due to cookie persistence limits.

[Jennifer_Dungan]

If the ECID is set to the domain (and not to each subdomain), you shouldn't need to use appendvisitorIDsTo at all...

The ECID cookie should be set against .allstate.com which would then be used for ALL domain variants. I checked the domains from the screen shot, and the correct domain is being used on the cookie.

I also tested visiting both domains, not even from site to site (but directly typing the domain into my browser), I got the same ECID.... 

@skhcg do you know how often this is happening? You might be on to something with "bot" traffic... the browser may not be accepting cookies, so while on the same domain variant, there is a memory (without the cookie), but as soon as the new domain variant is reached, a new ECID is generated due to the lack of cookie... you could try using the appendVisitorIDs, or do something custom and only do this IF you can't see an ECID cookie? Keeping the URLs cleaner for users without the issue.

[skhcg]

Thanks

It started happening intermittently since Thanks Giving. 

One set of data shows browser id as 1686914150 which is not present in browser lookup. Corresponding IP address for these records are 35.151.138.123 (Amazon Web Service)  and 150.252.240.10 some cyber security company.

In another set, I am getting OS which are not part of lookup table in click stream

Regards

[Sumit-Kumar]

Sure, I also tested on https://www.allstate.com and https://purchase.allstate.com/ and can confirm that the ECID is set on the root domain .allstate.com, so that looks fine. But, the site https://shopandbuy.allstate.com isn’t accessible for me where you are having this issue as it redirects to https://purchase.allstate.com. If you can test on that domain https://shopandbuy.allstate.com and verify that it uses the same ECID as shown below & on AA call as well, then cross domain tracking with the same ECID is working as expected fro most of your traffic. Test in incognito where the browser doesn't accept 3rd party cookies like safari/incognito etc.

[skhcg]

See the attached images. ECID remains same.

[Sumit-Kumar]

mid is visible only in ECID2.png, not in ECID1.png. vidAPI looks like a custom Allstate implementation, maybe for visitor ID. But yes as long as MID is present and is the same, the ECID service is working.

[Jennifer_Dungan]

MID can also appear if the Visitor ID Service is half working... but that I mean that the call to the Visitor ID service is made, and an MID is set, but if the cookie fails to save, it will only work so long as you are on the one domain in the one visit... 

So making sure the s_ecid cookie is actually set is very important... but like I said, I did see it in my testing... but bots may be restricting cookies, which might result in that behaviour...

And given the odd browser and the AWS IPs... it seems like that might be the case...