Milestone 7: Revenue Share [DRAFT]

[aprendendofelipe]

Turma, está chegando o momento de implementarmos a primeira versão da Revenue Share.

Serão criados os espaços de anúncios que vão ser divididos entre os mantenedores do TabNews e os usuários que participam do ciclo que cria valor no sistema (criação de conteúdos/comentários e qualificações).

Obs. 1: O TabCash que os mantenedores recebem individualmente com seus usuários ao participarem do ciclo do TabNews não conta como a parte do sistema na divisão, pois eles estão sujeitos às mesmas regras de contribuição de todos usuários.

Obs. 2: Não vai existir uma maneira de comprar espaços de anúncios através de pagamento em dinheiro, mas quem tem direito à espaços de anúncios poderá usá-los da forma achar melhor, desde que respeite os termos de uso, então pode inclusive vender seus espaços, mas terá que publicar o anúncio com seu usuário e será responsável por ele.

Podemos ter diferentes formatos de anúncios, como os “banners”, “destaque nos resultados de pesquisas”, “publicações promovidas” etc.

Acho que o mais simples para o início deve ser implementar as “publicações promovidas”. Penso assim tanto em termos de mecânica de funcionamento, como de adaptação da interface web, compatibilidade com Apps não oficiais e outros sites que usam a API.

Como os “banners” e “destaques nos resultados de busca” exigem a elaboração de mecânicas mais complexas, podemos reservá-los, pelo menos no início, aos anúncios publicados pelos mantenedores do TabNews. E em uma versão futura (em outra milestone) podemos criar formas do próprio TabNews ganhar parte do TabCash gerado e poder participar das publicações promovidas, assim como dos usuários usarem TabCash para anunciar em formato de banner.

Sobre os destaques em resultados, enquanto não temos um sistema de busca próprio, não podemos implementar nada que possibilite medir o alcance de forma simples. A busca hoje usa o próprio Google, e eu configurei alguns anúncios dos projetos do Filipe para aparecerem quando for pesquisado por algo relacionado, mas, pelo menos por enquanto, não temos nenhuma estatística de visualizações e cliques nesses resultados. Os únicos dados que temos são sobre a frequência de consultas dos termos mais pesquisados, mas nada específico dos anúncios.

Então acredito que os pontos de destaque da milestone ainda são:

• Publicações Promovidas #1491
• Atualizar Termos de Uso (e colocar link no cadastro) #1153
• Banner de Propaganda #1492
• Sugestão: Funcionalidade de denúncia/reportar conteúdos #877
• LISTA EM CONSTRUÇÃO

E permanecem no radar para quem quiser adiantar:

• A validação de email+senha deve tomar o mesmo tempo quando o usuário existe ou não #186
• [FEATURE/SUGESTÃO] Quantidade de visualizações em uma publicação #1115
• Implementar Two Factor #1171
• Migrar RDS de sa-east-1 para us-east-1 (ou outro provider como Supabase) #1172
• Mensagem global para anúncios #1181
• Adequar a página de conteúdos e o componente Content para lidar melhor com alterações nos dados #1376
• Barra de scroll sobrepondo o modal de confirmação. #1627
• Facilitar a cópia de âncoras para títulos de conteúdos #1659
• Adicionar paginação no endpoint /users e criar página para listar usuários #1675
• LISTA EM CONSTRUÇÃO

Em paralelo, já foram desenvolvidas durante a Milestone:

• Índices no Banco de Dados #1156
• Como testar em mobile? #1263
• Ajustes necessários no firewall interno (limite de usuários e publicações por IP) #1463
• [UX] Facilitar o entendimento dos campos dos formulários #1529
• MODEL:CONTENT:CREDIT_OR_DEBIT_TABCOINS:NEGATIVE_USER_EARNINGS #1540
• [Feature/Melhoria] Migrar do Jest para Vitest #1631
• Adiciona id em títulos de conteúdos e nos conteúdos #1635
• Permitir filtrar testes em qualquer modo de execução #1644
• Refatorar componentes de e-mail #1645
• Migração para criar novas tabelas de saldo #1656
• Permitir desabilitar rotas temporariamente pela variável de ambiente UNDER_MAINTENANCE #1662
• feat(error message text): add createErrorMessage function #1663
• Cria componente de paginação e teste de unidade no frontend #1668
• Corrige o código de status da resposta da API para o método OPTIONS de 404 para 200 #1678
• Não é possível editar ou apagar um conteúdo usando apenas o teclado #1681
• Refatora validator e corrige validação de null caso o campo seja obrigatório #1685
• Diminui a quantidade de campos e o tamanho total dos logs enviados para o Axiom #1696
• Corrige os testes de limite de tamanho do slug #1704
• Refatoração da validação da presença do título nos conteúdos #1705
• Corrige typo em content (contend) #1706
• Remove async desnecessário de pagination.get #1707
• Usar RequestBuilder em mais testes de conteúdos #1708
• Remove a biblioteca cross-fetch e muda a set-cookie-parser para devDependencies #1715
• Estabiliza testes que falham eventualmente #1720
• Mensagem de erro ao tentar publicar novo conteúdo #1721
• Habilita mais regras do ESLint #1723
• Usa o módulo crypto para gerar UUIDs e move o uuid para devDependencies #1725
• Remove propriedade obsoleta version do Docker Compose #1726
• Salvar nos eventos o histórico de alterações de username #1727
• Remove validação de existência do parent_id ao modificar um conteúdo #1728
• Diminui idas ao banco de dados na criação e edição de conteúdos, e na edição de usuários #1729
• Atualiza todas as dependências possíveis #1733
• Corrige o CSS gerado após atualização para o Next.js 14.2 #1734
• Corrige parâmetros de paginação para serem dinâmicos e incluir with_root e with_children em GET /contents #1735
• Diminui idas ao banco de dados na edição de usuários e na validação do token de confirmação do e-mail #1737
• Reserva usernames que podem ser usados para URLs da Revenue Share ou de outras funcionalidades #1738
• [C.I.] Remove o cache da pasta /.next/cache e atualiza as outras actions #1755
• Atualiza Node.js para v20 e usa o crypto de maneira compatível com a Edge #1768
• Sempre validar se username é único antes de validar o mesmo para o email #1772
• LISTA EM CONSTRUÇÃO

