6 exemplos reais de análise de produto em ação

Gestão de produto orientada por dados. É isso que os mais modernos fazem hoje em dia, certo? Talvez tenha pesquisado no Google e descoberto que ser “orientado por dados” consiste na utilização extensiva de análise de produto no fluxo de trabalho diário destes gestores de produto.

Mas a questão é: o que fazem com os dados analíticos? Como os utilizam na vida real?

Felizmente, compilei uma lista de 6 casos de utilização da análise de produto para o inspirar.

O que é a análise de produto e porque deve importar-se com ela?

A análise de produto é o processo de recolher dados sobre o seu produto digital (incluindo a atividade dos utilizadores, dados financeiros, etc.), analisá-los e tomar decisões diárias e estratégicas sobre o produto com base nas suas conclusões.

A utilização de análise de produto aumenta significativamente a qualidade da tomada de decisões que faz enquanto gestor de produto, uma vez que consegue apoiar e comprovar as suas ideias ou soluções através da utilização de dados.

Enquanto dados quantitativos, estes também complementam os dados qualitativos que recolheu através de entrevistas com clientes, proporcionando-lhe uma visão completa do estado do seu produto, bem como do comportamento dos clientes ou utilizadores.

Pode ativar a análise de produto para o seu produto configurando uma ferramenta especializada de análise de produto que monitoriza a atividade dos seus utilizadores e lhe envia relatórios sobre as interações dos utilizadores.

Estas ferramentas agregam então os dados sobre as ações dos utilizadores que recolheram do seu produto e permitem-lhe criar relatórios personalizados para encontrar respostas a algumas das perguntas que possa ter sobre a utilização do seu produto.

Agora que já sabemos em que consiste a análise de produto, vamos começar a explorar alguns dos casos práticos de aplicação da análise de produto.

Exemplo n.º 1: simplificar a sua interface, removendo funcionalidades que ninguém utiliza

Os grandes produtos não são aqueles que têm mais funcionalidades do que os seus concorrentes. Na verdade, na maioria das vezes, os produtos com demasiadas funcionalidades tornam-se difíceis de navegar para os seus utilizadores e impossíveis de manter pela equipa de desenvolvimento do produto.

Por isso, as grandes equipas de produto garantem que os seus produtos têm apenas funcionalidades que acrescentam valor aos seus utilizadores. Para isso, estará sempre a adicionar novas funcionalidades que pensa que as pessoas irão utilizar e a eliminar as que sabe que já não são valiosas.

O dilema seguinte e óbvio é saber como escolher as funcionalidades que vale a pena remover. É simples: verifique a sua utilização com uma ferramenta de análise de produto!

Utilizar uma ferramenta de análise de produto baseada em eventos, como a Mixpanel, para simplificar a interface

Para conseguir acompanhar a utilização de qualquer funcionalidade, terá de configurar um evento para a mesma e acioná-lo sempre que o utilizador interagir com essa funcionalidade. Partindo do princípio de que configurou estes eventos para as funcionalidades do produto que pretende medir, tudo o que precisa de fazer é criar um relatório sobre a utilização dessa funcionalidade.

Vamos ilustrar isto com um exemplo. Imagine que lidera a Spotify, o serviço de transmissão de música que muitos de nós utilizamos, e que gostaria de perceber se vale a pena eliminar a funcionalidade de reprodução aleatória.

Para isso, vamos criar um novo relatório de informações com o seguinte aspeto.

Aqui, selecionámos a funcionalidade em questão — “Aleatório” — juntamente com a funcionalidade de referência (normalmente, a ação principal do seu produto ou a Estrela Polar) com a qual a queremos comparar — neste caso, “Transmitir uma música”. Para ambas, selecionámos a opção “Contar utilizadores ativos diários” para nos mostrar o número de utilizadores únicos que utilizam a reprodução aleatória e transmitem música todos os dias.

Em seguida, adicionámos uma fórmula simples que calcula a percentagem de utilizadores que transmitem músicas e que utilizaram a funcionalidade de reprodução aleatória.

Ao observar este gráfico, podemos tirar 2 conclusões importantes:

• Mal 0,5% de todos os utilizadores que transmitem música utiliza a funcionalidade de reprodução aleatória.
• A utilização da reprodução aleatória tem vindo a diminuir constantemente, de 1,3% para 0,5%, no último mês.

Com base nestas estatísticas de utilização, podemos considerar a funcionalidade de reprodução aleatória uma candidata adequada para remoção e simplificação da nossa interface.

