[FEATURE/SUGESTÃO] Quantidade de visualizações em uma publicação

[Thiago-Mariotto]

Seria interessante a quantidade de visualizações das páginas, assim a pessoa criadora do artigo teria uma noção do quão impactante foi sua escrita.

Além de ser possível "rankear" as publicações mais visualizadas, etc.

[filipedeschamps]

Entrando nesta issue por sugestão do @aprendendofelipe através desta publicação.

Sugiro de início implementar isto sem influenciar qualquer tipo de ranking, para tentar tirar um pouco o incentivo de querer burlar este valor (que sempre vai ter abuso).

E implementaria isto de forma simples também, mas com o cuidado inicial de:

1. Um tempo mínimo para que um mesmo IP marque uma nova visualização.
2. Um número máximo de visualizações por IP.

[hkotsubo]

Uma dúvida: isso seria apenas para publicações root?

E para comentários, caso tenha, como ficaria? Se eu acesso pelo link direto (por exemplo, https://www.tabnews.com.br/FelipeBarso/b3ca9528-72c3-4fe3-ac99-ffb7f1ac84e9, isso contaria como uma visualização para este post, certo?

Mas e se eu acesso o parent dele (no caso, https://www.tabnews.com.br/filipedeschamps/2c7ef957-0e6c-4ad2-a5b2-a0da2714a87f), isso conta como visualização somente para o parent, ou também para os filhos?

[filipedeschamps]

Excelente pergunta @hkotsubo ! Talvez a lógica inicial (e que pode ser melhorada no futuro) poderia ser: toda vez que um conteúdo é acessado pela "raiz da página" (como no seu exemplo), deveria contabilizar uma visualização para ele. Pelo que lembro, é a mesma página que renderiza um conteúdo root ou uma resposta singular, então se ela fizer um POST para um endpoint de visualizações, vai funcionar automaticamente para os dois casos.

Agora, o que eu faria é somente mostrar a visualização do primeiro nó de conteúdo (e não na árvore das respostas).

[aprendendofelipe]

Sugiro de início implementar isto sem influenciar qualquer tipo de ranking

Concordo totalmente que não deve haver nenhum tipo de ranking nesse sentido. Não só por ser fácil de burlar, mas também porque esse tipo de indicador não diz muito sobre a qualidade do conteúdo, além de estimular clickbait. Se fosse para usar no ranking, talvez teria que rastrear coisas como tempo de permanência na página, tempo de rolagem etc.

Penso que agora é legal mostrar o alcance das publicações apenas como feedback para os autores. Então dependendo da forma que for implementado pode ser melhor mostrar esses dados em um primeiro momento apenas para o autor de cada publicação.

Uma dúvida: isso seria apenas para publicações root?

Pensando em começar da forma mais simples possível, acho melhor começar contando apenas para o primeiro nó de cada página, independentemente de ser root.

[filipedeschamps]

Penso que agora é legal mostrar o alcance das publicações apenas como feedback para os autores. Então dependendo da forma que for implementado pode ser melhor mostrar esses dados em um primeiro momento apenas para o autor de cada publicação.

Sugiro mostrar de forma 100% pública, mesmo que isso crie um novo problema. Vai dar um "ar muito mais vivo" para o TabNews.

Pensando em começar da forma mais simples possível, acho melhor começar contando apenas para o primeiro nó de cada página, independentemente de ser root.

100% 🤝 💪

[hkotsubo]

@aprendendofelipe Talvez fique para outra issue, já que a ideia é simplificar, mas enfim: seria possível fazer de forma retroativa?

Pois lendo aqui eu entendi que vc já sabe a quantidade de visualizações de cada post, então sugiro, se possível, verificar também o quão difícil seria adicionar esta informação para os posts já existentes.

[aprendendofelipe]

seria possível fazer de forma retroativa?

Temos os dados retroativos desde 27 de outubro de 2022, que é a data que adicionamos o Analytics da Vercel.

A Vercel não fornece esses dados via API (daí a dificuldade de torná-los públicos), mas dá para fazer um script para raspar os dados tomando cuidado para não cair em algum rate limit, já que teria que buscar os dados de cada uma das milhares de publicações separadamente.

Talvez fique para outra issue, já que a ideia é simplificar

Se formos fazer essa raspagem, não podemos demorar, pois os dados ficam guardados apenas por 12 meses, então daqui pouco mais de um mês já vamos começar a perder os dados mais antigos.

[aprendendofelipe]

Sugiro mostrar de forma 100% pública, mesmo que isso crie um novo problema. Vai dar um "ar muito mais vivo" para o TabNews.

Penso que ao olharmos para nossos próprios conteúdos, temos uma tendência maior de acompanhar a evolução dos números ao longo do tempo, mas ao olhar para os números de conteúdos de terceiros, olhamos apenas o dado instantâneo. De forma similar à Lei de Zipf, a maioria dos usuários verá os piores números. E esse efeito será ainda mais forte com os usuários orgânicos.

Com isso, vejo dois grandes riscos, tanto em probabilidade como em impacto negativo:

1. Dar um "ar mais morto" do que o real;
2. Estimular comportamentos indesejados;

Poucas publicações chegam a números altos de visualizações nas primeiras horas, ou seja, os usuários orgânicos do TabNews verão muitos números baixos e poucos altos. Mesmo entre os usuários esporádicos que vem pelo Google, apenas os mais atrasados verão os números melhores.

E o pior é que os usuários verão números altos com mais frequência nas publicações mais polêmicas, que hoje são a exceção, mas podem virar regra se seguirmos os mesmos caminhos das outras redes que focam em cliques a qualquer custo. No TabNews as publicações mais relevantes tem cauda longa, então acabam recebendo mais acessos ao longo de alguns dias após terem sido publicadas, pois recebem muitas visitas vindas pelo Google (busca e discover).

Pensando em como podemos mitigar esses riscos... Talvez mostrar os números publicamente, mas não em tempo real, ou seja, mostrar os resultados das publicações após certo intervalo de tempo, talvez 2 dias, uma semana, não sei...

O que pensam sobre esses riscos e formas de mitigar?

[aprendendofelipe]

Apenas para ilustrar o que digo acima, a publicação abaixo já teve só hoje de manhã bem mais visualizações do que ontem o dia inteiro. Ontem foram 980, e hoje já chegou a 1.440.

Crie GUI modernas e bonitas com Python!

No total ela já tem 2.426 visualizações e continua crescendo. Mas os usuários mais frequentes do TabNews, que viram a publicação ontem pela manhã (ela foi publicada antes de ontem), teriam encontrado que o alcance dela, em média, era de menos de 200 visualizações.

Isso porque 76% das visualizações vieram por recomendação do Google (ou 82% vendo só nas últimas 24 horas):

[filipedeschamps]

Excelente análise 💪 💪 💪

Nessas horas, as vozes da minha cabeça dizem o seguinte: é o tipo de situação com tanta variável, que é a mesma coisa que tentar planejar uma jogada de xadrez com 512 colunas. Qualquer movimento que a gente fizer, a vida vai mostrar que tá tudo "errado".

Vide TabCoins, que começou com um modelo muito frouxo e errado e foi melhorado ao longo do tempo, mas que pensando agora, era o modelo certo de se começar, porque era fácil qualquer um ver que TabCoins era uma coisa que existia de verdade. Assim... nunca dá para saber na verdade, mas ter invertido a ordem (ter começado "certo"), talvez não teria sido melhor.

Então a minha sugestão é implementar de uma forma simples, que revele de verdade o que está acontecendo nas views, para todo mundo, sem querermos esconder nada, e em cima disso a gente dá o próximo passo, sejam eles:

1. Controlar abuso
2. Pessoas tristes porque tem poucas views, pensar como maximizar.

Estes são problemas bons, e eu prefiro eles do que os problemas de ter entrado numa otimização prematura 🤝

[ErickCReis]

Acho que essa feature seria muito interessante.

Eu também não tenho certeza sobre os impactos desse número na publicação e como os usuários vão se comportar, mas acho que uma versão inicial e simplificada pode trazer muitas respostas.

Talvez exibir o número de visualizações apenas ao acessar a publicação possa minimizar os riscos que o @aprendendofelipe citou, já que a listagem não teria essa informação para influenciar o clique do usuário.

---

Também queria iniciar a discussão sobre infraestrutura e custos dessa funcionalidade.

1. A ideia é salvar isso no Postgres mesmo? Ou utilizar o Redis é mais interessante?

Imagino que atualizar esse dado vai ser uma operação muito frequente, e com o Redis da upstash a gente conseguiria "resolver" tudo isso no edge runtime e reduzir os custos.

2. Em uma implementação inicial a gente já teria que lidar com limitação baseadas em ip além das restrições já presentes no rate limit do middleware?

Se sim, isso provavelmente elevaria bastante os custos de armazenamento e operações no banco de dados.

3. @aprendendofelipe você poderia disponibilizar algumas métricas pra gente tentar estimar alguns custos?

Não tenho muita experiência nessa parte, mas acho imagino que os seguintes números podem ajudar:

• Publicações acessadas em um dia.
• Publicações acessadas por usuário por dia (não sei se é possível pegar essa informação).

[aprendendofelipe]

3. @aprendendofelipe você poderia disponibilizar algumas métricas pra gente tentar estimar alguns custos?

Estamos sem analytics na página home /, mas no restante temos uma média aproximada de 6k visitantes por dia e 500k visualizações por mês, mas isso é o líquido, pois o Analytics da Vercel faz uma limpeza dos duplicados.

[Rafatcb]

O PR #1598 trouxe algumas informações novas:

#1598 (review)

Mas, infelizmente, não podemos usar o middleware da Vercel dessa forma para contabilizar as visitas, pois as páginas de conteúdos são estáticas e a navegação em boa parte das vezes é SPA.

A grande maioria das 10M requisições mensais é servida por cache, seja da Vercel ou da Cludflare. O que for servido pelo cache da Vercel a gente até poderia contabilizar, mas isso é cerca de 1/3 do nosso tráfego. Os outros 2/3 são respondidos diretamente pela Cloudflare.

E o que for servido pela Vercel também não tem relação direta com o número de visitas das páginas, pois a maioria das requisições são para pré-carregar dados no cache do navegador, e não saberemos pelo middleware se essa página foi ou não visitada.

Acho que será preciso enviar os dados do client diretamente para um servidor ou endpoint dedicado a fazer essa contabilização, como os serviços de Analytics fazem.

Que tipo de técnica é utilizada como proteção (pelo Google, Vercel etc.) para garantir que a chamada à API de analytics é feita de forma natural, pelo site em questão?

[tiagopaes]

Vou deixar minha sugestão para uma possível solução para essa feature e para o analytics do tabnews em geral. Por que não usamos um sistema de analytics open-source como foco em privacidade como o plausible por exemplo?

[mthmcalixto]

Como falei em #1803 é possível utilizar com apenas uma API simples e retornar o número de visitas que uma postagem teve.

Pelo o que entendi eles guardam os dados por 6 meses, então depois reinicia e começa contar novamente, poderia salvar os dados antes dos 6 meses, a cada 1 semana, talvez;

Parece que eles cobram apenas por "eventos" e não por visitas que a postagem teve, eventos são para rastrear botões, cliques etc...

Seria ideal retornar as visitas, salvar na DB e então fazer verificação por baixo entre dias para atualizar o valor de views.

Como mostrei em #1803 é fácil retornar um dado, uma views de visita em uma postagem.

[mthmcalixto]

@aprendendofelipe abri um PR: #1819

[aprendendofelipe]

@mthmcalixto, eu vi, show! 💪

Não consegui responder antes porque estamos em um período de bastante correria. 😉

O Umami está parecendo uma ótima opção para reduzir nosso custo com analytics e tem grande potencial para ao mesmo tempo permitir compartilhar os dados estatísticos com os usuários do TabNews. Mas precisamos ir um passo de cada vez, primeiro ver se ele mede direito, depois ver se suporta o volume necessário para deixar os dados públicos.

Navegação SPA

Precisamos ver se o Umami contabiliza bem as navegações via SPA do Next.js. Acredito que isso pode exigir mais configurações do que o que está no PR #1819. Resolvendo a configuração, podemos confirmar a compatibilidade comparando se os dados batem com o analytics atual da Vercel.

Mas, para verificar isso sem precisar de uma conta paga do Umami Cloud e nem auto hospedar o serviço, precisamos começar habilitando ele apenas em algumas páginas. Que tal configurar para coletar os dados apenas da página de cadastro e de login? Assim podemos testar mantendo o volume dentro do permitido pela conta gratuita.

Capacidade de leitura

Em paralelo com o teste de compatibilidade com SPA, com a mesma configuração a gente já consegue começar a testar se a API do Umami é viável para deixar os dados públicos. Esse teste é importante, pois imagino que o Umami, como qualquer serviço de analytics, seja muito mais otimizado para inserção de dados do que para leitura. Só que, para usar como contador público de visualizações, a gente precisa que ele funcione bem com um número de leituras na mesma ordem de grandeza das inserções.

Já dá para saber que o rate limit da API da Umami Cloud não seria nem de longe suficiente para nossos momentos de pico. Mas parece que o limite é por chave, então talvez daria para rotacionar as chaves entre as diferentes lambdas. Talvez só dê para fazer isso com a conta paga, mas aí é um passo seguinte nos testes.

Substituição do Analytics atual

A questão SPA eu tenho quase certeza que conseguimos resolver, então já vai valer a pena usar a Umami Cloud no lugar do Analytics da Vercel, pois isso deve representar cerca de $50 de economia mensal, fora permitir habilitarmos de novo o analytics nas páginas que hoje estão sem ('/' e '/publicar').

Conclusão

A dúvida maior é a capacidade de compartilhar os dados, que, dependendo do resultado dos testes, podemos compartilhar quase em tempo real, ou com um cache com tempo maior, de acordo com a capacidade do Umami. Se o problema for mais o rate limit da API da Umami Cloud do que a capacidade do servidor do Umami, podemos pensar em auto hospedar o serviço, mas isso seria uma pena, pois traria custos muito maiores do que na Umami Cloud.

Ajuda para testar

Será ótimo se alguém puder abrir um PR, ou adequar o #1819, para permitir esses dois testes (SPA e API), mas habilitando para coletar dados apenas das páginas de login e de cadastro, e sem criar um endpoint que forneça os dados das páginas de conteúdos (por enquanto), pois primeiro o teste deve ser estressando diretamente a API da Umami Cloud e não a nossa API.

[mthmcalixto]

@aprendendofelipe eu fiz um hook no #1819 e ele vai funcionar com SPA para enviar dados apenas de "login" e "cadastro".

Sobre o rate-limit acredito que seja client-side da cloudflare que limita o envio do usuário, então vai de usuário para usuário e vai continuar o envio de dados de outros.