[Rafatcb]

Precisei escrever isso para organizar as ideias na minha mente e deixar claro para quê cada coisa irá servir e para quem, além de juntar as referências num único local. Então, aproveitei para adicionar outros aspectos da mecânica e compartilhar, porque dessa forma fica mais fácil de orientar quem não acompanhou nada e também de entender se eu estou alinhado com o consenso atual.

Tentei tirar partes mais específicas sobre a implementação para comentar no issue mais adequado, permanecendo aqui apenas a "análise macro" sobre o Revenue Share.

O intuito dos anúncios (para os usuários)

Resumo:

• O usuário que contribuiu com a plataforma tem como recompensa a possibilidade de divulgar algo (produto, serviço, projeto, vagas).
• O usuário não pode vender o espaço de anúncio pelo TabNews, mas pode vender particularmente para alguém ou para uma empresa e assumir a responsabilidade pelo anúncio.

Em alguns lugares já foi dito que a ideia é não ter uma forma de venda de um "espaço de anúncio", mas permitir que os usuários vendam de forma privada para quem quiserem, e se responsabilizarem pelos anúncios na plataforma. Algumas referências para quem quiser se aprofundar são: #1490 (comment) (publicação inicial desse issue), #352 (comment), vídeo de lançamento do TabNews.

Isso é extremamente empolgante, porque "algo" pode variar desde produtos ou serviços convencionais, até seus projetos pessoais, como repositórios no GitHub na qual você não gastaria dinheiro para divulgá-los, mas com essa mecânica você avaliaria divulgar. Ou até divulgar seu portfólio, site pessoal, vaga de emprego, o que fizer fechar a conta para você e tornar viável e sustentável a sua participação na plataforma.

O intuito dos anúncios (para o TabNews)

Resumo:

• O TabNews não gera receita, e os espaços de anúncios tem também como objetivo tornar o TabNews autossustentável.
• Como "compartilhamento", parte dos anúncios serão disponibilizados para os usuários, e parte para o TabNews, numa proporção ainda não estabelecida.

O TabNews sempre foi um projeto financiado pelo @filipedeschamps (referência), e hoje é mantido com a receita gerada pelo curso.dev. O Revenue Share surge como uma tentativa de não apenas retribuir o valor que a comunidade gerou, mas também de tornar o TabNews um projeto autossustentável, isto é, um projeto que gera uma receita maior do que os custos.

Como dito em #352 (comment), o "compartilhamento" é no sentido de que parte dos anúncios serão disponibilizados para os usuários e parte para o TabNews:

(...) vamos implementar um sistema de Revenue Share (Compartilhamento de Receita), muito próximo do que você encontra nas outras plataformas como YouTube, onde uma parte fica para a plataforma e outra para o criador, mas que nesse momento vamos zerar qualquer repasse da plataforma para entender o que funciona para o criador, e depois o que sobra para a plataforma.

e #352 (comment):

Como já comentado, o TabNews não tem receita, então será compartilhado o Espaço Publicitário e as pessoas poderão usar esse espaço para o que quiser (...)

Impactos iniciais nos Termos de Uso

Resumo:

• Proibir divulgação de vagas de empresas específicas no TabNews, permitindo esse tipo de divulgação apenas por meio de anúncios.
• Anúncios podem ser "puramente comerciais", diferentemente de publicações.

Para alguns anúncios fazerem sentido, eles devem ser permitidos como anúncio e não como uma publicação comum. A partir da citação feita em O intuito dos anúncios (para os usuários), imagino que um dos exemplos seria proibirmos a divulgação de vagas de empresas específicas em publicações, assim continuamos permitindo sites agregadores, e permitiremos a divulgação de empresas específicas em anúncios.