Exemplo n.º 2: Encontrar e corrigir problemas de experiência do utilizador que prejudicam os fluxos de configuração ou do momento AHA!

Os primeiros passos que os seus utilizadores dão no seu produto terão um forte impacto na retenção e no valor ao longo do ciclo de vida. Pelo menos, foi isto que observei inúmeras vezes nos produtos que liderei.

Qualquer melhoria no processo de configuração do seu produto pelos utilizadores e na chegada ao momento AHA! acabará por se traduzir num nível de retenção mais elevado.

Para maior clareza, os utilizadores atingem o momento de configuração quando concluíram todas as configurações necessárias ao inscreverem-se (por exemplo, fornecer os dados do cartão de crédito e verificá-los numa aplicação de pagamentos). O momento AHA! é o ponto do percurso do utilizador em que este experiencia pela primeira vez o benefício e o valor do seu produto (por exemplo, efetuar uma transferência instantânea com a sua aplicação de pagamentos).

É normalmente bastante comum existirem problemas na experiência do produto ao longo do percurso, fazendo com que menos pessoas alcancem os momentos de configuração e de criação de hábitos. Mas a boa notícia é que pode encontrá-los facilmente com uma ferramenta de análise ou mapas de calor de UX como estes. Com este tipo de dados, as equipas conseguem identificar onde os utilizadores abandonam o processo, que passos causam fricção e como melhorar a conversão.

Leitura relacionada: As 10 melhores ferramentas de design de UX para programadores de produtos

Como utilizar funis de análise de produtos no Heap para solucionar problemas de conversão

Uma das formas mais práticas de acompanhar e solucionar problemas nos percursos (incluindo os que conduzem aos momentos de configuração e AHA!) consiste em utilizar funis. Um funil é uma lista de eventos colocados numa ordem específica, na qual pode observar a conversão dos utilizadores de um evento para outro.

Eis o aspeto de uma análise de funil para uma página de inscrição básica, na qual existe um único campo de e-mail e um botão de envio.

Na nossa página de inscrição, acompanhamos os utilizadores relativamente a estes eventos:

1. Visualização da página de inscrição.
2. Preenchimento do e-mail do utilizador no campo.
3. Clique no botão de envio.

Como podemos ver, mais de 1 200 utilizadores entraram na página de inscrição. No entanto, apenas 17% desses 1 200 preencheram o e-mail e 90% dos que forneceram o e-mail clicaram no botão de envio.

Este funil indica-nos que existe algo de errado com o campo de e-mail e que precisamos de investigar exatamente o que se passa.

Para isso, podemos realizar testes de usabilidade do nosso ecrã de inscrição ou consultar a reprodução da sessão no Heap, que consiste numa gravação de vídeo em tempo real da interação do utilizador com o seu produto.

No caso do campo de e-mail, poderá descobrir que a validação do e-mail é frustrante e que os seus utilizadores desistem depois de tentarem introduzir o e-mail algumas vezes.

Exemplo n.º 3: Medir o impacto de uma funcionalidade durante a implementação gradual

Quantas vezes adicionou uma nova funcionalidade apelativa ao seu produto que acabou por ser um fracasso total (isto é, não melhorou a utilização ou até a prejudicou)? Isto já aconteceu pelo menos algumas vezes até aos PM mais talentosos.

Como nem sempre sabemos se a funcionalidade que criámos será bem-sucedida ou falhará, é boa ideia disponibilizá-la a um pequeno número de utilizadores, verificar se a utilizam (e se melhora as suas métricas principais, como a retenção ou o valor ao longo do ciclo de vida) e, depois, partindo do princípio de que foi um sucesso, disponibilizá-la a todos os restantes utilizadores.

Pode realizar tanto a implementação gradual como a medição do impacto com uma solução especializada de análise de produtos que inclua funcionalidades essenciais de software de análise, como o Amplitude.

Configurar e executar experiências com software avançado de análise de produtos, como o Amplitude

O Amplitude inclui uma funcionalidade avançada denominada Experiências. Pode utilizá-la para executar testes A/B ou para realizar implementações graduais de funcionalidades. Não vou entrar nos pormenores da criação de uma experiência, pois isso fica para outra ocasião, mas pode consultar a documentação que o Amplitude disponibiliza para esta funcionalidade, onde é descrito tudo, desde mensagens de API a integrações, notificações e preços.

Imaginemos agora que adicionou um guia em vídeo como parte da integração do seu produto e que pretende aumentar o número de pessoas que clicam no botão de reprodução e o veem. Para isso, concebeu duas soluções, com o vídeo a aparecer em duas partes diferentes da integração.

