Em "Campanhas", preenche o slug, o nome e a URL de destino real (a tua landing page). O slug é o identificador usado no link de tracking.

Cada campanha tem um link do tipo /r/{slug} — é esse link que colocas no Meta Ads Manager, Google Ads, etc., não a URL de destino direta. Quando alguém clica, o Alvo regista o clique (fbclid/gclid/ttclid + UTMs, se vierem no link do anúncio) e redireciona de imediato para a tua página, com os mesmos parâmetros.

Sempre que a pessoa avança uma etapa (deixou dados, marcou, apareceu, comprou), o teu sistema chama o endpoint de ingestão com o click_id capturado (fbclid/gclid) — ou, na falta dele, o Alvo tenta encontrar o clique por IP+dispositivo numa janela de 6h.

A carregar...

Num funil de serviços, formação ou high-ticket, entre o anúncio e o pagamento há uma DM, uma marcação e uma chamada. Com só "lead" e "venda", uma campanha que enche a agenda e outra que junta emails que nunca respondem apareciam iguais — ambas com zero vendas — e o que se faz a cada uma é o oposto.

Manda o campo tipo com uma destas:

• visita — abriu a página. Não conta como conversão (é o clique outra vez), mas conta para veres onde as pessoas caem.
• lead — deixou o contacto.
• agendamento — marcou uma chamada ou sessão.
• lead_qualificada — apareceu e encaixa no perfil.
• oportunidade — recebeu proposta / está a decidir.
• venda — pagou. Manda o valor.
• reembolso — devolveste dinheiro. Manda o valor devolvido em positivo: o Alvo é que o desconta da receita. Não conta como conversão — é o desfazer de uma.
• recorrencia — mensalidade ou renovação. Entra na receita, mas não no CPA: a segunda mensalidade não é um cliente novo, e contá-la baixaria o custo por venda todos os meses sem ninguém ter feito nada.

Se não mandares tipo, é lead — como era antes.

A mesma venda vai ser vista por vários sistemas ao mesmo tempo: o browser, o servidor da tua página, o Pulse e o CRM. Todos com razão, todos a falar do mesmo acontecimento. Sem nada que os ligue, o Alvo regista quatro vendas e o ROAS aparece quatro vezes melhor do que é.

Dá um event_id a cada acontecimento e repete o mesmo valor em todos os canais que o reportam. O primeiro a chegar grava; os seguintes recebem a resposta com "duplicado": true e não criam nada. É também o que te deixa fazer retry em segurança quando um pedido dá timeout.

Serve qualquer texto único e estável — o id da encomenda, o id do pagamento no Stripe, o id do registo no CRM. O que não pode é ser gerado à chamada (um uuid novo de cada vez não deduplica nada). Sem event_id o evento entra na mesma: é melhor um evento sem defesa do que evento nenhum.

O cartão "Confiança nos números", por cima da tabela, diz quantas conversões o Alvo conseguiu mesmo ligar a um clique. É a primeira coisa a olhar: se a percentagem for baixa, os números por campanha estão a contar menos do que aconteceu, e normalmente é porque o link do anúncio não passou pelo /r/<campanha>.

A tabela de "Campanhas & performance" mostra o funil todo — cliques, leads, agendamentos, oportunidades, vendas — mais a receita e os custos. Receita é líquida (reembolsos já descontados) e Recorrente aparece à parte: 5 000 € de mensalidades acumuladas não são a mesma coisa que 5 000 € de vendas novas este mês.

Olha para €/lead e €/venda antes do CPA geral: o CPA junta etapas de valor diferente, e é onde as duas se afastam que está a decisão — muitos leads baratos que nunca marcam é um problema de oferta, poucos leads caros que fecham todos é um problema de escala.

O Spend vem do que carregares em Gasto (ver abaixo) — sem ele o ROAS é sempre zero, porque não há como saber se o anúncio deu lucro.

Repara no seletor de período, em cima à direita da tabela. Até há pouco isto somava tudo desde sempre, portanto o ROAS que aparecia era o histórico da campanha — e uma campanha que foi excelente em julho e está a queimar dinheiro esta semana aparecia verde. As conversões contam pelo dia em que aconteceram, não pelo dia do clique: uma venda desta semana conta para esta semana mesmo que o clique que a gerou seja de há dois meses, que é o caso normal neste funil.

