material da comunidade 7 prompts na ordem pare de achar que anúncio não funciona use Opus 4.8 ou Opus 5

crie o seu trackz

passo a passo

7 prompts, 1 dia

Crie o seu Trackz
e descubra de onde vem cada venda.

Hoje você olha o painel do gateway e vê que vendeu. Só isso. Não sabe se veio do anúncio, do story de terça, do link na bio ou daquele botão lá no meio da página. Vai construir a ferramenta que responde isso: um carimbo que sai das suas páginas e volta dentro do pedido, e um painel que junta os dois lados. Ligado na Cakto, com o conceito explicado pra você plugar em qualquer outro gateway depois.

7 prompts prontos peça Opus 4.8 ou Opus 5 rastreio próprio, sem mensalidade botão a botão

Painel mostrando quanto do faturamento tem origem identificada — **O destino.** Print de verdade do painel rodando. Olha a barra do meio: **62,5% da receita chegou sem origem nenhuma**. Esse número é o motivo desse material existir, e no seu negócio ele provavelmente é pior.

Como rastreio funciona de verdade

Antes de qualquer prompt, entenda a mecânica. Rastreio tem dois lados que precisam se encontrar num campo só.

Lado um, a sua página. A pessoa chega vinda de algum lugar (um anúncio, um story, um link na bio). Esse lugar está escrito na URL, nos tais parâmetros utm. O seu script guarda isso e, quando ela clica em qualquer botão que leva pro checkout, ele carimba o link com a origem mais o nome do botão que ela clicou.

Lado dois, o gateway. Todo gateway sério tem um campo livre que ele aceita na URL do checkout e devolve junto do pedido. Na Cakto esse campo se chama sck (e tem o src como irmão). É nele que o carimbo viaja.

Quando a venda acontece, você pede os pedidos pra API do gateway e cada um vem com o carimbo dentro. Aí é só ler. É isso. O resto do material é fazer isso bonito e confiável.

instagram-bio-setembro--passo100k.faixa-final

origem de onde a pessoa veio antes de entrar no seu site

página em qual das suas páginas ela estava quando clicou

botão qual botão daquela página ela clicou

Vai usar outro gateway? Procure por essas duas coisas

Esse material conecta na Cakto, mas a receita é a mesma em qualquer lugar. Na documentação do seu gateway, procure: (1) um parâmetro livre que ele aceita no link do checkout e devolve no pedido (aparece como sck, src, custom, tracking ou external_reference, dependendo da casa) e (2) uma API de pedidos com paginação.

Se existirem os dois, só o passo 04 muda. O script, o banco, a classificação e o painel inteiro continuam iguais. Se o seu gateway não tiver o campo livre, o rastreio fica limitado ao que os utm sozinhos contam, que é bem menos.

Use no mínimo o Opus 4.8. Se tiver Opus 5, use o Opus 5.

O script de rastreio é a parte mais traiçoeira que você vai construir nessa série: ele roda no navegador dos outros, não pode quebrar a página de ninguém, e falha calado quando erra. Modelo leve escreve algo que parece certo e some com metade dos eventos.

Modelo em Opus e uma conversa só do primeiro ao último prompt.
Conta no Supabase com um projeto novo.
As credenciais da API da Cakto, que saem no painel dela em integrações. Você vai precisar do id e do segredo do cliente.
Pelo menos uma página sua no ar pra colar o script e ver o número mexer.

Prompt 01: o carimbo

Um arquivo de JavaScript que você cola no topo de qualquer página sua, com uma linha. Ele faz três coisas: guarda de onde a pessoa veio, carimba os links de saída e registra visita e clique.

Dentro do prompt tem três detalhes que só se aprende apanhando, e que estão lá porque eu apanhei: o jeito certo de mandar o evento sem o navegador bloquear, o separador que não suja a URL, e a regra de nunca carimbar link de programa de parceiro, que destrói o código que te credita a comissão.

Prompt 01 · o script de rastreio

Você é um engenheiro front-end sênior. Vamos construir o meu próprio rastreador de vendas. Comece pelo pedaço que roda no navegador de quem visita as minhas páginas.

O QUE É
Um único arquivo JavaScript puro, sem framework e sem dependência, que eu colo no topo de qualquer página minha com uma linha:
script src apontando pro meu arquivo, com um atributo data-pagina com o apelido daquela página, e defer.

REGRA ZERO: ele roda em páginas que já funcionam. Se ele quebrar, quebra o meu faturamento. Todo acesso a armazenamento, URL e rede tem que estar protegido contra erro. Nada pode estourar exceção pra fora.

