---
id: educacao/captacao-por-lancamento
industria: Educação
uso: comum
esforco: médio
grao: Pessoa x lançamento (cadastro) e pessoa x lançamento x pergunta (resposta)
---

# Captação por lançamento

Quantas pessoas se cadastraram em cada lançamento, quem respondeu a pesquisa e qual o perfil delas, numa tabela só e sem uma consulta copiada por lançamento.

## Resumo executivo

**Para quem:** Infoprodutores, cursos livres e escolas que fazem lançamentos, webinários e funis perpétuos com página de captura e pesquisa.

**O que resolve**

- Um lançamento novo é uma linha numa tabela, e não mais uma consulta copiada com data e código escritos à mão.
- Cadastro e resposta de pesquisa contados como eventos diferentes, por pessoa única, na primeira data de entrada.
- Perfil do lead (renda, escolaridade, ocupação, temperatura) por lançamento, sem misturar perguntas diferentes na mesma coluna.

**Por que importa:** No lançamento, a decisão é diária: subir verba, trocar criativo, mudar a página. O time precisa ver cadastros e perfil durante a captação, não depois do carrinho. Quando cada lançamento é uma consulta copiada, uma data esquecida ou um código parecido traz a base errada, e o perfil que orienta a oferta sai de outro público.

**Perguntas de negócio que responde**

- Quantas pessoas se cadastraram no lançamento atual até agora, por dia e por campanha?
- Quantos cadastrados responderam a pesquisa, e quantos são quentes, mornos e frios?
- Qual o perfil de renda e escolaridade dos leads quentes deste lançamento?
- Como a captação deste lançamento se compara com a do anterior no mesmo dia de captação?
- Quantos leads deste lançamento são MQL pelo critério do produto?
- Qual página e qual versão de página trouxe mais cadastros?

**O que você precisa**

- A fonte dos cadastros e das respostas conectada na Nekt (banco da página, formulário, automação de marketing)
- Uma tabela de lançamentos com código, produto, abertura, fim da captação e carrinho
- O critério de qualificação de cada produto, pergunta a pergunta

**O que você recebe**

- Uma tabela de cadastros com uma linha por pessoa e lançamento, com UTM, página e versão
- Uma tabela de respostas em chave e valor, uma linha por pessoa, lançamento e pergunta
- A planilha do lançamento atualizada sozinha para o time
- Perfil e MQL por lançamento no painel e no agente de IA

## Detalhado

### O problema

A página de captura grava um documento por envio, com lançamento, versão da página, temperatura e respostas misturados num JSON. O time pede a lista de cada lançamento e a solução vira uma consulta copiada por lançamento, com o código procurado por trecho de texto, a data de abertura escrita à mão e o fuso corrigido subtraindo três horas. Cada pergunta nova da pesquisa vira uma coluna nova, e a mesma pergunta feita para produtos diferentes cai na mesma coluna.

### Regras de negócio

