Feedback in-app que as pessoas realmente respondem

Feedback in-app é uma pergunta feita dentro do seu próprio produto, num momento que você escolhe, para um usuário que você já consegue identificar. Esse controle é toda a vantagem sobre qualquer outro canal, e é também o motivo de um aviso mal cronometrado causar mais dano do que nenhum aviso.

Um app móvel sabe algo que nenhuma pesquisa por email vai saber: exatamente o que a pessoa estava fazendo um segundo antes de a pergunta aparecer. Usar isso bem é a diferença entre um aviso que devolve sinal de produto e outro que devolve uma avaliação de uma estrela. O desenho de perguntas em geral está em como criar uma pesquisa online; este guia trata da tela pequena e da nota pública que você pode estragar.

Feedback não é o aviso de avaliação da loja

Se você levar só uma coisa deste artigo, leve esta. A pesquisa in-app e o aviso de avaliação da loja são dois mecanismos diferentes com duas tarefas diferentes, e confundir os dois é o erro mais comum dos times de mobile.

O aviso de avaliação é o diálogo do sistema operacional, solicitado via StoreKit no iOS ou pela In-App Review API no Android. A plataforma, e não o seu app, decide se ele aparece, e os dois fabricantes limitam quantas vezes um usuário o vê. O resultado é uma nota pública que você não consegue ler antes, nem responder em privado, nem acompanhar. A pesquisa in-app é sua: aparece quando você manda, pergunta o que você escreveu, e a resposta chega em privado com o contexto que você anexou, então dá para ramificar, encaminhar e responder.

A falha típica é ligar o aviso da loja num lugar onde na verdade se queria coletar informação. Um engenheiro adiciona o diálogo porque são quatro linhas de código, e o produto passa a ter um gerador de notas apontado para uma amostra aleatória de usuários, incluindo quem acabou de falhar um pagamento. A cota piora tudo, porque cada aviso gasto em alguém irritado é um promotor que você não vai mais alcançar. Nunca dispare o aviso da loja a partir de um sinal negativo ou desconhecido. Qualifique antes com a sua própria pergunta e ofereça o caminho da loja só a quem acabou de dizer que está satisfeito.

Quando perguntar

O timing faz mais pela taxa de resposta in-app do que redação, design e incentivos somados. O princípio por trás de todo bom momento é o mesmo: pergunte quando o usuário acabou de terminar algo e não tem mais nada nas mãos.

O momento mais forte é a tela de sucesso: o pagamento passou, o arquivo foi exportado, a corrida terminou, a fase foi concluída. A atenção sai de graça porque a tarefa acabou, e a lembrança do fluxo está intacta. Pergunte um ou dois segundos depois de essa tela aparecer, não três telas adiante.

O segundo é um marco, não uma ação: a sétima sessão, o fim da primeira semana, a primeira renovação. Marcos combinam com perguntas sobre o produto como um todo, são a casa natural de uma pesquisa de pulso periódica e garantem que a pessoa já tenha experiência para ter opinião. O terceiro é um atendimento resolvido, o gatilho mais limpo que existe porque a experiência avaliada tem um limite óbvio, e onde uma pergunta de esforço da família do customer effort score ganha de uma de satisfação.

Os momentos ruins ensinam mais. Nunca pergunte na abertura do app. Um aviso na inicialização interrompe alguém que chegou com uma intenção e ainda não fez nada, então não há sobre o que dar feedback. Isso produz taxas baixas, sentimento ruim e às vezes justamente a desinstalação que você tentava evitar. Uma sessão aberta a partir de uma notificação push é o mesmo caso: a notificação já gastou o seu orçamento de interrupção.

Nunca pergunte no meio de uma tarefa. Nem durante o checkout, nem sobre um formulário pela metade, nem durante uma partida ou um vídeo. Interromper algo inacabado custa em dobro: um descarte em vez de uma resposta, e mais chance de a tarefa ser abandonada.

Há duas zonas vermelhas menos evidentes. A primeira é logo depois de um travamento. É tentador, porque você tem alguém com opinião forte, mas uma nota ali mede o seu tratamento de erros e convida a uma reclamação pública; o que cabe depois de uma falha é uma pergunta diagnóstica estreita sobre o que a pessoa tentava fazer. A segunda é o paywall, porque feedback coletado ao lado de um preço fica contaminado pelo preço. Usuários de uma versão recém-lançada são um terceiro caso: reagem à novidade em vez de julgar o produto, então deixe uma versão assentar antes de retomar os avisos.

Os padrões de aviso e onde cada um encaixa