Para perceber se as suas soluções funcionam (e qual funciona melhor), podemos configurar uma experiência com uma implementação parcial de 25% para a variante A e de 25% para a variante B.

Quando iniciamos esta experiência e a executamos durante algum tempo para obter dados dos utilizadores estatisticamente significativos, é isto que vemos.

O gráfico acima representa um funil de conversão desde a visita à página inicial até ao início do vídeo. Como podemos ver, a variante A é a vencedora e consegue otimizar a conversão do início do vídeo em 3,4%.

Dependendo da situação, pode considerar isto um sucesso ou um fracasso. Para uma taxa de conversão de abertura de vídeos, eu diria que isto é um fracasso e que não vale a pena o esforço de implementar a alteração para todos. Mas, se o resultado de uma experiência fosse um aumento de 3,4% na retenção, isso seria um sucesso significativo.

Exemplo n.º 4: Monitorizar a saúde do produto

Os produtos são organismos vivos que podem sentir-se bem ou ficar "doentes". Para garantir que está sempre a par da saúde do seu produto e que consegue identificar e corrigir quaisquer problemas, terá de monitorizar o “batimento cardíaco” do produto sob a forma de um painel de controlo da saúde do produto.

Como resultado da sua monitorização, poderá notar descidas ou picos nas principais métricas do produto e nos KPIs, como WAU ou adesão, que necessitam de investigação, ou poderá verificar que o envolvimento dos utilizadores está a diminuir gradualmente — um sinal de que o seu produto precisa de ser renovado.

Felizmente, um painel de controlo da saúde do produto é algo que pode criar facilmente utilizando qualquer ferramenta de inteligência empresarial (por exemplo, Mixpanel ou Amplitude).

Acompanhar as principais métricas do produto com o Mixpanel

Os painéis de controlo do Mixpanel são constituídos por vários relatórios relacionados que coloca lado a lado. Para um painel de controlo da saúde do produto, pode considerar criar os seguintes relatórios:

• DAU, WAU ou MAU para a sua ação principal (por exemplo, ouvir uma música em transmissão contínua no Spotify). A escolha entre os três depende da frequência natural da ação principal. No caso da transmissão de músicas, será diária, pelo que a sua escolha deverá recair sobre o DAU.
• Adesão (DAU/WAU, WAU/MAU, etc.). Isto mostrará a percentagem de utilizadores que estão envolvidos e regressam ao seu produto.
• Registos ao longo do tempo e conversões de Gratuito → Pago ao longo do tempo. Deve acompanhar estes dois indicadores e garantir que estão a crescer gradualmente.
• Abandono. Este é o número de utilizadores que perdeu durante um determinado período. Um aumento neste indicador deve deixá-lo preocupado.
• Retenção. Isto mostra o número de utilizadores que permaneceram consigo após um período de tempo específico (por exemplo, 90 dias).

Eis o aspeto típico de um painel de controlo da saúde do produto no Mixpanel.

Pode adicionar livremente quaisquer outros relatórios ao seu painel de controlo, desde que representem a saúde do seu produto.

Exemplo n.º 5: Tomar uma decisão de lançar/não lançar quando a sua equipa de QA encontrou um problema grave na versão

Uma das decisões mais difíceis que temos de tomar é dar luz verde para o lançamento de uma versão. E é difícil porque as versões quase nunca estão isentas de erros. As coisas tornam-se ainda mais complicadas quando encontramos um erro capaz de prejudicar a experiência do cliente.

Mas por que motivo é complicado? Se tiver um erro grave, deve corrigi-lo primeiro antes de lançar a versão, certo? Bem, imagine que descobre que a sua equipa vai precisar de mais uma semana para o corrigir e que a sua equipa de marketing já assumiu compromissos e fez preparativos que são difíceis de cancelar.

Nesta situação, tem duas opções:

• Dar luz verde ao lançamento e enfrentar as consequências do erro grave.
• Dar à sua equipa de marketing um argumento forte para explicar por que motivo deve adiar o lançamento.

Ambas as opções parecem más. Mas não se preocupe, pois existe a possibilidade de o erro em questão ter um impacto muito menor do que imaginava e de poder lançar a versão sem muitas consequências.

Para medir o impacto dos erros, podemos utilizar dados da nossa plataforma de análise de produtos.

Utilizar o Google Analytics para calcular o impacto dos erros

