Push não avisa. Push vende.

As seis secções seguintes são o detalhe. Esta é a versão curta: a proposta, o que já está a funcionar, o que ainda é simulação, e a decisão que peço.

A objeção certa é: como sabemos qual botão é o tamanho do calçado, qual é o frete, qual é a aba de avaliações? Resposta curta, em três camadas — o detalhe está na secção 02 · Técnico:

Nenhuma peça de infraestrutura nova está em falta e nada aqui está bloqueado por decisão de arquitetura. O que falta é escolher a primeira loja real e ligar-lhe a flag, com autorização por escrito. É a única data que precisa de ser marcada.

Hoje, para o Pushnews funcionar, o lojista precisa criar segmentos, journeys, campanhas, triggers, regras de pop-up, textos, timings, testes A/B, audiências e calendários. Cada um deles é uma decisão que pedimos a ele, e cada uma é uma chance de ele desistir.

A maioria das lojas não tem alguém com tempo para isso. O resultado previsível é o que já vemos: uma configuração inicial, um pop-up de boas-vindas com 10% de desconto, e depois silêncio durante meses.

Não estamos propondo «adicionar IA ao Pushnews». Estamos propondo que tudo o que hoje pedimos ao lojista para configurar passe a ser um resultado calculado pelo motor. O lojista deixa de ser o programador das regras e passa a ser o gestor dos limites da IA.

Vale olhar para o que temos hoje sem embelezar, porque é isso que define o que dá para fazer já. A base paga tem 123 contas ativas, com MRR de cerca de R$ 348 mil. Dessas, pela leitura da lista, 64 vendem alguma coisa online — o resto publica conteúdo ou presta serviço, e para esses a tese deste documento simplesmente não se aplica.

Números lidos da lista de clientes de agosto de 2026. Uma observação que vale reportar: circula internamente que «~90% do MRR vem de e-commerce», mas pela classificação nome a nome dos 123 ativos, quem vende online responde por 53% do MRR (R$ 184 mil) e quem publica por 35% (R$ 120 mil). A diferença muda o tamanho do alvo imediato, então vale a pena a equipe confirmar caso a caso antes de o plano assumir um número.

E aqui está o ativo de verdade

Aqui é preciso separar duas coisas que costumam ser somadas numa só, e não são a mesma. Cerca de 1.080 contas chegaram a pagar — as 123 ativas e as 959 que saíram —, e essas tiveram a tag instalada de verdade. As outras quase 18 mil nunca pagaram: em boa parte são leads que criaram conta e nunca chegaram a colocar o script no site. Delas temos o e-mail, não a distribuição.

São dois ativos diferentes, e ambos valem. Distribuição instalada: as lojas que hoje pagam, mais uma fração das 959 que saíram sem remover o script — é onde a coleta liga por configuração, sem ninguém tocar em nada. Lista qualificada: quase 18 mil contatos de gente que um dia procurou uma ferramenta de conversão para o próprio site. Não é distribuição, é canal de aquisição — e nenhum concorrente o compra pronto.

E o detalhe que torna isso acionável agora: a configuração que a tag carrega é gerada por nós, do lado do servidor. Não precisamos que o lojista publique nada, chame a agência dele ou abra um chamado. Precisamos de mudar o que nós emitimos.

Ainda assim, 10% de 959 são cerca de 95 lojas onde ligar a coleta é imediato — sem reinstalação, sem tocar no site, sem chamar ninguém. E há um caso concreto que vale mais do que a média: um dos maiores e-commerces de eletrónicos do país cancelou há anos, deixou mais de R$ 400 mil de receita histórica, e continua pedindo o nosso sites/<appId>.js todos os dias. Basta uma conversa e uma linha de configuração.

Limites desta medição, para ninguém a usar como se fosse censo: só a página inicial, só desktop, seis segundos de espera, e três sites bloquearam o robô com 403 — entre eles duas das maiores contas ativas, que ficaram de fora da conta. O número certo sai do log de acessos do CDN por appId, que cobre a base toda e é a próxima medição a fazer. Esta amostra serve para saber a ordem de grandeza, e a ordem de grandeza já mudou uma frase do plano.

A sequência dos três primeiros meses, em uma linha cada

O resto deste documento descreve o produto completo. Mas a decisão que interessa hoje é só a primeira linha dessa lista — e ela não depende de aprovar mais nada.

Pense no que aquele script vê num dia normal: cada produto aberto, cada busca, cada vez que alguém volta ao mesmo tênis pela terceira vez. Hoje ele descarta tudo isso e guarda só o suficiente para disparar uma notificação. É como ter uma câmera na loja e só usar para saber a que horas fecha. Deveria estar registando a sessão inteira — sem o lojista configurar nada, e sem integração profunda no primeiro dia.

Grande parte disso pode ser descoberto automaticamente a partir de JSON-LD, do dataLayer, do DOM, dos URLs e dos metadados que as lojas já publicam para o Google.

Cada browser ganha um perfil progressivo desde a primeira interação. É anônimo, é do lojista, e é infinitamente mais útil do que os atributos demográficos que hoje conseguimos oferecer.

O lojista nunca define nenhum desses valores. São calculados a partir do comportamento e recalculados a cada evento relevante.

É a pergunta que decide se temos um produto ou um brinquedo. Um perfil que se apaga a cada visita não prevê nada: as afinidades levam sessões a se formar, e a hesitação que interessa acontece exatamente entre visitas. Vale a pena dizer com todas as letras como reconhecemos alguém — e onde não reconhecemos.

São quatro degraus, do mais frágil ao mais forte, e cada um resolve um caso diferente.

Por que o quarto degrau é de outra natureza

O celular e o desktop da mesma pessoa não têm absolutamente nada em comum que sirva de prova. Mesmo IP, mesmo horário, mesma cidade — tudo isso também é verdade para os vizinhos dela. É por isso que ligar dois aparelhos exige um ato dela, e por isso a pergunta que importa deixa de ser técnica e passa a ser de produto: quais são as ocasiões em que uma pessoa se identifica, e quantas delas nós conseguimos provocar?

São quatro, e elas não valem a mesma coisa:

