Transcription

• Speaker #0

  Bienvenue dans cette mini-série dédiée au tracking, un sujet technique et souvent galère pour les marketeurs et dirigeants. On n'y comprend pas grand-chose, on a peur de mettre les mains dedans et on ne se rend pas forcément compte des enjeux. Pourtant, le tracking est indispensable pour piloter votre activité. Il vous permet de comprendre le comportement de vos utilisateurs, de mesurer l'efficacité de vos actions marketing et de prendre les bonnes décisions pour développer votre… entreprise. ConsentMod, Serverside, CookieTiers, RGPD, Google Tag Manager, on met les pieds dans le plat et on va tacler ces sujets un par un, une bonne fois pour toutes. Et pour m'épauler dans cette lourde tâche, j'ai le plaisir d'accueillir à mon micro un expert qui est passionné du tracking, j'ai nommé Romain Spubla, consultant senior en tracking et analytique. Et enfin, comme le tracking est un sujet technique, On vous a préparé des fiches mémo pour revoir les notions clés abordées dans l'épisode. Pour y accéder, cliquez sur le lien en description de l'épisode pour télécharger la bibliothèque de ressources. Vous êtes prêts ? C'est parti ! Discaimer, on n'est pas juriste, avocat ni DPO. On vulgarise des notions complexes liées au tracking pour vous aider à prendre les bonnes décisions. Mais...

• Speaker #1

  nous ne sommes pas garants des installations que vous mettrez en place.

• Speaker #0

  Pour continuer cette mini-série, Romain, on va parler dans cet épisode de Tracking Serverside, qui, à ma grande surprise, est un épisode qui est très attendu de nos auditeurs puisque j'avais fait un sondage sur LinkedIn pour savoir quelles étaient leurs principales problématiques liées au tracking et c'est le Serverside qui arrive en tête avec plus de 40% des votes. Donc Romain, j'espère que tu es prêt parce que là, on est attendu sur cet épisode.

• Speaker #1

  Super, c'est ma spécialité pour le coup, le server-side, donc ravi d'en parler.

• Speaker #0

  Et bien pour démarrer Romain, est-ce que tu pourrais nous expliquer avec des mots simples ce que c'est le tracking server-side ?

• Speaker #1

  Déjà on va expliquer ce que c'est que le tracking classique, enfin du moins une architecture, alors toujours difficile à l'oral sans schéma mais vous allez vite comprendre. Quand vous mettez en place un tracking classique de Google Analytics, Google Ads et Facebook Ads par exemple, Quand vous mettez des balises sur votre site, vous allez envoyer des données à Google Analytics, vous allez envoyer des données à Google Ads et à Facebook. Par exemple, il y a un ajout au panier sur le site, il y a un achat sur le site. Depuis le site web, grâce aux balises de tracking, on va envoyer directement une requête qui indique qu'il y a eu un achat ou un ajout au panier vers le serveur de Google Analytics, vers le serveur de Google Ads et vers le serveur de Facebook. Donc ça c'est le tracking classique comme on l'entend. Le tracking server side est un peu différent. On va venir mettre une sorte de proxy, un intermédiaire, entre le serveur de Google Analytics, de Google Ads et de Facebook. Au lieu d'envoyer les données directement depuis son site web vers les serveurs Facebook et Google, on va d'abord envoyer la donnée vers son serveur de tracking, puis depuis son serveur de tracking, on enverra la donnée. vers Google, Facebook ou tout autre point de terminaison. On pourrait se dire à quoi ça sert d'envoyer, non pas les données directement, mais de mettre un proxy entre les deux. Ce qu'il faut se dire, c'est que Google Tag Manager, où on va intégrer les scripts, ou même le script directement, donc un script analytique, un script Facebook, sont des scripts qui sont relativement communs. est donc connu par des bases de données d'adblocker. Et donc forcément, si je veux déclencher mon script analytique, mon script Facebook ou mon Google Tag Manager de manière générale, sur mon site et que l'utilisateur a un adblocker, potentiellement, suivant l'adblocker, le script va être empêché de se charger. Et vu qu'il ne va pas se charger, la donnée ne sera pas envoyée au point de terminaison. Si a contrario, on vient cacher en quelque sorte Google Tag Manager et donc on vient le charger depuis mon serveur. Donc on n'appelle plus GoogleTagManager.com mais on appelle mon serveur qui est sur le même nom de domaine que mon site. Donc par exemple si j'ai un site monsite.com, je vais mettre mon serveur sur mon serveur.monsite.com et du coup le tag Google Tag Manager va être chargé depuis le serveur et avec un nom qui va correspondre à mon site web et non plus GoogleTagManager.com et on pourra contourner les adblockers comme ça. Et ce qui fait que vu que la donnée est arrivée vers le serveur, elle a contourné les adblockers, derrière on a libre choix de l'envoyer vers Facebook, vers Google, vers autre plateforme sans être bloqué.

• Léa

  Donc du coup, moi ce que je comprends, c'est que l'intérêt principal du tracking server side, c'est de pouvoir récolter la donnée des utilisateurs qui utilisent un adblocker.

