Quand les données marketing en temps réel justifient leur coût

Les capacités en temps réel nécessitent un business case au niveau de la décision

Payer pour des données marketing plus rapides a du sens lorsque la vitesse modifie une décision client. Lorsque les données arrivent déjà avant que cette décision doive être prise, acheter davantage de rapidité ajoute des coûts sans améliorer le résultat. Un achat de technologie marketing, ou martech, devrait donc commencer par l’échéance d’utilisation des données.

Cette décision d’achat est devenue plus difficile à dissocier d’une promesse ancienne : les données en temps réel résoudraient les problèmes d’engagement et d’expérience client. Un passionné de martech fait remonter le terme à l’informatique, en particulier aux systèmes d’exploitation et au traitement des données. Selon ce commentateur, les fournisseurs de gestion de la relation client, ou CRM, et d’analytics web l’ont adopté dans les années 1990 pour distinguer les mises à jour immédiates des systèmes du traitement par lots nocturne, qui traite ensemble des données accumulées. Les fournisseurs de martech ont ensuite fait du traitement en temps réel une capacité premium, ce qui leur a donné un intérêt financier à vendre davantage de rapidité.

Pourtant, le fait de disposer de cette capacité laisse aux acheteurs deux questions : l’organisation peut-elle la prendre en charge, et quelles décisions l’exigent ? Le commentateur soutient que la plupart des organisations ne disposent pas de l’infrastructure et des systèmes nécessaires pour prendre en charge le traitement en temps réel à grande échelle. La préparation de l’infrastructure et le besoin métier sont deux contraintes distinctes ; les acheteurs doivent donc évaluer les deux au regard de l’échéance de l’interaction client.

Définir la fraîcheur selon le moment où une décision commence à se dégrader

L’échéance de la décision transforme le « suffisamment frais » en exigence d’ingénierie. Pour chaque élément de donnée, demandez quelle décision il permet et jusqu’à quel âge il peut aller avant que cette décision ne se détériore. Des décisions différentes peuvent tolérer des âges de données différents même lorsqu’elles partagent la même infrastructure ; une préférence à l’échelle de la plateforme pour le traitement en temps réel ne peut donc pas établir la bonne exigence.

Pour adapter la vitesse de traitement à ces besoins, le commentateur propose un traitement en temps réel pour la faible quantité de données qui l’exige réellement, tout en organisant l’arrivée de la plupart des données avant leur utilisation. Cette répartition reflète les différences dans la vitesse à laquelle les données client évoluent et la fréquence à laquelle une organisation les collecte. Ces différences devraient guider la conception des pipelines : la manière dont les données se déplacent depuis leur origine jusqu’aux systèmes qui les utilisent.

Rendre ces exigences explicites revient à appliquer l’intelligence décisionnelle : examiner comment les décisions sont prises et utiliser le feedback pour améliorer leurs intrants et leurs résultats. Gartner la définit comme « une discipline pratique qui fait progresser la prise de décision en comprenant et en concevant explicitement la manière dont les décisions sont prises, et dont les résultats sont évalués, gérés et améliorés via le feedback. » Gartner a aussi un intérêt commercial ici : en tant qu’entreprise de recherche et de conseil, elle bénéficie de la demande d’accompagnement sur cette discipline. Appliquée à la fraîcheur, cette approche consiste à établir la fenêtre temporelle et l’urgence d’une décision avant de choisir la fréquence de mise à jour de ses intrants.

Choisir cet intervalle impose de peser les conséquences dans les deux sens. Mettre à jour trop souvent consomme du temps, de l’argent et des ressources sans bénéfice correspondant ; mettre à jour trop lentement peut nuire aux processus opérationnels, aux expériences client, ainsi qu’à la valeur et à la santé de la marque. Le commentateur soutient que la vitesse de livraison devient une vanity metric lorsqu’elle n’a aucun effet sur le fait qu’un intrant reste utile au moment de la décision.

Prendre en compte les coûts de traitement et de rapprochement

Une fois qu’une décision a une exigence explicite de fraîcheur, le coût de son dépassement devient plus facile à examiner. Le commentateur reconnaît l’attrait technique de rendre chaque flux de données temps réel, y compris des conceptions visant une livraison en moins d’une milliseconde. Mais cette ambition entraîne des obligations de construction, d’exploitation et de maintenance qui demeurent même lorsqu’une mise à jour planifiée servirait tout aussi bien la décision.

