Você lançou a feature. Mas alguém está usando?

Existe um momento bastante satisfatório na construção de qualquer produto.

A feature foi implementada.

O design está resolvido.

Os últimos bugs foram corrigidos.

O deploy aconteceu.

Tudo funciona.

Tecnicamente, o trabalho terminou.

Mas existe uma pergunta que só começa a fazer sentido depois disso:

alguém está usando?

Parece óbvio.

Se construímos alguma coisa, queremos saber se ela está sendo utilizada.

Só que, na prática, muitos produtos conseguem responder com bastante precisão quando uma requisição falhou e quase nada sobre o que acontece quando a requisição funciona.

Sabemos se o sistema está no ar.

Sabemos se existem erros.

Sabemos quanto tempo determinada página levou para carregar.

Mas nem sempre sabemos se as pessoas encontraram a funcionalidade que construímos.

Se entenderam como utilizá-la.

Se começaram o fluxo.

Se terminaram.

Ou se simplesmente ignoraram tudo aquilo em que passamos dias trabalhando.

É aí que analytics deixa de ser apenas um gráfico no dashboard.

E começa a participar da construção do produto.

Produção não valida uma ideia

Existe uma confusão fácil de fazer durante o desenvolvimento.

Quando uma feature finalmente funciona, existe uma sensação de validação.

A implementação está correta.

Os testes passam.

O fluxo pode ser concluído.

Do ponto de vista técnico, isso significa muita coisa.

Do ponto de vista do produto, significa bem menos.

O código valida que conseguimos construir aquilo.

Ele não valida que deveríamos ter construído.

Uma funcionalidade pode funcionar exatamente como planejamos e ainda assim não resolver um problema relevante.

Pode ser difícil de descobrir.

Pode exigir etapas demais.

Pode chegar no momento errado.

Pode ser compreendida de outra forma.

Pode simplesmente não ser importante o suficiente para mudar o comportamento de ninguém.

Nenhum teste automatizado consegue responder essas perguntas.

Quem responde é o uso.

Entre lançar e aprender existe instrumentação

Imagine que criamos uma nova funcionalidade para exportar relatórios.

O desenvolvimento foi concluído e o botão está disponível para todos.

Depois de algumas semanas, ninguém reclama.

Isso é bom?

Talvez.

Pode significar que tudo está funcionando perfeitamente.

Mas também pode significar que ninguém encontrou o botão.

Ou que encontrou, clicou e desistiu.

Ou que o arquivo gerado não era útil.

Ou que poucas pessoas tinham interesse naquela funcionalidade desde o começo.

Sem instrumentação, todos esses cenários se parecem.

Silêncio.

É por isso que eventos de produto são importantes.

Talvez queiramos saber quantas pessoas visualizaram a área onde a exportação está disponível.

Quantas iniciaram a ação.

Quantas concluíram.

Qual formato escolheram.

Se voltaram a usar depois.

Agora começamos a enxergar um comportamento.

E comportamento cria espaço para investigação.

Medir tudo não significa entender mais

Quando percebemos isso, aparece uma tentação natural:

registrar tudo.

Cada clique.

Cada abertura.

Cada scroll.

Cada mudança de aba.

Cada interação possível.

Em pouco tempo, temos milhares de eventos disponíveis.

E quase nenhuma ideia do que fazer com eles.

Existe uma diferença importante entre coletar dados e produzir informação útil.

Um evento deveria existir porque existe alguma pergunta que queremos responder.

Não apenas porque conseguimos registrá-lo.

Antes de instrumentar uma feature, talvez seja mais útil começar pelas perguntas:

Como sabemos que alguém encontrou essa funcionalidade?

Qual comportamento indica que ela começou a ser utilizada?

O que representa conclusão?

Existe algum ponto importante de abandono?

O usuário volta depois?

Que decisão podemos tomar dependendo dessas respostas?

Essa última pergunta é especialmente importante.

Se uma métrica muda e nenhuma decisão muda junto com ela, talvez estejamos apenas acumulando números.

Eventos contam histórias quando existe contexto

Considere um fluxo simples de criação de conta.

Podemos registrar:

signup_started

signup_completed

Isoladamente, já conseguimos descobrir uma taxa de conclusão.

Mas imagine que ela está baixa.

Agora precisamos de mais contexto.

