Entrevista para Product Manager: ¿Cómo diagnosticarías una caída del 15% en el DAU?

Planteamiento y escenarios aplicables

Los usuarios activos diarios (DAU) de un producto de colaboración cayeron de un promedio semanal de 1.000.000 a 850.000. La comparación cubre dos semanas completas con la misma distribución de días de la semana, por lo que la disminución reportada es del 15%. Para esta pregunta, DAU significa usuarios únicos que completan al menos una acción central de colaboración durante un día calendario UTC. Una acción central puede ser ver, editar o comentar en un documento compartido, pero su definición no puede cambiar a mitad del análisis.

Explica cómo confirmarías que la caída es real, localizarías la brecha de 150.000 usuarios en un recorrido de usuario específico, validarías la hipótesis principal y decidirías si reparar datos, detener un despliegue, revertir un cambio de producto o seguir observando. La pregunta aplica a roles de product manager, growth product manager y product analytics. Evalúa si un candidato puede transformar una anomalía ambigua en una decisión de producto falsable, no si puede enumerar todas las causas posibles.

Cada detalle del producto, número de versión y desglose numérico a continuación es una suposición de entrevista, no datos reales de la empresa. El material público muestra que el diagnóstico de caídas de métricas sigue presente en la preparación de entrevistas de producto y analítica en 2026. La atribución a empresas que no pueda verificarse de forma independiente no se trata como un hecho aquí.

Qué evalúa el entrevistador

Primero, ¿puede el candidato congelar el contrato de la métrica? Los sistemas de analítica pueden utilizar diferentes eventos, ventanas y reglas de identidad para definir a un usuario activo. Sin un numerador, límite de fecha, versión del evento y clave de deduplicación, un candidato no puede distinguir entre personas que abandonan el producto y un reporte que las subcuenta.

Segundo, ¿puede el candidato acotar el problema con evidencia? Una respuesta sólida valida los datos, calcula la pérdida absoluta a través de segmentos mutuamente excluyentes y luego sigue un embudo anidado para los mismos usuarios con el fin de encontrar la primera ruptura. Decir "revisaría geografía, dispositivo, versión y canal" sigue siendo solo una lista de consultas; no indica qué va primero ni qué resultado cambia el siguiente paso.

Tercero, ¿puede el candidato separar correlación, atribución y acción? Un lanzamiento que ocurre al mismo tiempo que la caída crea una hipótesis principal. No establece causalidad porque las personas que adoptan ese lanzamiento ya pueden ser diferentes. El candidato debe agregar señales del lado del servidor, registros de errores, controles de despliegue gradual o una reversión controlada antes de hacer una afirmación más contundente.

Cuarto, ¿puede el candidato tomar una decisión reversible con información incompleta? Esperar una prueba causal perfecta puede agravar el perjuicio a los usuarios cuando un recorrido crítico está roto. Revertir un producto sano solo porque falló el seguimiento también tiene un costo. Una respuesta sólida establece la conclusión actual, la confianza, el umbral de acción y el próximo punto de decisión.

Preguntas para clarificar antes de responder

• ¿Cuál es el contrato exacto del DAU? ¿La actividad significa abrir la aplicación, mantenerse interactuando o completar una acción central? ¿El límite de fecha es UTC, hora local o una ventana móvil de 24 horas? La respuesta cambia tanto la consulta como la comparabilidad histórica.
• ¿Cómo se calculó el 15%? ¿Es una comparación de un solo día, el promedio de semanas adyacentes o un residuo de pronóstico? Este caso utiliza dos semanas calendario completas con la misma distribución de días laborables y fines de semana. Los días festivos y los datos incompletos requieren un tratamiento por separado.
• ¿Cuándo están completos los datos? Los eventos pueden llegar con retraso, rellenarse posteriormente (backfill), muestrearse, estar sujetos a umbrales o cambiarse a una nueva zona horaria. Si la semana actual aún no ha madurado, compara ventanas con el mismo nivel de madurez.
• ¿Qué cambió recientemente? Obtén cambios de lanzamientos, seguimiento y modelos de datos; cambios en marketing, notificaciones, precios y permisos; interrupciones externas y días festivos. Una línea de tiempo pone a prueba las hipótesis, pero no las demuestra simplemente porque dos eventos coincidan.
• ¿La caída incluye daño a los usuarios? Las caídas de la aplicación (crashes), fallas de inicio de sesión, errores al cargar la pantalla de inicio, fallas al guardar y contactos a soporte determinan qué tan rápido se debe contener el riesgo. Si solo el reporte cae mientras las acciones centrales del lado del servidor permanecen estables, prioriza la vía de medición.
• ¿Qué controles de riesgo existen? ¿Puede el equipo detener un despliegue gradual, revertir una versión, desactivar un flag o preservar un grupo de control? La reversibilidad determina si contener el problema mientras se recopila más evidencia u observar primero.
• ¿Cuáles señales son independientes? Los eventos del cliente, las solicitudes del servidor, las escrituras en bases de datos, los reportes de crash y los contactos a soporte no proporcionan corroboración independiente si todos comparten el mismo punto de falla.

