Server-Side
Quelle est la durée de conservation des données ?
Source (collecte des données côté server-side):
Live events inspector :
Vous pouvez visualiser, jusqu'à 6 appels par minute pour chaque type d'événement. Et un bonus de 30 appels par heure pour chaque type d'événement.
Vous pouvez visualiser les logs de vos appels vers le server-side jusqu'à 7 jours.
Destination (redistribution des données vers vos partenaires server-side) :
Event Inspector :
Vous pouvez visualiser, jusqu'à 6 appels par minute pour chaque type d'événement. Et un bonus de 30 appels par heure pour chaque type d'événement.
Vous pouvez visualiser les logs de vos appels vers vos partenaires jusqu'à 48 heures.
Event delivery :
Le temps de stockage des données dans le rapport Event delivery de vos destinations est de 30 jours.
Health (dashboard de monitoring de la collecte sur vos sources server-side):
Le temps de stockage des données dans le rapport de Data quality est de 30 jours.
Le CAID a t-il un intérêt avec les API media (gec, capi par ex) ? finalement, ce CAID n'est -il qu'utile si on utilise une data clean room ?
En dehors de vous permettre d'échanger vos identifiants avec vos partenaires média, le CAID va avoir un interrêt majeur pour faire perpétuer votre cookie côté server et ainsi bypasser l'IT.
Le CAID a-t-il une durée maximale de conservation paramétrable ?
La durée maximale du CAID est de 13 mois. Cette durée est paramétrable dans nos interfaces.
Ce CAID peut il être partagé et utilisé par les plateformes d'achat OpenWeb (Xandr, TTD, Adform etc) ou uniquement par Walled Gardens ?
Le CAID a pour objectif essentiellement de permettre à un site de reconnaitre ces visiteurs.
Cet identifiant est la propriété du site, c'est un outil au service de la stratégie digitale du client et de ses partenaires.
En revanche une version hashée du CAID est envoyée à certaines destinations
Votre CA ID est il similaire à un First ID par exemple ?
Le CAID fonctionne en Silo, C'est le cookie de notre client sur son périmètre, il peut ensuite être partagé mais sous le contrôle du client, ce n'est pas un cookie lisible ou partageable.
La fin des cookies tiers signifie-t-elle que les CMP deviendront obsolètes et inutiles ou pas ?
Non car les choix en matière de consentement sont stockés dans des cookies First-Party qui peuvent être rendus encore plus solides si vous adoptez certaines pour une optimisation du tracking en first party.
Notre CMP est ccompatible et certifiée par Google Consent Mode
Le mode de délégation de sous domaine ne présente t il pas des problématiques de sécurité ?
Il existe plusieurs configurations et des sensibilités différentes (CNAME, A-record, Reverse Proxy).
Passer par un WAF (Reverse Prox) est souvent utilisé pour des questions de sécurité est représente une des meilleures approches pour tracker vos évènements en first party.
La délégation de sous-domaine est elle faisable pour n'importe quel type de cookies (ex : Google Ads) et si oui, peut être elle mise en place côté TMS que côté dev ?
Côté client-side (sauvegarde des cookies des tags clients side tel que Google Ads) : Phoenix
Côté server-side : le CAID sert de base aux destinations, en remplacement des ids initiaux
Quels serait l'impact financier du passage au Server-side (en termes de coûts pour l'organisme) ?
L'impact financier dépend du volume du site et/ou apps. Pour toutes demandes de ce type, n'hésitez pas à nos contacter directement pour en discuter si vous voulez une estimation personnalisée.
Vous pouvez également consulté le ROI constaté sur ceux qui ont déjà basculé sur le server-side (entre 15 et +25% d’augmentation des taux de conversion)
Avec Commanders Act, peut t'on faire du remarketing / retargeting via du server-side (sur diverses zones : accueil, produits, catégories, panier ...) ?
Oui, il faut trouver dans le contexte de la fin des cookies des protocoles d'échanges qui permettent de poursuivre ces mécaniques digitales. Pensé dans cette logique le server-side Commanders Act vous permet facilement d'orchestrer l'ingestion et la redistribution de vos données vers vos partenaires média.
Quand est-il du support de certaines fonctionnalités côté ss type consent mode ?
Notre plateforme intègre une solution de consentement, nativement intégrée qui est labellisé Consent Mode par google donc tout cela fonctionne bien ensemble.
Quels sont vos bénéfices vis-à-vis des autres acteurs du marché, à savoir Tealium / GTM server-side/GCP/Azure/etc... ?
Il y a un certain nombre de différences avec les acteurs que vous mentionnez. Nous sommes européen avec un hébergement en France.
La plateforme est très appréciée par le métier et souvent plus customisable. Notre solution Server Side peut être déployée y compris dans un environnement GTM.
Certains de nos clients actuels ont basculé leurs usages Server Side chez nous même si leur fondation avait été construite sur GTM pour le client side.
Du coup la solution server side représente bien un travail pour les devs en plus de l'aspect client side géré côté WA ?
Cela dépend si vous vous placez dans un contexte de Server Side complet ou un Server Side hybride (certaines choses gérées en client side, d'autres en server side).
Quoi qu'il en soit la solution server-side représente un énorme bénéfice car une fois déployée vous n'avez plus besoin de vous occuper de la collecte mais simplement de l'activation de vos partenaires média.
Quel est la différence entre le mode hybride et full server-side ?
En hybride, un tag à déployer, un paramétrage de votre first-party et c'est parti.
En full, une API à activer au sein de votre environnement, par votre équipe IT
On va partager plus de données personnelles qu'avant (capi / google enhanced conversion) - même si c'est soumis à cookies. Finalement, pour l'utilisateur/internaute, accepter des cookies revient à donner bien plus d'infos qu'avant. Que dit la CNIL à ce sujet ?
Le digital utilise la donnée pour segmenter, cibler, mesurer et activer. Rien ne change par rapport à avant. Il faut toujours rester conforme au RGPD. L'enjeu est de trouver les nouveaux composants et méthodes sur lesquelles s'appuyer.
En revanche, si il y a échange de données dans le futur, l'usage d'API sera beaucoup plus sécurisé que ce qui se faisait avec du javascript. L'avantage d'une API pour le marketing, c'est que l'on sait qui envoie, qui reçoit et ce qui est reçu.
Les équipes WA étant généralement distinctes des équipes devs, l'aspect Server Side ne va-t-il pas pousser les questions de mise en place côté dev là où la tendance était côté WA avec les tag managers ?
Les équipes devs ne sont sollicités sur une implé server-side qu'à la condition que vous optiez pour une approche "server to server". Car avec l'approche OneTag (majoritairement utilisée par nos clients) c'est l'inverse qui se produit, vous êtes beaucoup moins dépendant de vos équipes devs du fait que le tagging serverside ouvre de nouvelles possibilités no-code (enrichissement, data cleansing, data quality, etc.) qui n'était pas possible avec le client-side
Avec l'utilisation d'un server side - est-il toujours possible de suivre les données "comportementales" (Vues, Clics, conversions) sur des éléments précis (sur les utilisateurs consentants) ?
Les mêmes évènements seront collectées en mode server side qu'en client side. C'est seulement qu'au lieu que votre solution analytics ou autre aille chercher l'info sur le navigateur (Adblocker, limitation cookies, etc.), elle lui est poussé par Commanders Act en Server Side
Quels sont les bénéfices à attendre du serverside ?
Continuité du marketing digital
Web Performance
Data Quality & Monitoring
Enrichissement
Sécurité
Ai-je besoin de mon IT pour le mettre en place ?
Non il existe des solutions auto hébergées.
Nous recommandons l'utilisation du Onetag en tracking First pour une première implémentation.
Tutorial OneTag :
First party Tracking :
Dernière mise à jour
Comment valider la bonne implémentation d'un tag serverside ?
La recette est un enjeu pour le serverside comme il pouvait l'être sur le clientside.
Le serverside permet d'aller plus loin en proposant l'exhaustivité des hits entrants et sortants.
Le serverside permet de remonter au travers de dashboards les erreurs renvoyées par les partenaires.
Le tout peut être reçu par alerte (slack, teams, mail, api etc...)