O QUE ELE FAZ

1. DESCOBRE E GUARDA A ORIGEM
- Lê da URL: utm_source, utm_medium, utm_campaign, utm_content, utm_term, sck e src.
- Se achou algum, guarda no armazenamento local com a data, e essa vira a origem daquela pessoa por 30 dias. Ela pode sair, voltar depois por outro caminho e comprar: a origem que vale é a primeira que trouxe ela.
- Se não achou nada mas veio de outro site, traduz o endereço de origem pra um nome limpo (instagram, facebook, youtube, tiktok, google, whatsapp) e usa isso como origem, com o meio marcado como indicação.
- Se não achou nada e não veio de lugar nenhum, a origem é "direto".

2. CARIMBA OS LINKS DE SAÍDA
- Percorre todos os links da página e, nos que levam pro checkout ou pra outra página minha, acrescenta os utm da origem guardada mais dois campos com o carimbo completo: sck e src.
- O carimbo tem o formato: origem--pagina.botao
Exemplo: instagram-bio-setembro--pagina-de-vendas.faixa-final
- O nome do botão sai do atributo data-slot no próprio link ou em qualquer elemento pai dele. Se não tiver, usa o texto do botão, limpo e cortado.
- Se a pessoa veio de OUTRA página minha que já tinha carimbo, junte as duas: pagina1_pagina2.botao. Assim eu vejo o caminho, não só a última página.
- Use um MutationObserver pra carimbar também os links que aparecem depois (pop-up, conteúdo que carrega depois).
- Tudo em minúsculo, sem acento, trocando o que não for letra ou número por hífen. O separador entre página e botão é PONTO, nunca dois pontos: dois pontos viram %3A e sujam a URL.

3. REGISTRA VISITA E CLIQUE
- Ao abrir a página, manda um evento de visita. Ao clicar num link de saída, manda um evento de clique.
- Cada evento leva: apelido da página, um identificador de sessão, a origem, o nome do botão, o destino, o carimbo e se é celular ou computador.
- Manda com fetch usando keepalive verdadeiro. NÃO use sendBeacon com corpo JSON: ele dispara verificação de origem no servidor e falha calado. Já testei, não funciona.
- Se o envio falhar, ignore em silêncio. Métrica nunca pode atrapalhar a venda.

4. A REGRA DO LINK DE PARCEIRO (importante)
Links de programa de parceiro (onde eu ganho comissão por indicação) já carregam um código que me credita. Se o script escrever por cima, eu perco a comissão pra ganhar uma métrica.
Então: crie uma lista separada de domínios que devem ser CONTADOS mas NUNCA carimbados. O clique é registrado, a URL sai intacta.

ENTREGA
- Um arquivo só, comentado no topo com o exemplo de instalação.
- Me diga como testar: abrir uma página com utm na URL, olhar o link do botão antes e depois, e ver o evento chegando.
- Nada de TODO, nada de função vazia.

O banco dos eventos, com um problema novo

Aqui tem uma situação que não apareceu nos outros materiais. O script roda no navegador de qualquer pessoa, então a chave que ele usa pra gravar fica visível pra todo mundo. Não tem como esconder: é código que roda na máquina dos outros.

A saída não é esconder a chave, é fazer com que ela não sirva pra nada além de gravar. A tabela aceita inserção de quem tem a chave pública, e não deixa ninguém ler nada. A leitura sai por uma função separada, que só responde com uma senha que mora no servidor.

SQL · cole no editor do Supabase

-- 1. OS EVENTOS DE RASTREIO (visita e clique)
create table if not exists track_ev (
  id bigserial primary key,
  criado_em timestamptz not null default now(),
  tipo text not null,                 -- 'view' ou 'click'
  pagina text not null default '',
  sess text not null default '',
  slot text,                          -- nome do botao
  destino text,
  sck text,                           -- o carimbo completo
  source text default '',
  medium text default '',
  campaign text default '',
  content text default '',
  ref text default '',
  dev text default ''                 -- mobile ou desktop
);
create index if not exists track_ev_data on track_ev(criado_em desc);
create index if not exists track_ev_pagina on track_ev(pagina);

-- 2. A TRAVA: grava sim, le nao
-- A chave publica fica exposta dentro do script (nao tem como esconder).
-- Entao ela pode APENAS inserir, e com limite de tamanho em cada campo.
alter table track_ev enable row level security;