Estructura de respuesta de 30 segundos

"Primero congelaría el evento de DAU, la regla de identidad, la zona horaria y la ventana de madurez de los datos; luego contrastaría la caída del 15% con los eventos sin procesar y las acciones centrales del lado del servidor. Si es real, calcularía la pérdida absoluta en segmentos mutuamente excluyentes de plataforma, versión, geografía y antigüedad, en lugar de comparar únicamente porcentajes. Después rastrearía a los mismos usuarios a través de la apertura de la app, inicio de sesión, carga de inicio y acción central para encontrar el primer paso roto, y alinearía esa ruptura con lanzamientos y eventos externos. Una hipótesis principal necesita un segundo tipo de señal o una reversión controlada. Si el seguimiento falló, se reparan y rellenan los datos. Si un lanzamiento reciente rompió el flujo central, se detiene o se revierte. Si la caída es amplia y gradual, se investiga adquisición, retención, estacionalidad y competencia".

Análisis detallado paso a paso

Paso 1: Demostrar que la métrica es confiable

Escribe el contrato de la métrica como una sentencia ejecutable: DAU = valores user_id estables y distintos con al menos una core_collaboration_action durante un día calendario UTC. Congela el tratamiento de bots, cuentas internas, fusiones de identidad de anónimo a autenticado, identidad multidispositivo y eventos tardíos. Hasta que la definición no sea estable, cada segmento puede estar comparando dos significados diferentes de "activo".

Ejecuta tres tipos de comprobaciones. Recalcula el panel a partir de eventos sin procesar. Compara los usuarios únicos en el evento central del lado del cliente con los usuarios únicos en solicitudes exitosas del lado del servidor. Revisa si la latencia, el renombre de eventos, los filtros, la fusión de identidades o las reglas de zona horaria cambiaron al inicio de la caída. Si el panel muestra 850.000 mientras aproximadamente 1.000.000 de usuarios aún completan la acción central en el servidor, el primer incidente está en la medición. Corrige la definición, anota la ventana afectada y evalúa el backfill; una reversión de producto no puede reparar un error de reporte.

Paso 2: Describir la forma de la anomalía

Indica tanto el cambio relativo como el absoluto: (850,000 - 1,000,000) / 1,000,000 = -15%, o 150.000 usuarios menos por día. Grafica valores diarios u horarios para distinguir entre una caída abrupta, una disminución gradual y un cambio en la composición de los días de la semana. Un corte abrupto merece alinearse con un lanzamiento, un trabajo de datos (data job) o una interrupción externa. Una pendiente descendente es más consistente con adquisición, retención, estacionalidad o un problema de valor a largo plazo.

La línea base debe ser comparable. Compara semanas completas con semanas completas, mercados con días festivos con su propio historial, y una funcionalidad de rápido crecimiento con un pronóstico que refleje su trayectoria. Las distribuciones históricas o los intervalos de predicción pueden demostrar que el movimiento difícilmente es ruido ordinario. La sorpresa estadística no identifica la causa.

Paso 3: Localizar por contribución absoluta, no por la mayor caída porcentual

La partición utilizada para el análisis de contribución debe ser mutuamente excluyente y exhaustiva. Para evitar contar dos veces a los usuarios multiplataforma, asigna a cada usuario en este ejemplo a la plataforma de su primera acción central ese día:

