10 erros de instrumentação de produto e o que aprendemos com eles

Publicado por Sérgio Schuler no dia produto

No contexto de produto, instrumentação é a habilidade de medir e monitorar métricas importantes para a gestão de produto, como adoção ou retenção de uma funcionalidade. Isso é fundamental para que o time de produto, em especial product managers, possa tomar decisões baseadas em métricas ao invés de feeling.

Aqui na Resultados Digitais usamos o Mixpanel, integrado ao Segment.io, para centralizar essas métricas e deixá-las mais facilmente acessíveis aos product managers. Porém esse post não é sobre o Mixpanel. Ele pode ser generalizado para qualquer ferramenta, pois foca nos aprendizados que tivemos ao instrumentar o RD Station.

Erro 1: delegar o planejamento da instrumentação de produto para os desenvolvedores

Assim como você não deixa só na mão do desenvolvedor decidir qual funcionalidade vai ser construída, não faz sentido deixar na mão dele o que você vai instrumentar para gerenciar o produto. O time de desenvolvimento nem sempre sabe o que você precisa. Delegar essa responsabilidade para os desenvolvedores não faz sentido.

Os desenvolvedores com certeza serão os que vão implementar a instrumentação, mas usando como ponto de partida o seu planejamento.

Vale ressaltar aqui para não confundir a instrumentação de produto com a instrumentação de engenharia, essa última sim sob responsabilidade total do time de desenvolvimento.

Erro 2: não planejar a instrumentação

Se é um erro deixar na mão do desenvolvedor o planejamento da instrumentação, também é um erro pensar nela somente em linhas gerais. Por exemplo: “quero medir a retenção da funcionalidade” ou “quero saber quantos usuários acessaram a feature”.

Passar essas informações para o desenvolvedor é a receita de ter uma implementação incompleta, confusa e que, no fim, não vai fornecer os dados que você quer. O planejamento da instrumentação deve ser escrito, para que o desenvolvedor possa implementá-lo sem precisar pensar em nada além do código.

O que planejar: - Nome dos eventos e suas propriedades; - Quando, onde e como cada evento é disparado; - Que tipo de análise você pretende fazer e com qual frequência.

Erro 3: instrumentar absolutamente tudo

Intrumenthing all the things!

Ter um monte de dados pode parecer desejável, mas você precisa se perguntar “que conclusões posso tirar olhando essa métrica?” Se você não sabe, é provável que seja inútil instrumentá-la.

Claro que você pode pensar “vai que um dia eu preciso desse dado? Vou instrumentar”. Além disso não ser muito condizente com os princípios ágeis, o mais provável é que você ou nunca de fato precise ou precise de algo ligeiramente diferente, tornando o esforço um desperdício. Também é importante lembrar que a instrumentação gera código, e quanto mais linhas de código você tiver, mais complexo e custoso é modificar o software.

O que instrumentar:

Essas métricas variam de time e produto, mas em geral elas podem ser enquadradas nas Pirate Metrics (AARRR: Aquisição, Ativação, Retenção, Recomendação, Receita) e nas métricas de sucesso do cliente.

Um exemplo dessas métricas foi quando mudamos a interface do RD Station. Como era possível escolher entre a nova e a velha interface, instrumentamos as métricas de adoção e retenção:

  • Adoção: o percentual da base total de usuários que tinha acessado alguma vez a nova interface.
  • Retenção: daqueles usuários que acessaram alguma vez a nova interface, qual porcentagem deles se mantiveram nela.

Erro 4: não ter convenções de nome de evento

These are not the events you are looking for

Logo seu número de eventos vai crescer de 10 para 100+ e aí encontrar o que você quer torna-se uma tarefa inglória. Além disso, sem uma convenção clara de nomes, é muito provável que em breve você terá eventos que parecem que medem uma coisa, mas na verdade medem outra.

Na Resultados Digitais ainda estamos experimentando com convenções de nomes, mas hoje a convenção que usamos é: - Os nomes devem ser em inglês - Devem seguir o padrão CamelCase sem espaços - Devem ter a seguinte estrutura:

Feature: ComponenteOuObjeto Ação

Exemplos de nomes dos eventos

Exemplos de uso dessa convenção de nomes:

SocialMedia: PostEditor Add - Esse evento é disparado quando um post é adicionado (ação), usando o editor de posts (componente) da funcionalidade de mídias sociais do RD Station.

Dashboard: Home View - Esse evento é disparado quando o usuário carrega a página inicial do dashboard.

SuccessPlans: Plan Edit - É disparado quando o usuário edita um plano na feature de Planos de Sucesso do RD Station.

Erro 5: disparar eventos que não medem de fato o que você pensa que medem

Esse foi um aprendizado recente que tivemos: quando lançamos o novo RD Station, cheio de novas funcionalidades, os usuários eram recebidos ao fazer login por um modal de boas-vindas, apresentando as mudanças. Esse modal tinha 7 slides, cada um deles podendo ser fechado ou passado para o próximo ou anterior.