O Alvo conta cliques e conversões, mas só sabe se valeu a pena se lhe disseres quanto gastaste. No separador Gasto: arrasta o CSV exportado do Gestor de Anúncios da Meta ou do Google Ads, ou escreve o valor de um dia à mão.

As linhas ligam-se às campanhas pelo nome. As que não corresponderem a nenhuma campanha aparecem na resposta — nunca desaparecem em silêncio. Reimportar o mesmo ficheiro corrige os valores em vez de os duplicar.

Se um dia tiveres um token da Meta com permissão ads_read, o botão Sincronizar com a Meta passa a puxar sozinho (precisa do ID da campanha na plataforma preenchido).

Se o destino do anúncio for uma página ou formulário do Pulse, não precisas do exemplo acima: o Pulse envia os leads sozinho. No Pulse, em Integrações → Webhooks, cria um webhook com o URL https://alvo.inovaverse.com/api/ingest/pulse, o segredo que está no .env do Alvo (PULSE_WEBHOOK_SECRET) e o evento Contacto deixou dados. É um webhook por marca.

O Pulse leva consigo o fbclid/gclid que vinha no link do anúncio, mais o IP e o dispositivo — é isso que permite dizer qual anúncio gerou o lead. Só o evento "contacto deixou dados" conta como conversão: um comentário solto não é um lead. O botão "Testar" do Pulse chega aqui e responde OK sem criar conversão nenhuma.

Não precisas de te preocupar com o event_id nesta ponte: o Alvo deriva-o do próprio evento do Pulse. Quando o Pulse reenvia um webhook que não recebeu resposta — que é o comportamento certo dele — o reenvio não cria um lead novo.

De hora a hora, o Alvo olha para os números e levanta a mão quando algo está errado: uma campanha que gastou sem converter, um gasto que disparou face à média, cliques a entrar com gasto zero (que faz o ROAS parecer infinito), a sincronização de gasto parada (que faz o ROAS parecer melhor do que é), atribuição fraca demais para os números serem de confiança, um criativo em fadiga, ou o CRM a mandar vendas sem contacto.

Este último merece uma nota: quando a chave do CRM expira ou é revogada, nada rebenta. As vendas continuam a entrar e a contar para a receita, mas ficam todas sem origem — o ROAS fica mais baixo do que a realidade e parece só que os anúncios pioraram. É por existir este aviso que a chave do CRM pode ter validade em vez de ser eterna.

Fadiga é comparar um criativo com o seu próprio passado: os últimos 7 dias contra as 3 semanas anteriores. Quando a taxa de conversão cai 40% ou mais, é aviso — porque o criativo continua a gastar exatamente ao mesmo ritmo, e é isso que a torna cara. Só se compara com volume a sério (30 cliques recentes, 60 anteriores, 5 conversões de base): com números pequenos a taxa salta sozinha, e um aviso errado ensina a ignorar todos os outros.

Cada aviso traz os passos para resolver, agrupa as repetições em vez de encher a lista, e fecha-se sozinho quando o problema passa. Se tiveres a ponte para o Pulse ligada, o aviso chega-te também ao telemóvel.

Neste funil, a venda não acontece na página: acontece semanas depois, ao telefone, e quem a regista é o CRM. Esse evento chega ao Alvo com um email e mais nada — sem fbclid, sem IP, sem dispositivo. Sem uma pessoa onde o email já esteja ligado ao clique que o trouxe, a receita que mais importa entrava sempre sem origem.

Por isso, manda sempre email e/ou telefone em todos os eventos, desde o primeiro lead. É o que cose a jornada: primeiro anúncio → lead → agendamento → oportunidade → venda. Se tiveres o id da pessoa no CRM, manda também crm_id — é ainda mais seguro do que o email.

O Alvo normaliza o contacto antes de comparar (maiúsculas no email, +351 e espaços no telefone), portanto o mesmo contacto escrito de duas maneiras continua a ser uma pessoa só.

