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/Arquitectura

Arquitectura de referencia para una capa de decisioning

Una capa de decision se sitúa entre el plano de datos y el plano de activación. Lee el contexto del cliente desde el data warehouse o el CDP, produce una decisión clasificada y dimensionada por cliente, y escribe esa decisión en los sistemas que la ejecutan. Posee el log de decisiones y el estado del experimento, y no posee nada más.

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

Actualizado 4 August 2026 · 9 min de lectura

Solicitar demo

Definition

Capa de decisión

El componente de una pila de clientes que convierte el contexto unificado del cliente en una única acción comprometida por cliente, clasificada por valor esperado y registrada con el estado del experimento necesario para juzgarla posteriormente.

La mayoría de las pilas tienen un agujero en el medio

El stack B2C moderno está bien provisto en ambos extremos. Hay un data warehouse, generalmente un CDP, y un conjunto maduro de canales. Entre ellos hay una brecha donde se toma la decisión comercial real, y en la mayoría de las empresas esa brecha se llena con reglas de elegibilidad, límites de frecuencia y una reunión de planificación. Nada en el stack asume la frase 'este cliente debería obtener esto, y vale esta cantidad'.

El almacén lo sabe todo y no decide nada.
La plataforma de engagement decide cómo, nunca si.
Las reglas codifican las decisiones del año pasado y nunca se retiran.
Ningún sistema contiene el contrafactual, por lo que nada puede ser juzgado.

Cuatro planos

Mantener estos elementos separados es lo que hace que la pila sea reemplazable. Unir dos de ellos es lo que lleva a las organizaciones a no poder cambiar de proveedor.

01
Leer, no migrar
La capa de decisioning se suscribe al contexto donde ya reside. Cualquier arquitectura que requiera una migración de datos antes de la primera decisión ha puesto un año entre tú y el caso de ingresos.
02
Decidir en una ventana, no en cada evento
La mayoría de las decisiones B2C son diarias u horarias, no por evento. La toma de decisiones en tiempo real es genuinamente necesaria para las superficies en sesión y rara vez para las de ciclo de vida, y pagar por ella en todas partes es un error común y costoso.
03
Comprometer una decisión por cliente
El arbitraje solo significa algo si el resultado es singular. Emitir una lista clasificada y dejar que cada canal elija de ella recrea el problema original en un nuevo lugar.
04
Registrar el contrafactual con la decisión
La asignación de holdout es parte del registro de decisiones, no una ocurrencia tardía de informes. Si la asignación se reconstruye posteriormente, el plano de medición no puede ser fiable.
05
Ejecutar a través de los sistemas ya implementados.
La capa de decisioning debe llegar al cliente a través de los canales que la empresa ya utiliza, en lugar de convertirse en un nuevo canal con su propia gobernanza, plantillas y superficie de cumplimiento.

Responsabilidades y qué falla cuando se fusionan

Avión	Propietario	No debe poseer
Plano de datos	Identidad, perfiles unificados, historial de eventos, resultados. Warehouse, CDP, analítica de producto.	Prioridad comercial. Un almacén de perfiles que clasifica las acciones se vuelve imposible de razonar.
Plano de decisión	Generación de candidatos, clasificación por valor esperado, arbitraje, guardarraíles, asignación de holdout, el registro de decisiones.	Resolución de identidad o producción creativa. Ser propietario de cualquiera de ellas lo convierte en una migración de plataforma.
Plano de activación	Entrega, gobernanza de canales, creatividad, hora de envío y entregabilidad. Plataforma de engagement, superficies de producto, herramientas de atención.	Prioridad multicanal. Cada canal se optimiza a sí mismo y nada arbitra entre ellos.
Plano de medición	Integridad del holdout, ventanas, lecturas, el registro de lo que fue verdad.	El incentivo para informar favorablemente. Debe ser legible independientemente del plano de decisión.

Preguntas de revisión de arquitectura

Ejecútalas contra tu pila actual, quienquiera que la suministre.

