Formulário com campo demais: como pedir só o dado que tem finalidade

O e-book "Guia de backup para pequenas empresas" tinha um formulário com nome, e-mail, telefone obrigatório, empresa, cargo, número de funcionários e data de nascimento. De cada cem pessoas que abriam a página, sete terminavam. Quando o time reduziu para um único campo de e-mail, a conversão mais que triplicou, e o comercial descobriu que nunca tinha ligado para nenhum daqueles telefones. A resposta curta: cada campo precisa de uma frase honesta dizendo para que serve; se você não consegue escrever essa frase, o campo sai. Obrigatório é só o que impede o serviço de acontecer, e qualquer uso extra, como newsletter, vai num checkbox separado e desmarcado.

Isso não é só boa prática de conversão. Finalidade, adequação e necessidade são princípios da LGPD (artigo 6º): você coleta para um propósito informado, compatível com o que a pessoa espera, e no mínimo necessário para cumpri-lo.

Por que o formulário vira coleta

Formulário cresce por acúmulo. O marketing quer segmentar por cargo, o comercial quer telefone "para o caso de", alguém acha que data de nascimento rende um e-mail de parabéns. Ninguém remove campo, porque remover parece perder informação. Em dois anos, um download de PDF pede mais dados que uma abertura de conta.

O custo aparece em três lugares. A pessoa desiste ou inventa dados ("(11) 99999-9999"), então a base fica cheia de lixo. Quem preenche de verdade entrega informação sem saber o uso, o que corrói a confiança quando o telefone começa a tocar. E você passa a guardar, proteger e responder por dados que não usa: cada campo extra entra no backup, no export, no pedido de exclusão e no tamanho de um eventual vazamento.

Como decidir o que fica: o teste da frase

1. Liste os campos. Todos, inclusive os ocultos que preenchem origem da campanha.
2. Escreva a frase de uso de cada um. "E-mail: para enviar o link do e-book." Se a frase for "pode ser útil", o campo sai.
3. Faça o teste da quebra. Se tirar o campo, o serviço deixa de acontecer? Se não deixa, ele não é obrigatório.
4. Separe os usos extras. Newsletter, contato comercial e pesquisa são finalidades diferentes. Cada uma tem seu checkbox, desmarcado, com texto próprio.
5. Mostre a frase na tela. Um texto curto perto do campo, não só na política.
6. Faça o servidor obedecer. Ele aceita só os campos previstos e descarta o resto.
7. Defina por quanto tempo guarda. O e-mail do download não precisa viver para sempre se a pessoa não quis a newsletter. Veja retenção com data.

O exemplo do e-book, campo a campo

• E-mail: fica, obrigatório. Frase: "para enviar o link de download".
• Nome: opcional. Só personaliza a saudação do e-mail; o serviço funciona sem ele.
• Telefone: sai. Ninguém liga para quem baixa um PDF.
• Empresa, cargo, funcionários: saem. Se o marketing precisa de segmentação, pergunta depois, para quem aceitou receber conteúdo, explicando por quê.
• Data de nascimento: sai. Não tem relação nenhuma com um e-book.
• Newsletter: checkbox separado, desmarcado: "Quero receber o boletim mensal sobre infraestrutura. Posso cancelar a qualquer momento."

Como implementar no front e no servidor

O formulário enxuto:

<form method="post" action="/ebook/backup">
  <label for="email">E-mail</label>
  <input type="email" id="email" name="email" required autocomplete="email">
  <small>Usamos só para enviar o link do e-book.</small>

  <label>
    <input type="checkbox" name="newsletter" value="sim">
    Quero receber o boletim mensal sobre infraestrutura. Posso cancelar quando quiser.
  </label>

  <button type="submit">Receber o e-book</button>
</form>

No servidor, Express com mysql2/promise. O handler lê só os dois campos previstos e grava o consentimento da newsletter separado, com a versão do texto que a pessoa viu:

const express = require('express');
const mysql = require('mysql2/promise');

const pool = mysql.createPool({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME
});

const TEXTO_NEWSLETTER = 'boletim-mensal-v3';
const app = express();

app.post('/ebook/backup', express.urlencoded({ extended: false, limit: '2kb' }), async (req, res, next) => {
  const email = String(req.body.email || '').trim().toLowerCase();
  const querNewsletter = req.body.newsletter === 'sim';

  if (email.length > 254 || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    return res.status(400).send('Informe um e-mail válido.');
  }

  let conn;
  try {
    conn = await pool.getConnection();
    await conn.beginTransaction();
    await conn.execute(
      'INSERT INTO downloads_ebook (email, ebook, criado_em) VALUES (?, ?, NOW())',
      [email, 'backup']);
    if (querNewsletter) {
      await conn.execute(
        'INSERT INTO consentimentos (email, finalidade, texto_versao, registrado_em) VALUES (?, ?, ?, NOW())',
        [email, 'newsletter', TEXTO_NEWSLETTER]);
    }
    await conn.commit();
    res.redirect(303, '/ebook/backup/obrigado');
  } catch (err) {
    if (conn) await conn.rollback().catch(() => {});
    next(err);
  } finally {
    if (conn) conn.release();
  }
});

Repare em três coisas. O código não faz INSERT com req.body inteiro, então um campo enfiado no formulário por outra página não entra no banco. A tabela de downloads não tem coluna de newsletter: quem só baixou o e-book não aparece na lista de envio por acidente. E a versão do texto fica gravada, para você saber exatamente com o que a pessoa concordou se o texto mudar. As consultas usam parâmetro, como explicado em Node.js e MySQL com parâmetro.

Reaproveitar é o erro mais caro

O formulário pode estar perfeito e o problema aparecer seis meses depois, quando alguém exporta "todo mundo que baixou algo" para a campanha de Black Friday. A pessoa deu o e-mail para receber um PDF, não para receber oferta. Usar o dado para outra finalidade sem base legal adequada contradiz o que você mesmo prometeu na tela.

A defesa é estrutural: listas separadas por finalidade, e a ferramenta de envio de marketing só enxerga a tabela de consentimentos. O mesmo vale para o comentário do blog e para o formulário de contato: o e-mail serve para responder aquela mensagem.

Erros comuns

• Telefone obrigatório para baixar material. A conversão despenca e a base enche de número falso.
• Checkbox de newsletter marcado por padrão. Quem não percebeu "aceitou", e o primeiro envio gera descadastro e denúncia de spam.
• Um checkbox para tudo. "Aceito termos, newsletter e contato comercial" junta finalidades diferentes numa escolha só.
• Gravar o corpo inteiro do formulário. Qualquer campo extra enviado entra no banco sem você ter decidido coletar.
• Explicar o uso só na política. Ninguém lê a política antes de preencher; a frase precisa estar ao lado do campo.
• Exportar a base de downloads para marketing. Você usa o dado para algo que a pessoa não escolheu.

Checklist

• Cada campo tem uma frase de uso escrita e visível na tela.
• Só são obrigatórios os campos sem os quais o serviço não acontece.
• Usos extras têm checkbox próprio, desmarcado, com texto específico.
• O servidor lê campos por nome e ignora os não previstos.
• O consentimento é gravado com data e versão do texto.
• A ferramenta de marketing só acessa a lista de quem consentiu.
• Existe prazo de guarda para quem não aceitou nada além do serviço.

Abra o maior formulário do seu site e faça o teste agora: qual campo você pode apagar hoje sem que o serviço deixe de funcionar, e por que ele ainda está ali?