Pesquisa de onboarding de usuário — personalize ativação e segmente novo signup

Para quem é este modelo

Uma pesquisa de onboarding é o formulário de intake mais subutilizado do time de produto. Formulários de signup recebem toda a atenção de design — todo time obsessivamente otimiza a matemática de conversão da página de e-mail-e-senha — mas a pesquisa que roda logo depois do signup, a que decide qual template exibe, qual fluxo de onboarding bifurca, qual tooltip aparece, e qual alerta de sales-team dispara por um sinal de ICP enterprise, frequentemente é aparafusada como complemento com qualquer pergunta que alguém propôs no Slack três sprints atrás. Os times de produto que acertam isso (a pergunta "que tipo de trabalho você faz" do Notion, a pergunta de cargo do Linear, a pergunta de cargo e tamanho de time do Figma, a pergunta de stack de dev do Cursor, a pergunta de framework do Vercel) tratam a pesquisa de onboarding como o motor de ativação — as perguntas e a lógica de roteamento são A/B testadas com o mesmo rigor que o formulário de signup, e o dado alimenta personalização de produto, segmentação de CRM, e definição de cohort de product-analytics simultaneamente. Este modelo te dá essa estrutura. Quatro a sete perguntas que mapeiam pra cargo / tamanho de time / jobs-to-be-done / ferramenta anterior / origem, lógica condicional pra que usuário só veja as perguntas relevantes pro caso de uso primário dele, roteamento pro seu stack (Mixpanel / PostHog / Amplitude pra product analytics, RD Station / HubSpot / Salesforce / Pipedrive pra CRM, Segment pra ambos), e a opção de exibir in-app condicionalmente durante a primeira sessão em vez de bloquear ativação.

De finalização do signup à primeira sessão personalizada em menos de 90 segundos

Um usuário completa signup (e-mail/senha, OAuth, ou magic link) e cai na pesquisa de onboarding. A pesquisa tem 4-7 perguntas numa única página, com lógica condicional pra que um usuário que seleciona "engenharia" como cargo veja perguntas de follow-up sobre stack tecnológico enquanto um usuário que seleciona "marketing" veja perguntas de follow-up sobre tipo de campanha. A conclusão leva 60-90 segundos. Ao enviar, as respostas disparam pra três destinos simultaneamente: product analytics (Mixpanel, PostHog, Amplitude, Segment como camada de roteamento) pra segmentação de cohort que informa dashboard de ativação e retenção; CRM (RD Station — dominante pra B2B brasileiro — HubSpot, Salesforce, Pipedrive, Brevo) pra segmentação lado-vendas e workflow de alerta de ICP enterprise quando cargo + tamanho de empresa batem; e personalização in-app (LaunchDarkly, Statsig, PostHog feature flags, ou seu próprio storage de propriedade de usuário) pra controlar qual template exibe, qual fluxo de onboarding bifurca, qual tooltip aparece na primeira sessão. A primeira sessão do usuário reflete a resposta dele imediatamente — um marketing manager numa empresa de 50 pessoas vê a galeria de template de colaboração de time; um engenheiro numa startup de 5 pessoas vê o onboarding de integração de API; um criador solo vê o fluxo de template simples.

O que está incluído

Cada campo abaixo está aqui porque time experiente de produto e growth aprendeu que prevê ativação e retenção. Personalize o conjunto de campos conforme o modelo específico de personalização do seu produto — uma ferramenta B2B de gestão de projeto precisa de cargo + tamanho de time; um app consumidor de fitness precisa de objetivo + nível + frequência; uma ferramenta de dev precisa de stack + nível de experiência — mas resista à tentação de adicionar mais de 7 perguntas porque a taxa de conclusão cai abruptamente além desse limiar.

Feito pras categorias de produto onde a personalização de onboarding move taxa de ativação

