Engenharia de engajamento: o que o caso Meta ensina para devs

2>O caso Meta e o que devs precisam entender sobre plataformas viciantes

Quando li a matéria do Olhardigital.com.br sobre a Meta voltar aos tribunais nos EUA, meu primeiro pensamento não foi sobre legislação americana. Foi: “isso é resultado direto de decisões de engenharia”. O julgamento começa em 18 de agosto, em Oakland, com jurados sendo selecionados a partir de 12 de agosto, e pode render multas de até US$ 1,4 trilhão. Quatro estados (Califórnia, Colorado, Kentucky e Nova Jersey) acusam a empresa de projetar o Instagram e o Facebook para viciar adolescentes. Tudo começou com os vazamentos de Frances Haugen, em 2021, os chamados “Arquivos do Facebook”.

Na minha experiência construindo produtos digitais, vi无数次 como pequenos detalhes de UI viram decisões judiciais. Este caso é um manual técnico disfarçado de notícia jurídica. Vou destrinchar o que está em jogo, mostrar os mecanismos que devs usam (e abusam) no dia a dia, e o que podemos aprender para não repetir o mesmo erro.

Por que esse processo importa para quem programa

Antes de entrar no mérito técnico, preciso ser claro: o que a Meta é acusada não é “criar um bom produto”. É acusação de usar especificamente engenharia de engajamento para explorar vulnerabilidades cognitivas de menores. Isso muda tudo. Não estamos falando de um botão bem posicionado. Estamos falando de sistemas projetados para reter atenção usando psicologia comportamental combinada com machine learning.

Para um dev sênior, isso acende um alerta ético que vai além de “compliance”. Se você trabalha em qualquer produto com base de usuários significativa — e a maioria de nós trabalha —, os padrões usados nesse caso provavelmente estão documentados em algum playbook que sua empresa já leu.

Os mecanismos técnicos por trás da acusação

A acusação menciona que a Meta criou funcionalidades específicas para fazer menores passarem mais tempo nas plataformas. Não preciso especular sobre quais são — basta olhar a engenharia padrão de qualquer rede social. Vou listar os culpados habituais e mostrar como eles são implementados.

1. Scroll infinito (Infinite Scroll)

O scroll infinito é provavelmente o exemplo mais clássico. Em vez de paginação tradicional, o conteúdo carrega conforme o usuário rola a tela. Parece inocente, mas remove um ponto de fricção natural: a decisão de “ir para a próxima página”. Sem essa decisão, não há pausa cognitiva.

Implementação típica em React com Intersection Observer:

import { useEffect, useRef, useState, useCallback } from 'react';

function useInfiniteScroll(fetchMore) {
  const [items, setItems] = useState([]);
  const [page, setPage] = useState(1);
  const [loading, setLoading] = useState(false);
  const [hasMore, setHasMore] = useState(true);
  const sentinelRef = useRef(null);

  const loadMore = useCallback(async () => {
    if (loading || !hasMore) return;
    setLoading(true);
    try {
      const newItems = await fetchMore(page);
      if (newItems.length === 0) {
        setHasMore(false);
      } else {
        setItems(prev => [...prev, ...newItems]);
        setPage(prev => prev + 1);
      }
    } finally {
      setLoading(false);
    }
  }, [fetchMore, page, loading, hasMore]);

  useEffect(() => {
    const observer = new IntersectionObserver(
      entries => {
        if (entries[0].isIntersecting) {
          loadMore();
        }
      },
      { threshold: 0.5 }
    );

    if (sentinelRef.current) {
      observer.observe(sentinelRef.current);
    }

    return () => observer.disconnect();
  }, [loadMore]);

  return { items, loading, hasMore, sentinelRef };
}

Funciona muito bem. Talvez bem demais. O problema é quando você remove intencionalmente qualquer sinal de “fim” — sem indicador de quantos itens faltam, sem botão de “parar”, sem sugestão de pausa. Aí vira armadilha.

2. Notificações push com timing otimizado

Outra técnica clássica: enviar notificações no horário de maior propensão do usuário abrir o app. Isso não é feature, é engagement engineering. O sistema aprende quando você costuma olhar o celular e dispara o push exatamente nesse momento.

Exemplo simplificado de um job que decide quando enviar:

from datetime import datetime
from user_engagement_model import predict_optimal_send_time

def schedule_notification(user, notification):
    """
    Decide o melhor horário para enviar uma notificação,
    baseado em ML sobre comportamento passado do usuário.
    """
    optimal_time = predict_optimal_send_time(
        user_id=user.id,
        historical_opens=user.notification_history,
        current_context=user.context_signals,
        notification_type=notification.type
    )
    
    if user.age < 18 and notification.type == 'social_reengagement':
        # Em um mundo ético, talvez você NÃO queira isso
        return reject_or_delay(notification)
    
    notification_queue.enqueue_at(optimal_time, notification)
    return optimal_time

A linha comentada sobre idade é o ponto. Se você não tem um gate como esse, está construindo uma ferramenta que órgãos reguladores podem, legitimamente, chamar de predatória.

3. Reforço variável (Variable Reward)

Esse é o mecanismo central de qualquer feed algorítmico. O usuário não sabe se o próximo post será bom, ruim, engraçado ou chocante. Essa incerteza é o que mantém o comportamento de checagem. É o mesmo princípio de uma slot machine, e está documentado nos “Arquivos do Facebook” que vieram à tona em 2021.

Implementação simplificada de um ranking com exploration/exploitation:

import random

