Categoría: Análisis de datos
Preguntas analíticas: cuando la respuesta queda fuera
Aunque no me entusiasman las películas de zombis, un día vi en el carrusel de Netflix Guerra Mundial Z y decidí darle la oportunidad. Lo que me encontré fue muy distinto a lo que esperaba … y no por los zombis.
El mundo colapsaba por una pandemia y los equipos científicos se concentraban en analizar a los infectados. La pregunta que trataban de contestar era: ¿Qué les pasaba a los infectados? Por eso, tener un ejemplar vivo era tan valioso. Aunque esa era la pregunta obvia, era también una pregunta incompleta. El grupo que tenía la respuesta era el de quienes fueron expuestos pero no se infectaron. Y, por supuesto, el protagonista fue quien se hizo la pregunta indicada y encontró la solución.
Las preguntas analíticas pueden excluir información
En el análisis de datos y la toma de decisiones de negocio, este patrón se repite frecuentemente y casi siempre es un error en la pregunta de origen, no de habilidades técnicas. Cuando algo falla, ya sea una campaña, un producto o un proceso, la pregunta que se plantea de forma automática es: «¿Qué pasa con los afectados?» Puede parecer la pregunta obvia, pero deja fuera a un grupo igual de importante: los que no han sido afectados. La otra pregunta sería: «¿Qué tienen en común los que no fueron afectados?»
Un análisis puede estar técnicamente bien hecho y aun así llegar a una conclusión incompleta, porque la pregunta inicial dejó fuera a un grupo entero.
Una pregunta deficiente puede introducir un sesgo de selección. Al preguntar solo «¿qué le pasa a los afectados?», el análisis se concentra en el grupo donde el problema es visible: los usuarios que abandonaron, las transacciones que fallaron, los clientes que se quejaron, porque ahí está lo que tenemos que arreglar. Y está bien, pero es solo una parte de la historia.
Sin embargo, el grupo que no tuvo el problema: los usuarios que sí completaron el proceso, los clientes que no se quejaron, el segmento que ni siquiera aparece en el reporte de incidencias, queda fuera del análisis. El sesgo de selección surge naturalmente de esa pregunta incompleta.
El mismo principio se repite en el análisis de producto, de manera más cotidiana. Cuando un producto pierde usuarios, es común entrevistar a fondo a quienes cancelaron: encuestas de salida, llamadas de «¿Por qué te vas?», análisis del último recorrido antes del abandono. Es información valiosa, pero solo una parte.
El grupo que no aparece en los reportes
El grupo que casi nunca se revisa con el mismo nivel de detalle es el de los usuarios que llevan meses o años usando el producto sin quejarse. No generan tickets, no llenan encuestas negativas, no aparecen como «caso urgente» en ningún dashboard. Por lo mismo, es fácil asumir que no tienen nada que enseñar. Sin embargo, ese grupo suele contener la respuesta a una pregunta distinta y más útil: ¿Qué es lo que realmente los retiene?
Antes de dar por buena una pregunta analítica, vale la pena hacerse una pregunta adicional: ¿qué grupo estoy descartando por suponer, sin comprobarlo, que no tiene nada que aportar? En análisis de producto, ese grupo suele ser el que no se queja, el que no destaca, el que parece «normal». Y precisamente por eso es el que menos se revisa.
El problema puede o no encontrarse en ese grupo. Lo importante es tener la historia completa.
La lección: buscar la historia completa
En la película, la solución consistió en incluir al grupo de personas que no presentaban el problema aun después de haber sido expuestas. Analizar a los infectados confirmó lo que ya se sospechaba. La solución vino de otro lado. Esa es, en el fondo, la diferencia entre un análisis que confirma y otro que encuentra algo nuevo.
Epílogo
Regresando a la película: sí me gustó y no solo por lo que enseña sobre preguntas de negocio. Las películas de zombis siguen sin ser mis favoritas, pero sí volvería a hacer clic en otra.
Nota curiosa
Abraham Wald y los aviones que no regresaron
Este mismo mecanismo tiene un caso real, documentado, mucho antes de que existiera Guerra Mundial Z. Durante la Segunda Guerra Mundial, el ejército de Estados Unidos analizaba los aviones que regresaban de combate para decidir dónde reforzar el blindaje: marcaban las zonas con más impactos de bala y reforzaban ahí. El estadístico Abraham Wald señaló el error de origen: esos impactos mostraban dónde un avión puede recibir un disparo y aun así volver. Las zonas que había que reforzar eran las que aparecían limpias en los aviones sobrevivientes, porque los aviones dañados justo ahí eran los que nunca lograron regresar. Este caso me parece fascinante y con un impacto de vida o muerte.
El grupo que faltaba en el análisis: los aviones derribados, no estaba disponible para estudiarse directamente, pero su ausencia era, en sí misma, la información más importante. La pregunta inicial («¿Dónde reciben más impactos los aviones?») sonaba razonable, pero estaba mal planteada desde el principio.
Antes del dashboard: la importancia de definir las métricas
Cuando los datos no son el verdadero problema
Muchas veces, cuando los resultados nos parecen incongruentes con nuestras expectativas, empezamos a revisar con detalle los métodos, los algoritmos y el manejo de los datos. Sin embargo, es frecuente que esas incongruencias tengan su origen en la capa de la comunicación humana.
Y, en muchos casos, no es una equivocación de nadie. Cada persona puede estar interpretando el problema desde una perspectiva diferente.
Una palabra, múltiples interpretaciones
Hace un tiempo, teníamos como objetivo mejorar la activación de los usuarios. Había datos, dashboards de resultados y muchas reuniones, pero los equipos no lograban llegar a acuerdos.
Se suponía que la activación era una variable importante y se asumía que, para todos, era muy claro en qué consistía.
Pero cuando surgió la pregunta de qué significaba que un usuario estuviera “activado”, cada persona respondió algo distinto.
Para algunas personas, la activación consistía en completar el flujo de compra: elegir un producto, agregarlo al carrito y realizar el pago.
Para otras, bastaba con realizar una primera acción, como registrarse o guardar un artículo en favoritos.
También había quienes consideraban suficiente mostrar la intención de compra, por ejemplo, al agregar productos al carrito.
Las interpretaciones se traslapaban: una misma acción era, para algunos, una señal intermedia y, para otros, evidencia suficiente de activación.
El problema no estaba en el dashboard
En ese momento surgió el verdadero problema. Y no estaba en ninguna métrica, ni en ningún resultado ni en ningún dashboard.
El problema estaba en que intentábamos medir algo que aún no habíamos definido de forma conjunta.
En este caso, se había establecido que un usuario se consideraba activado al completar su primera compra. Sin embargo, esa definición no era conocida ni utilizada de manera consistente por todos los equipos. Las acciones previas, como registrarse, guardar productos o agregar artículos al carrito, evidenciaban interés, pero no generaban conversiones.
Resolver el problema exigió algo más que elegir una métrica. Primero acordamos a qué comportamiento llamaríamos activación. Después verificamos si esa señal realmente se relacionaba con el resultado esperado. Finalmente, dejamos la definición documentada para todo el equipo.
Y lo mejor fue que las reuniones sobre el tema disminuyeron, se volvieron efectivas y el trabajo empezó a fluir.
Cuando un concepto clave significa algo distinto para cada persona, podemos realizar análisis correctos y aun así llegar a decisiones incompatibles. Los datos no eliminan las diferencias de interpretación. Si la definición inicial es ambigua, el análisis puede reforzar esa ambigüedad en lugar de resolverla.
Tres preguntas antes de medir
Antes de pedir más datos o solicitar un nuevo dashboard, se recomienda acordar tres aspectos fundamentales:
- ¿Qué comportamiento queremos medir y en qué consiste?
- ¿Por qué ese comportamiento importa?
- ¿Qué decisión cambiaría con esa información?
Estas preguntas nos ayudan a convertir una idea general en una definición útil, observable y compartida.
Conclusión
Un dashboard no corrige una definición ambigua. Solamente la hace ver más profesional.
Antes de analizar, visualizar o automatizar una métrica, es necesario asegurarse de que todas las personas involucradas entiendan lo mismo por ella.