Talvez o fluxo tenha quatro etapas.

Podemos então saber quantas pessoas chegaram a cada uma delas.

De repente, aparece um padrão:

muitas pessoas começam.

Quase todas passam pelas duas primeiras etapas.

Metade abandona quando precisa adicionar informações de pagamento.

Agora existe algo para investigar.

Talvez o problema seja confiança.

Talvez a comunicação não esteja clara.

Talvez estejamos pedindo dados cedo demais.

Talvez exista um problema técnico naquela etapa.

Analytics não entrega automaticamente a resposta.

Ele mostra onde vale fazer uma pergunta melhor.

E essa diferença importa.

Dados não substituem interpretação

É fácil olhar para uma ferramenta de analytics e esperar que ela diga o que fazer.

Um gráfico sobe.

Outro cai.

Uma porcentagem fica vermelha.

Mas números não conhecem o contexto do produto.

Uma queda pode representar um problema.

Ou uma mudança esperada.

Um aumento no tempo de permanência pode indicar mais engajamento.

Ou que a interface ficou mais difícil de usar.

Mais cliques podem significar interesse.

Ou fricção.

Menos etapas em um funil podem ser boas porque simplificamos o fluxo.

Menos etapas concluídas podem ser ruins porque algo passou a impedir o usuário de avançar.

A métrica não carrega significado sozinha.

Ela precisa ser interpretada dentro do comportamento que estamos tentando entender.

Por isso, analytics não elimina julgamento.

Na verdade, exige mais dele.

Métrica de produto não é métrica de vaidade

Alguns números são fáceis de acompanhar porque fazem o produto parecer movimentado.

Pageviews.

Cadastros.

Cliques.

Sessões.

Total de usuários.

Eles podem ser úteis.

Mas isoladamente dizem pouco sobre valor.

Imagine um SaaS que ganhou mil novos cadastros em uma semana.

Parece ótimo.

Mas quantos usuários chegaram ao momento em que perceberam o valor do produto?

Quantos voltaram?

Quantos incorporaram aquilo à rotina?

Quantos abandonaram depois da primeira sessão?

É possível crescer em aquisição e continuar com um problema enorme de retenção.

Assim como é possível aumentar o número de cliques simplesmente porque tornamos uma tarefa mais longa.

O número precisa estar conectado ao comportamento que realmente importa.

Esse talvez seja um dos trabalhos mais difíceis de analytics:

decidir o que merece ser medido.

A feature precisa de uma definição de sucesso

Antes de lançar uma funcionalidade, existe uma pergunta que nem sempre fazemos:

o que precisa acontecer para considerarmos isso um sucesso?

Não precisa ser uma previsão extremamente precisa.

Mas deveria existir algum critério.

Se estamos criando uma nova forma de onboarding, talvez esperemos aumentar a conclusão do fluxo.

Se estamos adicionando atalhos para ações recorrentes, talvez esperemos reduzir tempo ou passos.

Se criamos uma área de relatórios, talvez seja importante observar se ela é utilizada repetidamente.

Se melhoramos uma busca, talvez a quantidade de pesquisas sem resultado seja mais relevante do que o número total de pesquisas.

Quando isso é definido apenas depois do lançamento, existe um risco.

Começamos a procurar nos dados alguma métrica que justifique aquilo que já fizemos.

Quando o critério existe antes, os dados podem realmente confrontar nossa expectativa.

E isso é mais útil.

Às vezes, ninguém usar é a resposta

Existe uma parte desconfortável em medir.

Podemos descobrir que algo em que investimos bastante trabalho quase não é usado.

Não existe erro.

O tracking está correto.

A funcionalidade está disponível.

As pessoas simplesmente não demonstram interesse.

A reação imediata pode ser tentar promover mais.

Mover o botão.

Adicionar destaque.

Criar um banner.

Enviar notificações.

Às vezes, isso faz sentido.

Mas também existe outra possibilidade:

talvez a feature simplesmente não seja importante.

Esse tipo de conclusão é difícil porque existe investimento emocional e técnico no que foi construído.

Só que produto não melhora porque defendemos nossas decisões anteriores.

Melhora quando conseguimos revisá-las.

Uma feature pouco utilizada não representa automaticamente um erro.

Mas representa uma pergunta que merece ser feita.

Analytics também ajuda a remover

Costumamos associar dados a descobrir o que construir.