• Romain

  C'est un des use cases. Disons qu'un des use cases, c'est en effet de récolter de la donnée d'utilisateurs qui ont un dispositif de blocage, mais il y a d'autres use cases. Là ici, on parlait d'un point de vue de données sur comment récolter de la donnée supplémentaire et quel est l'avantage d'utiliser un serveur. Mais typiquement, il y a les adblockers qui vont empêcher la donnée, enfin du moins les requêtes de partir. Et puis, il y a d'autres use cases, comme par exemple, je suis sur Safari, je suis sur iOS, mes cookies ont une durée de vie limitée. C'est le fameux iOS 14.5 d'il y a deux ans. Donc, elle fait un grand bruit à l'époque. Et puis, ça mise à jour 16.4 il y a un an. qui vient faire que les cookies sont limités à un jour ou sept jours. Donc par exemple, je clique sur une pub Facebook, je suis sur mon iPhone ou je suis sur mon Mac sur Safari. Les cookies qui vont être déposées dans mon navigateur vont avoir une durée de vie de 24 heures. Ce qui fait que mon attribution est... d'une durée maximale, et sur une fenêtre, d'une durée maximale de 24 heures, quand l'attribution classique sur Facebook, ça va être le modèle que vous décidez, 7 jours, 28 jours, etc. Mais en réalité, sur les utilisateurs Safari ou iOS, vous êtes limité à 24 heures. Donc vous perdez quand même une partie des conversions attribuées aux campagnes, même si elles suivent avancer les conversions, même si on envoie l'adresse email sur Facebook pour essayer de compenser un peu ça, ce ne sera pas aussi puissant qu'un identifiant de clic. Parce que potentiellement, l'adresse que j'ai sur Facebook, mon adresse email, c'est peut-être l'adresse email de 2010. Quand je fais des achats sur Internet, je n'achète pas avec cette adresse email. Facebook ne peut pas forcément réussir à rapprocher les données. L'autre use case, c'est en effet de pouvoir contourner les limitations sur Safari et iOS, pouvoir prolonger la durée de vie des cookies. On parle souvent de fin des cookies, etc. Les cookies, ça continue de perdurer sur le web. C'est juste qu'on est sur des cookies qui sont déposées par mon site, donc des cookies first party. Et donc, Facebook a des cookies first party, Google a des cookies first party. Et on va faire en sorte qu'ils aient la durée maximale. Donc, Facebook, 28 jours. Google Ads, on peut monter à 90 jours pour les cookies Google. Et puis, Google Analytics, on va monter à 13 mois pour être conforme RGPD.

• Speaker #0

  Et là-dessus, je pense qu'il y a eu pas mal de raccourcis. On a beaucoup entendu comme quoi ça allait être la fin des cookies et que ça allait être une vraie cata. La réalité, c'est que ça va être la fin des cookies, mais d'une seule catégorie de cookies, à savoir les cookies tiers qu'on appelle aussi les cookies third party. Et donc justement, Romain, est-ce que tu pourrais nous expliquer la différence entre ces cookies-là et des cookies classiques qu'on appelle aussi des cookies first party ?

• Speaker #1

  Donc la différence entre un cookie first party et un cookie third party, c'est juste par qui il est déposé. Quand je suis sur le site l'effet marketing, si tu déposes... un script Google Analytics et qui dépose un cookie first party, le cookie va être déposé par ton domaine, l'effet marketing. Donc ça veut dire que c'est toi qui déposes ce cookie-là. Quand l'utilisateur va quitter l'effet marketing, le cookie ne fonctionnera plus. Il sera stocké uniquement dans le contexte de ton site web. Ça, c'est un cookie first party. Le cookie third party, c'est un cookie, par exemple, qui va être déposé par Google. C'est Google qui dépose un cookie sur ton site. Ou Facebook qui dépose un cookie sur ton site. Ça peut paraître abstrait comme ça parce qu'on se dit « Bah ouais, mais quoi qu'il arrive, c'est Google Analytics qui dépose le cookie. » Non. La différence, c'est que tu as le premier cookie que tu déposes toi, c'est un script que tu mets toi sur ton site. Donc par exemple, le script Google Analytics, tu le mets sur ton site avec les balises. Google Analytics va déposer un cookie GA qui lui est... déposés sur le domaine, par le domaine l'effet marketing. À côté de ça, Google est capable de déposer des cookies qui sont uniquement déposées par le domaine Google et qui pourront survivre d'un site à un autre si le site a aussi des balises Google. Donc par exemple, tu vas sur le site A, tu as le tracking Google Ads, tu as des cookies first party qui sont déposées et tu as des cookies third party qui sont déposées. les cookies third party sont déposés par Google l'utilisateur part sur le site B qui a également du tracking Google Ads ces cookies third party vont suivre du site à l'autre et c'est ce qui va permettre de faire des audiences parce que Google va savoir que tu as été sur le site A puis le site B toi tes cookies first party ne servent pas à faire des audiences ils servent à faire de la mesure donc mesurer les conversions, mesurer l'analyse sur ton site mais derrière dès que l'utilisateur équipe ton site les cookies Il reste stocké dans son navigateur, parce que forcément, quand il reviendra, les cookies existeront toujours. Mais par contre, ils seront uniquement dans le contexte de ton site. Ils ne survivront pas, entre guillemets, au fait que l'utilisateur va quitter le site. La différence avec le third party, donc.

