Contar logins ou cliques pode indicar que alguém interage com um produto, mas não demonstra que um recurso resolve um problema. Para priorizar melhorias, as métricas de uso em SaaS devem relacionar comportamentos observáveis a perguntas de produto: quem usa um recurso, com que frequência, em que contexto e em que ponto abandona um fluxo.
Uma instrumentação útil começa antes de escrever código. Se um evento não pode orientar uma decisão, provavelmente é ruído. O objetivo não é registrar cada ação disponível, mas construir sinais consistentes que permitam entender a adoção, detectar atritos e verificar se uma intervenção muda o comportamento esperado.
Começar pela decisão, não pelo evento
Formulem primeiro a pergunta que querem responder. Por exemplo: “Que proporção de contas configura uma integração nos primeiros 14 dias?” é mais acionável do que “Quantas vezes o botão de integração foi clicado?”. A primeira define uma população, uma ação e uma janela temporal; a segunda apenas descreve atividade.
Para cada métrica, documentem:
- Decisão: o que a equipe poderia mudar se o sinal aumentar, diminuir ou permanecer estável.
- População: quais usuários, contas ou planos são incluídos e quais são excluídos.
- Comportamento: qual ação observável conta como uso significativo.
- Período: quando começa e termina a janela de observação.
- Limitações: o que a métrica não permite concluir.
Se a resposta não alteraria uma prioridade, uma hipótese ou uma investigação, não é necessário instrumentá-la ainda. Por outro lado, uma pergunta sobre abandono pode exigir eventos de início e conclusão de um fluxo, e não um contador geral de atividade.
Definir eventos com um esquema estável
Um evento deve ter um nome compreensível e uma definição compartilhada entre produto e desenvolvimento. Uma estrutura prática inclui o nome, o ator, a conta associada, o momento de emissão e um contexto mínimo. Por exemplo, report_export_completed deve significar que a exportação foi concluída com sucesso, não que o botão foi exibido nem que uma requisição foi iniciada.
Documentem também as propriedades permitidas e seus tipos: identificador interno da conta, tipo de exportação ou resultado. Evitem nomes ambíguos como action e valores livres que misturem conceitos. Se o significado de um evento mudar, registrem a alteração ou introduzam uma versão do esquema; caso contrário, uma série histórica pode combinar comportamentos distintos sem que os relatórios indiquem isso.
Definam com precisão o momento de emissão. Para medir a conclusão, enviem o evento após confirmar o resultado, não antes de executar a operação. Em processos assíncronos, separem início, sucesso e falha se essas etapas responderem a perguntas diferentes. Não chamem de “concluído” um processo que apenas foi colocado na fila.
Separar usuários, contas e fluxos
Em SaaS B2B, uma pessoa e uma conta empresarial não são a mesma unidade de análise. Um usuário pode pertencer a uma organização; vários usuários podem utilizar um recurso nessa conta. A adoção por conta responde quantas organizações incorporaram um recurso. A atividade individual mostra quem o utiliza e com que regularidade. Ambas as perspectivas são válidas, mas não devem ser misturadas no mesmo denominador.
Por exemplo, para avaliar um recurso colaborativo, vocês podem medir a proporção de contas elegíveis com pelo menos uma ação válida e, separadamente, quantos usuários distintos participam em cada conta. Definam o que significa “elegível”: uma conta sem acesso ao recurso não deve aparecer como não adotante. Combinem também como tratar uma conta com vários espaços de trabalho ou usuários que mudam de organização.
Para entender um fluxo, estabeleçam etapas observáveis, como início, validação e conclusão. Comparem o número de entidades que chegam a cada etapa usando uma identidade consistente. A taxa de abandono só é interpretável se souberem qual população entrou no fluxo, por quanto tempo se espera sua conclusão e como são tratadas tentativas repetidas ou processos ainda abertos.
Prevenir duplicatas e atividades que não representam uso
Um mesmo comportamento pode ser registrado duas vezes se o navegador repetir uma requisição, uma fila processar uma mensagem novamente ou uma chamada terminar sem que o cliente receba confirmação. Usem uma chave de idempotência ou um identificador único de operação quando apropriado e definam no sistema analítico qual evento representa a ação de negócio contabilizável.
Separem as ações de pessoas das tarefas automáticas. Uma sincronização programada, um trabalho de manutenção ou uma chamada interna não deve inflar o uso atribuível a um usuário. Se for importante medir a atividade automática, identifiquem-na com um ator ou tipo de origem diferente e excluam-na dos indicadores de adoção humana.
Também é preciso resolver mudanças de identidade: convites, baixas, fusões de usuários e contas migradas. Estabeleçam uma regra consistente para a identidade analítica, evitando usar o endereço de e-mail como identificador permanente. Um identificador interno pseudônimo costuma ser mais estável e reduz a exposição de dados pessoais.
Instrumentar em PHP sem acoplar a analítica ao negócio
A lógica de negócio deve determinar se uma operação é permitida e qual é seu resultado. A analítica registra esse resultado, mas não deve decidi-lo. Se uma chamada ao provedor de analítica falhar, normalmente isso não deve impedir que o usuário conclua uma exportação ou salve uma alteração.
Em uma aplicação PHP, vocês podem emitir eventos a partir de um serviço de aplicação após confirmar a operação relevante e enviá-los por meio de uma fila ou de um mecanismo desacoplado quando a confiabilidade exigir. Se a consistência entre a transação de negócio e o registro for crítica, avaliem o padrão outbox: salvar o evento pendente junto com a alteração e publicá-lo depois. A escolha depende do risco de perda, do volume e da arquitetura; nem todos os produtos precisam da mesma complexidade.
Centralizem o esquema e as convenções, em vez de criar eventos dispersos com propriedades diferentes em cada controller. Apliquem limites e validações, registrem erros de entrega sem expor dados sensíveis e evitem que as regras de negócio dependam de uma resposta da analítica.
Minimizar dados e validar a instrumentação
Coletem apenas os dados necessários para responder à pergunta definida. Não enviem senhas, conteúdo de documentos, tokens, dados de pagamento nem texto livre para a analítica. Revisem identificadores e propriedades que possam revelar informações pessoais, restrinjam o acesso por função e estabeleçam uma política de retenção compatível com a finalidade e as obrigações aplicáveis.
Antes de confiar em um indicador, testem os eventos com cenários concretos: operação bem-sucedida, falha de validação, nova tentativa, envio duplo, usuário sem permissões e processo automático. Verifiquem se o evento aparece uma única vez, se contém o ator e a conta esperados e se é emitido no momento correto. Adicionem verificações operacionais para detectar quedas bruscas de volume, propriedades ausentes ou mudanças na proporção de erros.
A validação não termina quando o código é implantado. Comparem registros de amostra com a ação real, verifiquem os filtros e denominadores dos relatórios e revisem as alterações no esquema. Um aumento repentino pode ser causado por uma nova integração, um erro de duplicação ou uma alteração de identidade, e não por uma melhora na adoção.
Interpretar sinais e transformá-los em testes
Tendências e coortes ajudam a comparar grupos definidos por uma condição comum, como a data de cadastro ou o uso inicial de um recurso. Indiquem sempre o período, o tamanho do grupo e os critérios de inclusão. Uma melhora na conversão após uma alteração é um sinal para investigar, não uma prova automática de que a alteração a causou: sazonalidade, composição dos clientes, campanhas ou mudanças simultâneas podem ter influenciado o resultado.
Transformem a observação em uma hipótese verificável. Por exemplo: “As contas que não concluem a conexão param durante a autorização; mostrar instruções específicas deve aumentar as conexões válidas”. Definam antecipadamente a métrica principal, as métricas de proteção — como erros ou solicitações de suporte — e o período de avaliação. Quando for viável, usem uma comparação controlada; caso contrário, combinem a tendência com entrevistas, revisão de sessões ou análise de incidentes, sem apresentar evidências correlacionais como causais.
Uma métrica útil permite decidir o que fazer a seguir, não apenas informar o que aconteceu. Revisem periodicamente se cada evento mantém uma definição clara e se continua respondendo a uma decisão real. Assim, a analítica acompanha o produto: oferece sinais confiáveis, mantém seus limites visíveis e orienta testes que podem confirmar ou refutar uma hipótese.
