Gerador de CSV com leads fake

CSV de leads fake: dados sintéticos para vendas, teste de CRM e conformidade

Um CSV de leads fake é um dos datasets mais reutilizados em qualquer stack de vendas e marketing. O formato Comma-Separated Values (formalizado na RFC 4180 com strings entre aspas, fim de linha CRLF e linha de cabeçalho obrigatória) é a língua franca do Excel, Google Sheets e de qualquer ferramenta de BI, e por isso treinamentos, demos em vídeo e load tests quase sempre começam por um CSV de leads fake — nunca por JSON, nunca por XML. O custo de uma base de leads real é alto: Apollo, ZoomInfo, Lusha e Cognism cobram milhares de dólares por ano, e mesmo assinando você não pode legalmente usar dado real de prospect numa gravação demo ou em um workbook Tableau público.

Leads sintéticos contornam o problema por completo. As colunas espelham o que um CRM típico importa: nome, email, telefone, empresa, cargo, fonte (Google Ads, busca orgânica, referral, evento), interesse (linha de produto ou segmento), score (lead scoring de 0 a 100) e data_captura. Algumas equipes adicionam match score de ICP (Ideal Customer Profile), sinais de intenção e atribuição de last-touch para imitar data warehouses mais ricos.

Onde leads fake são usados

• Treinar SDRs num tour de CRM mock (Salesforce, HubSpot, RD Station, Pipedrive)
• Testar fluxos de automação de marketing em Mailchimp, HubSpot, ActiveCampaign e RD Station
• Popular dashboards de visualização no Tableau, Power BI e Metabase
• Load test de backend de CRM, serviços de lead scoring e receivers de webhook
• Seed de data warehouse para analytics engineers (arquivos CSV via dbt seed)
• Demos e screenshots para decks de sales engineering

LGPD e GDPR: por que sintético ganha de real

Lead é dado pessoal. Sob a LGPD brasileira, o GDPR europeu e o CCPA californiano, basta nome mais email para acionar direitos do titular. Usar dado real de prospect em ambiente de teste, no notebook do dev ou num dashboard público gera exposição difícil de defender. Dado sintético resolve a questão: @example.com, @test.com e @mailinator.com são domínios reservados, números de telefone gerados ficam na faixa documental e nomes vêm de dicionários do Faker.

Bibliotecas Faker: um tour rápido

Em JavaScript, o pacote npm legado faker foi sabotado em 2022 e forkado como @faker-js/faker, que hoje é o padrão da comunidade. Em Python, a biblioteca Faker compete com o Mimesis (este é mais rápido mas tem catálogo menor). Em Ruby vai junto o Faker com o FactoryBot para fixtures. O Faker localizado em pt_BR gera nomes brasileiros, strings com formato de CPF/CNPJ, CEPs válidos e telefones com DDD coerente — importante quando o público da demo é brasileiro e nomes em inglês ficariam fora de tom.

Anti-padrões e ética de outreach

Existe um anti-padrão que volta de tempos em tempos: gerar nomes fake com emails de aparência real e usar a lista como base de prospecção real. Isso é ilegal sob CAN-SPAM, GDPR e LGPD, e o estrago na reputação do domínio remetente é imediato. Email gerado serve para fixture, não para enviar. Se precisa testar deliverability, abra um sandbox no SendGrid, Postmark ou AWS SES e use os endereços de teste oficiais.

Perguntas frequentes

Por que CSV e não JSON? Porque CSV abre no Excel e no Google Sheets sem conversão, importa limpo em qualquer CRM ou ferramenta de BI e sobrevive a copy-paste no chat. JSON é melhor para API, pior para humanos.

Os emails podem receber mensagem? Não. Usam @example.com e outros domínios reservados, e vão dar bounce. Servem só para fixture e demo.

Quantas linhas para load test? Tipicamente 10k para smoke test, 100k para stress test realista e 1M para planejamento de capacidade. Gere em batches e faça streaming do arquivo para disco em vez de bufferizar tudo na memória.

Dá para customizar o schema? Sim. A maioria dos geradores deixa escolher as colunas, adicionar campos custom para indústria, faixa de MRR ou campanha de last-touch e alternar o locale (pt_BR, en_US) dos dicionários de nome e endereço.