• Speaker #0

  Donc si je comprends bien cette fin des cookies tiers en termes d'enjeux, ça concerne plutôt les grosses régies publicitaires, un Google, un Meta, etc. Mais nous, en tant que boîte, en tant qu'annonceur, ça ne va pas nous impacter directement dans notre tracking. En tout cas, on ne peut pas y faire grand-chose. Parce que j'ai beaucoup entendu, c'est la fin des cookies tiers, ça va être la galère. Donc oui, ça va être la galère d'un point de vue ciblage publicitaire, ça va devenir de plus en plus compliqué. Mais de ce que je comprends avec ce que tu es en train de nous dire là, pour moi, il n'y a pas forcément de lien entre cette fin des cookies tiers Merci. et la mise en place du tracking server-side qui pourrait un peu tout solutionner.

• Speaker #1

  Alors ça va avoir un gros impact, mais le server-side n'est pas forcément la réponse à ça. Il y a beaucoup d'abus de langage par rapport au server-side, et je pense qu'on peut faire un certain disclaimer sur à quoi sert le server-side et à quoi il ne sert pas. Typiquement, on parle beaucoup de fin des cookiesières, il y en a qui font des posts sur LinkedIn en disant que vous allez perdre 60% de données sur Chrome. C'est faux ! Vos données de conversion, elles sont récoltées par des cookies first party.

• Speaker #0

  Oui.

• Speaker #1

  Quand vous envoyez une action de conversion à Facebook, quand vous envoyez une action de conversion à Google, l'identifiant de clic de l'utilisateur, il avait été déposé dans un cookie first party. Donc la fin des cookies tiers n'affecte pas ça. La fin des cookies tiers, elle affecte en fait le ciblage de vos utilisateurs. et donc... le site A, l'utilisateur qui va du site A vers le site B puis le site C. Donc forcément Google ou Facebook ou autres plateformes qui savaient que les utilisateurs de votre site étaient également intéressés par tel ou tel site, forcément ça l'aidait dans le ciblage pour essayer de trouver des patterns. Et là ça va venir compliquer le ciblage, donc ça va rendre compliqué le fait d'atteindre des utilisateurs qui seraient utiles pour le site. Donc, ça complique le travail des géants de la tech, on va dire, des régies publicitaires. Mais vous, en tant qu'annonceur, en fait, qu'est-ce que vous avez à faire pour la fin des cookies tiers ? Mise à part, on va dire, mettre en place ce qui est demandé par les différentes régies, à savoir à chaque fois envoyer l'adresse e-mail, envoyer le numéro de téléphone en haché, bien entendu. Après consentement, vous n'avez rien d'autre à faire. C'est-à-dire qu'on entend beaucoup parler de Private Assistant Box, d'API Topics, etc. qui sont des dispositifs pour la fin des cookies tiers. Mais ça, ça concerne Criteo, ça concerne la régie du Boncoin, ça concerne tous les régies publicitaires qui doivent se servir de technologies pour pouvoir cibler. Vu qu'elles ne peuvent plus s'appuyer sur des cookies tiers, elles vont s'appuyer sur d'autres dispositifs qui sont proposés, mais qui ne vont plus se baser. sur ce principe de cookies qui naviguent d'un site à un autre. Donc vous, en tant qu'annonceur, envoyez des adresses e-mail sous consentement. C'est à peu près la seule chose que vous pouvez faire pour préparer la fin des cookies tiers sur Chrome, parce que les cookies tiers, c'est déjà fini sur les autres navigateurs. Donc on parle bien sur Chrome.

• Speaker #0

  Et du coup, une question se pose, maintenant qu'on a bien compris ce que c'est les cookies tiers, quel est le lien entre cookies tiers et server-side ? si il y en a un aucun ou très peu ok si ce n'est un abus de langage du coup un abus de langage ok non parce qu'on a un peu l'impression que du coup le server side c'était la recette miracle pour les cookies tiers pour contourner le RGPD le server side on a l'impression que c'est un petit peu la solution magique et c'est peut-être pour ça que ça fait aussi beaucoup parler mais la réalité c'est que non ça n'a pas de lien avec les cookies tiers et sur la partie RGPD ça ne sert en aucun cas enfin arrête-moi si je me trompe à récolter les données des utilisateurs qui ont refusé le consentement.

• Speaker #1

  Exactement. J'ai l'impression que c'est un peu comme les fiches de marabout qu'on reçoit parfois dans la boîte aux lettres. Ça fait revenir l'être aimé aussi, le server side. Non, mais ça ne vous fera pas gagner au loto non plus.

• Speaker #0

  Dommage.

