Quando fui montar a página de convite do meu grupo de ofertas no WhatsApp, abri o código de uma página de grupo de achadinhos que eu tinha como referência, pra entender como ela convertia. Os dois gatilhos mais fortes dela eram inventados.

O que tinha no código

Três peças, todas rodando no navegador de quem visita:

• uma lista fixa de nomes e sobrenomes comuns;
• um script que, a cada 1,8 a 3 segundos, sorteia um nome dessa lista e mostra “✅ fulano entrou no grupo agora”;
• um contador que começa em “Restam 25 vagas hoje” e desce até 5 enquanto a pessoa está na página.

Simplificando, a lógica era esta (o código é meu, reescrito pra mostrar o padrão):

const nomes = ["Ana Souza", "Bruno Lima", "Carla Dias"];  // lista fixa
let vagas = 25;
function passo() {
  if (vagas <= 5) return;                              // para em 5: "últimas vagas"
  vagas--;                                             // as vagas só descem
  mostrar(`✅ ${sortear(nomes)} entrou no grupo agora`);  // ninguém entrou
  setTimeout(passo, 1800 + Math.random() * 1200);      // de 1,8 a 3 segundos
}
passo();

Ninguém entrou no grupo naquele momento, e as vagas não estavam acabando. Basta recarregar a página: o contador volta pra 25 e os mesmos nomes recomeçam a entrar.

Por que eu não uso: o que diz a lei

O Código de Defesa do Consumidor proíbe publicidade enganosa no artigo 37. O parágrafo primeiro define como enganosa a informação “inteira ou parcialmente falsa” capaz de induzir o consumidor ao erro sobre quantidade, características ou quaisquer outros dados do produto ou serviço. Um contador de vagas que não conta nada e uma lista de pessoas que não entraram são exatamente isso.

O artigo 67 vai além e trata como crime fazer ou promover publicidade que se sabe ou deveria saber ser enganosa, com pena de detenção de três meses a um ano e multa. Grupo de ofertas com link de afiliado existe pra vender, então a página de convite é publicidade. Não sou advogado. É a leitura direta do texto da lei, que está nas fontes no fim do artigo.

O problema que vem antes da lei: confiança

Grupo de ofertas vive de uma coisa: a pessoa acreditar que o “70% OFF” é de verdade. Quem recarrega a página e vê as mesmas 25 vagas, ou vê o mesmo nome “entrar” duas vezes, tem um motivo pra desconfiar de tudo que vem depois, inclusive das ofertas. O gatilho inventado empresta conversão de hoje contra a credibilidade de amanhã.

O que eu coloquei no lugar

Duas regras fazem isso funcionar:

1. Todo número tem data. Na minha página, o aviso de membros some sozinho quando a contagem fica mais velha que 10 dias. Número velho vira mentira sem ninguém perceber.
2. Escassez só quando é real. Grupo de WhatsApp lota de verdade. Quando chega perto do limite, o aviso aparece, e é a hora de criar o próximo grupo e trocar o link.

Mas a versão falsa não converte mais?

Pode converter. Eu não testei a versão falsa contra a verdadeira, e não vou testar: não faço teste A/B de coisa que eu não publicaria. O risco da versão falsa é jurídico e de confiança, e os dois aparecem depois que a campanha já gastou o dinheiro.

Checklist antes de publicar uma página de convite

• Cada número da página tem fonte e data?
• O contador mostra algo que aconteceu de fato, ou só anima a tela?
• Se a pessoa recarregar a página, ela vê a mesma coisa (e isso continua verdade)?
• A escassez tem um limite real por trás?
• As ofertas mostradas como prova são reais e têm data?

Botão de WhatsApp é um dos piores lugares pra medir conversão. A pessoa toca, o app abre por cima, e a sua página sai da tela antes de a tag terminar de mandar o evento. Na página do meu grupo de ofertas eu resolvi isso com uma página intermediária pequena, e é ela que eu mostro aqui.

Por que o clique se perde