O que o Alvo não faz de propósito: juntar duas pessoas porque partilharam um clique. Um fbclid identifica um clique, não uma pessoa — no telemóvel partilhado lá de casa, duas pessoas chegam pelo mesmo. Juntá-las daria a venda de uma à jornada da outra, e isso é um erro que não se vê no ecrã.

Na tabela, clica numa linha para ver a jornada completa dessa pessoa. No cartão "Confiança nos números", pela pessoa é esta ligação — conta como atribuída porque é o mesmo email dos dois lados, não um palpite.

Neste funil a venda não fecha na página — fecha ao telefone, semanas depois, e quem a regista é o CRM. Até aqui o Alvo via o lead entrar e mais nada, para sempre. Com esta ponte, cada mudança de fase no Twenty volta como uma etapa do funil.

No Twenty, em Definições → Webhooks, cria um webhook com o URL https://alvo.inovaverse.com/api/ingest/crm, o segredo que puseres em CRM_WEBHOOK_SECRET no .env do Alvo, e os eventos opportunity.created e opportunity.updated.

As fases traduzem-se assim: NEW → lead, SCREENING → lead qualificada, MEETING → agendamento, PROPOSAL → oportunidade, CUSTOMER → venda. Se mudares o nome de uma fase no Twenty, ajusta o CRM_FASES no .env — uma fase por mapear não é traduzida às cegas, fica apenas registada no log.

Nos Filtros, escolhe Opportunities e não "Todos os Objetos": com todos, o Twenty envia para cá cada nota, cada tarefa e cada email e mensagem que sincroniza das tuas contas. O Alvo ignora-os, mas não há razão para o conteúdo das tuas caixas de correio passar por uma aplicação de atribuição.

Medir melhor não muda nada sozinho: quem decide a quem mostrar os anúncios é o algoritmo da Meta, e ele só aprende com o que lhe chega de volta. Se o único sinal que recebe for "preencheu o formulário", é gente que preenche formulários que ele vai procurar — e a maior parte dessa nunca aparece à chamada.

O Alvo devolve-lhe as etapas caras — agendou, apareceu, comprou e por quanto — e é isso que o faz procurar quem compra. Precisa de duas coisas no .env: META_ACCESS_TOKEN e META_PIXEL_ID. Sem elas fica desligado e o worker diz-te.

O email e o telefone vão sempre em SHA-256, nunca em claro. O event_id que já usas na ingestão é o mesmo que a Meta usa para deduplicar contra o pixel dela — foi para isto que ele existiu desde o início.

O Alvo guarda coisas sobre pessoas reais. O fundamento é o interesse legítimo em medir a eficácia de publicidade própria — mas legítimo não é ilimitado, e por isso há prazos automáticos:

• IP e dispositivo apagam-se ao fim de MINIMIZACAO_DIAS (2 por omissão). Só servem para atribuir uma conversão nas 6 horas seguintes ao clique; depois disso são dado identificável sem uso. O resto do clique fica — campanha, criativo, UTMs — e nada disso identifica ninguém.
• Tudo o resto é apagado ao fim de RETENCAO_DIAS (400 por omissão). Pôr a 0 desliga a purga, e aí passas a não ter prazo nenhum, o que é uma decisão a tomar de olhos abertos.

Quando alguém pedir para ver ou apagar os seus dados, usa POST /api/privacidade/exportar e /apagar com o email ou o telefone. O apagamento remove a pessoa e o contacto de todos os eventos, mas não apaga as vendas: uma venda de 3 000 € continuou a acontecer e continua a contar para o resultado da campanha. O que desaparece é quem a fez.

Para esta tabela funcionar, marca o link de cada anúncio com utm_content = identificador do criativo. Exemplo: https://alvo.inovaverse.com/r/promo-julho?utm_content=video-depoimento.

Sem isso, os cliques aparecem todos juntos em "(sem identificação)" — e essa linha grande é ela própria o aviso de que os links precisam de ser marcados.

É o segredo que autoriza chamadas a /api/ingest/conversion — guarda-o só nos sistemas que registam conversões (ex: script no "obrigado" do formulário), nunca o exponhas em páginas públicas.

A carregar...