• B2B SaaS (o caso de uso dominante)

  Notion, Linear, Figma, Vercel, Stripe, Airtable, Zapier — todo produto B2B SaaS principal tem uma pesquisa de onboarding, porque a experiência de primeira sessão pra um marketing manager é genuinamente diferente da experiência de primeira sessão pra um engenheiro, e rotear eles pra template / tutorial / demo específico de caso de uso diferente sobe taxa de ativação mensuravelmente (tipicamente lift de 10-30% em ativação quando a pesquisa está bem-implementada). Os campos padrão: cargo (Engenheiro / Designer / Produto / Marketing / Vendas / Operações / Founder / Outro), tamanho de time (Só eu / 2-10 / 11-50 / 51-200 / 201-1000 / 1000+), caso de uso primário (o um ou dois caso de uso que seu produto suporta melhor, com texto-aberto pra outlier), ferramenta anterior (qual concorrente ou não-concorrente eles estão deixando — inteligência competitiva crítica), e origem (como ouviram falar — LinkedIn / Twitter / busca Google / indicação / podcast / fonte específica nomeada). Pra B2B SaaS brasileiro (RD Station — líder de marketing automation no Brasil, Pipefy pra workflow, Conta Azul pra gestão financeira de pequena empresa, Bling pra gestão de e-commerce e estoque, Omie, Movidesk e Octadesk pra atendimento, ContaWise, Asaas, ContaAzul, Granatum), o mesmo padrão aplica com opção de cargo e tamanho de time específica de mercado brasileiro.

• App de consumidor com personalização (fitness, finança, aprendizado)

  A categoria onde a pesquisa de onboarding diretamente determina o valor da primeira sessão. A primeira sessão de um app de fitness pra um iniciante fazendo treino de peso corporal em casa deveria parecer completamente diferente da primeira sessão pra um levantador avançado numa academia comercial, e a única forma de saber qual experiência mostrar é perguntar. Campos padrão: objetivo principal (perder peso / ganhar músculo / melhorar resistência / fitness geral — vs. aprender uma habilidade / economizar dinheiro / construir um hábito, dependendo da categoria), nível atual (iniciante / intermediário / avançado), equipamento ou contexto disponível (casa / academia / ar livre; orçamento / avançado; só-smartphone / notebook), frequência que pretende engajar (diariamente / 3-4x semanalmente / semanalmente / ocasionalmente). Pra app de consumidor brasileiro, Smart Fit pelo lado de academia, Gympass (agora Wellhub) pelo lado consumidor, MeuJusVida, Beat Saber e outros apps de fitness pelo lado mobile. Pra fintech brasileira (Nubank com a interface conversacional sendo o estado-da-arte de onboarding consumidor; Inter, C6 Bank, PicPay, BTG Pactual digital, Mercado Pago, Pagbank), a pesquisa de onboarding captura objetivo financeiro e conta existente pra personalizar exibição de feature in-app.

• Marketplaces (casando comprador e vendedor)

  Marketplaces de dois lados precisam de duas pesquisas de onboarding — uma pra comprador, uma pra vendedor — porque os objetivos de ativação diferem inteiramente. Pra vendedor, a pesquisa captura a categoria que está listando, o volume que ele espera, os canais existentes onde vende, a plataforma anterior de onde está saindo (se houver), e a estratégia de pricing. Pra comprador, a pesquisa captura a categoria que está comprando, a faixa de orçamento, a urgência, e a preferência de descoberta. Mercado Livre, Magalu Marketplace, Americanas Marketplace, Shopee Brasil, Amazon Brasil rodam onboarding diferente pra vendedor vs. comprador; Enjoei, OLX rodam pra ambos os lados; Hotmart, Eduzz, Kiwify pra criador-de-curso vendedor vs. comprador-de-curso. A categoria de marketplace B2B (Olist agregando varejista pra venda em marketplace, GetNinjas pra serviço, Workana pra freelancer) similarmente roda pesquisa de onboarding separada pra lado-comprador e lado-vendedor.

• Ferramenta de dev (cargo técnico + stack + caso de uso)

  Vocabulário diferente do B2B SaaS. Pesquisa de onboarding de ferramenta de dev captura cargo (backend / frontend / full-stack / devops / ML / data / security), linguagem e framework primário (TypeScript / Python / Go / Rust / Java; React / Next.js / Vue / Svelte), o contexto de cloud e infraestrutura (AWS / GCP / Azure / Vercel / Fly.io / Railway / self-hosted), e o caso de uso (CI/CD / monitoramento / banco de dados / autenticação / cliente API / feature de IDE). Pra ferramenta moderna de dev de IA (Cursor, Windsurf, Continue, Cline, Aider, Anthropic Claude Code), a pesquisa também captura conforto-com-IA / modelo-preferido / tamanho-de-empresa-pra-elegibilidade-de-tier-pro. Vercel, Stripe, Twilio, Datadog, PostHog, Linear todos rodam variante afinada pra audiência específica deles de dev. Pra ferramenta de dev com presença no Brasil, capturar o idioma de comentário de código e documentação que o dev escreve (português, inglês, mistura) ajuda a personalizar a amostra e a documentação in-app — e capturar se o dev brasileiro está trabalhando pra time brasileiro ou pra time internacional ajuda a calibrar a sugestão de feature.

