Construir seu próprio stack de analytics ou só plugar três SDK?
Todo time de mini-jogos instala um SDK de analytics na primeira tarde. Quase ninguém chega a possuir seus dados. Os SDKs servem para "quantos instalaram", mas no momento em que você quer saber "qual coorte derrubou a retenção D7 e por quê", está consultando três painéis que não concordam, sobre um esquema de eventos que você nunca projetou. A escolha não é construir contra comprar; é se você continua alugando suas perguntas ou as possui. Aqui está a parte que se pula na pressa.
Q: Por que três SDK juntos não somam um stack de dados?
Porque cada SDK detém seu próprio esquema, sua própria costura de identidade e sua própria definição de "sessão", e nenhum conversa com os outros sem você. Seu SDK de atribuição diz que 1200 instalações vieram do canal A; seu SDK de produto diz 900 sessões; seu SDK de anúncios diz 1400 conversões. Eles não estão errados — estão contando universos diferentes com relógios diferentes. Sem um esquema de eventos único e um user ID estável que sobreviva aos três, você não consegue unir, e não consegue responder a única pergunta que importa: qual canal traz usuários que de fato pagam. Alugar três ferramentas significa que você só pode fazer as perguntas que cada ferramenta foi construída para responder, que nunca é sua pergunta real.
Q: Se você constrói, qual é o primeiro passo que não é escrever ETL?
Projete o esquema de eventos antes de escrever uma linha de pipeline. Um armazém é só um banco de dados; a parte difícil é decidir o que contém um evento "purchase", o que é o user ID estável e como você nomeia as coisas para que daqui a seis meses "level_complete" signifique o mesmo. Times que pulam isso terminam com vinte eventos "buy" levemente diferentes e um cientista de dados que pede demissão. O segundo passo é um ponto de ingestão único — um SDK que envia tudo ao seu armazém, e só então você decide o que encaminhar às redes de anúncios. Possua os eventos brutos; alugue as ferramentas a jusante. Essa ordem é o que deixa você fazer novas perguntas depois em vez de implorar um relatório ao fornecedor.
Q: PII e conformidade — como não estragar tudo no dia um?
Trate o ID do jogador e o país de faturamento como radioativos desde o primeiro commit. O erro barato é registrar tudo "por via das dúvidas", o que transforma seu armazém em um passivo de GDPR/CCPA no instante em que ele enche. A disciplina: colete um ID anônimo estável, empurre o PII (e-mail, pagamento) apenas ao processador e mantenha um mapa de dados que diga exatamente qual tabela guarda o quê e por quanto tempo. Os caminhos de exclusão importam mais que os de coleta — se você não consegue provar que pode apagar um usuário, não pode mantê-lo legalmente na UE. Esta é a única área onde "vamos consertar depois" é uma multa esperando para acontecer.
Q: Como decidir, de fato, construir ou comprar?
Use o teste de posse. Se suas perguntas são padrão — instalações, retenção, taxa sem crash — três SDKs bastem e você deve lançar. No instante em que sua vantagem competitiva depende de uma pergunta que só você pode fazer — "jogadores do Brasil que viram o anúncio tutorial churnam mais devagar?" — você precisa desse evento no seu próprio armazém. O híbrido que funciona: possua o fluxo de eventos brutos e o user ID, alugue a visualização e as APIs de atribuição por cima. A tabela é a linha que a maioria traça tarde demais.
| Se você precisa de… | Abordagem | Por que | O custo |
|---|---|---|---|
| Só métricas padrão | 2–3 SDKs | Rápido, sem pipeline | Não faz perguntas entre ferramentas |
| Uma pergunta só sua | Possua o armazém de eventos | Você guarda a pergunta | ETL + manutenção de esquema |
| Misto | Possua bruto, alugue visualização | O melhor dos dois | Disciplina de integração |
| Jogadores na UE/CA | Minimize PII desde o dia 1 | Conformidade não é opcional | Contenção ao registrar |
Seus dados são um ativo que você possui ou um aluguel que você renova. O aluguel parece mais barato até a pergunta que você precisa não estar no plano.
