Como montar um sistema de sugestao de atividades que realmente funciona
A maioria das pessoas constrói listões de tarefas esperando que a lista em si seja o produto. Não é. O produto é o filtro. Depois de dois anos configurando fluxos para times de diferentes tamanhos, percebi que o problema nunca foi quantidade de opções, e sim o momento em que a sugestao de atividades aparece na frente do usuário. Se eu te disser para escolher entre 47 tarefas aleatórias, você não faz nenhuma. A coisa mais importante aqui é limitar o pool antes de entregar qualquer coisa. O processo começa com um banco de dados simples. Não precisa ser elaborado. Tabelas para atividades, tags de categoria, duracao estimada em minutos, e um campo de dificuldade de 1 a 5. A partir daí voce define regras de filtragem baseadas no contexto do momento. Dia de semana com pouco tempo livre gera sugestoes de alta velocidade e baixa dificuldade. Final de semana permite atividades longas e complexas. Isso é o básico, mas a maioria para acao aqui e se arrepende.
O problema que todo mundo subestima
Cada nova atividade que você adiciona ao banco multiplica o tempo de processamento da sua logica de recomendacao. Vou dar um numero concreto: com 200 atividades, uma query de filtragem rodando localmente leva cerca de 80 milissegundos. Com 2.000 atividades, sobe para 600 milissegundos. Com 10.000, você esta falando de 4 a 6 segundos, o que já mata a experiencia do usuario. A solucao nao é comprar um servidor melhor. É fazer uma pré-classificação em camadas antes da recomendação propriamente dita. Eu tive esse problema em um projeto real. Um cliente tinha uma biblioteca de mais de 8 mil atividades. O sistema de sugestao de atividades travava no mobile. A solução que funcionou foi criar um indexador por tags primarias com pesos fixos. Antes de qualquer calculo complexo, voce descarta automaticamente 85% do banco com base em dois filtros brutos: tempo disponivel e categoria preferencial. Só os 15% restantes passam pela logica de ranqueamento. Isso reduziu o tempo de resposta de 6 segundos para 120 milissegundos. Ninguem reclama de 120 milissegundos.
Como estruturar as regras de priorizacao
O algoritmo em si é uma soma ponderada de variaveis. Cada atividade recebe uma nota baseada em cinco fatores: horas desde a ultima vez que o usuario viu aquela categoria, duracao vs tempo disponivel, dificuldade vs nivel atual do usuario, popularidade relativa entre usuarios similares, e um fator de frescor que penaliza atividades repetidas consecutivamente. O peso de cada fator depende do seu objetivo. Se voce quer reengajamento, aumente o peso do fator histórico. Se quer introduzir novidade, aumente o fator frescor. Um detalhe que poucos mencionam: o fator de popularidade deve ser calculado por cohort temporal, nao pelo totl de historico. Uma atividade que foi popular em 2023 nao tem a mesma relevancia em 2026. Recalcule o score de popularidade a cada trimestre, aplicando decay exponential aos scores antigos. Isso evita que as atividades mais antigas dominem as sugestoes indefinidamente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Implementacao pratica passo a passo
Passo 1: Defina o schema do banco de dados. Tabelas separadas para atividades, tags, e preferencias do usuario. A tabela de atividades deve incluir campos calculados como score_de_relevancia_atual e vezes_sugerido_ultimos_30_dias. Atualize esses campos semanalmente via job agendado, nao em tempo real. Passo 2: Construa o pipeline de filtragem em tres camadas. Camada um: tags primarias contra o contexto do usuario. Camada dois: duracao e dificuldade contra as preferencias atuais. Camada tres: ranqueamento ponderado entre os candidatos restantes.
Passo 3: Adicione um mecanismo de feedback loop. Cada vez que o usuario clica, ignora, completa ou rejeita uma sugestao, registre o evento com timestamp e contexto. Esse dado alimenta o ajuste dinamico dos pesos do algoritmo. Sem esse feedback, seu sistema estagna depois de duas semanas. Passo 4: Monitore a diversidade. Calcule mensalmente o indice Shannon de diversidade das sugestoes entregues. Se o indice cair abaixo de 0,4, seu algoritmo esta ficando muito conservador e entregando sempre as mesmas atividades para os mesmos usuarios. Ajuste o peso do fator frescor ou reduza o decay das atividades novas.
Quando o metodo falha
Esse sistema funciona bem para usuarios existentes com historico. Com usuarios novos, o cold start é o problema real. Nos primeiros sete dias, sem dados comportamentais, suas sugestoes sao basicamente sorteadas dentro das restricoes de tempo e categoria. isso gera uma taxa de rejeicao de 40 a 60%. A saida e fazer um onboarding obrigatorio de cinco minutos onde o usuario seleciona tres categorias favoritas e informa Disponibilidade media semanal. Isso reduz o cold start para cerca de dois dias de dados suficientes. E se o usuario recusar o onboarding, você pode entregar um catalogo exploratorio com 10 atividades aleatorias bem balanceadas por categoria, documentando que essas sugerencas sao temporarias ate o sistema coletar dados suficientes. Nao tente personalizar demais no inicio. A primeira versao deve focar em correto e rapido, nao em perfeito e lento. Um sistema de sugestao de atividades que responde em menos de 200 milissegundos com acuracia moderada sempre vence um sistema que responde em dois segundos com acuracia alta. O usuario medio desiste antes de perceber a diferenca de qualidade se a espera for maior que uma segunda inteira.
