Como conciliar conversões do site e registos do CRM

Como conciliar conversões da análise do site com os registos do CRM

As ferramentas de análise do site e o CRM contabilizam coisas diferentes. A ferramenta de análise pode registar um evento de envio de formulário, enquanto o CRM só regista um potencial cliente depois da validação, da deduplicação ou de uma transferência bem-sucedida. A diferença entre conversões da análise web e registos do CRM não significa automaticamente que o acompanhamento esteja avariado. Significa, sim, que precisa de uma forma consistente de os comparar.

O objetivo é identificar o que aconteceu a cada conversão relevante — não obrigar os dois sistemas a apresentar o mesmo número. Para aprender como conciliar conversões do site com o CRM, comece por definir um evento, seguir um conjunto de regras e registar os motivos de eventuais diferenças.

1. Defina a conversão e o potencial cliente que vai conciliar

Escolha uma conversão da ferramenta de análise e o resultado correspondente no CRM. Por exemplo, compare o evento do site demo_request_submit com os registos criados no CRM como novos potenciais clientes que pediram uma demonstração. Não misture esse evento com inscrições na newsletter ou pedidos por telefone: correspondem a ações diferentes dos clientes e podem seguir percursos distintos.

Registe o que conta em cada sistema. Uma conversão da ferramenta de análise pode corresponder a um evento de envio bem-sucedido, acionado depois de o servidor confirmar a receção. Um potencial cliente no CRM pode ser um registo recém-criado com um endereço de e-mail válido, e não um contacto existente cujos dados foram atualizados. Esta distinção determina o que a comparação lhe pode dizer.

Defina o período de análise e os estados a incluir. Se estiver a analisar a primeira semana de um mês, indique as horas exatas de início e de fim e decida se vai incluir potenciais clientes em aberto, qualificados, desqualificados ou eliminados. Mantenha o âmbito suficientemente restrito para poder explicar os resultados. «Todas as conversões e toda a atividade do CRM» é, regra geral, demasiado abrangente para diagnosticar o problema.

Registe a definição numa nota partilhada antes de extrair os dados. Este pequeno passo evita que um analista conte todos os envios de formulário enquanto outro contabiliza apenas os potenciais clientes aceites pela equipa de vendas. Se precisar de um método mais abrangente para planear fluxos de dados, trate esta conciliação como uma tarefa de medição independente, em vez de reabrir todo o desenho da integração com o CRM.

2. Defina as regras de comparação antes de extrair os dados

Comece por acordar o fuso horário. Os sistemas de análise e o CRM podem guardar os registos temporais em fusos horários diferentes ou apresentá-los de acordo com definições de conta distintas. Converta ambos os conjuntos de dados para um único fuso horário acordado, como UTC, antes de comparar os totais diários; caso contrário, um envio perto da meia-noite pode surgir em dias diferentes.

Use o mesmo intervalo de datas, mas esclareça qual é a data e hora que determina a inclusão. A ferramenta de análise pode usar a hora do evento, enquanto o relatório do CRM pode filtrar pela hora de criação do potencial cliente. Se o registo for criado com atraso, as duas datas podem cair em períodos de análise diferentes. Para a conciliação, a hora do evento costuma ser o ponto de partida mais útil; mantenha também a hora de criação no CRM para explicar os atrasos.

Se a questão envolver a atribuição de campanhas, documente também o período e o modelo de atribuição. Uma conversão pode constar de ambos os sistemas, mas ter uma origem diferente, porque a ferramenta de análise e o CRM podem atribuir o crédito segundo regras distintas. Compare separadamente o número de registos e a atribuição por canal; misturar as duas questões dificulta a interpretação dos resultados.

Decida antecipadamente como vai tratar testes, spam, duplicados e registos desqualificados. Por exemplo, exclua os envios de teste internos usando um endereço de teste conhecido, mas não elimine um potencial cliente só porque a equipa de vendas o marcou posteriormente como não qualificado. Essa alteração de estado pode explicar um resultado comercial; não apaga o envio original.