Ces obligations commencent par l’infrastructure de streaming, qui traite les données à mesure qu’elles arrivent, et par les pipelines toujours actifs qui les maintiennent en mouvement. Les deux nécessitent une exploitation et une maintenance continues ; leur construction ne représente donc qu’une partie de la dépense. Lorsque le travail marketing concerné peut s’exécuter de manière périodique, l’organisation paie quand même pour maintenir ces systèmes actifs entre les décisions. Le traitement par lots peut au contraire regrouper le travail dans le temps disponible.

Maintenir les pipelines actifs crée aussi un travail récurrent en leur sein. Les données entrantes doivent souvent être transformées dans un format qu’un autre système peut utiliser ; un traitement continu signifie donc répéter ces transformations à mesure que les mises à jour arrivent. La résolution d’identité, qui relie les données à l’identité client pertinente, ajoute des exigences d’ingénierie et d’exploitation lorsqu’elle doit se faire avec très peu de délai. Le stockage ajoute une autre dépense, ce qui fait d’une exigence de rapidité inutile un engagement budgétaire permanent à travers ces systèmes.

Le commentateur associe également une ingestion plus rapide, c’est-à-dire l’arrivée des données dans un système, à une difficulté accrue pour maintenir la cohérence et le rapprochement, c’est-à-dire le travail consistant à faire concorder les enregistrements. À mesure que les données arrivent plus vite, le système doit maintenir cette concordance à un rythme plus soutenu. Une décision peut donc recevoir un intrant plus récent alors même que l’organisation doit fournir davantage d’efforts pour établir si la vue combinée est fiable.

Lorsqu’aucune décision immédiate n’est en attente, le commentateur soutient que laisser du temps au rapprochement peut aider à maintenir une vue partagée fiable des données. La fiabilité doit donc figurer dans le business case au même titre que les dépenses d’infrastructure. Certaines décisions perdent effectivement de la valeur si le traitement attend ; l’exigence doit donc spécifier des données fiables avant l’échéance. Un traitement plus rapide est justifié lorsque le respect de cette échéance l’exige.

Donner à chaque décision marketing son propre intervalle de rafraîchissement

Les exemples du commentateur montrent comment ces échéances diffèrent au sein du marketing. Les données d’abandon de panier, les signaux de détection de fraude et la personnalisation pendant une session web ou applicative doivent être disponibles en quelques secondes. Pour une interaction déjà en cours, une mise à jour plus tardive peut arriver après que l’opportunité d’agir est passée ; le délai peut donc modifier directement le résultat.

D’autres travaux permettent une fenêtre plus large : le commentateur classe les audiences de retargeting, la segmentation du cycle de vie et la préparation des campagnes hebdomadaires dans la catégorie pouvant utiliser des mises à jour horaires ou quotidiennes. Une campagne hebdomadaire décrit le travail en préparation ; ses intrants peuvent malgré tout devoir être rafraîchis plus fréquemment qu’une fois par semaine. Ces intervalles expriment les recommandations du commentateur par cas d’usage, la fenêtre temporelle réelle de la décision déterminant l’exigence.

La préparation des campagnes dépend aussi d’intrants soumis à des échéances bien plus serrées. Le commentateur demande des mises à jour presque immédiates des données de consentement et de suppression afin que les désinscriptions et les questions de conformité influencent la possibilité de contacter un client. Le rafraîchissement d’une audience peut tolérer un rythme horaire alors que l’autorisation de contacter quelqu’un change presque immédiatement. Le calendrier de préparation ne peut donc pas déterminer l’intervalle de rafraîchissement de chaque intrant.

Ces différentes échéances peuvent coexister dans le même workflow. Concevoir séparément la préparation des audiences et les contrôles d’autorisation préserve le traitement urgent tout en permettant à d’autres intrants de suivre un rythme plus lent. Cela donne à chaque décision une exigence spécifique plutôt qu’une instruction générale consistant à tout traiter par lots.

Traduire les échéances en SLA et en choix d’accès aux données