1. **Lançamento por código exato, de uma tabela.** O lançamento de cada envio sai, em ordem, do campo de lançamento do documento, do mesmo campo dentro dos dados do formulário, do caminho da página e da UTM, e é comparado por igualdade com a tabela de lançamentos (código, produto, abertura, fim da captação, carrinho). Busca por trecho (contém 'ora') pega códigos parecidos e textos que não são lançamento. Abertura e fim da captação saem da tabela, nunca escritos na consulta. (Evite: launch LIKE '%ora%' e a data de abertura digitada em cada consulta.)
2. **Cadastro e pesquisa são eventos diferentes.** Cadastro é o envio da página de captura. Resposta de pesquisa é o envio da página de obrigado (por exemplo version = 'typ'), com o perfil. Classifique pelo tipo de página ou de formulário, não pela ausência de respostas: definir cadastro como escolaridade vazia tira da conta quem respondeu e põe nela quem pulou a pergunta. (Evite: Cadastro = linhas com nivel_escolaridade nulo.)
3. **Pessoa única, na primeira entrada.** Conte pessoas por lançamento pelo e-mail normalizado (minúsculo, sem espaços), com o telefone só como apoio. A mesma pessoa no mesmo lançamento conta uma vez, na primeira data de entrada; para os atributos, use a resposta mais recente. Quando duas fontes registram o mesmo cadastro (formulário e planilha da página, versões antiga e nova da página), fique com a de maior prioridade declarada. (Evite: Contar linhas da página de captura como pessoas.)
4. **Fuso e formato de data resolvidos uma vez.** createdAt chega em ISO com Z (UTC) ou em dd/mm/aaaa, às vezes sem hora. Converta para America/Sao_Paulo na camada de captação, escolhendo o parser pelo formato, e compare datas já convertidas. Subtrair três horas na mão numa consulta e comparar texto com data em outra desloca cadastros entre dias. Hora desconhecida fica marcada, não inventada. (Evite: createdat - INTERVAL '3' HOUR numa consulta e comparação de texto em outra.)
5. **Respostas em chave e valor, pela referência da pergunta.** Guarde uma linha por pessoa, lançamento e pergunta, com o id ou a referência da pergunta como chave. Pivotar pelo título funde perguntas diferentes: a mesma frase de previsão de investimento existia uma vez por produto, e cada lançamento cria sua própria pergunta de expectativa. O pivot, se necessário, acontece na leitura, pela referência. (Evite: Uma coluna por título de pergunta, com a primeira resposta que aparecer.)
6. **Id do campo é por conta.** Em automação de marketing com várias contas, o mesmo campo de qualificação tem id diferente em cada conta, e o título já foi renomeado. Mapeie conta x id do campo numa tabela de referência e pivote pelo id, filtrando sempre pelo par. O campo do contato guarda só a resposta mais recente, com a data: a resposta de uma inscrição específica vem do formulário ou do CRM. (Evite: field IN (ids das três contas) ou filtro pelo título do campo.)
7. **Temperatura tem dono, e nulo não é frio.** A temperatura da página (quente, morno, frio, gravada como q, m, f) vem da página ou da campanha que trouxe o lead. A percepção do consultor é outra coisa, em outra coluna, e costuma ser pouco preenchida. Sem valor fica nulo: preencher com frio ou criar não informado dentro da escala distorce o perfil. (Evite: Tratar lead sem temperatura como frio.)
8. **Respostas normalizadas, sem inventar de-para.** Normalize caixa e espaços. Respostas podem chegar codificadas (por exemplo em hexadecimal) misturadas com texto claro: decodifique só quando o resultado for texto legível. Escalas diferentes entre contas ou produtos (faixas de renda com cortes diferentes) só se comparam nos cortes que coincidem. Valor fora da lista de opções fica visível, não é descartado. (Evite: Agrupar a renda de dois formulários com faixas diferentes na mesma escala.)
9. **MQL é critério por produto, em lógica E.** O lead é MQL de um produto quando atende a todas as perguntas marcadas como critério daquele produto. Perguntas marcadas como não interfere ou não se aplica ficam fora. Produto sem critério definido não tem MQL: não trate todos os leads dele como qualificados. Campos de cadastro (nome, e-mail, empresa) nunca entram no critério. (Evite: Um MQL único para todos os produtos, ou todo lead de produto sem regra virando MQL.)
10. **Schema fixo para a planilha do time.** A captação alimenta planilhas e painéis por ETL reverso. Fixe os tipos das colunas: uma coluna vazia num dia não pode virar tipo nulo e quebrar a carga. Pergunta nova entra como linha na tabela de chave e valor, não como coluna nova na planilha. (Evite: Deixar o tipo da coluna ser inferido a cada execução.)

### Como cada envio vira cadastro, pesquisa ou temperatura

Campos típicos do documento da página de captura.

- **Página de captura (version cap)** → Cadastro (`evento = cadastro`)
- **Página de obrigado (version typ)** → Resposta de pesquisa, com perfil (`evento = pesquisa`)
- **launch, data.launch, path, utm** → Código do lançamento, nesta ordem (`igual ao código da tabela`)
- **temperature = q** → Quente
- **temperature = m** → Morno
- **temperature = f** → Frio
- **temperature vazia** → Sem temperatura: nulo, não frio
- **Formulário de sessão ou levantada de mão** → Entrada no comercial

### Definições

| Métrica | Definição |
|---|---|
| Cadastros do lançamento | pessoas distintas (e-mail normalizado) com envio da página de captura do lançamento entre a abertura e o fim da captação, na primeira data de entrada |
| Respostas de pesquisa | pessoas distintas com envio da página de obrigado do lançamento |
| Taxa de resposta da pesquisa | respostas de pesquisa / cadastros do mesmo lançamento |
| Cadastros por temperatura | cadastros por valor de temperatura da página, com sem temperatura em linha própria |
| Dia de captação | dias desde a abertura do lançamento, para comparar lançamentos no mesmo ponto |
| MQL do produto | lead que atende a todos os critérios marcados para o produto, pela resposta mais recente de cada pergunta |
| Cobertura da pesquisa | leads com pelo menos uma resposta / leads do período, declarada ao lado de qualquer perfil |

