Integração Shopify + CRM: rastreando a conversão de verdade do carrinho ao fechamento

Quem gerencia tráfego para e-commerce convive com um problema silencioso: cada plataforma tem a sua própria versão da verdade. O Shopify sabe quando um pedido foi pago. O CRM — Pipe.run, Kommo ou qualquer outro — sabe quando um lead virou negócio fechado. O gerenciador de anúncios sabe quem clicou. E nenhum desses três conversa nativamente com os outros de forma confiável. O resultado é uma contabilidade fragmentada, em que o mesmo cliente aparece como três pessoas diferentes e a conversão real se dilui no meio de eventos de intenção.

Este artigo mostra como amarrar a jornada inteira, do primeiro clique ao fechamento, em um único evento de conversão confirmada — e por que isso muda a qualidade da otimização de campanha.

O problema dos dados multiplataforma

Imagine um funil típico de e-commerce com upsell ou venda assistida. O visitante chega por um anúncio no Meta, navega no Shopify, coloca um produto no carrinho e inicia o checkout. Em alguns modelos de negócio, ele para por aí e um vendedor entra em cena pelo CRM para fechar. Em outros, ele paga direto na loja.

Cada uma dessas etapas vive em um sistema diferente:

• Shopify guarda o carrinho, o checkout e — o que importa de verdade — o pedido pago.
• CRM (Pipe.run / Kommo) guarda o lead, as interações do vendedor e o estágio do negócio até o deal won.
• Plataforma de anúncios (Meta, Google) guarda o clique, o click id e precisa receber de volta o sinal de conversão para otimizar.

O erro clássico é tratar esses sistemas como se cada um pudesse, sozinho, dizer "houve uma venda". O pixel do navegador dispara um evento de compra que pode nem ter sido paga. O CRM marca um negócio como ganho que ainda vai ser estornado. A plataforma de anúncios otimiza para quem chegou no checkout, não para quem comprou. Sem uma camada que reconcilie tudo, você otimiza para o sinal errado.

Os eventos do Shopify: o que cada um realmente significa

O Shopify emite eventos em vários pontos da jornada, e a diferença entre eles é a diferença entre ruído e receita.

Intenção não é conversão

Add to cart e initiate checkout são eventos de intenção. Eles indicam interesse, são úteis para remarketing e para diagnosticar abandono, mas não representam dinheiro trocando de mãos. Uma parcela enorme de carrinhos nunca vira pedido, e uma parcela de checkouts iniciados nunca é paga. Se você manda esses eventos para a plataforma de anúncios rotulados como "compra", está ensinando o algoritmo a perseguir gente que não compra.

O evento que importa: <code>orders/paid</code>

O webhook orders/paid do Shopify dispara quando o pagamento de um pedido é confirmado. Esse é o marco da conversão real na loja. Ele carrega o valor do pedido, a moeda, os itens, o order id e — crucial para o rastreamento — os dados do cliente: e-mail, telefone e, quando disponível, atributos de origem da sessão.

Existem outros webhooks relacionados (orders/create, orders/fulfilled, orders/cancelled, refunds/create) e cada um tem o seu papel. Mas o pilar de uma conversão de e-commerce que respeita a realidade é o pedido pago, não o pedido criado — porque um pedido criado com boleto ou Pix pendente ainda não é receita. Uma camada de rastreamento séria escuta orders/paid e, quando é o caso, reverte a conversão ao receber refunds/create.

Mapeando o pedido pago para o evento de conversão do anúncio

Ter o orders/paid é metade do caminho. A outra metade é entregar esse fato de volta à plataforma que gerou o clique, no formato que ela entende, com a identidade certa amarrada.

Cada plataforma tem a sua API de conversão server-side — a Conversions API do Meta, o enhanced conversions do Google. O que todas exigem em comum:

1. Um identificador de conversão único para deduplicar contra o pixel do navegador (se ele ainda existir) e contra reenvios.
2. Dados de correspondência do usuário, normalizados e com hash: e-mail e telefone passados por SHA-256 depois de trimados e em minúsculas.
3. O identificador de clique capturado na chegada (fbclid/_fbc, gclid), que é o que efetivamente liga a venda ao anúncio.
4. Valor e moeda vindos do pedido real, não estimados.

O trabalho de mapeamento é transformar o payload do orders/paid nesse formato de destino. Aqui mora a maior parte dos erros de implementação caseira: hash aplicado no campo errado, telefone sem código de país no padrão E.164, valor mandado com imposto quando deveria ser sem, click id perdido porque ninguém o persistiu na primeira visita. Uma camada de consolidação existe justamente para padronizar essa tradução e não deixar o click id cair no caminho.

Conversões offline: quando a venda fecha no CRM

Nem toda conversão acontece dentro do Shopify. Em vendas assistidas, high ticket ou B2B, o pagamento pode até rodar na loja, mas a decisão fecha no CRM, com um vendedor movendo o negócio de estágio até deal won. Essa é a conversão offline, e ela é invisível para o pixel — o navegador do cliente já foi embora há dias.

O CRM (Pipe.run, Kommo) emite eventos quando um negócio muda de estágio. O evento de deal won é o análogo do orders/paid: é o momento em que a receita se confirma. Para fechar o ciclo, você precisa:

• Capturar o deal won com o valor real do negócio.
• Recuperar o identificador de clique original — normalmente carimbado no lead lá na entrada, quando ele preencheu o formulário vindo do anúncio.
• Enviar como conversão offline para a plataforma de anúncios, com a mesma disciplina de hash de identidade.

