Déporter l'exécution de ses outils de mesure côté serveur

Quand, comment, pourquoi ?

03 décembre 2018
Bloqueurs de publicité et/ou de traceurs, blocage intelligent du suivi sur les navigateurs, restrictions au niveau des cookies tiers, données de user agent simplifiées transmises par les navigateurs, voici quelques uns des systèmes pouvant conduire à diminuer significativement le volume de données collectées côté client, sans compter les biais inhérents à une transmission de données directement depuis l'appareil d'un utilisateur. Déporter les processus de collecte et de transmission d'informations, côté serveur, constitue une réponse possible à ces multiples problèmes. Faut-il se laisser tenter ?

Rappels concernant les biais inhérents à une collecte de données côté client

Au delà du recours à des systèmes de blocage, qui relève d'un choix plus ou moins conscient de l'utilisateur d'un site Web ou d'une application, les seuls modes d'usage de l'applicatif logiciel peuvent influer considérablement, bien que les usagers n'en aient pas conscience, sur le volume de données collectées.

La connexion à un service en itinérance est l'un des principaux facteurs de déperdition d'informations. En effet, si les applications sont capables de stocker directement sur le dispositif concerné les informations devant être transmises, de même que les applications Web progressives, une fois la connexion internet récupérée, il n'en va pas de même pour les navigateurs. Ainsi, en cas de bande passante insuffisante afin de traiter l'ensemble des requêtes entrantes et sortantes, les outils de mesure s'avéreront le plus souvent totalement inopérants.

Autre cas courant sur le Web, bien que l'usage progressif de la méthode sendBeacon permette en partie d'en limiter les conséquences, l'absence d'envoi de données en cas de consultation trop rapide d'une page, ou d'interaction avec un élément de navigation.

Autre explication possible à une absence de collecte d'informations, toute aussi forte cette fois sur le Web que sur application, l'obsolescence technologique du logiciel utilisé afin d'accéder à un service. Il peut s'agir tout autant d'un navigateur, que d'un système d'exploitation sur mobile ou tablette, qui pourra potentiellement rendre totalement inopérant un système de mesure.

Les gestionnaires de sites et d'applications n'ayant aucun moyen réellement efficace à leur disposition afin de résoudre les problèmes listés ci-dessus, tout au plus peuvent-ils inciter les utilisateurs à renoncer à un navigateur obsolète ou à un système de blocage mais sans garantie de résultats. Dès lors, ne vaut-il pas mieux pour eux se reposer sur des systèmes s'exécutant côté serveur et abandonner définitivement la collecte de données côté client ?

Collecte de données côté serveur : un moyen complexe et coûteux de compléter celle s'effectuant côté client

Pour mettre en oeuvre des systèmes de recueil, de transmission et d'enregistrement de données côté serveur, un gestionnaire d'application logicielle pourra choisir de recourir à un outil de gestion des balises s'exécutant côté serveur, à des interfaces uniques de collecte tel que segment.com ou encore paramétrer dans le langage de programmation de son choix les appels nécessaires à l'alimentation des différents outils concernés.

Certains éditeurs de logiciels peuvent fournir des kits prêts à l'emploi, à même de permettre à leurs utilisateurs de recourir à leur API aisément. Cependant, lorsque le volume de solutions déployé côté serveur ne peut plus se compter sur les doigts d'une main, le recours aux outils de gestion des balises ou aux interfaces uniques de collecte devient indispensable afin de diminuer les coûts d'implémentation.

Le volume d'outils compatibles avec cette méthode de suivi ne cesse de progresser, d'année en année, sans qu'elle puisse pour autant être qualifiée de fonctionnalité incontournable. En outre, certains systèmes peuvent ne pas s'avérer compatibles avec une telle méthode de suivi, bien qu'une API de collecte soit proposée à leur utilisateurs, notamment ceux nécessitant qu'un identifiant soit généré côté client afin de suivre les actions d'un utilisateur sur différents dispositifs. Par ailleurs, certains éditeurs de logiciels ne proposant pas d'API publique pour leurs service, la mise en place d'un suivi côté serveur s’avérera impossible afin d'alimenter leurs systèmes.

Il est important de garder à l'esprit que même en cas de recours à un système de gestion des balises, un suivi côté serveur sera inévitablement synonyme d'une sollicitation accrue des département techniques afin d'installer et de maintenir les systèmes de mesure concernés. Sans oublier que le paramétrage de la plupart des outils nécessitera un niveau de connaissance technique, des utilisateurs finaux, plus poussé.

Par ailleurs, les cycles de paramétrages liés à l'ajout ou à la modification d'une solution, dans le dispositif de suivi côté serveur, sont généralement plus longs que ceux constatés pour des outils s'exécutant côté client. Enfin, le maintien de tels systèmes est nécessairement plus onéreux car les coûts de licence liés sont plus importants. En cas d'hébergement en propre des programmes nécessaires, c'est un système de collecte à part entière qu'il s'avérera nécessaire de paramétrer, gérer, sécuriser et mettre à jour.

En conclusion

A même de palier à certaines des limites des outils de suivi s'exécutant côté client, leurs pendants s'exécutant côté serveur ne peuvent prétendre au titre de réelle alternative du fait d'une compatibilité partielle des éditeurs de logiciels, mais aussi de coûts et de délais de paramétrage en moyenne significativement plus élevés. De ce fait, l'ajout de systèmes de collecte de données côté serveur devra se limiter à compléter des systèmes existant côté client, sur des indicateurs stratégiques ou sur des processus de collecte de données impactant trop fortement l'expérience utilisateur.