First-party cookies are stored by the domain (website) you are visiting directly. They allow website owners to collect analytics data, remember language settings, and perform other useful functions that help provide a good user experience.
Third-party cookies are created by domains other than the one you are visiting directly, hence the name third-party. They are used for cross-site tracking, retargeting and ad-serving.
Until now all the data collected on a website was done mainly by tags, 3rd party tags, because the data is pushed to external servers (not owned by the brand but by some partners).
Major browsers, such as Safari or Google Chrome, decided to not allow anymore 3rd party cookies. That means they will block cookies not coming from the brand itself but coming from partners (such as Commanders Act). They will detect all data flux pushed to a domain not related to the brand (3rd party domains).
As a result, the workaround to continue to track and push data from websites to partners, is to use a domain owned by the brand, a first party domain. And the cookies should be set by this domain, this is what is called ‘1st party cookie’ because it seems to be generated by the brand itself and not from partners.
There is a technical setup to do to initialize this 1st party tracking (on the domain level first and then on the cookie level).
In the customer's DNS, the use of a CNAME pointing to a Commanders Act server allows to set cookie as a first party.
The customer should create a subdomain and setup CNAME entries to point to our server (and create as many subdomains as existing domains). Example:
client.com creates a subdomain XYZ.client.com pointing to Commanders Act server. From now on, our tags will now call XYZ.client.com instead of our 3rd party domain (commander1) and response will set a cookie on main domain .client.com which is allowed by main web browsers.
Then please indicate the subdomain on our platform: Administration > Domain Management.
The customer must decide if the SSL encryption on the new subdomain they created is done with ‘Let’s Encrypt’ or with their own certificate. In the former case, nothing to do; in the latter case follow the instruction on the domain management page.
Moreover change on every tag the URL to specify the 1st party domain.
Put in place the Mixcommander tags as you would normally do, but this time use the the tags marked COOKIE 1ST V1.0
In the #CUSTOMER_SUBDOMAIN# placeholder you need to enter the subdomain agreed with the customer.
At this point it’s time to test the hits . ATTENTION the structure of the redirection URL is different from the usual MixCo.
before it was : http://client.commander1.com/c3/?tcs=13&chn=sem&src=google&url=https://domain.client.com/en/13/campaign/trafficking
Now it is : https://client.subdomain.com/mix/c3/?tcs=13&chn=sem&src=google&url=https://domain.client.com/en/13/campaign/trafficking
There are 2 possible situations that we can encountered:
Users with an existing cookie 1st
This is the target configuration when cookies 3rd will disappear.
The browser will push the cookie to the 1st party domain, this one will recognize the cookie and update it and then push it to the browser. Then the data related to the cookie is sent to our system.
Users without an existing cookie 1st
This case is hybrid, as we will work with both 1st and 3rd party domains to keep a continuity of shared information between the 2 servers.
For this case we have users without cookies known by the 1st party domain.
The browser will push the data to the 1st party domain, and we will request on the 3rd party domain all the information we have regarding this user (does a cookie already exist?). The 3rd party domain will push this information (if it exists). Then the 1st party domain will setup the cookie (or create a new one) and the data is pushed to our system.
Now it’s possible to use a combination of first and third party cookies (create a ticket to ask MIX team to activate this option) - available only for the transition.