Qué sistema único puede responder 'por qué este cliente recibió esto el martes pasado'?
¿Dónde se resuelve hoy la prioridad entre canales, y se resuelve por valor o por límite?
¿Puede la pila emitir 'ninguna acción' como una decisión de primera clase?
¿La asignación de holdout se registra en el momento de la decisión o se reconstruye en el momento de la elaboración del informe?
Si reemplazaras tu plataforma de engagement el próximo año, ¿qué porcentaje de la lógica de decisioning tendría que reconstruirse?
¿Algo en el stack registra lo que realmente sucedió, para que la próxima decisión sea mejor que la anterior?

Dos cosas en las que una capa de decisión nunca debe convertirse

Una segunda fuente de verdad. Si empieza a resolver identidades o a almacenar perfiles canónicos, ahora tiene dos sistemas que discrepan y una migración que no planeó.
Un canal. Una vez que posee plantillas, reputación de envío y revisión de cumplimiento, compite con la plataforma de engagement en lugar de dirigirla.
Un reemplazo para el almacén. Las cargas de trabajo analíticas y las cargas de trabajo de toma de decisiones tienen formas diferentes; fusionarlas ralentiza ambas.
Un motor de reglas con un modelo acoplado. Si el conjunto de Candidate actions es de autoría humana, la arquitectura está bien y el techo sigue siendo humano.

Markin es un equipo autónomo de growth-science para grandes empresas B2C. Investiga por qué el ingreso por cliente está estancado, forma sus propias hipótesis en marketing, producto, precios y salud técnica, elige la Next Best Action para cada cliente, la lanza a través de los sistemas que la empresa ya gestiona, y prueba cada una frente a un holdout aleatorizado.

Las herramientas de toma de decisiones eligen entre las acciones que tu equipo ya ha desarrollado. Markin decide qué construir.

Preguntas que hace la gente

¿Una capa de decisioning reemplaza a un CDP?: No. Un CDP resuelve la identidad y unifica perfiles; una capa de decisioning consume esos perfiles y elige acciones. Resuelven problemas diferentes y el límite es claro: si un componente decide qué debe suceder con un cliente, pertenece al plano de decisioning, y si decide quién es el cliente, pertenece al plano de datos.
¿Necesitamos decisioning en tiempo real?: Para superficies en sesión como un paywall, un checkout o una ubicación in-app, sí. Para decisiones de ciclo de vida, una ventana de decisión diaria u horaria suele ser indistinguible en el resultado y considerablemente más barata de operar. Comprar tiempo real para todo es uno de los excesos de gasto más comunes en esta categoría.
¿Dónde debería residir el registro de decisiones?: En el plano de decisión, y legible desde el almacén. Cada decisión debe incluir al cliente, la acción elegida, las alternativas consideradas, el valor esperado, las salvaguardias aplicadas y la asignación del holdout. Sin ese registro, nada más adelante puede ser auditado o mejorado.
¿Cómo evita la capa de decisioning entrar en conflicto con la lógica de journey ya existente en la plataforma de engagement?: Al convertirse en la señal de entrada en lugar de un remitente paralelo. La capa de decisioning escribe un atributo o dispara un evento, y el journey existente lo recoge. La gobernanza del canal, las reglas de frecuencia y la creatividad permanecen donde ya están, lo que también mantiene la integración reversible.

Comparar

Cómo esto se compara con las categorías que ya compras.

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

Todas las comparaciones

Seguir leyendo

Cómo las decisiones llegan al cliente

Los cuatro patrones de activación y sus ventajas e inconvenientes.

Toma de decisiones del cliente vs. CDP

El límite, argumentado en su totalidad.

Markin + Segment / Tealium

Un plano de decisión sobre un plano de datos.

Toma de decisiones del cliente: la guía

Comienza aquí si la categoría es nueva.

Arquitectura de referencia para una capa de decisioning

La mayoría de las pilas tienen un agujero en el medio

Cuatro planos

Leer, no migrar

Decidir en una ventana, no en cada evento

Comprometer una decisión por cliente

Registrar el contrafactual con la decisión

Ejecutar a través de los sistemas ya implementados.

Preguntas de revisión de arquitectura

Dos cosas en las que una capa de decisión nunca debe convertirse

Preguntas que hace la gente

Cómo esto se compara con las categorías que ya compras.

Seguir leyendo