Existem cinco formas comuns de mostrar uma pergunta num app, cada uma com seu nível de interrupção. Casar o padrão com o momento é o que evita que um programa de feedback pareça insistência.

O cartão deslizante de baixo para cima é o cavalo de batalha: uma pergunta, sem bloquear o conteúdo atrás, descartado com um gesto. É o padrão correto depois de uma ação concluída, porque respeita o fato de que o usuário talvez não queira falar hoje, e aqui tem a melhor relação entre respostas e incômodo. Foi por isso que a micropesquisa virou o padrão no mobile.

O aviso em tela cheia ocupa o display inteiro. Consegue mais conclusão depois de aberto e custa muito mais quando cai errado, então reserve para momentos terminais: um marco, o encerramento do onboarding, um fluxo de cancelamento. Faça dele o seu padrão e em duas semanas os usuários vão fechá-lo por reflexo. O bloco em linha é o oposto, um cartão entre itens de um feed. Nunca interrompe, e mesmo com volume menor as respostas são voluntárias de um jeito que as torna úteis.

O acesso permanente é um «Enviar feedback» nas configurações ou no menu de ajuda. É passivo, então a minoria motivada domina e a amostra pende tanto para reclamações fortes quanto para entusiasmos fortes. Ainda assim é obrigatório: todo app precisa de um lugar que um usuário frustrado alcance sem sair para a loja, e a ausência dele é causa direta de avaliações de uma estrela que deveriam ter sido um ticket. O gesto de sacudir abre um formulário de reporte ao agitar o aparelho, ótimo em versões beta e testes internos, especialmente com captura automática de tela. Em produção é de nicho: precisa ser anunciado para ser descoberto e precisa de um botão nas configurações, porque disparos acidentais irritam.

Padrão	Interrupção	Ideal para	Perguntas que sustenta
Cartão deslizante	Baixa	Satisfação logo após uma ação concluída	Uma, mais um acompanhamento condicional
Aviso em tela cheia	Alta	Marcos, fim do onboarding, cancelamento	Duas ou três, com um fim visível
Bloco em linha num feed	Nenhuma	Perguntas de fogo lento em apps de conteúdo	Uma, autocontida
Acesso nas configurações	Nenhuma, iniciada pelo usuário	Reclamações, relatos de erro, pedidos de recurso	Texto livre mais uma categoria
Sacudir para reportar	Nenhuma, iniciada pelo usuário	Betas, testes internos, usuários avançados	Texto livre mais uma captura de tela
Aviso da loja	Alta, e com cota	Usuários que já disseram estar satisfeitos	Nenhuma, coleta uma nota pública

Qualquer que seja o padrão escolhido, descartar precisa ser trivial. Um aviso sem um controle de fechar visível transforma uma irritação leve exatamente na avaliação pública que você queria evitar.

Redigir uma pergunta que caiba numa tela de celular

A restrição que ninguém planeja é física. Um cartão deslizante te dá uma pergunta curta e uma linha de respostas antes de a dobra ou o teclado comerem o resto.

Mantenha a pergunta abaixo de uns sessenta caracteres e nomeie aquilo sobre o que você pergunta. Um «Como estamos indo?» solto devolve uma resposta sobre algo que você não identifica, enquanto «Quão fácil foi enviar essa transferência?» fixa o escopo e produz algo comparável entre milhares de respostas. Se o aviso dispara numa tela específica, refira-se àquela tela; num marco, refira-se ao app como um todo. Nunca misture os dois.

As opções de resposta precisam caber numa linha com áreas de toque de pelo menos 44 pontos, o que te limita a cinco ou seis. Uma escala de cinco pontos, uma linha de carinhas ou um par de polegares funcionam igualmente bem. Uma linha NPS de onze pontos não cabe numa tela estreita sem encolher as células abaixo do tamanho do polegar, então divida em duas linhas ou leve para um aviso de marco mais folgado; a escolha entre métricas de relacionamento e transacionais está destrinchada em CSAT versus NPS. Rotule as duas pontas, porque uma linha de números sozinha deixa as pessoas adivinhando.

Evite escrever a resposta dentro da pergunta. «A música de fundo te incomoda?» planta a ideia de que deveria; «O que você acha do som do app?» não. Esse problema de pergunta tendenciosa é pior in-app, porque com uma única pergunta nada mais corrige o viés. A lista de verificação está em perguntas para um formulário de feedback. Redações que sobrevivem ao espaço disponível:

• Quão fácil foi terminar isso? Uma pergunta de esforço de um toque, o melhor padrão depois de um fluxo concluído.
• Como você avaliaria esta tela? Com escopo estreito o suficiente para a resposta apontar uma peça específica de interface.
• O que você estava tentando fazer? A pergunta certa depois de um erro, e a única que vale a pena fazer ali.
• O que está faltando para você? Uma pergunta aberta para um marco, quando a pessoa já tem experiência para responder.
• O que quase te impediu de terminar? Ganha de «algum comentário?» porque pede algo concreto.

Quantas perguntas cabem in-app e quando levar para fora

Dentro do app o orçamento realista é uma pergunta mais um acompanhamento condicional. Não é preferência, é o que a tela e o momento sustentam. Três é o teto, reservado a avisos de marco em tela cheia onde o usuário já aceitou ao tocar em algo.

O padrão que compra volume e profundidade ao mesmo tempo tem dois passos: a nota dentro do app, onde o toque é quase gratuito, e o detalhe fora. O acompanhamento se ramifica, então uma nota baixa pergunta o que deu errado e uma alta pergunta o que manter. Isso é lógica de ramificação comum, e dobra o valor de um aviso de uma só pergunta.

Quando você realmente precisa de cinco perguntas ou mais, leve para uma pesquisa web num navegador dentro do app. Carregue a primeira resposta para que nada seja perguntado duas vezes, passe o contexto como parâmetros de URL e seja honesto sobre o tamanho, porque prometer duas perguntas e entregar nove ensina as pessoas a ignorar todos os avisos seguintes; a mecânica está em como reduzir o abandono em pesquisas. Ponha a pergunta fechada primeiro porque custa um toque, e deixe a pergunta aberta opcional, um equilíbrio exposto em perguntas abertas e fechadas. Texto livre obrigatório num celular coleta respostas que dizem «asdf».

Encaminhar respostas negativas ao suporte, não à loja

No momento em que um usuário toca numa nota baixa, você tem uma janela curta em que o problema ainda é seu para resolver. O que acontece a seguir decide se aquilo vira um ticket resolvido ou uma avaliação pública.

Ramifique pela nota. Uma resposta negativa abre um acompanhamento perguntando o que deu errado e depois oferece um caminho real até uma pessoa: um atendimento, um relato de erro, um retorno por telefone, com o diagnóstico anexado automaticamente para ninguém ter que descrever o aparelho. Uma resposta positiva segue o outro ramo, e só ali um convite para avaliar na loja faz sentido.

Duas ressalvas mantêm isso honesto. A oferta de suporte precisa ser real, porque encaminhar detratores para um formulário que não leva a lugar nenhum confirma a suspeita de que ninguém escuta. E não esconda o caminho do insatisfeito: suprimir feedback negativo removendo a saída é um desenho que nem reguladores nem lojas de aplicativos aprovam. A versão legítima é uma bifurcação em que os dois ramos levam a algo útil e só um menciona a loja. Bem feito, isso sobe a sua nota sem burlar nada, porque quem reclama em privado e recebe resposta raramente reclama em público, e usuários satisfeitos perguntados no momento certo deixam a avaliação que de outro modo nunca existiria.

Limite de frequência, para ninguém receber dois avisos por mês

Cada aviso gasta um pouco de boa vontade. O teto de frequência mantém o saldo positivo, e o lugar dele é o código, não um documento de boas intenções, porque o usuário que mais dispara os seus eventos é justamente o usuário avançado que você menos pode irritar.

Um conjunto de regras que funciona: um aviso por usuário a cada trinta ou sessenta dias, contando todas as pesquisas juntas e não por campanha. Depois de alguém responder, estenda para noventa dias no mínimo. Trate descartes como sinal, então um empurra a próxima data elegível e dois seguidos silenciam aquele usuário por seis meses. Defina uma idade mínima de conta e um número mínimo de sessões para nunca perguntar a usuários de primeiro dia, e pause tudo durante um incidente, quando as respostas mediriam a sua queda e não o seu produto.

A amostragem é a parte subestimada: numa base grande, mostrar o aviso a uma fração dos elegíveis dá volume suficiente deixando a maior parte da audiência intocada, e a nossa nota sobre tamanho de amostra cobre quanto você precisa. Guarde o estado de elegibilidade no servidor e não só no aparelho, porque contadores locais reiniciam na reinstalação e não viajam entre um celular e um tablet, que é como alguém acaba vendo o mesmo aviso três vezes numa semana. Essa é a face operacional da fatiga de pesquisas, e ela aparece como taxas de resposta em queda muito antes de alguém reclamar.

