RESOURCES/Arquitetura
Arquitetura de referência para uma camada de decisioning
Uma camada de decisioning situa-se entre o plano de dados e o plano de ativação. Lê o contexto do cliente do warehouse ou CDP, produz uma decisão classificada e dimensionada por cliente e escreve essa decisão nos sistemas que executam. Possui o log de decisão e o estado do experimento, e não possui mais nada.
Román Via-Dufresne, Co-fundador, Markin
Atualizado 4 August 2026 · 9 min de leitura
Solicitar uma demo
Definição
Camada de decisão
O componente de uma stack de cliente que transforma o contexto unificado do cliente em uma única ação comprometida por cliente, classificada por valor esperado e registrada com o estado do experimento necessário para avaliá-la posteriormente.
A maioria das stacks tem um buraco no meio
A stack B2C moderna está bem provisionada em ambas as extremidades. Existe um warehouse, geralmente um CDP, e um conjunto maduro de canais. Entre eles, há uma lacuna onde a escolha comercial real é feita, e na maioria das empresas essa lacuna é preenchida por regras de elegibilidade, limites de frequência e uma reunião de planeamento. Nada na stack possui a frase 'este cliente deve receber isto, e vale tanto'.
- O armazém sabe tudo e não decide nada.
- A plataforma de engagement decide o como, nunca o se.
- As regras codificam as decisões do ano passado e nunca são retiradas.
- Nenhum sistema detém o contrafactual, então nada pode ser julgado.
Quatro planos
Manter estes elementos separados é o que torna o stack substituível. Juntar quaisquer dois deles é como as organizações acabam por não conseguir mudar de fornecedores.
01
Ler, não migrar
A camada de decisioning assina o contexto onde ele já vive. Qualquer arquitetura que exija uma migração de dados antes da primeira decisão colocou um ano entre você e o caso de receita.
02
Decidir numa janela, não em cada evento
A maioria das decisões B2C são diárias ou horárias, não por evento. A decisão em tempo real é realmente necessária para superfícies em sessão e raramente é necessária para as do ciclo de vida, e pagar por ela em todo o lado é um erro comum e dispendioso.
03
Comprometer uma decisão por cliente
A arbitragem só significa algo se o resultado for singular. Emitir uma lista classificada e deixar cada canal escolher dela recria o problema original num novo local.
04
Registar o contrafactual com a decisão
A atribuição de holdout faz parte do registo de decisão, não uma reflexão posterior de relatórios. Se a atribuição for reconstruída posteriormente, o plano de medição não pode ser fidedigno.
05
Executar através dos sistemas já implementados.
A camada de decisioning deve chegar ao cliente através dos canais que a empresa já opera, em vez de se tornar um novo canal com sua própria governança, templates e superfície de conformidade.
Responsabilidades e o que falha quando estas são unidas
| Avião | Detém | Não deve possuir |
|---|---|---|
| Plano de dados | Identidade, perfis unificados, histórico de eventos, resultados. Warehouse, CDP, análise de produto. | Prioridade comercial. Um perfil de loja que classifica ações torna-se impossível de justificar. |
| Plano de decisão | Geração de Candidate, classificação por valor esperado, arbitragem, guardrails, atribuição de holdout, o registo de decisão. | Resolução de identidade ou produção criativa. Possuir qualquer um deles transforma-o numa migração de plataforma. |
| Plano de ativação | Entrega, governação de canais, criativos, tempo de envio e capacidade de entrega. Plataforma de engagement, superfícies de produto, ferramentas de suporte. | Prioridade multi-canal. Cada canal otimiza-se a si mesmo e nada arbitra entre eles. |
| Plano de medição | Integridade do holdout, janelas, leituras, o registo do que era verdadeiro. | O incentivo para relatar favoravelmente. Deve ser legível independentemente do plano de decisão. |
Perguntas de revisão de arquitetura
Execute-os contra a sua stack atual, quem quer que a forneça.
- Que sistema único pode responder 'porque é que este cliente recebeu isto, na terça-feira passada'?
- Onde a prioridade cross-channel é resolvida hoje, e é resolvida por valor ou por limite?
- A stack pode emitir 'no action' como uma decisão de primeira classe?
- A atribuição do holdout é registada no momento da decisão ou reconstruída no momento do relatório?
- Se substituísse a sua plataforma de engagement no próximo ano, que percentagem da lógica de decisão teria de ser reconstruída?
- Algo na stack regista o que realmente aconteceu, para que a próxima decisão seja melhor do que a anterior?
Duas coisas que uma camada de decisão nunca deve se tornar
- Uma segunda fonte de verdade. Se começar a resolver a identidade ou a armazenar perfis canónicos, agora tem dois sistemas que discordam e uma migração que não planeou.
- Um canal. Uma vez que possui modelos, reputação de envio e revisão de conformidade, compete com a plataforma de engagement em vez de a direcionar.
- Um substituto para o armazém. As cargas de trabalho analíticas e de decisioning têm formas diferentes; a sua fusão torna ambas mais lentas.
- Um motor de regras com um modelo acoplado. Se o conjunto de Candidate actions for criado por humanos, a arquitetura está bem e o limite ainda é humano.
Markin é uma equipa autónoma de growth-science para grandes empresas B2C. Investiga porque a receita por cliente está estagnada, formula as suas próprias hipóteses em marketing, produto, precificação e saúde técnica, escolhe a Next Best Action para cada cliente, lança-a através dos sistemas que a empresa já utiliza, e comprova cada uma contra um holdout aleatório.
As ferramentas de tomada de decisão escolhem entre as ações que a sua equipa já construiu. A Markin decide o que construir.
Perguntas que as pessoas fazem
- Uma decision layer substitui um CDP?
- Não. Um CDP resolve a identidade e unifica perfis; um decision layer consome esses perfis e escolhe actions. Eles resolvem problemas diferentes e o limite é claro: se um componente está a decidir o que deve acontecer a um cliente, pertence ao plano de decisão, e se está a decidir quem é o cliente, pertence ao plano de dados.
- Precisamos de real-time decisioning?
- Para superfícies durante a sessão, como um paywall, um checkout ou um posicionamento in-app, sim. Para decisões de ciclo de vida, uma janela de decisão diária ou horária é geralmente indistinguível no resultado e consideravelmente mais barata de operar. Comprar em tempo real para tudo é um dos gastos excessivos mais comuns nesta categoria.
- Onde deve residir o registo de decisões?
- No plano de decisão, e legível a partir do armazém. Cada decisão deve conter o cliente, a ação escolhida, as alternativas consideradas, o valor esperado, os guardrails aplicados e a atribuição do holdout. Sem esse registo, nada a jusante pode ser auditado ou melhorado.
- Como a camada de decisioning evita conflitos com a lógica de jornada já existente na plataforma de engagement?
- Ao tornar-se o sinal de entrada em vez de um remetente paralelo. A camada de decisão escreve um atributo ou dispara um evento, e a jornada existente o capta. A governança do canal, as regras de frequência e o criativo permanecem onde já estão, o que também mantém a integração reversível.
Comparar
Como isto se compara com as categorias que você já compra.
Neutral, side by side reads on where the decision layer sits next to the tools in your stack.
Todas as comparações- Markin vs Optimizely: executar testes vs decidir o que testarOptimizely executa os experimentos que você projeta. Markin decide quais experimentos vale a pena executar, dimensiona-os em receita e lê cada um contra um holdout.
- Markin vs desenvolvê-lo internamente: o que uma equipa pode realmente entregarConstruir uma camada de decisão internamente é possível e, por vezes, a escolha certa. Uma comparação honesta de rendimento, custo, propriedade e tempo até um número verificado.
- Next-best action vs. next-best opportunityNext-best opportunity dimensiona o que está em jogo para um cliente. Next-best action escolhe o tratamento. Por que a ordem importa e como os dois se conectam.