Estatísticas do Site

[filipedeschamps]

Contexto

Algo que eu acredito ser muito importante para mensurarmos nosso progresso é visualizar de uma forma fácil e pública as estatísticas do site.

Execução

Não sei muito bem como executar esse ponto e procuro por ideias. Mas algo que precisa ser respeitado é não fazer nenhum tracking individual de usuários e não mandar nenhuma informação para sistemas malucos e daí ter que pedir aquela autorização de cookie maluco e usar esses dados de forma ultra malígna... não... caramba chega desse tipo de internet.

Vamos montar estatísticas para nós usuários do site e criadores de conteúdo para entender o nosso próprio trabalho.

O pontapé inicial poderia ser tão simples quanto uma tabela/gráfico mostrando quantos usuários se cadastraram/ativaram no site ao longo dos dias. Ou quantas notícias foram criadas... comentários, etc. Qualquer informação que mostre que o site está crescendo e novas pessoas estão vindo formar essa comunidade massa, com conteúdos massa.

E novamente, podemos mirar em algo bem simples, uma entidade especializada nessas estatísticas, uma página gerada estaticamente com revalidate razoável e expor isso na API.

Se quisermos, essa página também pode trazer o que é mostrado por esse endpoint: https://www.tabnews.com.br/api/v1/status Não digo mostrar tudo, só o mais importante para saber que está tudo ok.

[liverday]

Nas empresas onde eu trabalhei, sempre tivemos um serviço relacionado a esse tipo de entidade. Sendo ela chamada de Metric, Event ou Indicator, o interessante é que isso se repete na necessidade de conseguirmos ter um "mapa" de progresso da App.

Tem várias estratégias de seguir nesse tipo de tracking, seja com uso de ferramentas como Google Analytics, ou através do nosso próprio desenvolvimento, que é o que eu sugiro, pois conseguiremos escalar depois.

Caso o escolhido seja partir pro desenvolvimento, tenho duas sugestões:

1 - Usar uma Entidade genérica com padrão schemaless

Podemos criar uma entidade específica com um padrão schemaless usando JSONB para permitir injetarmos metadados em uma determinada métrica.

Vantagens

• Todas as métricas em uma única entidade.
• Possibilidade de incluirmos metadados sem a necessidade de termos mais "colunas".
• Menor complexidade de escrita do dado no banco (implementar o modelo no momento de escrita é mais fácil).

Desvantagens

• Complexidade na hora de extrair os dados (vai requerer uma query mais complexa pra saber quantos "clicks" determinada notícia teve, por exemplo)
• Dificuldade pra conseguirmos relacionar dados entre si.

2 - Usar Entidades específicas para determinado tipo de métrica

Podemos fazer com que todo tipo de dado "metrificável" tenha uma tabela específica correspondente pra isso. Exemplo disso é termos uma tabela posts pra armazenar os posts e post_visitors pra armazenar os eventos das pessoas que passaram pelo Post

Vantagens

• Facilidade na extração dos dados, é fácil relacionar um post com seus visitantes e vice-versa.
• Conseguimos especializar todo tipo de consulta nessas entidades, fazendo com que o desenvolvimento delas escale mais rápido

Desvantagens

• Esse tipo de abordagem requer uma melhor gerência na abstração das entidades, pra não termos muitos modelos que possam fazer a mesma coisa ou coisas similares
• Métricas expandem continuamente, que se desordenado, pode gerar problemas de gerência.

Essa é a minha contribuição pra discussão e pode ser que eu não ajudei muito, mas acha que faz sentido alguma delas?

[filipedeschamps]

@liverday cara achei sensacional todo mapa que escreveu, muito bom e nem tinha passado pela minha cabeça essas soluções, adorei o schemaless 🤝 O que eu tinha pensado para montar a página era fazer uma query (um count) direto na fonte, nas entidades que a gente tem interesse em analisar, por exemplo ir direto na tabela users (meio que é o "source of truth" desse dado), mas novamente a sua sugestão é bem interessante porque dá uma flexibilidade muito boa.

E isso me fez pensar onde certos valores deveriam estar anotados, como você comentou, visualização dos Conteúdos (na tabela dos conteúdos ou outro lugar?), e daí mais para frente quantidade de TabCoins dos Conteúdos e Usuários, e outras coisas.

