#018 ITSA: Cómo medir el impacto de features en tu producto digital

¿Cómo medir el impacto de una nueva funcionalidad tras un test AB? en esta edición presentamos ITSA: una solución para medir el impacto de nuestras funcionalidades en producto digital.

Eureka.

Tienes una variante ganadora o, mejor, una funcionalidad nueva que quieres lanzar a producción y que tienes medio validada. Se definen las épicas y las tareas de cada equipo. Todo va sobre ruedas y llega el día D. Lanzas a producción esta nueva feature que tanto interés ha generado en tu compañía y llega la gran pregunta:

“¿Qué impacto ha generado esta funcionalidad?” pregunta tu jefe. Le entregas un reporte que mide ese manido “antes y después” día a día, semana a semana. Las métricas no te acompañan, tu jefe te mira raro y la reunión se torna tensa. “Es lógico: el impacto no es una cosa de un día para otro” te dices a ti mismo, pero no conoces otro método para reflejar el impacto de tus ideas porque nadie te ha enseñado. Hasta ahora.

Ahora sí, empieza ITSA: Cómo medir el impacto de las features en tu producto digital.

---

Una nueva feature

Empecemos con un caso hipotético para amenizar la lectura: El equipo de producto de Idealista.com decide lanzar una nueva feature que permite al usuario subir una foto (por ejemplo, de Pinterest, Instagram o una hecha por él mismo) de una casa o una habitación que le gusta, y una IA le encontrará inmuebles que tengan un estilo visual similar. Es decir, un recomendador basado en una imagen subida por el usuario.

Dejando a un lado cuestiones organizativas, políticas y de alineamiento con otros stakeholders como diseño, desarrollo, analítica y negocio, la iniciativa consigue salir adelante mediante un MVP que pasará un filtro mediante un test AB con el que se desea evaluar si una funcionalidad de este tipo incide de manera positiva (o no negativa) a métricas como las siguientes:

1. Métricas primarias:

   1. Tasa de conversión de búsqueda a lead: Al facilitar la búsqueda mediante imágenes, se aumenta la probabilidad de que contacte con el anunciante.

   2. CTR y select_item: Los inmuebles a través de este método generan mayor interés, aumentando clics en los anuncios y viviendas, tanto de alquiler como en venta.

2. Métricas secundarias:

   1. Tiempo medio en la plataforma.

   2. Tasa de búsquedas sin resultados: para evaluar qué búsquedas no tienen resultados y si esta funcionalidad incide en esta métrica de manera estadísticacmente significativa.

3. Métricas terciarias:

   1. Lead Quality Score: asumiendo que hay un scoring de la calidad del lead, trakearla si es posible.

   2. Uso de búsquea mediante filtros y navegación: Tasa de adopción y retención de la búsqueda tradicional tras incorporar la búsqueda visual.

   3. Diversidad y distribución de viviendas mostradas.

El test AB ha resultado ser un éxito a favor de nuestra feature. Todas las métricas han sido positivas o no han generado impacto negativo. Así, se decide hacer una solución un poco más sólida para lanzar a producción al 100 % de los usuarios.

¿Nuestro trabajo ha acabado? En absoluto. Es nuestra labor seguir midiendo si esta funcionalidad realmente incide positivamente en nuestras métricas objetivo y redunda en un valor general para el negocio. No podemos olvidar que en experimentación existen los falsos positivos y tenemos la responsabilidad de tener un cierto nivel de “ownership” de nuestras decisiones.

Sin embargo, el product manager que pueda leer esto sabrá que existen elementos externos que pueden incidir en el comportamiento de métricas más allá de nuestra nueva funcionalidad: cambio en campañas, promociones particulares, stock de producto, estacionalidad, entre otros. ¿Cómo diferenciar el grano de la paja, es decir, cómo separar con rigor estadístico y metodológico el efecto directo atribuible a nuestra nueva funcionalidad, del ruido causado por estos elementos externos?

