Cómo Configurar las Analíticas Antes de que Tu App Salga al Mercado
Los datos desde el primer día valen diez veces más que los datos del segundo mes. Si lanzas sin las analíticas configuradas, estás volando a ciegas exactamente en el momento en que la información es más valiosa.
La filosofía de las analíticas
No necesitas analíticas exhaustivas. Necesitas las analíticas correctas. El objetivo es instrumentar los eventos específicos que te dirán si tu hipótesis principal es verdadera y si los usuarios están progresando a través del recorrido principal que diseñaste.
Todo lo demás es ruido que desperdicia tiempo de ingeniería y aumenta la complejidad de los datos.
Los cinco eventos que necesita cada app
1. Primera apertura La primera vez que cualquier usuario abre la app después de instalarla. Esta es tu línea base: cada otra métrica es un subconjunto de esta.
2. Incorporación completada Cuando un usuario completa con éxito tu flujo de incorporación y llega al estado principal de la app por primera vez. La tasa de conversión de Primera Apertura a Incorporación Completada es tu primera métrica crítica. Si una parte significativa de los usuarios no está completando la incorporación, esta necesita mejoras antes que cualquier otra cosa.
3. Acción principal realizada La primera vez que un usuario realiza la acción central de tu app: registrar un entrenamiento, hacer una reserva, enviar un mensaje, crear un listado, cualquiera que sea tu acción principal. Esta es tu señal de product-market fit. Si los usuarios completan la incorporación pero nunca realizan la acción principal, tu producto tiene un problema de comunicación del valor.
4. Retorno el día 1 ¿El usuario volvió a abrir la app en las 24 horas siguientes a su primera apertura? La retención del día 1 (comúnmente llamada retención D1) es el indicador temprano más predictivo de la retención a largo plazo. Síguelo desde el primer día y presta atención a cualquier caída tras un cambio de producto — la dirección importa más que cualquier referencia absoluta.
5. Retorno el día 7 ¿El usuario volvió a abrir la app en los 7 días siguientes? La retención D7 separa las apps que los usuarios encuentran habitualmente útiles de las apps que prueban una vez y olvidan. Si la D7 mejora en cohortes sucesivas, es una señal positiva — si se estanca o cae, el problema está en el onboarding o en el valor central del producto.
Recomendaciones de plataformas
Firebase Analytics: Gratuito, potente, se integra con todo el ecosistema de Google (Google Ads, BigQuery para análisis avanzado). La mejor opción si ya estás usando Firebase para tu backend.
Mixpanel: Análisis de embudo de primera categoría e historial de eventos a nivel de usuario. El nivel gratuito es suficientemente generoso para la mayoría de las apps en etapas tempranas. Elige Mixpanel si esperas hacer un análisis profundo del embudo.
PostHog: Código abierto, autoalojable, incluye grabación de sesiones y banderas de funcionalidades. La mejor opción si quieres la propiedad total de los datos o estás construyendo una app web junto a tu app móvil.
Orientación de implementación
Define cada evento por escrito antes de que comience la implementación. Para cada evento, documenta: nombre del evento, cuándo se activa y las propiedades adjuntas (ID de usuario, plataforma, versión de la app, versión de la funcionalidad).
Este documento de taxonomía de eventos es un contrato entre tú y tu desarrollador. Sin él, los nombres de eventos se vuelven inconsistentes ("onboarding_complete" vs "OnboardingComplete" vs "onboarding_finished"), y tus datos se vuelven inútiles para la comparación a lo largo del tiempo.
Prueba cada evento en desarrollo antes de lanzar. El error más común de analíticas es lanzar con eventos rotos: eventos que se activan en el momento equivocado, con valores de propiedad incorrectos, o que no se activan en absoluto. Incluye las pruebas de analíticas en tu lista de QA previa al lanzamiento como un requisito de primera clase.
El panel que realmente necesitas en el lanzamiento
El día del lanzamiento, necesitas ver cuatro números casi en tiempo real: 1. Instalaciones totales hoy 2. Tasa de finalización de incorporación 3. Tasa de finalización de la acción principal 4. Tasa de retención D1 de las instalaciones de ayer
Todo lo demás puede esperar hasta que tengas suficientes datos para ser estadísticamente significativo.
Qué herramienta de analítica elegir
No necesitas pagar por la analítica para lanzar. Toda herramienta seria tiene un plan gratuito que aguanta de sobra una app que aún no ha alcanzado el product-market fit. Esto es lo que ofrece cada una en realidad, para que elijas con datos y no con marketing.
Firebase Analytics (Google Analytics para Firebase) es gratuito y sin límite de volumen de eventos, algo poco habitual. Puedes definir hasta 500 tipos de eventos distintos y registrarlos sin límite de cantidad. Es la opción natural si tu app ya usa Firebase como backend. La contrapartida: sus informes son menos flexibles para investigar a fondo a nivel de usuario que las herramientas especializadas que siguen.
Mixpanel tiene un plan gratuito limitado a un millón de eventos al mes, con asientos de equipo ilimitados y sin necesidad de tarjeta de crédito. Ese tope es suficiente para la mayoría de las apps tempranas. Mixpanel está construido en torno a embudos, retención y cohortes, lo que lo convierte en una opción por defecto sólida si quieres entender el comportamiento, no solo contar instalaciones.
Amplitude ofrece un plan gratuito Starter que cubre hasta 10.000 usuarios seguidos al mes y hasta dos millones de eventos. Está en la misma categoría que Mixpanel — análisis de comportamiento a fondo, embudos, retención, cohortes — y la elección entre ambos suele reducirse a qué interfaz prefieres.
PostHog incluye un millón de eventos al mes gratis, sin tarjeta de crédito, y es de código abierto y autoalojable bajo licencia MIT. Elige PostHog si quieres la propiedad total de tus datos, o si estás construyendo una app web junto a tu app móvil y quieres una sola herramienta para ambas.
Elige una e instruméntala bien. Usar dos herramientas en el lanzamiento duplica el trabajo y rara vez duplica el conocimiento. Añade una segunda más adelante, cuando ya sepas qué preguntas quieres responder.
Analítica de eventos frente a analítica de embudos
Estos dos términos confunden a muchos fundadores primerizos, así que aquí va la versión en lenguaje sencillo.
La analítica de eventos cuenta cosas que ocurrieron. ¿Cuántos usuarios abrieron la app hoy? ¿Cuántos realizaron la acción principal esta semana? Cada evento es un hecho aislado con una marca de tiempo y algunas propiedades asociadas. La analítica de eventos responde al "cuánto" y al "cuántos".
La analítica de embudos mide el avance a través de una secuencia de pasos. Toma una lista ordenada de eventos — por ejemplo, Primera Apertura, luego Incorporación Completada, luego Acción Principal Realizada — y muestra qué porcentaje de usuarios pasó de cada paso al siguiente, y dónde se quedaron por el camino.
La diferencia importa porque los números dicen cosas distintas. La analítica de eventos puede mostrarte que 200 personas realizaron tu acción principal. Útil, pero incompleto. Un embudo muestra que 1.000 personas abrieron la app, 600 terminaron la incorporación y solo 200 llegaron a la acción principal. Ahora sabes exactamente dónde estás perdiendo gente: la mayor fuga está entre la incorporación y la acción principal, no en la puerta de entrada.
Configura al menos un embudo antes de lanzar: Primera Apertura a Incorporación Completada a Acción Principal Realizada. Es la vista más útil que tendrás en tu primer mes.
Cómo medir las compras dentro de la app para la analítica de ingresos
Si tu app genera dinero, los ingresos son simplemente un evento más, y deberías tratarlos así desde el primer día.
Envía un evento "Purchase" (compra) cada vez que un usuario paga, y adjunta el importe y la moneda como propiedades (por ejemplo, value: 9.99 y currency: "EUR"). Una vez que los ingresos viven en tu herramienta de analítica junto a todo lo demás, puedes responder preguntas que los números de descargas nunca responderán:
- ¿Qué camino de incorporación lleva a más usuarios que pagan?
- ¿Los usuarios que realizan la acción principal en su primera sesión pagan en mayor proporción?
Dos apuntes prácticos. Primero, Firebase Analytics puede recopilar de forma automática los eventos de compra dentro de la app y de suscripción en plataformas de Apple sin código adicional, lo que ahorra tiempo de configuración si trabajas con ese stack. Segundo, la cifra de ingresos que muestra tu herramienta no es tu saldo bancario: Apple y Google se quedan con su comisión de plataforma, y hay reembolsos. Trata la analítica de ingresos dentro de la app como una señal de dirección sobre el comportamiento, y cuadra los euros reales en los informes de pagos de la App Store y de Google Play.
Registra los importes en una sola moneda o, como mínimo, guarda la moneda en cada evento de compra. Mezclar euros y dólares en una misma métrica sin etiquetarlos produce cifras que parecen precisas y no significan nada.
Análisis de cohortes para la retención
Una cohorte es un grupo de usuarios que comparten un punto de partida, normalmente la semana en que abrieron tu app por primera vez. El análisis de cohortes sigue a cada grupo por separado a lo largo del tiempo en lugar de mezclar a todo el mundo en una sola media.
Esto importa porque un único número de retención mezclado oculta la verdad. Si lanzas una mejora de incorporación en marzo, los usuarios que llegaron en enero arrastran tu media hacia abajo y hacen que el cambio parezca no haber servido de nada. Las cohortes resuelven esto: comparas a quienes llegaron antes del cambio con quienes llegaron después, semana a semana.
La vista estándar es una tabla de retención. Cada fila es una cohorte (semana uno, semana dos, y así sucesivamente). Cada columna es cuántas semanas después. Cada celda muestra el porcentaje de esa cohorte que sigue activo. Léela de arriba abajo y verás si las cohortes más nuevas retienen mejor que las antiguas: la prueba más clara de que tu producto está mejorando de verdad.
Las cuatro herramientas anteriores construyen esto por ti de forma automática en cuanto tus eventos de Primera Apertura y de retorno se disparan correctamente. No necesitas un analista de datos. Necesitas los eventos bien instrumentados y la disciplina de mirar la tabla cada semana.
El número que hay que vigilar: si la retención de la primera semana de cada nueva cohorte es más alta que la anterior. Si sube, te estás acercando al product-market fit. Si se mantiene plana, tus cambios no están dando donde importa.
Cómo es un buen panel para una app sin product-market fit
Antes del product-market fit, tu panel tiene un solo trabajo: decirte si el producto está mejorando. Debe caber en una pantalla y no contener nada sobre lo que no actuarías.
Un buen panel previo al product-market fit muestra:
- Usuarios nuevos por semana — tu volumen de entrada, para saber que el resto de tus números son significativos.
- Tasa de activación — el porcentaje de usuarios nuevos que completan la incorporación y realizan la acción principal. Es tu número más importante antes del product-market fit.
- El embudo principal — Primera Apertura a Incorporación Completada a Acción Principal Realizada, con la caída en cada paso.
- Retención por cohortes semanales — la tabla de antes, para ver si la retención mejora cohorte tras cohorte.
- Ingresos por semana (si monetizas) — y el porcentaje de usuarios activos que pagan.
Ese es el panel entero. Resiste la tentación de añadir más.
El error que comete casi todo fundador es construir un panel lleno de métricas de vanidad — descargas totales, eventos totales, vistas de pantalla — que solo suben pase lo que pase y nunca te dicen qué arreglar. No pueden decirte si tu producto funciona. La activación y la retención sí.
Revisa este panel cada semana, no cada hora. Sin product-market fit, los números diarios son demasiado ruidosos para actuar sobre ellos, y mirarlos fijamente solo te pondrá ansioso. Míralo una vez por semana, pregúntate qué cambió y decide qué construir a continuación. Ese ciclo — medir, aprender, lanzar — es justo el motivo de configurar la analítica antes de lanzar.