Imagine que tem um erro que está a causar falhas ocasionais na sua aplicação móvel em Android 6.0.1, interrompendo completamente o percurso do cliente. Para compreender o impacto deste erro, precisamos de saber o número de utilizadores que têm esta versão do Android.

Felizmente, para além dos dados de utilização, o Google Analytics também consegue recolher e armazenar dados sobre os aspetos técnicos dos nossos utilizadores, tais como os tipos de dispositivos, as versões do sistema operativo, os tamanhos dos ecrãs, entre outros.

Assim, se abrirmos o relatório “Detalhes tecnológicos” e selecionarmos a opção “Sistema operativo com versão”, descobriremos que apenas 1,2% da totalidade dos utilizadores utiliza o Android 6.0.1.

Embora estes dados já sejam um indicador para darmos luz verde ao lançamento, podemos ir um passo mais além e calcular também o potencial impacto financeiro, verificando as receitas que obtemos dos utilizadores do Android 6.0.1.

Se compararmos a receita total entre “todos os utilizadores” e “utilizadores do Android 6.0.1”, veremos o seguinte.

Aparentemente, os utilizadores que irão enfrentar falhas após o lançamento não geram qualquer receita para nós. Por isso, não teremos consequências financeiras ao lançar a versão com o erro. Bónus!

Exemplo n.º 6: Identificar grupos de utilizadores que merecem os seus esforços de marketing

Nem todos os seus utilizadores são iguais. Alguns serão utilizadores intensivos que representam a maior parte da utilização do seu produto (bem como a maioria das suas receitas), enquanto outros estarão inativos, havendo pouca esperança de os envolver e rentabilizar.

Naturalmente, todos gostariam de identificar os utilizadores que podem gerar mais receitas e concentrar neles os seus esforços de marketing. Mas como fazê-lo?

Pode aproveitar os dados de análise do seu produto, identificando diferentes grupos de utilizadores e comparando as suas principais métricas de utilização e monetização. 

Análise de grupos com o Amplitude

Os grupos são conjuntos de utilizadores que partilham uma característica comum. Pode criar grupos com base em:

• Plataforma (por exemplo, utilizadores de Mac e Windows). Tive um produto em que os utilizadores de Mac apresentavam um LTV 30% superior ao dos utilizadores de Windows.
• Geografia (por exemplo, utilizadores de França e da Grécia). Dependendo do produto, este pode ser bem rentabilizado em determinados países e ter um desempenho inferior noutros.
• Data de registo (por exemplo, utilizadores que se registaram em novembro e janeiro). Imagine que a sua campanha da Black Friday foi um enorme sucesso. Alcançou as pessoas certas e o seu grupo de novembro tem um LTV muito superior ao dos outros meses.
• Comportamento do utilizador ou utilização de determinadas funcionalidades (por exemplo, utilizadores que baralham músicas e aqueles que não o fazem). Ao criar uma funcionalidade, pretende realmente que os seus utilizadores tenham um maior envolvimento e um LTV superior. Caso contrário, a funcionalidade não foi bem-sucedida e vale a pena eliminá-la.

Agora vamos criar alguns grupos no Amplitude e compará-los.

Imagine que pretende perceber se vale a pena investir em marketing no Japão. Podemos criar no Amplitude um grupo de utilizadores japoneses desta forma.

Depois, podemos comparar a frequência das ações de compra dos utilizadores japoneses com a de todos os restantes utilizadores.

Como podemos ver, os utilizadores japoneses fazem mais compras do que a média. Por isso, vale a pena pedir à sua equipa de marketing que direcione os seus esforços para o Japão.

Em resumo

A análise de produto facilita a sua vida enquanto gestor de produto, permitindo-lhe tomar decisões de conceção orientada por dados e não depender exclusivamente da sua intuição e dos seus pressentimentos.

Tomar decisões fundamentadas em dados analíticos é ótimo, mas não deve ficar por aí. Algumas das outras ferramentas excelentes que pode utilizar para se tornar um melhor gestor de produto incluem:

• Ciclos de retorno dos clientes para garantir que todos ouvem a voz dos seus clientes.
• Esquemas de produto para iterar rapidamente sobre a sua conceção e sem complicações.
• PRDs para alinhar todos relativamente aos detalhes de implementação da funcionalidade, entre outros.
• Cursos de análise de produtos são recursos valiosos, com um ROI elevado, para o tornar mais eficaz na sua função.

Além de ler estes guias, também pode subscrever o nosso boletim informativo e deixar que lhe entreguemos diretamente na sua caixa de entrada muitos conteúdos úteis sobre gestão de produto!