aka CloudFlare proxy
Setup a reverse proxy DNS on a WAF like CloudFlare is an easy and reliable way for tracking purposes using 1st party cookies.
Contact your account manager for more details.
1. In Cloudflare (or your WAF), declare the tracking domain to be used and point it to our infra (for ex. waf.myshop.com) and point it to the endpoint we've defined for the proxy:
ca-trk-proxy.commander1.com
2. On the DNS side, point your tracking domain (ex. waf.myshop.com) to Cloudflare (the CNAME is provided by cloudflare).
Declare the domain
Use our interface Domain Management to declare this domain and adjust the way Commanders Act collect the datas
Administration > Domain Management
Activate the domain Turn ON the option "Containers Integration" will allow the domain to be included in the container configuration.
All Commanders Act tags will switch to first party collection.
This action will affect Consent, Deduplication, Campaign, Segment, Server Side
What happens when I have 2 or more domains?
It prioritizes the domain of the website where the container is loaded. If no domain matches the domain of the website, the 1st in the list is used.
At this point, WebContainers and Privacy banners should be regenerated and deployed.
If applicable, adjust your existing tracking to reflect your new tracking domain. For example on a View Campaign tracking hit: https://waf.myshop.com/mix/v3/?firsttime=1&tcs=5039&chn=referrer&src=referrer_3&user_id=96177&TCID=96177&cmp=Promotionnal+game&cty=Italy
Improve the way you collect data with Commanders Act by using a first party approach.
The Domain Management Interface is the key to optimize your data collection configuration.
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, rettargeting 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).
5 methods are possible:
WAF proxy: easy to setup if you have a WAF like CloudFlare. The recommended method
CNAME record combined with cookie CAID: still useful for Adblockers
A record combined with cookie CAID: not the best solution anymore, but still useful for Adblockers
On-premise Proxy: more technical but preferred by some IT team. As efficient as WAF proxy.
CNAME record or A record without setting cookie CAID: not recommended but still useful for Adblockers.
Migration from 3rd party to 1st can be handled with Commanders Act consultants.
The A record is a solution for tracking purposes using 1st party cookies. You need to combine A record with the CAID on-premise cookie to get the most out of it.
A record?
A record (A for Address) is a DNS record type. It is a match between a domain and an IP address. It points the hostname to the IP address.
cs.example.com ⇒ IP Address : 36.283.49.384
Since there is a link between the domain and the IP address, we need to have control over it. Otherwise, it would be very complicated for maintenance: we will have to ask customers to change their configuration each time we want to upgrade the platform.
We therefore ask customers to delegate part of their DNS to us. This means that we will be able to configure the corresponding IP address for the delegated domain.
The process is quite simple, on Administration / Domain Management interface, click on 'Add subdomain' to add a domain name that will be delegated. Select A record and select how to provide the certificate:
Use Let's Encrypt certificate: with this method, the certificate will be automatically generated. Follow the steps on the interface, no action is required on your side.
Use your own certificate: this will require to provide the following elements:
- The SSL certificate(s) linked to the subdomain(s) entered above - The key of the certificate - The chain of the certificate If you need assistance, please contact the Commanders Act support team.
Customers' DNS should be configured with A record information (ask your IT department).
Click on "Validate configuration" and this will test the DNS configuration.
Click then on "Generate certificates"
Click on "Test configuration" and the setup will be done.
Customers' DNS should be configured with A record information (ask your IT department).
Provide the requested information: - The SSL certificate(s) linked to the subdomain(s) entered above - The key of the certificate - The chain of the certificate If you need assistance, please contact the Commanders Act support team.
Then click on "Validate configuration" and this will test the DNS configuration.
Test the configuration and the setup will be done.
Click on "Containers Integration", this will allow the domain to be included in the container configuration.
All Commanders Act tags will switch to first party collection.
This action will affect Consent, Deduplication, Campaign, Segment, Server Side
At this point, WebContainers and Privacy banners should be regenerated and deployed.
It prioritizes the domain of the website where the container is loaded. If no domain matches the domain of the website, the 1st in the list is used.
1st party collection through your own proxy
The On-Premise Proxy is a feature that orchestrates the communication between your website/app and the Commanders Act platform. A proxy is a sort of intermediary, routing information back and forth between two points—in this case, your website or app and Commanders Act.
The On-Premise Proxy is designed to be installed by your IT team on your own servers. This allows for control and flexibility in managing the data flow between your system and Commanders Act.
For the installation and technical details, your DevOps team can refer to the technical documentation available at the following link:
In the customer's DNS, the use of a CNAME pointing to a Commanders Act server allows to set cookie as a first party.
A CNAME, or Canonical Name, is an entry within the Domain Name System (DNS) that specifies where someone can find your web pages. You'll use the CNAME to associate your custom domain with our products.
Running a domain name is a multi-sided process thanks to the many DNS management possibilities offered by web hosting providers. Most of the hosts today offer multiple options for control over your domain's DNS settings, among them being the CNAME Records.
The customer should create a subdomain and setup CNAME entries to point to our server (and create as many subdomains as existing domains). Example:
Then please indicate the subdomain on our platform: Admin / 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 later case, follow the instruction on the domain management page.
Moreover, change on every tag the URL to specify the 1st party domain.
Click on "Containers Integration", this will allow the domain to be included in the container configuration.
All Commanders Act tags will switch to first party collection.
This action will affect Consent, Deduplication, Campaign, Segment, Server Side
At this point, WebContainers and Privacy banners should be regenerated and deployed.
It prioritizes the domain of the website where the container is loaded. If no domain matches the domain of the website, the 1st in the list is used.
The CAID cookie: your VIP pass for a top level tracking visitors on your website! 🌐 Powered by Commanders Act, the CAID cookie, is your go-to for identifying and tracing a visitor's journey across different browsing sessions.
Its construction is essential, especially in the context of restrictions imposed by privacy and security policies such as ITP (Intelligent Tracking Prevention).
The CAID is automatically created/managed by Commanders Act servers if you choose the proxy method (WAF or on-premise proxy)
You must create it yourself, on your own server, in the case of "First Party" tracking via CNAME or A-Record, but it is not necessary if you use a proxy. In this documentation, you'll find all the information you need to build it.
Ready to elevate your tracking game and conquer the challenges? Dive in, and let's make your On-Premise CAID cookie the superhero of your website! 🚀
When creating your CAID's cookie, apply the following requirements:
"CAID" (in uppercase)
Here are some examples of snippet code to create your On-Premise CAID cookie
You need to combine CNAME with the to get the most out of it.
creates a subdomain pointing to Commanders Act server. From now on, our tags will now call instead of our 3rd party domain (commander1) and response will set a cookie on main domain . which is allowed by main web browsers.
Contains 20 random characters
Preceded by the year the cookie was created
Available on the entire domain and its sub-domains. Accessible client-side and server-side
Cookie's expiry date: maximum 13 months after creation date.
Created by the company server (On-Premise). Deposited on the main domain and all associated sub-domains. (.mydomain.com)
Accessible to all, including servers and JavaScript scripts on the page.