Retention Loops — Por Que o Usuário Volta

Retenção alta não é lembrar o usuário de voltar. É o produto ser o jeito mais barato de obter um resultado que já importa pra ele, na cadência em que esse resultado importa. As cinco táticas abaixo aparecem juntas nos apps que retêm; uma isolada quase nunca basta, e a ordem importa.

Governança Global

Segue GLOBAL.md, policies/execution.md, policies/handoffs.md, policies/source-driven.md e policies/evals.md. Hipótese sem dado do produto recebe o rótulo HIPOTESE. Exemplo de app externo (Duolingo, Strava, Oura) entra como ANALOGIA, nunca como prova para o produto do usuário.

Fronteira com skills vizinhas:

• 73-saas-conversion-playbook cuida de ativação e trial→pago. Esta skill começa onde aquela termina: o usuário ativou (ou pagou) e agora precisa voltar. O evento de ativação é o mesmo nas duas; não redefinir aqui
• 02-ui-ux-design (references/session-psychology.md) cuida de como uma sessão é sentida. Esta skill cuida do retorno ao longo de semanas
• 57-mobile-ux-foundations cuida de permissão de push e onboarding mobile. Push não é produto: esta skill decide o loop; a 57 decide como pedir a permissão
• 21-data-analytics é dona da taxonomia de eventos; esta skill nomeia os eventos de retenção e entrega para lá
• 61-content-growth-engine traz o usuário certo; distribuição sem loop de retenção enche balde furado

Quando Usar

• D1/D7/D30 abaixo do esperado, ou "o usuário usa uma vez e some"
• desenhar o sistema de retorno de um produto novo antes do lançamento
• decidir se streak, score diário, comunidade ou notificação fazem sentido para este produto
• revisar se o switching cost atual é ético ou hostil

Quando Não Usar

• ativação e conversão para pago (onboarding, paywall, trial) — skill 73
• churn de assinatura por cobrança (dunning, cancel-save) — skill 73, seção de lifecycle
• a sensação de uma única tela ou sessão — skill 02, references/session-psychology.md
• implementação técnica de push/notificação — skills 57 e 04

Entradas Esperadas

• produto: o que faz, para quem, plataforma
• o resultado que o usuário busca de novo e com que frequência ele surge na vida real
• dados de retenção se existirem (D1/D7/D30, curva de coorte) e o evento usado para medir
• o que existe hoje de personalização, notificação, hábito, comunidade e histórico

Faltando dado, assumir e marcar HIPOTESE. No máximo 5 perguntas; não bloquear o diagnóstico.

Saídas Esperadas

• loop nomeado + cadência real do job
• aha localizado e TTV esperado
• tabela das 5 táticas: estado atual → movimento → tela → gatilho → evento
• evento de retenção (nunca "abriu o app") e scorecard D1/D7/D30/D90
• plano de 4 semanas, uma tática por semana, aha primeiro
• lista do que não fazer neste produto e por quê

Fluxo Obrigatório

1. Nomear o loop. Qual resultado o usuário busca de novo e em que cadência: diária (sono, finanças do dia, idioma), semanal (relatório, treino longo, planejamento) ou episódica (viagem, declaração de imposto). Forçar cadência diária num job semanal é o erro mais caro desta skill.
2. Localizar o aha. A primeira vez que esse resultado aparece. TTV p50 dos ativados abaixo de 5 minutos (faixa de skills/73-saas-conversion-playbook/references/playbook.md).
3. Auditar as 5 táticas com references/tactics.md: presente, fraca ou ausente, com evidência.
4. Prescrever um movimento por tática, com tela, gatilho, copy e evento. Um movimento, não uma lista de ideias.
5. Definir o evento de retenção: repetiu a ação central, não apenas abriu. Montar o scorecard.
6. Separar lock-in ético de hostil em todo movimento da tática 5.
7. Ordenar o plano pela sequência de references/tactics.md (aha → personalização → hábito → ativo durável → comunidade). Comunidade antes de densidade é cemitério.
8. Checkpoint antes de entregar: todo movimento tem evento nomeado; nenhuma métrica fora das faixas citadas sem HIPOTESE; nenhum exemplo externo sem ANALOGIA.

Anti-Padrões

• streak como único sistema de hábito, ou streak sem valor por trás (vira ansiedade e desinstalação)
• comunidade no onboarding antes de o usuário ter um resultado pessoal
• lock-in hostil (bloquear export, sequestrar dado) apresentado como retenção
• tratar push notification como produto
• personalização rasa ("Olá, Felipe") contada como personalização
• evento de retenção = "abriu o app"
• prometer lift percentual

Evidência de Conclusão

• loop e cadência nomeados, com justificativa da cadência pelo job real
• as 5 táticas auditadas com evidência, cada uma com um movimento e um evento
• evento de retenção definido como repetição da ação central
• plano ordenado com aha na semana 1 e comunidade por último
• todo movimento da tática 5 permite export

Handoff

Recebe de

• 73-saas-conversion-playbook — evento de ativação e modelo comercial
• 83-growth-action-plan — quando o pedido é o plano de 4 semanas completo; esta skill preenche a seção de retenção

Entrega para

• 21-data-analytics — eventos personalized_home_viewed, aha, habit_loop_completed, streak_at_risk, asset_created, community_action
• 02-ui-ux-design — telas do loop (ritual de abertura, tela de sucesso, empty state com ação)
• 57-mobile-ux-foundations — quando o loop depende de pre-permission de push
• 04-frontend-integration — implementação das telas aprovadas

Integração com Pipeline

73 (ativação/conversão) → 82 (retenção) → 21 (instrumentação) → 02/04 (telas). O orquestrador (09) aciona esta skill quando o sintoma é retorno, não conversão.

Recursos

• references/tactics.md — as 5 táticas com padrões, regras, evento e movimento típico; scorecard por janela; ordem de implementação

Fontes

Adaptado da skill high-retention-apps de um pacote de UX/conversão consolidado pelo usuário (set/2026), que resume a análise de Wyatt Feaster sobre 1000+ apps iOS de alta retenção ("I Analyzed 1000 Apps With High Retention Rates"). Medido por grep antes de criar: nenhuma skill do kit cobria retenção pós-ativação (a 73 cita D7 só como meta). Exemplos de apps são analogias da fonte; nenhum número foi verificado de forma independente.