PostHog

PostHog: migramos do silo de dados na rotina técnica

PostHog entrega resultado em fluxo de trabalho? Na minha avaliação, sim: migramos nossa infraestrutura de analytics para ele neste trimestre e a resposta curta é que ganhamos muito mais do que perdemos. Ter rastreamento de eventos, replays de sessão e feature flags nativos em um único ecossistema de código aberto acabou com os silos de dados que travavam nosso time. A ressalva é que a interface do backend fica pesada conforme os módulos novos chegam. Como o PostHog substituiu três ferramentas fechadas na nossa stack A migração não foi um capricho técnico. Antes dela, a gente mantinha três SaaS de ecossistema fechado convivendo mal: um para eventos, outro para gravação de sessão e um terceiro só para liberar flags. Cada um com seu modelo de cobrança, seu jeito de nomear eventos e sua própria exportação. Quando precisávamos cruzar um replay com a flag que liberou a mudança, o caminho era planilha, exportação manual e paciência. Ao consolidar tudo no PostHog, o ganho mais imediato foi a integração nativa com nosso data warehouse. Os logs de eventos passam a ser roteados direto para o destino que já usávamos, sem aquele overhead de API manual que antes consumia sprint inteira de engenharia. Deixamos de escrever job de sincronização e passamos a cuidar de produto. O segundo ganho foi econômico e político. Três contratos viraram um, e a conversa sobre qual time é dono de qual métrica deixou de existir, porque a fonte passou a ser única. Isso devolveu uma faixa de banda real para o time de engenharia, que gastava tempo demais colando dados de ferramentas diferentes antes de qualquer decisão. Como código aberto, ganhamos ainda a possibilidade de olhar o código quando algo parece estranho, o que muda a relação de confiança com o fornecedor. A interface do backend fica pesada com tantos módulos novos Aqui vem a parte que ninguém coloca na landing page. O PostHog entrega módulo novo em ritmo agressivo, e isso é ótimo para quem quer recurso, mas cobra seu preço na navegação. O backend, que é onde a gente realmente opera, vai ficando cheio. Menu que cresce, seções que se sobrepõem, caminhos diferentes para chegar ao mesmo relatório. Em dia de investigação de incidente, isso pesa. Notei também que a curva de aprendizado não é igual para todos. Quem é de produto aprende rápido o caminho do replay de sessão, mas se perde quando precisa montar um funil mais elaborado ou entender por que um evento aparece duplicado. Já quem é de operações sente mais falta de atalhos e de visões salvas com um clique, porque o excesso de opções na tela transforma uma tarefa simples em garimpo. Nada disso é defeito fatal, e é bom deixar claro: a plataforma é sólida e o ritmo de entrega é justamente o motivo de ela ter substituído três fornecedores. O ajuste prático que fizemos foi padronizar um conjunto pequeno de dashboards oficiais e treinar o time a partir deles, em vez de deixar cada pessoa explorar o backend inteiro sem mapa. Reduziu reclamação e reduziu retrabalho. Gestão de permissões: o que evita gargalo para quem não é técnico O ponto que mais exige disciplina é o controle de permissões por workspace. Se você libera tudo para todo mundo, membros de time que não são de operações batem em um gargalo silencioso na hora de puxar um relatório simples. Não é falta de capacidade técnica deles, é excesso de superfície: filtro demais, nomenclatura demais, contexto demais sem explicação. O que funcionou para nós foi separar papéis por função real de trabalho, não por senioridade. Um grupo com acesso a criação de eventos e flags, um grupo com acesso a leitura de dashboards prontos e um grupo intermediário que monta consultas mas não altera configuração de coleta. Depois disso, o volume de pedido interno do tipo me ajuda a achar aquele número caiu bastante. Também passamos a documentar dentro do próprio workspace o que cada evento significa e quem é o dono dele. Parece burocracia, mas é o que impede a base de virar um depósito de nomes duplicados. Em um ambiente de código aberto com integração direta ao warehouse, a qualidade da taxonomia é o que separa análise de adivinhação, e essa parte é responsabilidade do cliente, não da ferramenta. Fechando o balanço, a migração valeu cada hora de setup. Trocamos três contratos e três modelos de dados por uma plataforma só, com eventos, replays e flags conversando entre si e com o nosso warehouse. A interface do backend poderia ser mais enxuta e o onboarding de quem não é técnico merecia mais carinho, mas nada disso apaga o ganho de banda que o time de engenharia recuperou. Se você tem silos de dados acumulando e quer centralizar de verdade, é uma escolha que eu repetiria sem hesitar.