Option 1 : Reverse Proxy DNS
Fonctionnement
En utilisant un reverse proxy, vous forcez le trafic de votre serveur de tracking à passer via le DNS de votre site de navigation. Les IP du serveur de votre site de navigation (example.com) et de votre serveur de tracking (tagging.example.com) n’apparaitront donc plus lors de la dépose de cookies sur le navigateur de l’utilisateur = seul l’IP de votre reverse proxy sera apparent. Ainsi, lors d’un check du navigateur sur l’IP de votre serveur de navigation et sur l’IP de votre serveur de tracking, ces IP seront exactement identiques. Les cookies déposés par votre serveur de tracking seront donc considérés comme des cookies first-party, et leur durée de vie sera bien de 13 mois.
Ci-dessous nous listons plusieurs solutions logicielles possibles. Renseignez vous auprès de votre équipe en interne si vous utilisez déjà l’une d’elle. Cela vous aidera à choisir la meilleure option pour continuer à maintenir vos cookies dans la nouvelle version de Safari.
Choix de la Solution
Cloudflare
Reverse Proxy via Sous-domaine
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
-
Allez sur votre compte Cloudflare.
-
Sélectionnez votre site sur l’interface.
-
Allez sur SSL/TLS puis Overview, et assurez vous que le mode de chiffrement soit en Complet ou Complet (Strict).
Si ce n’est pas le cas, il est possible de créer une règle de configuration pour être en Complet, uniquement sur le domaine de tagging.
-
Allez sur SSL/TLS et sélectionnez Serveur d’origine.
-
Cliquez sur Créer un certificat, et laissez les options par défaut.
-
Dans la section Noms d’hôte, entrez le domaine défini dans Addingwell, par exemple : metrics.example.com.
- Cliquez sur Créer.
Une fois que vous avez créé le certificat, Cloudflare vous fournira le certificat ainsi que la clé privée, gardez les pour les utiliser ultérieurement. Veuillez noter que la clé privée ne sera donnée qu’une seule fois.
- Dans votre Container sur app.addingwell.com, sous Dashboard > Domains, et sur votre domaine, sélectionnez Set reverse-proxy.
- Remplissez les champs avec votre certificat et la clé fournis par Cloudflare précédemment.
- Une fois les certificats enregistrés, vous devriez voir apparaitre une icône à coté de votre domaine.
- De retour sur Cloudflare, dans le menu de gauche, sélectionnez DNS et activez le proxy Cloudflare sur l’enregistrement DNS correspondant au domaine lié à Addingwell.
Reverse Proxy via Chemin
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy Cloudflare ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Premières étapes
- Dans le tableau de bord Cloudflare, sélectionnez votre domaine et confirmez que :
- Le domaine est proxifié via Cloudflare (nuage orange sur l’enregistrement DNS pour example.com)
- SSL/TLS → Aperçu est réglé sur Complet ou Complet (strict)
- Règles → Paramètres → Normalisation d’URL ne supprime ni ne trie les paramètres de requête (Addingwell nécessite que les paramètres de requête soient préservés inchangés).
Configurez le reverse proxy avec un Cloudflare Worker :
Création du Worker
Le Worker intercepte les requêtes correspondant à votre chemin de mesure, supprime le préfixe du chemin, définit les en-têtes requis et transfère la requête vers la destination Addingwell.
- Dans le tableau de bord Cloudflare, allez dans Workers & Pages → Créer → Créer un Worker. Donnez-lui un nom tel que
addingwell-reverse-proxyet cliquez sur Deploy pour créer un Worker vide.
Les Workers peuvent générer des coûts d’utilisation Cloudflare au-delà du quota inclus dans le plan Free. Consultez la page de tarification Cloudflare pour les tarifs en vigueur si votre trafic dépasse le quota inclus.
-
Sur la page du Worker déployé, cliquez sur Modifier le code et remplacez le contenu du fichier par le code JavaScript suivant :
export default { async fetch(request) { const url = new URL(request.url); const originalHost = url.hostname; // Strip the /w3ke4d prefix; the trailing /? makes /w3ke4d, // /w3ke4d/ and /w3ke4d/anything all resolve correctly. url.pathname = url.pathname.replace(/^\/w3ke4d\/?/, "/"); // Route the request to the Addingwell destination const destination = "example.adding-sst.com"; url.hostname = destination; // Forward the original host so Addingwell knows the first-party domain, // and the real client IP so Addingwell can geolocate the end user // (Cloudflare would otherwise hide it behind the edge IP). const newRequest = new Request(url, request); newRequest.headers.set("Host", destination); newRequest.headers.set("x-forwarded-host", originalHost); newRequest.headers.set("true-client-ip", request.headers.get("CF-Connecting-IP")); return fetch(newRequest); }, };Remplacez w3ke4d avec le chemin choisi à l’Étape 1 et example.adding-sst.com avec le domaine que nous vous avons partagé à l’Étape 2.
-
Cliquez sur Deploy pour publier le worker.
Lier le Worker à votre domaine et à votre chemin
-
Toujours sur la page du Worker, ouvrez Settings → Domains & Routes → Add → Route.
-
Réglez :
- Zone : le domaine sur lequel le reverse proxy prendra effet, e.g. example.com
- Route : example.com/w3ke4d/* (remplacez avec le domaine de votre site et le chemin que vous avez choisi à l’Étape 1)
-
Cliquez sur Save. Le Worker est maintenant actif et intercepte chaque requête qui correspond à ce chemin.
Contourner la mise en cache pour le chemin de mesure
Les points de terminaison de suivi ne doivent pas être mis en cache.
-
Allez sur Caching → Règles de Cache et cliquez sur Créer une règle.
-
Choisissez un nom pour la règle, comme
Addingwell bypass cache. -
Sous « If incoming requests match… », choisissez Custom filter expression puis sélectionnez :
- Champ :
URI Path - Opérateur :
commence par - Valeur : /w3ke4d (remplacez par le chemin que vous avez choisi)
- Champ :
-
Sous « Then… », réglez Cache eligibility sur
Bypass cache. -
Sauvegardez puis déployez ces changements.
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy, la page doit :- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
Akamai
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy Cloudfront ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Changer l’Origine
-
Allez sur votre page Cloudfront dans Amazon Web Services.
-
Sélectionnez votre distribution Cloudfront.
-
Dans l’onglet Origins, créez une nouvelle origine avec les paramètres suivants :
- Réglez Origin domain sur le domaine que nous vous avons partagé à l’Étape 2, au format example.adding-sst.com.
- Réglez le Protocol sur HTTPS Only.
- Sous Add custom header, ajoutez un header avec Header name
x-forwarded-hostet Header value réglé sur votre domaine first-party, e.g. example.com. Cela transmet l’hôte d’origine au serveur Addingwell, ce que Cloudfront ne fait pas nativement avec la politique de requête d’origineAllViewerExceptHostHeader. Pour l’IP de l’utilisateur final, Cloudfront renseigne automatiquementX-Forwarded-Foravec l’IP du visiteur.
Créer le comportement de redirection
-
Revenez sur votre distribution Cloudfront, en sélectionnant cette fois l’onglet Behaviors, et créez-en un nouveau.
-
Réglez Path pattern sur le chemin que vous avez défini à l’Étape 1 (par exemple, nous utilisons ici /w3ke4d/*).
Le préfixe de chemin (e.g. /w3ke4d) doit être supprimé lors du transfert de la requête vers le domaine de destination d’Addingwell (e.g. example.adding-sst.com). Le chemin restant doit être préservé au complet. Par exemple : /w3ke4d/test/collect doit être transmis comme : /test/collect
-
Réglez Origin and origin groups sur le domaine que nous vous avons partagé à l’Étape 2, au format example.adding-sst.com.
-
Pour l’option Compress objects automatically sélectionnez No.
-
Réglez la Viewer protocol policy sur HTTPS only.
-
Pour Allowed HTTP Methods choisissez GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE.
-
Dans Cache key and origin requests choisissez Cache policy and origin request policy
- En réglant Cache policy sur CachingDisabled.
- et Origin request policy sur AllViewerExceptHostHeader.
-
Dans la liste de vos Behavior, vérifiez la précédence du comportement nouvellement créé et assurez-vous qu’il soit plus haut que tous les autres.
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy, la page doit :- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
NGINX
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy Akamai ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Changer l’Origine
-
Créez une nouvelle version de votre delivery configuration dans le gestionnaire de propriété.
-
Sous la section Property Configuration Settings sélectionnez add a new Rule. Nommez-la, par exemple, Measurement Path.
-
Ajoutez un nouveau Match, et réglez le menu match dropdowns sur Path et is one of.
-
Ensuite, choisissez pour match value le chemin défini à l’Étape 1, par exemple /w3ke4d/*.
Le préfixe de chemin (e.g. /w3ke4d) doit être supprimé lors du transfert de la requête vers le domaine de destination d’Addingwell (e.g. example.adding-sst.com). Le chemin restant doit être préservé au complet. Par exemple : /w3ke4d/test/collect doit être transmis comme : /test/collect
-
Ajoutez un nouveau Behavior et sélectionnez Standard Property Behavior, puis prenez Origin Server comme option.
-
Pour Origin Server Hostname inscrivez la valeur que nous vous avons partagée à l’Étape 2, au format example.adding-sst.com.
-
Réglez Forward Host Header sur Origin Hostname.
-
Sous Origin SSL Certificate Verification, réglez Match CN/SAN sur « {{Origin Hostname}} », et aussi sur la valeur que nous vous avons partagée à l’Étape 2, au format example.adding-sst.com.
-
Ajoutez un comportement Modify Outgoing Request Path. Réglez Action sur
Remove fixed path segment, et le paramètre Path segment to remove sur le chemin que vous avez choisi à l’Étape 1, ici /w3ke4d. -
Ajoutez un comportement Modify Outgoing Request Header pour transmettre l’hôte d’origine. Réglez Action sur
Add, puis Custom header name surx-forwarded-host, avec Header value sur{{builtin.AK_HOST}}, et définissez Avoid duplicate headers surOn. -
Ajoutez un autre comportement Modify Outgoing Request Header pour transmettre l’IP de l’utilisateur(ice) final(e). Réglez Action sur
Add, Custom header name surtrue-client-ip, Header value sur{{builtin.AK_CLIENT_IP}}, et définissez Avoid duplicate headers surOn.
Il ne faut pas que des règles viennent modifier ou supprimer les en-têtes des requêtes sortantes. Cela pourrait causer des erreurs avec les scripts Google si l’en-tête de réponse Content-Type est absent.
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy,la page doit :
- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
Fastly
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy GCP ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Changer les Règles de Backend
-
Ouvrez le GCP load balancer, puis la section Backend configuration. Cliquez ensuite sur Create a new backend service.
-
Pour commencer à configurer, spécifiez un nom, par exemple, « measurement-path ».
-
Pour Backend type, sélectionnez Internet network endpoint group.
-
Pour Protocol, sélectionnez HTTPS et laissez Timeout comme valeur par défaut.
-
Dans Backends, sélectionnez le menu déroulant Internet network endpoint group et créez-en un nouveau.
-
Pour Network endpoint group type, sélectionnez Internet NEG (Global, Regional), réglez l’option Scope sur Global et l’option Add through sur Fully qualified domain name and port.
-
Pour Fully qualified domain name, inscrivez le domaine que nous vous avons partagé à l’Étape 2 en tant que hostname (sans préfixe protocole), e.g. example.adding-sst.com.
-
Cliquez sur CREATE pour créer l’endpoint, et fermez l’onglet Network endpoint group pour revenir sur le New backend service.
-
Cherchez ensuite le nom du new network endpoint group précédemment choisi à l’Étape 4, sélectionnez-le et ouvrez la section Advanced configurations. Ajoutez les en-têtes de requêtes suivants :
- Host, avec comme valeur le domaine que nous vous avons partagé à l’Étape 2, au format example.adding-sst.com.
- x-forwarded-host, avec comme valeur votre domaine, comme par exemple example.com.
- true-client-ip avec la valeur
{client_ip_address}, le placeholder GCP pour cet en-tête custom.
-
Sauvegardez les changements de configuration.
Règles de Routing
-
Retournez sur GCP load balancer, en ouvrant cette fois-ci la section Routing rules.
-
Ajoutez les règles host et path suivantes :
- Host : *
- Path : le chemin choisi à l’Étape 1, (e.g. /w3ke4d) avec le format /w3ke4d/*
- Backend : le nom de backend choisi à l’Étape 4
-
Toujours dans la section Routing rules, développez la règle path que vous venez de créer et ouvrez Advanced URL rewrite. Définissez ensuite Path prefix rewrite sur
/.
Le préfixe de chemin (e.g. /w3ke4d) doit être supprimé lors du transfert de la requête vers le domaine de destination d’Addingwell (e.g. example.adding-sst.com). Le chemin restant doit être préservé au complet. Par exemple : /w3ke4d/test/collect doit être transmis comme : /test/collect
- Cliquez sur Update et sauvegardez la configuration dans le load balancer.
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy,la page doit :
- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
undefined
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy NGINX ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Changer la configuration
- La configuration suivante est un exemple avec NGINX pour le domaine example.com, avec un chemin de mesure choisi comme example.com/w3ke4d. Les différentes occurrences de ces éléments doivent être remplacées par votre domaine, le chemin choisi et le domaine que nous avons partagé à l’Étape 2. Si votre tracking en server side est déjà en place, certaines parties ci-dessous ne sont pas nécessaires, par exemple car les certificats SSL pourraient déjà avoir été mis en place. Au besoin, nous listons dans la section d’après les exigences techniques pour une bonne implémentation.
server {
listen 443 ssl http2;
server_name www.example.com;
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem; # managed by Certbot
location /w3ke4d {
proxy_pass https://example.adding-sst.com/;
proxy_ssl_server_name on;
proxy_ssl_name example.adding-sst.com;
proxy_set_header true-client-ip $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host 'www.example.com';
}
}Si votre nginx sert plusieurs vhosts dans la même configuration, vous pouvez substituer $host à la valeur en dur de l’en-tête Host ci-dessus pour que l’en-tête Host d’origine soit transmis dynamiquement à chaque requête.
Configurations Requises
-
Les méthodes HTTP suivantes doivent être prises en charge :
GET, POST, OPTIONS -
Concernant les En-têtes (Headers) :
- L’adresse IP de l’utilisateur final doit être transmise dans l’en-tête : true-client-ip
- L’hôte d’origine (par exemple, example.com, et non le domaine de destination Addingwell partagé à l’Étape 2, c.-à-d. example.adding-sst.com) doit être transmis : x-forwarded-host
-
Si une mise en cache est activée sur votre proxy :
- Le cache du proxy doit respecter les en-têtes cache-control d’Addingwell.
- La clé de cache doit inclure tous les paramètres des requêtes.
- Concernant les paramètres de requête, ils doivent donc :
- Ne pas être modifiés
- Ne pas être réordonnés
- Ne pas se voir ajouter de paramètres supplémentaires
-
Tous les Cookies doivent être transmis sans modification.
-
Lorsque le proxy inverse est exposé via un chemin (par exemple, example.com/w3ke4d/) :
- Le préfixe de chemin (par exemple, /w3ke4d) doit être supprimé lors du transfert de la requête vers le domaine de destination d’Addingwell (par exemple, le domaine partagé à l’Étape 2 au format example.adding-sst.com).
- Le chemin restant doit être préservé au complet.
- Exemple : /w3ke4d/test/collect doit être transmis comme : /test/collect
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy,la page doit :
- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
undefined
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy Apache ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Changer la configuration
- La configuration suivante est un exemple avec Apache (2.4+) pour le domaine example.com, avec un chemin de mesure choisi comme example.com/w3ke4d. Les différentes occurrences de ces éléments doivent être remplacées par votre domaine, le chemin choisi et le domaine que nous avons partagé à l’Étape 2. Si votre tracking en server side est déjà en place, certaines parties ci-dessous ne sont pas nécessaires, par exemple car les certificats SSL pourraient déjà avoir été mis en place. Au besoin, nous listons dans la section d’après les exigences techniques pour une bonne implémentation.
<VirtualHost *:443>
ServerName www.example.com
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/www.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem
SSLProxyEngine on
ProxyPreserveHost Off
ProxyPass "/w3ke4d/" "https://example.adding-sst.com/"
ProxyPassReverse "/w3ke4d/" "https://example.adding-sst.com/"
<Location "/w3ke4d/">
RequestHeader set true-client-ip "expr=%{REMOTE_ADDR}"
RequestHeader set X-Forwarded-Host "www.example.com"
</Location>
</VirtualHost>Cette configuration s’appuie sur les modules proxy, proxy_http, ssl et headers. Activez-les si besoin avec sudo a2enmod proxy proxy_http ssl headers, puis rechargez Apache.
Si ce virtual host sert plusieurs domaines, vous pouvez substituer expr=%{HTTP_HOST} à la valeur en dur de l’en-tête X-Forwarded-Host ci-dessus pour que l’hôte d’origine soit transmis dynamiquement à chaque requête. Conservez ProxyPreserveHost Off (la valeur par défaut) : l’en-tête Host envoyé à la destination doit être le endpoint Addingwell, pas votre domaine.
Configurations Requises
-
Les méthodes HTTP suivantes doivent être prises en charge :
GET, POST, OPTIONS -
Concernant les En-têtes (Headers) :
- L’adresse IP de l’utilisateur final doit être transmise dans l’en-tête : true-client-ip
- L’hôte d’origine (par exemple, example.com, et non le domaine de destination Addingwell partagé à l’Étape 2, c.-à-d. example.adding-sst.com) doit être transmis : x-forwarded-host
-
Si une mise en cache est activée sur votre proxy :
- Le cache du proxy doit respecter les en-têtes cache-control d’Addingwell.
- La clé de cache doit inclure tous les paramètres des requêtes.
- Concernant les paramètres de requête, ils doivent donc :
- Ne pas être modifiés
- Ne pas être réordonnés
- Ne pas se voir ajouter de paramètres supplémentaires
-
Tous les Cookies doivent être transmis sans modification.
-
Lorsque le proxy inverse est exposé via un chemin (par exemple, example.com/w3ke4d/) :
- Le préfixe de chemin (par exemple, /w3ke4d) doit être supprimé lors du transfert de la requête vers le domaine de destination d’Addingwell (par exemple, le domaine partagé à l’Étape 2 au format example.adding-sst.com).
- Le chemin restant doit être préservé au complet.
- Exemple : /w3ke4d/test/collect doit être transmis comme : /test/collect
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy,la page doit :
- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
undefined
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy via Fastly ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Condition et Hôte
-
Créez une nouvelle Condition avec les réglages suivants : pour Type, sélectionnez Request, pour Name, choisissez Measurement Path (ou un autre nom si vous le souhaitez), et pour l’option Apply if…, renseignez req.url.path ~ ”^/w3ke4d” en remplaçant w3ke4d par le chemin choisi à l’Étape 1.
-
Créez ensuite un nouvel Host et remplissez le champ Host name/Address avec le domaine que nous vous avons partagé à l’Étape 2, au format example.adding-sst.com.
-
Toujours pour ce nouvel Host, cliquez sur Attach a condition et sélectionnez la Condition créée à l’Étape 3.
-
Enfin, pour l’option Set Override host, renseignez le domaine que nous vous avons partagé à l’Étape 2, au format example.adding-sst.com. Laissez tous les autres réglages par défaut et cliquez sur Update pour sauvegarder le Host.
-
Toujours dans la configuration de votre service Fastly, ouvrez Content puis Headers et créez trois nouveaux headers, chacun avec Condition définie sur la condition créée à l’Étape 3 (par exemple Measurement Path).
-
Premièrement, pour supprimer le préfixe du chemin, définissez Type sur Request, Action sur Set, Destination sur url, et dans Source, saisissez
regsub(req.url, ”^/w3ke4d/?”, ”/”)(remplacez w3ke4d par le chemin que vous avez choisi). -
Ensuite, pour transmettre l’IP réelle du client, définissez Type sur Request, Action sur Set, Destination sur http.true-client-ip et Source sur client.ip.
-
Troisièmement, pour transmettre le host d’origine, définissez Type sur Request, Action sur Set, Destination sur http.x-forwarded-host et Source sur req.http.host.
-
Pour finir, activez la nouvelle version du service.
Configurations Requises
-
Les méthodes HTTP suivantes doivent être prises en charge :
GET, POST, OPTIONS -
Concernant les En-têtes (Headers) :
- L’adresse IP de l’utilisateur final doit être transmise dans l’en-tête : true-client-ip
- L’hôte d’origine (par exemple, example.com, et non le domaine de destination Addingwell partagé à l’Étape 2, c.-à-d. example.adding-sst.com) doit être transmis : x-forwarded-host
-
Si une mise en cache est activée sur votre proxy :
- Le cache du proxy doit respecter les en-têtes cache-control d’Addingwell.
- La clé de cache doit inclure tous les paramètres des requêtes.
- Concernant les paramètres de requête, ils doivent donc :
- Ne pas être modifiés
- Ne pas être réordonnés
- Ne pas se voir ajouter de paramètres supplémentaires
-
Tous les Cookies doivent être transmis sans modification.
-
Lorsque le proxy inverse est exposé via un chemin (par exemple, example.com/w3ke4d/) :
- Le préfixe de chemin (par exemple, /w3ke4d) doit être supprimé lors du transfert de la requête vers le domaine de destination d’Addingwell (par exemple, le domaine partagé à l’Étape 2 au format example.adding-sst.com).
- Le chemin restant doit être préservé au complet.
- Exemple : /w3ke4d/test/collect doit être transmis comme : /test/collect
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy,la page doit :
- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
undefined
Une fois le reverse proxy mis en place et en production, votre tracking pourra être interrompu pour un moment jusqu’à ce que les changements se propagent. Nous recommandons donc d’effectuer ces changements hors périodes critiques.
Mise en place détaillée
- Réservez un chemin de mesure unique sur le domaine de votre site web pour chaque domaine sur Addingwell auquel vous souhaitez appliquer un reverse proxy. Pour le site web example.com, réservez par exemple : example.com/w3ke4d
Le(s) chemin(s) choisi(s) ne doivent pas déjà être utilisé(s) sur votre domaine, ne doivent pas être le chemin à la racine ”/” et ne pas excéder 100 caractères. Pour éviter au maximum les bloqueurs de pubs, évitez de choisir des chemins un peu trop transparents comme /metrics, /ads, etc…
-
Contactez-nous à [email protected] en mentionnant le nom de votre conteneur, le domaine sur lequel vous configurez le reverse proxy, le chemin de mesure choisi, et ajoutez l’objet « Configuration du Reverse Proxy + le nom du fournisseur que vous souhaitez utiliser (e.g. Cloudfront, Nginx, etc) ».
Nous vous retournerons une valeur sous le format example.adding-sst.com, conservez-la. Elle sera configurée de notre côté et utilisée comme le endpoint de destination pour la configuration du reverse proxy.
Configurations Requises
-
Les méthodes HTTP suivantes doivent être prises en charge :
GET, POST, OPTIONS -
Concernant les En-têtes (Headers) :
- L’adresse IP de l’utilisateur final doit être transmise dans l’en-tête : true-client-ip
- L’hôte d’origine (par exemple, example.com, et non le domaine de destination Addingwell partagé à l’Étape 2, c.-à-d. example.adding-sst.com) doit être transmis : x-forwarded-host
-
Si une mise en cache est activée sur votre proxy :
- Le cache du proxy doit respecter les en-têtes cache-control d’Addingwell.
- La clé de cache doit inclure tous les paramètres des requêtes.
- Concernant les paramètres de requête, ils doivent donc :
- Ne pas être modifiés
- Ne pas être réordonnés
- Ne pas se voir ajouter de paramètres supplémentaires
-
Tous les Cookies doivent être transmis sans modification.
-
Lorsque le proxy inverse est exposé via un chemin (par exemple, example.com/w3ke4d/) :
- Le préfixe de chemin (par exemple, /w3ke4d) doit être supprimé lors du transfert de la requête vers le domaine de destination d’Addingwell (par exemple, le domaine partagé à l’Étape 2 au format example.adding-sst.com).
- Le chemin restant doit être préservé au complet.
- Exemple : /w3ke4d/test/collect doit être transmis comme : /test/collect
Vous utilisez notre contournement des bloqueurs de publicité ? Vous pouvez mettre en cache ses fichiers, voir (Optionnel) Contournement des bloqueurs de publicité ci-dessous.
Vérifier l’Installation
-
En allant sur */chemin-choisi/healthy, par exemple
https://example.com/w3ke4d/healthy, la page doit afficher : ok -
En allant sur */chemin-choisi/transformer/reverse-proxy, par exemple
https://example.com/w3ke4d/transformer/reverse-proxy,la page doit :
- Afficher votre IP dans « currentIp »
- Afficher l’hôte actuel dans « host »
- Si des cookies sont présents et passés dans la requête, ils ne doivent pas être modifiés
Voici par exemple une requête pour le tester :
curl --location 'https://example.com/w3ke4d/transformer/reverse-proxy' \ --header 'Cookie: gtm_preview=test123' \ --header 'Origin: example.com'La réponse ressemblera à :
{ "currentIp": "X.X.X.X", "origin": "www.example.com", "host": "www.example.com", "cookieGtmPreview": "test123" }Pour host, le domaine ressemblant à example.adding-sst.com ne doit pas s’afficher.
-
En allant sur
https://example.com/w3ke4d/g/collect?tid=G-XXXXXXXX&v=2&en=page_view&richsstsse. C’est pour essayer d’envoyer de la « vraie » donnée via le chemin de collecte. En réponse, un 200 (au moins, en fonction de votre configuration vous pourriez avoir plus).
Implémentez ces changements pour envoyer vos données via ce chemin
Maintenant que le reverse proxy est configuré, il ne reste plus qu’à propager ces changements pour que les données soient envoyées via ce nouveau chemin créé.
Balise de configuration Google
Pour ce faire, nous devrons ajouter ou modifier le paramètre server_container_url dans votre conteneur web GTM, pour indiquer la nouvelle destination vers le serveur pour votre transporteur de données.
Sélectionnez votre balise de configuration Google, et ajoutez ou modifiez le paramètre server_container_url pour qu’il reflète la destination avec votre domaine/votre chemin, par exemple example.com/w3ke4d
Prévisualisation Côté Serveur
Dans votre conteneur serveur GTM, si vous devez effectuer des tests avant de déployer les modifications, vous devrez également modifier l’URL du serveur.
Dans Admin (en haut à gauche), sélectionnez Container Settings à droite et ajoutez l’URL au serveur, au format https://example.com/w3ke4d
(Optionnel) Contournement des bloqueurs de publicité
Si vous utilisez ou souhaitez utiliser notre CDN pour contourner les bloqueurs de publicité, il existe un snippet que vous pouvez utiliser pour charger tous les composants dont vous avez besoin pour le tracking en utilisant des URL indétectables. Consultez notre documentation associée pour plus d’informations.
Si vous avez suivi ce guide pour implémenter un reverse proxy, ce snippet doit être modifié pour refléter les changements.
Normalement, dans cet onglet CDN, vous pouvez trouver dans le snippet une ligne ressemblant à https://w3ke4d.example.com/a1b2c3d4e5f6g7h8.js…
Remplacez w3ke4d.example.com par votre domaine et le chemin choisi, comme example.com/w3ke4d.
Cela garantira que vous chargez le GTM via le reverse proxy que nous venons de configurer et que vous contournez tous les bloqueurs de publicité du marché.
Note sur le cache : si vous utilisez notre contournement des bloqueurs de publicité et souhaitez réduire les requêtes CDN associées, envisagez d’ajouter une règle pour que les fichiers statiques *.js soient servis depuis le cache de votre fournisseur. Attention : tout cache doit respecter les en-têtes cache-control d’Addingwell et utiliser une clé de cache incluant tous les paramètres de requête, sans modification, afin de ne pas affecter les requêtes de tracking. Nous recommandons une durée de cache plutôt courte (10 min à une heure), car les fichiers concernés incluent votre conteneur GTM web : un cache trop long retardera la mise en production de vos modifications GTM web.
Pour toute question, contactez-nous à [email protected], nous serons ravis de vous aider !