Como o Decisa atribui receita.

Todo evento de receita no Decisa percorre a mesma cadeia:

UtmLink  →  Click  →  Session  →  Order  →  AttributedConversion

UtmLink são os metadados que você possui. Click é capturado por pixel.js quando um visitante chega. Session costura múltiplos cliques sob um único cookie first-party dcs_vid. Order é criado quando o seu back-end faz um POST para /v1/conversions. AttributedConversion é a linha de junção que registra quais cliques recebem crédito por qual pedido, sob qual modelo e em qual momento no tempo.

• Janela de clique → conversão: 30 dias por padrão. Configurável por workspace.
• Identidade do visitante: cookie first-party dcs_vid, expiração contínua de 12 meses, renovada a cada clique reconhecido.
• Deduplicação de pedidos: unicidade de (workspace_id, external_id). Reenvios do mesmo webhook nunca criam um pedido duplicado.
• Deduplicação de conversões (para envio via CAPI): unicidade de event_id por plataforma + workspace. Cada pusher verifica o log de saída antes de enviar.

Os modelos são entidades de primeira classe — alternar de modelo não reescreve o histórico. O snapshot de atribuição anterior continua consultável para fins de reprodutibilidade.

Último clique (padrão)

100% da receita do pedido é atribuída ao clique qualificável mais recente dentro da janela. É o que a Meta e o Google mostram por padrão. Começamos por aqui porque é o número mais fácil para uma equipe financeira reconciliar.

Linear

A receita é dividida igualmente entre todos os cliques qualificáveis da sessão. Útil para descobrir quais origens de topo de funil sustentam silenciosamente o herói do último clique.

Baseado em posição (40/20/40)

O primeiro clique recebe 40%, o último clique recebe 40%, e os cliques intermediários dividem os 20% restantes igualmente. Padrão para jornadas em que tanto a introdução quanto o momento da decisão importam.

Decaimento temporal (meia-vida de 7 dias)

Peso por clique = 2^(-age_days / 7), normalizado para que os créditos entre os pontos de contato somem 1. Um clique 7 dias antes da conversão carrega metade do peso de um clique no dia da conversão. Bom para janelas de consideração curtas; oculta investimentos de marca/PR de queima lenta cujo impacto se acumula ao longo de semanas.

Cada linha de AttributedConversion carrega o nome e a versão do modelo de atribuição sob o qual foi calculada. Se algum dia mudarmos a matemática (e vamos), as linhas mais antigas permanecem intactas e uma nova versão é gravada ao lado. Você pode fixar relatórios em uma versão do modelo ao defender um número para a liderança seis meses depois.

• Não fazemos fingerprinting de visitantes. Sem hashing de canvas, sem sondagem de fontes, sem correspondência IP+UA. Apenas dcs_vid.
• Não armazenamos e-mails brutos nem IPs completos. Os e-mails são hasheados com SHA256; os IPs são hasheados com um salt por workspace.
• Não inventamos atribuição para cliques que nunca vimos. Se o pixel não estava instalado quando um clique aconteceu, esse pedido é marcado como não atribuído. Ele nunca é reatribuído silenciosamente a uma origem diferente.
• Não fazemos correspondência com as conversões reportadas pelas plataformas. Nosso número é independente. Mostramos a diferença; nunca a encobrimos.

• Navegadores in-app do iOS limpam cookies de forma agressiva. Alguns cliques perdem a continuidade nas transferências entre apps. Estamos monitorando a lacuna; ainda não a fechamos.
• Jornadas entre dispositivos exigem que o usuário se identifique em ambos os dispositivos (por exemplo, checkout autenticado). Sem isso, as duas sessões permanecem independentes.
• E-mails renderizados no servidor com parâmetros utm ainda não são integrados ao grafo de sessões. Em breve, em uma versão futura.