¿Construyes tu propio stack de analítica o solo conectas tres SDK?
Cada equipo de mini-juegos instala un SDK de analítica en la primera tarde. Casi nadie llega a poseer sus datos. Los SDK están bien para "cuántos instalaron", pero en el momento en que quieres saber "qué cohorte bajó su retención D7 y por qué", estás consultando tres paneles que no coinciden, sobre un esquema de eventos que nunca diseñaste. La elección no es construir contra comprar; es si sigues alquilando tus preguntas o las posees. Aquí está la parte que se salta en el apuro.
Q: ¿Por qué tres SDK juntos no suman un stack de datos?
Porque cada SDK posee su propio esquema, su propia costura de identidad y su propia definición de "sesión", y ninguno habla con los otros sin ti. Tu SDK de atribución dice que 1200 instalaciones vinieron del canal A; tu SDK de producto dice 900 sesiones; tu SDK de anuncios dice 1400 conversiones. No están equivocados — están contando universos distintos con relojes distintos. Sin un esquema de eventos único y un user ID estable que sobreviva a los tres, no puedes unirlos, y no puedes responder la única pregunta que importa: qué canal trae usuarios que de verdad pagan. Alquilar tres herramientas significa que solo puedes hacer las preguntas que cada herramienta fue construida para responder, que nunca es tu pregunta real.
Q: Si construyes, ¿cuál es el primer paso que no es escribir ETL?
Diseña el esquema de eventos antes de escribir una línea de pipeline. Un almacén es solo una base de datos; la parte difícil es decidir qué contiene un evento "purchase", qué es el user ID estable y cómo nombras las cosas para que dentro de seis meses "level_complete" signifique lo mismo. Los equipos que saltan esto terminan con veinte eventos "buy" ligeramente distintos y un científico de datos que renuncia. El segundo paso es un punto de ingesta único — un SDK que envía todo a tu almacén, y luego decides qué reenviar a las redes de anuncios. Posee los eventos crudos; alquila las herramientas aguas abajo. Ese orden es lo que te deja hacer nuevas preguntas después en vez de pedirle un reporte al proveedor.
Q: PII y cumplimiento — ¿cómo no arruinarla desde el día uno?
Trata el ID del jugador y el país de facturación como radiactivos desde el primer commit. El error barato es registrar todo "por si acaso", lo que convierte tu almacén en un pasivo de GDPR/CCPA en cuanto se llena. La disciplina: recolecta un ID anónimo estable, empuja el PII (correo, pago) solo al procesador y mantén un mapa de datos que diga exactamente qué tabla guarda qué y por cuánto tiempo. Las rutas de borrado importan más que las de recolección — si no puedes probar que puedes borrar a un usuario, no puedes mantenerlo legalmente en la UE. Este es el único área donde "lo arreglaremos después" es una multa esperando ocurrir.
Q: ¿Cómo decides de verdad construir o comprar?
Usa la prueba de propiedad. Si tus preguntas son estándar — instalaciones, retención, tasa sin crash — tres SDK están bien y deberías lanzar. En cuanto tu ventaja competitiva depende de una pregunta que solo tú puedes hacer — "¿los jugadores de Brasil que vieron el anuncio tutorial churnen más lento?" — necesitas ese evento en tu propio almacén. El híbrido que funciona: posee el flujo de eventos crudos y el user ID, alquila la visualización y las APIs de atribución encima. La tabla es la línea que la mayoría traza demasiado tarde.
| Si necesitas… | Enfoque | Por qué | El costo |
|---|---|---|---|
| Solo métricas estándar | 2–3 SDK | Rápido, sin pipeline | No puedes hacer preguntas entre herramientas |
| Una pregunta solo tuya | Posee el almacén de eventos | Conservas la pregunta | ETL + mantenimiento de esquema |
| Mixto | Posee crudo, alquila visualización | Lo mejor de ambos | Disciplina de integración |
| Jugadores en UE/CA | Minimiza PII desde el día 1 | Cumplimiento no es opcional | Contención al registrar |
Tus datos son un activo que posees o un arrendamiento que renuevas. El arrendamiento parece más barato hasta que la pregunta que necesitas no está en el plan.
