Como medir a adoção de features

A taxa de adoção de uma feature é a proporção de usuários elegíveis que de fato a usam. A fórmula é simples — adotantes dividido pela população que poderia adotá-la — mas o número não significa nada até você definir três coisas: quem conta como elegível (amplitude), com que profundidade a usam (profundidade) e em qual janela de tempo (tempo). Erre nisso e você lança um dashboard que diz 80% quando o número honesto é 12%. Isto é um how-to: instrumente a feature, calcule as três métricas e aja sobre elas.

Pré-requisitos

• Uma ferramenta de analytics que capture eventos custom atrelados a um ID estável de usuário/conta — Amplitude, Mixpanel, Heap ou Pendo. O Heap auto-captura clicks (menos instrumentação inicial, taxonomia de eventos mais bagunçada); Amplitude e Mixpanel precisam de chamadas explícitas de track() (mais trabalho, dados mais limpos).
• Uma “população elegível” definida. Nem todo usuário pode usar toda feature — uma feature por trás de um plano Enterprise tem como denominador os seats Enterprise, não todos os seats. Escreva essa regra antes de calcular qualquer coisa.
• Uma definição do que significa “usar a feature” como um ou mais eventos concretos, não um page view. Abrir a página não é adoção; completar a ação central é.

Passo 1 — instrumente a ação central, não a página

Dispare um único evento nomeado na ação que entrega o valor da feature. Para uma feature de exportação em massa, o evento é bulk_export_completed, não export_page_viewed. No Amplitude ou Mixpanel, adicione a chamada track('bulk_export_completed', { row_count, format, account_id }) no callback de sucesso da exportação, depois que o arquivo é gerado — nunca no click do botão, porque os clicks incluem falhas e rage-clicks. No Pendo ou Heap você pode tagear o elemento do DOM no estado de sucesso, mas um evento do lado do servidor é mais confiável porque sobrevive a ad-blockers e crashes do cliente.

Anexe account_id e plan_tier como propriedades do evento para depois conseguir filtrar o denominador às contas elegíveis. Sem isso, você consegue calcular a amplitude sobre todos os usuários mas nunca sobre a população elegível — e o número da população elegível é o que importa.

Passo 2 — calcule as três fórmulas

Amplitude   = adotantes / usuários elegíveis        (eles chegaram a tocá-la?)
Profundidade = ações centrais / adotante            (o quanto se apoiam nela?)
Tempo       = adotantes dentro de N dias de elegibilidade / usuários elegíveis nesse cohort

• Amplitude é a taxa de adoção principal. Um adotante é qualquer usuário elegível que disparou o evento central pelo menos uma vez na janela. A amplitude responde “essa feature pegou afinal?”
• Profundidade separa uma feature que as pessoas testam uma vez de uma feature da qual as pessoas dependem. Calcule-a apenas sobre os adotantes (não a base inteira), ou uma amplitude baixa vai mascarar uma profundidade alta. Uma feature com 15% de amplitude e 40 ações por adotante por mês é uma feature de power-user, não um fracasso — trate-a diferente de uma com 15% de amplitude e 1.2 ações.
• Tempo de adoção é a amplitude medida contra um relógio de cohort. “Que proporção de contas que se tornaram elegíveis em março usou a feature dentro de 30 dias?” Esta é a métrica que diz se seu onboarding torna a feature visível, e é a que a maioria dos times pula.

Exemplo trabalhado: uma feature é gateada a 500 contas Enterprise. Numa janela de 30 dias, 145 dispararam o evento central, gerando 1.160 ações centrais no total. Amplitude = 145 / 500 = 29%. Profundidade = 1.160 / 145 = 8 ações por adotante. Se apenas 60 das 145 adotaram dentro de 30 dias de se tornarem elegíveis, tempo de adoção(30d) = 60 / 500 = 12%.

Passo 3 — escolha a janela deliberadamente

A janela não é cosmética. Uma feature de uso diário (um dashboard) deve ser medida sobre uma janela ativa móvel de 7 ou 28 dias — alguém que a usou no trimestre passado não é um adotante hoje. Uma feature de uso trimestral (uma exportação de compliance) precisa de uma janela de 90 dias ou você vai reportar churn que é só sazonalidade. Case a janela com a cadência natural da feature, escreva-a na definição da métrica e nunca compare duas features medidas em janelas distintas.

Passo 4 — fixe o piso do denominador

Para uma feature com menos de um ciclo de release de idade, a população elegível ainda está crescendo, então a amplitude fica artificialmente deprimida por contas que se tornaram elegíveis ontem. Exclua contas elegíveis por menos que a cadência natural da feature (ex.: descarte contas elegíveis por menos de 28 dias para uma feature de uso semanal). Reporte amplitude sobre a população madura e tempo de adoção sobre o cohort completo — elas respondem perguntas distintas.

Como é o bom

Não existe benchmark universal; a taxa de adoção é específica de cada feature. Uma feature de workflow central na faixa de 40-60% de amplitude é saudável; uma feature de power-user ou de admin vivendo em 5-15% de amplitude pode ser totalmente bem-sucedida se a profundidade for alta entre os poucos que a adotam. O número que deveria te alarmar é uma feature com amplitude baixa e profundidade baixa depois de uma janela de cadência completa — essa é uma feature que ninguém precisava, e a ação é descontinuá-la ou reconstruí-la, não empurrar mais forte no enablement.

Agir sobre os dados

• Amplitude baixa, profundidade alta — problema de descoberta. Quem a encontra adora. Torne-a visível no onboarding e in-app (guias do Pendo, prompts de empty-state), depois meça o tempo de adoção de novo.
• Amplitude alta, profundidade baixa — valor superficial ou uma feature de uso único. Se ela deveria ser recorrente, o momento de ativação não está fixando; investigue a queda do segundo uso.
• Amplitude baixa, profundidade baixa, janela completa transcorrida — candidata a eliminar. Confirme com um cross-tab de churn/expansão antes de descontinuá-la, mas não continue investindo enablement numa feature que a população elegível rejeitou.

Erros comuns

• Page views como adoção. Contar page_viewed infla a amplitude com todos que entraram por acidente. Guarda: o evento central dispara no callback de sucesso da ação que entrega valor, nunca na navegação ou no click.
• Denominador = todos os usuários. Dividir pelo total de contas quando a feature é gateada por plano subestima a adoção entre quem de fato pode usá-la. Guarda: filtre o denominador por plan_tier/entitlement, definido no Passo 1.
• Sem janela, ou janelas desemparelhadas. Um número acumulado vitalício de “já usou alguma vez” só sobe e não diz nada sobre a saúde atual. Guarda: defina uma janela móvel casada com a cadência da feature (Passo 3) e nunca compare features medidas em janelas distintas.
• Amplitude e profundidade tiradas na média juntas. Reportar “ações médias por usuário” sobre a base inteira mistura adotantes e não-adotantes num meio sem sentido. Guarda: calcule a profundidade apenas sobre os adotantes.

Relacionados

• NRR vs GRR — a adoção é um indicador antecedente da retenção
• Pendo — guias in-app para impulsionar a adoção de features de amplitude baixa
• Amplitude — análise de cohort e funnel para o tempo de adoção