Sign in to Community
Sign in to view all badges
Currently the options are to use either thrid party cookie or first party cookie.
With third party cookie the visitor ID is in sync across domains, but third party cookie support is reduced over time.
With first party cookie the visitor ID is different on different domains, prohibiting correct analysis of unique visitors across multiple domains.
Use first party cookie as default, but use a third party cookie to sync the cookie information across domains.
This way the main functionality is based on FPCs with all advantages. For all users who accept thrid party cookies the information are synced across all domains.
This could also be used to sync cookie information for cross visit pathing, getValOnce information, Timestamps for campaign expiry....
The latest version of the s_code will attempt to set a 3rd party cookie (if your implementation is 3rd party), if it can't set a 3rd party cookie it will set a first party cookie.
There's no syncing of 1st party cookies across domains since this would break the privacy intention around anyone/browser who disables 3rd party cookies.
So you have a kind of hybrid approach. Obviously as more browser block 3rd party cookies your solution moves closer percentage wise to a 1st party cookie implementaton and that also means you loose the ability to de-dupe users across a network as this happens.
Thats true - I only realized yesterday that Mozilla will now block 3rd party cookies as well. Until now this approach worked very good, but it seems that it won't in future