• Speaker #1

  Dommage. Non, en fait, quand je dis aucun, bien sûr que ça peut aider le server side à la fin des coups qui tirent, par effet ping-pong. C'est-à-dire que si vous contournez les adblockers, vous récoltez plus de données et donc potentiellement vous envoyez plus de data aux plateformes publicitaires avec des adresses email. Donc potentiellement vous allez aider la régie publicitaire à mieux cibler. Donc là-dessus ça aide. Par contre quand on me dit le server side c'est la solution pour la fin des critères, non la solution c'est l'envoyer des user data. des adresses email, des numéros téléphone, des first name, last name, etc. de la base client aux régies publicitaires. En haché, bien entendu, après consentement. Ça, c'est la solution. Après, le server-side vient en complément pour justement, faites adblocker et autres qui empêchent de récolter trop de données, enfin assez de données. Là, on va venir en récolter plus et donc par effet de bord, on récupère plus d'adresses e-mails, plus de user data, donc on alimente mieux les algos. Mais la solution numéro un, c'est vraiment les user data. Et ça, on peut le faire même en étant en client-side. Ça fait des années maintenant que Google pousse pour le suivi avancé des conversions. Et le suivi avancé des conversions, on peut le configurer sans être en server-side. Donc ça, c'est vraiment le truc prioritaire. Suivi avancé des conversions, correspondance avancée des événements. Sur Criteo, il demande aussi l'adresse e-mail. Sur n'importe quelle régie aujourd'hui, sur TikTok, Snapchat et autres, il demande l'adresse e-mail. Donc ça, c'est la prio. Ensuite, pour ce qui est du RGPD. Le server-side ne permet pas de contourner le RGPD. il n'y a rien qui permet de contourner le RGPD. En fait, on parle de cookies depuis tout à l'heure, on parle de cookies first, cookies tiers, etc. Le server side, il va fonctionner également avec des cookies first. On va aussi déposer des cookies. Ce n'est pas parce qu'on met une technologie un peu plus avancée que c'est le Far West. Et là où, par contre, c'est compliqué, c'est que il y a plein de petits tools qui permettent dans Chrome de savoir si euh on a telle ou telle balise qui se déclenche, tout ça. Bon, forcément, quand on est en server-side, c'est un peu plus opaque. Donc, on pourrait se dire plus opaque. Donc, on peut faire un peu ce qu'on veut. Personne ne va s'en rendre compte. Sauf qu'en réalité, ce n'est pas parce que c'est côté serveur qu'il n'y a aucun retour côté navigateur. Il y a quand même des cookies qui sont déposés. Donc, si vous trichez, ça se voit. Première chose. Et puis, demain, vous avez un contrôle clean. Vous pouvez toujours leur dire, ah oui, mais je fais du server-side. Ils vont dire, bah oui, mais tu fais du server-side, tu fais du client-side. tu te dois de respecter le consentement de l'utilisateur. Et donc, ça vient rendre le setup un peu plus technique parce que quand l'utilisateur, il accepte ou il refuse, du coup, s'il accepte dans la CMP le consentement, il faut remonter cette information au serveur pour conditionner les tags en fonction du choix qui a été réalisé par l'utilisateur. Donc non, le server side ne permet pas de contourner le RGPD. Donc vous n'aurez jamais 100% de vos données, même avec le serveur.

• Speaker #0

  Ok. Donc, du coup, on pourrait se dire que le server-side est un peu surcoté.

• Speaker #1

  Non, ça c'est faux. Je savais que ça allait pas être d'accord. Non, c'est pas du tout surcoté. Le server-side, déjà, c'est une super technologie qui permet de, on parle beaucoup de récolte supplémentaire de données, mais il y a d'autres avantages. De un, en effet, on récolte plus de données. Donc, quand on a des gros budgets publicitaires, on peut aller chercher... 20, 25%, même j'ai parfois vu plus de 30% d'attribution supplémentaire selon les plateformes. Parce qu'un annonceur qui est dans le luxe et qui a une grande part de son trafic qui est Safari, iOS, forcément il a des problèmes d'attribution, donc ça, ça peut aider. Et puis derrière, il y a d'autres choses autour du server side. C'est qu'on peut faire de la transformation de données, on a beaucoup plus la main que sur du tracking classique. La philosophie est différente. Quand je mets en place un script Facebook sur mon site, je mets le Facebook Pixel. Le Facebook Pixel, il se sert dans mon navigateur. Il prend mes données d'URL, il prend certaines données, l'adresse IP, le user agent de l'utilisateur, et ça, je ne peux rien faire. Je ne peux pas l'empêcher de prendre ces données-là. C'est nativement, dans le script qui est chargé, il est fait pour récupérer ces données-là, je ne peux rien faire. Côté serveur, j'ai eu le cas, une fois... d'une cliente qui avait un problème parce que son URL elle avait des user data à l'intérieur mais en clair donc par exemple je m'inscrivais je m'inscrivais sur tel formulaire qui était un formulaire Calendly donc et ensuite j'arrivais sur le site en page de remerciement et du coup il y avait les user data dedans, donc les user data elles servaient quand même parce que ça servait à faire le suivi avancé des conversions sauf qu'elles restaient dans l'URL le problème de ça c'est qu'à Facebook, on envoyait des données utilisateurs en clair. Et ça la mettait en infraction, e-privacy, parce qu'elle envoyait, par exemple, mon adresse romain trackanalyse, elle était envoyée telle qu'elle à Facebook, sans être transformée, donc sans être hachée. Et donc ça, on n'a pas le droit. Et c'était le cas à Google Analytics, c'était le cas à Google, etc. Grâce au serveur, on peut mettre des règles, on peut transformer l'URL, on rédacte l'URL, on la réécrit, Et ensuite... on vient envoyer la donnée. Donc ça peut servir pour des raisons aussi de gouvernance de données, de transformer certaines données, de cacher certaines données, avant de les envoyer aux plateformes. Donc on récupère le contrôle sur la donnée. La philosophie du serveur, c'est je donne ma donnée. Alors que la philosophie du client-side, c'est on me prend ma donnée. Je donne versus je prends. Et puis l'autre point qui est hyper avantageux et qui va faire plaisir aux développeurs, c'est la webperf. Quand sur ton site, tu charges pour un ajout au panier un script Google Analytics, un script Criteo, un script Google Ads, un script Facebook, un script TikTok, un script Pinterest. Je peux les faire, parce que je les vois les conteneurs parfois. Un ajout au panier, parfois, c'est 15 scripts sur le site. Imaginons, alors toutes les régies sont pas côté serveur. Bing, pour le moment, n'a pas de pendant. Criteo, il pousse pas vers ça. Mais en tout cas, imaginons que tu vas mettre ton Facebook, ton TikTok, ton Snapchat, ton Pinterest, ton Google Ads côté serveur. Au lieu de déclencher 10 scripts, potentiellement, t'en déclenches plus que 2 ou 3. Ouais. En termes de performance, tu vois la différence. et forcément ça a un impact peut-être moindre sur l'expérience utilisateur parce que ça va peut-être pas faire la diff mais par contre pour tout ce qui est référencement ou aujourd'hui t'as quand même tout ce qui est expérience utilisateur qui est pris en compte donc plus tu vas améliorer tes indicateurs corps vital mieux ça va être et puis c'est souvent un argument qui passe bien en interne quand le marketing voit l'intérêt du serveur site pour la quantité de données quand tu convainc la DSI en leur disant par contre, ça va réduire le nombre de scripts, parce que souvent, les services IT rêvent d'une chose, c'est d'avoir un site sans aucun script de tracking. Et puis en plus de ça, tu réunis le service juridique en lui disant, bah ouais, toutes les données que tu veux pas qu'on envoie aux plateformes, on va pouvoir transformer avant, on va pouvoir restreindre, par exemple, on va plus envoyer l'adresse IP ou on va plus envoyer telle donnée. ça réunit un peu tout le monde autour de la table. Et là, on fait à peu près le tour de l'avantage du serveur sans aller dans des use cases ultra tricky. Mais typiquement, on peut même aller chercher de la marge en temps réel sur des bases de données distantes. Donc, on peut vraiment imaginer des choses très avancées avec le serveur qu'on ne peut pas du tout imaginer avec du tracking classique client-side.