3. Compare as conversões da ferramenta de análise com os potenciais clientes no CRM

Para comparar as conversões da ferramenta de análise com os potenciais clientes no CRM — ou perceber como comparar leads do CRM com formulários do site — crie uma linha para cada conversão do período escolhido e procure o registo correspondente no CRM. Um ID de envio ou de evento partilhado é a forma mais fiável de fazer a correspondência, desde que ambos os sistemas o conservem. Transmita esse identificador ao longo do fluxo do formulário e guarde-o num campo do CRM para poder verificá-lo mais tarde.

Se não existir um ID partilhado, use uma combinação de campos definida com rigor, como a hora do envio, o tipo de formulário e um identificador adequado do ponto de vista da privacidade e disponível para a sua equipa. A hora, por si só, é um indício pouco fiável: duas pessoas podem enviar o mesmo formulário com poucos segundos de diferença, e uma mesma pessoa pode enviá-lo duas vezes. Não trate uma correspondência aproximada como certa quando as provas são incompletas.

Classifique cada comparação como correspondente, sem correspondência ou ambígua. Uma linha correspondente tem um registo claramente associado. Um evento de análise sem correspondência não tem qualquer registo no CRM segundo as regras acordadas. Uma linha ambígua pode corresponder a mais do que um registo possível, ou os dados podem não ser suficientes para decidir. Mantenha estas categorias separadas, em vez de forçar todas as linhas a uma resposta de sim ou não.

Uma tabela de trabalho básica pode incluir o ID do evento de análise, a hora do evento, o nome do formulário, o ID do registo no CRM, a hora de criação no CRM, o estado atual e o resultado da correspondência. Restrinja o acesso a dados pessoais e use apenas os campos necessários para a tarefa. Se o formulário não tiver um identificador de envio estável, registe-o como uma limitação do acompanhamento, em vez de fingir que uma correspondência baseada na hora é conclusiva.

4. Diagnostique as diferenças entre os dados da análise do site e os do CRM

Uma diferença entre os dados da análise do site e os do CRM pode surgir em várias etapas entre a ação de um visitante e a apresentação de um relatório. Trate cada possível causa como uma hipótese a testar, não como uma explicação garantida. Comece pelos registos sem correspondência: observe se a diferença se concentra num formulário, navegador, campanha ou período específico.

• Consentimento ou bloqueio de anúncios: Um visitante pode enviar um formulário enquanto a recolha de dados de análise está limitada ou bloqueada. Verifique se o formulário continua a chegar ao servidor e se, segundo as definições de consentimento aplicáveis, o evento deve ser acionado.

• Acionamento da etiqueta: A etiqueta de análise pode não ser executada após o envio ou pode ser acionada antes de o envio ser concluído com sucesso. Teste o formulário numa sessão controlada e confirme que o evento só aparece no momento previsto do fluxo.

• Entrega do formulário: Uma página de confirmação no navegador não prova que os dados do formulário chegaram ao CRM. Consulte o ponto final do formulário ou o registo de integração para confirmar se a entrega foi bem-sucedida e se houve algum erro associado ao mesmo envio.

• Validação do CRM: Uma regra do CRM pode rejeitar um registo por falta de um campo obrigatório ou porque um valor não cumpre os critérios de validação. Consulte os registos de rejeição e, sempre que possível, associe o envio rejeitado ao ID do evento.

• Deduplicação: O CRM pode atualizar um contacto existente em vez de criar um novo potencial cliente. Procure o identificador nos registos existentes e confirme se o sistema registou uma atualização ou uma fusão.

• Criação tardia: Uma fila, uma tarefa agendada ou uma revisão manual pode atrasar a criação do registo no CRM. Compare a hora do evento com a hora de criação do registo antes de o considerar em falta.

Teste uma causa de cada vez. Se todos os registos sem correspondência vierem de um formulário específico, examine o processo de envio e de acompanhamento desse formulário antes de alterar os relatórios de campanhas. Registe a data em que qualquer alteração às etiquetas ou ao tratamento do formulário entrou em vigor, para que uma comparação posterior permita distinguir um problema antigo de um atual.