En próximas ediciones de Leanalytics hablaremos de análisis causal que, sin duda, sería el enfoque correcto ante este reto. No obstante, antes de sumergirnos en esas complejas aguas quiero enseñarte ITSA (Interrupted Time Series Analysis), un método con el que podemos analizar el comportamiento de una métrica antes y después del cambio (la intervención) en un producto digital y evaluar si ha habido un efecto estadísticamente significativo en una métrica objetivo.

Porque esto es lo que realmente buscamos: no solamente ganar con un test AB, sino también asegurarnos de que cuando lanzamos nuestra variante (en este caso la nueva funcionalidad) existe un impacto positivo en el negocio o que realmente no tenemos generando efectos negativos, adversos y desconocidos. Como dijo una vez Donald Rumsfeld: son los unknown unknowns los que nos matan.

ITSA: Interrupted Time Series Analysis

Este método consiste en estudiar los efectos de una intervención antes y después de que esta haya ocurrido para evaluar si ha afectado a una métrica objetivo. Un ejemplo de “intervención” bien puede ser el lanzamiento de una funcionalidad nueva en una web como Idealista.

El planteamiento técnico de ITSA es que no consiste en evaluar únicamente el valor de la métrica día a día o semana a semana y ver el uplift. Consiste (también) en evaluar su tendencia y si la evolución es estadísticamente significativa con respecto al periodo previo al día D desde una perspectiva de análisis de serie temporal.

Breve introducción a la visualización de series temporales

Vamos a ir despacio. En primer lugar quiero que mires esta gráfica que muestra la evolución de leads generados en idealista.com. La línea vertical de color morado con las líneas (-) representa el día de la intervención, es decir, el día que lanzamos la funcionalidad al 100 % de los usuarios.

¿Hemos mejorado la consecución de leads? si usamos “el ojímetro” advertiremos que, como mínimo, no es la típica subida que se ven en los grandes casos de éxito. Las series temporales también son así: difíciles verdaderamente de interpretar ante cambios sutiles. Una alternativa común aquí es ver el Uplif Week Over Week pero lamento decirte que es un método cuanto menos cuestionable, manipulable y ciertamente ineficaz.

Mira la siguiente gráfica. Son los mismos datos, pero añadimos dos medidas nuevas: la media movil, que es la media de los últimos 7 días de datos y que sirve para eliminar el "ruido" para ver tendencias reales y la predicción que es la tendencia estimada de leads sin fluctuaciones diarias y que permite ver el impacto de la intervención.

¿Cómo ha cambiado el diagnóstico a simple vista, verdad? Ahora se denota una tendencia ascendente después de lanzar la intervención. Este es el punto de las series temporales: el sub-método de visualización cobra una importancia absolutamente atroz en materia de diagnóstico de patrones.

Evaluación de nuestra feature con ITSA paso a paso

A continuación, te propongo un procedimiento paso a paso que puedes seguir de manera lineal para realizar este tipo de evaluaciones. Sigamos con el ejemplo de la funcionalidad de Idealista: debemos evaluar el impacto que genera en las métricas primarias y elegiremos el número de leads para ejemplificar este proceso.

1. EDA: Exploratory Data Analysis y comprensión de los datos

Una buena práctica es tratar de elaborar una buena visualización de serie temporal para poder entender cómo esta métrica se comporta antes y después. En la siguiente gráfica ves cómo cada semana se convierte en un diagrama de caja, lo que permite entender la distribución de cada semana (máximo, mínimo, mediana…).

En la siguiente imagen tenemos información bastante útil, la cual desgloso a continuación. Además de la media móvil, la línea de intervención o la de tendencia, podemos ver que también tenemos:

• Media pre: 50.06. Esta sería la media de leads relativos al periodo previo a la intervención. Se podría capturar la media (u otra medida) de otros periodos como meses anteriores o el mismo periodo en años anteriores.

• Media post: 57.65. La misma medida pero en el periodo post.