• Speaker #0

  Et du coup, tu vois, si le server-side, ça nous permet de récolter plus de données, de décider les données qu'on partage ou non, et du coup, d'avoir de meilleurs perfs dans notre acquisition de manière globale, en fait, c'est le rêve de tous les annonceurs. Pourquoi toutes les boîtes ne le mettent pas en place ?

• Speaker #1

  Ah ! Aïe, aïe,

• Speaker #0

  aïe !

• Speaker #1

  Pourquoi ? Honnêtement, je voyais le titre d'une... D'une conférence de Simo Hava, qui est un mec ultra avancé dans notre milieu, qui est peut-être même l'expert absolu du tracking en Europe et sans doute au niveau mondial, qui a fait une conférence chez Google le mois dernier qui s'appelait « L'herbe sera toujours plus verte avec le server-side » . Et en fait, il a totalement raison. Je trouve que la métaphore est bien faite. C'est-à-dire qu'en fait, aujourd'hui, il n'y a pas d'inconvénient à passer en server-side. Il n'y aura que des effets positifs d'un point de vue technique. l'inconvénient c'est juste l'argent c'est à dire que tu vas payer une personne qui va mettre en place ton serveur sauf si t'as quelqu'un en interne qui est capable de le faire ça c'est la première chose deuxièmement tu vas payer des coûts serveurs tous les mois alors suivant la boîte ça va coûter plus ou moins d'argent pour un annonceur on va dire petit ou de taille intermédiaire on peut s'en tirer à 90-100 euros par mois chez Addingwell par exemple qui est l'hébergeur par excellence de en France de serveurs destinés au tracking parce qu'en plus de juste les serveurs il y a tout ce qu'il y a autour, tout ce qui est le monitoring et autres moi je sais que je conseille toujours cette plateforme là mais ça a un coût forcément de se dire 90 euros par mois 100 euros par mois, 200 euros par mois suivant ton volume, ça a un coût si tu dépenses 20 000, 50 000 100 000 euros de budget publicitaire par mois c'est tellement ridicule ce coût là qu'il n'y a aucun intérêt à ne pas y passer. Si tu dépenses 1000 euros par mois de budget publicitaire, il va falloir payer une personne qui va t'installer ton serveur, il va falloir payer 100 euros par mois de coût serveur, et là, ce n'est pas intéressant. C'est toujours une question de rationalisation, d'investissement et derrière, de retour sur investissement. C'est un peu comme tout chantier. C'est toujours plus intéressant d'avoir un site web qui est codé de telle manière, qui a telle fonctionnalité dessus. Mais derrière, si tu as 50 personnes qui viennent sur ton site, bon, il faut peut-être être aussi... Il faut peut-être être aussi... Mettre ton effort là où c'est le plus important. Donc, il n'y a pas d'inconvénient. si ce n'est des inconvénients financiers. Et il y a autre chose, j'en parlais hier avec un client, c'est que ça vient rajouter un layer de complexité. Ça vient rajouter une couche de complexité parce que jusqu'alors, tu pouvais derrière, tu mettais en place ton tracking et puis souvent, tu avais toujours quelqu'un dans ton entourage qui était capable de te remettre à jour une balise. que ce soit ton stagiaire, que ce soit ton traffic manager, que ce soit, j'aurais peut-être dû terminer par le stagiaire d'ailleurs, que ce soit ton agence, il y aura toujours, ou même toi, tu seras toujours capable de mettre à jour, en tant qu'annonceur, ton tracking. Que ce soit propre, pas propre. Quand tu mets en place du server-side, c'est-à-dire que tu as une logique en deux bandes qui se fait. C'est-à-dire que tu vas envoyer les données au serveur, puis depuis ton serveur, tu vas déclencher les balises. Donc tu rajoutes une complexité. Déjà que ça fait peur à tout le monde d'aller dans le GTM. Peur à tout le monde, j'entends, mais il y a beaucoup de personnes qui ne sont pas à l'aise avec le outil. Là, tu rajoutes la partie serveur. Et là, en plus, tu dis le mot serveur, et là, les gens te regardent et se disent « Oula ! Comment je ne veux pas toucher le serveur ? J'ai peur, je vais tout casser ! » Donc ça rajoute une complexité, ça rajoute donc potentiellement une maintenance. supplémentaires et souvent on va quand même le conseiller à des boîtes qui sont assez matures qui ont soit des besoins d'analysé précis typiquement quand aujourd'hui on me demande du dashboard et il faut la donner sur la plus précise possible c'est mieux d'avoir du serveur side comme on dit garbages in garbage out si ta donnée n'est déjà pas propre en entrée Ce n'est pas le fait de faire un beau dashboard qui va te permettre de présenter comme il faut tes données. Voilà un peu le frein. Souvent, c'est l'argent et à la limite, la maintenance. Même si la maintenance serveur, en soi, elle est déléguée à des prestataires comme Adimwell.