Pour établir ces exigences, le commentateur recommande de partir du canal ou point de contact orienté client. Identifiez l’interaction et la décision, déterminez à quelle fréquence les données doivent être consultées ou rafraîchies, puis remontez jusqu’à leur origine. Cette séquence établit la latence acceptable, c’est-à-dire le délai avant que les données deviennent disponibles pour utilisation. Partir de la vitesse maximale de l’infrastructure risque de faire de sa capacité l’exigence par défaut.

L’exemple de la détection de fraude montre pourquoi l’interaction doit venir en premier. Les contrôles anti-fraude dans une application numérique peuvent devoir se produire bien plus fréquemment que les contrôles de mise à jour d’un score de crédit, même si les deux évaluent un client dans un environnement numérique. Chaque contrôle a besoin de sa propre exigence de fraîcheur, car l’interaction détermine à quelle fréquence l’information pertinente doit être réévaluée.

Ces exigences peuvent ensuite devenir des accords de niveau de service, ou SLA, qui spécifient le service qu’un système doit fournir pour chaque cas d’usage. Chaque SLA doit énoncer l’âge tolérable des données et l’échéance de la décision avec suffisamment de clarté pour guider les choix d’ingénierie. Cela évite d’appliquer la « vitesse la plus rapide disponible » à toute l’infrastructure tout en conservant des exigences plus strictes pour les intrants urgents au sein d’un workflow plus lent.

Une échéance explicite aide aussi à distinguer l’accès rapide de la décision de copier les données dans un autre système. Les fournisseurs d’architectures modernes proposent des approches hybrides ou fédérées qui combinent des méthodes d’accès ou récupèrent les données là où elles résident déjà. Ces fournisseurs ont un intérêt commercial à vendre ces approches ; la capacité pertinente est qu’un système consommateur puisse obtenir l’information depuis son emplacement existant. Pour les décisions soumises à des délais serrés, cela peut fournir un accès rapide sans exiger que chaque intrant soit d’abord copié.

Lorsque l’échéance le permet, le commentateur recommande le traitement par lots ou la capture des changements de données, qui suit les modifications des données à leur origine. Le choix dépend du timing de la décision et de la manière dont les données doivent atteindre le système qui les utilise. La récupération, la duplication, l’ingestion et le traitement continu sont des choix d’architecture distincts ; une exigence pour l’un ne doit pas dicter tous les autres.

Ces choix donnent aux achats un critère d’acceptation concret : le système proposé peut-il fournir l’insight pertinent à temps pour la décision visée ? Le commentateur présente l’intelligence décisionnelle comme le prochain axe concurrentiel de la martech, au-delà du stockage des données, de la promotion des capacités temps réel et de la tentative de répondre immédiatement à chaque événement client. Les acheteurs peuvent concrétiser cette orientation en exigeant que chaque premium de vitesse proposé serve un SLA explicite par cas d’usage.

Points clés à retenir pour les dirigeants

• Lier les dépenses de rapidité à la valeur métier : Les acheteurs de martech ont besoin de preuves qu’une donnée plus rapide modifie une décision client avant de payer un premium temps réel. Évaluez séparément la préparation de l’infrastructure et le besoin métier de rapidité.
• Définir la fraîcheur pour chaque décision : Les responsables métier et les équipes d’ingénierie doivent établir jusqu’à quel âge chaque intrant peut aller avant que la décision ne se dégrade. Utilisez ce seuil pour définir les intervalles de traitement et évaluer les résultats.
• Budgéter les coûts de traitement récurrents : Les équipes d’architecture doivent prendre en compte les pipelines toujours actifs, les transformations, la résolution d’identité, le stockage et le rapprochement. Le traitement par lots peut réduire ces exigences lorsque l’échéance de la décision le permet.
• Séparer les intrants urgents du travail planifié : Les opérations marketing ont besoin de mises à jour presque immédiates des données de consentement et de suppression, tandis que la préparation des audiences peut tolérer des rafraîchissements horaires ou quotidiens. Attribuez à chaque intrant sa propre échéance, même au sein du même workflow.
• Transformer les échéances en exigences d’achat : Les SLA par cas d’usage donnent aux équipes d’ingénierie et d’achats des critères clairs concernant l’âge acceptable des données et le délai de livraison. Évaluez le streaming, le traitement par lots, la capture des changements de données et la récupération directe au regard de ces exigences.