Este tipo de visualizaciones bien pueden permitirnos entender la naturaleza de las gráficas. Si miras detenidamente la gráfica anterior, verás que hay una caída leve en la recta de tendencia nada más inicia el periodo post-intervención. Es un auténtico clásico que ante cambios más o menos importantes en productos digitales haya no solamente bugs, sino también despliegues graduales, por lo tanto, no es raro ver en análisis de este tipo márgenes de hasta una semana entre pre y post intervención.

Esto pone encima de la mesa la idea de que el análisis diario o semana a semana que se llega a exigir a equipos de analítica y ciencia de datos, en ocasiones, puede no tener sentido por más paz mental genere a responsables de negocio, ya que en ocasiones la ventana de tiempo en la que veremos impacto va más allá de la fecha de la siguiente weekly.

Stationatity, Autocorrelation & Decompose

Para poder ejecutar este tipo de análisis debemos también entender en qué grado tenemos estacionariedad (no confundir con estacionalidad), autocorrelación y deberíamos descomponer la serie temporal para entender la naturaleza de la misma. Antes una serie de definiciones:

• Stationarity: Hay estacionariedad cuando las propiedades estadísticas de una serie (media, varianza, autocorrelación) se mantienen constantes a lo largo del tiempo. No es una propiedad obligatoria para ITSA, pero nos interesa entender si existe o no.

• Autocorrelación: Mide la correlación de una serie temporal consigo misma en diferentes intervalos de tiempo. Es una medida preciosa que muestra que entre una observación y sus valores anteriores puede haber similitud, lo que revelaría cierta dependencia temporal.

• Descomposición de la Serie: Es una técnica que descompone una serie temporal en sus componentes fundamentales: tendencia, estacionalidad y residuos.

Para evaluar la “Stationarity” (o, en castellano, estacionariedad) podemos aplicar la prueba ADF, que permite evaluar si sufrimos de estacionariedad o no. En este caso

Como la p-valor es muy inferior a 0.05, podemos asumir que SÍ existe de manera estadísticamente significativa estacionariedad. Esto no es un impedimento para hacer ITSA, pero sí que deberemos tener en cuenta que al ser la serie estacionaria, cualquier cambio observado en parámetros estadísticos (como la media) tras la intervención puede reflejar un efecto atribuible a dicha intervención, y no simplemente a tendencias subyacentes o efectos estacionales. Esto nos interesa.

La autocorrelación es un fenómeno que puede estudiarse visualmente con la figura anterior. No se observan patrones claros de autocorrelación, ya que casi todos los valores están dentro de los intervalos de confianza (zona azul). Otra forma de evaluarlo es mediante estos dos métodos que se muestran en la siguiente figura y que diagnostican que NO hay autocorrelación (p-valor superior a 0.05).

En la siguiente figura vemos una serie temporal con una clara estacionalidad semanal. Por otro lado, los residuos presentan una amplitud a evaluar. Un buen método para evaluar si tenemos heterocedasticidad es mediante Breusche-Pagan como se muestra a continuación en los siguientes cálculos:

¡Lo que creía! tenemos heterocedasticidad como vemos en la figura siguiente, es decir, nuestros residuos tienen una distribución diferente a lo largo de la serie temporal lo que podría inducir que el modelo que estamos empezando a dibujar tiene disfuncionalidades de diversos tipos. Sin embargo, debemos recordar que esto no tiene por qué ser algo malo.

El código (que en breve subiré a mi GitHub) ejecuta el análisis de heterocedasticidad a lo largo de toda la serie temporal, independientemente de que se haya ejecutado o no la intervención y resultaría razonable pensar que hubiera que hacer dos análisis distintos en función de si hubiera intervención o no, ya que de alguna manera justamente estamos buscando un efecto en esta serie temporal.

En la siguiente figura vemos que cuando las tomamos por separado tenemos homocedasticidad, es decir, los residuos no siguen ningún patrón particular, lo cual es muy bueno (y casi necesario) para hacer un análisis ITSA.

Ahora que entendemos la naturaleza de nuestra serie temporal podemos el análisis ITSA para comprender si ha habido un impacto estadísticamente significativo después de nuestra intervención en la métrica seleccionada: leads.