class FeedRanker:
    def __init__(self, model):
        self.model = model
        self.exploration_rate = 0.15  # 15% de conteúdo "novo"
    
    def rank(self, candidates, user_context):
        # Exploitation: mostra o que o modelo acha que o usuário quer
        scored = [(c, self.model.predict_engagement(c, user_context)) 
                  for c in candidates]
        scored.sort(key=lambda x: x[1], reverse=True)
        
        # Exploration: injeta variação para manter o hábito
        top = scored[:int(len(scored) * (1 - self.exploration_rate))]
        random.shuffle(candidates)
        explore = candidates[:int(len(candidates) * self.exploration_rate)]
        
        # Intercala de forma aparentemente aleatória
        return self.interleave(top, explore)

Exploration não é necessariamente ruim — é como o TikTok descobre novos criadores. Mas a dosagem importa. Quando a taxa de exploração é calibrada para maximizar tempo de tela em menores, ela deixa de ser técnica e vira manipulação.

Na Prática: um checklist ético para devs

Se você está construindo um produto com qualquer componente social ou de feed, sugiro rodar este checklist antes de cada release:

Identifique mecanismos de retenção duvidosos: scroll infinito sem fim visível? Notificações com ML de timing? Reforço variável sem propósito claro? Liste todos.
Implemente gates de idade: features de re-engagement agressivo devem ter tratamento diferente para menores. Não é só COPPA/LGPD — é responsabilidade técnica.
Adicione fricção intencional: um indicador de “você está há 40 minutos rolando”, pausas a cada X itens, ou botão de “sair do modo automático”. Isso parece ruim para métricas de curto prazo, mas é a única defesa real em tribunal.
Documente decisões de produto: registre por que cada padrão viciante existe. Se a resposta for “porque aumenta DAU em 12%”, isso vai aparecer no seu eDiscovery em algum processo.
Faça red team interno: tenha alguém na equipe cujo trabalho é tentar tornar seu próprio produto viciante e depois apresentar o caso contrário.

Erros Comuns que devs cometem nesse cenário

Na minha carreira, vi os mesmos deslizes se repetirem. Vou listar os mais perigosos:

Tratar ética como responsabilidade do PM, não do dev

Errado. Você é quem escreve o código que implementa o padrão viciante. Não adianta o PM aprovar um design se você não questionar tecnicamente. Engenharia é responsabilidade técnica, não execução cega de spec.

Achar que “só funciona em redes sociais grandes”

Falso. Qualquer app com feed, notificações ou gamificação está sujeito aos mesmos princípios. Já vi SaaS B2B com streaks diários, badges e notificações otimizadas por ML que tecnicamente são o mesmo padrão de uma rede social para adolescentes.

Otimizar apenas para retenção

O NORTH STAR METRIC deveria incluir qualidade do tempo gasto, não só quantidade. Se seu usuário fica 3 horas mas sai insatisfeito, você tem um problema — e eventualmente um processo.

Ignorar dados demográficos na auditoria

Seus testes de UX precisam segmentar por idade. Uma notificação que funciona para adultos pode ser predatory para um usuário de 14 anos. Se você não está medindo isso, está no escuro.

Não ter logs de decisão algorítmica

Quando o processo chegar (e em alguns setores, vai chegar), a primeira coisa que o juiz vai pedir é o log de por que cada decisão foi tomada. Se seu sistema de ranking é uma caixa-preta sem rastreabilidade, você perde o caso antes de começar.

O que esse caso significa para o ecossistema tech

Olhando além da Meta, esse julgamento estabelece precedente. Se a empresa for condenada com multa de US$ 1,4 trilhão, espere três coisas nos próximos 18 meses:

Legislação estadual mais agressiva nos EUA, especialmente para apps com público adolescente
Auditoria obrigatória de “padrões viciantes” em qualquer produto com base jovem
Mudança no cálculo de responsabilidade: devs individuais podem ser nomeados em processos, não só empresas

Já vi movimento parecido na Europa com o DSA (Digital Services Act) e no Brasil com o PL das Fake News e o Estatuto da Criança no ambiente digital. O vento está soprando para监管 mais pesado, e quem não se preparar vai pagar caro.

FAQ — perguntas que devs estão fazendo

Esse caso afeta apenas empresas dos EUA?
Não. Qualquer plataforma global que opere nos EUA está sujeita a jurisdição americana. E o precedente legal atravessa fronteiras — o que for decidido em Oakland será citado em processos no Brasil, Europa e Ásia.

Padrões viciantes são ilegais por definição?
Não. O que está em jogo é o uso intencional em populações vulneráveis (menores) e a ausência de mitigação. Scroll infinito em um app de notícias para adultos é diferente de scroll infinito em um app usado majoritariamente por adolescentes.

Como saber se meu produto já está “na zona de risco”?
Se você tem qualquer combinação de feed algorítmico + notificações push com timing otimizado + métricas de tempo de tela segmentadas por idade, você está na zona. Hora de implementar os gates que mencionei no checklist.

Devs podem ser responsabilizados pessoalmente?
Em tese, hoje não. Na prática, o movimento é nessa direção, principalmente em casos de negligência comprovada. Mais provável: você perde o emprego e a empresa paga a multa. Mas isso pode mudar.

Qual a alternativa técnica para engajamento sem exploração?
Foque em value-driven retention: notificações de eventos reais (mensagem recebida, atualização importante), feeds com diversidade forçada, pausas intencionais, e métricas de satisfação ao lado de tempo de tela. Engajamento saudável existe — é só mais difícil de medir.

Quando esse julgamento termina, em outubro, o que muda na prática?
Depende do veredicto. Se a Meta perder, espere novos requisitos regulatórios em todos os estados. Se ganhar, o lobby da indústria usa o caso como escudo por alguns anos. De qualquer forma, devs que trabalham com produtos para jovens precisam se preparar agora, não depois do precedente.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Esse tema vai dominar conversas em tech nos próximos meses — melhor estar preparado antes do próximo vazamento.