Des campagnes aux décisions par client
Le bloqueur n'est presque jamais le modèle. C'est l'identité, la latence, l'écriture différée (write-back), un chiffre de marge et la volonté de retenir.
5 vérifications
Cinq exigences déterminent si une première décision par client est à quelques semaines ou à quelques trimestres, et la qualité du modèle n'en fait pas partie.
Points clés
- 01Le blocage d'une première décision par client n'est presque jamais la qualité du modèle. C'est le write-back dans le canal qui exécute l'action.
- 02L'input le plus souvent manquant est une marge par action fournie par les finances, et son absence est silencieuse : le programme optimise les revenus et signale le succès.
- 03La fraîcheur des événements est généralement sur-spécifiée. La plupart des premières décisions sont confortables sur un batch quotidien, et non un stream.
- 04La résolution d'identité n'a besoin d'être complète qu'entre deux systèmes : celui qui détient le signal et celui qui exécute l'action.
- 05Le holdout est une décision de gouvernance avant d'être une décision technique, et c'est l'élément qui n'a le plus souvent pas de propriétaire désigné.
Romà Llambés · PDG, Markin · Examiné 2026-09-10 · Chaque rapport est révisé deux fois par an et ré-exécuté hors cycle chaque fois qu'une source sur laquelle il repose change. · Méthode et sources
La question
De quoi une entreprise a-t-elle réellement besoin pour passer des campagnes aux décisions par client ?
Le decisioning par client nécessite cinq éléments : une identité client unique sur tous les systèmes, des événements suffisamment récents pour la fenêtre de décision, un moyen de réécrire une décision dans le canal d'exécution, une marge par action fournie par les finances, et la volonté organisationnelle de maintenir un contrôle. La qualité du modèle est rarement la contrainte. Le write-back et les entrées de marge le sont généralement.
- Échantillon
- Évaluations de préparation des déploiements Markin et des évaluations dans de grandes bases B2C, anonymisées et rapportées comme des bloqueurs ordonnés plutôt que comme des comptes. Les exigences sont énoncées comme des seuils qu'une équipe peut vérifier par rapport à sa propre pile en un après-midi, sans notre implication.
- Période
- Évaluations menées entre le T3 2025 et le T3 2026.
- Examiné
- 2026-09-10Révisé deux fois par an
Résultats
Ce que nous avons trouvé
- 01Déploiements Markin anonymisés
L'écriture dans le canal d'exécution, et non la qualité du modèle, est le principal obstacle à une première décision par client.
Les équipes disposent généralement des données pour décider, mais n'ont pas de chemin pris en charge pour mettre la décision en œuvre. L'indice est un pilote de decisioning qui se termine par un tableau de bord que personne n'opère. Lorsque la plateforme d'engagement peut lire un attribut de profil et qu'un parcours existant peut s'y ramifier, l'écart se réduit en quelques jours ; lorsque le seul chemin est une nouvelle intégration détenue par une équipe surchargée, cela devient un trimestre.
Fais celaTeste d'abord la réécriture : définis un attribut manuellement et confirme qu'un parcours existant s'y ramifie. Fais cela avant tout travail de modélisation.
- 02Déploiements Markin anonymisés
Une marge par action fournie par les services financiers est l'apport le plus souvent manquant, et son absence est silencieuse.
Sans cela, les actions candidates sont classées en fonction des revenus attendus, ce qui favorise systématiquement les remises et les produits à faible marge. Rien ne se casse ; le programme optimise simplement la mauvaise quantité et rapporte le succès en le faisant. Une bande de marge approximative par action, convenue lors d'une seule réunion, vaut plus qu'une bande précise qui n'arrive jamais.
Fais celaDemande aux services financiers une fourchette de marge par action candidate ce trimestre, et commence avec des fourchettes plutôt que d'attendre la précision.
- 03Déploiements Markin anonymisés
Les exigences de fraîcheur des événements sont généralement sur-spécifiées. La plupart des premières décisions ont une fenêtre mesurée en jours, pas en secondes.
Les décisions de renouvellement, de win-back, d'ajustement de plan et de cross-sell sont toutes confortables en traitement par lots quotidien. Une infrastructure de streaming est réellement nécessaire pour les décisions en session et l'intervention au niveau du panier, et c'est un projet considérablement plus long. Choisir une première décision avec une fenêtre quotidienne élimine la plus grande dépendance technique du chemin critique.
Fais celaChoisis une première décision avec une fenêtre mesurée en jours. Cela élimine la plus grande dépendance technique du chemin critique.
- 04Déploiements Markin anonymisés
La résolution d'identité a rarement besoin d'être complète. Elle doit être complète sur exactement deux systèmes : celui qui détient le signal et celui qui exécute l'action.
L'identité cross-channel complète est un programme de plusieurs trimestres. Une première décision nécessite une clé de jointure fiable entre deux systèmes. Les équipes qui définissent l'identité en fonction de la décision commencent à expérimenter des mois plus tôt que les équipes qui la définissent en fonction de la roadmap.
Fais celaDéfinis l'identité pour les deux systèmes que la décision touche, et non pour la feuille de route.
- 05Déploiements Markin anonymisés
Le holdout est une exigence de gouvernance, pas une exigence technique, et c'est l'exigence la plus susceptible d'être discrètement abandonnée sous la pression.
Chaque prérequis technique a un propriétaire et un ticket. Le holdout n'a ni l'un ni l'autre, et la première fois qu'un stakeholder senior demande pourquoi un dixième de la base n'a rien reçu, il disparaît à moins que quelqu'un ne soit responsable de sa défense. Nommer ce propriétaire avant le lancement ne coûte rien et fait la différence entre un résultat mesuré et une histoire.
Fais celaNomme le propriétaire du holdout par écrit avant le début du pilote.
Graphiques et tableaux
Les données
| Exigence | Le seuil | Comment vérifier cela | Délai de clôture typique |
|---|---|---|---|
| Identité du client | Une clé de jointure fiable entre le système de signal et le système d'exécution | Prends 100 clients du système de signal et associe-les dans le système d'exécution | Jours si une clé existe, un trimestre si elle doit être créée |
| Fraîcheur des événements | signal disponible dans la fenêtre de décision, de bout en bout | Temps entre l'occurrence d'un événement réel et sa disponibilité pour le calcul de la décision. | Quelques jours pour un lot quotidien, quelques semaines à quelques mois pour le streaming |
| Write-back | Le système d'exécution peut lire un attribut ou un événement défini en externe, et quelque chose en dépend déjà. | Définit manuellement un attribut de test et confirme qu'un parcours ou une file d'attente répond | Quelques jours là où c'est pris en charge, un trimestre là où une nouvelle intégration est nécessaire |
| Marge par action | Une bande de marge par action candidate, fournie par les services financiers | Demande-le. Si cela prend plus d'une réunion, utilise des fourchettes plutôt que d'attendre | Une à deux semaines |
| Gouvernance du holdout | Un propriétaire nommé qui peut autoriser et défendre la rétention d'une tranche randomisée | Demande qui signe, et si cela a déjà été fait | Une conversation, ou jamais |
| Attribuer | Première décision bon marché | Première décision coûteuse |
|---|---|---|
| Fenêtre de décision | Jours | Secondes, en session |
| Systèmes impliqués | Deux | Quatre ou plus |
| Chemin d'exécution | Parcours existant ou branches de file d'attente sur un champ | Un nouveau canal ou une nouvelle interface doit être construit |
| Saisie de la marge | Un produit, une bande de marge | Modèle de marge du catalogue complet |
| Mesure | holdout randomisé au niveau client | Répartition géographique ou pré-post, car la base est trop petite |
Exécute-le sur tes chiffres
Vérifie ta propre préparation pour une première décision
Réponds pour la décision que tu veux exécuter en premier, et non pour ton estimation globale. Les seuils sont ceux du tableau ci-dessus.
Exigences remplies
0 / 5
Moins de trois exigences sont remplies. Choisis une première décision moins coûteuse : deux systèmes, une fenêtre de décision mesurée en jours et un chemin d'exécution qui existe déjà.
Implications
Ce que cela signifie pour la personne qui doit agir.
Propriétaire de la plateforme de données
Vérifie le write-back avant toute autre chose. Si le canal d'exécution peut déjà se ramifier sur un attribut de profil défini de l'extérieur, la première décision est à quelques semaines ; s'il a besoin d'une nouvelle intégration dans une équipe en retard, c'est un trimestre, quelle que soit la qualité des données.
Responsable growth
Définis une décision avec une seule fenêtre de décision, et non un programme. La plupart des premières décisions sont à l'aise avec un traitement par lots quotidien, donc spécifier une fraîcheur en streaming entraîne généralement un délai plutôt qu'une précision.
Sponsor exécutif
Nomme le propriétaire du holdout avant le début du pilote. C'est l'exigence qui n'a le plus souvent pas de propriétaire, et c'est une décision de gouvernance, pas une décision technique.
Méthode
Définitions qui changent la réponse
- Décision par client
- Une action choisie pour un client à un moment donné, parmi l'ensemble des actions candidates, évaluée et arbitrée les unes contre les autres. Distinct d'une campagne, qui sélectionne un segment et applique une action à l'ensemble de celui-ci.
- Fenêtre de décision
- Le temps entre l'arrivée du signal et l'action devant être entreprise pour qu'elle reste pertinente. Il fixe l'exigence de fraîcheur : une décision de même session nécessite des événements en streaming ; une décision de renouvellement est acceptable sur un traitement par lots quotidien.
- Write-back
- Le mécanisme par lequel une action choisie atteint le système qui l'exécute : un attribut sur un profil client, un champ sur un enregistrement CRM, un événement ou un appel API. Sans cela, une décision n'est qu'une recommandation dans un tableau de bord.
- Préparation
- Pas la maturité des données dans l'abstrait. La question spécifique de savoir si ces cinq exigences sont satisfaites pour la seule décision que tu souhaites exécuter en premier, ce qui est un seuil beaucoup plus bas qu'un programme CDP complet.
Estimateur
Le modèle, écrit en entier
Temps jusqu'à une première décision par client en production, et quelle exigence se trouve sur son chemin critique. Le résultat est un classement des bloqueurs, et non un score.
Temps jusqu'à la première décision
T = max(t_identity, t_freshness, t_writeback, t_margin, t_holdout)
Un maximum, pas une somme, car les cinq exigences sont travaillées en parallèle par différentes personnes. Un élément en retard fixe la date à lui seul.
Classement des bloqueurs
rank(i) = share of assessments where t_i = T
Une exigence est le bloquant lorsqu'elle est celle qui a été terminée en dernier, et non lorsqu'elle était difficile.
Où le maximum devient une somme
T = t_identity + t_writeback when write-back needs resolved identity
Les dépendances entre les exigences sont la raison pour laquelle un projet qui semblait durer six semaines s'étend sur deux trimestres.
Ce qui doit tenir
- La portée est une décision, pas un programme. Chaque seuil de ce rapport est défini pour cette portée.
- Les cinq exigences sont séparables et travaillées en parallèle par des équipes qui existent déjà.
- La fraîcheur est jugée par rapport à la fenêtre de décision de cette seule décision, et non par rapport à une ambition générale de données en temps réel.
Ce qui le casse
- Des exigences qui se bloquent mutuellement, ce qui transforme le maximum en une somme.
- Une base réglementée où le consentement et la limitation de la finalité deviennent une sixième exigence et généralement la première.
- Pas d'entrepôt de données ni de flux d'événements, ce qui est un problème antérieur à n'importe lequel des cinq.
- Arbitrage entre de nombreuses décisions simultanées, ce qui ajoute des exigences de gouvernance que ce modèle ne couvre pas.
Méthode
Comment reproduire ceci
- 01
Choisis une décision, pas un programme. Note sa fenêtre de décision en heures.
- 02
Vérifie l'identité : peux-tu résoudre le même client à travers le système détenant le signal et le système exécutant l'action, sans jointure manuelle ?
- 03
Vérifie la fraîcheur : le signal est-il disponible dans la fenêtre de decisioning, de bout en bout, y compris le chargement vers l'endroit où la décision est calculée ?
- 04
Vérifie la réécriture : le système d'exécution peut-il lire un champ ou un événement défini par quelque chose d'extérieur, et un parcours ou une file d'attente réagit-il déjà à ce champ ?
- 05
Vérifie la marge : les finances peuvent-elles fournir une marge par action candidate ce trimestre ? Si ce n'est pas le cas, les décisions seront classées en fonction des revenus et dériveront vers des actions à faible marge.
- 06
Vérifie le holdout : y a-t-il un propriétaire agréé qui peut autoriser la rétention de l'action pour une tranche randomisée pendant une fenêtre complète, et la défendre quand quelqu'un demande pourquoi 10 % des clients n'ont rien obtenu ?
Incertitude
À quel point chaque chiffre pourrait être erroné
Un petit ensemble d'évaluations non aléatoires. Nous publions un classement et refusons de publier des pourcentages, car à cette taille d'échantillon, un pourcentage impliquerait une précision que nous n'avons pas. L'énoncé d'incertitude ci-dessous concerne la stabilité du classement, et non un intervalle de confiance.
Le write-back classé premier
Il reste premier dans chaque sous-ensemble des évaluations que nous pouvons former, et dans les deux secteurs représentés.
stable
Les inputs de marge classés deuxièmes
La marge est rarement l'élément le plus lent. Elle est classée haut parce que son absence est silencieuse : le programme est déployé, optimise les revenus et rapporte le succès.
stable, mais pour une raison différente
Identité et fraîcheur
Leur ordre s'échange par secteur, il faut donc les traiter comme une paire liée plutôt que comme les rangs trois et quatre.
interchangeable
Semaines contre trimestres
La distribution est bimodale plutôt qu'étalée. Une première décision est soit prise en charge par l'infrastructure existante, soit attend un élément de la feuille de route appartenant à une autre équipe.
2 à 6 semaines, ou 3 à 9 mois
Robustesse
Ce qui survit à une hypothèse différente
Chaque ligne modifie le contexte et redérive quelle exigence se trouve sur le chemin critique.
| Change une hypothèse | Ce qui change | Résultat | Conclusion |
|---|---|---|---|
| La plateforme d'engagement peut lire un attribut de profil | Le write-back existe déjà | La gouvernance du holdout devient un obstacle. Le temps tombe dans la catégorie des semaines. | Inversions |
| Base réglementée, consentement par finalité | Une sixième exigence est ajoutée | Le consentement est classé en premier et l'ordre en dessous reste inchangé. | Inversions |
| Canal uniquement par lot, envoi quotidien | La fenêtre de décision s'élargit à 24 heures | La fraîcheur disparaît entièrement du chemin critique. L'ordre est inchangé par ailleurs. | Maintiens |
| L'équipe exécute déjà des tests randomisés | La gouvernance du holdout est établie | Ordre inchangé. La variance de la date de livraison se réduit fortement. | Maintiens |
| Pas d'entrepôt de données, pas de flux d'événements | Prérequis manquant | Le modèle ne s'applique pas. C'est un projet de plateforme de données, pas un projet de decisioning. | Inversions |
Le write-back reste en première position dans tous les scénarios où il n'est pas déjà résolu, et la marge reste l'exigence dont l'absence cause le plus de dégâts par unité d'attention qu'elle reçoit. Ce qui bouge, c'est la date de livraison, pas l'ordre. Lis ceci comme une checklist à appliquer à une décision, jamais comme un score de maturité.
Limites
Ce que cela ne peut pas te dire
- Il s'agit d'un classement des bloqueurs, et non d'une mesure de leur fréquence. Nous n'avons délibérément pas publié de décomptes, car l'échantillon est suffisamment petit pour qu'un pourcentage implique une précision que nous n'avons pas.
- Les évaluations concernent des entreprises qui envisageaient déjà le decisioning, ce qui sélectionne un certain niveau de maturité des données. Une base sans entrepôt de données ni flux d'événements est confrontée à un problème plus précoce que n'importe lequel de ceux-ci.
- Les exigences sont énoncées pour la première décision. Exécuter cinquante décisions avec arbitrage entre elles ajoute des exigences de gouvernance et de pression de contact que ce rapport ne couvre pas.
- Rien ici n'est spécifique à Markin. Toute approche de decisioning, construite ou achetée, est confrontée aux mêmes cinq points.
Réfutabilité
Ce qui nous ferait changer d'avis
- 01
Un ensemble de déploiements où la qualité du modèle, et non le write-back, était la contrainte principale sur la première décision.
- 02
Preuve que les équipes, même sans marge par action fournie par la finance, évitent de s'orienter vers les remises et les produits à faible marge.
- 03
Premières décisions qui nécessitent de routine une fraîcheur de moins d'une heure. Cela placerait la latence des événements avant la réécriture dans l'ordre.
Provenance
Sources, et à quoi chacune a servi
- Déploiements Markin anonymisésÉvaluations de la préparation anonymisées à travers les déploiements et les évaluations Markin
L'ordre des bloqueurs et les définitions des seuils. Aucun décompte ou pourcentage n'en est publié.
- Dérivé dans ce rapportSeuils d'exigence
Les deux tableaux. Chaque vérification est rédigée de manière à ce qu'un lecteur puisse l'exécuter sans nous.
Questions auxquelles ce rapport répond
- De quoi avons-nous besoin avant de pouvoir prendre des décisions par client ?
- Pourquoi les projets de personnalisation stagnent-ils après la construction du modèle ?
- Avons-nous besoin de données en temps réel pour la next best action ?
- Comment passer des campagnes aux décisions 1:1 ?
- Quel est le cas d'usage initial le plus rapide pour le decisioning ?
Questions fréquentes
- De quoi une entreprise a-t-elle besoin pour passer des campagnes aux décisions par client ?
- Cinq choses : une identité fiable entre le système de signaux et le système d'exécution, des événements suffisamment récents pour la fenêtre de décision, un chemin de write-back supporté vers le canal d'exécution, une marge par action candidate fournie par les finances, et un propriétaire nommé pour le holdout randomisé.
- Avons-nous besoin de données en temps réel ?
- Généralement pas pour une première décision. Les décisions de renouvellement, de win-back, d'adéquation au plan et de cross-sell ont des fenêtres de quelques jours et s'exécutent confortablement sur un traitement par lots quotidien. Le streaming est véritablement nécessaire pour les décisions en session et au niveau du panier, et c'est un projet beaucoup plus long.
- Avons-nous besoin d'un CDP d'abord ?
- Non. Un CDP résout l'identité et l'activation sur l'ensemble du domaine, ce qui est un programme de plusieurs trimestres. Une première décision nécessite une clé de jointure entre deux systèmes et un chemin de write-back pris en charge. Le fait de circonscrire l'identité à la décision plutôt qu'à la feuille de route permet aux équipes d'expérimenter des mois plus tôt.
- Pourquoi l'absence de chiffre de marge est-elle si importante ?
- Parce que sans cela, les actions sont classées en fonction des revenus attendus, ce qui favorise systématiquement les réductions et les produits à faible marge. Rien ne semble visiblement cassé. Le programme optimise la mauvaise quantité et rapporte de la growth alors que la marge de contribution reste stable.
- Ces chiffres proviennent-ils des clients Markin ?
- Il n'y a pas de chiffres. Les découvertes sont un classement des bloqueurs issus d'évaluations de préparation anonymisées, publiées en tant que classement précisément parce que l'échantillon est trop petit pour des pourcentages. Les seuils dans les tableaux sont des vérifications que tu peux effectuer toi-même, sur ta propre stack, sans nous.
Agis là-dessus
- ManuelAjoute une next best action aux parcours que tu exécutes déjà dans BrazeArbitrage par client inscrit dans les canevas que ton équipe utilise déjà.
- ManuelRegagne des clients inactifs avec une fenêtre de silence au lieu d'une échelle de réductionsRéactivation synchronisée sur l'intention de retour, non sur les jours depuis la dernière commande.
- RechercheConcevoir un holdout qui peut réellement détecter un uplift d'ARPULa plupart des expérimentations d'ARPU ne sont pas peu concluantes. Elles manquaient de puissance le jour où elles ont été conçues, et personne ne l'a calculé.
- RechercheRevenus porteurs de margeChaque décision de growth de cette liste augmente les revenus déclarés. Quatre d'entre elles augmentent la marge de contribution. Ce ne sont pas les quatre mêmes que la plupart des équipes priorisent.
- GuideComment l'IA peut-elle unifier les données CRM, produit et fidélité ?Résolution d'identité, une timeline par client, préséance explicite des attributs et la décision qui justifie le coût de l'unification.
- GuideArchitecture de référence pour une couche de décisionLà où une couche de décision se situe entre ton entrepôt, ton CDP et tes canaux, ce qu'elle doit posséder et ce qu'elle ne doit jamais essayer de posséder.
- GuideComment les décisions atteignent le clientLes modèles d'activation dont une couche de decisioning a besoin : écriture des attributs, événements déclenchés, API de décision en temps réel et surfaces produit. Avec des compromis.