[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:

https://github.com/filipedeschamps/tabnews.com.br/pull/1598#pullrequestreview-1811528012

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?