Nós queríamos medir até onde nossos usuários liam as novidades para, caso fosse necessário, mandar notificações in-app daquelas novidades que não foram lidas. Então implementamos um evento para cada mudança de slide do modal. Tudo bem que isso não ia garantir que o usuário leu o conteúdo do modal, mas pelo menos indicaria que ele passou pelo conteúdo.

O problema é que o modal também tinha a funcionalidade de mudar sozinho de slide a cada 7 segundos. Além disso o modal era infinito, ou seja, ao chegar no fim, ele voltava para o 1º slide. Isso significa que se um usuário abrisse o app e fosse tomar um café, ele passaria múltiplas vezes por todos os slides do modal, mesmo sem de fato ver nenhum deles. No fim, esse evento não garantiu o que queríamos metrificar.

Erro 6: não calcular o potencial número de eventos disparados

O aprendizado anterior não foi o único que nosso modal de boas-vindas nos proporcionou. Lembra do usuário que abriu o RD Station e foi tomar um cafezinho? Se só 500 usuários (entre 2-3% da nossa base) fizessem o mesmo, teríamos uma enxurrada de eventos:

  • Seriam 500 eventos a cada 7 segundos (velocidade que o modal mudava de slide)
  • 4.285 eventos em 1 minuto
  • 257.100 eventos em 1 hora

E isso de fato aconteceu, em 4 dias esse evento foi disparado mais de DOIS MILHÕES de vezes. Considerando que nosso limite atual no Mixpanel é de 4 milhões de eventos por mês, podemos dizer que foi bem fora da curva. :)

Erro 7: não usar (e planejar) as propriedades dos eventos

No Mixpanel, e na maioria das ferramentas de instrumentação de produto, é possível enviar junto com o evento uma série de propriedades para identificar melhor o que foi feito, bem como auxiliar na segmentação dos dados.

Costumamos enviar como padrão em todos os eventos o ID da conta e ID do usuário que disparou o evento. Mas é possível enviar qualquer tipo de informação como propriedade do evento, por exemplo: qual navegador foi usado, qual a versão da funcionalidade que disparou o evento (para o caso de rollouts parciais) etc.

Porém vale a máxima do erro 3: não mande um monte de dados só porque você pode. Se o dado não for útil para suas análises e decisões, não envie-o como propriedade.

Erro 8: criar eventos muito parecidos

Eventos muito parecidos são um sintoma de que você provavelmente está criando eventos demais. Um exemplo que ocorreu na Resultados Digitais foram os eventos que usamos para monitorar o uso da nossa página de Metodologia. Quando o usuário acessava uma página, cada uma disparava 2 eventos distintos: um com o nome do evento e outro com o tempo de visualização da página:

  • Methodology: BlogContent View
  • Methodology: BlogContent ViewTime
  • Methodology: BlogCreation View
  • Methodology: BlogCreation ViewTime
  • Methodology: BlogPromo View
  • Methodology: BlogPomo ViewTime
  • Methodology: BlogVisitorsOfferPromo View
  • Methodology: BlogVisitorsOfferPromo ViewTime
  • Methodology: EmailMarketing View
  • Methodology: EmailMarketing ViewTime
  • … e mais 28 eventos, para um total de 38 (2 por página da metodologia)

Todos esses 38 eventos poderiam ser facilmente resolvidos com apenas um evento:

Methodology: Content View

Mas só com esse evento perderíamos a informação de qual página da Metodologia foi acessada, bem como o tempo que o usuário ficou na página, certo? Errado. Podemos usar as propriedades de evento, mostradas no erro anterior, para este fim. Bastava adicionar 2 propriedades no evento único disparado: ContentName (i.e. BlogCreation) e ViewTime.

Simplificação do evento

Erro 9: não testar a análise que planejou

Depois de planejar a instrumentação, seguindo suas convenções estabelecidas para medir as métricas realmente úteis, é muito comum esquecer-se delas até chegar o momento de você de fato fazer as medições. Então você descobre “droga, o dado que eu precisava não pode ser usado da forma que eu enviei”. E a sua instrumentação vai pelo ralo.

Para evitar isso, é recomendado testar as análises que você quer fazer (i.e. cohort, funil…) e simular como você vai receber esses dados para ver se realmente você conseguirá medir o que quer, como quer e com as segmentações que desejar.

Erro 10: não instrumentar o produto :)

Assim como você não consertaria um carro sem saber o que está errado com ele, você não deve modificar o produto sem métricas importantes para tomar as decisões certas sobre o caminho a seguir. Comece aos poucos instrumentando as métricas mais importantes e torne uma cultura do time de produto tomar decisões baseando-se nesses dados.

Sérgio Schuler

Sérgio Schuler

Product Manager

Comentários