Sem isso, campanhas de geração de lead ficam cegas: o Meta otimiza para volume de formulário, não para negócios ganhos, e você acaba pagando barato por leads que nunca compram. O sinal de deal won é o que reorienta o algoritmo para a receita de verdade.

Identity stitching: costurando as três identidades

O nó da integração é a identidade. O mesmo ser humano é um customer id no Shopify, um contact id no CRM e um click id no gerenciador de anúncios. Costurar isso — o identity stitching — é o que permite dizer "este pedido pago é do mesmo lead que o vendedor fechou, que veio daquele anúncio".

A chave de junção prática é o dado de contato: e-mail e telefone, normalizados. Normalizar significa padronizar antes de comparar ou dar hash — e-mail em minúsculas e sem espaços, telefone em formato internacional E.164. Só depois vem o SHA-256, porque hash de entradas diferentes ("João@x.com" e "joao@x.com") gera valores diferentes e quebra a correspondência.

O hash tem dupla função. Primeiro, protege o dado pessoal: você trafega e armazena o identificador sem expor o e-mail em claro, o que é essencial para conformidade com LGPD. Segundo, é exatamente o formato que as APIs de conversão das plataformas esperam para fazer o matching do lado delas. A mesma normalização precisa ser aplicada de ponta a ponta, senão o hash do Shopify não bate com o hash do CRM e a costura falha silenciosamente.

Onde não há e-mail nem telefone, sobram sinais mais fracos — click id persistido, cookies de primeira parte, fingerprint de sessão. Uma camada de consolidação usa uma cascata de chaves, da mais forte para a mais fraca, para maximizar a taxa de correspondência sem inventar vínculos que não existem.

Um detalhe operacional que costuma passar batido: o click id precisa sobreviver à jornada inteira. O fbclid chega na URL de destino do anúncio na primeira visita, mas o pedido pago pode acontecer dias depois, em outra sessão, talvez em outro dispositivo. Se você não persistir esse identificador — em cookie de primeira parte na chegada e, quando o lead se identifica, gravado no registro dele no CRM —, ele desaparece e a venda fica órfã de atribuição. Capturar cedo e carimbar no lead é o que garante que o deal won de três dias depois ainda saiba de qual anúncio veio.

Janela de atribuição e reconciliação com o financeiro

Rastreamento honesto tem prazo de validade. Uma conversão só deve ser atribuída a um anúncio dentro de uma janela de atribuição definida — o intervalo entre o clique e a venda que você considera causal. Estourou a janela, a venda ainda é real, mas não é mais mérito daquele clique. Uma camada de consolidação carrega o timestamp do clique e o do pagamento e só atribui dentro do prazo, evitando dar crédito a campanhas que não têm relação com a compra.

O teste final de qualquer setup de rastreamento é bater com o financeiro. Se o painel de anúncios diz 100 conversões e o Shopify fechou 70 pedidos pagos no período, alguém está mentindo — e quase sempre é o rastreamento, contando intenção como venda ou duplicando eventos. Quando a fonte da verdade é o orders/paid e o deal won, deduplicados e dentro da janela, essa reconciliação para de doer: o número de conversões confirmadas tende ao número de vendas reais, e as diferenças que sobram são explicáveis (estornos, vendas sem clique rastreável), não misteriosas.

A camada de consolidação: uma verdade, um evento

Juntando as peças, o desenho que funciona é uma camada intermediária que fica entre as fontes (Shopify, CRM) e os destinos (plataformas de anúncios). Ela faz quatro coisas:

1. Ingere os eventos de conversão real — orders/paid do Shopify, deal won do CRM — e ignora, ou trata como sinal auxiliar, os eventos de intenção.
2. Reconcilia a identidade via normalização e hash, unindo pedido, negócio e clique na mesma pessoa.
3. Deduplica com um identificador estável por conversão, para que um reenvio de webhook ou um retry de entrega não conte a mesma venda duas vezes.
4. Dispara um único evento de conversão confirmada para cada destino, no formato de cada API, apenas quando a venda de fato aconteceu.

Essa é a diferença entre um rastreamento que reflete a realidade e um que infla números. O evento sai da camada de consolidação já validado — pago, atribuído, sem duplicata — e não do navegador do cliente, que pode ser bloqueado, ter o pixel perdido ou disparar em intenção. É o mesmo princípio que discutimos em por que o webhook deve disparar só quando a venda acontece: a fonte da verdade é o pedido pago e o negócio ganho, não o clique de "comprar".

O que muda na prática

Quando o rastreamento passa a enviar só conversões confirmadas, três coisas mudam de forma mensurável. O algoritmo das plataformas de anúncios recebe um sinal limpo e otimiza para quem compra, não para quem chega no checkout — o que, ao longo de semanas, reduz o custo por aquisição real. A atribuição para de contar carrinho como venda e a reconciliação com o financeiro para de doer. E as conversões offline do CRM, antes invisíveis, entram na conta, tornando visível o valor de campanhas de lead que pareciam caras só porque ninguém media o fechamento.

Nada disso depende de mais pixels no navegador. Depende de escutar os eventos certos — orders/paid, deal won —, costurar a identidade com disciplina e disparar um evento por conversão real. A loja e o CRM já sabem quando houve venda; o trabalho é fazer as plataformas de anúncios saberem também, sem ruído e sem duplicata.