2. Ejecución de ITSA

Al ejecutar el modelo ITSA podemos utilizar distintas aproximaciones. En mi libro “Experimentación Online” explico este método desde una perspectiva OLS pero en este contexto es más beneficioso utilizar GLM. Para datos de conteo (número de leads) como estos, GLM es más adecuado que OLS, también por lo que hemos visto en el anterior paso acerca de la distribución de los residuos.

Volvamos al caso. La nueva funcionalidad se lanza el 01 de julio y queremos evaluar no solamente si hay una evolución o no en la métrica objetivo, sino también si la diferencia que vemos es estadísticamente significativa. Es decir, que la diferencia entre “el antes y el después” de la serie temporal es significativa.

Con estos datos podemos ver que el coef “tiempo_desde_intervencion" (0.0030)” es altamente significativo (p-valor=0.000). Esto indica un cambio positivo en la tendencia después de la intervención, aproximadamente 0.30% diario de incremento compuesto. Es decir, la tendencia inicia con 0.30% de aumento el día 1, y tendrá aproximadamente 0.60% el día 2, 0.90% el día 3, y 1.20% el día 4.

Un dato muy interesante que ya mencionamos antes es que, inmediatamente después de la intervención no hubo un impacto positivo, lo cual es normal y debería ponernos en preaviso a todos los que nos dedicamos a reportar a negocio sobre la naturaleza del negocio digital. “Indicador_intervencion (0.0475)” no alcanza significancia estadística (p-valor=0.243), por lo que no hubo un cambio inmediato significativo al implementar la funcionalidad, sino que se vio con el paso del tiempo.

El coeficiente de “tiempo (-0.0001)” tampoco es significativo (p-valor=0.699), lo que indica que no había una tendencia clara antes de la intervención. “Intercept (3.9216)” es significativo (p-valor=0.000) y representa el nivel base de leads (aproximadamente 50.48 leads diarios).

Estos resultados indican que la funcionalidad de búsqueda por imagen no generó un impacto inmediato, sino que produjo un cambio gradual y progresivo en la tendencia, coherente con un patrón típico de adopción de nuevas funcionalidades donde los usuarios necesitan tiempo para descubrirlas e integrarlas en su comportamiento habitual.

En la figura anterior podemos ver la ganancia acumulada mediante un counterfactual que nos permite evaluar qué hubiera pasado con las métricas si no hubiéramos hecho nada (este es uno de los pilares del análisis causal como en siguientes ediciones hablaremos). Conclusión: nuestra feature genera un impacto positivo en la métrica objetivo de manera estadísticamente significativa.

¿Cómo reportar ITSA a perfil de negocio?

“Sí, todo esto es muy bonito pero cómo lo reporto a perfiles de negocio?” Si te has hecho esta pregunta, esta sección es para ti. Yo también vivo en el mundo real y empresarial. Yo también trabajo a menudo con personas que este tema les parece muy técnico. Incluso, tengo compañeros que esto les suena a marciano.

Reporting convencional

Si hubiéramos hecho un reporting 7 días después (lo cual es una práctica convencional) habríamos tenido un resultado muy diferente a lo que hemos visto (que, recordemos, es estadísticamente significativo). Mira los siguientes resultados:

• Al cabo de 7 días, esa evolución de +9,44% hubiera generado felicidad y jolgorio.

• Al cabo de 14 días, ese +1,82% baja los humos y hace que salten las alarmas.

• Al cabo de 21 días, solamente es un +6,24%. Aunque mejor, la semana pasada tuviste miedo y si no gestionaste bien esa reunión se podría poner en duda la validez estratégica de esta feature. Incluso de tu medición.