• Speaker #0

  Et tu vois, un truc peut-être pour rebondir sur ce que tu disais, la technicité du coup de mettre tout ça en place. Interromps-moi si je me trompe, mais c'est quand même un truc qui ne s'improvise pas. le tracking server-side c'est quelque chose de très poussé donc même si t'as quelques notions d'EF de tracking et tout c'est quand même un truc qui est touchy à mettre en place et qui peut vite être un gros chantier là où du tracking client-side avec les cookies classiques sur Google Tag Manager en creusant en checkant la doc en y passant quelques heures tu peux mettre quelque chose en place qui tienne la route j'ai l'impression que sur du server-side ça s'improvise pas en tout cas tu vois moi typiquement si je prends mon cas à moi personnellement je ne m'y aventurerai pas quoi Merci.

• Speaker #1

  Tout est question d'apprentissage derrière. C'est-à-dire que quand tu mets le temps et quand c'est ton objectif, parce que derrière, tu as une vraie barrière à l'entrée qui est l'apprentissage.

• Speaker #0

  En soi,

• Speaker #1

  ce n'est pas inaccessible. Comme n'importe quel, il n'y a rien qui est inaccessible dans nos métiers. C'est juste, il faut dire qu'il faut apprendre. Et la différence entre du tracking classique et du tracking server-side, C'est que du tracking classique, tu fais coucou chat GPT, viens m'aider sur n'importe quel script JS, t'as plein de vidéos YouTube. Bon du server side, chat GPT déjà il a du mal un petit peu parce qu'il confond souvent client-server. Et puis ça reste une logique qu'il faut être sûr de bien avoir assimilée. Il n'y a pas beaucoup de formations aujourd'hui. T'as la formation de Simo Hava, t'as les formations d'Analytics Mania, c'est des formations en anglais. Ça s'adresse quand même souvent à des personnes qui ont un niveau de technicité déjà avancé pour comprendre comment fonctionnent les requêtes navigateurs et autres.

• Speaker #0

  Donc c'est typiquement le genre de sujet qui est difficile à internaliser, sauf si on a quelqu'un bien évidemment qui maîtrise la compétence et là il faut en profiter. Mais si l'objectif c'est de former quelqu'un en interne pour mettre en place tout ça, finalement tu en as vraiment pour un moment et je ne suis pas sûre que déjà les équipes et la bande passante et que le ROI soient vraiment intéressants. Je pense que typiquement c'est le genre de tâche très technique qui vaut mieux externaliser. Je t'en rejoins totalement sur la partie annonceur. Compliqué de se dire je vais former une personne pendant 10, 15, 20, 30 heures sur le sujet quand tu vois combien te coûte un salarié en bout de chargé. Et que la personne ne soit pas encore experte à ce niveau parce que ce qui va faire que tu vas être expert, c'est de rencontrer toutes les problématiques et de pratiquer. Tu es une agence, tu développes un pôle tracking. Là, en effet, ça peut être intéressant d'internaliser le savoir-faire. Mais c'est un peu toujours le cas quand tu es annonceur. Tu vas essayer d'internaliser ce qui va te servir régulièrement, ce qui va avoir un coût régulier et qui va être très stratégique. Mais dès que tu es sur un besoin de niche qui est en one shot ou presque... Pourquoi t'embêter à former quelqu'un quand tu payes un prestataire, il te met en place et après, soit tu prends un accompagnement qui te coûtera pas très cher en maintenance, si t'es gros et qu'au final tu risques de faire évoluer régulièrement ta structure, mais si t'as un site en Shopify, PrestaShop et que tes régies bougent pas beaucoup, bon t'as de grandes chances que ton tracking reste fonctionnel pendant plusieurs mois, années, même s'il faut faire attention, il faut être... très agile avec ces technos-là parce que t'auras toujours la mise à jour d'iOS 18 en septembre prochain potentiellement. Ça, on verra au mois de juin quand ça sera annoncé. Mais il y aura toujours quelque chose en plus sur lequel il faudra s'adapter pour rester avec un setup parfait. Mais ça, c'est partout. Google Ads, c'est pareil, ça bouge tout le temps et si tu veux garder des structures de campagne propres et qui fonctionnent, il faut s'adapter.

