Does a decision layer replace a CDP?

No. A CDP resolves identity and unifies profiles; a decision layer consumes those profiles and chooses actions. They solve different problems and the boundary is clean: if a component is deciding what should happen to a customer, it belongs in the decision plane, and if it is deciding who the customer is, it belongs in the data plane.

Do we need real-time decisioning?

For in-session surfaces such as a paywall, a checkout or an in-app placement, yes. For lifecycle decisions, a daily or hourly decision window is usually indistinguishable in outcome and considerably cheaper to operate. Buying real-time for everything is one of the most common overspends in this category.

Where should the decision log live?

In the decision plane, and readable from the warehouse. Every decision should carry the customer, the chosen action, the alternatives considered, the expected value, the guardrails applied and the holdout assignment. Without that record, nothing downstream can be audited or improved.

How does the decision layer avoid conflicting with journey logic already in the engagement platform?

By becoming the entry signal rather than a parallel sender. The decision layer writes an attribute or fires an event, and the existing journey picks it up. Channel governance, frequency rules and creative stay where they already are, which is also what keeps the integration reversible.

Is Markin a replacement for Braze?

No. Braze is an engagement platform: it builds, personalises and delivers journeys, and BrazeAI Decisioning Studio chooses the best message, channel and timing inside them. Markin sits above that. It decides which commercial opportunity is worth pursuing for each customer in the first place, including opportunities that are not messages at all, such as a pricing change, an onboarding fix or a payment failure. When the answer is a message, Markin launches it through Braze.

How is Markin different from AI decisioning inside an engagement platform?

AI decisioning selects between actions a marketer already created, inside the channels that platform owns. Markin authors the hypotheses itself and is not limited to the campaign surface: marketing, product, pricing and technical health are all in scope. It then executes inside the systems already in place and reads every decision against a randomised holdout, which is how a data science team works rather than how an optimiser works.

No. A CDP unifies and distributes customer data. Markin consumes that data and decides what to do with it. Markin has no ambition to be your source of truth, and it does not require you to replace one. If a CDP or a warehouse already holds customer context, Markin reads from it.

Does Markin replace my data science or growth team?

No. Markin removes the arithmetic constraint on how many hypotheses can be tested, not the judgement about which constraints, economics and risks matter. Teams using Markin move from producing analyses to setting guardrails, interpreting results and deciding what gets scaled.

RESOURCES/Architecture

Architecture de référence pour une couche de décision

Une couche de décision se situe entre le plan de données et le plan d'activation. Elle lit le contexte client de l'entrepôt ou du CDP, produit une décision classée et dimensionnée par client, et écrit cette décision dans les systèmes qui exécutent. Elle gère le journal de décision et l'état de l'expérimentation, et rien d'autre.

Román Via-Dufresne, Co-fondateur, Markin

Mis à jour 4 August 2026 · 9 min de lecture

Demander une démo

Définition

Couche de décision

Le composant d'une stack client qui transforme le contexte client unifié en une action unique engagée par client, classée par valeur attendue et enregistrée avec l'état d'expérimentation nécessaire pour la juger plus tard.

La plupart des piles ont un trou au milieu

La stack B2C moderne est bien pourvue aux deux extrémités. Il y a un entrepôt, généralement un CDP, et un ensemble mature de canaux. Entre les deux se trouve un fossé où le choix commercial réel est fait, et dans la plupart des entreprises, ce fossé est comblé par des règles d'éligibilité, des plafonds de fréquence et une réunion de planification. Rien dans la stack ne porte la phrase 'ce client devrait recevoir ceci, et cela vaut tant'.

L'entrepôt sait tout et ne décide rien.
La plateforme d'engagement décide comment, jamais si.
Les règles encodent les décisions de l'année dernière et ne sont jamais retirées.
Aucun système ne détient le contrefactuel, donc rien ne peut être jugé.

Quatre plans

C'est en les gardant séparés que la pile est remplaçable. C'est en fusionnant deux d'entre eux que les organisations se retrouvent incapables de changer de fournisseurs.

01
Lire, ne pas migrer
La couche de decisioning s'abonne au contexte là où il existe déjà. Toute architecture qui exige une migration de données avant la première décision crée un délai d'un an entre toi et l'opportunité de revenus.
02
Décider sur une fenêtre, pas sur chaque événement
La plupart des décisions B2C sont quotidiennes ou horaires, et non par événement. La décision en temps réel est véritablement requise pour les interfaces en session et rarement pour celles du cycle de vie, et payer pour cela partout est une erreur courante et coûteuse.
03
Engager une décision par client
L'Arbitrage n'a de sens que si le résultat est singulier. Émettre une liste classée et laisser chaque canal choisir parmi elle recrée le problème original à un nouvel endroit.
04
Enregistrer le contrefactuel avec la décision
L'assignation holdout fait partie de l'enregistrement de la décision, et non une réflexion après coup en matière de reporting. Si l'assignation est reconstituée ultérieurement, le plan de mesure ne peut pas être fiable.
05
Exécuter via les systèmes déjà en place
La couche de decisioning doit atteindre le client via les canaux déjà exploités par l'entreprise, plutôt que de devenir un nouveau canal avec sa propre gouvernance, ses modèles et sa surface de conformité.

Responsabilités, et ce qui casse quand elles sont fusionnées