### Armadilhas

- **Nome da consulta, outro lançamento.** Uma consulta copiada de lançamento em lançamento dizia no nome que trazia quatro lançamentos e filtrava um quinto no código. A planilha do time recebeu a base errada. Como evitar: Uma tabela de captação com coluna de lançamento e filtros vindos da tabela de lançamentos.
- **Data de abertura escrita à mão.** A data de corte digitada numa consulta não batia com a do comentário logo acima, e ninguém sabia qual era a abertura certa do lançamento. Como evitar: Abertura e fim da captação só na tabela de lançamentos.
- **Perguntas fundidas no pivot.** O BI pivotava as respostas pelo título, e a pergunta de previsão de investimento de vários produtos caía numa coluna só, com uma resposta escolhida ao acaso. Como evitar: Chave pela referência da pergunta.
- **Perfil tirado de uma fração.** O questionário de qualificação só existia a partir de um mês recente e cobria uma parte pequena dos leads, mas o perfil do ano inteiro foi tirado dessa fração. Como evitar: Declare a cobertura e o início da série antes de falar de perfil.
- **Campo oculto que não veio.** Só uma minoria das submissões do formulário trazia o campo oculto com o funil, e o resto ficava sem lançamento. Como evitar: Derive o lançamento da página ou do formulário de origem, quando ele é de um lançamento só.
- **Integração escrevendo no campo errado.** Campos de consentimento e de qualificação da automação recebiam código de criativo, telefone e o texto trafegopago, e o perfil ficou com valores sem sentido. Como evitar: Compare o valor gravado com a lista de opções do campo e marque o desvio.

### Teste de aceitação

- [ ] A soma de cadastros por lançamento é igual ao número de pessoas distintas na fonte entre a abertura e o fim da captação, sem diferença.
- [ ] Nenhuma pessoa aparece duas vezes como cadastro no mesmo lançamento.
- [ ] Cadastrar um lançamento novo exige só uma linha na tabela de lançamentos, e a planilha do time passa a trazê-lo na execução seguinte.
- [ ] Um cadastro feito às 23h de Brasília aparece no dia local certo.
- [ ] Nenhuma coluna de perfil mistura respostas de perguntas de produtos diferentes: cada pergunta tem uma referência única.

### Context document

```text
Captação por lançamento
- Lançamentos: tabela <tabela de lançamentos> com código, produto, abertura, fim da captação e carrinho. Filtros de data vêm dela.
- Código do lançamento lido de launch, depois data.launch, depois path, depois a UTM <campo>; normalizado (minúsculo, sem espaços) e comparado por igualdade. Nunca LIKE por trecho.
- Cadastro = envio da página de captura (version <cap>). Pesquisa = envio da página de obrigado (version <typ>). Não classificar por ausência de resposta.
- Pessoa = e-mail normalizado. A mesma pessoa no mesmo lançamento conta uma vez, na primeira data de entrada. Atributos pela resposta mais recente.
- Datas em America/Sao_Paulo, convertidas na camada de captação. createdAt chega em ISO com Z ou em dd/mm/aaaa.
- Respostas em chave e valor: pessoa x lançamento x referência da pergunta. Não pivotar pelo título.
- Automação com várias contas: id do campo por conta pela referência <tabela conta x campo>. O campo do contato guarda só a última resposta.
- Temperatura da página: q = quente, m = morno, f = frio; vazio = nulo. Percepção do consultor é outra coluna.
- MQL por produto: todos os critérios marcados (lógica E); não interfere fica fora; produto sem critério não tem MQL.
- Sempre informar a cobertura da pesquisa e a última carga.
Exceções por cliente:
- <cliente>: o lançamento <código> teve segunda onda (<código>L2); somar as duas só quando pedido.
- <cliente>: as faixas de renda de <produto> têm cortes diferentes; comparar só em sem renda, até <valor> e acima de <valor>.
- <cliente>: MQL de <produto> = <pergunta> em <valores> E <pergunta> em <valores>.
```

### Variações

- **Funil perpétuo:** Lead = entrada de uma pessoa num funil (ebook, minicurso, sessão); a mesma pessoa no mesmo funil e no mesmo dia conta uma vez, e a levantada de mão vira entrada no comercial.
- **Qualificação no CRM:** Quando a qualificação vive em campos do CRM, o tipo de cliente pode vir da resposta do questionário de marketing, pelo e-mail, com a quantidade de fallbacks declarada.
- **Perfil do comprador:** Cruze comprador, turma e cargo para o perfil de quem compra cursos de ticket alto, segmentando só compradores, não toda a base de leads.