• Speaker #1

  Et typiquement, la mise en place d'un tracking server-side dans une boîte, tu dirais que ça prend combien de temps en moyenne ? Et savoir, est-ce que ça prend potentiellement de la bande passante à l'équipe tech, aux développeurs, pour que nos auditeurs qui potentiellement ont envie de mettre ça en place et se posent ces questions-là puissent un petit peu être fixés là-dessus ?

• Speaker #0

  Alors, je dirais que l'écart-type de mes prestations server-side va s'étaler entre 2-3 semaines à 6 mois.

• Speaker #1

  Ok.

• Speaker #0

  La médiane, elle va être plus aux alentours des un mois. En gros, il y a des projets qui vont être longs parce qu'il y a des mises à jour plus globales de tracking. Et c'est ça qu'il y a à prendre en compte, c'est est-ce que mon tracking de base est propre aujourd'hui ? Je disais tout à l'heure, garbage in, garbage out, c'est exactement ça. Si tu as un tracking aujourd'hui qui ne tient pas la route, tu peux mettre du server side.

• Speaker #1

  C'est là où tu déterres des cadavres, tu mets les mains dedans et tu te rends compte que c'est bordel.

• Speaker #0

  Moi, parfois, on me dit ça coûte combien du server side et je donne jamais de prix. C'est pas par opacité, c'est juste que le premier truc que je demande, c'est un accès à Google Tag Manager.

• Speaker #1

  Ouais, pour comprendre déjà ce qui est mis en place et la différence aussi entre. Ouais, mais nous, ça va, notre tracking, il tourne et tout. Et en fait, quand tu mets les mains dans le compte du team, je fais oh là là, là, il y a du taf.

• Speaker #0

  C'est exactement ça. Alors déjà, moi, quand on a un call prospect, je regarde, je vais sur le site, j'ouvre la console, je regarde les tactiques qui se déclenchent, je regarde le data layer. Ça, tu peux le voir sans avoir accès à GTM. Mais je trouve que c'est bien d'avoir accès à GTM parce que déjà, en faisant un rapide audit, en te baladant sur le site, tu ne vois pas tout. Puis, tu comprends quand même si le tracking, il est templétisé au max ou s'il y a déjà eu des choses custom. Tu comprends si tu as un développeur quand même derrière qui... qui maîtrisent le truc ou s'ils sont totalement à la rue. Et en fonction, ça te permet de jauger aussi la quantité de travail qu'il va y avoir pour assainir le tracking et ensuite rajouter le volet server-side. Mais à côté, je tombe quelques fois sur des annonceurs où le travail a été très bien fait de mise à niveau de GA4, où la donnée est propre, le data layer est propre. On va rajouter un serveur par-dessus, tu t'adaptes déjà sur une structure qui est bonne. Dans ces cas-là, la mise en place sous deux semaines, elle est faite. du travail au dev c'est assez faible, on va leur demander d'ajouter deux entrées DNS pour avoir son serveur qui va être sous son nom de domaine c'est la première chose et puis s'il y a une configuration Cloudflare on va demander de mettre un reverse proxy, je ne vais pas rentrer dans les détails techniques mais en gros on va mettre en place un setup pour tout ce qui est iOS et Safari ou s'il n'y a pas Cloudflare on va Euh... Plutôt passer par une méthode de dépose d'un cookie HTTP. Mais le but, ce n'est pas d'expliquer tous les termes barbares. C'est juste de dire, en gros, votre dev, il va avoir deux missions qui sont quand même assez légères. Si le tracking est propre en amont, si par contre, on est sur un environnement custom et qu'il va falloir refaire tout le data layer, là, c'est un projet qui est beaucoup plus large que juste du server side. Et en effet, là, ça va embarquer l'IT.

• Speaker #1

  OK. Et tu vois, pour essayer d'aider nos auditeurs à arbitrer un petit peu, du coup, selon toi, quels sont... Il y a deux, trois questions à se poser pour savoir si ça vaut le coup ou pas de mettre en place du server-side dans ma boîte.

• Speaker #0

  Alors, je dirais, c'est déjà de te poser la question. Première chose, de combien tu dépenses par mois en budget acquisition ? Et deuxièmement, est-ce que tu te sers de ton analytique ? Normalement, tu devrais être serveur de ton analytique. Ça fait partie des good practices.