5. Concilie duplicados, atrasos e alterações de estado

Nem todas as conversões da ferramenta de análise devem gerar um novo potencial cliente no CRM. Alguém pode enviar o formulário duas vezes, ou o CRM pode fundir o segundo envio com um contacto existente. Conte os eventos de conversão segundo a definição da ferramenta de análise e, em separado, os registos únicos do CRM segundo a definição desse sistema. Os totais podem diferir legitimamente, mas a regra para os duplicados tem de ser explícita.

Permita algum tempo para a chegada dos dados antes de marcar uma conversão como sem correspondência. Se o registo do CRM aparecer algumas horas depois, o envio não se perdeu: chegou com atraso. Preserve ambas as horas e defina um período de espera consistente para os relatórios regulares. O período adequado depende do processo de tratamento dos dados; confirme-o com a equipa responsável pela integração.

Distinga a criação das alterações de estado posteriores. Um potencial cliente marcado como desqualificado após uma revisão continua a existir como registo no CRM, mesmo que já não seja elegível para um relatório de vendas. Um registo eliminado exige outra explicação: confirme se foi removido por um utilizador, por um processo de retenção ou devido a uma fusão. Registe o que mostra o histórico de auditoria do CRM, em vez de deduzir a causa a partir da vista atual.

Para cada exceção, registe um motivo breve, como «duplicado fundido», «criado no dia seguinte» ou «rejeitado por falta de um campo obrigatório». Assim, a conciliação será útil para a equipa responsável pela etapa seguinte. Se, durante a análise, surgir uma questão de privacidade ou de acesso, consulte as orientações aprovadas pela sua organização sobre segurança do site e tratamento de dados.

6. Corrija a conciliação sem reescrever o histórico

Corrija a origem do problema assim que tiver provas. Se a etiqueta for acionada antes de uma resposta bem-sucedida, altere o acionador e teste um envio confirmado. Se a validação do CRM rejeitar um valor válido do formulário, corrija o mapeamento do campo ou a regra de validação através do processo habitual de gestão de alterações. A correção deve resolver uma falha comprovada, não apenas fazer com que os dois totais coincidam.

Preserve a hora original do evento de análise e a hora de criação no CRM. Se preencher dados retroativamente, assinale-os como tal e guarde a data da correção. Caso contrário, um analista poderá confundir dados reconstruídos com um evento registado em tempo real.

Registe quaisquer alterações às definições, aos filtros ou às regras de atribuição. Por exemplo, se um relatório começar a excluir testes internos no primeiro dia de um trimestre, assinale essa alteração e evite comparar o novo total com um total anterior como se as regras não tivessem mudado. Os números do passado devem continuar a poder ser interpretados, mesmo quando a medição melhora.

7. Acompanhe a conciliação ao longo do tempo

Repita a mesma comparação segundo um calendário definido, por exemplo, após cada período de análise ou depois de uma alteração significativa a um formulário. Use sempre o mesmo evento, as mesmas regras de estado, o mesmo fuso horário e o mesmo método de correspondência. Se o processo mudar, documente a nova regra e a data em que entrou em vigor.

Acompanhe as diferenças por resolver de acordo com a respetiva causa, não apenas como uma percentagem ou um total. Um pequeno conjunto de falhas de validação no CRM pode exigir a intervenção de uma equipa diferente daquela que trata as conversões em falta devido às definições de consentimento que impedem a recolha de dados de análise. Atribua cada categoria à equipa que a pode investigar e, sempre que possível, inclua alguns IDs de exemplo sem dados pessoais.

Acorde com as equipas responsáveis pela análise e pelo CRM um limite para escalar os problemas. Esse limite deve basear-se na variação normal das operações, por isso confirme-o antes de o usar nos alertas. Quando a diferença observada ultrapassar esse limite, notifique a equipa responsável e indique o período, o formulário afetado, o número de registos sem correspondência e as primeiras verificações já realizadas. Um alerta específico permite agir; «os números parecem errados» não.