Mas eles também ajudam a descobrir o que pode desaparecer.

Produtos acumulam funcionalidades.

Algumas nasceram de necessidades que já não existem.

Outras foram substituídas por fluxos melhores.

Algumas são mantidas porque alguém acredita que determinados usuários ainda dependem delas.

Sem dados, remover qualquer coisa parece arriscado.

Com alguma instrumentação, conseguimos pelo menos entender o tamanho da decisão.

Quem ainda utiliza?

Com qual frequência?

Existe algum segmento específico dependente disso?

Que outras ações normalmente acontecem junto?

Isso não torna a remoção automática.

Mas torna a discussão mais concreta.

Às vezes, entender o que ninguém usa é tão importante quanto descobrir o que deveríamos construir em seguida.

O frontend está mais próximo dessa decisão do que parece

É comum pensar em analytics como responsabilidade exclusiva de produto ou marketing.

Mas a instrumentação frequentemente nasce dentro da aplicação.

Um evento precisa ser disparado no momento correto.

Com propriedades que façam sentido.

Sem duplicidade.

Sem depender de comportamentos frágeis.

E, principalmente, representando a intenção certa.

Existe uma diferença entre registrar:

button_clicked

e

report_export_started

O primeiro descreve uma interação visual.

O segundo descreve uma ação de produto.

Se amanhã mudarmos aquele botão por um menu, a intenção continua existindo.

Essa distinção parece pequena, mas muda a qualidade dos dados ao longo do tempo.

Instrumentação também é arquitetura.

Os nomes que escolhemos, as propriedades que enviamos e os momentos em que os eventos acontecem criam uma espécie de contrato sobre como interpretamos o comportamento dentro do produto.

Quando isso cresce sem critério, analytics acumula dívida da mesma forma que código.

Dados também precisam de confiança

Existe outro problema pouco discutido.

Um dashboard bonito não serve para muita coisa se ninguém confia nele.

Eventos podem disparar duas vezes.

Alguns usuários podem gerar dados incompletos.

Uma alteração no frontend pode quebrar tracking silenciosamente.

Ambientes de desenvolvimento podem contaminar números de produção.

Um evento pode mudar de significado ao longo do tempo sem mudar de nome.

Quando isso acontece, o time começa a desconfiar das métricas.

E métricas em que ninguém confia deixam de participar das decisões.

Por isso, analytics não deveria ser tratado como código descartável.

Se determinada informação influencia uma decisão importante de produto, a coleta dessa informação também merece cuidado.

Não necessariamente o mesmo nível de rigor de uma transação financeira.

Mas rigor suficiente para sabermos o que estamos olhando.

Nem tudo precisa virar evento

Também existe um limite importante.

Usuários não são apenas linhas em um funil.

Existem coisas que analytics quantitativo não explica bem.

Por que alguém abandonou?

Por que determinada palavra confundiu?

Por que uma feature parece pouco confiável?

Por que alguém criou um processo alternativo fora da aplicação?

Às vezes, a resposta está em uma conversa.

Em uma sessão de suporte.

Em uma entrevista.

Em um feedback aberto.

Em observar alguém utilizando o produto.

Dados quantitativos ajudam a mostrar o que está acontecendo.

Nem sempre explicam por que.

Produtos melhores normalmente surgem da combinação dessas duas coisas.

O comportamento mostra onde olhar.

O contexto ajuda a entender o que estamos vendo.

Indo além da criação

Quando uma feature está em desenvolvimento, quase tudo gira em torno daquilo que esperamos que aconteça.

Esperamos que o usuário encontre.

Esperamos que entenda.

Esperamos que complete.

Esperamos que volte.

Depois do lançamento, finalmente podemos começar a substituir expectativa por evidência.

Essa talvez seja uma das mudanças mais importantes quando deixamos de pensar apenas em criação e começamos a pensar em produto.

O trabalho não termina quando conseguimos colocar uma funcionalidade diante do usuário.

Existe outra etapa:

observar.

Entender.

Questionar.

E decidir novamente.

Porque uma feature em produção pode estar tecnicamente perfeita.

Pode ter uma interface bem construída.

Pode ter uma copy clara.

E ainda assim não produzir o resultado que imaginávamos.

Lançar mostra que conseguimos construir.

O uso mostra se construímos algo que importa.