iOS representa 139.000 usuarios, aproximadamente el 92,7% de la brecha neta, por lo que investigar iOS primero es más eficiente que consultar a fondo cada mercado y canal a la vez. La contribución es cambio absoluto del segmento / cambio absoluto total. Si los segmentos en crecimiento compensan a los que caen, una contribución puede ser negativa o superar el 100%; no es la proporción de usuarios del segmento.

Repite el cálculo dentro de iOS por versión, geografía, antigüedad de la cuenta y canal de adquisición. Cambia un corte a la vez y conserva los recuentos absolutos. Una caída del 80% en un mercado pequeño puede explicar solo cientos de usuarios, mientras que una caída del 20% en una versión ampliamente adoptada puede explicar la mayor parte del total.

Paso 4: Encontrar la primera ruptura en un embudo anidado

Construye conjuntos de usuarios anidados para el mismo día y con la misma clave de deduplicación. Cada usuario en un paso posterior debe pertenecer al paso anterior:

Las aperturas de la app y los inicios de sesión exitosos se mantienen casi estables. La primera ruptura ocurre entre el inicio de sesión y la carga exitosa de la pantalla de inicio. Una vez que la pantalla de inicio carga, la conversión a la acción central también es casi estable. "El DAU cayó" se ha transformado ahora en "los usuarios de iOS no pueden llegar a la superficie principal". Multiplicar tasas condicionales solo es válido cuando los conjuntos están genuinamente anidados y utilizan la misma ventana y clave de identidad. Multiplicar totales de eventos no relacionados crea un embudo falso.

Supongamos que un análisis posterior encuentra 200.000 usuarios con sesión iniciada en iOS 9.4.0 pero solo 50.000 cargas exitosas de inicio. Las versiones anteriores tienen 79.000 usuarios con sesión iniciada y 70.000 cargas exitosas de inicio. Si los usuarios únicos con una solicitud de carga de inicio exitosa del lado del servidor también caen de aproximadamente 269.000 a 118.000, en lugar de que solo desaparezca el evento del cliente home_loaded, la evidencia de una falla real en el flujo se vuelve mucho más sólida. Estas siguen siendo suposiciones del caso; demuestran cómo pasar de un agregado a una ruptura comprobable.

Paso 5: Clasificar las hipótesis según la evidencia

Agrupa las hipótesis en cuatro familias, pero prioriza solo aquellas que expliquen el momento, el alcance y la ruptura en el embudo:

1. Medición: un renombre de evento, pérdida de SDK, fusión de identidades o retraso de datos. Se espera que el DAU del cliente caiga mientras el éxito en el servidor y los comentarios de los usuarios se mantienen estables.
2. Cambio técnico o de producto interno: una regresión en la solicitud de inicio, permisos o ruta de almacenamiento en caché de iOS 9.4.0. Se espera que la caída se concentre en esa versión mientras aumentan los errores y las fallas de carga.
3. Alcance o suministro: se detuvieron las notificaciones, terminó una campaña o cayó la oferta de contenido. Se espera una pérdida antes de abrir la aplicación o en un canal de adquisición mientras el embudo dentro del producto permanece comparativamente estable.
4. Externo o estacional: días festivos, conectividad regional, políticas de plataforma o un evento competitivo. Se espera alineación con geografía, tiempo o grupo de usuarios en lugar de una versión interna específica.

La correlación temporal con la versión sigue siendo evidencia observacional. Los adoptantes de 9.4.0 pueden concentrarse por dispositivo o geografía. Compara versiones nuevas y antiguas dentro del mismo dispositivo y mercado, utiliza un control preservado por el despliegue gradual existente y, cuando sea seguro, detén o revierte una pequeña porción para ver si el éxito de carga de inicio y las acciones centrales se recuperan. Un control aleatorizado o preasignado es lo más sólido. Una comparación post-hoc debe mantener su advertencia de factores de confusión residuales.

Paso 6: Hacer que el diagnóstico genere una acción