El problema es no entender cuál es el parámetro (que no métrica) en toda esta conversación: No es la evolución period over period de una métrica porque, como ves, es absolutamente volátil. Estos son los resultados utilizando el mismo dataset. En lo que debes fijarte es en la p-valor. En ningún caso ha habido una diferencia estadísticamente significativa. Ni debías alegrarte al cabo de 7 días ni apesadumbrarte al cabo de 14. Los datos porcentuales eran diferentes pero realmente el diagnóstico y tu manera de gestionar la reunión debía ser lo mismo.

Reporting propuesto

A continuación, se esboza un proceso para reportar esto. Hay que mencionar que gran parte del éxito de cualquier iniciativa del dato reside en el data-storytelling por una razón: encontrar la verdad con datos requiere técnica, pero también requiere que la hagas llegar al que tienes en frente.

Una buena manera (quién ha trabajado conmigo lo sabe) de trabajar este tipo de conversaciones es preparar mucho antes (cuando hubo esas discusiones sobre aspectos de diseño y specs en la feature al inicio de todo) sobre cómo medir y el umbral temporal del impacto.

En la siguiente figura ves que el día en el que hubo un impacto estadísticamente significativo de manera positiva fue a partir del día 29. Es decir, necesitas más de 4 semanas (en este caso, pero en otros puede ser más) para tener una tendencia sólida y continua. Además, la media post-intervención se mantendrá en 9,59% y subirá hasta los +16% que hemos llegado a ver previamente.

¿Qué significa esto? Independientemente de que al cabo de una semana o dos haya un impacto X en una métrica, debemos entender qué estamos viendo y estamos manejando. Si hay un cambio estadísticamente significativo o no es en lo que deberemos fijarnos porque el aumento porcentual de una métrica es voluble y su interpretación muchas veecs en marketing digital, infantil.

¿Los perfiles de negocio saben de p-valor? Lo normal es que no, pero no es necesario entenderlo para saber interpretarlo o que tú comuniques esto de manera eficaz. Lo que bien puedes hacer es:

1. Al cabo de 7 días comunicar que hay una evolución poositiva, pero poner en preaviso de que aunque es sublime, no es estadísticamente significativo todavía. Eso te preparará para siguientes comportamientos.

2. Al cabo de 14 días, como avisaste (también por escrito) que esto podía pasar, simplemente apuntas a lo que dijiste 7 días antes. Aquí debes mostrar serenidad y experiencia. Obviamente habrá preocupación, miedos y te pedirán que mires guardrail metrics y demás. No es desaconsejable hacerlo y mitigará incertidumbres y miedos.

3. Al cabo de 21 días los resultados son mejores, pero debes continuar con el mismo discurso.

4. Es a partir del día 29 que puedes gritar “eureka”. Aunque hay que vigilar y ser prudentes, ya que bien podría tratarse de un caso de p-hacking.

Ventajas de esta aproximación

Lo que propongo a lo largo de este artículo es lo siguiente:

1. Adopta un enfoque más maduro de la analítica de features en producto. Hemos visto que tienen un componente de serie temporal importante y que este tipo de análisis tiene sus propias normas.

2. El uplift week over week es una falacia que deberíamos exterminar por las razones que he dado. Los negocios digitales son mucho más complejos hoy en día y el caso del reporting lo ejemplifica. ¿Cuántos dolores de cabeza para ti y para tus stakeholders por no entender estos conceptos?

3. Aunque más técnica, debes comprender que el concepto de “significancia” (tanto estadística como práctica) te permite poner los pies en el suelo tanto a perfiles de negocio como técnicos y hacer un análisis mucho más maduro y asentado a la realidad de los negocios.

Conclusión

Las preguntas de nuestros stakeholders han cambiado. Así, nuestros métodos parra llegar a las respuestas tienen que cambiar. La analítica en el entorno digital debe ser más técnica por una cuestión de pura supervivencia y eso implica no solamente contar con dotes técnicas sino también de comunicación.

Detente. Mantén la calma. Ya has visto ccon este ejemplo que el uplift WoW es absolutamente ridículo. Acéptalo y enfréntate con las armas que dispones a los escenarios sociales que las empresas nos ponen delante. Eres tú el responsable de poner el foco donde toca.