Todo time de produto está cercado de respostas que nunca coleta. O usuário que abandonou a configuração no meio do caminho sabe exatamente o que o fez parar. O cliente que cancelou no último trimestre poderia ter apontado, em uma frase, a funcionalidade que faltava. O power user que, discretamente, faz algo engenhoso com a sua função de exportação adoraria contar isso para você. Nenhum deles vai mandar um e-mail, mas um número surpreendente deles vai responder a uma pergunta, agora mesmo, se ela aparecer onde eles já estão e levar quatro segundos.
Essa é toda a proposta da pesquisa in-app: trocar tamanho por timing. Você abre mão do questionário de dez perguntas e ganha, em troca, feedback de pessoas que estão vivendo a experiência, e não tentando se lembrar dela, coletado no momento exato em que ela acontece e vindo de toda a base, não só da minoria barulhenta que abre e-mails de pesquisa.
Este guia cobre o tema de ponta a ponta: o que é uma pesquisa in-app e como ela se diferencia da sua prima por e-mail, os seis tipos que vale a pena aplicar em um produto SaaS, a anatomia de uma micropesquisa que as pessoas realmente respondem, quando disparar cada pesquisa e quando ficar em silêncio, 30 modelos de perguntas que você pode copiar direto, oito boas práticas para manter as taxas de resposta altas e como conduzir todo o programa sem escrever código.
Principais aprendizados
- No timing, o in-app ganha do e-mail. A mesma pergunta feita dentro do produto, logo depois da experiência, coleta mais respostas, e respostas mais precisas, do que a versão que chega por e-mail dois dias depois.
- O formato é uma pergunta. Uma micropesquisa é uma pergunta mais um follow-up aberto opcional. Cada pergunta adicional custa respostas mais rápido do que gera insights.
- Seis tipos cobrem tudo: NPS, CSAT, CES, product-market fit, feedback de funcionalidade e pesquisas de saída. Mantenha uma pesquisa relacional rodando continuamente e duas ou três transacionais nos pontos de decisão.
- Dispare por eventos, nunca por timers. Pergunte depois de uma ação concluída, nunca no meio de uma tarefa, nunca durante as etapas de onboarding, nunca enquanto o usuário está corrigindo um erro.
- O valor está no follow-up aberto. A nota diz que algo está errado; o campo "qual é o principal motivo da sua nota?" diz o quê.
- Limite a frequência e feche o ciclo. Uma pesquisa por usuário por mês, e sempre mostre o que mudou porque as pessoas responderam; a taxa de resposta da segunda rodada depende de como você tratou a primeira.
O que é uma pesquisa in-app? (Definição e significado)
Uma pesquisa in-app é um questionário curto apresentado aos usuários dentro do próprio produto, enquanto eles o usam. Normalmente ela assume a forma de um card deslizante em um canto da tela, de uma barra fina no topo ou no rodapé, ou de uma pequena janela centralizada, e faz uma pergunta, às vezes duas. É disparada por algo que o usuário fez, e não por um calendário, e é respondida com um clique, sem sair da página.
Definição de pesquisa in-app. Um microquestionário entregue dentro de um produto, disparado pelo comportamento do usuário e pensado para ser respondido em segundos, sem interromper a tarefa em andamento. Sua característica definidora é o contexto: a pergunta chega enquanto a experiência de que ela trata ainda está acontecendo, então a resposta descreve a realidade, e não uma lembrança.
Esse formato costuma ser confundido com outros métodos de coleta de feedback. Cada um captura algo diferente:
| Método | Onde fica | No que é bom | Ponto fraco |
|---|---|---|---|
| Pesquisa in-app | Dentro do produto, disparada pelo comportamento | Alta taxa de resposta, precisão em contexto, iteração rápida | Espaço para só uma ou duas perguntas |
| Pesquisa por e-mail | Na caixa de entrada, dias depois | Tamanho: dá para fazer dez perguntas | Poucas respostas, viés de memória, amostra autosselecionada |
| Widget de feedback | Um botão fixo na interface | Captar relatos espontâneos, sem que ninguém peça | Só ouve usuários motivados o bastante para clicar |
| Entrevista com usuários | Uma conversa agendada | Profundidade, perguntas de follow-up, o "porquê por trás do porquê" | Amostra minúscula, cara e lenta |
| Analytics de produto | Dados de eventos | O que os usuários fizeram, na escala de toda a base | Nunca diz por que fizeram |
A última linha é a mais importante. Seu analytics de produto pode mostrar que 40% dos usuários em trial travam na mesma tela; só uma pergunta feita nessa tela diz se a causa é uma integração que falta, um rótulo confuso ou um preço que os usuários não esperavam. Os dados de comportamento estreitam a busca; as pesquisas in-app a encerram. Usados juntos, eles formam um ciclo: o analytics encontra a anomalia, uma micropesquisa a explica e a correção volta a ser medida no analytics.
Por que as pesquisas in-app superam as pesquisas por e-mail
Os argumentos para perguntar dentro do produto, em cinco partes:
-
Elas perguntam enquanto a experiência ainda está fresca
A memória se apaga rápido e se reescreve mais rápido ainda. Se você perguntar na sexta-feira como foi a configuração de terça, o usuário vai relatar uma versão suavizada e arrumada da verdade. Se perguntar trinta segundos depois de ele terminar a configuração, ele vai contar qual campo específico o confundiu, porque esse campo ainda está na tela, atrás da pesquisa.
-
Elas alcançam a maioria silenciosa, não a minoria barulhenta
Pesquisas por e-mail são respondidas por quem ama você e por quem está furioso com você. Todo mundo no meio, onde está a maior parte da sua receita, apaga o e-mail. Uma pergunta in-app não exige ir até a caixa de entrada nem motivação especial, então ela captura o usuário comum, cuja opinião comum é justamente a que está faltando para você.
-
Elas podem ser segmentadas com precisão cirúrgica
Você pode fazer uma pergunta exatamente aos usuários que usaram a funcionalidade X duas vezes na semana passada, estão no plano Pro e no segundo mês de uso. Esse tipo de segmentação transforma um genérico "como estamos indo?" em uma pergunta específica com uma resposta acionável, e é por isso que a segmentação importa tanto para as pesquisas quanto para o onboarding.
-
Elas fecham o ciclo rápido o bastante para fazer diferença
Lance uma mudança na segunda-feira e veja se as respostas à pergunta mudam até quinta. As pesquisas in-app transformam o feedback em um instrumento contínuo, e não em um evento trimestral, e essa é a diferença entre medir o seu produto e pilotá-lo.
Essas mesmas qualidades fazem com que seja fácil abusar das pesquisas in-app. Como são baratas de lançar e impossíveis de ignorar, elas se multiplicam: o NPS de um time, a enquete de funcionalidade de outro, a pesquisa de saída de um terceiro, todas disparando para o mesmo usuário cansado. Cada pedido indesejado gasta uma confiança de que você vai precisar mais tarde. Trate as exibições de pesquisa como um orçamento escasso, compartilhado e com um dono, ou a sua taxa de resposta vai cair por motivos que nenhuma pesquisa isolada consegue explicar.
Os 6 tipos de pesquisa in-app (e quando usar cada um)
As pesquisas se dividem em duas famílias. As pesquisas relacionais medem o que os usuários sentem em relação ao produto como um todo e rodam continuamente em uma amostra rotativa. As pesquisas transacionais medem uma interação específica e são disparadas logo depois dela. Você precisa das duas, e precisa saber qual é qual; é misturando as duas que os times acabam com uma nota NPS que oscila por motivos que ninguém consegue rastrear.
| Tipo | Família | A pergunta que ela faz | Melhor gatilho |
|---|---|---|---|
| NPS | Relacional | Qual a probabilidade de você nos recomendar? (0–10) | Aos ~30 dias de uso, depois uma vez por trimestre por usuário |
| CSAT | Transacional | Qual é o seu nível de satisfação com isso? (1–5) | Imediatamente após uma interação específica |
| CES | Transacional | Quão fácil foi fazer X? (1–7) | Logo após a conclusão de uma tarefa |
| Product-market fit | Relacional | Quão decepcionado você ficaria sem nós? | Usuários com duas semanas ou mais de uso real |
| Feedback de funcionalidade | Transacional | Esta funcionalidade faz o que você precisava? | No segundo ou terceiro uso dessa funcionalidade |
| Saída / cancelamento | Transacional | O que fez você decidir sair? | Na intenção de cancelar ou no abandono de um fluxo |
1. NPS: a linha de tendência da lealdade
Uma pergunta, uma escala de 0 a 10 e um follow-up aberto. O Net Promoter Score é mais bem entendido não como um número a otimizar, mas como uma tendência a acompanhar e uma máquina de gerar comentários em texto livre. Aplique-o em uma amostra rotativa, para que uma parte da sua base o veja a cada mês em vez de todo mundo de uma vez, e nunca pesquise o mesmo usuário mais de uma vez por trimestre.
2. CSAT: a satisfação com uma coisa específica
A pergunta "Qual é o seu nível de satisfação com isso?", em uma escala de 1 a 5, disparada imediatamente depois da interação a que se refere: uma conversa com o suporte, uma importação, a exportação de um relatório. O CSAT é estreito por definição, e é exatamente por isso que as respostas dele são acionáveis. Se o CSAT do seu importador de CSV está em 3,1 enquanto todo o resto está em 4,4, você encontrou a sua próxima sprint.
3. CES: quanto esforço isso exigiu?
O Customer Effort Score pede aos usuários que avaliem quão fácil foi uma tarefa, geralmente em uma escala de concordância de sete pontos ("O produto facilitou a conclusão de X"). O esforço prevê o churn melhor do que o encantamento: os usuários raramente vão embora porque um produto não era encantador; vão embora porque ele era cansativo. Dispare o CES depois das tarefas que entregam o seu valor: a configuração, o primeiro convite, a primeira exportação bem-sucedida.
4. Product-market fit: a pergunta do "muito decepcionado"
"Como você se sentiria se não pudesse mais usar este produto?", com três opções: muito decepcionado, um pouco decepcionado, nada decepcionado. A parcela que responde "muito decepcionado" é uma leitura direta e honesta sobre se o seu produto é uma necessidade ou só um nice-to-have, e o follow-up em texto livre desse grupo diz para qual segmento você deve construir. Só pesquise usuários com uso real no histórico; perguntar a quem está no primeiro dia de trial só gera ruído.
5. Feedback de funcionalidade: a micropesquisa com a melhor taxa de acerto
A mais subestimada das seis e, muitas vezes, a mais útil. Depois que um usuário tiver usado uma funcionalidade específica duas ou três vezes, faça uma pergunta sobre ela: se faz o que ele esperava, o que está faltando, se ele a recomendaria. Como o contexto é extremamente preciso, as respostas já chegam praticamente organizadas como itens de backlog. Combine com o trabalho de descoberta de funcionalidades: uma funcionalidade com pouco uso e alta satisfação tem um problema de descoberta, não de qualidade.
6. Pesquisas de saída: a lição cara, registrada
São disparadas quando o usuário demonstra intenção de cancelar ou abandona um fluxo crítico, com uma lista curta de motivos predefinidos mais "outro". Limite tudo a uma tela e um clique; um usuário que está de saída não vai preencher um formulário. O valor não está em salvar esse usuário: está no fato de que cinquenta respostas de saída ao longo de um trimestre vão apontar os seus dois principais motivos de churn com mais clareza do que qualquer análise de comportamento jamais conseguiria.
A anatomia de uma micropesquisa que as pessoas realmente respondem
Uma pesquisa que é respondida é uma pequena máquina com cinco peças. Erre qualquer uma delas e a taxa de resposta despenca de um jeito que as outras não conseguem compensar:
Uma micropesquisa tem cinco partes: um gatilho baseado em evento, uma pergunta, uma resposta em um clique, um follow-up aberto opcional e uma saída elegante que se lembra de que foi usada.
1. O gatilho: um evento, não um timer
A pesquisa é disparada porque o usuário acabou de fazer algo: concluiu o onboarding, exportou um relatório, usou uma funcionalidade pela terceira vez, clicou em cancelar. "Cinco segundos depois de a página carregar" não é um gatilho, é uma emboscada: o usuário ainda não fez nada, então não há sobre o que ter opinião.
2. A pergunta: uma só, específica e neutra
"Quão fácil foi criar o seu primeiro relatório?" é melhor do que "O que você está achando da nossa nova experiência de relatórios?": a primeira dá para responder, a segunda é um estado de espírito. Evite formulações tendenciosas ("O quanto você gostou de…"), evite perguntas duplas ("Quão rápido e preciso foi…") e evite perguntar sobre coisas que o usuário não fez.
3. A resposta: um clique para responder
Comece com uma escala, um conjunto de opções ou polegares para cima e para baixo, nunca com um campo de texto em branco. Uma caixa de texto como primeira interação pede que o usuário escreva antes mesmo de ter decidido participar, e a maioria não vai escrever. Depois que ele clica em alguma coisa, a psicologia se inverte: ele já se comprometeu, e o follow-up é digitado.
4. O follow-up aberto: onde o valor realmente está
A nota é um termômetro; a resposta em texto livre é um diagnóstico. Sempre faça um follow-up aberto depois do clique ("Qual é o principal motivo da sua nota?"), sempre o deixe opcional e sempre leia, uma por uma, as primeiras cem respostas. Times que só acompanham o número perdem todo o sentido de ter perguntado.
5. A saída: fácil de dispensar, e para sempre
Um botão de fechar visível, e uma pesquisa que o respeita: dispensada significa que sumiu para aquele usuário, naquela pesquisa, e não que sumiu até amanhã. Qualquer outra coisa transforma um pedido em insistência, e é insistindo que você perde também a próxima pesquisa, a mesma lição que vale para toda mensagem in-app que você envia.
Timing: quando perguntar e quando ficar em silêncio
Duas versões da mesma pesquisa, na mesma tela. A única diferença é o momento escolhido, e essa diferença vale mais do que todo o capricho do mundo na redação da pergunta:
A pesquisa da esquerda será dispensada por quase todo mundo que a vir, e ainda vai tornar a próxima pesquisa mais fácil de dispensar. A da direita é respondida com um clique por um usuário que acabou de sentir algo que vale a pena relatar. Mesmo produto, mesmo time, a mesma pergunta no fundo: um conjunto de dados completamente diferente.
As regras de timing que mais importam:
- Espere o usuário pegar o jeito. Ninguém consegue avaliar um produto que não usou. Pesquisas relacionais vêm depois do momento aha, não antes, normalmente entre duas e quatro semanas de uso, e nunca durante a primeira sessão.
- Dispare na conclusão, não na interrupção. O momento depois que uma tarefa termina é uma pausa natural. O momento durante a tarefa não é, e uma pesquisa ali custa a você tanto a resposta quanto a tarefa.
- Nunca pesquise dentro de um fluxo crítico. Checkout, etapas de onboarding, recuperação de erros, cobrança. Jamais. Uma pesquisa que custa uma conversão é o feedback mais caro que você vai coletar na vida.
- Limite a frequência de forma global. Uma pesquisa por usuário por mês, somando todos os times, com exclusão obrigatória de quem respondeu nos últimos 30 dias. O limite de frequência é, sozinho, a configuração de maior alavancagem em um programa de pesquisas.
- Use amostras, não a base inteira. Uma amostra rotativa de 20% do segmento elegível entrega a mesma linha de tendência com um quinto do custo de atenção, e ainda preserva um grupo de controle limpo.
30 perguntas para pesquisas in-app que geram respostas
Agrupadas pelo que você quer descobrir. Use-as do jeito que estão ou como ponto de partida, mas sempre uma de cada vez.
Onboarding e primeira experiência
- Quão fácil foi fazer a configuração inicial? (1–5)
- O que quase impediu você de concluir a configuração?
- O que você esperava conseguir quando se cadastrou?
- Alguma coisa ficou confusa nas últimas etapas?
- Quanto tempo você esperava que a configuração levasse, e quanto tempo ela levou de fato?
- Se você pudesse mudar uma coisa para deixar isso mais rápido, qual seria?
Ativação e valor
- O produto já trouxe valor para você? (Sim / Ainda não / Não tenho certeza)
- Para que você usa principalmente o nosso produto?
- O que impede você de usar isso com mais frequência?
- Como você se sentiria se não pudesse mais usar este produto?
- O que quase fez você desistir na primeira semana?
- O que você usava antes, e o que fez você trocar?
Feedback de funcionalidade
- Esta funcionalidade faz o que você esperava? (Sim / Em parte / Não)
- O que está faltando nesta funcionalidade?
- Com que frequência você pretende usar isso? (Diariamente / Semanalmente / Raramente)
- O que você tentou fazer aqui e não conseguiu?
- Se removêssemos isso amanhã, o que você usaria no lugar?
- Quão fácil foi encontrar isso? (1–5)
Satisfação, esforço e lealdade
- Qual é o seu nível de satisfação com isso? (1–5)
- O produto facilitou a conclusão desta tarefa. (1–7, discordo/concordo)
- Qual a probabilidade de você nos recomendar a um colega? (0–10)
- Qual é o principal motivo da sua nota?
- O que poderíamos fazer para merecer uma nota maior?
- Como isso se compara ao que você esperava? (Melhor / Como esperado / Pior)
Churn, saída e abandono
- O que levou você a decidir cancelar?
- O que poderíamos ter feito para você ficar?
- Qual destas opções descreve melhor o motivo da sua saída? (opções + outro)
- Você está migrando para outra solução ou parando de vez?
- O que impediu você de concluir agora há pouco?
- Você consideraria voltar se resolvêssemos isso? (Sim / Não / Talvez)
Higiene de perguntas em uma linha: pergunte sobre algo que o usuário acabou de fazer, com as palavras que ele mesmo usaria, sem nenhum adjetivo que sugira a resposta que você quer. Se uma pergunta pode ser respondida com "bom, depende", ela precisa ser mais específica.
Boas práticas de pesquisas in-app: 8 regras
1. Sempre uma pergunta: conquiste o direito à segunda
Comece com uma única pergunta e um follow-up aberto opcional. Se você está convencido de que precisa de uma terceira, aplique primeiro a versão de uma pergunta só e veja quanto você aprende; a maioria dos times descobre que as perguntas extras geravam dados que ninguém usava. O tamanho é o imposto que você paga sobre cada resposta que vai coletar.
2. Segmente com precisão, para que as respostas sejam úteis
"Todo mundo" não é um público. Pesquise um segmento definido (usuários em trial na segunda semana, admins que configuraram uma integração, usuários que usaram o novo editor duas vezes) e as respostas já chegam vinculadas a uma decisão. Pesquisas amplas geram médias; pesquisas segmentadas geram sprints.
3. Faça a pergunta na tela a que ela se refere
O feedback sobre o criador de relatórios deve ser pedido no criador de relatórios, instantes depois de um relatório ser criado. O contexto faz metade do trabalho da pergunta: o usuário não precisa se lembrar de nada, e os olhos dele já estão naquilo sobre o que você está perguntando.
4. Torne o fechamento fácil e definitivo
Um "Agora não" claro, que signifique de fato agora não. Botões de fechar escondidos ou que demoram a aparecer rendem algumas respostas forçadas e custam a credibilidade de todos os pedidos futuros. Respeitar o "agora não" do usuário é a forma mais barata de comprar confiança.
5. Nunca interrompa o dinheiro nem o embalo
Nada de pesquisas durante o checkout, o upgrade, as etapas de onboarding ou estados de erro. A regra vale mesmo quando a tentação é maior, principalmente nessa hora, porque uma pesquisa em uma tela de erro soa como um produto pedindo aplausos enquanto pega fogo.
6. Leia os comentários, classifique com tags e conte as tags
As respostas abertas são onde está o valor, mas só se alguém as processar. Classifique cada resposta em um conjunto pequeno e estável de temas (preço, funcionalidade ausente, confusão, desempenho, bug) e acompanhe a contagem de cada tag ao longo do tempo. Um tema em alta é um item de roadmap com evidências anexadas, muito mais persuasivo do que uma média.
7. Feche o ciclo, de forma visível
Quando você lançar algo que uma pesquisa pediu, avise: nas release notes, em um anúncio in-app ou em uma resposta para a pessoa que sugeriu. "Você pediu, nós lançamos" é a forma mais eficaz de impedir que as taxas de resposta caiam, porque prova que responder não é falar para as paredes.
8. Trate a taxa de resposta como uma métrica de saúde
Acompanhe-a por pesquisa e no agregado. Taxas de resposta em queda costumam significar que você está perguntando com frequência demais, de forma ampla demais ou cedo demais, e não que os usuários deixaram de se importar. Faça uma limpeza nas suas pesquisas como faria com qualquer outro elemento in-app: se uma pesquisa não mudou nenhuma decisão em dois trimestres, aposente-a e devolva essa atenção aos usuários.
Pesquisas in-app: o que fazer e o que evitar
✅ Faça
- Pergunte uma coisa só, com um follow-up aberto opcional
- Dispare após uma ação concluída, em contexto
- Segmente para um grupo restrito e bem definido
- Comece com uma escala de um clique, não com uma caixa de texto
- Limite a frequência somando todos os times: uma por usuário por mês
- Use uma porcentagem rotativa como amostra, em vez de todo mundo
- Classifique e conte as respostas em texto livre
- Conte aos usuários o que mudou graças às respostas deles
❌ Evite
- Lançar um formulário de seis perguntas em um modal
- Disparar com um timer de carregamento de página, sem nenhum evento por trás
- Pesquisar durante o checkout, o onboarding ou um erro
- Pedir a usuários do primeiro dia que avaliem um produto que ainda não usaram
- Reexibir uma pesquisa que o usuário já dispensou
- Usar formulações tendenciosas ou perguntas duplas
- Coletar comentários que ninguém nunca lê
- Deixar cada time rodar a própria pesquisa sem coordenação
Como aplicar pesquisas in-app sem escrever código
Tudo o que vimos acima (gatilhos por evento, segmentação, limites de frequência, memória de dispensa por usuário, analytics das respostas) exige um bom volume de engenharia se você construir por conta própria, e é o tipo de engenharia que nunca chega ao topo do backlog. Com a Kompassify, a camada de pesquisas roda por cima do seu produto atual, sem código:
- Monte a pesquisa visualmente. Escolha o tipo de pesquisa (uma nota NPS ou uma pergunta de múltipla escolha), escreva a pergunta, escolha a escala e adicione o follow-up aberto. Sem ciclo de release, sem ticket para o front-end.
- Dispare com base no comportamento real. Exiba a pesquisa depois de uma ação específica, em uma página escolhida, para um segmento escolhido: os usuários que acabaram de concluir o onboarding, os admins do plano Pro, as pessoas que usaram a nova funcionalidade duas vezes.
- Frequência e dispensa já resolvidas. O estado por usuário garante que uma pesquisa dispensada continue dispensada e que quem respondeu recentemente não seja questionado de novo; a boa educação vem embutida, em vez de ser reimplementada a cada pesquisa.
- Veja as respostas ao lado do comportamento. As respostas chegam ao mesmo analytics dos seus tours de produto e checklists, então cada nota vem sempre acompanhada da jornada que a gerou.
- Feche o ciclo no mesmo lugar. Lance a correção e depois anuncie exatamente para os usuários que pediram: pesquisa, anúncio e tour a partir de um único editor e um único snippet.
A Kompassify está em conformidade com o GDPR, é hospedada na UE, é gratuita para menos de 100 usuários ativos mensais e tem planos pagos a partir de US$ 129/mês.
Pergunte aos seus usuários, dentro do seu produto
Com a Kompassify, você cria pesquisas in-app, tours de produto, tooltips e checklists de onboarding por cima do seu produto atual, sem código e sem ciclo de release. Dispare a pergunta certa no momento certo, leia as respostas ao lado do comportamento que as gerou e lance a correção a partir do mesmo lugar. Em conformidade com o GDPR, hospedada na UE e gratuita para menos de 100 usuários ativos mensais.
Comece grátis →Perguntas frequentes
O que é uma pesquisa in-app?
Uma pesquisa in-app é um questionário curto exibido aos usuários dentro do produto, enquanto eles o usam, em vez de ser enviado por e-mail depois. Ela costuma aparecer como um pequeno card deslizante, uma barra ou um modal leve, faz uma ou duas perguntas e é disparada por algo que o usuário acabou de fazer: concluir o onboarding, usar uma funcionalidade pela terceira vez, esbarrar em um erro. Como chega em contexto e leva segundos para ser respondida, uma pesquisa in-app normalmente coleta muito mais respostas do que a mesma pergunta enviada por e-mail, e as respostas são mais precisas: o usuário descreve uma experiência que está vivendo, não uma que está tentando lembrar.
Qual é a diferença entre uma pesquisa in-app e uma pesquisa por e-mail?
Contexto e timing. Uma pesquisa por e-mail chega ao usuário horas ou dias depois, em outra ferramenta, e pede que ele se lembre de como foi a experiência, por isso coleta menos respostas, concentradas em pessoas com opiniões fortes. Uma pesquisa in-app alcança o usuário no exato momento em que a experiência acontece, dentro do produto, com um clique. A contrapartida é o tamanho: o e-mail tolera dez perguntas, o in-app tolera uma ou duas. Essa restrição é uma vantagem, não uma limitação: uma única pergunta feita no momento certo e respondida por muitos usuários vale mais do que um questionário longo respondido por poucos.
Que tipos de pesquisa in-app um produto SaaS deve aplicar?
Seis tipos cobrem quase tudo. O NPS mede a lealdade geral e fornece uma linha de tendência. O CSAT mede a satisfação com uma interação específica. O CES mede o quanto uma tarefa pareceu difícil. As pesquisas de product-market fit perguntam quão decepcionados os usuários ficariam sem o produto. As micropesquisas de feedback de funcionalidade perguntam sobre uma única funcionalidade logo depois que ela é usada. As pesquisas de saída perguntam por que alguém está cancelando ou abandonando um fluxo. A maioria dos times deve começar com uma pesquisa relacional (NPS ou PMF) rodando continuamente em uma amostra de usuários e acrescentar micropesquisas transacionais nos dois ou três momentos do produto em que há uma decisão real a tomar.
Quando disparar uma pesquisa in-app?
Depois de uma ação concluída, nunca antes nem durante. As regras que importam: espere até o usuário ter experiência suficiente para ter uma opinião (normalmente depois do momento aha, não no primeiro dia), dispare a partir de um evento e não de um timer, nunca interrompa uma tarefa em andamento e nunca dispare durante o checkout, as etapas de onboarding ou a recuperação de um erro. Uma pesquisa exibida para alguém no meio de uma tarefa não é apenas dispensada: ela ensina ao usuário que as suas mensagens são ruído, e você paga esse preço em todas as mensagens futuras também.
Qual deve ser o tamanho de uma pesquisa in-app?
Uma pergunta, mais um follow-up aberto e opcional. Esse é o formato que funciona. Cada pergunta extra custa respostas, e a queda entre a primeira e a quinta pergunta é tão acentuada que uma pesquisa in-app de cinco perguntas costuma coletar, no total, menos sinal do que uma de uma pergunta só. Se você realmente precisa de mais, faça a primeira pergunta no app para obter a nota e depois convide o pequeno grupo que aceitou participar para uma conversa mais longa em outro canal. O in-app serve para medir o pulso; as entrevistas, para ir a fundo.
Qual é uma boa taxa de resposta para pesquisas in-app?
Micropesquisas in-app bem segmentadas costumam alcançar taxas de dois dígitos, contra taxas baixas de um dígito para a mesma pergunta por e-mail, mas o número depende muito mais da segmentação e do timing do que da pergunta em si. Em vez de perseguir um benchmark, acompanhe a sua própria tendência: se a taxa de resposta cai a cada nova rodada, você está pesquisando as mesmas pessoas com frequência demais ou perguntando no momento errado. Limite a frequência (uma pesquisa por usuário por mês é um teto comum), trabalhe com amostras em vez de atingir todo mundo e sempre exclua os usuários que responderam recentemente.
Como adicionar pesquisas in-app sem programar?
Com uma plataforma no-code como a Kompassify, você monta a pesquisa visualmente, escolhe o tipo de pesquisa (uma nota NPS ou uma pergunta de múltipla escolha), define o evento de gatilho e o segmento de público, configura limites de frequência e publica direto no seu produto em produção, sem precisar de release. As respostas chegam ao analytics integrado, ao lado dos seus tours de produto, checklists e anúncios, para que você veja a nota junto com o comportamento que a gerou. A Kompassify está em conformidade com o GDPR, é hospedada na UE, é gratuita para menos de 100 usuários ativos mensais e tem planos pagos a partir de US$ 129/mês.