Landing page estática da Imersão Presencial do Método P4, integrada a um workflow n8n que grava leads em Google Sheets, segmenta origem de tráfego e sincroniza o CRM comercial.
🌐 Ver página ao vivo · 📁 Repositório GitHub
Este projeto concentra a captação do lead, a coleta de tracking e a entrada no funil comercial da Imersão Presencial. O front-end vive em um único index.html; o navegador chama um proxy server-side em api/lead-proxy.php (que protege o segredo do webhook); a automação operacional está documentada em automation/README.md e versionada em automation/workflow.json.
- Evita perda de lead entre formulário, planilhas de controle e CRM.
- Preserva tracking de campanha (
utm_*,fbclid,src,sck,a_id,referrer,page_url) para análise de aquisição. - Recalcula MQL no servidor em vez de confiar no navegador.
- Segmenta os leads entre
banco de dados,PagoeOrganico. - Atualiza registros existentes no CRM sem duplicar por e-mail/WhatsApp, arquivando o snapshot anterior antes de qualquer alteração.
- Mantém o segredo de autenticação do webhook fora do navegador (proxy PHP server-side).
- Redireciona o usuário para o checkout da Sympla após o envio do formulário, propagando
fbclide as demais UTMs para a URL de destino — necessário para que o Meta Pixel/GTM na página da Sympla consiga atribuir eventos posteriores (Add to Cart, Initiate Checkout, Purchase) à campanha de origem.
- O visitante acessa a LP por tráfego pago ou orgânico.
- O
<head>captura os parâmetros de tracking antes do GTM carregar. - O formulário coleta nome, e-mail, WhatsApp, perfil de negócio, faturamento e tipo de ingresso.
- O front-end valida os campos, sanitiza o payload e envia o lead para
api/lead-proxy.php(mesmo domínio, sem nenhum segredo). - O proxy PHP valida a requisição, aplica um rate limit simples por IP, e repassa ao webhook do n8n anexando o segredo de autenticação (que só existe no servidor).
- O workflow normaliza os dados, recalcula MQL, deduplica por WhatsApp e grava 100% dos leads em
banco de dados. - O mesmo workflow envia o lead para exatamente uma aba de segmentação:
PagoouOrganico. - O CRM é consultado por e-mail e, se necessário, por WhatsApp; se o lead já existir, o registro atual é arquivado em
Archived Leadse então atualizado no lugar; se for novo, um registro é criado. - Após o envio, a página mostra sucesso e redireciona para o checkout da Sympla.
flowchart LR
A[Acesso à landing page] --> B[Captura first-touch de tracking]
B --> C[Preenchimento e validação do formulário]
C --> P[Proxy PHP: api/lead-proxy.php]
P --> D[Webhook n8n]
D --> E[Normalização, MQL e deduplicação]
E --> F[banco de dados]
E --> G[Pago ou Organico]
E --> H[CRM: cria ou arquiva + atualiza]
D --> I[Redirecionamento para Sympla]
O front-end calcula uma classificação preliminar apenas para analytics, mas o valor final de MQL é recalculado no n8n. A regra atual é:
MQL = "Sim"quandoja_vende_marketplaces = sim, omodelo_negocioestá entreloja_fisica,ecommerce_marketplaceouindustria_distribuidora, e ofaturamentoé maior queate_50k.MQL = "Não"em qualquer outro cenário.
- Frontend: HTML5, CSS3 e JavaScript vanilla
- Tracking: Google Tag Manager com carga diferida
- Automação: n8n via webhook autenticado por header
- Persistência operacional: Google Sheets
- CRM: planilha operacional sincronizada pelo próprio workflow n8n
- Deploy: HostGator/cPanel
| Camada | Responsabilidade |
|---|---|
index.html |
Interface da LP, tracking, validação, modal, envio ao proxy e redirecionamento |
api/lead-proxy.php |
Proxy server-side: recebe o POST do navegador, valida, aplica rate limit, anexa o segredo do webhook e repassa ao n8n |
automation/workflow.json |
Export versionado do workflow lead-Imersão |
automation/README.md |
Fonte de verdade documental da automação |
assets/ |
Imagens, tipografia e mídia da landing page |
.
├─ .htaccess # clean URLs + SPA fallback para rotas de seção
├─ api/
│ ├─ lead-proxy.php # proxy do webhook (secret nunca chega ao navegador)
│ ├─ config.example.php # template committado
│ ├─ config.php # real, gitignored — criado manualmente no servidor
│ └─ .htaccess # bloqueia listagem de diretório e acesso a config*.php
├─ assets/
│ ├─ brand/
│ ├─ fonts/
│ ├─ marketplaces/
│ ├─ team/
│ └─ venue/
├─ automation/
│ ├─ README.md
│ └─ workflow.json
├─ index.html
├─ LICENSE
└─ README.md
- Rotas limpas para navegação interna (
/,/imersao,/quem-conduz,/onde,/duvidas,/inscricao) sem exporindex.html#...na barra de endereço. - Formulário único com validação client-side (nome, e-mail, WhatsApp, modelo de negócio, faturamento, ingresso individual/duplo).
- Captura de tracking (
utm_*,fbclid,src,sck,a_id,referrer,page_url) no<head>, antes de qualquer script assíncrono carregar. - Honeypot anti-bot (
website) e sanitização anti-injeção de fórmula (sanitizeForSheets()) antes do envio. - Cálculo preliminar de MQL no client (só para analytics) e recálculo autoritativo no servidor.
- Segmentação automática de origem de tráfego (Pago vs. Orgânico, por presença de
fbclid) e sincronização com o CRM comercial, sem duplicar registros. - Nenhum lead se perde silenciosamente: leads barrados por validação ou duplicidade são registrados na aba Descartes para auditoria e disparam uma notificação por e-mail.
- Redirecionamento automático para o checkout da Sympla após o envio do formulário, propagando
fbclide as demais UTMs para a URL de destino — necessário para que o Meta Pixel/GTM na página da Sympla consiga atribuir eventos posteriores (Add to Cart, Initiate Checkout, Purchase) à campanha de origem.
| Serviço | Papel |
|---|---|
n8n (n8n.srv1095468.hstgr.cloud) |
Motor da automação: recebe o webhook, valida, deduplica, classifica e grava os dados |
| Google Sheets | Persistência operacional (banco de dados, Pago, Organico) e CRM comercial (CRM) |
| Gmail | Alerta de erro de execução e notificação de leads descartados |
| Google Tag Manager | Tracking client-side (carregado de forma diferida) |
| Sympla | Checkout do ingresso, para onde o usuário é redirecionado após o envio do formulário |
Detalhes de cada integração (credenciais, nós do workflow, tratamento de erro) estão em automation/README.md.
Não há .env ou variáveis de ambiente de build — é um site estático servido como arquivo. Em index.html, WEBHOOK_URL aponta para o caminho relativo /api/lead-proxy.php (sem nenhum segredo no client).
O segredo real de autenticação do webhook vive só no servidor, em api/config.php — um arquivo gitignored, nunca commitado, criado manualmente a partir do template api/config.example.php:
return [
'webhook_url' => 'https://n8n.srv1095468.hstgr.cloud/webhook/imersao-presencial-marketplaces',
'webhook_secret' => 'COLE_AQUI_O_SECRET_REAL',
'rate_limit_max_requests' => 8,
'rate_limit_window_seconds' => 60,
];Isso substitui a abordagem anterior (secret embutido no JavaScript público) — ver automation/README.md para o detalhe completo do proxy.
Não há dependências para instalar — não existe package.json, build step ou bundler. Basta clonar o repositório:
git clone https://github.com/taysouzaa/imersao.git
cd imersaoNenhuma configuração local é necessária para visualizar a página. Para testar o envio real do formulário contra o n8n de produção, é preciso ter acesso à instância n8n (n8n.srv1095468.hstgr.cloud) e às credenciais do Google Sheets/Gmail já cadastradas nela — ver automation/README.md.
Qualquer servidor estático com fallback SPA funciona. O comando recomendado para desenvolvimento local usa serve:
npx serve -s -l 5500 .Depois, acesse http://localhost:5500. O modo -s é importante para testar refresh direto em rotas limpas como /inscricao ou /duvidas. O formulário, quando enviado localmente, ainda chama o webhook de produção (não existe um ambiente de staging do n8n) — use dados de teste claramente identificados (ex.: "TESTE ... (pode apagar)") se for submeter o formulário de fato.
O deploy é manual, via upload de arquivos para o HostGator/cPanel (não há CI/CD configurado):
- Validar as mudanças localmente (
npx serve -s+ teste manual do formulário com dados de teste). - Fazer upload de
index.html, do arquivo.htaccess, da pastaassets/e da pastaapi/para o diretório público do domínioimersao.metodop4.com.brno cPanel. - Criar
api/config.phpdiretamente no servidor a partir deapi/config.example.php, preenchendo a URL real do webhook e o segredo (esse arquivo nunca é commitado nem enviado pelo processo normal de upload do restante do código). - Confirmar em produção que a página carrega, o tracking dispara, as rotas limpas recarregam sem 404 e o formulário grava corretamente (checar a aba "banco de dados" no Google Sheets).
Não versionar exports manuais de deploy (.zip, pastas de upload) neste repositório — historicamente isso gerou divergência entre o que estava em produção e o que estava no index.html versionado (motivo pelo qual a pasta hostgator_upload_imersao/ foi removida do projeto).
| Sintoma | Onde investigar |
|---|---|
Refresh em /inscricao / /duvidas etc. cai em 404 |
Confirmar se o .htaccess da raiz foi enviado no deploy e se o Apache do cPanel está com mod_rewrite habilitado |
| Formulário não envia / erro no console | Checar se api/config.php existe no servidor (o proxy responde 500 proxy_not_configured se não existir) e se WEBHOOK_URL em index.html aponta para /api/lead-proxy.php |
| Proxy retorna 429 | Rate limit do api/lead-proxy.php foi atingido (default 8 req/60s por IP) — ajustável em api/config.php |
| Lead não aparece em nenhuma planilha de leads (Pago/Organico/banco de dados) | Ver execuções do workflow lead-Imersão no n8n — pode ter sido barrado em "Validar campos obrigatórios" ou "Filtrar duplicata"; nesse caso ele é gravado na aba Descartes (gid 899834827) para auditoria e chega um e-mail de notificação |
| Lead aparece na aba errada (Pago vs. Organico) | Conferir a regra de classificação em Format lead — hoje é só fbclid presente; nenhum outro critério (utm_medium/channel) conta |
| Telefone não aparece no CRM | Conferir a coluna Telefone 1 (não Telefone / WhatsApp) — é a coluna real de telefone usada pelo time comercial |
| CRM duplicado | Verificar se o e-mail do lead está normalizado (trim + lowercase) — o dedup é primariamente por e-mail, com fallback pelo telefone na coluna Telefone 1 |
| CRM atualizado com dado errado/incompleto | Conferir se o node "Atualizar CRM" no n8n referencia $('Buscar duplicata CRM').item.json (não $json bruto) — um bug real nesse sentido já ocorreu e foi corrigido, ver automation/README.md |
| UTM/fbclid não chegou na planilha | Confirmar que a Landing Page está enviando o campo no payload (window.__leadTracking) e que o Parse Imersão no n8n tem esse campo no pick() |
| Alerta de erro por e-mail chegou | Ver o link da execução no e-mail — geralmente é falha de credencial/quota do Google Sheets |
- Qualquer mudança no workflow n8n deve ser re-exportada para
automation/workflow.json, para manter o repositório como fonte de verdade auditável. - Ao alterar campos do formulário em
index.html, conferir se opick()do nodeParse Imersão(n8n) precisa ser atualizado para capturar o novo campo — histórico do projeto já teve campos capturados na LP e silenciosamente descartados no backend. - Ao adicionar uma nova coluna em qualquer aba do Google Sheets, replicar a mudança nas três abas de leads (
banco de dados,Pago,Organico) para manter os schemas consistentes. - Não reintroduzir exports manuais de deploy (
.zip, pastas*_upload_*) no controle de versão.
- Sempre testar mudanças no formulário e nas rotas limpas localmente antes do deploy (
npx serve -s). - Usar nomes de teste claramente identificáveis (ex.:
"TESTE ... (pode apagar)") ao testar o envio contra o webhook de produção, já que não existe ambiente de staging. - Preferir editar
index.htmldiretamente a criar arquivos/abstrações novas — é uma landing page estática de arquivo único, sem build step. - Manter
automation/README.mdeautomation/workflow.jsonsincronizados com o estado real do workflow no n8n.
- Não existe mais webhook separado para CRM no front-end; toda a automação passa por um único endpoint n8n, acessado através do proxy
api/lead-proxy.php. - O segredo do webhook não fica mais exposto no JavaScript público — vive só em
api/config.phpno servidor. - Leads existentes no CRM são arquivados (aba
Archived Leads) antes de serem atualizados — o registro não é fisicamente reordenado para o final da planilha (limitação conhecida, documentada emautomation/README.md). - A documentação detalhada da automação, integrações, limitações conhecidas e mapeamento de campos está em
automation/README.md.
Licença proprietária — todos os direitos reservados. Qualquer uso, mesmo parcial, requer autorização prévia por escrito da autora. Ver LICENSE para os termos completos.