En este caso, iOS explica cerca del 92,7% de la brecha neta, el embudo anidado localiza la falla en la carga de inicio, la señal del servidor se mueve en la misma dirección y la anomalía comienza cerca del lanzamiento de la versión 9.4.0. Si la falla bloquea el trabajo de los usuarios y detener o revertir el lanzamiento es reversible, la acción razonable es detener la expansión de 9.4.0 y revertir el tráfico afectado mientras el equipo identifica el defecto exacto. La contención no requiere localizar primero cada línea de código defectuosa.

Comunica la confianza explícitamente: "Tenemos alta confianza en que la mayor parte de la brecha proviene de la falla de carga de inicio en iOS. La versión 9.4.0 es la hipótesis causal principal, aún no una causa confirmada". Luego designa al responsable, la acción de reparación o reversión, los criterios de recuperación y la próxima actualización. La recuperación debe exigir que el éxito de carga de inicio, los usuarios de acciones centrales en iOS y el DAU general se muevan juntos, no simplemente ver un panel en verde.

Si, por el contrario, la contrastación muestra acciones centrales estables del lado del servidor, no reviertas el producto. Repara el rastreador o el data job, realiza el backfill del historial y registra el cambio de definición. Si todas las plataformas caen durante semanas, orienta el análisis hacia la entrada de nuevos usuarios, la retención de usuarios existentes y la frecuencia, y luego valida hipótesis de producto mediante investigación de usuarios, evidencia de canales o experimentos. La rama de evidencia cambia la acción; ese es el criterio de producto que evalúa esta pregunta.

Ejemplo de respuesta de alta calidad

"Primero convertiría el 15% en un problema falsable. DAU aquí significa usuarios únicos que completan una acción central de colaboración durante un día UTC, por lo que validaría la definición del evento, fusiones de identidad, datos tardíos y la comparación de semanas completas; luego lo recalcularía a partir de eventos sin procesar y acciones exitosas del lado del servidor. Si el servidor aún registra un millón de usuarios activos mientras el panel muestra 850.000, gestionaría un incidente de medición y no modificaría el producto.

Si la caída es real, la brecha absoluta es de 150.000 usuarios por día. Calcularía la contribución de cada segmento mutuamente excluyente. En el ejemplo, Web pierde 4.000, Android 7.000 e iOS 139.000. iOS explica aproximadamente el 92,7% de la caída neta, por lo que se investiga primero.

En iOS, las aperturas se mantienen en 300.000 y los inicios de sesión exitosos solo pasan de 280.000 a 279.000, pero las cargas exitosas de inicio caen de 270.000 a 120.000. La conversión después de una carga exitosa se mantiene cerca del 92,5%. La primera ruptura es la carga de la pantalla de inicio. Si la pérdida también se concentra en 9.4.0 y caen los usuarios con solicitudes exitosas de inicio en el servidor, establecería esa versión como la hipótesis principal y alinearía su lanzamiento con los registros de errores.

No atribuiría causalidad únicamente a la coincidencia temporal. Compararía versiones dentro del mismo dispositivo y geografía, usaría el control del despliegue gradual y detendría de forma segura la expansión o revertiría una fracción para ver si el embudo se recupera. Los usuarios ya están bloqueados de la superficie principal y la reversión es reversible, por lo que contendría el impacto antes de finalizar el análisis de causa raíz.

Mi actualización comunicaría: es altamente probable que la mayor parte de la brecha provenga de la falla de carga de inicio en iOS; 9.4.0 sigue siendo la causa no confirmada; la expansión se detuvo y la reversión está en curso con un responsable asignado. El incidente se considera recuperado solo cuando el éxito de carga de inicio, las acciones centrales en iOS y el DAU general se recuperen en conjunto. Si las acciones del servidor se mantienen estables, lo reclasificaré como un incidente de datos, repararé y rellenaré el seguimiento y evitaré una reversión del producto".

Errores comunes