A última linha merece ser desdobrada, porque é o mecanismo mais subestimado do produto. Quando enviamos um push, um e-mail ou um WhatsApp, o link vai com um token assinado que diz «esta é a pessoa 5512». Ela abre no celular — um aparelho que até então era um anônimo chamado 7C31 — e, no instante em que a página carrega, o token identifica aquele navegador. Sem formulário, sem login, sem fricção nenhuma. Identidade transferida por navegação.

Isso inverte a forma de pensar os canais de saída. Mandar uma mensagem não serve só para trazer a pessoa de volta: serve para descobrir onde ela está. Quem abre o e-mail no celular, o push no desktop e o WhatsApp no tablet acaba com três aparelhos ligados a uma identidade, e nós nunca pedimos um dado sequer. Há até casos em que vale gastar um contato barato só por isso — o retorno não é a conversão daquela mensagem, é o aparelho que ela liga para sempre.

Duas decisões que tomamos de propósito e que convém a equipe conhecer. Nada de fingerprinting nem de casamento probabilístico — juntar pessoas por IP, resolução e user agent funciona razoavelmente bem e é exatamente o que nos derrubaria numa auditoria da LGPD. E a fusão de perfis é conservadora: um computador de família ou um balcão de loja são dois usuários no mesmo dispositivo, por isso só fundimos com sinal forte e guardamos a origem da fusão, para poder desfazê-la.

Honestidade sobre o alcance: com cookie primário emitido pelo servidor, reconhecemos a maioria de quem volta em 30 dias no Chrome e no Android. No Safari sem esse cuidado, bem menos. E entre dispositivos, sem identificação, não reconhecemos — e não vamos fingir que sim. É justamente por isso que a peça seguinte existe.

Para cada visitante, o motor responde continuamente a uma pergunta. Não «que campanha está ativa», mas o que devo fazer a esta pessoa neste momento. E muitas vezes a resposta certa é não fazer nada: pop-ups para todo mundo destroem a experiência e treinam o cliente a esperar pelo desconto.

O exemplo concreto

O João está olhando pela terceira vez para um tênis de R$ 899. O motor avalia as opções que tem e estima o lucro incremental de cada uma:

Valores ilustrativos. O que interessa é a forma da tabela: o desconto é a ação com maior impacto na conversão e a única com lucro negativo, porque a maior parte dessas pessoas comprava sem ele. E repare nas duas linhas de combinação — é a pergunta seguinte.

«E por que não um pop-up com as três de uma vez?»

É a primeira pergunta que qualquer pessoa faz ao ver essa tabela, e ela está meio certa. Meio, porque parte de um pressuposto que não se sustenta: o ganho das ações não soma. As três atacam a mesma hesitação, portanto são substitutas, não complementares — juntas rendem +13,1%, não os +27,3% da soma ingênua.

E há um detalhe pior. Uma das três destrói margem: a alternativa de R$ 599 tem o maior ganho de conversão isolado (+11,0%) e o menor lucro (+R$ 26), porque canibaliza a venda de R$ 899. Colocá-la ao lado das outras duas é oferecer a saída barata justamente a quem já ia comprar o caro — por isso o pop-up com as três converte mais (+13,1%) e ganha menos (+R$ 31) do que o bloco com duas.

Dito isso, a pergunta melhora a proposta, e é assim que ela deve entrar na arquitetura: o espaço de decisão do motor não pode ser a lista de ações isoladas, tem que ser o conjunto de combinações — com o lucro esperado estimado para cada combinação, nunca somado a partir das partes.

Aí a regra deixa de ser «uma ação» ou «três ações» e passa a depender de como elas se relacionam. Entrega e prova social são complementares: reduzem tipos diferentes de risco percebido e cabem no mesmo bloco sem competir. A alternativa mais barata é substituta e canibaliza: só entra se as outras duas falharem, ou se o perfil disser que a barreira é mesmo preço — que aqui não é, com price_sensitivity em 0,31.

Duas consequências práticas. A primeira é de custo: avaliar combinações faz o número de candidatos explodir, por isso o motor limita-se a blocos pequenos (dois, no máximo três elementos) e aprende quais compõem bem naquela loja. A segunda é de método: «uma intervenção vs. um bloco com duas» é exatamente o tipo de hipótese que o motor deve testar sozinho, loja a loja — e a resposta provavelmente não é a mesma para todas.

Hoje a regra típica é «exit intent → 10%». Passa a ser «exit intent → é preciso incentivo?». Um cliente habitual que comprava na mesma recebe zero. Um visitante novo e sensível ao preço talvez receba frete grátis. Outro recebe 5%. Outro recebe apenas prova social. Isso elimina o problema clássico de ensinar o consumidor a esperar pelo pop-up.

Escolhemos formato, headline, texto, imagem, produtos, CTA, incentivo, momento e posição — não apenas um template de uma lista. O SDK já sabe injetar boa parte desses componentes; o que falta é o motor escolher qual usar.

Isso fica abstrato depressa, então vale ver o que o João realmente enxerga na terceira visita ao Pegasus. A decisão da peça anterior foi prazo de entrega + prova social, no mesmo bloco — é exatamente isto:

Repare no que não está aí: nenhum cupom, nenhum contador regressivo, nenhuma sobreposição que tape a página. O bloco responde às duas dúvidas que o comportamento dele revelou e sai da frente.

A mesma posição, quatro pessoas, quatro conteúdos

O que muda de visitante para visitante não é o template — é tudo o que está dentro dele, decidido no momento a partir do perfil.

O catálogo de componentes que o motor pode injetar é o mesmo que já discutimos: carrossel de recomendações, mensagem flutuante, barra fixa, prova social, comparação de produtos, assistente de tamanho, cupom, contador, indicador de frete grátis, vistos recentemente, comprados juntos, alternativas, aviso de reposição de estoque, alerta de queda de preço, pesquisa, quiz e assistente conversacional.

E uma regra de desenho que vale a pena fixar agora, antes de existir código: a experiência tem que caber na página, não tapar a página. O formato padrão é um bloco ancorado que a pessoa pode ignorar; a sobreposição modal fica reservada para o caso raro em que ela já está saindo de qualquer maneira. Uma plataforma que aumenta a conversão de hoje destruindo a experiência da loja não sobrevive ao terceiro mês.

