Valeeeu Filipe! Boa ideia, e fui atrás dela agora.
Os patrocinados não estavam no meu acervo, porque a listagem /contents filtra type: 'content' e anúncio tem tipo próprio. Mas o endpoint /api/v1/sponsored-beta é público, então dava para pegar.
Só que ele devolve seleção aleatória em vez de listagem paginada. Fui chamando repetidamente e juntando os ids únicos até parar de aparecer coisa nova, o que aconteceu por volta da décima oitava rodada. O conjunto inteiro hoje é este:
- 120 publicações patrocinadas
- 79 anunciantes distintos
Dá para ver bem para que o recurso está servindo olhando quem usa. O @JuanMathewsRebelloSantos anuncia treinamento e voucher de certificação, e é quem mais usa, com 14. O @filipedeschamps divulga os próprios vídeos e o repositório do algoritmo do fogo do Doom, com 8. O @JeielMiranda leva o RegataOS, distro brasileira, e uma plataforma de threat intelligence. O @gmasson tem um gerador de favicon gratuito. O @LuC45m4Th3u5 tem uma API de recomendação. O @obrenoalvim, um projeto de memória para IA no GitHub.
Ou seja, não é um espaço de propaganda genérica. É gente da casa mostrando o que faz.
E isso me leva ao achado que eu não esperava: todos os 79 anunciantes também publicam post normal aqui. Nenhum é anunciante puro que chegou de fora só para comprar espaço.
E eles não são membros quaisquer. A média de tabcoins por post desse grupo é 8,04, contra 4,63 do site. Quem anuncia é gente que já contribui acima da média.
Os destinos mais comuns são github.com, youtube.com e linkedin.com, com cinco anúncios apontando de volta para o próprio TabNews.
Agora sobre a sua observação de que faltam funcionalidades básicas. Pelo endpoint, dá para saber o que está sendo anunciado e por quem, e nada além disso: ele devolve seis campos, sem data, sem valor, sem período, sem desempenho.
Mas antes de sugerir o que implementar eu fui olhar o repositório, e a história é mais interessante do que "falta tudo". Boa parte já está construída, só não conversa entre si.
O orçamento existe. A migration 1721243449839_create-table-ad-tabcash-operations.js cria a tabela ad_tabcash_operations com o enum ['budget', 'daily_debit']. Então o sistema já sabe quanto TabCash cada anúncio recebeu e quanto foi debitado por dia, o que dá custo e tempo no ar.
A audiência também existe. O models/umami.js já busca pageviews, visitors e visits por caminho, e o models/analytics.js expõe isso internamente como getStatsByPath.
O que realmente não existe em lugar nenhum é o clique no anúncio. E impressão do anúncio também não, porque anúncio exibido na lateral de outra página não gera visita própria, então o Umami não pega.
Então a lista do que falta fica bem mais curta do que parecia: contar clique, contar impressão, e devolver isso junto com o gasto para quem pagou. Os dois últimos pedaços já estão em casa.
Uma coisa que me chamou atenção no modelo de cobrança: sendo daily_debit, você paga por dia no ar, e não por quem viu. Isso torna a falta de retorno mais custosa ainda, porque o anunciante não consegue nem estimar se o dia valeu. Provavelmente é parte da explicação para a concentração: 79 anunciantes para 120 anúncios significa que a maioria fez um e parou.
Obrigado pela sugestão, foi a que mais rendeu coisa nova até agora.