Num link direto pro chat.whatsapp.com, a navegação começa no toque. As tags de conversão (Meta, Google Ads, GA4) são carregadas e disparadas de forma assíncrona, então podem não terminar antes de a página ser trocada. No celular, o app do WhatsApp ainda abre por cima e deixa a aba em segundo plano.

O resultado é conversão subnotificada: a campanha manda gente pro grupo, e a conta de anúncio não fica sabendo. Com menos conversão registrada, a otimização da campanha trabalha com menos sinal.

O fluxo

1. Todo botão “Entrar no grupo” da página aponta pra /entrar/, uma página sua.
2. A /entrar/ carrega o GTM e empurra o evento entrar_grupo no dataLayer.
3. O eventCallback só redireciona depois que o GTM termina de processar as tags desse evento.
4. O eventTimeout de 1.500 milissegundos garante o redirecionamento mesmo se alguma tag travar.
5. No celular, a página tenta abrir o app com whatsapp://chat?code=. Se a página continuar visível 1,5 segundo depois, ela vai pro link web.

O código da página /entrar/

O snippet padrão do GTM vai no <head> dessa página, igual em qualquer outra. Depois, este script:

<script>
  var link = "https://chat.whatsapp.com/SEU-CODIGO";
  var convite = link.match(/chat\.whatsapp\.com\/(?:invite\/)?([A-Za-z0-9]{10,40})/);
  var celular = /Android|iPhone|iPad|iPod/i.test(navigator.userAgent);
  var foi = false;

  function abrir() {
    if (foi) return;  // nunca redireciona duas vezes
    foi = true;
    if (convite && celular) {
      window.location.href = "whatsapp://chat?code=" + convite[1];
      setTimeout(function () { if (!document.hidden) window.location.href = link; }, 1500);
    } else {
      window.location.href = link;
    }
  }

  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: "entrar_grupo",
    eventCallback: function () { setTimeout(abrir, 100); },
    eventTimeout: 1500
  });
  setTimeout(abrir, 1500);  // GTM bloqueado: vai do mesmo jeito
</script>

Três detalhes que fazem diferença:

• O setTimeout extra no fim. O eventTimeout só funciona se o GTM carregar. Se um bloqueador de anúncio impedir o gtm.js, o dataLayer.push vira um item numa lista que ninguém lê, e o eventCallback nunca é chamado. Sem esse último setTimeout, a pessoa ficaria presa na tela de “Abrindo o WhatsApp”.
• A variável foi. Garante que o redirecionamento aconteça uma vez só, venha do callback ou do tempo limite.
• O link com ?mode= no fim. O link que o WhatsApp copia pode vir com parâmetros depois do código. A expressão regular pega só o código, e o resto não atrapalha.

Configurando no GTM

1. Crie um acionador do tipo Evento personalizado com o nome de evento entrar_grupo.
2. Pendure nele as tags de conversão: o evento Lead no pixel da Meta, a conversão do Google Ads e, no GA4, o evento recomendado generate_lead.
3. Publique e confira no modo de visualização do GTM se o evento aparece quando você toca em “Entrar no grupo”.

Como eu testei sem sujar os números

Testar com o GTM de verdade dispararia conversões reais na conta de anúncio. Então, no navegador de teste, interceptei o carregamento do googletagmanager.com e do chat.whatsapp.com. No lugar do GTM entrou um script que só chama o eventCallback, e o link do WhatsApp foi respondido pelo próprio teste, sem abrir o grupo.

Com o GTM funcionando, a pessoa sai mais rápido do que esperaria um tempo fixo. Com ele bloqueado, perde um segundo e meio, mas chega no grupo.

Cuidados

• Tire a /entrar/ do Google. Coloque noindex na página e um Disallow no robots.txt. Robô que visita essa página dispara evento de conversão.
• Não duplique a conversão. Se a página já tem o pixel da Meta instalado direto, além do GTM, o mesmo clique conta duas vezes. Escolha um caminho.
• Guarde o link num lugar só. Grupo de WhatsApp lota com 1.024 pessoas. Quando acontecer, você troca o link num arquivo, e todos os botões e mensagens antigas continuam levando pro grupo certo.