drop policy if exists track_ev_insert on track_ev;
create policy track_ev_insert on track_ev
  for insert to anon
  with check (
    tipo in ('view','click')
    and length(coalesce(pagina,'')) between 1 and 60
    and length(coalesce(slot,'')) <= 60
    and length(coalesce(destino,'')) <= 200
    and length(coalesce(sck,'')) <= 200
    and length(coalesce(source,'')) <= 60
    and length(coalesce(campaign,'')) <= 90
    and length(coalesce(ref,'')) <= 200
  );
-- nenhuma policy de select: ninguem le com a chave publica.

-- 3. A LEITURA, so com a chave que mora no servidor
create or replace function track_resumo(p_key text, p_dias int default 30)
returns table (
  pagina text, slot text, tipo text, destino text, sck text,
  source text, dev text, dia date, total bigint
)
language plpgsql stable security definer set search_path = public as $$
begin
  if p_key is null or p_key <> current_setting('app.track_key', true) then
    raise exception 'sem permissao';
  end if;
  return query
    select e.pagina, e.slot, e.tipo, e.destino, e.sck, e.source, e.dev,
           (e.criado_em at time zone 'America/Sao_Paulo')::date as dia,
           count(*)::bigint
    from track_ev e
    where e.criado_em > now() - (p_dias || ' days')::interval
    group by 1,2,3,4,5,6,7,8;
end $$;

-- guarde a sua chave de leitura (troque pelo seu valor secreto)
-- rode uma vez, como dono do banco:
alter database postgres set app.track_key = 'TROQUE_POR_UMA_SENHA_LONGA';

Por que o limite de tamanho em cada campo

Com a chave pública exposta, qualquer pessoa consegue inserir linha na sua tabela. Não dá pra impedir sem quebrar o rastreio. O que dá é limitar o estrago: campo curto significa que ninguém enche o seu banco com um texto de 5MB por requisição. É o mesmo raciocínio de porta de vidro com grade: você não esconde, você limita.

Prompt 02: ler os pedidos da Cakto

Agora o outro lado. Uma rota no seu servidor troca as suas credenciais por um token, pagina a lista de pedidos e guarda em memória por alguns minutos, pra você não bater na API a cada clique no painel.

É esse o único passo que muda se você trocar de gateway. Por isso o prompt manda a IA isolar essa parte num arquivo só, com um formato de saída fixo. Trocar de gateway vira reescrever um arquivo, não o projeto.

Prompt 02 · a fonte das vendas

Agora a parte que roda no servidor e busca as minhas vendas. Vou usar a Cakto.

AUTENTICAÇÃO
- Troque as minhas credenciais por um token: uma requisição POST pra https://api.cakto.com.br/public_api/token/ com o corpo em formato de formulário, mandando client_id e client_secret, que ficam em variáveis de ambiente do servidor. Nunca no código.
- Guarde o token em memória até pouco antes de expirar, pra não pedir token toda hora.

BUSCA DOS PEDIDOS
- GET em https://api.cakto.com.br/public_api/orders/ com limite de 100 por página, seguindo a paginação enquanto houver próxima página, com um teto de segurança de páginas pra nunca entrar em laço infinito.
- Mande o token no cabeçalho de autorização.
- Guarde o resultado em memória por 5 minutos. O painel vai ser aberto várias vezes seguidas e não pode martelar a API.

NORMALIZE PARA UM FORMATO MEU
Não deixe o resto do sistema conhecer o formato da Cakto. Converta cada pedido para um objeto meu com exatamente estes campos:
id, status, tipo (se é principal ou order bump), produto, valor, pago (data do pagamento), criado (data do pedido), pgto (forma de pagamento), utm_source, utm_medium, utm_campaign, utm_content, sck e url do checkout.

ISOLE A FONTE (isso é uma exigência de arquitetura, não um detalhe)
Esse trecho tem que viver num arquivo separado, exportando uma função só, que devolve a lista já no MEU formato. Se um dia eu trocar de gateway, ou somar um segundo, eu escrevo outro arquivo igual e o resto do sistema não muda uma linha. Nenhum outro arquivo pode saber que existe uma empresa chamada Cakto.

CUIDADOS
- Se a API responder erro, devolva uma mensagem curta em português e não derrube o painel: mostre o que já tem em cache.
- Nunca devolva as credenciais nem o token pro navegador.
- Se a lista vier vazia, isso é um estado válido, não um erro.

Me entregue os arquivos completos e me diga como conferir que está puxando (quantos pedidos vieram, o mais recente, e se o campo sck está chegando preenchido em alguns).

Prompt 03: a classificação, o coração