• Hacer una lluvia de ideas de diez causas de inmediato → las hipótesis no tienen prioridad y no producen una siguiente consulta → valida los datos, luego acota con la contribución absoluta y la primera ruptura del embudo.
• Dejar el DAU sin definir → un cambio de evento, ventana o identidad parece comportamiento del usuario → establece primero el evento, clave de deduplicación, zona horaria, exclusiones y ventana de madurez.
• Mirar solo la caída porcentual por segmento → una caída enorme en un segmento diminuto puede no explicar la brecha total → calcula el cambio absoluto y la contribución a la brecha neta.
• Sumar segmentos superpuestos → el mismo usuario multiplataforma recibe múltiples causas y el total no se puede reproducir → usa una partición mutuamente excluyente y exhaustiva para la contribución, y etiquetas superpuestas solo para exploración.
• Afirmar que un lanzamiento del mismo día es la causa raíz → la adopción, el dispositivo y la geografía pueden confundir la comparación → busca una señal independiente, grupos comparables o una reversión controlada.
• Esperar una causa raíz completa antes de actuar → la falla continua en una ruta crítica agrava el daño al usuario → establece un umbral de contención basado en impacto, confianza y reversibilidad.
• Dar por terminado cuando el DAU parece recuperarse → un backfill o una notificación única pueden crear una recuperación aparente → revisa en conjunto el paso roto, el resultado en el servidor, los comentarios de los usuarios y la duración.
• Detenerse en el análisis → el entrevistador no puede apreciar el criterio de producto → indica la conclusión actual, acción, responsable, criterios de recuperación y condiciones de reversión.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: El panel cayó un 15%, pero las acciones exitosas del lado del servidor están totalmente estables. ¿Qué haces?

Trátalo como un incidente de medición. Compara el evento faltante por versión, plataforma y tiempo; inspecciona el SDK, nombre de evento, filtros, fusión de identidades y latencia del pipeline; y congela experimentos o automatizaciones que consuman la métrica. Realiza el backfill de los datos recuperables tras la corrección y anota cualquier intervalo no recuperable. Recorridos de usuario estables y señales independientes del servidor no justifican una reversión de producto.

Pregunta de seguimiento 2: Todas las plataformas han disminuido gradualmente durante ocho semanas, sin un lanzamiento evidente. ¿Cómo cambia el enfoque?

Pasa de una ruptura de eventos a una descomposición por composición de usuarios: cuantifica las contribuciones del flujo de nuevos usuarios, activación, retención por cohorte de registro, frecuencia de actividad y reactivación. Revisa la concentración por geografía, tamaño de cliente y caso de uso. Luego conecta hipótesis de canal, estacionalidad, precio, competencia o valor del producto con entrevistas y experimentos controlados. Una pendiente de ocho semanas no justifica perseguir un despliegue de un solo día.

Pregunta de seguimiento 3: Las personas que adoptan 9.4.0 tienen mayor probabilidad de activar actualizaciones automáticas. ¿Cómo evitas una falsa atribución?

La propensión a la actualización automática puede correlacionarse con el dispositivo, la geografía y la actividad previa. Da preferencia a etapas de despliegue aleatorizadas o a un grupo de control asignado antes del lanzamiento. Sin aleatorización, compara dentro del mismo dispositivo, versión de SO, geografía y actividad histórica, e inspecciona tendencias previas a la actualización. Mantén la salvedad sobre las limitaciones observacionales. Un perjuicio claro al usuario aún puede justificar una reversión reversible, pero la decisión de riesgo no debe presentarse como causalidad comprobada.

Pregunta de seguimiento 4: El embudo de iOS se recupera tras la reversión, pero el DAU total solo se recupera a la mitad. ¿Qué sigue?

Recalcula la brecha restante con la misma tabla de contribución. La recuperación de iOS muestra que el incidente explicó parte de la caída; no establece una causa única. Revisa Web, Android, antigüedad de cuenta y canales en busca de un segundo cambio independiente, y verifica la cobertura de la reversión y la madurez de los datos. Cuando las causas se superponen, cada actualización debe separar la porción explicada de la no explicada.

Pregunta de seguimiento 5: El DAU se recuperó. ¿Por qué continuar monitoreando la retención de la siguiente semana?

Una reversión, un reenvío de notificaciones o un backfill de datos pueden restablecer el número de un solo día. Es posible que los usuarios afectados ya hayan abandonado la plataforma (churn), o que las aperturas se recuperen sin que se restablezca el valor central. Continúa monitoreando las acciones centrales, la retención de la semana siguiente, los contactos a soporte y las cancelaciones para la cohorte afectada con el fin de detectar secuelas. Estas son verificaciones de seguimiento; no modifican la decisión de contener la falla inmediata.