Envie o contexto que você já tem

A melhor pergunta é a que você não precisou fazer. Cada dado anexado automaticamente é uma pergunta a menos no aviso, o que aumenta a conclusão e melhora a exatidão ao mesmo tempo, já que a sua telemetria ganha da lembrança do usuário. Passe esses dados como campos ocultos, pelo seu SDK ou como parâmetros da URL da pesquisa:

• Versão e build do app. O corte mais útil em feedback mobile, transforma uma queda vaga de notas em «a versão 4.2».
• Sistema operacional, versão e modelo do aparelho. Metade dos relatos de erro se resolve só com essa linha.
• A tela onde o aviso disparou. Sem ela, «isto é confuso» não é acionável.
• Idade da conta, número de sessões e plano. A mesma reclamação significa coisas diferentes vinda de alguém da primeira semana ou de um assinante de dois anos.
• Idioma e tipo de conexão. Relatos de lentidão costumam ser uma história de rede antes de serem de código.
• Se a sessão teve um erro. Separa «o app está bom» de «o app está bom quando funciona».

Dois limites. Mantenha dados pessoais fora dos parâmetros de URL, porque links são encaminhados e registrados, e passe um identificador interno que não signifique nada fora dos seus sistemas. E seja verdadeiro sobre o que você anexa, porque um aviso que promete anonimato carregando um ID de conta não é anônimo; a nossa nota sobre pesquisas anônimas detalha o que essa palavra exige.

O que fazer com as respostas

Feedback que cai num painel que ninguém abre é custo sem retorno. O caminho que vai de uma resposta a uma mudança no produto precisa existir antes de você ligar o primeiro aviso.

Comece pela triagem, de preferência diária. As respostas caem em poucos baldes: um erro, um pedido de recurso, um problema de usabilidade, uma reclamação de preço ou ruído. Erros vão direto para o tracker com versão e aparelho já anexados, que é a recompensa dos campos ocultos. Pedidos de recurso vão para um backlog por temas com contagens, porque o sentido de coletar centenas de respostas é saber qual pedido é frequente e não qual foi formulado com mais vivacidade. Problemas de usabilidade são os mais valiosos e os mais fáceis de perder, porque chegam como frases e não como tickets.

Depois leia os números por versão e por tela. Uma nota para o app inteiro é métrica de vaidade; separada por versão ela diz se a última entrega ajudou, e separada por tela diz para onde mandar um designer. Agrupe o texto aberto em temas com contagens para o comentário mais barulhento não superar o mais comum, um processo coberto em análise temática. Observe também o próprio aviso: descartes em alta são o alerta mais precoce de que você pergunta demais. Meça a taxa de resposta e a taxa de conclusão separadamente, porque um aviso aberto e nunca terminado é um problema diferente de um que é ignorado.

Por fim, feche o ciclo, o que num app móvel é mais fácil do que em qualquer outro lugar. Notas de versão que nomeiam o que os usuários pediram, um aviso dentro do app dizendo a quem reportou que o problema foi resolvido, uma resposta ao fio que começou como uma nota baixa: tudo isso sobe a taxa de resposta do próximo aviso, porque as pessoas respondem pesquisas de produtos que visivelmente escutaram na vez anterior. Também as torna menos propensas a repetir a mesma reclamação em público, que é o mecanismo silencioso por trás da maioria das melhorias de nota que os times atribuem ao feedback.

Erros frequentes

• Usar o aviso da loja como ferramenta de feedback. Ele coleta uma nota pública, não informação, e cada aviso desperdiçado é um promotor que você não vai mais alcançar.
• Perguntar na abertura do app. O usuário ainda não fez nada, então não há sobre o que opinar.
• Interromper uma tarefa inacabada. Um aviso sobre um checkout custa a resposta e às vezes a compra.
• Pedir uma nota logo após um travamento. Isso mede o seu tratamento de erros e convida a uma avaliação de uma estrela.
• Oito perguntas num cartão. A tela sustenta uma mais um acompanhamento; o que for mais longo vai numa página linkada.
• Sem saída. Um aviso que não se fecha com um toque transforma um incômodo leve numa reclamação pública.
• Perguntar o que você já sabe. Versão, aparelho, plano e idade da conta vão em campos ocultos, nunca em perguntas.
• Um teto guardado só no aparelho. Reinstalações e segundos aparelhos reiniciam os contadores locais, e quem usa mais é perguntado mais.
• Coletar e depois silenciar. Nada mata a taxa de resposta do próximo trimestre mais rápido do que inação visível sobre esta.