Aqui está o motivo pelo qual push, e-mail e WhatsApp não são um acessório do Pushnews — são o que torna o motor economicamente viável. Um cérebro sem braços fora do site só consegue agir sobre a fração de gente que ainda está com a aba aberta. O valor de verdade está na outra ponta: a decisão de comprar não acaba quando a sessão acaba. Quem viu o mesmo produto três vezes vai decidir nas próximas 48 horas — e, sem canal de saída, decide sem nós.

Cada canal é uma combinação diferente de custo, velocidade e permissão. Não existe o melhor canal; existe o canal certo para aquela pessoa, naquele momento, àquele custo.

Custos de ordem de grandeza para o Brasil, para efeito de decisão. O que importa não é o número exato: é que eles diferem em uma ordem de grandeza entre si, e por isso o canal entra na mesma conta de lucro esperado que a ação. Um WhatsApp a R$ 0,45 só se justifica quando a probabilidade de compra vezes a margem paga esse custo — e num carrinho de R$ 80 com margem de 30%, muitas vezes não paga.

A escada de intervenção

É a mesma ideia do incentivo mínimo, aplicada ao contato: sobe-se um degrau de cada vez, e só quando o anterior não resolveu.

Duas consequências que valem para o produto. A primeira é que «canais alcançáveis» passa a ser um atributo do perfil: o motor precisa saber, para cada pessoa, quais portas estão abertas — aceitou push, deu e-mail, autorizou WhatsApp — porque a melhor ação do mundo é inútil se não houver como entregá-la. A segunda é que o limite de frequência é da pessoa, não do canal: três mensagens em três canais diferentes continuam sendo três interrupções, e é assim que uma plataforma perde a permissão que levou meses para conquistar.

O botão que resolve identidade e canal no mesmo clique

Repare no problema que sobrou das duas peças anteriores: para alcançar alguém depois que ela sai, precisamos de uma porta aberta; e para abrir a porta, historicamente, pedimos um dado — e-mail, telefone, uma conta. Cada pedido desses é um formulário, e cada formulário perde gente.

O «fale com a gente no WhatsApp» resolve isso de um jeito que nenhum formulário resolve. Quando a pessoa toca no botão e manda a mensagem, ela nos entrega o número, o consentimento e o contexto de uma vez — e do lado dela não pareceu um cadastro, pareceu tirar uma dúvida. Junte com o mecanismo do token: aquela conversa fica amarrada ao visitor_id daquele navegador, e o quarto degrau da identidade acontece sem que ninguém preencha nada.

Mas isso só funciona se o botão não for o balãozinho genérico de «Atendimento» parado no canto da tela, que todo mundo aprendeu a ignorar. O convite tem que nascer da hesitação que o motor acabou de detectar — mesmo lugar do bloco onsite, mesma lógica de decisão, texto gerado para aquele momento:

