Pageview é a métrica mais fácil de coletar e uma das menos úteis para decisões de produto. O que medir depende do que se está tentando entender.
Todo mundo mede pageview. É o número que aparece em primeiro lugar no Google Analytics, é fácil de entender e fácil de reportar. O problema é que pageview não diz nada sobre se o usuário encontrou o que procurava, se voltou, ou se a visita resultou em qualquer coisa relevante para o negócio.
Eric Ries, em The Lean Startup (2011), cunhou o termo que descreve bem esse tipo de número: vanity metrics, ou métricas de vaidade. São métricas que sobem, deixam todo mundo satisfeito, e não respondem a pergunta que importa: “o que a gente deveria fazer diferente?” Pageview, seguidores, impressões, downloads — todas têm essa característica em comum. Crescem sem necessariamente indicar progresso.
A oposição que Ries propõe é com as actionable metrics, métricas acionáveis: aquelas em que existe relação clara entre causa e efeito, e que ajudam a decidir o próximo passo.
Em plataformas editoriais ou de blog, o mais importante não é quantas páginas foram vistas. É se o conteúdo foi consumido. Scroll depth, tempo na página e taxa de retorno são indicadores muito mais úteis do que pageview bruto.
Um artigo com 10.000 pageviews e 15 segundos de tempo médio na página está servindo para uma coisa muito diferente de um artigo com 3.000 pageviews e 4 minutos de tempo médio. A decisão de investir em mais conteúdo desse tipo depende de saber qual dos dois está performando melhor, e pageview não responde essa pergunta.
Outras métricas que costumam revelar mais: percentual de leitores que chegam ao final do texto, taxa de cliques em links internos, e quantidade de retornos no mesmo mês. Cada uma indica algo distinto sobre como o conteúdo está sendo usado.
Em SaaS ou plataformas de serviço, as métricas que importam giram em torno de ativação, retenção e receita. O framework mais conhecido para pensar isso é o AARRR, ou “pirate metrics”, proposto por Dave McClure em 2007: Acquisition, Activation, Retention, Referral, Revenue. Cinco estágios do ciclo de vida do usuário, cada um com perguntas específicas.
Não é necessário aplicar o framework inteiro. O valor está na sequência: aquisição que não vira ativação, ativação que não vira retenção, retenção que não vira receita. Cada degrau identifica onde está o gargalo real. Times que olham só para aquisição (a métrica mais fácil de inflar) costumam descobrir tarde que a retenção está vazando o funil.
O excesso de métricas é tão problemático quanto a falta. Dashboards com 40 indicadores não orientam decisões. Paralisam. Alguém precisa decidir quais 3 ou 4 números representam saúde do negócio nesse momento, e o time precisa concordar com essa escolha.
A revisão periódica das métricas monitoradas é tão importante quanto a coleta. O que era relevante no lançamento pode não ser o que importa seis meses depois. Uma plataforma em estágio de aquisição agressiva mede coisas diferentes de uma plataforma em estágio de retenção e crescimento de receita por usuário.
A pergunta de partida é: qual é a decisão que essa métrica vai ajudar a tomar? Se não há resposta clara, a métrica provavelmente não precisa estar no dashboard principal.
Outra pergunta útil, sugerida pela escola Lean: a métrica é manipulável sem que a saúde real do negócio melhore? Pageview pode ser inflado com tráfego pago de baixa qualidade. Cadastros podem ser inflados com cupons que ninguém usa. Quando a métrica pode subir sem que o produto melhore, ela não está medindo o produto.
Métricas existem para reduzir incerteza antes de decisões. Não para preencher relatórios semanais.
Em projetos de plataforma, a gente costuma propor uma conversa específica sobre métricas no início do projeto, antes do design e antes da arquitetura. Não para definir tudo de antemão, mas para alinhar o que o cliente precisa decidir nos próximos doze meses e quais números vão ajudar a tomar essas decisões.
Essa conversa, feita cedo, evita o cenário mais comum: plataforma lançada, dashboard montado pelo time de marketing com tudo que o Google Analytics oferece por padrão, e ninguém olhando porque os números não respondem nada útil. Métrica precisa nascer da pergunta. Não da ferramenta.
Referências consultadas: Eric Ries, “The Lean Startup” (2011) e “Entrepreneurs: Beware of Vanity Metrics”, Harvard Business Review (2010); Dave McClure, “Startup Metrics for Pirates” (2007).
Acessibilidade não é só obrigação legal. É a diferença entre uma plataforma que funciona para todos e uma que exclui parte do mercado silenciosamente.
A escolha de tecnologia para um projeto digital não começa pela tecnologia. Começa pela pergunta certa: o que essa plataforma precisa fazer?
36% das empresas gastam mais tempo resolvendo problemas de APIs do que desenvolvendo funcionalidades. O problema quase nunca é a API. É a documentação tratada como anexo, não como produto.
