De campanhas a decisões por cliente
O bloqueador quase nunca é o modelo. É a identidade, a latência, a gravação de dados (write-back), um número de margem e a disposição de reter.
5 verificações
Cinco requisitos decidem se uma primeira decisão por cliente está a semanas ou trimestres de distância, e a qualidade do modelo não é um deles.
Principais conclusões
- 01O bloqueador para uma primeira decisão por cliente quase nunca é a qualidade do modelo. É o write-back para o canal que executa a ação.
- 02O input mais frequentemente em falta é uma margem por ação fornecida pelas finanças, e a sua ausência é silenciosa: o programa otimiza a receita e reporta o sucesso.
- 03A frescura do evento é geralmente sobre-especificada. A maioria das primeiras decisões é confortável com um lote diário, não com um stream.
- 04A resolução de identidade só precisa de ser completa em dois sistemas: o que detém o sinal e o que executa a ação.
- 05O holdout é uma decisão de governação antes de ser uma decisão técnica, e é o item que mais frequentemente não tem um proprietário nomeado.
Romà Llambés · CEO, Markin · Revisto 2026-09-10 · Cada relatório é revisto duas vezes por ano e reexecutado fora de ciclo sempre que uma fonte na qual se baseia muda. · Método e fontes
A pergunta
De que precisa uma empresa para passar de campanhas para decisions por cliente?
O decisioning por cliente precisa de cinco coisas: uma identidade de cliente entre sistemas, eventos suficientemente recentes para a janela de decisão, uma forma de escrever uma decisão de volta para o canal de execução, uma margem fornecida pelas finanças por ação e a vontade organizacional de manter um controlo. A qualidade do modelo raramente é a restrição. Os inputs de write-back e margem geralmente são.
- Amostra
- Avaliações de prontidão em implementações e avaliações da Markin em grandes bases B2C, anonimizadas e reportadas como bloqueadores ordenados em vez de contagens. Os requisitos são apresentados como thresholds que uma equipa pode verificar em relação à sua própria stack numa tarde, sem o nosso envolvimento.
- Período
- Avaliações realizadas entre o 3º trimestre de 2025 e o 3º trimestre de 2026.
- Revisto
- 2026-09-10Revisto duas vezes por ano
Resultados
O que encontrámos
- 01Implementações Markin anonimizadas
A gravação de volta no canal de execução, e não a qualidade do modelo, é o bloqueador mais comum para uma primeira decisão por cliente.
As equipas rotineiramente têm os dados para decidir, mas nenhum caminho suportado para que a decisão atue. O sinal é um piloto de decisioning que termina num dashboard que ninguém opera. Onde a plataforma de envolvimento pode ler um atributo de perfil e uma jornada existente pode ramificar-se com base nele, a lacuna fecha em dias; onde o único caminho é uma nova integração detida por uma equipa com backlog, torna-se um trimestre.
Faça istoTesta o write-back primeiro: define um atributo manualmente e confirma que uma jornada existente se ramifica nele. Faz isso antes de qualquer trabalho de modelagem.
- 02Implementações Markin anonimizadas
Uma margem por ação fornecida pelas finanças é a entrada que mais frequentemente falta, e a sua ausência é silenciosa.
Sem isso, as ações candidatas são classificadas com base na receita esperada, o que favorece sistematicamente descontos e produtos de baixa margem. Nada quebra; o programa simplesmente otimiza a quantidade errada e relata sucesso ao fazê-lo. Uma faixa de margem aproximada por ação, acordada numa única reunião, vale mais do que uma precisa que nunca chega.
Faça istoPeça ao financeiro uma faixa de margem por ação candidata neste trimestre e comece com faixas em vez de esperar pela precisão.
- 03Implementações Markin anonimizadas
Os requisitos de frescura do evento são geralmente excessivamente especificados. A maioria das primeiras decisões tem uma janela medida em dias, não em segundos.
As decisões de renovação, win-back, ajuste de plano e cross-sell são todas confortáveis com um lote diário. A infraestrutura de streaming é genuinamente necessária para decisões intra-sessão e intervenção ao nível do carrinho, e é um projeto substancialmente mais longo. Escolher uma primeira decisão com uma janela diária remove a maior dependência de engenharia do caminho crítico.
Faça istoEscolha uma primeira decisão com uma janela medida em dias. Isso remove a maior dependência de engenharia do caminho crítico.
- 04Implementações Markin anonimizadas
A resolução de identidade raramente precisa ser completa. Ela precisa ser completa em exatamente dois sistemas: aquele que detém o sinal e aquele que executa a ação.
A identidade cross-channel completa é um programa de vários trimestres. Uma primeira decisão precisa de uma chave de junção fiável entre dois sistemas. As equipas que limitam a identidade à decisão começam a experimentar meses antes das equipas que a limitam ao roadmap.
Faça istoDelimita a identidade aos dois sistemas que a decisão afeta, não ao roteiro.
- 05Implementações Markin anonimizadas
O holdout é um requisito de governação, não técnico, e é o requisito que mais provavelmente será silenciosamente descontinuado sob pressão.
Cada pré-requisito técnico tem um proprietário e um ticket. O holdout não tem nenhum dos dois, e na primeira vez que um stakeholder sénior pergunta porque um décimo da base não recebeu nada, ele desaparece, a menos que alguém seja responsável por defendê-lo. Nomear esse proprietário antes do lançamento não custa nada e é a diferença entre um resultado medido e uma história.
Faça istoNomeie o proprietário do holdout antes do início do piloto, por escrito.
Gráficos e tabelas
Os dados
| Requisito | O limiar | Como verificar isso | Tempo típico para fechar |
|---|---|---|---|
| Identidade do cliente | Uma chave de junção fiável entre o sistema de sinais e o sistema de execução | Pegue 100 clientes do sistema de sinal e combine-os no sistema de execução | Dias se existir uma chave, um trimestre se tiver de ser criada |
| Frescura do evento | Sinal disponível dentro da janela de decisão, de ponta a ponta | Cronometrar um evento real desde a ocorrência até à disponibilidade onde a decisão é calculada. | Dias para batch diário, semanas a meses para streaming |
| Write-back | O sistema de execução pode ler um atributo ou evento definido externamente, e algo já se ramifica a partir dele. | Defina um atributo de teste manualmente e confirme se uma jornada ou fila responde | Dias onde é suportado, um trimestre onde uma nova integração é necessária |
| Margem por ação | Uma faixa de margem por ação candidata, fornecida pelas finanças | Peça. Se demorar mais de uma reunião, use faixas em vez de esperar | Uma a duas semanas |
| Governança de holdout | Um proprietário nomeado que pode autorizar e defender a retenção de uma fatia aleatorizada | Pergunte quem aprova e se já o fizeram antes | Uma conversa, ou nunca |
| Atributo | Primeira decisão barata | Primeira decisão cara |
|---|---|---|
| Janela de decisão | Dias | Segundos, em sessão |
| Sistemas envolvidos | Dois | Quatro ou mais |
| Caminho de execução | Jornada existente ou branches de fila num campo | Novo canal ou nova superfície tem de ser construído |
| Input de margem | Um produto, uma faixa de margem | Modelo de margem de catálogo completo |
| Medição | holdout aleatório ao nível do cliente | Divisão geográfica ou pré-pós, porque a base é muito pequena |
Execute com os seus números
Verifique a sua própria prontidão para uma primeira decisão
Responda para a decisão que você deseja executar primeiro, não para a sua estimativa como um todo. Os limites são os da tabela acima.
Requisitos cumpridos
0 / 5
Menos de três requisitos cumpridos. Escolha uma primeira decisão mais económica: dois sistemas, uma janela de decisão medida em dias e um caminho de execução que já existe.
Implicações
O que isto significa para a pessoa que tem de agir
Proprietário da plataforma de dados
Verifique o write-back antes de tudo. Se o canal de execução já pode ramificar com base num atributo de perfil definido externamente, a primeira decisão está a semanas de distância; se precisar de uma nova integração numa equipa com atraso, é um trimestre, independentemente de quão bons sejam os dados.
Líder de growth
Delimita uma decisão com uma janela de decisão, não um programa. A maioria das primeiras decisões é confortável num lote diário, então especificar a atualização de streaming geralmente causa atraso em vez de precisão.
Patrocinador executivo
Nomeie o proprietário do holdout antes do início do piloto. É o requisito que mais frequentemente não tem proprietário, e é uma decisão de governança, não técnica.
Método
Definições que alteram a resposta
- Decisão por cliente
- Uma ação escolhida para um cliente num determinado momento, do conjunto completo de ações candidatas, avaliadas e arbitradas entre si. Distinto de uma campanha, que seleciona um segmento e aplica uma ação a todo ele.
- Janela de decisão
- O tempo entre a chegada do sinal e a necessidade de realizar a ação para que esta ainda seja relevante. Define o requisito de frescura: uma decisão na mesma sessão requer streaming events; uma decisão de renovação funciona bem com um batch diário.
- Write-back
- O mecanismo pelo qual uma ação candidata alcança o sistema que a executa: um atributo num perfil de cliente, um campo num registo de CRM, um evento ou uma chamada de API. Sem isso, uma decisão é uma recomendação num dashboard.
- Prontidão
- Não a maturidade de dados no abstrato. A questão específica de saber se estes cinco requisitos são cumpridos para a única decisão que você quer executar primeiro, o que é um patamar muito mais baixo do que um programa CDP completo.
Estimador
O modelo, escrito
Tempo para uma primeira decisão por cliente em produção, e qual requisito está no seu caminho crítico. O output é uma ordenação de bloqueadores, não uma pontuação.
Tempo para a primeira decisão
T = max(t_identity, t_freshness, t_writeback, t_margin, t_holdout)
Um máximo, não uma soma, porque os cinco requisitos são trabalhados em paralelo por pessoas diferentes. Um item atrasado define a data por si só.
Classificação de bloqueador
rank(i) = share of assessments where t_i = T
Um requisito é o bloqueador quando é o que terminou por último, não quando foi difícil.
Onde o máximo se torna uma soma
T = t_identity + t_writeback when write-back needs resolved identity
As dependências entre os requisitos são a razão pela qual um projeto que parecia seis semanas acaba em dois trimestres.
O que tem de aguentar
- O âmbito é uma decisão, não um programa. Cada limiar neste relatório é declarado para esse âmbito.
- Os cinco requisitos são separáveis e trabalhados em paralelo por equipas que já existem.
- A freshness é julgada em relação à janela de decisão dessa única decisão, e não em relação a uma ambição geral por dados em tempo real.
O que o quebra
- Requisitos que se bloqueiam mutuamente, o que transforma o máximo numa soma.
- Uma base regulamentada onde o consentimento e a limitação da finalidade se tornam um sexto requisito e geralmente o primeiro.
- Sem warehouse e sem event stream, o que é um problema anterior a qualquer um dos cinco.
- Arbitragem entre muitas decisões simultâneas, o que adiciona requisitos de governança que este modelo não abrange.
Método
Como reproduzir isso
- 01
Escolha uma decisão, não um programa. Anote a sua janela de decisão em horas.
- 02
Verifique a identidade: consegue resolver o mesmo cliente em todo o sistema que detém o sinal e no sistema que executa a ação, sem uma junção manual?
- 03
Verifique a atualidade: o sinal está disponível dentro da janela de decisão, de ponta a ponta, incluindo o carregamento para onde quer que a decisão seja computada?
- 04
Verifique a gravação: o sistema executor pode ler um campo ou evento definido por algo externo a ele, e uma jornada ou fila já responde a esse campo?
- 05
Verifique a margem: as finanças podem fornecer uma margem por ação candidata este trimestre? Caso contrário, as decisões serão classificadas com base na receita e irão desviar-se para ações de baixa margem.
- 06
Verifique o holdout: existe um proprietário acordado que pode autorizar a retenção da ação de uma fatia aleatória por uma janela completa e defendê-lo quando alguém perguntar por que 10% dos clientes não receberam nada?
Incerteza
Quão errada cada figura poderia estar
Um conjunto pequeno e não aleatório de avaliações. Publicamos uma ordenação e recusamo-nos a publicar percentagens, porque com este tamanho de amostra uma percentagem implicaria uma precisão que não temos. A declaração de incerteza abaixo é sobre a estabilidade da ordenação, não sobre um intervalo de confiança.
Write-back classificado em primeiro lugar
Mantém-se em primeiro lugar em todos os subconjuntos das avaliações que podemos formar, e em ambos os setores representados.
stable
Inputs de margem classificados em segundo lugar
A margem raramente é o item mais lento. Ela ocupa uma posição elevada porque a sua ausência é silenciosa: o programa é implementado, otimiza a receita e relata sucesso.
estável, mas por uma razão diferente
Identidade e freshness
A sua ordem troca por setor, então trate-os como um par empatado, em vez de classificações três e quatro.
interchangeable
Semanas versus trimestres
A distribuição é bimodal em vez de dispersa. Uma primeira decisão é resolvida com a infraestrutura existente ou espera por um item do roadmap de outra equipa.
2 a 6 semanas, ou 3 a 9 meses
Robustez
O que sobrevive a uma suposição diferente
Cada linha muda o contexto e redefine qual requisito está no caminho crítico.
| Mude uma premissa | O que muda | Resultado | Conclusão |
|---|---|---|---|
| A plataforma de engagement pode ler um atributo de perfil | Write-back já existe | A governança do holdout torna-se o obstáculo. O tempo passa a ser medido em semanas. | Inversões |
| Base regulada, consentimento por finalidade | Um sexto requisito é adicionado | O consentimento classifica-se em primeiro lugar e a ordenação abaixo dele permanece inalterada. | Inversões |
| Canal apenas por lote, envio diário | Janela de decisão alarga para 24 horas | A freshness sai completamente do caminho crítico. A ordenação permanece inalterada. | Retenções |
| A equipa já executa testes randomizados | A governança do holdout está estabelecida | Ordenação inalterada. A variação na data de entrega diminui drasticamente. | Retenções |
| Sem warehouse, sem event stream | Pré-requisito em falta | O modelo não se aplica. Isso é um projeto de data platform, não de decisioning. | Inversões |
Write-back permanece em primeiro lugar em todos os cenários onde ainda não foi resolvido, e a margem continua a ser o requisito cuja ausência causa o maior dano por unidade de atenção que recebe. O que muda é a data de entrega, não a ordem. Leia isto como uma checklist para executar contra uma decisão, nunca como uma pontuação de maturidade.
Limites
O que isto não lhe pode dizer
- Esta é uma ordenação de bloqueadores, não uma medição da frequência de cada um. Deliberadamente não publicámos contagens, porque a amostra é suficientemente pequena para que uma percentagem implicasse uma precisão que não temos.
- As avaliações são de negócios que já estavam a considerar decisioning, o que seleciona para um certo nível de maturidade de dados. Uma base sem data warehouse e sem event stream enfrenta um problema anterior a qualquer um destes.
- Os requisitos são declarados para a primeira decisão. Executar cinquenta decisões com arbitragem entre elas adiciona requisitos de governação e pressão de contacto que este relatório não aborda.
- Nada aqui é específico da Markin. Qualquer abordagem de decisioning, construída ou comprada, enfrenta os mesmos cinco.
Falsificabilidade
O que nos faria mudar de ideias
- 01
Um conjunto de implementações onde a qualidade do modelo, não o write-back, foi a restrição limitante na primeira decisão.
- 02
Evidências de que equipas sem uma margem por ação fornecida pelas finanças evitam, mesmo assim, desviar-se para descontos e produtos de baixa margem.
- 03
Primeiras decisões que rotineiramente exigem atualização em menos de uma hora. Isso colocaria a latência do evento à frente do write-back na ordem.
Proveniência
Fontes, e para que cada uma foi utilizada
- Implementações Markin anonimizadasAvaliações de prontidão anonimizadas em implementações e avaliações da Markin
A ordenação dos bloqueadores e as definições dos limiares. Não são publicados contagens nem percentagens a partir disto.
- Derivado neste relatórioLimiares de requisitos
Ambas as tabelas. Cada verificação é escrita para que um leitor possa executá-la sem nós.
Perguntas que este relatório responde
- De que precisamos antes de podermos fazer decisioning por cliente?
- Porque é que os projetos de personalização estagnam depois de o modelo ser construído?
- Precisamos de dados em tempo real para a next best action?
- Como passamos de campanhas para decisões 1:1?
- Qual é o caso de uso mais rápido para decisioning?
Perguntas frequentes
- De que precisa uma empresa para passar de campanhas para decisions por cliente?
- Cinco coisas: uma identidade fiável entre o sistema de sinais e o sistema de execução, eventos suficientemente recentes para a janela de decisão, um caminho de write-back suportado para o canal de execução, uma margem fornecida pelas finanças por ação candidata, e um proprietário nomeado para o holdout aleatório.
- Precisamos de dados em tempo real?
- Geralmente não para uma primeira decision. As decisions de renewal, win-back, plan-fit e cross-sell têm janelas medidas em dias e são executadas confortavelmente num batch diário. O streaming é genuinamente necessário para decisions em sessão e ao nível do carrinho, e é um projeto muito mais longo.
- Precisamos primeiro de um CDP?
- Não. Uma CDP resolve a identidade e a ativação em todo o ecossistema, o que é um programa de vários trimestres. Uma primeira decisão requer uma chave de junção entre dois sistemas e um caminho de write-back suportado. Delimitar a identidade à decisão, em vez de ao roadmap, é o que faz com que as equipas experimentem meses mais cedo.
- Porque é que um número de margem em falta importa tanto?
- Porque sem ele, as ações são classificadas com base na receita esperada, o que favorece sistematicamente descontos e produtos de baixa margem. Nada quebra visivelmente. O programa otimiza a quantidade errada e reporta growth enquanto a margem de contribuição permanece estável.
- Estes números são de clientes da Markin?
- Não há números. As descobertas são uma ordenação de bloqueadores a partir de avaliações de prontidão anonimizadas, publicadas como uma ordenação precisamente porque a amostra é demasiado pequena para percentagens. Os limiares nas tabelas são verificações que você pode executar por conta própria, na sua própria stack, sem nós.
Aja sobre isto
- PlaybookAdicione next best action às jornadas que já executa no BrazeArbitragem por cliente escrita nas canvases que a sua equipa já opera.
- PlaybookReative clientes inativos com uma janela de silêncio em vez de uma escada de descontosReativação programada com base na intenção de retorno, não nos dias desde o último pedido.
- PesquisaProjetando um holdout que pode realmente detetar uplift de ARPUA maioria dos experimentos de ARPU não são inconclusivos. Eles foram subdimensionados no dia em que foram concebidos, e ninguém o calculou.
- PesquisaReceita que gera margemCada decisão de growth nesta lista aumenta a receita reportada. Quatro delas aumentam a margem de contribuição. Não são as mesmas quatro que a maioria das equipas prioriza.
- GuiaComo pode a AI unificar dados de CRM, produto e lealdade?Identity resolution, uma timeline por cliente, precedência de atributo explícita e a decisão que faz com que a unificação valha o seu custo.
- GuiaArquitetura de referência para uma camada de decisioningOnde uma camada de decisioning se situa entre o seu warehouse, o seu CDP e os seus canais, o que deve possuir e o que nunca deve tentar possuir.
- GuiaComo as decisões chegam ao clienteOs padrões de ativação que uma camada de decisioning precisa: gravação de atributos, eventos acionados, API de decisioning em tempo real e superfícies de produto. Com trade-offs.