Cada pedido chega com um monte de campo bagunçado: às vezes o carimbo do seu link, às vezes um código automático da plataforma de anúncio, às vezes nada. Essa é a peça que transforma essa bagunça em quatro respostas claras.

E é aqui que mora o insight mais valioso do painel inteiro: separar "não sei de onde veio" de "veio de anúncio mas sem parâmetro". O primeiro é cego. O segundo é um conserto de dez minutos que recupera dinheiro.

Prompt 03 · classificar a origem

Agora a peça que decide de onde veio cada venda. Escreva uma função pura que recebe um pedido no meu formato e devolve a origem classificada.

CADA PEDIDO CAI EM UMA DE QUATRO FAMÍLIAS, nesta ordem de checagem:

1. MEU LINK
O carimbo tem o meu padrão: origem--pagina.botao
Devolva: família meu-link, o canal (a origem), a página, o botão e um rótulo legível.
É a família mais valiosa: eu sei a página e o botão exatos.

2. ANÚNCIO IDENTIFICADO
O carimbo tem o formato que a plataforma de anúncio grava sozinha, com os pedaços separados por barra vertical, no padrão campanha, id, conjunto, id, anúncio, id, posicionamento.
Também entra aqui o pedido que não tem carimbo mas traz os utm no formato de anúncio (origem sendo a rede, e os outros campos trazendo nome e id separados por barra).
Devolva: família anuncio, canal, e os campos separados: campanha, conjunto, anúncio e posicionamento. Limpe prefixos e ids do rótulo, senão o painel vira sopa de número.

3. ANÚNCIO SEM PARÂMETRO
Não tem carimbo nenhum, mas a URL do checkout tem marca de clique de anúncio (o identificador que a rede social gruda no link quando alguém clica no anúncio).
Devolva: família anuncio-sem-tag. Traduza isso pra mim como "veio de anúncio, mas eu não configurei o parâmetro, então não dá pra saber qual".

4. SEM ORIGEM
Nada. Devolva: família sem-origem.

REGRAS
- Função pura: entra um pedido, sai um objeto. Sem banco, sem rede.
- Sempre devolva os mesmos campos, mesmo vazios, pra o painel não ter que checar existência o tempo todo.
- Nunca invente origem. Se não dá pra saber, é sem-origem, e ponto. Um painel que chuta é pior que nenhum painel.
- Escreva testes com exemplos reais de cada uma das quatro famílias e me mostre passando.

DEPOIS, agregue:
- Receita paga por família, com percentual do total.
- Receita por canal, por página, por botão, por campanha, por anúncio e por produto.
- Quanto de dinheiro está parado em pedido não pago, e quanto desse parado é sem origem.
Some sempre a receita PAGA no período. Pedido cancelado e reembolsado não entram no faturamento.

Tabela com a origem exata de cada venda e a família de cada carimbo — **É esse o resultado da classificação.** Cada linha é um carimbo, com a etiqueta da família ao lado. As verdes são as suas, as azuis são anúncio, a laranja é anúncio mal configurado e a cinza é o que você perdeu de vista.

Prompt 04: o painel

Agora a tela. A regra que guia o desenho inteiro: o painel não existe pra você admirar número, existe pra te dizer o que fazer amanhã de manhã. Por isso a primeira coisa que ele mostra não é o faturamento, é quanto do faturamento você consegue explicar.

Prompt 04 · a visão geral

Agora o painel. Uma página só, protegida por uma senha minha guardada em variável de ambiente do servidor.

VISUAL
- Fundo preto, texto quase branco, uma cor de destaque laranja, uma fonte mono nos rótulos e números. Cara de terminal, não de relatório corporativo.
- Sem gradiente, sem sombra pesada, sem emoji.
- Uma navegação por abas no topo. Um seletor de período: 7 dias, 30 dias, 90 dias, 1 ano e tudo. Um botão de atualizar que mostra que está buscando.
- Embaixo do título, a data da última atualização e quantos pedidos existem na base.

ABA VISÃO GERAL, nesta ordem

1. Faixa de seis números:
- Receita paga no período, com a quantidade de pedidos pagos embaixo.
- Ticket médio.
- Percentual da receita COM origem identificada. Esse é o número mais importante da tela.
- Receita vinda de order bump, com a quantidade.
- Dinheiro parado em pedido não pago (pix gerado e cartão recusado).
- Quanto desse parado é sem origem nenhuma.

2. Uma barra horizontal única, dividida em quatro faixas coloridas, mostrando quanto da receita paga veio de cada família: sem origem, meus links, anúncio identificado e anúncio sem parâmetro. Embaixo, a legenda de cada faixa com percentual, valor e quantidade de vendas. É a imagem que resume o negócio inteiro.