Avion	Possède	Ne doit pas posséder
Plan de données	Identité, profils unifiés, historique des événements, résultats. Entrepôt, CDP, analyse produit.	Priorité commerciale. Un magasin de profils qui classe les actions devient impossible à analyser.
Plan de décision	Génération de candidats, classement par valeur attendue, arbitrage, garde-fous, attribution de holdout, journal de décision.	Résolution d'identité ou production créative. Posséder l'une ou l'autre en fait une migration de plateforme.
Plan d'activation	Livraison, gouvernance des canaux, création, heure d'envoi et délivrabilité. Plateforme d'engagement, surfaces produit, outils de service client.	Priorité multi-canal. Chaque canal s'optimise et rien n'arbitre entre eux.
Plan de mesure	Intégrité holdout, fenêtres, readouts, le registre de ce qui était vrai.	L'incitation à faire un rapport favorable. Il devrait être lisible indépendamment du plan de décision.

Questions d'examen d'architecture

Fais-les fonctionner avec ta pile actuelle, quel que soit le fournisseur.

Quel système unique peut répondre à 'pourquoi ce client a-t-il reçu cela, mardi dernier' ?
Où la priorité cross-channel est-elle résolue aujourd'hui, et est-elle résolue par la valeur ou par un plafond ?
La stack peut-elle émettre une 'no action' comme décision de premier ordre ?
L'attribution du holdout est-elle enregistrée au moment de la décision ou reconstituée au moment du reporting ?
Si tu remplaçais ta plateforme d'engagement l'année prochaine, quel pourcentage de la logique de décision devrait être reconstruite ?
Y a-t-il un élément de la pile qui enregistre ce qui s'est réellement passé, afin que la prochaine décision soit meilleure que la précédente ?

Deux choses qu'une couche de décision ne doit jamais devenir

Une deuxième source de vérité. Si elle commence à résoudre l'identité ou à stocker des profils canoniques, tu auras désormais deux systèmes en désaccord et une migration que tu n'avais pas prévue.
Un canal. Une fois qu'il possède les modèles, la réputation d'envoi et la révision de conformité, il rivalise avec la plateforme d'engagement au lieu de la diriger.
Un remplacement de l'entrepôt. Les charges de travail analytiques et les charges de travail de décision ont des formes différentes ; les fusionner rend les deux plus lentes.
Un moteur de règles auquel un modèle est boulonné. Si l'ensemble de candidats est rédigé par un humain, l'architecture est bonne et le plafond reste humain.

Markin est une équipe growth-science autonome pour les grandes entreprises B2C. Il investigue pourquoi les revenus par client sont bloqués, formule ses propres hypothèses à travers le marketing, le produit, la tarification et la santé technique, choisit la Next Best Action pour chaque client, la lance via les systèmes que l'entreprise utilise déjà, et prouve chacune d'entre elles par rapport à un holdout randomisé.

Les outils de decisioning choisissent parmi les actions que ton équipe a déjà mises en place. Markin décide ce qu'il faut construire.

Questions que les gens se posent

Une couche de decisioning remplace-t-elle un CDP ?: Non. Un CDP résout l'identité et unifie les profils ; une couche de decisioning consomme ces profils et choisit les actions. Ils résolvent des problèmes différents et la frontière est claire : si un composant décide de ce qui doit arriver à un client, il appartient au plan de decisioning, et s'il décide qui est le client, il appartient au plan de données.
Avons-nous besoin d'une prise de décision en temps réel ?: Pour les surfaces en session telles qu'un paywall, une page de paiement ou un emplacement in-app, oui. Pour les décisions de cycle de vie, une fenêtre de décision quotidienne ou horaire est généralement indiscernable en termes de résultats et considérablement moins chère à opérer. Acheter du temps réel pour tout est l'une des dépenses excessives les plus courantes dans cette catégorie.
Où devrait se trouver le journal de décision ?: Dans le plan de décision, et lisible depuis l'entrepôt de données. Chaque décision doit inclure le client, l'action choisie, les alternatives envisagées, la valeur attendue, les garde-fous appliqués et l'attribution au holdout. Sans cet enregistrement, rien en aval ne peut être audité ou amélioré.
Comment la couche de décision évite-t-elle les conflits avec la logique de parcours déjà présente dans la plateforme d'engagement ?: En devenant le signal d'entrée plutôt qu'un expéditeur parallèle. La couche de décision écrit un attribut ou déclenche un événement, et le parcours existant le récupère. La gouvernance des canaux, les règles de fréquence et la création restent là où elles sont déjà, ce qui maintient également l'intégration réversible.

Comparer

Comment cela se présente par rapport aux catégories que tu achètes déjà.

Neutral, side by side reads on where the decision layer sits next to the tools in your stack.

Toutes les comparaisons

Continuer la lecture

Comment les décisions atteignent le client

Les quatre modèles d'activation et leurs compromis.

Décision client vs. CDP

La limite, entièrement argumentée.

Markin + Segment / Tealium

Un plan de décision au-dessus d'un plan de données.

Décision client : le guide

Commencez ici si la catégorie est nouvelle.

Architecture de référence pour une couche de décision

La plupart des piles ont un trou au milieu

Quatre plans

Lire, ne pas migrer

Décider sur une fenêtre, pas sur chaque événement

Engager une décision par client

Enregistrer le contrefactuel avec la décision

Exécuter via les systèmes déjà en place

Questions d'examen d'architecture

Deux choses qu'une couche de décision ne doit jamais devenir

Questions que les gens se posent

Comment cela se présente par rapport aux catégories que tu achètes déjà.

Continuer la lecture