O que acha de nessa primeira versão montarmos uma página, até sem API mesmo pra ser realmente uma POC que a gente jogue fora depois e que fazemos as queries diretamente dentro do getStaticProps usando o database.js? É realmente algo para ser jogado fora depois, que é fácil de executar e vai nos dar tempo para elaborarmos melhor o sistema de estatística e o que queremos dele.

E sobre o Google Analytics e sistemas parecidos, sugiro que a nossa postura seja banir esse tipo de solução por privacidade ao usuário 👍 então ou a gente auto-hospeda algo open source, ou a gente faz o nosso de uma forma bem simples e direcionada 🤝

[liverday]

Acredito que podemos seguir assim por enquanto e ir refinando conforme as necessidades.
Deixa que essa eu faço! Haha

Tem algum modelo de interface desejada?

[filipedeschamps]

Showww @liverday que massa 😍

Por enquanto, se basear nessas duas abaixo e pode copiar/colar/duplicar código sem problema, porque não vai ser agora que vamos desenvolver um design system. Vamos deixar para um próximo passo, então faça o que for necessário para mostrar os dados de uma forma legal 👍

• https://www.tabnews.com.br/pocs/home-08
• https://www.tabnews.com.br/pocs/post-01

[andrefd17]

Já usei o jsonb exatamente pra isso em um projeto juntamente com pandas no python, funciona super bem para esse intuito!

Também poderíamos criar um audit que "escuta" e armazena eventos que acontecem no sistema e daí usar isso pra "alimentar" as estatísticas?

Em relação aos eventos, estes poderiam ser criados com timestamp, o que poderia ser usado pra construir uma "timeline" de evolução.

E esses eventos poderiam ser por exemplo:

• Novos usuários
• Quantos Tabcoins Gerados x Gastos
• Quantos conteúdos (Posts) criados

O que acham?

[liverday]

Também poderíamos criar um audit que "escuta" e armazena eventos que acontecem no sistema e daí usar isso pra "alimentar" as estatísticas?

Gosto bastante disso aqui, mas precisamos entender as limitações quanto projeto. Por enquanto podemos ir para uma ação faseada, onde podemos segmentar as ações da seguinte forma:

• Criamos uma página que busca as informações desejadas direto nas fontes, usando o tradicional database.js
• Criamos um modelo para lidar com as métricas/eventos em si, e criamos um mecanismo pra conseguirmos escrever e consultar de qualquer lugar do tabnews, através de um modelo event.js
• Criamos rotas específicas para consumo e escrita dessa informação, como POST /events e GET /events
• Isolamos essas rotas em uma segunda aplicação/deployment. Essa parte aqui é importante pois é esperado que essas rotas tenham um volume muito grande entre todo o tabnews uma vez que formos pro ar.

O que vocês acham? faz sentido? De qualquer forma, vou começar a implementação inicial!

[rodrigoKulb]

O que eu tinha pensado para montar a página era fazer uma query (um count) direto na fonte, nas entidades que a gente tem interesse em analisar, por exemplo ir direto na tabela users (meio que é o "source of truth" desse dado).

Esse sistema no inicio funciona muito bem, porem é importante pensar em armazenar em cache as informações, para evitar o consumo dessas tabelas principais de forma desnecessária.

Segue um exemplo de Estatísticas aberta em um portal que gosto muito:

https://www.vivaolinux.com.br/estatisticas.php

[inovaprog]

@rodrigoKulb dá pra usar um banco só de leitura (meio que uma cópia do banco original ) só pra trabalhar essas métricas que as vezes tem um processamento mais trabalhoso. e esse banco espelha as tabelas usadas em produção mesmo.

[sembug]

@rodrigoKulb Outra opção é prepararmos essas estatísticas em D-1 e inserirmos em uma tabela. Não precisaríamos fazer um cache e ainda ganhamos um histórico de evolução do site.

[rodrigoKulb]

@inovaprog gostei da sugestão😊️! Levando em conta o que o @filipedeschamps pediu aqui:

• Usuários
  Cadastrados
  Ativaram
• Noticias
  Cadastradas
• Comentários
• Cadastrados

Acredito que a sugestão do @sembug seja a melhor forma, podemos armazenar essas informações no momento do cadastro / ativação sempre somando +1 nessa tabela de relatório / analytics.

Desta forma não precisa nem ser D-1, podemos seguir com a informação real, apenas utilizando uma tabela separada já com a somatória.

Acredito que o total por DIA assim podemos depois somar por mês facilmente.

O que acham?