Checklist Google Play e App Store
1. Dados confirmados pelo projeto
- Conta: sim.
- Login: Google, Apple e PlayFab guest login.
- Eliminar conta dentro do jogo: parece existir CloudScript PlayFab; falta confirmar fluxo visível para o utilizador.
- AdMob: ativo.
- Unity LevelPlay: ativo.
- Unity Analytics: as definições do projeto indicam que analytics pode estar ativo; confirmar se Unity Analytics ou telemetria do Unity Dashboard entram no build final.
- Crash reporting: parece desligado na auditoria, mas confirmar serviços Unity finais.
- Notificações: há notificações locais Android para vidas/cooldowns no projeto.
- Formulário de suporte: a página pública de suporte envia para um Cloudflare Worker, que envia o email através da Resend.
- Identificador guest: login convidado pode usar ID gerado ou identificador derivado do dispositivo; identificadores derivados do dispositivo devem ser minimizados e declarados como identificadores de dispositivo.
- Pacotes técnicos/locais identificados: Unity Purchasing, Localization, Input System, URP, Cinemachine, Visual Scripting, UGUI, Vector Graphics, Adaptive Performance e Kamgam text auto-sizing; rever se algum pacote final envia telemetria externa.
- PlayFab: cloud saves, leaderboards, estatísticas, inventário, entitlements e validação de compras.
- Não há chat, nomes/perfis públicos ou conteúdo criado pelo utilizador.
- Compras: compras únicas, incluindo Remove Ads. Sem subscrições.
- Público: inclui crianças, adolescentes e adultos.
- Objetivo de idade: faixa etária mais abrangente possível para jogo de palavras.
2. Google Play Data Safety
A Google exige uma secção Data Safety clara e precisa para cada app. A declaração deve cobrir a soma das práticas de recolha/partilha da app, incluindo SDKs de terceiros, versões, regiões e idades.
Para a WordWildWest, provavelmente será necessário declarar recolha/partilha relacionada com:
- identificadores de utilizador/conta: PlayFab ID, custom/guest ID, Google/Apple ID de plataforma, display name;
- email, se for recebido através de login, suporte ou recuperação;
- identificadores de dispositivo e advertising ID;
- IP, dados técnicos, app version e diagnóstico;
- atividade na app: progresso, pontuação, estatísticas, conquistas, leaderboards, cloud saves, inventário, moeda virtual e interações;
- compras: produto, receipt/token, validação de compra, entitlement e remove_ads_permanent;
- interações com anúncios e medição publicitária;
- notificações locais, mensagens de suporte se o formulário estiver ativo, e analytics/diagnóstico/desempenho se ativados.
Finalidades prováveis: funcionalidade da app, gestão de conta, analytics/diagnóstico se ativo, publicidade/marketing, prevenção de fraude, segurança e conformidade legal.
3. Google Play account deletion
Como a aplicação permite criação de conta, deve existir uma forma de iniciar eliminação de conta dentro da app. Também será necessário responder às perguntas de eliminação de dados no Play Console e disponibilizar informação coerente no site/política.
A implementação mínima recomendada: Settings > Account > Delete Account, mais a página pública Pedido de Eliminação de Conta, com confirmação, aviso de perda de progresso/cloud saves/leaderboards/compras associadas, e chamada ao fluxo PlayFab CloudScript ou pedido autenticado ao backend.
4. Google Play target audience e Families
Como o público inclui crianças, a secção Target audience and content deve indicar faixas etárias que incluem crianças. Isso aciona requisitos da Families Policy, incluindo uso de SDKs de anúncios certificados para famílias quando forem servidos anúncios a crianças ou a utilizadores de idade desconhecida.
Recomendação: usar age screen neutro ou modo seguro por defeito para crianças, configurar anúncios para crianças/idade desconhecida como não personalizados, com rating adequado e sem tracking comportamental. Confirmar se todos os SDKs de anúncios usados para crianças são permitidos pela Google Play Families Policy.
5. Apple App Privacy Labels
A Apple exige App Privacy Details no App Store Connect, incluindo tipos de dados recolhidos, se estão ligados ao utilizador, finalidades e se são usados para tracking.
Para a WordWildWest, preparar respostas para: identifiers, user content/profile/display name, usage data, diagnostics/analytics se ativo, purchases, coarse location via IP, contact info se email for recolhido, support content se formulário estiver ativo, advertising data e gameplay/account data.
6. Apple ATT e tracking
Se a aplicação recolher dados e os partilhar com outras empresas para tracking entre apps/sites, ou usar IDFA para publicidade personalizada, deve usar App Tracking Transparency antes desse tracking. Para crianças ou contas infantis, a disponibilidade de tracking é limitada pelas regras da Apple.
Se a app não for usar tracking no iOS, remover IDFA/NSUserTrackingUsageDescription e configurar SDKs para não fazer tracking. Se for usar tracking, implementar ATT e alinhar com consentimento UE/UK quando aplicável.
Os privacy manifests da Apple também devem ser revistos antes da submissão. Se a app ou SDKs incluídos usarem required reason APIs, recolherem dados, permitirem recolha de dados ou contactarem tracking domains, o build iOS final deve incluir as declarações PrivacyInfo.xcprivacy necessárias.
7. Apple account deletion
Apps que suportam criação de conta devem permitir iniciar eliminação de conta dentro da app. O fluxo não deve ser apenas por email. Pode haver passos de confirmação e retenção de dados legalmente necessária, mas o utilizador deve conseguir iniciar o processo dentro da app.
8. Classificação etária
Preencher os questionários de classificação etária nas lojas de acordo com conteúdo real: jogo de palavras, anúncios, compras, funcionalidades online, leaderboards, login, conteúdo gerado por utilizadores se existir e interação entre utilizadores se existir.
Para manter faixa etária ampla, evitar chat livre, conteúdo gerado por utilizadores não moderado, anúncios inadequados, tracking comportamental de crianças e compras com pressão indevida.
9. Antes da submissão
- Implementar botão de apagar conta dentro da app.
- Confirmar SDKs e serviços Unity reais no build final, sobretudo se existe analytics/crash reporting ativo.
- Confirmar a definição Unity Analytics e desligar ou declarar consistentemente em políticas, Google Play Data Safety e Apple labels.
- Confirmar estado final do formulário de suporte, endpoint Cloudflare Worker, domínio remetente da Resend e declarações de loja/privacidade antes do lançamento. Se outro backend de formulário for ativado posteriormente, atualizar este site, declarações das lojas e avisos de SDK.
- Confirmar fluxo de permissão de notificações locais e permissão Android 13+.
- Evitar ou substituir identificadores guest derivados do dispositivo quando possível; se mantidos, declarar como identificadores de dispositivo.
- Confirmar que serviços do Unity Dashboard e manifests de packages coincidem com o Aviso de Parceiros e SDKs publicado.
- Configurar consentimento UE/UK antes de AdMob/LevelPlay e qualquer SDK não essencial.
- Configurar tratamento infantil: anúncios não personalizados, SDKs permitidos, sem tracking comportamental.
- Preencher Google Play Data Safety com base no build real.
- Preencher Apple App Privacy Labels com base no build real.
- Concluir revisão Apple privacy manifest / required reason APIs para o build iOS final.
- Validar classificação etária e target audience.
- Garantir que as políticas publicadas correspondem exatamente ao comportamento do jogo.