Construindo a Espinha Dorsal de Atribuição: Uma Visão Técnica

Atribuição é onde os dados de receita vão para virar uma discussão. O marketing reivindica o pipeline, as vendas reivindicam o fechamento, a equipe de parceiros reivindica a apresentação, e o financeiro desconfia silenciosamente dos três porque nada disso concilia. A reação usual é discutir sobre modelos: primeiro-toque, multi-toque, alguma mistura ponderada. Mas o modelo é o último problema. O primeiro problema é que a maioria das organizações não tem uma espinha dorsal de atribuição, ou seja, nenhuma estrutura de dados subjacente que registre quem tocou o quê, quando e em qual contexto, em uma forma que qualquer modelo consiga computar.

Este é o complemento de engenharia do artigo conceitual sobre a espinha dorsal de atribuição: o modelo de dados, os problemas de identidade e timestamp, e o pipeline que transforma um fluxo confuso de pontos de contato em algo consultável e agnóstico de modelo. Dentro da arquitetura de referência para uma plataforma de receita moderna, este é o inquilino mais exigente da camada de inteligência, porque a atribuição encontra toda fraqueza nos seus dados.

É um modelo de dados, não um relatório

O erro central é tratar a atribuição como um problema de relatório, um painel que você configura. É um problema de modelagem de dados que você resolve uma vez, depois do qual os relatórios ficam fáceis. A espinha dorsal tem três primitivas.

Pontos de contato são registros atômicos e imutáveis de uma interação: um webinar assistido, uma resposta de e-mail, uma reunião originada por parceiro, um cadastro de produto. Cada um tem um sujeito (quem), um tipo (o quê), um timestamp (quando) e um sistema de origem (de onde veio).

Entidades são as contas e contatos aos quais os pontos de contato se vinculam, resolvidos para identificadores canônicos, de modo que um ponto de contato da automação de marketing e um do CRM caiam na mesma conta.

Eventos de receita são os resultados para os quais o crédito é alocado: pipeline criado, oportunidade avançada, negócio fechado, expansão registrada.

Com essas três coisas em vigor, qualquer modelo de atribuição, seja primeiro-toque, último-toque, linear, decaimento temporal, em forma de U, ou uma ponderação aprendida, é apenas uma função sobre os pontos de contato entre a primeira interação de uma entidade e um evento de receita. Você para de discutir sobre qual relatório está certo e começa a computar visões diferentes sobre os mesmos dados imutáveis. Essa separação é todo o sentido.

As duas coisas que realmente quebram os projetos

Mais projetos de atribuição morrem por causa disso do que por qualquer desacordo de modelagem.

Resolução de identidade. Um ponto de contato não vale nada se você não conseguir vinculá-lo à entidade certa. A mesma pessoa aparece como um ID de cookie, um e-mail de preenchimento de formulário, um contato de CRM e um ID de usuário de produto, e se esses não se costurarem, os pontos de contato dela se espalham entre entidades fantasmas. Você precisa de correspondência determinística onde tem chaves compartilhadas (e-mail, domínio) e correspondência probabilística cuidadosa onde não tem. É por isso que a atribuição pune tão duramente a má higiene de dados de RevOps. Toda identidade não resolvida é um buraco na espinha dorsal, e os buracos não se distribuem aleatoriamente. Eles se concentram exatamente nos canais com a pior instrumentação, o que enviesa todo o modelo.

Integridade temporal. A atribuição aloca crédito ao longo de uma sequência, então precisa de timestamps confiáveis e consistentemente ajustados a fuso horário em cada ponto de contato e cada evento de receita. As falhas comuns: sistemas registrando o tempo de ingestão em vez do tempo do evento, inconsistência de fuso horário entre fontes, registros retroativos chegando fora de ordem. Um ponto de contato registrado depois do negócio que supostamente influenciou não é um erro pequeno. Ele corrompe silenciosamente os modelos de decaimento temporal e baseados em posição. Trate o tempo do evento como um contrato de correção, um tema que aprofundamos em Tempo Real vs. Lote: Quando a Atualidade dos Dados de Receita Importa.

O pipeline

Uma espinha dorsal funcional é um pipeline com estágios distintos, cada um testável isoladamente.

1. Coleta. Ingira pontos de contato de cada fonte: automação de marketing, atividades de CRM, análise de produto, sistemas de parceiros, plataformas de anúncios. Mantenha o payload bruto. Nunca descarte a fidelidade da fonte que você pode precisar depois.
2. Normalização. Mapeie os eventos heterogêneos no esquema comum de ponto de contato, com um conjunto consistente de tipos, sujeitos e timestamps de tempo de evento.
3. Resolução de identidade. Costure os pontos de contato a entidades canônicas usando a lógica de correspondência acima.
4. Montagem. Ordene os pontos de contato de cada entidade em uma linha do tempo e associe-os aos eventos de receita relevantes. Isso produz as jornadas que os modelos consomem.
5. Computação do modelo. Aplique um ou mais modelos sobre as jornadas montadas. Como a espinha dorsal é agnóstica de modelo, esse estágio é barato de mudar e barato de rodar vários modelos lado a lado para comparação.

A disciplina é manter os estágios separados. Uma vez que a lógica de normalização vaza para a computação do modelo, você não consegue mais trocar modelos sem arriscar os dados por baixo, e todo o benefício desaparece.

Tornando isso confiável

Uma espinha dorsal conquista confiança por meio da explicabilidade. Para qualquer dólar creditado, você deveria conseguir rastrear de volta aos pontos de contato exatos e à ponderação exata que o produziu. Armazene a saída do modelo ao lado da jornada da qual foi computada, de modo que a atribuição seja auditável, em vez de uma caixa que emite números.

A mesma estrutura torna tratáveis os casos genuinamente difíceis, especialmente a atribuição de co-sell e de parceiros, em que um negócio envolve sua equipe, um parceiro e pontos de contato sobrepostos. Como a espinha dorsal registra nativamente o sistema de origem e o tipo de ponto de contato, os toques originados e influenciados por parceiros são linhas de primeira classe, em vez de notas de rodapé manuais. Os resultados só se tornam úteis, no entanto, uma vez que são roteados de volta para os sistemas em que as pessoas trabalham. Esse é o trabalho da camada de write-back, que empurra o crédito atribuído para os campos do CRM e painéis onde vendedores e líderes realmente vão vê-lo.

Principais conclusões

• Resolva a atribuição como um modelo de dados. Uma vez que a espinha dorsal existe, todo modelo é apenas uma consulta sobre ela.
• Três primitivas: pontos de contato imutáveis, entidades canônicas, eventos de receita.
• Identidade e timestamps matam mais projetos do que qualquer debate de modelo jamais vai matar, e o dano é silencioso.
• Mantenha coletar, normalizar, resolver, montar e computar como estágios separados, para que você possa mudar modelos sem tocar nos dados.
• Armazene a saída ao lado da jornada de onde veio. É isso que torna o número defensável quando o CFO pergunta.

Uma espinha dorsal bem construída transforma uma discussão infinita de crédito em uma base consultável e auditável, que é o tipo de camada de dados de que uma plataforma de orquestração de receita como a Revnewo depende. Se seus debates de atribuição continuam girando em torno do modelo, o conserto real geralmente está uma camada abaixo.