3. Receita por dia, em barras verticais simples, sem biblioteca de gráfico.

4. Top canais, em barras horizontais proporcionais, com valor e quantidade.

5. Produtos, também em barras, com o aviso de que inclui order bump.

REGRAS
- Todo número sai dos mesmos dados agregados. Nada de calcular a mesma coisa de dois jeitos em lugares diferentes.
- Formato brasileiro: R$ 12.400 e datas em dd/mm.
- Enquanto carrega, esqueleto cinza. Nunca a palavra carregando.
- Precisa ficar bom no celular, porque é de lá que eu vou olhar de manhã. Zero rolagem lateral na página.
- Se a API do gateway falhar, mostre o que tem em cache com um aviso, em vez de uma tela vazia.

Me entregue os arquivos completos e o que testar.

Painel aberto no celular — O painel no celular. É onde ele é olhado de verdade.

Prompt 05: as abas que respondem perguntas

A visão geral dá o diagnóstico. Essas quatro abas dão o remédio. A mais poderosa é a de fluxo: ela cruza os eventos do seu script com as vendas do gateway e mostra, botão por botão, quantas pessoas clicaram e quantas compraram.

Prompt 05 · as abas de análise

Agora as outras abas do painel. Todas respeitam o período escolhido no topo.

ABA "DE ONDE VEIO"
Tabela com a origem exata de cada venda, agrupada por carimbo: o carimbo, a etiqueta colorida da família, quantas vendas, quanta receita e o ticket. Ordenada por receita. É a tabela que eu abro quando quero saber o que está dando dinheiro.

ABA "ANÚNCIOS"
- Campanhas, conjuntos e anúncios que geraram venda, cada bloco em uma tabela, ordenado por receita.
- Posicionamento (onde o anúncio apareceu) também agregado.
- Um bloco chamado "sem origem: o que dá pra recuperar", explicando em uma frase quanto dinheiro chegou sem parâmetro e o que fazer pra parar de perder isso.

ABA "FLUXO NAS PÁGINAS"
Essa cruza os eventos do meu script com as vendas. Quatro números no topo: visitas rastreadas, cliques em botão de saída, clique por visita e quantas vendas trouxeram o nome de um botão.
Depois duas tabelas:
- Páginas: visitas, pessoas distintas, cliques e a taxa de clique por visita.
- Botão a botão: página, nome do botão, pra onde ele leva, cliques, vendas, receita e a conversão do botão.
A tabela botão a botão é o coração dessa aba: é ela que me diz qual lugar da página empurra pro checkout e qual só enfeita.

ABA "VENDAS"
Lista das últimas vendas pagas: quando, produto (com etiqueta quando for order bump), a origem, a família e o valor.

REGRAS
- Nada de biblioteca de gráfico nem de tabela. Barras em div, tabela em HTML.
- Toda tabela precisa de estado vazio com uma frase curta explicando por que está vazia.
- A aba de fluxo só tem dado das páginas onde o script está instalado. Deixe isso claro na tela, senão eu vou achar que está quebrado.
- Me entregue os arquivos completos e o que testar em cada aba.

Aba de fluxo mostrando páginas e a tabela botão a botão

Aba de anúncios com campanhas e criativos que venderam

Lista das últimas vendas pagas com a origem de cada uma

Aba com o trecho de instalação do script e como nomear os botões

Os valores nos prints estão trocados de propósito. A estrutura, as barras e as proporções são reais.

Prompt 06: o padrão de nomes (não pule esse)

Esse passo parece burocracia e é o que decide se o painel vai ser útil em três meses. Rastreio morre de bagunça de nome: o mesmo story vira "insta", "instagram", "ig-stories" e "Instagram Stories" em quatro links diferentes, e o painel mostra quatro linhas do que era uma coisa só.

Prompt 06 · padrão de nomes e instalação

Agora a última aba, que é o manual dentro da própria ferramenta, e o padrão de nomes que vai me salvar de bagunça.

ABA "INSTALAR"
- O trecho exato que eu colo no topo de uma página pra ligar o rastreio, com botão de copiar, e uma frase explicando o que ele faz.
- Como nomear um botão, com exemplo do atributo no próprio link e exemplo marcando uma seção inteira, também com botão de copiar. Explique que sem nome ele usa o texto do botão, o que funciona mas fica feio no relatório.
- Um exemplo do carimbo final, mostrando as três partes separadas e o que cada uma significa.

