Rota do lead

A plataforma da Athlete's Hub funciona. O que não funciona é a velocidade com que conseguimos testar uma página nova de captação.

Hoje toda página nova depende da agenda de quem mexe na plataforma. Não conseguimos publicar, ajustar nem testar uma variação sozinhos, e campanha de tráfego vive exatamente disso: colocar duas versões no ar na terça e saber na sexta qual delas converteu melhor. Quando cada ajuste vira um pedido na fila de outra pessoa, a campanha anda no ritmo da fila.

Existe um segundo ponto, mais silencioso e mais caro. O anúncio leva a pessoa para o athleteshub.com.br e o cadastro acontece no athleteshub.app. A origem do anúncio é repassada nesse salto, então ela chega. O que não existe é a costura de volta: o lead nasce dentro da plataforma e nada devolve para a medição qual visita virou qual lead. Sabemos quantas pessoas clicaram, o que elas leram e onde pararam de rolar a página. Não sabemos quais delas viraram cadastro.

Sem essa costura, otimizar anúncio é chute educado. Com ela, paramos de investir no criativo que traz volume e passa a investir no que traz lead que fecha.

As páginas de captação passam a morar no domínio que já administramos, e cada lead capturado é entregue dentro da base da Athlete's Hub por uma porta que o time cria e pode fechar a qualquer momento.

Nada é alterado dentro da plataforma. Não vamos publicar, editar nem mexer em uma linha do que já está no ar. A plataforma só ganha uma entrada nova de lead, do mesmo tipo das que ela já tem.

Essa ordem parece um detalhe técnico e é a decisão mais importante do documento.

• Lead nenhum se perde. Se a plataforma estiver fora do ar, se o token expirar ou se algum campo mudar de nome, o registro já está guardado e a entrega é refeita sozinha. Formulário que grava direto no banco do outro lado perde lead em silêncio, e ninguém descobre porque não há o que conferir.
• A visita e o lead finalmente se encontram. O lead nasce dentro do portão, no mesmo instante em que a medição da página já está identificando aquela visita. Origem do anúncio, comportamento na página e resposta do diagnóstico ficam na mesma linha desde o primeiro dia.
• Nenhuma chave da Athlete's Hub vai parar no navegador. O token fica guardado no servidor do portão. Ninguém consegue abrir o código da página e achar essa credencial, porque ela não passa por lá.
• A Athlete's Hub continua dona do dado oficial. A base dela segue sendo a verdade comercial. O que guardamos é a camada de marketing, e ela existe para responder uma pergunta que a plataforma não precisa responder: qual anúncio pagou esse lead.

A boa notícia é que o caminho que recomendamos já é o jeito que a plataforma funciona hoje.

A plataforma roda em Supabase e já tem uma coleção de funções de entrada publicadas, no padrão submit-alguma-coisa: submit-sports-assessment, submit-english-test, submit-financial-aid e outras. Cada uma recebe informação de fora, confere e grava. O que estamos pedindo é mais uma função exatamente igual a essas.

Se por qualquer motivo esse caminho travar, existe um terceiro: o portão entrega o lead por onde a Athlete's Hub já recebe informação hoje, como o WhatsApp automático ou um webhook do CRM. Funciona e não bloqueia o projeto, mas a informação chega mais pobre e a conferência vira trabalho manual. É a terceira opção justamente por isso.

Oito itens, e a maior parte é resposta de uma linha. Estão numerados para você poder responder por item.

Seis etapas. A construção da página anda em paralelo com o acesso, então o projeto não fica parado esperando resposta.

1. A lista de campos

   Mandamos o que pretendemos enviar, campo por campo, e o time da Athlete's Hub confirma ou corrige. É uma conversa curta, e é ela que evita retrabalho depois.

   Depende dos itens 1, 5 e 6.

2. A porta de entrada no Supabase

   A função é criada e o token é gerado. Testamos com um lead de mentira e conferimos junto com o time que ele apareceu no lugar certo do CRM.

   Depende dos itens 3 e 4.

3. Página e diagnóstico no domínio da campanha

   Construídos por nós, com a identidade visual da Athlete's Hub que já usamos nas páginas atuais. Esta etapa corre em paralelo com a 2.

   Depende do item 2.

4. Teste ponta a ponta

   Enchemos o formulário de verdade, do clique no anúncio até o lead aparecer no CRM, e você confere com os próprios olhos antes de qualquer real ser investido.

5. Virada do tráfego

   Começa com uma parte do investimento, não com tudo. Se algo estiver errado, erramos barato e voltamos atrás em minutos.

6. Acompanhamento

   Com a costura pronta, passamos a comparar criativo por criativo pelo lead que ele gerou, e não mais pelo clique que ele comprou.

O que a gente não vai fazer importa tanto quanto o que vai.

• Não vamos simular o formulário da Athlete's Hub. Nada de robô preenchendo tela por trás, nada de usar chave encontrada no código do site. A entrega acontece pela porta combinada ou não acontece.
• Não vamos guardar credencial da Athlete's Hub no navegador. Token fica no servidor, sempre.
• Não vamos duplicar a área logada. Cadastro, assinatura e produto continuam sendo da Athlete's Hub, em um lugar só.
• Não vamos mandar o mesmo lead por dois caminhos. O portão é o único, justamente para não existir lead duplicado nem contagem dobrada.

• Página no ar no dia em que ela ficar pronta, sem depender da fila de ninguém, e o mesmo vale para corrigir um texto que não está convertendo.
• Teste de verdade. Duas versões da mesma oferta no ar ao mesmo tempo, com resposta em dias em vez de meses.
• Cada lead com a origem grudada nele. Qual anúncio, qual criativo, quanto custou e o que a pessoa fez na página antes de preencher.
• Risco zero para a plataforma. Nada é alterado dentro do que já está funcionando. O que existe é uma entrada nova, isolada e desligável.
• Reversível. Se um dia a Athlete's Hub quiser trazer tudo para dentro da plataforma, a informação já está estruturada e o caminho de volta é curto.