Desligar o algoritmo parece uma opção simples de interface, mas não existe um único botão capaz de remover toda a lógica automatizada de uma rede social. O que a Austrália propõe, segundo o Sapo.pt, é permitir que utilizadores com 16 anos ou mais escolham um feed sem recomendações personalizadas, limitado às contas que seguem e ordenado cronologicamente. Para quem desenvolve plataformas, a discussão importante não é “algoritmo ou nenhum algoritmo”: é quais decisões automatizamos, com que critérios e com quanto controlo deixamos o utilizador.
O que o Digital Duty of Care propõe para as redes sociais
O projeto australiano Digital Duty of Care, ou Dever de Cuidado Digital, propõe que serviços online identifiquem riscos previsíveis de danos e adotem medidas razoáveis para os mitigar, com atenção especial à proteção de crianças. Entre as medidas destacadas está a opção “My Feed, My Way”: pessoas com 16 anos ou mais poderiam desativar as recomendações do feed principal e ver conteúdos de contas que decidiram seguir, em ordem cronológica ou cronológica inversa.
Segundo o Sapo.pt, o rascunho foi divulgado para consulta no início de setembro e o projeto foi apresentado ao Parlamento pela ministra das Comunicações, Anika Wells. É importante tratar a iniciativa como uma proposta legislativa, não como uma descrição universal de funcionalidades já disponíveis em todas as plataformas.
A medida chama atenção porque transforma uma escolha de produto em requisito de política pública. Uma plataforma não poderia apenas dizer que o utilizador controla o feed: teria de oferecer uma alternativa concreta à ordenação personalizada. Isso muda decisões de arquitetura, interface, telemetria e governança de produto.
Por que “desligar o algoritmo” é uma simplificação técnica
Na análise citada pelo Sapo.pt, três professores de comunicação digital argumentam que não há um único algoritmo para ligar ou desligar. A palavra costuma ser usada como sinónimo de recomendação, mas sistemas automatizados também participam da moderação, da busca, da publicidade direcionada e da deteção de spam.
Do ponto de vista de engenharia, faz sentido separar esses subsistemas. Um feed pode combinar coleta de publicações, filtros de segurança, regras de elegibilidade, cálculo de relevância, ordenação e paginação. Remover a personalização da ordenação não significa, por si só, remover moderação, bloquear spam ou alterar os resultados de pesquisa.
Também não significa que todo sistema de aprendizagem automática seja uma recomendação de conteúdo. Um classificador que identifica provável spam responde a uma pergunta diferente de um modelo que estima se uma publicação será interessante para uma pessoa. Agrupar ambos sob “o algoritmo” torna a conversa pública mais fácil, mas dificulta decisões técnicas precisas.
O que muda quando uma plataforma oferece um feed cronológico
Um feed cronológico dispensa uma pontuação personalizada para decidir qual publicação aparece primeiro. Mas ainda depende de escolhas de produto e de código: quais publicações são elegíveis, como tratar conteúdo removido, que fuso horário usar, como ordenar itens com o mesmo horário e se existe paginação consistente.
Essas escolhas são mediação. Não são necessariamente personalização algorítmica, mas continuam a determinar o que o utilizador vê. Por exemplo, uma plataforma pode mostrar apenas publicações de contas seguidas, excluir itens removidos por violarem regras e ordenar o restante por data. A experiência não é “sem sistema”; é uma experiência com critérios diferentes e mais explícitos.
Recomendação não é o problema inteiro: importam os objetivos
Na minha leitura, a pergunta mais útil para quem constrói produtos não é se devemos usar algoritmos. É o que o sistema tenta otimizar e quais sinais usa para isso. Um modelo treinado para maximizar tempo de utilização pode produzir resultados diferentes de um sistema que prioriza relevância declarada, diversidade de fontes ou controlos definidos pela própria pessoa.
Esse objetivo não vive apenas no modelo. Vive também nos eventos registados, nas métricas de sucesso, nos testes A/B e nas decisões de negócio. Se a equipa celebra apenas cliques e sessões mais longas, o sistema tende a privilegiar comportamentos que aumentam esses indicadores, mesmo que outras dimensões importantes não estejam representadas.
O artigo do Sapo.pt aponta ainda um exemplo de recomendações ajustadas para contas de menores, desenvolvido pelo YouTube com especialistas internacionais. A referência ajuda a ilustrar uma distinção importante: a recomendação pode ser desenhada com objetivos e salvaguardas específicos. Segundo o mesmo artigo, menores de 16 anos na Austrália deixaram de ter acesso a esse benefício com a entrada em vigor de restrições de idade nas redes sociais. Isso levanta uma questão de desenho de políticas: uma regra que reduz exposição a certos riscos pode também retirar uma proteção específica.
Na Prática: como implementar um modo cronológico
Se eu estivesse a desenhar essa funcionalidade, separaria a preferência de ordenação da lógica de segurança e da consulta de publicações. Assim, “cronológico” não desativa verificações essenciais: apenas troca o critério que ordena os itens elegíveis. Abaixo está um exemplo simplificado em TypeScript para essa camada de ordenação.
type FeedMode = "recommended" | "newest" | "oldest";
type Post = {
id: string;
authorId: string;
createdAt: string;
isVisible: boolean;
};
function buildFeed(
posts: Post[],
followedAccountIds: Set<string>,
mode: FeedMode,
): Post[] {
const eligible = posts.filter(
post => post.isVisible && followedAccountIds.has(post.authorId),
);
if (mode === "recommended") {
// Em produção, a ordenação personalizada seria calculada
// por um serviço de ranking, não por esta função.
return eligible;
}
return eligible.sort((a, b) => {
const timeA = Date.parse(a.createdAt);
const timeB = Date.parse(b.createdAt);
// Desempate determinístico para evitar ordem instável
// quando duas publicações têm o mesmo timestamp.
const chronological = timeA - timeB || a.id.localeCompare(b.id);
return mode === "newest" ? -chronological : chronological;
});
}O exemplo é deliberadamente pequeno: não inclui banco de dados, paginação ou permissões completas. Ainda assim, torna explícita uma decisão saudável de arquitetura. A filtragem de visibilidade e de contas seguidas acontece independentemente do modo de ordenação; a preferência do utilizador altera apenas a ordenação final.
- Separe elegibilidade de ranking. Decida primeiro quais itens podem aparecer. Aplique regras de bloqueio, visibilidade e segurança antes de ordenar.
- Guarde a preferência como configuração do utilizador. Não deduza que alguém quer um feed cronológico apenas porque ignorou recomendações numa sessão.
- Defina a semântica de “cronológico”. Escolha a origem do timestamp, o desempate e o comportamento para publicações editadas ou agendadas.
- Faça a paginação de forma consistente. Um cursor baseado apenas no horário pode duplicar ou saltar itens quando várias publicações partilham o mesmo timestamp. Inclua uma chave de desempate estável.
- Teste a compreensão da interface. O utilizador deve conseguir perceber qual modo está ativo e como voltar a alterá-lo.
Arquitetura de feed: escolha explícita, não bifurcação improvisada
Uma implementação comum é manter um único endpoint com um parâmetro de modo, por exemplo GET /feed?mode=newest. O backend valida a preferência e chama a estratégia de consulta apropriada. Isso costuma ser mais sustentável do que duplicar toda a lógica de feed em endpoints separados, porque elegibilidade, permissões e políticas de visibilidade continuam centralizadas.
Em escala, a diferença entre modos pode afetar o caminho de leitura. Um feed recomendado pode exigir recuperação de candidatos e uma etapa de ranking; o cronológico pode consultar publicações recentes de contas seguidas e fundi-las. Essa consulta também tem custos e limites: contas seguidas muito numerosas, alta frequência de publicação e filtros complexos podem tornar uma ordenação cronológica cara.
Por isso, “cronológico” não deve ser tratado como sinónimo de “sem engenharia”. Índices por autor e data, cursores compostos, consistência de leitura e cache continuam importantes. O caminho mais simples para o utilizador pode exigir cuidado adicional no backend.
Erros Comuns: o que evitar ao implementar feeds controláveis
- Prometer “sem algoritmo” quando só se remove o ranking personalizado. A expressão cria uma expectativa impossível de cumprir se a plataforma ainda usa regras de elegibilidade, moderação e ordenação.
- Desativar salvaguardas junto com recomendações. Um modo cronológico não deve, por definição, mostrar conteúdo removido ou ignorar controlos de segurança. Personalização e proteção são preocupações distintas.
- Oferecer dois modos e chamar isso de controlo completo. A opção cronológica é útil, mas não responde a preferências como limitar temas, escolher diversidade, reduzir repetições ou definir prioridades. É um primeiro controlo, não uma solução universal.
- Medir sucesso só por tempo de utilização. Se o objetivo do produto é devolver escolha, avalie também se as pessoas encontram o modo, compreendem a diferença e conseguem manter a preferência.
- Usar timestamps sem uma regra de desempate. Ordenações instáveis podem fazer publicações saltarem entre páginas e gerar duplicados, sobretudo quando a paginação depende de cursores.
- Esconder a opção nas definições. Um controlo difícil de encontrar existe no código, mas oferece pouco controlo prático. A interface precisa comunicar estado e consequências sem linguagem enganosa.
O que essa proposta significa para quem programa
Para uma equipa de desenvolvimento, o debate australiano é um bom motivo para inventariar onde há decisões automatizadas no produto. Não basta documentar o modelo de recomendação. É preciso saber que dados alimentam os sistemas, quais métricas influenciam a ordenação, que controlos a pessoa tem e que componentes continuam ativos quando uma opção é desativada.
Eu também trataria as preferências de feed como parte da API do produto, não como um detalhe visual. Isso facilita testes, evita que aplicações diferentes interpretem a escolha de formas incompatíveis e permite analisar falhas sem confundir modo cronológico com um erro no ranking.
Por fim, medir a qualidade exige mais do que comparar cliques. Um modo cronológico pode reduzir interações com publicações recomendadas e, ainda assim, cumprir o seu propósito: mostrar conteúdo de contas escolhidas pela pessoa em ordem previsível. A métrica precisa corresponder à promessa da funcionalidade, não apenas ao indicador mais conveniente para o negócio.
Perguntas frequentes sobre feeds cronológicos e algoritmos
Desligar as recomendações remove todos os algoritmos de uma rede social?
Não necessariamente. A opção descrita pelo Sapo.pt incide sobre recomendações do feed principal. Moderação, deteção de spam, pesquisa e outros sistemas automatizados podem continuar a funcionar, pois cumprem funções diferentes.
Um feed cronológico é realmente livre de algoritmos?
Não no sentido amplo. Ele reduz ou elimina a ordenação personalizada, mas ainda depende de regras para selecionar itens, aplicar controlos de visibilidade e ordenar publicações. É mais preciso dizer que é um feed sem ranking personalizado por recomendação.
Como evitar que a paginação cronológica repita publicações?
Use um cursor composto, com timestamp e identificador estável, em vez de depender apenas da data. Assim, publicações com o mesmo horário têm uma ordem determinística e o próximo pedido consegue continuar do ponto correto.
Uma plataforma deve desligar também a moderação no modo cronológico?
Não. A escolha da ordenação não deve desativar regras independentes de segurança e visibilidade. A arquitetura deve separar a elegibilidade do conteúdo do critério usado para ordenar os itens permitidos.
Conclusão
“My Feed, My Way” torna visível uma tensão que equipas de produto já enfrentam: personalização pode ser útil, mas a pessoa precisa entender e controlar como o conteúdo é organizado. Para os desenvolvedores, a resposta não é fingir que existe um interruptor universal. É separar sistemas, explicitar objetivos, oferecer escolhas compreensíveis e implementar cada modo com regras previsíveis.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.