• Speaker #1

  Comme avoir un compte Google Tag Manager propre.

• Speaker #0

  Exactement, mais comme plein de choses, comme avoir une stratégie CRO, comme avoir un compte client, des mails de marketing automation et tout. Mais on sait très bien que dans la réalité, tout n'est pas fait comme il faut. Et donc, si tu as un compte analytique qui n'est jamais regardé, que tu demandes un plan de marquage qui est ultra poussé, souvent c'est de l'argent qui est déployé pour rien. Mais pour en venir aux questions qui sont à se poser, c'est en effet, quel est mon degré d'analyse aujourd'hui ? Est-ce que la qualité de la donnée que je remonte est stratégique ou non pour moi ? Si oui, déjà on oriente la réponse vers oui. il faut passer par du server-side. Deuxièmement, combien je dépense par mois ? Parce que les données visibles, tout à l'heure je disais qu'on récolte 20% de données supplémentaires, c'est en fait qu'on envoie 20% de données supplémentaires et donc on va avoir dans les plateformes 20% de données visibles supplémentaires. Ça ne veut pas dire qu'il y a eu 20% d'achats supplémentaires. C'est autre chose. Du coup, si tu as beaucoup de dépenses publicitaires, tu fais mieux à prendre ton algorithme pub en face. Par contre, à long terme, tu peux avoir des effets cumulés. Vu que tu lui envoies plus de données, il est meilleur. Et donc, il va aller te chercher en réalité plus de purchases. Ou plus de leads. Ça, c'est l'objectif. Ça,

• Speaker #1

  c'est la base, oui.

• Speaker #0

  Si tu dépenses beaucoup d'argent, je dis beaucoup d'argent, si tu dépenses 10 000 euros par mois de budget pub, Ce qui est beaucoup pour certains annonceurs, ce qui est absolument rien pour d'autres. Donc c'est toujours une question de où est-ce qu'on se situe. Si tu dépenses 10 000 euros par mois, mettre par exemple 90, 100 euros par mois dans ton serveur de tracking pour récolter plus de données et que tu as un algorithme derrière qui soit plus performant et que derrière tu génères plus de performances.

• Speaker #1

  C'est un bon héroïsme.

• Speaker #0

  J'ai envie de te dire que tes 100 euros par mois, en toute logique, par la donnée que tu vas envoyer en plus et par l'apprentissage de ton algorithme, ils vont être remboursés par eux-mêmes. Le seul truc, c'est toujours calculer le ROI du server side. C'est hyper compliqué. C'est le ROI du tracking, c'est compliqué. Parce que tu as toujours des méthodes Facebook qui vont te donner un indicateur en te disant que tu as eu tant de pourcents de conversion supplémentaire attribuée grâce à l'API, mais ça reste une boîte noire. Et tu vas pouvoir en effet mettre en place des techniques via BigQuery ou en envoyant des données supplémentaires pour savoir si tu aurais ou non récolté la donnée euh... est-ce que l'utilisateur avait un adblocker ou non, ça tu peux le faire mais ça reste des setups plus avancés tu peux mettre en place une double configuration analytique, une sans un server side une avec server side mais bon tu viens affecter ta webperf donc c'est pas beaucoup fait en clair à part le multiverse et avoir un monde où t'as pas mis en place ton server side et un monde où t'as mis en place ton server side Et du coup, voir combien de chiffre d'affaires tu fais avec ServerSide et combien de chiffre d'affaires tu fais sans ServerSide, c'est impossible de savoir. Et le multiverse, c'est que dans Marvel, donc on n'a pas la possibilité. Mais dans l'idée, il faut être logique, tu envoies plus de données de meilleure qualité, donc ton algorithme va mieux apprendre, donc tu vas être plus rentable. Donc, moi je dis, seuil de 10 000 euros déjà. Ça te bien intéresse. 10 000 euros de dépense, souvent, c'est un seuil où c'est dommage de passer à côté.

• Speaker #1

  Ok, intéressant. Trop cool. Eh bien, écoute, je te propose de clôturer cet épisode. J'espère que ça aura permis à nos auditeurs d'avoir des premières clés sur le server side. Et ce qu'on va faire avec Romain, c'est qu'on vous partagera en complément de cet épisode une petite infographie, des fiches mémo qui vont vous permettre de comprendre tout le fonctionnement et pour illustrer un petit peu tout ça parce qu'on a conscience de à quel point ça peut être technique. Et si vous avez des questions ou que vous voulez aller plus loin sur le sujet, je vous invite chaudement à contacter Romain.

• Speaker #0

  Merci à tous pour votre écoute et merci Léa surtout pour son invitation.

• Speaker #1

  Si cet épisode vous a plu, partagez-le à un marketeur ou à un entrepreneur à qui ça pourrait être utile. Vous pouvez aussi laisser 5 étoiles au podcast sur Spotify ou Apple Podcast. Et comme le tracking est un sujet technique, on vous a préparé avec Romain des fiches mémo pour retrouver les notions clés abordées dans l'épisode sous forme de schéma. Pour y accéder, cliquez sur le lien dans la description de l'épisode pour télécharger la bibliothèque de ressources. Et je vous dis à très vite pour le prochain épisode. Ciao, ciao !