Enxergar o cliente que fica — não só a venda que entra.
Estruturar o dado da jornada completa, do primeiro clique à renovação do 12º mês, para que aumentar o investimento em Meta e Google deixe de ser aposta e passe a ser decisão.
O pixel para de contar na primeira venda.
O produto já converte e a operação já roda. O gargalo não está na campanha — está no que as plataformas e os relatórios conseguem enxergar do que acontece depois do clique.
Um assinante de SaaS não vale o que pagou hoje. Vale o que vai pagar no 3º, no 6º e no 12º mês. Mas o Meta e o Google só recebem o sinal da primeira cobrança — quando recebem. A segunda renovação, a terceira, a mudança de plano: nada disso volta para as plataformas. O algoritmo otimiza para uma fração do valor real de cada cliente.
Do lado da decisão, a leitura disponível hoje é a de último clique: quem levou o crédito pela conversão. Isso responde "qual anúncio apareceu por último". Não responde "qual canal traz gente que fica" — que é a pergunta que define até onde dá para subir o orçamento.
O efeito prático é conhecido: o teto de investimento passa a ser definido pela confiança, não pelo dado. Sem saber o CAC real por campanha e o retorno acumulado por origem, cada aumento de orçamento é um teste caro — e a decisão de cortar uma campanha "cara" pode estar matando justamente o canal que traz o melhor cliente.
Trackeamento não é rastreamento.
Rastreamento é você entender. Trackeamento é a máquina entender.
Por que o dado quebra antes de chegar
O pixel não é seu. Ele é uma câmera instalada pela plataforma de anúncios — com endereço de outro domínio — dentro do seu site. E o navegador do visitante enxerga isso. A partir daí, ele pode tomar cinco decisões que bloqueiam o seu dado, em ordem crescente de gravidade:
O navegador detecta que o script é de outro domínio — GTM externo, UTMify, qualquer terceiro — e bloqueia antes de carregar. Bloqueadores, Safari ITP e as proteções nativas do iOS fazem isso hoje, silenciosamente.
O script carrega, mas o disparo do evento é impedido. Extensões de privacidade, Firefox com proteção avançada, iOS com Private Relay. O pixel está instalado — e não captura nada.
O evento dispara, mas ITP, DNS bloqueando domínios de tracking ou firewall corporativo impedem que ele chegue à plataforma. Foto tirada, não entregue.
Aqui começa o que quase ninguém comenta. O evento chega, mas sem dizer de qual campanha veio: referrer removido, UTM cortada na transição para o checkout, gclid ou fbclid perdido no caminho. A conversão existe e não está atribuída a anúncio nenhum.
O mais escondido de todos. Sem cookie de terceiro, sem external_id junto do evento, a plataforma recebe a conversão, sabe a campanha — e não sabe quem converteu. Não consegue procurar pessoas parecidas. Campanha burra, sem escala, e ninguém sabe por quê.
As decisões 4 e 5 são onde a maioria das operações quebra — e são exatamente as que GTM, Stape e "server-side" convencional não resolvem. Server-side conserta o problema de entrega: o dado sai do seu servidor em vez do navegador. Mas o que o servidor recebe é o que o navegador coletou antes. Se a coleta falhou, o servidor não recebe lixo: recebe silêncio. E envia silêncio. A nota do gerenciador continua alta porque ela mede os eventos que chegaram — não os que deveriam ter chegado.
A saída é não depender do navegador do visitante.
Os 3 pilares
Um tracking só escala campanha quando os três estão corretos ao mesmo tempo. Faltando um, os outros dois não compensam.
Marcação de eventos
O evento chega. Visita, cadastro, início de checkout, teste grátis, assinatura e renovação — com os parâmetros completos, mesmo com bloqueador ativo, iOS com Private Relay ou Safari ITP funcionando.
Atribuição de anúncios
A plataforma sabe de qual campanha, conjunto e anúncio o evento veio. Sem referrer removido, sem UTM cortada na transição para o checkout da Ticto, sem gclid ou fbclid perdido no meio do caminho.
Atribuição de usuários
A plataforma sabe quem converteu — o external_id ligado à pessoa real na base dela. Sem este pilar a campanha continua burra mesmo com os dois primeiros certos: o algoritmo não consegue procurar gente parecida com quem assina e renova.
O mesmo dado, do seu lado
Os três pilares existem para a máquina entender. Mas a mesma coleta produz, do seu lado, o registro cru da operação — e é isso que o dashboard lê. Não são "métricas da plataforma": são os dados reais, evento a evento, usuário a usuário.
- Visualizações de página e sessões, com origem, por visitante identificado — inclusive quem voltou depois por outra fonte.
- Início de checkout na Ticto, incluindo quem começou e não terminou.
- Cadastro, primeiro cartaz e uso do teste grátis — a ativação real dentro do produto.
- Aquisições por plano, com a primeira assinatura e cada renovação registradas separadamente.
- A jornada completa de cada usuário, em ordem cronológica, do primeiro anúncio à última cobrança.
- Retenção individual: quem continuou pagando, por quantos meses, e quanto já gerou desde a aquisição.
É essa granularidade que viabiliza as tabelas de cohort. Cohort não é um gráfico que se liga num painel: é a consequência de ter, para cada cliente, a data de aquisição, a origem e todo o histórico de receita. Sem o registro por usuário, cohort é estimativa. Com ele, é contagem.
Onde cada coisa vive.
A estrutura respeita a decisão de não migrar infraestrutura agora — e já nasce desenhada para permitir a separação no futuro, se o crescimento justificar.
Coleta — no próprio domínio
Um Worker na Cloudflare rodando em cartazista.online, servindo o script de coleta e recebendo os eventos em rotas do próprio domínio. Sem GTM, sem script de terceiro, sem depender de bloqueadores permitirem a chamada. O identificador do visitante é um cookie first-party (HttpOnly, Secure, 2 anos), gravado pelo próprio Worker — não um cookie de terceiro que o navegador descarta.
Assinaturas — webhook da Ticto
A Ticto é a fonte da verdade de pagamento, renovação e cancelamento. O identificador do visitante viaja com ele até o checkout, no parâmetro indexador da Ticto, e volta no webhook — é isso que amarra a compra à origem. O parser da Ticto já existe e está em produção na base de código que uso, o que retira desta entrega o risco de mapear um gateway do zero.
Armazenamento — no Supabase que já existe
Conforme a sua preferência, os dados de marketing ficam no mesmo projeto Supabase, porém em schema dedicado — tabelas próprias, índices próprios, permissões próprias. A escrita de tracking não toca nas tabelas operacionais do SaaS.
Sobre o risco de performance: a escrita é pequena e assíncrona (não entra no caminho crítico de nenhuma tela do produto), e as consultas pesadas do dashboard rodam sobre tabelas agregadas, não sobre a base bruta. E, por viver em schema separado com fronteira explícita, o dia em que o volume justificar um banco dedicado é uma troca de destino de escrita — não uma reescrita do sistema.
Saída de sinal — de volta às plataformas
Meta Conversions API com deduplicação por event_id contra o pixel do navegador (nada é contado duas vezes) e Google Ads com Enhanced Conversions. A importação de conversões offline no Google — que é o que credita uma renovação de daqui a seis meses ao clique que a originou — depende de uma aprovação do próprio Google, detalhada na seção 11.
Trackeamento (Meta e Google).
A camada que faz o dado existir e chegar íntegro — nas plataformas e no seu banco. É pré-requisito técnico do dashboard: sem ela, o painel mostraria a mesma leitura incompleta de hoje, só que mais bonita.
Entregáveis
- Worker de coleta no domínio próprio — script servido e eventos recebidos em cartazista.online, sem GTM e sem intermediários.
- Identidade first-party persistente — cookie próprio de 2 anos, criado na primeira visita, que sobrevive a sessões, fechamento do navegador e retorno por outra fonte.
- UTMs à prova de falha — captura e persistência de UTMs, gclid, gbraid, wbraid e fbclid, incluindo a passagem para o checkout da Ticto.
- Costura com o Supabase — o ID anônimo é vinculado ao user_id no cadastro. É o que mantém o vínculo cliente ↔ origem meses depois.
- Mapeamento e implementação dos eventos na landing e dentro do app: visita, cadastro, primeiro cartaz (ativação), início do teste grátis, início de checkout, 1ª assinatura e renovação.
- Separação explícita entre aquisição e recorrência — novo assinante e assinante existente trafegam como eventos distintos, com valores distintos.
- Integração com a Ticto por webhook, como fonte da verdade de pagamento, renovação e cancelamento.
- Meta · Conversions API com dados avançados de correspondência (e-mail e telefone com hash), external_id e deduplicação por event_id contra o pixel.
- Google Ads · Enhanced Conversions no web, com os identificadores de clique preservados. A importação offline de renovações entra conforme a seção 11.
- Painel de diagnóstico de eventos — o que foi enviado, para qual plataforma, com qual resposta, e reprocessamento de falhas.
- Documentação e validação assistida ponta a ponta, com eventos reais, antes da entrega.
Dashboard de crescimento.
Nove telas, desenhadas a partir das perguntas que você fez — e não a partir do que a ferramenta consegue mostrar.
Visão geral
- Investimento, cadastros, CAC, novos assinantes e MRR do período
- ROAS da primeira venda e ROAS considerando recorrência, lado a lado
- Churn, LTV e ARPU com comparativo contra o período anterior
- Filtro global por data, canal, campanha e plano
Aquisição
- Visitantes, sessões e visualizações de página por origem e canal
- Recorte por campanha, conjunto, anúncio e UTM
- Cadastros e custo por cadastro em cada nível
- Investimento diário vs. volume de cadastros
Funil de conversão
- Visita → cadastro → primeiro cartaz → teste grátis → checkout → assinatura
- Taxa de passagem e volume perdido em cada etapa
- Checkouts iniciados e não concluídos na Ticto
- O mesmo funil recortado por campanha, para ver onde cada canal trava
Jornada e atribuição
- Linha do tempo completa de cada cliente, com todos os pontos de contato
- First-click, last-click e all-clicks comparados na mesma tela
- Caminhos de conversão mais frequentes (ex.: Meta → orgânico → Google)
- Quanto cada canal ganha ou perde conforme o modelo de atribuição
Ativação e uso
- Cadastro → primeiro uso / primeiro cartaz
- Ativação e intensidade de uso durante o teste grátis
- Conversão trial → assinatura por origem
- Correlação entre uso no trial e permanência depois
Receita e recorrência
- MRR com abertura entre nova receita, expansão, renovação e perda
- Primeira assinatura vs. renovações, separadas
- Cancelamentos e churn (de clientes e de receita)
- Ticket médio / ARPU e distribuição por plano adquirido
Cohorts e LTV
- Cohorts por mês de aquisição cruzados com origem e campanha
- Curva de retenção mês a mês por cohort
- Receita acumulada e LTV por cohort e por canal
- Payback: em quantos meses cada canal devolve o CAC
Campanhas · Meta e Google
- Meta e Google na mesma tabela, com a mesma régua
- Custo, CPM, CPC, CTR por campanha, conjunto e anúncio
- Ao lado: cadastros, assinaturas, receita e LTV gerados de fato
- CAC real e ROAS de 1ª venda vs. ROAS de LTV por campanha
Clientes, acessos e auditoria
- Base de clientes com origem, data de aquisição, plano e receita acumulada
- Busca por cliente para abrir a jornada individual completa
- Exportação em CSV das visões principais
- Login individual por usuário e registro de acessos
Tudo que você listou — e onde aparece.
Cada métrica que você pediu está contemplada. Abaixo, agrupadas pela pergunta de negócio que respondem.
Aquisição
Ativação
Receita
Retenção
Atribuição e retorno
O que o painel faz com as plataformas.
Você perguntou qual seria o escopo do gerenciador próprio e quais ações dariam para executar direto pela plataforma. A resposta, com a fronteira clara:
Nesta entrega · Leitura completa e unificada
- Meta e Google na mesma tabela, com a mesma régua e o mesmo período — sem abrir dois gerenciadores e conciliar na mão.
- Métricas de mídia por nível: investimento, impressões, cliques, CPM, CPC, CTR e alcance por campanha, conjunto e anúncio.
- Cruzamento com o que aconteceu depois do clique: cadastros, ativações, assinaturas, renovações e receita acumulada — vindos do seu banco, não do relatório da plataforma.
- CAC real e ROAS por campanha, em duas leituras: primeira venda e LTV.
- Alertas de leitura: campanhas acima do CAC alvo e campanhas com CAC alto na primeira venda mas LTV acima da média — o caso clássico do canal que parece caro e é o melhor.
Fora desta entrega · Ações de escrita
Pausar, ativar, alterar orçamento, editar segmentação e criar campanhas pelo painel são ações de escrita nas APIs. Executá-las com segurança exige tratar limites de requisição, fila de execução, permissões por usuário, rollback e auditoria — um bloco de trabalho que não cabe nesta primeira entrega sem inflar prazo e valor.
Na prática, o ganho está na decisão, não no clique de pausar: com o CAC e o LTV reais por campanha na tela, a ação no gerenciador leva segundos. Fica mapeado como módulo de evolução, orçado à parte quando a camada de leitura estiver rodando com dados acumulados.
Proposta comercial.
Os módulos podem ser contratados separadamente. O trackeamento é pré-requisito técnico do dashboard — contratado sozinho, o dashboard trabalharia sobre um dado incompleto.
O projeto completo: a fundação de dados e a leitura dela, construídas juntas e validadas ponta a ponta. É o formato que entrega a resposta inteira — do custo do clique à renovação do 12º mês.
Aprovação da proposta
Cinco semanas, com entrega intermediária.
Início a definir, após a confirmação do pagamento e a liberação dos acessos. As semanas contam a partir do início do mapeamento. O trackeamento entra em produção na semana 2 — ou seja, o dado já começa a ser acumulado enquanto o dashboard é construído.
Domínio, acessos e mapeamento
Definição e execução da rota de DNS (seção 10), criação do schema de tracking no Supabase, liberação dos acessos, abertura do pedido de token do Google (seção 11) e mapeamento definitivo dos eventos: quais ações do app viram sinal, com quais parâmetros e qual valor.
Trackeamento em produção · Entrega do Módulo 1
Worker no ar, eventos implementados na landing e no app, webhook da Ticto integrado, envio para Meta CAPI com dedupe e Google Ads com Enhanced Conversions, e validação assistida com conversões reais.
Base analítica e integrações de mídia
Modelagem das tabelas agregadas (funil, cohort, MRR, atribuição), ingestão diária do custo de mídia pela via definida na seção 11, e construção das telas do dashboard.
Validação assistida e handover · Entrega do Módulo 2
Conferência dos números contra as fontes originais (Supabase, Ticto e gerenciadores), ajustes finais, e passagem de uso com a documentação de como ler cada tela.
Duas rotas para rodar no seu domínio.
Todo o valor do trackeamento vem de o código rodar no próprio cartazista.online. Como a zona hoje é administrada na GoDaddy, existem duas formas de chegar lá — e a escolha é sua. Em ambas, precisarei de acesso à GoDaddy (ou de alguém do seu time executando comigo, ao vivo).
Recomendada Rota A · Migrar a zona para a Cloudflare
O registro do domínio continua na GoDaddy — muda apenas o servidor de nomes (nameserver), que passa a ser o da Cloudflare. Todos os registros atuais são copiados antes da troca, o processo é feito em conjunto e não derruba o site nem o e-mail.
- Custo: zero. O plano gratuito da Cloudflare atende o escopo.
- Alcance: o tracking roda no domínio raiz e em qualquer subdomínio, sem limitação.
- Ganho extra: CDN, cache e proteção da Cloudflare passam a valer para o SaaS inteiro.
- Contrapartida: a gestão de DNS passa a ser feita no painel da Cloudflare, não mais na GoDaddy.
Rota B · Manter a GoDaddy e delegar um subdomínio
A zona continua inteiramente na GoDaddy. Criamos um subdomínio dedicado à coleta (por exemplo dados.cartazista.online) e apontamos apenas ele para a nossa infraestrutura na Cloudflare, via um único registro CNAME. O certificado é emitido e renovado automaticamente.
- O cookie continua first-party, porque o subdomínio compartilha o mesmo domínio registrável do site — o navegador o trata como casa própria, não como terceiro.
- Custo: baixo, porém não nulo — exige plano pago da Cloudflare para hostname personalizado (na ordem de poucos dólares por mês, por conta do cliente).
- Contrapartida: uma camada a mais de configuração e um ponto extra de manutenção quando houver mudança de DNS.
Minha recomendação é a Rota A: é mais simples, é gratuita, e elimina o intermediário de forma definitiva. A Rota B existe para o caso de haver uma restrição interna para trocar o nameserver — e resolve igualmente bem o problema técnico.
O que depende de aprovação do Google.
Prefiro deixar isto explícito na proposta a descobrir junto na semana 3. É a única parte do projeto cujo prazo não está sob meu controle nem sob o seu.
O que funciona desde o primeiro dia
- Meta, por completo. A Conversions API depende apenas de um token gerado no seu próprio Business Manager. Cadastro, trial, primeira assinatura e renovação passam a ser enviados server-side, com identidade e atribuição, sem aprovação de ninguém.
- Google Ads no web. Conversões e Enhanced Conversions com os identificadores de clique preservados funcionam com a configuração normal da conta.
- Todo o dado do seu lado. A coleta, o banco, a jornada, os cohorts e o LTV não dependem de aprovação nenhuma — o dado é seu e fica no seu Supabase.
O que depende de aprovação — e o plano B
Duas funções específicas passam pela Google Ads API, que exige um developer token aprovado pelo Google: (1) puxar o custo de mídia por campanha, conjunto e anúncio para dentro do dashboard, e (2) importar conversões offline — o mecanismo que credita uma renovação de daqui a seis meses ao clique original.
A aprovação exige uma conta administradora (MCC), dados formais da empresa e uma descrição do uso da API. É um processo do Google: costuma levar de alguns dias a algumas semanas, e não há como acelerar por fora.
Como isso não trava o projeto
- O pedido é aberto na semana 1, junto com os acessos, para que o relógio do Google comece a correr no primeiro dia.
- Plano B para o custo de mídia: enquanto o token não sai, o investimento por campanha entra no dashboard por um conector de dados (tipo Stract, Supermetrics ou equivalente), autorizando a leitura da conta e tratando o retorno antes de gravar no Supabase. O dashboard não fica esperando: nasce completo, só troca a fonte do custo depois.
- Plano B para as renovações no Google: importação periódica das conversões offline pelo próprio painel do Google Ads, a partir de um arquivo que o sistema gera pronto. Menos elegante e não contínuo, mas o sinal chega.
- Assim que o token for aprovado, a troca para a API oficial é feita sem custo adicional e sem refazer o dashboard — a fonte muda, as telas não.
O eventual custo mensal do conector de dados é do cliente e não está incluso no valor da proposta.
O que preciso para começar.
Nada aqui é bloqueio — mas o cronograma da semana 1 depende destes itens. Todos podem ser resolvidos juntos, em uma chamada.
- GoDaddy — acesso ao painel de DNS do cartazista.online, para executar a rota escolhida na seção 10.
- Conta Cloudflare — sua, para que o Worker e o domínio fiquem sob o seu controle desde o primeiro dia.
- Supabase — acesso ao projeto para criar o schema de tracking e ler as tabelas de usuários e assinaturas.
- Projeto no Lovable — para instalar o script e marcar os eventos do app (cadastro, primeiro cartaz, início de trial). Alternativamente, entrego as instruções para o seu time aplicar.
- Ticto — acesso para configurar o webhook de compra, renovação e cancelamento, e o parâmetro de rastreio no checkout.
- Meta Business — acesso ao pixel, à conta de anúncios e permissão para gerar o token da Conversions API.
- Google Ads — acesso à conta, mais os dados formais da empresa para abrir o pedido de developer token logo na semana 1.
O combinado entre as partes.
- O trackeamento é pré-requisito do dashboard. Contratado isoladamente, o dashboard trabalharia com o dado incompleto que existe hoje — sem origem confiável por cliente e sem vínculo entre renovação e campanha.
- Cohorts e jornada começam a contar a partir da implementação. Não existe forma honesta de recuperar a origem de mídia de quem se cadastrou antes. O histórico já registrado no Supabase e na Ticto (assinaturas, receita, cancelamentos) entra no dashboard normalmente — porém sem origem de campanha atribuída.
- Os dados de marketing ficam no Supabase atual, em schema dedicado, sem alterar as tabelas operacionais do SaaS. A arquitetura já nasce preparada para separação futura, caso o crescimento justifique.
- As marcações dentro do app dependem de pontos no código do Lovable. Com acesso ao projeto, eu aplico; sem acesso, entrego as instruções exatas e o seu time aplica — nesse caso o prazo depende dessa execução.
- O prazo da Google Ads API é do Google. Conforme a seção 11, o projeto é entregue completo pelas rotas alternativas caso a aprovação não saia dentro das 5 semanas, e migra para a API oficial sem custo adicional quando sair.
- Fidelidade de atribuição. O sistema recupera a maior parte da jornada, mas nenhuma solução recupera 100%: navegação anônima, troca de dispositivo sem login e recusa de consentimento sempre deixam lacunas. O compromisso é com um dado íntegro e auditável, não com um número mágico.
- Custos de terceiros não estão inclusos — Cloudflare, Supabase, conector de dados de mídia e eventuais limites de API.
- Dados pessoais trafegam com hash (e-mail e telefone) nos envios às plataformas, e o comportamento de consentimento respeita a política de privacidade do CARTAZISTA.online.
- Será criado um grupo de WhatsApp para alinhamentos durante o projeto.
O que não está incluído.
Para clareza entre as partes, os itens abaixo não fazem parte deste projeto — todos podem ser tratados em um segundo momento, com escopo e orçamento próprios:
Para dar o sim.
- Aprovação do escopo e do formato — módulos separados ou combo.
- Pagamento via Pix — a confirmação libera o início da semana 1.
- Escolha da rota de DNS — migrar a zona para a Cloudflare (recomendado) ou delegar um subdomínio mantendo a GoDaddy.
- Chamada de setup — execução do DNS, liberação dos acessos e abertura do pedido do developer token do Google, tudo em uma sessão.
- Mapeamento de eventos — validação de quais ações do produto viram sinal e com qual valor.
De acordo
Trackeamento, dados e decisão para quem investe em mídia.