O PADRÃO DE NOMES (escreva as regras na tela, curtas)
- Sempre minúsculo, sem acento, palavras separadas por hífen.
- Origem: o lugar de onde a pessoa veio, no singular e sempre igual (instagram, youtube, whatsapp, email, anuncio).
- Página: o apelido curto daquela página, o mesmo pra sempre.
- Botão: onde ele está, não o que ele diz. Prefira faixa-topo, meio-da-pagina, oferta-final. O texto do botão muda quando eu testo copy, e aí o histórico quebra.
- Nada de data no nome, exceto em campanha.

FERRAMENTA DE APOIO
Faça uma seção onde eu escolho origem, página e botão em campos simples e ela monta o link carimbado pronto pra copiar. É pra quando eu for mandar um link no story ou pro afiliado, e não tiver o script no meio do caminho.

VALIDAÇÃO
No painel, marque com um aviso discreto os carimbos que fogem do padrão (maiúscula, acento, espaço, dois pontos). Assim eu conserto antes de virar bagunça.

Me entregue os arquivos e o texto pronto de cada explicação, escrito pra quem não é programador.

Prompt 07: no ar e o teste de ponta a ponta

O teste desse projeto é o mais divertido da série, porque ele fecha o círculo na sua frente: você abre uma página com um parâmetro inventado, clica no botão, olha a URL do checkout e vê o seu carimbo lá. Depois gera um pix, não paga, e vê o pedido aparecer no painel com o nome do botão que você clicou.

Prompt 07 · deploy e teste real

Meu rastreador funciona local. Quero ele no ar hoje.

Me guie clicado, assumindo que eu não sei o que é terminal:
1. Como subir o projeto.
2. Onde cadastrar as variáveis de ambiente (as credenciais do gateway, o endereço e a chave do banco, a chave de leitura do banco e a senha do painel) e por que nenhuma delas pode estar no código.
3. Como eu sirvo o arquivo do script num endereço fixo, pra eu poder colar a mesma linha em todas as minhas páginas.
4. Como eu ligo um domínio próprio.

TESTE DE PONTA A PONTA, faça comigo nesta ordem:
- Abrir uma página minha acrescentando na URL um utm_source inventado, por exemplo teste-do-fellipe.
- Passar o mouse no botão de compra e conferir que o link agora tem sck com origem, página e botão.
- Clicar. Na página do checkout, olhar a URL: o carimbo tem que estar lá.
- Gerar um pix e NÃO pagar.
- Abrir o painel: esse pedido tem que aparecer como parado, já com a origem certa.
- Voltar na página, clicar em outro botão, e conferir que o nome do botão mudou no carimbo.
- Abrir o painel na aba de fluxo e ver a visita e os cliques contados.
- Abrir o painel numa aba anônima sem a senha: tem que barrar.
- Procurar no que chega no navegador se alguma credencial do gateway aparece. Me prove que não.
- Abrir a página com o script no celular e conferir que nada quebrou e que o evento chegou marcado como mobile.

Depois me diga quantos minutos leva pro pedido aparecer no painel (por causa do cache) e como forçar a atualização.

O que esse painel não é

Ele responde de onde veio a venda. Ele não otimiza anúncio e não substitui o pixel: quem ensina a plataforma a achar mais gente parecida é o pixel e a API de conversão, e isso continua sendo trabalho deles. Os dois vivem juntos sem problema.

E ele não é perfeito por natureza: quem compra pelo celular depois de ver no computador, quem apaga cookie, quem abre em aba anônima, tudo isso vira sem origem. O objetivo não é 100%. É sair de 40% de vendas explicadas pra 80%, que já muda toda decisão de onde colocar dinheiro.

com o rastreio de pé você descobre qual anúncio paga a conta qual botão da página vende qual story virou dinheiro quanto está parado em pix

Os 3 loops, mirando onde rastreio mente

Rastreio quebrado é pior que rastreio nenhum, porque você toma decisão errada com cara de decisão embasada. Esses três loops existem pra você confiar no número.

Loop 01 · caça-problema

Pare de construir. Agora ataque o próprio trabalho, procurando os jeitos de o meu rastreio MENTIR.

