Phoenix reduce the impact of Safari ITP on your cookies.
The Intelligent Tracking Protection (ITP) feature of Safari browsers reduces the duration of most 1st party cookies to one day. ITP was initially implemented to reduce the effectiveness of cross domain visitor tracking—unfortunately it also has a strong impact on the user experience of website users. 1st party cookies are often used to store user settings of important features of a website.
e.g. cookie banner use 1st party cookies to store consent settings of a website visitor. On Safari these cookies might only last for one day. Thus cookie banner show up on almost any consecutive website visit, asking the visitor for his privacy settings again and again.
Phoenix enables you to persist 1st party cookies for longer durations to reduce the impact of ITP on your website and business.
To understand how Phoenix works it is important to understand following cookie concepts.
Phoenix allows to persist 1st party cookies without a Secure and HttpOnly flag.
After Phoenix is set up on a website domain it will backup selected 1st party cookies that are affected by ITP by storing them in Secure Http cookies that are not affected by ITP.
Phoenix will check if a 1st party cookie was deleted and recreate it from its backup on further website visits. Therefore the 1st party cookie is not anymore affected by ITP.
Phoenix setup consists of following steps. A Commanders Act consultant will support you during setup.
Phoenix has to run on your website domain to be able to create Secure Http cookies. Therefore you will need to assign a subdomain of your domain (e.g. phoenix.mydomain.com) to Phoenix.
In case you want to activate Phoenix for multiple domains (e.g. two domains, one .com for an English site and .fr for a French site.) you need to create one subdomain per domain.
Your administrator can configure your Phoenix subdomains in your Commanders Act interface under Admin > Domain Management.
Browsers, like Safari, can usually store a maximum of 8 kB of cookie data per domain. Web servers also have a cookie data limit, often matching the 8 kB of browsers.
Your administrator can configure how much cookie space he wants to make available for Phoenix in your Commanders Act interface under Admin > Domain Management. It is recommended to not exceed 2 kB, and we suggest a limit below 0.5 kB during initial setup.
Exceeding cookie storage limit can make your website inaccessible. Please consult with your technical teams during setup to define an optimal storage quota for Phoenix.
You will then need to connect your Phoenix subdomains with the Phoenix service. Your domain administrator needs to therefore declare the tracking domain in Cloudflare, or your WAF, that point your Phoenix subdomains (e.g. phoenix.mydomain.com) to the Phoenix service domain (e.g. sitexxx.commander5.com).
If you have any questions about how to configure your reverse proxy, check this dedicated documentation
Your administrator can find the Phoenix service domain in your Commanders Act interface under Admin > Domain Management.
You have to re-generate your web containers (Commanders Act TMS) after enabling Phoenix.
Commanders Act cookies are automatically managed by Phoenix. Cookies of other vendors have to be configured manually.
In TMS Commanders Act, cookies are usually set by your vendor tags. You can enable Phoenix for selected tags in the "Deployment" step of your Commanders Act TMS container by enabling the ITP BYPASS option. This will automatically persist all cookies of this tag with Phoenix. A progress bar will show the remaining cookie space made available by your administrator.
Please contact the Commanders Act support or your Commanders Act consultant in case the ITP BYPASS option is not available for a tag or cookie you would like to persist.
Please contact your Commanders Act consultant in case you would like to persist cookies outside of Commanders Act TMS or in case you would like to install Phoenix without Commanders Act TMS.
List of partners for which we operate a cookie synchronization (cookie sync) in order to match users and activate them on partners networks.
AB Tasty
Criteo
Freespee
Appnexus
Realytics
Optimizely
Adventori
Yahoo
PublicIdees
Effinity
RhythmOne
Prediggo
Experian
Zendesk
Bluekai
Google DBM / Adwords
IBM
Adotmob
Sirdata
Squadata
Temelio
Eperflex
Axciom - Liveramp
Adition
Rakuten - Nextperf
Cabestan
Graphinium
Vortex
Adobe
Deutschepost
Golden Bees
Invibes
The Trade Desk
Taboola
An overview of cookies used by the Commanders Act platform.
The technical session cookies for First party domain tracking have been renamed. ("PHOENIX" replaced by "FIRST" in the cookie name) - 06/05/2024 16:01
Following cookies are used automatically in depending on the installed Commanders Act products.
Users can create custom cookies with TMS Commanders Act. For example it is possible to store a URL parameter on a landing page in a cookie to make it available for further pageviews in the session. Users can choose their own name and storage duration for these cookies. Therefore it is not possible to include them in this list.
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.
