Comme vous le savez peut être, Tarteaucitron n'est aujourd'hui pas très adapté à du S2S (ou server side tracking).
En effet, le principe du server side est d'envoyer des informations au serveur, afin que le serveur gère l'envoi des tags, là où tarteaucitron gère lui même l'envoi des tags.
Pourquoi c'est problématique ?
Parce que la fin des cookies tiers est imminente.
Alors oui, cette fin a été "annulée" par Google, mais ils ont annoncé prévoir une expérience de consentement (autrement dit on peut les considérer désactivés par défaut, comme sur les autres navigateurs).
Il ne s'agit pas selon moi d'un grosse évolution à prévoir : Tarteaucitron envoie déjà des événements au document de la forme serviceKey+'_loaded'.
Ce qu'il faut maintenant c'est la possibilité de ne pas envoyer les tags.
Un workaround aujourd'hui pour la plupart des solutions requierrant un ID serait de n'envoyer que la line de code suivante côté client :
(tarteaucitron.job = tarteaucitron.job || []).push(serviceKey);
Cela permet de déclencher correctement les events sur le document, mais mène toutefois à des affichages étranges "0 services" par type de service (voir capture ci-dessous) :
Une solution qui serait proche de l'implémentation actuelle serait de pouvoir pousser des instructions de la forme suivante (ou quelque chose de similaire) pour déclencher l'événement sans déclencher le tag :
(tarteaucitron.job = tarteaucitron.job || []).push(serviceKey,"eventOnly");
Cela permettrait à ceux qui le veulent de faire du S2S, et je pense que cet ajustement ne demande pas de modifications trop structurantes (et assure la rétrocompatibilité).
Bien sûr tous les services ne sont pas compatibles avec du server side, mais dans tous les cas la gestions déclarative offre une meilleure maîtrise de l'ordre de déclenchement des éléments, ce qui évite de se passer de setTimeOut dès qu'on essaie de reprendre le contrôle sur l'ordre de déclenchement des éléments (en tag management notamment).
Petit point d'attention : le consent mode doit toujours être géré client-side.
This issue has been automatically marked as inactive because it has not had activity for 20 days. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
Bonjour !
Comme vous le savez peut être, Tarteaucitron n'est aujourd'hui pas très adapté à du S2S (ou server side tracking). En effet, le principe du server side est d'envoyer des informations au serveur, afin que le serveur gère l'envoi des tags, là où tarteaucitron gère lui même l'envoi des tags.
Pourquoi c'est problématique ? Parce que la fin des cookies tiers est imminente. Alors oui, cette fin a été "annulée" par Google, mais ils ont annoncé prévoir une expérience de consentement (autrement dit on peut les considérer désactivés par défaut, comme sur les autres navigateurs).
Il ne s'agit pas selon moi d'un grosse évolution à prévoir : Tarteaucitron envoie déjà des événements au document de la forme serviceKey+'_loaded'. Ce qu'il faut maintenant c'est la possibilité de ne pas envoyer les tags.
Un workaround aujourd'hui pour la plupart des solutions requierrant un ID serait de n'envoyer que la line de code suivante côté client :
(tarteaucitron.job = tarteaucitron.job || []).push(serviceKey);
Cela permet de déclencher correctement les events sur le document, mais mène toutefois à des affichages étranges "0 services" par type de service (voir capture ci-dessous) :Une solution qui serait proche de l'implémentation actuelle serait de pouvoir pousser des instructions de la forme suivante (ou quelque chose de similaire) pour déclencher l'événement sans déclencher le tag :
(tarteaucitron.job = tarteaucitron.job || []).push(serviceKey,"eventOnly");
Cela permettrait à ceux qui le veulent de faire du S2S, et je pense que cet ajustement ne demande pas de modifications trop structurantes (et assure la rétrocompatibilité). Bien sûr tous les services ne sont pas compatibles avec du server side, mais dans tous les cas la gestions déclarative offre une meilleure maîtrise de l'ordre de déclenchement des éléments, ce qui évite de se passer desetTimeOut
dès qu'on essaie de reprendre le contrôle sur l'ordre de déclenchement des éléments (en tag management notamment).Petit point d'attention : le consent mode doit toujours être géré client-side.