Outro ponto seria o nível "comercial" que os anúncios poderiam ter. Anúncios extremamente comerciais podem não ter um efeito tão bom quanto um anúncio com cara de publicação, e tudo bem, porque os anúncios em outras plataformas também funcionam assim (uns convertem mais do que outros). Então, acredito que inicialmente podemos ser mais permissivos, e moderar conforme vermos que a situação desandou para além do que a comunidade consegue gerenciar bem.

Requisitos para criar um anúncio

Resumo:

• O usuário usará TabCash para criar anúncios.
• Anúncios devem ser aprovados e/ou podem ser removidos.
• Nem todos usuários poderão criar anúncios, existirá uma "régua mínima" para diminuir abusos.

Para conseguir criar anúncios, o usuário utilizará uma certa quantia de TabCash, conforme dito em #352 (comment):

Você somente consegue comprar anúncios usando o TabCash, esse é o "objetivo final" (caso você queira isso como objetivo). Então a questão é, como ganhar TabCash? E a resposta é simples: qualificando conteúdos de valor concreto com suas TabCoins.

Como dito nesse comentário no TabNews, nem todo mundo poderá anunciar, e os anúncios precisarão ser aprovados ou poderão ser removidos. Isso deve ser debatido mais especificamente nos issues de implementação, de acordo com o tipo de anúncio e como o sistema está se comportando.

Além disso, o acesso ao sistema de anúncios não será disponibilizado para "todos que possuem TabCash", e inicialmente poderá ser restrito a um grupo menor de usuários para termos um melhor controle sobre como está sendo a resposta da comunidade diante da nova funcionalidade.

5. E sobre a feature em sí, que no fundo é implementar o Revenue Share (que é uma das formas de usar o TabCash), vai precisar de outras implementações importantes, como uma administração melhor das features do usuário, porque eles irão precisar ter uma regua mínima para entrar no programa (igual ao YouTube faz para tentar diminuir os abusos). Uma das formas de implementar isso é um usuário conseguir "comprar" a feature de poder participar do Revenue Share ao atingir certos critérios.
6. E junto disso, precisaremos construir um administrador de anúncios, pois todos eles irão precisar passar por aprovação manual antes de poderem aparecer no site. A não ser que a gente consiga fazer alguma auto-administração disso, pelo menos para reportar algum abuso, ou acertar a mão na régua inicial para conseguir participar do programa.

Duração do anúncio, custo, alcance etc.

Resumo:

• Discutir no issue específico sobre o tipo de anúncio.

Já pensamos em alguns tipos de anúncio, como banner (#1492), publicações promovidas (#1491) e destaques nos resultados de busca, conforme listado na publicação inicial deste issue (#1490 (comment)). Como são tipos de anúncios diferentes, o custo (em TabCash) para criá-los deverá ser diferente, assim como funcionarão de forma diferente: sua duração talvez seja medida em visualizações, em interações, ou usando uma fórmula onde cada fator consome uma determinada quantia de TabCash. Por isso, é mais adequado discutir esse tipo de detalhe no issue específico sobre o tipo de anúncio.

Quantidade de anúncios limite por usuário

Resumo:

• Discutir no issue específico sobre o tipo de anúncio.

Provavelmente teremos limitações para que um usuário não ocupe todos os espaços de anúncio o tempo inteiro, ou podemos fazer com que o custo de ter dois anúncios ou de ampliar o alcance do único anúncio seja mais caro do que o "básico" (aumento exponencial ao invés de linear, por exemplo). Apesar disso poder ser uma limitação de forma global (para todo tipo de anúncio), é mais adequado discutirmos passo a passo, visto que primeiro iremos implantar uma forma de anúncio, acompanhar os resultados e partir para a próxima. Então, inicialmente isso será tratado no issue do tipo específico de anúncio.

[Rafatcb]

Estou criando este comentário separado do anterior para esclarecer dúvidas ou dar sugestões.

Entendendo melhor como o TabNews se tornará autossustentável

Essa parte não está totalmente clara para mim, e pretendo editar o comentário anterior depois que entender melhor. Entendo que não será implementado de imediato, e vamos avançando em etapas, mas é importante entender isso para planejar algo que faça sentido desde o início.

O que está planejado atualmente para ajudar o TabNews a se tornar mais autossustentável é ter espaços de propaganda que o próprio TabNews possa usar para promover algo, onde, no momento, esse algo será apenas o curso.dev, mas, futuramente, poderá ser outros projetos do Filipe. É isso?

TabCoins e TabCash. E talvez algo mais?

Existem alguns estudos que mostram que o ser humano sente mais a dor da perda do que a felicidade do ganho, e também há o chamado viés da aversão à perda. Acredito que algumas pessoas terão receio maior em usar o TabCash porque não terão mais nenhum outro "número" que represente a sua "participação" no TabNews.

Então, me parece que seria uma boa ideia termos um terceiro elemento, mantendo a gamificação e a "experiência/reputação/karma" que o usuário possui. Quero saber se outras pessoas concordam comigo, mas isso pode ser implementado mesmo depois do primeiro tipo de anúncio ser lançado, porque conseguimos "corrigir em retrospecto" com base nos eventos gerados com os gastos de TabCash.