Investigue especificamente:
- O script quebra alguma página? Teste numa página com pop-up, numa com conteúdo que carrega depois e numa que já tem outro script de análise.
- Armazenamento local bloqueado (aba anônima, navegador restrito): o script continua funcionando sem gravar, ou estoura erro e derruba a página?
- Link que já tinha utm próprio: o script sobrescreve o que já estava lá? Não pode.
- Link de programa de parceiro: o código de comissão sobrevive intacto? Esse teste é obrigatório, é dinheiro meu.
- Link relativo, link com âncora, link de telefone, link de e-mail, link com javascript: o script tenta carimbar e quebra?
- Botão que não é link, e sim um elemento com clique programado: está sendo contado?
- Duas páginas minhas em sequência: o carimbo junta as duas ou a segunda apaga a primeira?
- Nome com acento, com maiúscula, com espaço e com dois pontos: o que sai no carimbo?
- Carimbo muito longo: está sendo cortado antes de estourar o limite do gateway?
- Pedido com order bump: a receita é contada uma vez ou duas?
- Pedido reembolsado e pedido cancelado: estão fora do faturamento?
- Pedido pago num dia e criado no dia anterior: em qual dia ele aparece? Defina e siga uma regra só.
- Fuso: o gráfico por dia usa horário de Brasília ou o do servidor?
- A mesma pessoa comprando duas vezes: as duas contam?
- Zero eventos no período: as tabelas explicam ou parecem quebradas?

Escreva a lista numerada, do mais grave pro mais bobo, com o que acontece na prática. Não conserte ainda.
Depois conserte um por um e me diga o que mudou.
No fim, rode tudo de novo. Repita até uma passagem não achar nada novo.

Loop 02 · o número que manda agir

Agora olhe o meu painel como se você fosse eu abrindo ele às 8h da manhã, com café na mão e 30 segundos de paciência.

Para cada bloco da tela, responda três coisas:
1. Que decisão esse bloco me faz tomar hoje?
2. Se a resposta for "nenhuma", ele deveria sumir ou virar outra coisa?
3. Falta algum número que eu precisaria pra tomar a decisão e não está aqui?

Depois me proponha, em ordem de impacto:
- Um bloco pra remover, porque é vaidade e não decisão.
- Um bloco pra mudar, porque mostra o dado certo do jeito errado.
- Um bloco novo pra criar, com o dado que está faltando.

Regras do refino:
- Todo número grande na tela precisa de uma linha embaixo dizendo o que ele significa em português.
- Onde tem problema, ofereça o próximo passo escrito na própria tela (por exemplo: "R$ X chegou sem parâmetro, conserte assim").
- Nada de gráfico bonito que não muda decisão.
- Nada de cor nova, nada de emoji.
Aplique um de cada vez e me diga o que mudou.

Loop 03 · o invasor

Esqueça que você construiu isso. Você abriu uma página minha, apertou F12 e achou o meu script de rastreio, com a chave pública dentro dele. Seus objetivos: ver o meu faturamento, sujar os meus dados ou derrubar o meu banco.

Liste tudo que tentaria e o resultado real, considerando o meu SQL e o meu código:
- Usar a chave pública pra LER a tabela de eventos. Deve dar zero. Me prove.
- Usar a chave pública pra ler qualquer outra tabela do meu banco.
- Inserir 100 mil eventos falsos e sujar as minhas métricas. Quanto dano dá pra fazer? Existe limite de tamanho e de frequência?
- Inserir um evento com 5MB de texto num campo.
- Chamar a função de leitura sem a chave de leitura, e com chave errada.
- Chamar a rota do painel sem a senha, e com senha errada.
- Achar as credenciais do gateway no que chega no navegador.
- Injetar HTML ou script dentro do nome de um botão e ver se ele executa quando eu abrir o painel. Esse é o mais provável de todos, já que o conteúdo vem de fora.
- Descobrir o meu faturamento por algum endereço que não exige senha.

Para cada item: o que tentei, o que aconteceu, e se é um buraco.
Se algo passar, me entregue a correção pronta e a explicação em português.
No fim, diga em uma frase o risco real que sobra mesmo com tudo certo.

Quando travar

Nesse projeto o travamento quase nunca é erro na tela: é número que não aparece. A tabela abaixo cobre a maioria.

SOS · destravar sem piorar

Alguma coisa não bate. Antes de mexer em qualquer linha, investigue.

O que eu esperava ver: DESCREVA AQUI
O que apareceu: DESCREVA AQUI
Onde: no carimbo do link, no evento que não chega, no pedido que vem sem origem ou no número do painel?
Console do navegador na página rastreada (F12): COLE O ERRO OU ESCREVA "nada"
Aba de rede: o evento saiu? Qual foi a resposta? COLE OU ESCREVA "nao olhei"