Conectei o WhatsApp de um painel de ofertas na Evolution API, o pareamento pelo QR code funcionou, e na hora de listar os grupos veio isto:

{"status": 500, "error": "Internal Server Error", "response": {"message": "Cannot convert undefined or null to object"}}

O WhatsApp estava conectado: o connectionState respondia open. Mesmo assim, toda chamada de grupo voltava com esse erro, e voltava na hora. Erro que responde em zero segundo não chegou nem a falar com o WhatsApp. Quebrou antes.

Onde o erro acontece

Antes de executar uma rota, a Evolution passa a requisição por um validador. A rota fetchAllGroups usa um validador próprio (o que exige o parâmetro getParticipants), e a findGroupInfos usa o validador de grupo (o que exige o groupJid). Os dois fazem a mesma coisa no começo: pegam o corpo da requisição e copiam campos para dentro dele com Object.assign.

Este é o trecho do validador do fetchAllGroups no dist/main.js da versão 2.4.0. O código é minificado; reescrevi os nomes pra ficar legível:

const query = request.query;   // ?getParticipants=false
const body = request.body;     // corpo da requisição
Object.assign(body, query);    // se body for undefined, quebra aqui

Quando body é undefined, o JavaScript lança TypeError: Cannot convert undefined or null to object, e a Evolution devolve exatamente essa mensagem dentro do erro 500.

Por que o corpo chega undefined: o Express 5

A Evolution 2.4.0 roda em cima do Express 5. Conferi no container: o node_modules/express/package.json diz versão 5.2.1. E o guia oficial de migração do Express 5 lista esta mudança: o req.body agora vem undefined quando nenhum corpo foi lido. No Express 4 ele vinha como objeto vazio, {}.

Num GET comum, o cliente não manda corpo nem Content-Type. O leitor de JSON não roda, o req.body fica undefined, e o validador quebra ao tentar copiar campos para dentro dele. No Express 4 o mesmo código funcionaria, porque o corpo seria {}. Não testei a Evolution 2.3, então não afirmo em qual versão o problema começou.

O conserto: mande {} no corpo do GET

Mande um JSON vazio no corpo, com o cabeçalho Content-Type: application/json. O leitor de JSON roda, o corpo vira {} e o validador segue normal.

Com curl (o -X GET é obrigatório, porque o -d sozinho transforma a chamada em POST):

curl -X GET "https://SUA-EVOLUTION/group/fetchAllGroups/SUA-INSTANCIA?getParticipants=false" \
  -H "apikey: SUA-CHAVE" \
  -H "Content-Type: application/json" \
  -d '{}'

Com Python e httpx, que foi o que usei no painel:

resposta = httpx.request(
    "GET",
    f"{url}/group/fetchAllGroups/{instancia}",
    params={"getParticipants": "false"},
    json={},  # o corpo vazio que evita o erro 500
    headers={"apikey": chave},
    timeout=240,
)

Um cuidado: no navegador e no fetch do Node, GET com corpo não é permitido, e a chamada falha antes de sair. Faça essa chamada do servidor, com um cliente HTTP que aceite corpo em GET, como curl, httpx ou requests.

Mandar corpo em GET é gambiarra?

É um contorno para um bug do servidor, e o padrão HTTP permite. A RFC 9110 diz que conteúdo num GET não tem significado definido e que alguns servidores podem recusar a requisição. Aqui a Evolution aceita, lê o {} e ignora. Quando o validador for corrigido, o corpo vazio continua inofensivo.

Outras pegadinhas da Evolution 2.4.0 que encontrei

Como saber se a sua Evolution tem esse problema

1. Veja a versão: um GET na raiz da sua Evolution devolve a versão no JSON.
2. Veja o Express: docker exec NOME-DO-CONTAINER grep '"version"' /evolution/node_modules/express/package.json. Versão 5 é o sinal.
3. Faça o teste: chame o fetchAllGroups sem corpo e depois com -d '{}'. Se só a segunda funciona, é esse o problema.

Versões em que testei: Evolution API 2.4.0 (imagem homolog), Baileys 7.0.0-rc13 e Express 5.2.1, em outubro de 2026.