o link já vai preenchido → wa.me/55…?text=Oi! Tenho uma dúvida sobre o Pegasus 41, tam. 42 [#7C31] — o código curto amarra a conversa à sessão, ao produto e ao motivo

O texto pré-preenchido carrega o produto e o motivo, então quem atende — pessoa ou assistente — já começa sabendo do que se trata. E o mesmo assistente conversacional que está no catálogo de componentes pode atender essas conversas com o perfil, o estoque, os prazos e as políticas na mão.

Uma ressalva que não pode ser esquecida: espalhar não é encher. O convite aparece onde há hesitação real — página de produto, frete, carrinho, pós-compra —, nunca em todas as páginas ao mesmo tempo, e entra na mesma conta de frequência de todo o resto.

E quem responde? O bot atende, a loja resolve

A objeção óbvia é de capacidade: abrir mil conversas por dia numa loja que responde em seis horas destrói mais reputação do que qualquer pop-up. Mas repare no tipo de pergunta que esses convites provocam — e é aí que a objeção se desfaz.

Ou seja: o bot cobre a maior parte — porque a maior parte é dúvida objetiva sobre prazo, tamanho, estoque e frete — e o humano entra quando o caso deixa de ser informação e passa a ser decisão. E note quem é esse humano: é sempre alguém da loja. Nós não atendemos o cliente final por ela, nem entramos no meio da relação: o Pushnews conduz a conversa até onde ela é automatizável e entrega o resto no atendimento que a loja já tem.

Isso também muda o que o motor precisa saber. A capacidade de atendimento vira um número do onboarding — quantas conversas humanas por dia a loja aguenta, em que horário —, e é ela que limita quantos convites o motor solta. Fora do horário, o bot avisa que a resposta humana vem de manhã, em vez de deixar a pessoa falando sozinha.

De quem é o número de WhatsApp?

Essa pergunta aparece na primeira reunião com qualquer loja de porte, e a resposta muda a arquitetura — a ponto de merecer aba própria. Os cenários de número, o que a Meta descontinuou, o mecanismo do botão e a galeria de convites por contexto estão em 07 · WhatsApp.

Ninguém entrega o controle do seu site a uma IA no primeiro dia — nem nós devemos pedir isso. A adoção tem uma escada, e cada degrau precisa ser merecido com resultados demonstrados.

Isso é uma proposta muito melhor do que um botão «Criar campanha» — mostra que já percebemos a loja antes de pedir qualquer coisa ao lojista.

E repare no bloco do meio, que é a parte que costuma faltar: o lojista vê a experiência exata que vai aparecer no site dele, onde ela aparece e com que gatilho, antes de clicar em Ativar. Sem isso, «Ativar» é um salto de fé — e ninguém entrega a própria página de produto a um botão em que precisa confiar às cegas. Como o criativo é gerado, a pré-visualização mostra o texto real que será servido, não um exemplo genérico; e o mesmo painel deixa reescrever qualquer linha antes de publicar, porque a primeira vez que uma marca vê uma IA escrevendo em seu nome, ela quer poder mexer.

Tudo o resto é inferido. Se conseguimos ler a categoria, não perguntamos a categoria. Se conseguimos escrever o texto, não pedimos o texto.

E o calendário comercial, que não nasce dos dados

Black Friday, volta às aulas, escoar uma coleção, uma ação paga por uma marca — nada disso está no comportamento de quem visita o site. Está num contrato com um fornecedor, num armazém cheio, num calendário fechado em junho. Um motor que só lê o visitante nunca descobre que existe um acordo com a Nike, e um produto que ignore isso é um produto que o lojista não pode usar em novembro.

A resposta não é devolver-lhe o construtor de campanhas. É uma ordem com prazo: uma janela em que o objetivo e os tetos mudam. O lojista declara-a numa frase — «de 24 a 30 de novembro quero escoar o estoque de inverno, pode ir até 30%» — e o motor devolve-a estruturada (janela, objetivo em unidades e não em receita, escopo de SKUs, teto de desconto, investimento) com o preço em margem que ela deve custar. Dentro da janela persegue o objetivo da ordem; fora dela volta ao do período. E o inverso também vale: vendo estoque parado, é o motor que propõe a ordem.

Junto com as cinco decisões, isto fecha o modelo de controle: limites permanentes, ordens com prazo e inegociáveis — a linha premium que nunca entra em desconto, a marca que tem de aparecer porque paga por isso. O lojista decide o quê, quando e até onde; o motor decide o como.

E até o tom da marca pode ser lido

Ao ligar o site, fazemos uma leitura da homepage, das páginas de produto e categoria, das FAQs, das políticas de entrega e devolução e das avaliações. Daí sai a voz da marca, o vocabulário, as propostas de valor, as objeções típicas, o posicionamento de preço e a política promocional. O lojista não preenche um formulário descrevendo a própria marca.

A porcentagem de visitantes não tocados é uma métrica de qualidade, não de falha — e os 71% não são aspiração: é o que o motor decidiu nas 1.000 sessões gravadas em produção. Uma plataforma que interrompe 100% das sessões está destruindo a experiência da loja.

E uma seção que hoje não existe em lugar nenhum

O que a IA aprendeu esta semana

Depois de meses, duas lojas nunca funcionam da mesma maneira: numa os descontos são decisivos, noutra são as avaliações, noutra são o frete. Esse conhecimento é proprietário daquela loja e não se transfere para um concorrente — é a forma mais saudável de lock-in que podemos construir.

Um potencial cliente instala a tag. Durante algumas semanas observamos as mesmas 18.432 sessões da Peça 7 e não mostramos absolutamente nada. Depois entregamos um número.

Deixa de ser uma demonstração do nosso produto e passa a ser um diagnóstico da loja dele. Nenhum concorrente que exija configuração consegue oferecer isso antes da venda.

Há dois tipos de aprendizado saindo do motor, e confundi-los seria o erro mais caro do produto inteiro.

O primeiro é específico daquela loja e é propriedade dela: que naquele catálogo o frete grátis converte melhor que 10%, que os clientes recorrentes daquela marca não reagem a desconto, que o pico é na segunda-feira à noite. Isso nasce dos dados dela, vive na conta dela, e não atravessa a parede em circunstância nenhuma.

O segundo é estrutural e não pertence a ninguém em particular: que a terceira visualização do mesmo produto é o melhor momento para intervir; que reforço de prazo de entrega funciona melhor em celular do que em desktop; que prova social vence desconto em tráfego social. Esses padrões só aparecem quando se olha para muitas lojas ao mesmo tempo, não identificam nenhuma, e é deles que se faz um produto que melhora sozinho para todo mundo.

Como isso se sustenta tecnicamente

Três condições, e nenhuma é opcional. Limiar mínimo: um padrão só sobe se aparecer em pelo menos algumas dezenas de lojas independentes — abaixo disso não é estrutura, é a loja de alguém disfarçada de estatística. Forma, nunca conteúdo: sobe «reforço de prazo supera desconto em celular na categoria calçados», nunca o texto que a loja usou, o produto, o preço ou o número dela. Reprodutibilidade: se um padrão não se confirma em lojas que não participaram de sua descoberta, ele não entra — é ruído.

E comunicar isso ao cliente?

Aqui a resposta importa mais do que parece, porque a mesma verdade dita de duas formas produz reações opostas. «Usamos os dados da sua loja para melhorar o produto» soa a extração, mesmo sendo legítimo. «Sua loja começa já sabendo o que aprendemos em milhares de outras» é a mesma coisa dita pelo lado do benefício — e é o lado verdadeiro, porque o fluxo que interessa ao lojista é o de descida, não o de subida.

Minha recomendação é comunicar o benefício com destaque e o mecanismo com precisão: a rede aparece na venda como vantagem («não começa do zero») e nos termos como cláusula clara sobre agregação e anonimização. Não escondemos, e também não transformamos em campanha — porque o detalhe do que se agrega e como se anonimiza é, esse sim, propriedade nossa e vantagem competitiva.

Duas travas que valem a pena assumir agora. Opt-out existe, mesmo que quase ninguém use: uma loja pode ficar fora da camada estrutural, e nesse caso ela para de receber os padrões também — quem contribui recebe mais, e isso é justo e fácil de explicar. E portabilidade total: os dados e o perfil dos visitantes são do lojista e saem com ele quando quiser, porque a LGPD exige e porque a barreira de saída certa não é reter dado de ninguém. É a próxima seção.

Se o motor decide o que fazer com cada pessoa, então também decide onde: agora no site, ou por push daqui a trinta minutos, ou por e-mail daqui a quatro horas, ou por WhatsApp amanhã, ou nunca. Deixam de existir cinco campanhas independentes por canal; existe um percurso decidido pelo motor.

Um exemplo. Alguém vê quatro camisas, coloca uma no carrinho e sai. O motor não envia nada — estima alta probabilidade de retorno espontâneo. Quatro horas depois ainda não voltou: «a camisa azul que você viu continua disponível no seu tamanho». No dia seguinte: «encontramos outra que combina melhor com a calça que você viu». Só depois, e só se necessário: «hoje você tem frete grátis». A intervenção escala gradualmente, e o desconto é o último recurso, não o primeiro.

Isso abre uma categoria maior do que aquela em que estamos hoje: uma plataforma de conversão que, por acaso, tem push, WhatsApp, e-mail, SMS e onsite como braços de execução. E a entrada para essa categoria já foi paga: está no rodapé de cada uma dessas lojas, carregando um arquivo nosso todo dia.

A pergunta certa para começar não é «como construímos o motor», é «o que exatamente precisa mudar naquilo que já está rodando em milhares de sites». A resposta é curta, e é boa: quase nada do que precisamos mudar é código que o cliente instalou.

Antes de tudo, uma correção de vocabulário

Vinha chamando «tag v2» ao que muda, e o nome atrapalha mais do que ajuda — porque sugere que existe um script novo para o lojista instalar. Não existe. Vale a pena separar as três coisas que costumam ser chamadas de «a tag», porque só uma delas muda:

→ ver todo o código — coletor, endpoint, esquema, diff e simulador, sem precisar de acesso ao repositório

Ou seja, a expressão correta não é «atualizar a tag do cliente» — é «publicar um pacote novo para aquele appId». E publicar é literalmente o que o SiteConfigService já faz hoje: um putObject no bucket, na chave sites/<appId>.js. Reverter é publicar a versão anterior na mesma chave.

O documento passa a usar pacote v1 e pacote v2 em vez de «tag v1/v2», para que ninguém saia daqui achando que há trabalho do lado do cliente onde não há.

Concretamente, o que passa a ser emitido

Ao lado da configuração de campanhas que já geramos, o arquivo passa a carregar um coletor de sinais — um módulo pequeno, sem dependências, idempotente, que faz três coisas e mais nenhuma:

Só isso já produz o esquema rico da seção seguinte para lojas reais, com tráfego real, sem esperar por nada. As duas peças que exigem trabalho de verdade — o armazém de eventos e o coletor no edge — são infraestrutura nossa, construída em paralelo, sem bloquear a coleta.

O que não dá para resolver só com configuração

Três coisas, e é honesto listá-las agora para ninguém se surpreender depois. O cookie de primeira parte precisa do endpoint no domínio da loja — sem isso a memória é curta no Safari, e o caminho para tornar isso fácil está algumas seções abaixo. Sinais que só o site sabe — carrinho, login, estoque em tempo real — ficam melhores com uma camada de sinais instalada pelo cliente, mas há uma versão inferida que funciona sem ela. E texto verdadeiramente personalizado depende de createPushOnSite, que compõe o conteúdo do nosso lado — o SDK não substitui variáveis no título e no corpo dos pop-ups, então o caminho é compor o texto inteiro antes de mandar.

Metade do caminho já está andada, e vale listar o que existe antes de listar o que falta — porque é a diferença entre um projeto de trimestre e uma semana de trabalho.

Três itens em falta, todos pequenos, nenhum bloqueado por decisão de arquitetura. A sequência abaixo é o que dá para fazer nos primeiros cinco dias úteis.

As três decisões que travam o dia 1, se ninguém as tomar

Vale a pena separar o que nos limita do que nos dá vantagem, porque a proposta se apoia inteiramente na segunda coluna.

O erro mais caro que podemos cometer é tratar tudo como «dados». Essas três camadas têm requisitos opostos e devem viver em lugares diferentes.

O ponto que torna isso à prova de futuro: daqui a seis meses vamos descobrir que tempo_entre_visualizacoes ou abriu_info_de_entrega são muito preditivos. Se o esquema não aceitar campos novos sem migração, perdemos esses sinais para sempre — e não há como recuperá-los retroativamente.

Envelope validado na escrita, propriedades interpretadas na leitura. O envelope é contrato: se falhar na validação, é rejeitado. As propriedades entram sem cerimônia e ganham significado quando alguém descobrir que são úteis. Isso permite à tag começar a coletar um sinal novo hoje e nós decidirmos daqui a três meses se ele entra no modelo.

Tipos de evento da primeira versão

A última coluna é a mais importante e a mais fácil de esquecer: sem registrar o que nós mesmos mostramos, e a quem, não conseguimos medir uplift nem treinar nada. Os eventos das nossas intervenções são tanto dados de treino quanto os do visitante.

De onde vem cada sinal numa loja que não é a nossa

A pergunta óbvia ao ler a coluna «sinais finos»: como sabemos qual botão é o tamanho do calçado, qual é o cálculo de frete, qual é a aba de avaliações? Na demonstração está tudo colado ao site de teste, e o pn-personalization.js de hoje resolve isso com adaptadores escritos loja a loja. Não é isso que se propõe repetir. São três camadas, e só a última precisa de trabalho por loja — que também é automatizável.

A parte de produto está na Peça 3. Aqui fica o que a equipe precisa construir, porque a diferença entre reconhecer alguém por sete dias e por um ano está em três detalhes de implementação.

1 · O cookie tem que vir do servidor

Um cookie escrito por JavaScript no Safari é apagado em 7 dias pelo ITP — 24 horas se o visitante chegou por um link com parâmetros de rastreio conhecidos. Não é contornável por engenhosidade: é política do navegador. O que é aceito é um cookie de primeira parte emitido pelo servidor, num Set-Cookie HTTP vindo de um endpoint no próprio domínio da loja.

Ou seja, o coletor do pacote v2 não pode falar só com api.pushnews…: o coletor precisa responder de dentro do domínio do cliente. O caminho clássico para isso é um CNAME — e aqui está a parte que decide a adoção do produto inteiro, porque pedir um registro de DNS a um lojista é onde o onboarding morre. Metade não sabe onde fica o DNS; a outra metade sabe e vai «ver isso com a agência» — que é como se diz «nunca» em português.

2 · Como não pedir DNS a quase ninguém

A saída é não tratar isso como um passo único e obrigatório, mas como uma escada de quatro caminhos que o próprio onboarding percorre sozinho, do mais invisível ao mais manual. Detectamos a plataforma e o provedor de DNS da loja no primeiro minuto e oferecemos só o caminho mais fácil que aquela loja permite.

3 · A tabela de apelidos, e por que os perfis nunca se editam na mão

Quando um visitor_id anônimo passa a estar ligado a uma pessoa, o histórico anterior tem que ser reatribuído. Isso não se faz reescrevendo eventos — eles são imutáveis. Faz-se com uma tabela de aliases que mapeia identificadores para uma identidade canônica, e recalculando o perfil por cima dela.

Como o perfil é derivado e não editado, desfazer uma fusão errada é remover a linha e recalcular — não é uma cirurgia de dados. É exatamente por isso que a Peça sobre as três camadas insiste que a inferência seja descartável e reproduzível.

4 · As regras de fusão, que são de produto e não de engenharia

Nenhuma dessas fases exige desligar o que existe. O sistema atual continua funcionando durante todo o percurso, e cada fase tem uma forma explícita de se provar antes de avançarmos para a seguinte.

O que não conseguimos fazer, e devemos dizê-lo já

Não há backfill possível. O histórico em ecommerce_events não tem produto, preço nem contexto, e nada os recupera. Serve para volumetria e sazonalidade; não serve para inteligência. O aprendizado de cada loja começa no dia em que o pacote v2 é publicado — o que é mais um argumento para colocar a F0 no ar cedo, mesmo antes de sabermos se vamos construir todo o resto.

Se mandarmos cada evento a um modelo de linguagem, a fatura é impossível e o resultado é pior. Um LLM é extraordinário a interpretar, raciocinar, gerar conteúdo e explicar decisões — e é um mau e caro classificador de probabilidade de compra. Cada camada só passa à seguinte o que a anterior não consegue resolver.

Coleta intensiva de comportamento no Brasil significa LGPD, e conformidade precisa ser desenhada junto com o sistema, não acrescentada depois. E vira argumento de venda: é exatamente aqui que as plataformas americanas são frágeis.

O prazo curto só é possível por causa do que já existe: a tag instalada, o SDK que renderiza onsite, o canal push com base de inscritos, a relação comercial com as lojas e a configuração que geramos do lado do servidor. Não estamos começando um produto do zero — estamos ligando um cérebro a um corpo que já está no lugar.

O calendário abaixo é contado a partir de agosto de 2026 e assume uma equipe pequena e dedicada. Cada marco tem uma verificação observável, não uma opinião sobre estar pronto.

Começa esta semana e não depende de nenhuma decisão de arquitetura. Conversa curta com as contas ativas que vendem, autorização por escrito, e a coleta é ligada pela configuração que já emitimos.

Risco desta fase: uma loja recusar por desconfiança. Mitigação: o pedido é de leitura, não de mudança — e o argumento é honesto, porque ela recebe o diagnóstico de graça no fim.

As três peças que transformam eventos em decisão, construídas em paralelo com a coleta já rodando — de modo que, quando o motor ficar pronto, ele tenha semanas de histórico real de lojas reais para aprender, em vez de começar vazio.

Só aqui o produto começa a cobrar, e por uma razão de sequência: a auditoria só convence com dados daquela loja, e esses dados levam semanas para existir. Cobrar antes seria vender promessa; cobrar depois de mostrar o diagnóstico é vender resultado.

A partir de fevereiro o trabalho deixa de ser construir e passa a ser escalar — com três frentes rodando em paralelo e uma quarta que só abre quando as três primeiras estiverem estáveis.

Os números trimestrais dessa escala — quantas lojas, qual receita, com que margem — estão na aba do plano.

Estes números são estimativas de ordem de grandeza, com premissas explícitas, feitas para decidir arquitetura — não são uma proposta de preços nem um orçamento. O componente com maior incerteza é o compute analítico, que pode variar entre metade e o triplo do valor indicado conforme a qualidade das queries.

Valores em reais por mês e por loja, convertidos à taxa de 11 de agosto de 2026 (1 USD = R$ 5,12; 1 EUR = R$ 5,91) e arredondados. A taxa cambial é uma variável real do modelo: o custo é quase todo em dólares e a receita é em reais, por isso uma desvalorização de 20% do real comprime a margem bruta sem que nada mude no produto.

Comunicações pagas — SMS e WhatsApp — estão deliberadamente fora desta tabela. Push, onsite e e-mail têm custo marginal baixo e podem estar incluídos; SMS e WhatsApp têm custo variável por operadora e destroem qualquer múltiplo se forem absorvidos na mensalidade.

Esta é a leitura que mais interessa para decisões de produto: numa loja pequena, o custo é sobretudo compute analítico; numa loja grande, quase três quintos do custo são inteligência. Cada funcionalidade nova de IA pesa desproporcionalmente nos maiores clientes.

Reais por mês e por loja — pequena / média / grande —, agrupando as linhas da tabela acima. A proporção de IA sobe de 31% na loja pequena para 58% na grande.

É a regra fixa do modelo: preço = 4 × COGS, o que dá 75% de margem bruta antes de vendas, suporte e estrutura. Serve como piso, não como preço recomendado: onde o valor gerado é muito superior — tipicamente nas lojas médias e grandes — o preço deve ser mais alto, e para clientes empresariais o alvo razoável é 5× a 8×.

A banda inferior de cada linha é o COGS técnico puro; a superior inclui os 25% de margem operacional. Vender ao preço da banda inferior mantém os 75% sobre o custo puro mas come a folga operacional — por isso o piso a usar comercialmente é o valor de cima.

Vale a pena olhar para a última linha sem embelezar: a regra dos 4× coloca uma loja de 10 milhões de sessões acima de R$ 90 mil por mês. É um preço de contrato empresarial, não de plano de catálogo — o que significa que o segmento grande precisa de venda consultiva com prova de receita incremental, e que a auditoria gratuita deixa de ser um truque de marketing para passar a ser o instrumento de venda principal. Se a conclusão for que o mercado não paga isso, o caminho é reduzir o COGS — quase todo IA, quase todo otimizável pelo funil computacional — e não afrouxar o múltiplo.

A regra dos 4× resolve a nossa margem. Falta a outra metade da conversa, que é a que se tem numa reunião: o lojista não compara o preço com o nosso custo, compara com o que ele ganha. E essa conta é mais simples do que parece.

O que a base que vende paga hoje

Da maior (R$ 22.500/mês) à menor (R$ 110/mês). A mediana em R$ 1.338 diz o essencial: metade da base que vende paga menos de mil e quatrocentos reais por mês — e é para essa metade que o preço novo de R$ 2.300 tem de ser justificado.

A conta que interessa ao lojista

Com margem de 50%, cada real de mensalidade exige dois reais de venda adicional para empatar. É toda a aritmética: vendas adicionais necessárias = preço ÷ margem. O que muda entre os portes não é a conta, é o tamanho do denominador.

GMV estimado com conversão de 1,8% e ticket médio de R$ 250 a R$ 350 conforme o porte — valores conservadores para e-commerce brasileiro. «Paga hoje» é a mediana observada em cada faixa da nossa base. Margem do lojista assumida em 50%: numa loja de moda é mais, numa de eletrónicos é bem menos, e é por isso que a conta deve ser refeita com o número real dele na reunião.

Uma ressalva que nos impede de nos enganarmos a nós próprios: o simulador calcula «lucro incremental» e dá números altos, mas não serve para provar esta conta. Ele demonstra o mecanismo — que o motor escolhe por lucro e não por conversão — com deltas de probabilidade que eu escolhi. O número que vale é o do grupo de controle numa loja real, e é por isso que ele aparece já na primeira fase paga. Até lá, a única coisa que se pode afirmar com segurança é esta: a barra que o produto tem de saltar é da ordem de 1%, e isso é baixo.

Uma sessão que entra, vê a homepage e sai custa praticamente zero. Uma sessão que vê doze produtos, faz três pesquisas, adiciona ao carrinho, retira, volta, recebe uma recomendação, fala com o assistente, abandona, recebe um push, volta e compra consome centenas de vezes mais recursos — e gera muito mais valor.

A unidade interna certa é a decisão de conversão analisada, não a sessão nem o pageview. É essa unidade que devemos instrumentar desde a F0, porque é sobre ela que assentará tanto o modelo de custos como qualquer modelo de preços futuro.

Software de marketing costuma valer o máximo no dia da instalação e virar commodity depois — por isso o churn é uma luta permanente e a renovação se ganha no desconto. Um motor que aprende inverte essa curva: no mês 1 ele sabe pouco e vale pouco; no mês 12 ele conhece a sazonalidade daquela loja, sabe quais categorias reagem a frete, quais clientes não merecem desconto, que criativo funciona em qual público. Trocar de fornecedor deixa de ser trocar de ferramenta e passa a ser apagar a memória.

Quanto isso vale, em números

A conta é simples e vale a pena estar escrita, porque justifica investir em onboarding com a mesma seriedade com que se investe em features. Tomando a loja média a R$ 14.200/mês com 75% de margem bruta — R$ 10.650 de margem por mês:

Cortar o churn pela metade dobra o valor de cada cliente — aritmética elementar, mas o que importa aqui é o mecanismo: não é fidelidade nem contrato de 12 meses, é o custo real de recomeçar. Um concorrente que entre amanhã não herda nada: volta ao modo de aprendizado, e são 60 a 90 dias até valer alguma coisa. Esse intervalo é a barreira.

Lock-in saudável e lock-in hostil não são a mesma coisa

Vale separar isso explicitamente, porque a diferença define que tipo de empresa somos. Reter dado é hostil — e, no Brasil, também é ilegal: a LGPD dá ao titular o direito à portabilidade, e os eventos e perfis são do lojista. Devemos exportá-los inteiros, em formato aberto, no dia em que ele pedir, sem fricção e sem ligação para «entender melhor a sua necessidade».

O que não se exporta é o modelo calibrado, e isso não é uma trava que colocamos: é a natureza da coisa. Os pesos só fazem sentido dentro do motor que os treinou, do mesmo jeito que exportar as notas de um aluno não transfere o que ele aprendeu. O lojista leva a matéria-prima e não leva a experiência — e é justamente por isso que a barreira é honesta.

O que isso exige do produto

Nada disso depende de aprovarmos a visão inteira hoje. Depende de decidirmos as quatro primeiras.

Todo o plano assenta em quatro fatos lidos da base de agosto de 2026, e vale começar por eles porque são menos confortáveis do que a narrativa habitual.

A última linha é a mais importante e a menos discutida: 2017 trouxe 330 contas novas, 2024 trouxe 71, 2025 trouxe 39 e 2026 traz 13 até agora. Um plano que assuma crescimento por aquisição em 2027 está assumindo uma reversão que ainda não aconteceu. Por isso o plano abaixo cresce, no primeiro ano, dentro de casa: convertendo quem já é cliente e reativando quem saiu.

As 64 contas que vendem pagam hoje R$ 184 mil por mês. No preço da regra de 4× COGS, com o mix de portes que essa base sugere, as mesmas 64 contas valeriam cerca de R$ 511 mil por mês — 2,8 vezes mais, sem um cliente novo sequer.

Portes estimados pelo MRR atual como aproximação de volume — dos 64, onze pagam acima de R$ 5 mil/mês e vinte e sete pagam menos de R$ 1 mil. É uma aproximação grosseira que a coleta da F0 vai substituir por número real de sessões nas primeiras semanas, e esse é mais um motivo para ligá-la já.

É um teto, não uma previsão. Nem todas convertem, nem todas convertem rápido, e algumas vão achar caro — a loja que paga R$ 1,4 mil hoje vai receber uma proposta de R$ 2,3 mil. A diferença entre o teto e o plano de verdade é exatamente o que a tabela seguinte modela.

A trajetória segue o roadmap: nada de receita nova até o produto existir, primeiras ativações no primeiro trimestre de 2027, e escala só depois de a auditoria provar que converte. As lojas que migram deixam de pagar o plano antigo — a coluna de legacy já desconta isso.

Barras na mesma escala: o comprimento total é comparável entre linhas. O MRR dobra em quinze meses, e o que muda de verdade é a composição — no fim de 2027, a maior parte da receita vem de um produto que hoje não existe.

Como o preço é fixado em 4× COGS, a margem bruta do produto novo é conhecida por construção. O que a tabela mostra é que ela se mantém enquanto a receita triplica — que é a propriedade que torna esse crescimento saudável em vez de apenas grande.

Os R$ 108 mil de COGS saem da tabela de custos da aba anterior aplicada ao mix de portes. Fora dessa conta: equipe, vendas, suporte e as comunicações pagas — SMS e WhatsApp iniciado por nós — que continuam faturadas à parte, por crédito, para não corroerem o múltiplo.

O que precisa ser verdade para esse plano se cumprir

Vale deixar as premissas expostas, porque cada uma delas é falsificável e é assim que se descobre cedo que o plano precisa mudar:

Tudo o que este documento descreve existe e está de pé: o coletor, o endpoint que grava, o motor que constrói perfis e decide, e a console. As 1.000 sessões abaixo foram gravadas numa base de produção pela mesma função que uma loja real chamaria — nenhum número desta aba foi escrito à mão.

Clique numa sessão para ver os scores e a decisão. Depois, em «ver na loja», a sessão é reproduzida na loja demo: o cursor se move, a página rola, o painel de frete abre, o item cai na sacola — e no fim aparece a experiência que o motor escolheu, ou não aparece nada, se ele decidir não interromper.

O motor não espera pelo fim. Ao longo da sessão ele intervém quando o sinal aparece: na terceira volta ao mesmo modelo, na segunda abertura do frete, na parada em cima do preço. A barra do replay conta essas intervenções à medida que acontecem, e cada uma diz o que a provocou. As de meio de sessão saem de cena sozinhas; só a decisão final fica. E os botões de WhatsApp que surgem na página são os mesmos da aba WhatsApp — durante um replay não disparam nada para fora, mostram a mensagem que sairia.

O acerto é medido contra a persona que gerou cada sessão — que o classificador nunca lê. Ela existe nos dados só como gabarito. É a diferença entre demonstrar e fingir.

Abrir a console em aba própria →  ·  ver um replay direto na loja →  ·  ler o código que gerou isto →

Quando se diz «vamos usar WhatsApp», estão sendo ditas duas coisas que não têm quase nada em comum. Uma é cara, lenta de aprovar e cheia de regras. A outra é imediata, gratuita e ninguém precisa de autorizar nada. Confundi-las é o erro que faz um projeto de WhatsApp demorar três meses para começar.

Não é um botão flutuante de «Fale conosco» parado no canto — esse toda a gente aprendeu a ignorar. É um convite que nasce da hesitação que o motor viu, no sítio onde ela aconteceu, com o texto escrito para aquele momento.

Cada cartão mostra as três peças: o botão como aparece na página, a mensagem que ela envia (que é o que o ?text= pré-preenche — a caixa dela, não a nossa) e a nossa resposta, já dentro da janela de 24 horas, onde cabe tudo o que quisermos dizer.

É a mesma disciplina que o motor aplica às ofertas, aplicada ao atendimento — com um piso mais baixo, e por uma razão que se defende: oferecer conversa não gasta margem. Um cupão custa dinheiro em cada uso e por isso tem de passar por uma conta de lucro; uma pergunta respondida custa o tempo de um bot e abre a janela de 24 horas que torna todo o resto possível. O que não muda é a exigência de haver um motivo — o piso existe nos dois casos, só está em sítios diferentes.

O código [#7C31] é o fio que liga a mensagem à sessão que a gerou — produto, carrinho, motivo, tudo. Ele pode ser apagado por quem escreve: nesse caso ligamos por proximidade, porque o clique fica registrado com hora e a mensagem chega segundos depois. Na dúvida, o bot pergunta em vez de adivinhar.

A tentação é escrever o botão assim: «Você tem 15% de desconto no seu carrinho». É seditor e está errado por duas razões diferentes.

A primeira é mecânica: o ?text= pré-preenche a caixa dela. Uma mensagem que anuncia um desconto seria ela a dizer-nos que tem 15% — não faz sentido nenhum. O texto tem de ser o bilhete de entrada dela: «quero guardar a minha sacola».

A segunda é a que interessa mais: pôr o desconto no botão é dá-lo a toda a gente que ia clicar de qualquer maneira. É o «exit intent → 10%» que este documento inteiro existe para matar. Na resposta, já sabemos que ela abriu o WhatsApp e podemos decidir se precisa mesmo de 15%, de 5%, ou só do prazo de entrega. O clique é informação nova — desperdiçá-la a confirmar um desconto já prometido é caro.

Repare no que as três linhas têm em comum: número dedicado, operado por nós, dentro da conta dela. Não é uma opção entre várias — é o desenho por defeito, e por uma razão que só aparece quando se junta o botão com os cenários de número.

E resolve, de passagem, a objeção do «o consumidor vai ver dois números da mesma marca»: o segundo número não é um número de marketing, é o número de pré-venda, com o bot que responde prazo, tamanho, estoque e frete, e escalamento para o humano da loja. Quem escreve para lá com uma dúvida não está no sítio errado — está exatamente no sítio previsto.

Há uma versão ainda mais rápida: usar o nosso número, sem pedir nada a ninguém. Vale a pena separar exatamente o que isso poupa, porque é menos do que parece.

O ganho grande é o de cima, e não depende do número. Com o botão apontado ao número da loja tens exatamente o mesmo: zero templates, zero aprovações, zero limites de volume, custo zero, e o telefone amarrado ao visitor_id. O que o nosso número poupa é só a segunda linha — um clique de quinze minutos, uma vez.

E custa quatro coisas que convém dizer em voz alta:

E o argumento para a loja passar ao número dela deixa de ser técnico: «seu cliente está falando com a Pushnews sobre a sua loja; por um clique de quinze minutos, passa a falar com você, com o seu selo verde». Isso vende-se sozinho depois de ela já ver conversas a acontecer.

Vender «recuperação de carrinho por WhatsApp» é pedir a uma loja um diagnóstico de quarenta perguntas antes de lhe mostrar um número. A ordem que funciona é a inversa — cada degrau produz o dado que torna o seguinte possível.

O degrau 3 tem uma pergunta em aberto que muda o modelo de receita: se formos Solution Partner, o custo da mensagem é nosso e há margem no canal; se formos Tech Provider, a mensagem cai na fatura Meta da loja — e nesse caso a console tem de mostrar custo por decisão, senão ela vê a fatura subir sem ligar isso às intervenções. É decisão de negócio, não técnica, e convém tomá-la antes do degrau 3.