Siga exatamente esta ordem:
1. Diga em qual dos QUATRO pontos da corrente o problema está: o script carimbou? o evento gravou? o gateway devolveu o campo? o painel leu certo?
2. Me diga o teste mais rápido pra isolar esse ponto, e o que eu devo ver em cada caso.
3. Só com o ponto confirmado, faça a correção mínima. Não reescreva o script inteiro, não mude o visual.
4. Diga o que mudou e como eu confirmo.

Se não tiver certeza, diga que não tem certeza e me peça o que falta. Chutar correção é proibido.

o sintoma

o que é, na real

O link não é carimbado

O domínio de destino não está na lista de domínios que o script pode carimbar. Ele só carimba checkout e páginas suas, de propósito.

O evento não chega no banco

Quase sempre o envio por sendBeacon com corpo JSON, que falha calado por causa da verificação de origem. Troque por fetch com keepalive.

new row violates row-level security

Algum campo passou do limite de tamanho da política, ou o tipo do evento não é view nem click. É a trava funcionando.

O carimbo chega picotado no gateway

Caractere que vira código na URL. Use só letra, número e hífen, e ponto como separador. Dois pontos viram %3A.

A venda vem sem origem mesmo com o link carimbado

A pessoa abriu o checkout por outro caminho (digitou, veio de print, salvou o link antigo), ou o gateway não repassa o campo naquele tipo de link. Confira gerando um pedido de teste.

Anúncio aparece como sem parâmetro

Falta ligar o parâmetro de rastreio na plataforma de anúncio. É configuração lá, não código aqui, e é dinheiro que você recupera em dez minutos.

O painel demora e às vezes falha

Está pedindo todas as páginas de pedidos a cada abertura. Cache de alguns minutos resolve.

O total do painel não bate com o do gateway

Quase sempre order bump contado duas vezes, ou reembolso e cancelado entrando na conta. Defina a regra uma vez e use a mesma em toda tela.

A venda de ontem à noite aparece hoje

Fuso. Fixe o horário de Brasília na hora de agrupar por dia, sem depender do relógio do servidor.

Um canal aparece em quatro linhas parecidas

Bagunça de nome. É o passo 06 sendo cobrado. Padronize e conserte os links antigos.

As oito regras que fazem esse caminho funcionar

Nenhuma é sobre código. São sobre como você comanda. Aqui elas valem dinheiro direto: rastreio errado faz você desligar o anúncio que estava pagando a conta.

Opus, sempre

No mínimo Opus 4.8, de preferência Opus 5. O script roda no navegador dos outros e falha calado. Não é lugar de modelo leve.

Uma conversa só

Do prompt 01 ao 07 no mesmo chat, senão a IA reinventa o formato do carimbo no meio e os dois lados param de se encontrar.

Nunca invente origem

Se não dá pra saber, é sem origem. Painel que chuta é pior que painel nenhum, porque você decide errado achando que sabe.

Isole o gateway num arquivo

É o único pedaço que muda quando você troca de plataforma ou soma uma segunda. Nenhum outro arquivo pode conhecer o formato dele.

Padronize o nome antes de escalar

Minúsculo, sem acento, com hífen, e o botão nomeado pelo lugar e não pelo texto. Copy muda, lugar não.

Métrica nunca atrapalha a venda

Se o rastreio falhar, ele falha em silêncio. Nenhum erro de medição pode travar um botão de compra.

A chave pública não pode ler nada

Ela vive exposta dentro do script. Grava e só. Toda leitura passa por uma função com senha que mora no servidor.

Proibido TODO

Repita em todo prompt: nada de função vazia, nada de "aqui você implementa". Sem isso, você recebe meia entrega bonita.

o que fazer com o número

Descobrir de onde vem a venda só vale se você mexer em alguma coisa.

Na primeira semana o painel vai te dar um susto. Vai mostrar que metade do seu faturamento é cego, que o botão em que você mais confia não vende, e que existe um anúncio pequeno pagando a conta sozinho. A lista abaixo é a ordem em que eu mexeria.

Ligue o parâmetro no gerenciador de anúncio. É o conserto mais rápido e o que mais recupera venda cega
Cole o script em todas as páginas, não só na principal. Página sem script é buraco no relatório
Nomeie os botões antes de sair testando copy, senão o histórico não serve pra comparar nada
Olhe o dinheiro parado em pix. Ali costuma ter mais receita esquecida do que em qualquer otimização de anúncio

Copia o primeiro e vai.

Sete prompts. Uma conversa. No fim do dia você abre um painel e, pela primeira vez, sabe qual botão da sua página pagou o almoço.

Começar pelo prompt 01