Hier, nous avons cartographié les trois fuites de la mesure : Safari, le consentement refusé et les bloqueurs. Aujourd'hui, la solution, mais sans le marketing du miracle. Le tracking server-side est un vrai gain d'ingénierie, à condition de savoir précisément ce qu'il récupère et ce qu'il ne récupère pas. Trop de discours commerciaux entretiennent la confusion pour vous vendre une promesse intenable. Voici la version honnête.
En mesure classique, le navigateur du visiteur parle directement à Google, à Meta et à votre outil d'analyse. En server-side, on intercale un serveur que vous contrôlez, hébergé sur un sous-domaine de votre site. Le navigateur n'envoie plus les données qu'à ce serveur. Celui-ci filtre selon le consentement, met en forme, puis transmet aux plateformes de serveur à serveur, par des canaux prévus pour ça : le protocole de mesure de Google Analytics pour l'analytique, l'API de conversions de Meta (souvent appelée CAPI) pour la publicité Facebook et Instagram.
Le composant qui orchestre tout cela s'appelle un conteneur GTM côté serveur (Server-Side Google Tag Manager). C'est votre standard téléphonique de l'image du pilier : un point de passage unique, sur votre domaine, où vous décidez ce qui sort.
Ce qu'il récupère réellement
Trois gains solides, vérifiables.
- Des cookies qui tiennent dans le temps. Un cookie posé par votre serveur, sur votre propre domaine, avec les bons réglages, échappe au plafond de sept jours que Safari impose aux cookies posés par un script. Vos parcours d'achat longs redeviennent mesurables. Attention : cela ne marche que si la configuration est propre. Depuis Safari 16.4, un serveur jugé « déconnecté » du site principal retombe sous la limite des sept jours. Le server-side mal posé ne récupère rien : c'est un travail d'artisan, pas une case à cocher.
- Une partie du signal bloqué qui repasse. Comme les données transitent par votre domaine et non par un script tiers facilement reconnaissable, une part de ce que les bloqueurs interceptaient repart. Pas tout, une part.
- Un point de contrôle et de nettoyage. Vous voyez ce qui sort, vous pouvez enlever des données inutiles, corriger des erreurs, et appliquer le consentement au même endroit pour toutes les destinations. C'est un gain de fiabilité et de conformité à la fois.
Ce qu'il ne récupère pas, et ne récupérera jamais
Voici la ligne que nous ne franchissons pas, et que vous devez exiger de tout prestataire.
Le server-side ne récupère pas les visiteurs qui ont refusé. C'est le point central, et nous y consacrons demain un article entier. Il faut distinguer deux choses. Le signal perdu techniquement (un cookie effacé par Safari, un pixel bloqué) est récupérable, parce que le visiteur n'a rien refusé, c'est la plomberie qui a lâché. Le signal refusé par le visiteur (il a dit non au bandeau) n'est pas récupérable, et toute solution qui prétend le récupérer vous vend un risque juridique. Le server-side hérite de votre gestion du consentement, il ne la contourne pas.
Il ne réconcilie pas magiquement les appareils. Si un client vous découvre sur son téléphone au travail et achète le soir sur l'ordinateur familial, aucune technique honnête ne relie ces deux sessions sans identifiant que le client vous a donné (une connexion à un compte, par exemple). Le server-side améliore la mesure sur un même appareil, il ne fabrique pas une identité que vous n'avez pas.
Il ne remplace pas une donnée que vous possédez déjà. Votre caisse, votre CRM, votre back-office de boutique contiennent la vérité de vos ventes. Le server-side sert à réconcilier la mesure marketing avec cette vérité, pas à la contredire.
Le vrai comparatif
| Type de perte | Cause | Récupérable en server-side ? |
|---|
| Cookie effacé au bout de 7 jours | Safari ITP, cookie posé par script | Oui, avec cookie serveur bien configuré |
| Pixel intercepté | Bloqueur de publicité | En partie |
| Identifiant de campagne retiré de l'URL | Protection renforcée iOS 17 | En partie, si le signal est capté avant |
| Visiteur qui a refusé le consentement | Choix de l'internaute | Non, et il ne faut pas essayer |
| Parcours multi-appareils sans identifiant | Absence de compte connecté | Non |
Est-ce que ça vaut le coup pour vous ?
Le server-side demande un serveur dédié, une configuration soignée et de la maintenance. Ce n'est pas gratuit et ce n'est pas figé : les navigateurs évoluent, votre installation aussi. Le calcul est simple : si votre budget publicitaire mensuel et vos ventes en ligne sont significatifs, récupérer dix à trente pour cent de signal (ordre de grandeur avancé par les éditeurs, à vérifier chez vous) change vos décisions et rentabilise l'investissement. En dessous d'un certain volume, l'énergie est mieux placée ailleurs, sur la vitesse du site ou sur le contenu. Nous vous le dirons franchement, comme nous l'avons montré sur une boutique Shopify réelle.
Pour savoir si le jeu en vaut la chandelle dans votre cas précis, un audit gratuit chiffre l'écart et le potentiel avant tout engagement. Notre approche est détaillée sur nos pages tracking server-side et e-commerce. Pour en parler, contactez-nous. Demain, le sujet le plus délicat et le plus mal compris : le Consent Mode v2, comment poser le consentement sans casser sa mesure ni enfreindre la loi.