Montar isso sem um time de research

A parte de engenharia é menor do que parece. Você precisa de um gatilho ligado a um evento real, uma superfície leve para desenhar a pergunta, uma camada de regras que decida a elegibilidade e um lugar onde as respostas caiam com o contexto anexado. A maioria dos times tem o primeiro, constrói o segundo uma vez, erra o terceiro e pula o quarto.

A metade da pesquisa não precisa de código próprio. Uma pesquisa hospedada, aberta num navegador dentro do app, cuida das perguntas, da ramificação, dos campos ocultos e dos relatórios, enquanto o seu app guarda só o gatilho e o limite de frequência. Assim um programa entra no ar em dias, não em sprints. Partir de um modelo pronto elimina a maioria dos erros de redação antes de você chegar nos de timing, e o argumento mais amplo está em por que product managers precisam de pesquisas.

O SurveyNinja cobre essa metade: lógica que manda notas baixas e altas por caminhos diferentes, variáveis ocultas para versão do app, aparelho e plano, layouts pensados primeiro para mobile que não precisam de ajuste, e relatórios filtrados para comparar uma entrega com a seguinte. O plano gratuito não tem teto de respostas, o que importa mais no mobile do que em qualquer outro lugar, porque um aviso lançado numa base grande devolve volume em horas e uma cota é a última coisa que você quer atingir no meio de um ciclo de entrega; veja a página de preços. Monte a pesquisa, ligue a uma única tela de sucesso e comece com uma pergunta.

Perguntas frequentes

O que é feedback in-app?

Uma pergunta feita dentro de um app móvel ou web num momento que o produto escolhe, com a resposta enviada em privado em vez de publicada. Como o app sabe o que o usuário estava fazendo, ele pode escolher o momento, anexar contexto como versão e aparelho automaticamente e ramificar conforme a resposta.

Qual a diferença em relação ao aviso de avaliação da loja?

O aviso de avaliação é um diálogo do sistema operacional que escreve uma nota pública dentro de uma cota da plataforma, e não pode ser lido nem respondido em privado. Uma pesquisa in-app é sua: você controla quando ela aparece, o que pergunta e para onde vai a resposta, e ela nunca toca na sua nota.

Qual o melhor momento para pedir feedback num app?

Logo depois de uma ação concluída, na tela de sucesso, enquanto a atenção sai de graça e a tarefa está fresca. Marcos combinam com perguntas sobre o produto como um todo, e um atendimento resolvido combina com uma pergunta de esforço. Nunca pergunte na abertura, nunca no meio de uma tarefa e nunca peça uma nota logo após um travamento.

Quantas perguntas dá para fazer dentro de um app?

Uma, mais um acompanhamento condicional. Três é o teto, e só para um aviso em tela cheia num marco. Se você precisa de cinco ou mais, faça a nota no app e leve para uma pesquisa web, carregando a primeira resposta e o contexto para nada ser perguntado duas vezes.

Com que frequência o mesmo usuário deveria ver um aviso de feedback?

No máximo uma vez a cada trinta ou sessenta dias contando todas as pesquisas, estendido a noventa dias depois de alguém realmente responder. Conte descartes como sinal e silencie quem ignorou dois avisos seguidos. Guarde o estado de elegibilidade no servidor, porque contadores locais reiniciam na reinstalação.

O que deve acontecer quando alguém dá uma resposta negativa?

Ramifique para um acompanhamento curto perguntando o que deu errado e então ofereça um caminho real até uma pessoa, como um atendimento ou um relato de erro, com o diagnóstico anexado automaticamente. Nunca mande esse usuário para a loja de aplicativos. O ramo positivo é o único lugar onde um convite para avaliar cabe.

Quais dados convém anexar automaticamente a uma resposta in-app?

Versão e build do app, sistema operacional e modelo do aparelho, a tela onde o aviso disparou, idade da conta, número de sessões, plano, idioma e se a sessão teve um erro. Tudo nessa lista é uma pergunta que você não precisa mais fazer. Mantenha dados pessoais fora dos parâmetros de URL, e nunca chame de anônima uma resposta que carrega um ID de conta.

Qual padrão de aviso in-app funciona melhor?

Um cartão deslizante com uma única pergunta é o melhor padrão: pouca interrupção, fácil de descartar e a melhor relação entre respostas e incômodo. Avisos em tela cheia servem só para marcos e cancelamento, blocos em linha servem para feeds de conteúdo, e um acesso permanente nas configurações deveria existir em todo app.