• SaaS vertical (produto específico de indústria)

  Onboarding pra SaaS vertical captura o sub-setor vertical, o workflow específico que o cliente quer automatizar ou melhorar, e o contexto de integração pras ferramentas dominantes nesse vertical. Um SaaS vertical pra restaurante captura tipo de culinária / capacidade / PDV atual (Stone POS, Linx, Sischef, Saipos, ConsumerNet pra Brasil) / intent de integração; um SaaS vertical pra clínica captura especialidade / volume de paciente / prontuário eletrônico atual (Tasy/Philips, MV, Memed, iClinic, Doctoralia EHR, Conexa Saúde pra telemedicina) / escopo de conformidade (LGPD pra Brasil, ANS pra plano de saúde, CFM pra ética médica); um SaaS vertical pra construção captura ofício / tamanho de empresa / ferramenta atual de gestão de projeto (Sienge, Builders 360, Construmanager pra construtora brasileira). O contexto vertical deixa a pesquisa de onboarding fazer pergunta muito mais precisa que um produto horizontal, e o dado alimenta priorização do time de produto específica do vertical.

• Produtos de IA (caso de uso + conforto + intent de integração)

  A categoria onde pesquisa de onboarding mais cresceu desde 2022. Onboarding de produto de IA captura o caso de uso principal do usuário (escrita / código / pesquisa / atendimento ao cliente / geração de imagem / geração de vídeo / agente / análise de dado), o conforto dele com prompting de IA (novato / intermediário / avançado), o intent de integração dele (API pra desenvolvimento / web app pra uso / extensão de navegador / app mobile), e o stack de IA existente (ChatGPT / Claude / Gemini / open-source local / deployment específico de empresa). Pra produto de IA enterprise, a pesquisa também captura tamanho de empresa + setor + escopo de conformidade (porque conformidade de IA — LGPD pra Brasil, GDPR, EU AI Act com sua classificação de tier — varia significativamente por setor). Pra produto de IA brasileiro (a onda de startup brasileira de IA desde 2023 — wrapper brasileiro de modelo foundation, ferramenta de IA pra setor jurídico como JusBrasil expandindo, ferramenta de IA pra setor médico como Memed AI-adjacent), a pesquisa captura caso de uso específico em português e o conforto com code-switching entre português e inglês em workflow de IA — porque modelo foundation principal performa melhor em inglês mas o usuário brasileiro frequentemente quer output em português.

Ajuste a pesquisa pro modelo de personalização do seu produto

Comece com o conjunto de 4-7 perguntas. A pesquisa de onboarding mínima útil são 4 perguntas (cargo / tamanho de time / caso de uso / origem); o máximo que mantém taxa aceitável de conclusão são 7. Além de 7, a conclusão cai abruptamente e as respostas que você recebe são enviesadas pra usuário com motivação incomumente alta de completar. Cada pergunta deveria mapear pra uma decisão de personalização ou roteamento downstream — não pergunte uma pergunta cuja resposta seu produto não usa. Use lógica condicional pra que usuário só veja as perguntas relevantes pro caso de uso primário dele (um engenheiro vê pergunta de stack, um marqueteiro vê pergunta de tipo de campanha). Decida se a pesquisa é obrigatória ou opcional. Pesquisa obrigatória gateia acesso ao app até completar — entrega maior qualidade de dado mas menor taxa de ativação (uma pequena porcentagem de usuário abandona na pesquisa). Pesquisa opcional aparece condicionalmente durante a primeira sessão e deixa usuário pular — entrega menor taxa de conclusão (40-70% típico) mas sem perda de ativação. A maior parte dos times usa obrigatória pra B2B SaaS onde o trade-off de ativação é aceitável pelo ganho de personalização; opcional pra app consumidor onde ativação importa mais que completude de dado. Roteie as respostas pra três destinos simultaneamente: product analytics, CRM (RD Station como destino dominante pra B2B brasileiro), e personalização in-app. Traduza a pesquisa pros idiomas da sua audiência — versão português brasileiro pra produto com base de usuário brasileira crescente sobe taxa de conclusão 20-40% nesse segmento.

Perguntas frequentes sobre a pesquisa de onboarding de usuário

Modelos relacionados