Soy Juanma Barea, responsable de Marcas B2B y Corporativas y creador la Newsletter Brandketing y hoy tomo el control de su newsletter para pediros ayuda.

Los equipos de Branding os necesitamos. Queremos datos, pero siendo honestos, nos perdemos. Por eso os comparto 10 puntos para que los tengáis en consideración y entre todos usemos el dato para crear un relato.

Ahora sí, empieza la 23ª edición de Leanalytics: Branding Loves Data.

Branding y data han vivido demasiado tiempo en departamentos distintos, con agendas distintas y conversaciones que pocas veces se cruzan.

Branding habla de percepción, de emociones, de storytelling.

Data habla de métricas, de dashboards, de modelos predictivos.

Pero si queremos construir marcas fuertes, tenemos que reconocer algo: no se puede hacer branding a ciegas.

Necesitamos datos para tomar decisiones más inteligentes, para demostrar impacto y para convencer al negocio de que invertir en marca no es un lujo, es una necesidad.

Si trabajas en data, aquí tienes 10 puntos que los equipos de branding necesitamos de ti, desarrolladas y explicadas para que sepas exactamente cómo ayudarnos.

1. Insights, no solo números

Los datos sin interpretación se quedan en el Excel.

Queremos saber qué hacer después:

• Si baja el awareness, ¿qué segmentos están impulsando esa caída?

• Si el engagement sube, ¿qué mensajes lo provocaron?

Un buen insight es el que convierte un gráfico en una decisión.

2. Segmentación más humana

Edad, género y país son el punto de partida, no el destino.

Necesitamos entender:

• Qué mueve a nuestra audiencia.

• Qué les preocupa, qué esperan de nuestra marca.

• Cuándo están más receptivos y en qué canales.

Esa información es la base para crear campañas relevantes y experiencias de marca personalizadas.

3. Métricas de percepción (aunque sean difíciles)

Medir el impacto del branding es complicado, pero imprescindible. Y este es el reto que os pongo sobre la mesa.

Necesitamos ayuda para rastrear y cuantificar indicadores como:

• Awareness, consideración y preferencia.

• Brand love y reputación.

• Sentimiento en redes, NPS y share of voice.

Son métricas que demuestran si la marca está ganando espacio en la mente de las personas, antes de que eso se refleje en ventas.

Conocer este punto es fundamental para cualquier equipo de Branding, ya que no necesitamos un dato genérico, sino hechos fehacientes y comprobaciones reales.

4. Conexión con métricas de negocio

Una de nuestras mayores batallas es demostrar el ROI del branding.

Necesitamos que nos ayudes a conectar métricas “blandas” (equity, notoriedad) con indicadores de negocio:

• Revenue.

• Customer Lifetime Value.

• Retención y recurrencia.

Cuando logramos esa conexión, convencer a dirección de invertir en marca deja de ser una pelea y se convierte en una estrategia de crecimiento.

Queremos demostrar la rentabilidad del Branding en el negocio.

5. Velocidad y claridad

Los datos que llegan tarde ya no sirven.

Necesitamos que la información fluya casi en tiempo real y que llegue en un formato digerible:

• Dashboards claros, con pocas métricas pero significativas.

• Visualizaciones que permitan identificar patrones de un vistazo.

• Actualizaciones frecuentes para reaccionar rápido.

Un buen dashboard puede ser el mejor aliado de una campaña viva.

6. Tendencias y patrones, no solo resultados

No queremos quedarnos en el pasado.

Los datos históricos son útiles, pero lo que nos permite ganar ventaja son los patrones:

• Cambios de comportamiento en la audiencia- actual

• Canales que empiezan a traccionar- hoy

• Mensajes que están resonando mejor- hoy

Si detectamos esas tendencias pronto, podemos ajustar nuestra estrategia antes que la competencia.

7. Comparativas y benchmarks

Necesitamos contexto para saber si vamos bien:

• ¿Estamos creciendo más rápido o más lento que el mercado?

• ¿Cómo se comportan otras marcas en awareness o share of voice?

• ¿Qué están haciendo los líderes de nuestra categoría?

El benchmarking convierte métricas aisladas en puntos de referencia estratégicos.

8. Alertas tempranas

Muchas crisis de marca podrían evitarse si los datos hablaran antes.

Queremos sistemas de alerta que detecten:

• Caídas en NPS o satisfacción.

• Aumento de menciones negativas.

• Descenso brusco de interacción o engagement.

Cuanto antes podamos actuar, menos costoso será reparar el daño y más ágil la respuesta.

9. Colaboración desde el inicio

Queremos que data sea parte del proceso creativo, no solo del análisis post-mortem.

Si nos acompañas desde el briefing:

• Definimos objetivos medibles.

• Creamos hipótesis que luego se puedan validar.

• Optimizamos sobre la marcha, no al final.

Así, el análisis no es un informe de lo que pasó, sino una palanca para mejorar resultados en tiempo real.

10. Traducción para humanos

No todos en branding (ni en dirección) hablan el idioma de las métricas.

Necesitamos que los datos se expliquen de forma sencilla, que cuenten una historia.

Un buen analista no solo muestra un gráfico: lo convierte en narrativa, en un argumento que inspira decisiones.

Por qué esto importa

Porque branding sin data es intuición, y en un mundo saturado de información, eso es un lujo que no podemos permitirnos.

Los datos nos permiten priorizar, enfocar recursos y demostrar que el trabajo de marca genera valor tangible.

Y a cambio, el branding ayuda a que los datos cobren sentido: convierte cifras en historias, métricas en dirección y resultados en reputación.

Por eso, branding loves data.

Brandketing

Si te apetece estar al día en Branding, te comparto un par de artículos y te animo a unirte a Brandketing:

• Branding B2B: Su importancia y por qué es diferente. Click

• ¿Cómo se mide el Branding?: Post 0 y origen de la conexión con Ubaldo. Click

• No eres Apple. Y no pasa nada. Click

Esta vez continuamos con la serie que iniciamos en agosto sobre análisis causal. En la edición 020 introduje el concepto de análisis causal, un fenómeno dentro del campo del análisis de datos que introduce una serie de heurísticas que se pueden aplicar en bioestadística, medicina y, sí, también en el mundo del negocio digital. Te recomiendo empezar por esa edición de introducción si esto del análisis causal no te suena.

Si por el contrario ya estás algo familiarizado con este mundillo, en la presente edición mostraré un caso paso a paso para aplicar los principios del análisis causal a un problema de negocio offline de una industria fundamental en España: la turística.

Así empieza la 22ª edición de Leanalytics.

Causalidad en la práctica: DiD con Control Sintético (SCM)

Contexto

Imagina que trabajas como un científico de datos en una empresa hotelera ubicada en España. Un proveedor de la empresa sugiere a los directivos cambiar el contenido de la nevera de las habitaciones de los hoteles, ya que, según él, aumentará el margen. Él apunta a que, como contiene productos de mayor reconocimiento y calidad, los usuarios los identificarán al abrir la neverita y los consumirán, beneficiando a ambas partes.

Antes de confiar al 100% en la opinión del proveedor, se plantea ejecutar un experimento: probar en una serie de hoteles esta práctica a partir de un día determinado y ver la evolución de la métrica objetivo (margen) comparando el periodo previo y posterior al cambio.

Hasta aquí no hay nada que no sepas: muy a menudo en marketing digital tenemos retos de este tipo y en la edición 018 enseñé cómo medir el impacto de features en tu producto digital con ITSA, pero en este caso se trata de un cambio en un entorno offline (y sí, las reglas cambian).

Debemos tener en cuenta las siguientes consideraciones:

1. Por temas logísticos, solo podemos aplicar estos cambios en la Comunidad de Madrid, donde hay 12 de los 100 hoteles que tenemos en toda la península ibérica. No se pueden aplicar de manera aleatoria en unos hoteles de una comunidad u otra o en habitaciones concretas. En absoluto se puede ejecutar este cambio a huéspedes de forma aleatoria por mera logística y riesgo en la experiencia.

2. Un planteamiento razonable sería ejecutar un test AB dentro de los 12 hoteles de Madrid (6 con cambio vs. 6 sin cambio) para estimar si existe impacto. Sin embargo, para cuando te ha llegado la petición de análisis, desde dirección se ha decidido que el total de hoteles de Madrid tendrán este cambio y ya no hay marcha atrás.

Este último punto dificulta el análisis y es lo que provoca que debamos encontrar alternativas al Test AB. Pensando en alternativas a esta técnica es cuando nace el análisis causal y es lo que vamos a ver ahora: usaremos Diferencia en diferencias (DiD).

Análisis, unidad de tratamiento y medidas

¿En qué consiste DiD?

Diferencia en diferencias es un buen método para este tipo de situaciones. Consiste en comparar, entre un grupo tratado (los 12 hoteles de Madrid) y un grupo de control, el cambio de una métrica a partir de una intervención específica (modificar la nevera del hotel).

¿Y esto no es como un test AB? Se parece, pero no es igual. Un test AB aleatoriza unidades (veremos lo que es a continuación) y, por diseño, es el gold standard de la causalidad porque resuelve el problema fundamental de la inferencia causal: nunca vemos el contrafactual Y(0) del grupo tratado. Es decir, nunca veremos qué hubiera pasado si en Madrid no hubiéramos hecho cambios.

La aleatorización en el test AB garantiza exchangeability, es decir, que las unidades son intercambiables entre grupos, así que la diferencia entre control y variante es fruto del cambio. Esto no sucede en inferencia causal (en DiD) ya que aquí no hay aleatorización por mandato de dirección y dificultades logísticas.

Por eso usaremos DiD: construiremos el contrafactual de Madrid con la evolución del grupo control y del periodo pre, buscando tendencias paralelas. Así podremos evaluar si la sugerencia del proveedor genera impacto o no. Esto lo veremos al final de esta edición.

¿Y por qué no comparar una comunidad autónoma con otra y ya? Lo típico de comparar mercados de cuantía similar. Porque hay más variables que intervienen en el consumo de la nevera: la ocupación del hotel, los ingresos medios por habitación, entre otros.

Unidad de tratamiento

En la edición 020 se introduce brevemente algunos términos de análisis causal, pero hay bastante más lenguaje que vale la pena introducir en este caso. ¿Cuál sería el objeto de nuestro análisis? ¿el hotel? ¿la habitación? ¿el usuario? Es decir, ¿cuál es la unidad de nuestro estudio? Una unidad es el objeto del estudio que vamos a efectuar.

En nuestro caso, la unidad es el hotel. Necesitaremos un ID único de cada hotel y disponer de las métricas objetivo antes y después del tratamiento o intervención que vamos a ejecutar. En este caso, por temas logísticos suele ser complicado aleatorizar por habitaciones dentro de un hotel (por posibilidad de error, por ejemplo) y casi inviable aleatorizar el cambio por huésped. Experimentar en entornos offline es más complicado que en entornos online.

DAGs

¿La ocupación del hotel no puede ser un factor exógeno que afecta al margen que genera la nevera? Si has hecho esta pregunta: ¡Enhorabuena! Estás empezando a entender la naturaleza del análisis causal.

En la edición 020 te enseñé los DAGs. Estos nos sirven para construir una relación causal y entender visualmente las variables que influyen en el outcome. Antes de nada, utilizaremos dos métricas: el margen (€ por hotel y día) y el margen por habitación ocupada.

¿Qué tenemos en esta imagen?

• U (unobserved): existen muchísimos elementos que no podemos (o es muy difícil) modelizar, como, por ejemplo, que Taylor Swift haga un concierto en Madrid después de que ejecutemos la intervención o aspectos como ferias, meteorología, entre otros. Estos elementos no están en nuestro dataset, pero podemos ponerlos encima de la mesa y hay multitud de artículos al respecto de cómo integrar lo desconocido en nuestros modelos (y se están haciendo hartos ejercicios práctico-teóricos al respecto). Si te interesa todo esto de lo “Unobserved”, puedes empezar por aquí con “Instrumental Variables Analysis”. En futuras ediciones sobre análisis causal ahondaremos en este fascinante tema.

• D (Treatment): la modificación en el minibar.

• X (Occupancy y ADR): asumimos que la ocupación de los hoteles es algo que afecta causalmente al outcome, así como la tarifa media diaria (ADR - Average daily rate), es decir, los ingresos de habitaciones / habitaciones ocupadas en un día y hotel. Cuánta más ocupación haya en un hotel (independientemente del tratamiento), más movimientos puede haber en la nevera.

• Y (Outcome): El output, es decir, la métrica objetivo. El margen.

• Mechanism (share_new): Se trata de un mediator entre treatment y outcome. Es el porcentaje de ventas del minibar que proviene de los SKUs del nuevo proveedor en un hotel y día. Se supone que el cambio en la nevera (D) aumenta share_new. Como esos SKUs tienen mayor margen por unidad, un share_new más alto eleva el margen total (Y).

Recuerda que las flechas establecen que una variable genera una relación causal hacia aquello a lo que apunta. En este caso Treatment afecta directamente al outcome pero también lo hace a través de un Mediator ubicado en medio. Un DAG, más allá de ser un dibujo con flechitas, nos permite entender de manera visual a qué nos estamos enfrentando.

El Reto: un tratamiento en Madrid

DiD y preparación de los datos

El tratamiento solamente sucede en Madrid. Esto introduce un potencial sesgo por todo lo anteriormente dicho. ¿Cómo podemos abordar esto? Básicamente, vamos a construir un control que tenga un comportamiento estadísticamente similar a Madrid previo al cambio (en cuanto a nivel y tendencia).

Para empezar, puedes descargar este CSV para que puedas ver algunas métricas que hemos considerado relevantes. Estas métricas a menudo vienen de la propia hipótesis y del conocimiento del sector. Añadir más variables no hará, necesariamente, que tus diagnósticos y modelos sean mejores.

Una vez tenemos los datos limpios y en el formato correcto, empezamos con el cacharreo serio.

Matching & Synthetic Control Method (SCM)

En lugar de elegir una o dos ciudades que “creemos” son similares a Madrid (lo típico que se hace en muchos departamentos de marketing), vamos a usar una técnica mejor: Synthetic Control Method (SCM).

¿Y si pudiéramos construir una versión sintética de Madrid a partir de una combinación ponderada de nuestros otros 88 hoteles? El método busca de forma algorítmica la "receta" perfecta, asignando un peso específico a varios hoteles de nuestro pool de control (los 88) para que, en conjunto, su comportamiento (su margen, su tendencia, su estacionalidad) antes de la intervención sea un clon lo más parecido posible del comportamiento de Madrid en ese mismo periodo. Este "gemelo estadístico" es nuestro Control Sintético, y será el contrafactual ideal contra el que compararemos el Madrid real tras el cambio.

Partimos de dos universos:

• Los hoteles con tratamiento (Madrid)

• Un pool elegible de hoteles fuera de Madrid.

Acotamos el análisis a la ventana de tiempo pre-intervención y, sobre esa ventana, resumimos la dinámica del outcome por hotel en un conjunto de métricas, en este caso:

1. Nivel medio del margen

2. Tendencia (pendiente temporal)

3. Patrón semanal que capture diferencias laborables–fin de semana.

4. ADR

5. Ocupación

El output que obtenemos es el siguiente:

¿Qué significa esto? En esencia, cada fila es un hotel y su peso en el “Madrid sintético”. Pesos como los que se ven en la tabla, que son en torno al 1.5–1.8%, indican un grupo de control muy diversificado, lo que hace que, por ejemplo, no dependamos de un solo hotel como puede pasar. Si podemos contar con varios hoteles de manera diversa, nuestro grupo de control sintético será más fidedigno y similar al periodo pre-intervención de Madrid.

Así obtenemos un grupo de hoteles ponderado que es lo más parecido posible al grupo de Madrid pre-intervención. Con estos pesos cerrados, trazamos su trayectoria esperada sin intervención y comparamos Observado vs Control sintético en el periodo post-intervención para estimar el efecto causal vía DiD.

Pero… un momento: ¿Por qué necesitamos construir un contrafactual? ¿qué es exactamente un contrafactual? Como recordarás, el problema fundamental de la inferencia causal es que no podemos ver qué hubiera pasado si en Madrid no aplicamos el tratamiento: solamente podemos ver los datos de Madrid con tratamiento [Y(1)], más conocidos como factuales, pero jamás podremos ver qué hubiera pasado sin tratamiento [Y(0)], más conocido como contrafactual.

Y es que aquí viene lo mágico del análisis causal: nos permite matemáticamente imaginar mundos que jamás han existido. Sí, has leído bien: imaginar para establecer qué clase de relación existe entre los elementos. Es el máximo nivel dentro de la escalera de la causalidad de Judea Pearl que se mostró en la edición 020 y que te vuelvo a mostrar en la figura anterior.

Por que la pregunta no es qué impacto ha generado el cambio. Eso no lo podemos responder. La pregunta es “¿Qué hubiera pasado con el margen si no hubiéramos hecho ningún cambio?” La manera de formular la pregunta es lo que nos permite entender por qué necesitamos un contrafactual.

Pero, claramente, este contrafactual no lo inventamos de la nada. Al disponer de datos de otros 88 hoteles, podemos usar el SCM para construir una réplica de Madrid antes del cambio. Este grupo de control sintético" actuará como nuestro contrafactual observable y es precisamente lo que nos permitirá hacer el diagnóstico de tendencias paralelas que haremos a continuación.

Resultado del modelo y evaluación

En la figura anterior vemos cómo el cambio en la nevera ha generado un impacto tremendo en los hoteles de Madrid. ¿Por qué podemos inferir que ha sido por el cambio en la nevera? Podría haber otros elementos estacionales. Podemos inferir esto gracias a que contamos con un grupo de control que no ha tenido ninguna afectación en la métrica objetivo si comparamos el periodo pre y post-intervención.

Ahora bien, una gráfica no prueba causalidad. Debemos evaluar el modelo y es aquí donde hay mucha tela que cortar. ¿Podemos fiarnos de estas gráficas? ¿podemos fiarnos de lo que ven nuestros ojos? Vamos a ver cómo evaluar si realmente nuestra intervención ha generado dicho impacto y en qué medida de manera causal.

Antes de nada, vamos a checkear con OLS (Ordinary Least Squares) ambos grupos para comprobar que, antes de la intervención, la diferencia Madrid−Control no tiene tendencia. Si el “gap” es plano en pre-intervención entre ambos grupos, la asunción de tendencias paralelas (necesaria para estimar el efecto) se cumple y ya podemos pasar a los siguientes pasos. Si el “gap” crece o cae de forma sistemática, hay que reconstruir el control y volver a empezar. Ejecutamos el siguiente código:

def slope(y):
    t=np.arange(len(y)); return np.polyfit(t,y,1)[0] if len(y)>1 else 0.0
m_pre=mad_series[mad_series['date']<ref_date]
c_pre=ctrl_series[ctrl_series['date']<ref_date]
pre_df=m_pre.rename(columns={'margin':'m_mad'}).merge(c_pre.rename(columns={'margin':'m_ctrl'}), on='date')
pre_df=pre_df.sort_values('date').reset_index(drop=True)
pre_df['t']=np.arange(len(pre_df))
res_pre=smf.ols('(m_mad - m_ctrl) ~ t', data=pre_df).fit()
print(res_pre.summary())
print('Pendiente PRE Madrid:', slope(m_pre['margin'].values))
print('Pendiente PRE Control:', slope(c_pre['margin'].values))

El output del código (que es solo de Madrid en periodo pre-intervención) nos muestra:

• Intercept: nivel del margen del primer día preintervención que resulta que es alrededor de 134€/hotel-día.

• t: la pendiente de Madrid en el periodo preintervención. Aumenta de manera estadísticamente significativa (p-valor = 0.005) en 0,0962€/día.

¿Por qué no sale “lo del control” ahí? Porque esa tabla no compara grupos; es una regresión univariada. A continuación, realizamos el siguiente que busca directamente asumir si la tendencia pre-intervención entre el grupo de control y los hoteles de Madrid son paralelas:

m_pre = mad_series[mad_series['date'] < ref_date].rename(columns={'margin':'m_mad'})
c_pre = ctrl_series[ctrl_series['date'] < ref_date].rename(columns={'margin':'m_ctrl'})
pre_df = (m_pre.merge(c_pre, on='date')
                .sort_values('date')
                .assign(gap=lambda x: x['m_mad'] - x['m_ctrl'],
                        t=lambda x: np.arange(len(x))))

X = sm.add_constant(pre_df['t'])
mod = sm.OLS(pre_df['gap'], X).fit(cov_type='HAC', cov_kwds={'maxlags':7})
print(mod.summary().tables[1])
print(f"Pendiente gap PRE: {mod.params['t']:.4f}  |  p-valor: {mod.pvalues['t']:.3f}")

# Visual rápido: gap PRE
plt.figure()
plt.plot(pre_df['date'], pre_df['gap'])
plt.axhline(0, ls=':')
plt.title('Gap PRE (Madrid - Control)')
plt.xlabel('Fecha'); plt.ylabel('€'); plt.tight_layout(); plt.show()

Aquí vemos el output del anterior código. Debido a que la p-valor no es estadísticamente significativa (es superior a 0.05), podemos validar la asunción de tendencias paralelas o, como mínimo, es plausible asumir esto. Igualmente, que la pendiente sea -0,0309 significa que antes del cambio el gap entre control y los hoteles de Madrid se estrechaba muy levemente. Sin embargo, como no es estadísticamente significativo, no podemos decir que sea distinto de 0 (que es lo que buscamos).

TWFE (Two-way Fixed Effects)

Con TWFE buscamos estimar el efecto causal de un tratamiento que cambia con el tiempo como tenemos en este caso. ¿Cómo lo hacemos? aplicando una regresión con efectos fijos por hotel y por fecha.

Veámoslo con un ejemplo: si el Hotel A tiene un margen “propio” de 100€ y ese día, en promedio, todos los hoteles están 10 puntos por encima, una observación de 120 se convierte en un “residuo” ≈ 120 − 100 − 10 = 10. La regresión usa esos residuos de margen y de las variables explicativas para ver si los hoteles con tratamiento (los de Madrid), tras el cambio, suben más que lo esperable por su hotel y por el día. Así quitamos (es decir, absorbemos) “ser un hotel A” y “ser un domingo” del análisis.

Esto permite aislar el efecto del cambio de la nevera del resto del ruido. Al quitar lo fijo de cada hotel y lo común de cada día, el modelo compara la variación dentro del hotel y dentro del día.

D es el cambio de Madrid frente a su contrafactual (29,08€/hotel-día). Si asumimos tendencias paralelas (que hemos hecho con el anterior cálculo), lo podemos interpretar como el efecto causal medio (ATT = Average Treatment Effect on the Treated). Es importante destacar el intervalo de confianza entre 21,34 y 36,81.

¿Y occ (ocupación) y adr (average daily rate)? Los tratamos como covariables. Es decir, como dijimos en la anterior edición, como variables que pueden influir tanto en la métrica objetivo como en el tratamiento. Es importante entender que no son como tal causas del margen, ya que su coeficiente resulta una correlación condicional y no causal.

¿Para qué nos sirven? para reducir ruido y ganar precisión en la estimación de D. Al “absorber” la parte de margin explicada por la ocupación (occ) y el precio (adr), el error residual baja y el estimador del efecto del cambio de minibar sale más estable y con menor error estándar. Eso sí, solo los usamos como controles de precisión si no son “bad controls” (es decir, si el tratamiento no los altera). Para comprobar esto, sencillamente debemos ejecutar el siguiente código:

specs = {
    "base":       "margin ~ D + C(hotel_id) + C(date)",
    "+occ":       "margin ~ D + occ + C(hotel_id) + C(date)",
    "+occ+adr":   "margin ~ D + occ + adr + C(hotel_id) + C(date)",
}
for name, f in specs.items():
    res = smf.ols(f, data=work).fit(cov_type='cluster',
                                    cov_kwds={'groups': work['hotel_id']})
    print(f"{name:8s}  D = {res.params['D']:.2f}  (se={res.bse['D']:.2f}, p={res.pvalues['D']:.3g})")

# 2) Falsificación: ¿el tratamiento mueve occ o adr? (no debería)
for y in ['occ','adr']:
    res = smf.ols(f"{y} ~ D + C(hotel_id) + C(date)", data=work)\
             .fit(cov_type='cluster', cov_kwds={'groups': work['hotel_id']})
    print(f"{y}:  efecto de D = {res.params.get('D', float('nan')):.3f}  p={res.pvalues.get('D', float('nan')):.3g}")

Como es similar al valor de D anteriormente mostrado (29,08€/hotel-día) y, sobre todo, porque no es estadísticamente significativo, podemos asumir que D no afecta a occ ni adr, así que incluirlos no sesga el tratamiento y pueden ser covariables como han sido hasta ahora.

Event Study

Un event-study es la radiografía dinámica del efecto. En vez de dar un único número promedio, estimamos un coeficiente para cada día relativo al cambio (k): días “lead” antes del 0 (que sería el periodo pre-intervención) y “lag” después (periodo post-intervención). Así comprobamos dos cosas a la vez:

1. Que la tendencia PRE sea plana (la asunción de tendencias paralelas)

2. Cómo evoluciona el impacto tras la intervención.

¿Por qué volver a calcular la asunción de tendencias paralelas? Porque el test previo miraba algo muy concreto (el gap medio), pero el event-study es más fino: pone un indicador por día y comprueba si hubo anticipación (efectos antes del día pre-intervención), curvaturas o baches PRE que un slope promedio puede no detectar.

¿Y qué ganamos si ya teníamos el valor de 29,08€/hotel-día? El DiD da una cifra media, pero el event-study te da la película entera: cuándo aparece el efecto, si despega poco a poco, si se agota o se acelera, y cuánto ruido/incertidumbre hay en cada tramo (bandas IC). El event-study no reemplaza al DiD: lo audita y lo enriquece mostrando la dinámica causal completa.

¿Cómo se interpreta esto? Antes del día del cambio en Madrid, las bandas del intervalo de confianza están cerca de 0, lo cual es buena señal: serían parámetros paralelos. Tras el día del cambio vemos un salto positivo: a partir de k = 10 los βk​ rondan +20 € a +40 € por hotel·día y el 0 queda fuera del IC en buena parte de las fechas. Eso sugiere un efecto causal creciente (rampa) más que un pico efímero.

Donut, Placebo Test & Leave-one-city-out

Para finalizar, vamos a estresar el modelo con tres técnicas de evaluación adicionales:

1. Donut: Excluye días cercanos al día de inicio del tratamiento para evitar contaminación y estima el efecto.

2. Placebo Test: Mueve artificialmente la fecha del tratamiento al pasado y verifica que el efecto estimado sea nulo. Muy útil en contextos de este tipo.

3. Leave-one-city-out (LOCO): Reestima el modelo excluyendo una ciudad y comprueba que el resultado no dependa de ese mercado. También muy adecuado en este contexto.

El output que obtenemos es el siguiente:

1. Donut: pese a perder días en el análisis, el efecto es prácticamente igual.

2. Placebo test: el placebo da −4.02 y p-valor igual a 0.005. Es decir, es pequeño pero significativo y señala algo de estacionalidad en el periodo pre-intervención no capturada. No invalida el resultado, pero pide cautela porque podría indicar que el efecto depende de una rampa ascendente previa. En este caso se debería averiguar si hay algo de ruido en los datos repitiendo los placebos en distintas ventanas de tiempo o incluso ejecutar permutaciones.

3. Leave-one-city-out (LOCO): Al quitar Zaragoza se obtiene 26.53, casi idéntico al principal. El hallazgo no depende de esa plaza y tenemos un modelo interesante. Una buena práctica es repetir LOCO con otras ciudades.

Falsificaciones

Una buena manera de acabar de evaluar un modelo de DiD es mediante una falsificación, la cual sirve para comprobar que nuestro método no detecta “efectos” cuando no debería. Es decir: si no hubiera intervención, es decir, si no hubiéramos hecho ningún cambio en los 12 hoteles de Madrid, ¿mi DiD produciría 0? La idea es que sí. Estas pruebas atacan sesgos por pre-tendencias, estacionalidad mal capturada, entre otros.

¿Cómo lo hacemos? Utilizamos occ y adr como respuesta del modelo en dos regresiones separadas en las que usamos D (el tratamiento) para así cuadrar que la intervención no mueve ocupación o precio una vez controlas por hotel y fecha. Así medimos el cambio medio en ocupación (occ) o precio (adr) cuando D=1 (tratado) frente a D=0, manteniendo constante cada hotel y cada fecha. El resultado es muy adecuado como podemos ver en la siguiente figura:

Gráfica final con contrafactual

Es aquí cuando vamos a construir el contrafactual. Justamente cuando hacemos work.copy y definimos “D = 0”. Lo pongo en negrita para que se vea más fácil. Anteriormente, nuestras estimaciones del modelo han sido con el grupo de control que hemos generado a partir de los 88 hoteles restantes y que no están presentes en Madrid.

treated_post=work['treated'].eq(1) & work['D'].eq(1)
pred=twfe.predict(work)
cf=work.copy(); cf.loc[treated_post, 'D']=0
pred_cf=twfe.predict(cf)
agg=(work[work['treated']==1].assign(yh=pred, yh_cf=pred_cf)
     .groupby('date', as_index=False).agg(actual=('margin','mean'), cf=('yh_cf','mean')))
agg['att_t']=agg['actual']-agg['cf']
plt.figure(); plt.plot(agg['date'], agg['actual'], label='Observado (Madrid)');
plt.plot(agg['date'], agg['cf'], linestyle='--', label='Contrafactual');
plt.axvline(ref_date, linestyle='--'); plt.title('Observado vs Contrafactual');
plt.xlabel('Fecha'); plt.ylabel('€'); plt.legend(); plt.tight_layout(); plt.show()
print('ATT medio post (€/hotel·día):', agg.loc[agg['date']>=ref_date,'att_t'].mean())

Ahora hemos justo creado el contrafactual, es decir, el mundo que imaginamos y que responde a la pregunta “¿Qué hubiera pasado con el margen si no hubiéramos hecho ningún cambio?” En la siguiente figura puedes ver cómo hubiera evolucionado la métrica objetivo si nunca hubiéramos hecho caso al proveedor. Como se puede ver, el ATT es de 29,08€/hotel-día. Este contrafactual es la predicción que hace el modelo para Madrid fijando D = 0 en TWFE, mientras que el gemelo sintético son los datos observados de otros hoteles combinados con pesos para emular a Madrid en pre-intervención.

Cambiar el contenido de la nevera en Madrid elevó el margen en alrededor de 29€/hotel-día. Las pre-tendencias son paralelas, el efecto aparece tras el cambio y se mantiene.

Ideas clave

Aquí algunas de las ideas clave:

1. DiD permite hacernos preguntas que están en pleno mundo de la imaginación: “¿Qué hubiera pasado con el margen si no hubiéramos hecho ningún cambio?”

2. Las alternativas serias al test AB son fascinantes y forman parte de la familia del análisis causal. Son alternativas sinceramente más técnicas, pero que una vez dominadas son altamente efectivas.

3. Los métodos de evaluación son fundamentales y es donde más horas dedicarás. Son los que determinan si tu modelo tiene la suficiente calidad como para apuntar que existe una relación causal entre un fenómeno y otro.

4. Dominar estas técnicas nos permite dejar de ser meros observadores de datos para convertirnos en arquitectos de decisiones estratégicas, estimando el verdadero impacto de cada acción que tomamos.

Libros recomendables:

• The Book Of Why - Judea Pearl

• Causal Inference in Python - Mateus Facure

• Causal Inference for Data Science - Aleix Ruiz de Villa

• Inferencia y descubrimiento causal en Python - Aleksander Molak

• Causal AI - Robert Osazuwa

Sé que dije que no publicaría ninguna nueva edición hasta septiembre, pero este anuncio (¡que me pilló en plenas vacaciones! ¡vaya fechas!) de Google merece que haga un excepcional hueco ya que la tecnología y, sobre todo, la emoción que generan estas noticias no entienden de veraneo.

Vamos al grano, empieza la 21ª edición de Leanalytics.

Guía: MCP de Google Analytics con Claude Desktop

Introducción

La pasada semana Google lanzó y compartió un repositorio oficial que explica paso a paso cómo instalar el MCP (Model Context Protocol) de GA4. Este modelo, todavía experimental, permite a un servidor local MCP interactuar con la API de Google Analytics.

Es decir, permite preguntar a una IA generativa (como Claude o Google Gemini) por los datos previamente capturados de tu propiedad de Google Analytics para obtener información como veremos más adelante.

“Es un game changer” es la frase que más he repetido y no tengo dudas de que va a transformar la manera no solo de analizar el comportamiento digital, sino también de reportar y tomar decisiones estructuradas de negocio.

¿Qué encontrarás en esta edición?

1. Instalar Claude Desktop

2. Instalar MCP de Google Analytics

   1. Instalar pipx

   2. Configurar las APIs de Google Cloud

   3. Configurar Claude Desktop

3. Análisis con el MCP de Google Analytics

   1. Una tabla de datos y funcionamiento básico

   2. Una tabla y revisión de calidad del dato

   3. Gráficas e inferencia: ¿Algún contenido sobresale de manera estadísticamente significativa?

4. Rápidas Reflexiones

¡Empecemos!

1. Instalar Claude Desktop

Aunque la documentación de Google explica cómo instalar este MCP con Gemini CLI o Gemini Code Assist he optado por Claude Desktop por mera preferencia y costumbre de uso. Tengo constancia de que se pueden hacer consultas con Visual Studio y Code Assist y, de hecho, Google Gemini es superior a Claude en aspectos de estadística, álgebra o cálculo y particularmente lo recomiendo para dicho fin.

La instalación de Claude Desktop no tiene ningún misterio. Basta con visitar este enlace y descargar Claude Desktop en función del dispositivo que utilices. Esto pone encima de la mesa una de las características más importantes de esta funcionalidad: este MCP corre en local cosa de la que luego hablaremos.

2. Instalar MCP de Google Analytics

El proceso de instalación del MCP de Google Analytics puede ser complejo para aquellos no dados a este mundillo. Vamos a ir poco a poco para que nadie se pierda y si tienes cualquier duda, más abajo tienes la sección de comentarios.

2.1 Instalar pipx

Como bien apunta la documentación de Google debemos instalar pipx. Deberías pegar el siguiente código en tu terminal si trabajas con macOS. Si usas otros sistemas operativos como Windows deberás instalarlo vía Scoop y si eres Linux dependerá de si usas Arch, Fedora o Ubuntu como se dice en la documentación que te he dejado arriba.

brew install pipx
pipx ensurepath
sudo pipx ensurepath --global # optional to allow pipx actions with --global argument

2.2 Configurar las APIs de Google Cloud

Debemos asumir que si estamos montando el MCP de Google Analytics tenemos acceso a una propiedad con datos (parece obvio, pero mejor avisar). Si no tienes datos en tu propiedad de Google Analytics, aunque sigas estos pasos de instalación, no obtendrás ningún output.

Dicha esta obviedad, deberemos:

2.2.1 Crear un proyecto de Google Cloud

Lo que no es tan seguro es que tengas una cuenta de Google Cloud: no te preocupes, si haces clic en el siguiente enlace podrás crear una cuenta de Google Cloud y montar proyecto. También puedes crearla visitando console.cloud.google.com. Una vez tengas tu cuenta de Google Cloud, debes montar un proyecto. La parte marcada en rojo es donde deberías hacer clic.

2.2.2 Crear credenciales

Una vez creado el proyecto, si haces clic en la hamburguesa (☰) se desplegará una columna a la izquierda y deberás hacer clic en “APIs y servicios”. Después de hacer clic en APIs y servicios, aparecerá un desplegable y deberás hacer clic en “credenciales”.

La siguiente página será algo similar a esto (no exactamente igual, ya que ya tengo cosas montadas). Si haces clic en “Crear credenciales” podrás crear una “Cuenta de servicio”.

El proceso es francamente sencillo: apenas es necesario que pongas un nombre (el que prefieras, puede ser “ga4-mcp-test”) y cuando lo finalices verás que tienes una fila adicional como la que se ve en la siguiente imagen. Donde ves la franja azul deberías ver un correo electrónico.

Si haces clic sobre el correo electrónico verás lo siguiente. Haz clic en “Claves” y dentro haz clic en el CTA principal: “Agregar clave”.

Si has seguido estos pasos deberías ver algo como la siguiente imagen. Te recomiendo que selecciones JSON y que nunca compartas con nadie este archivo ya que contiene las credenciales secretas que dan acceso total a tu cuenta de servicio. Es como compartir tu contraseña: cualquiera con este archivo puede actuar en tu nombre en Google Cloud. Cuando le des a “Crear” te descargará automáticamente un archivo JSON.

2.2.3 Dar acceso a la propiedad de Google Analytics

¿Y ahora qué? pues deberías copiar el correo electrónico que tienes en tu listado de “Cuentas de servicio” (la franja azul de antes) y dirigirte a tu propiedad de Google Analytics. Así, podrás dar acceso a ese correo en tu propiedad. Este es un proceso estándar dentro del entorno de Google Cloud. Con permisos de lector ya debería ser suficiente.

2.2.4 Habilitar las APIs

Para finalizar: deberemos volver al entorno de Google Cloud y en la sección “Biblioteca” habilitar dos APIs: Google Analytics Admin API y Google Analytics Data API. Es tan sencillo como hacer clic en cada una y pulsar “habilitar”

Ahora sí, podemos dar por concluido todo lo que necesitamos hacer con Google Cloud.

2.3 Configurar Claude Desktop

Si abrimos Claude Desktop e iniciamos sesión no tendremos instalado el MCP. Todavía nuestro Claude Desktop no entendería nada si le hacemos un prompt preguntando sobre nuestros datos de Google Analytics. Por ello, necesitamos configurar Claude Desktop. Si abres Claudes Desktop, en macOS, en la barra superior deberemos hacer clic en “Configuración”.

Aparecerá la siguiente sección y deberemos hacer clic en “Desarrollador” (marcado en rojo). Te llevará a una sección donde el CTA principal es “Editar configuración”, lo cual te abrirá el finder de macOS como se ve en la figura 21.11.

Esto te lleva a la carpeta de Claude (ya que, recuerda, has instalado Claude en tu portátil) y deberás abrir este JSON que señalo en la figura 21.11. Este JSON no tiene nada que ver con el JSON de Google Cloud que acabas de crear hace un rato. Haz doble clic para ver lo que hay dentro.

Antes de nada, deberás volver a la documentación de Google en Github. Allí se muestra un código como el que muestro a continuación. Este es el que deberás pegar en el JSON de Claude Desktop que acabas de abrir. IMPORTANTE: donde pone "PATH_TO_ADC_JSON" deberás poner la ruta en la que se encuentra el JSON que descargaste de Google Cloud (ya que son tus credenciales).

{
  "mcpServers": {
    "analytics-mcp": {
      "command": "pipx",
      "args": [
        "run",
        "--spec",
        "git+https://github.com/googleanalytics/google-analytics-mcp.git",
        "google-analytics-mcp"
      ],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "PATH_TO_ADC_JSON"
      }
    }
  }
}

Si tus credenciales se encuentran en “Downloads”, seguramente la ruta será esta “/Users/nombre/Downloads/nombre-del-archivo.json”, pero si no estás seguro cualquier herramienta como Claude, Google Gemini o ChatGPT puede ayudarte a saber en qué ruta está cualquier archivo de tu ordenador.

¿Qué debes hacer?

1. Copiar el código de la documentación de Google que te he dejado más arriba y pegarlo en el JSON de Claude Desktop (que debería estar vacío si es la primera vez que entras).

2. Poner bien la ruta donde pone "PATH_TO_ADC_JSON" para apuntar al JSON que descargaste de Google Cloud, es decir, apuntar a tus credenciales.

3. Guardar el archivo JSON de Claude Desktop. Debería quedarte algo similar a lo que se muestra en la siguiente figura.

Cierra Claude Desktop y vuelve a abrirlo. Si todo ha funcionado bien deberías poder ver “analytics-mcp” al hacer clic en la sección de conectores. ¡Enhorabuena! has configurado de manera exitosa el MCP de GA4 con Claude Desktop.

3. Análisis con el MCP de Google Analytics

Te engañaría si te dijera que le he dado mucho trote a Claude Desktop y al MCP de Google Analytics ya que lo acabé de instalar este miércoles. No obstante, puedo compartir algunas consideraciones que extraigo a partir de estos primeros usos con el MCP.

3.1 Una tabla de datos y funcionamiento básico

Vamos a ver adónde podemos llegar. Para que tengas algo de contexto este MCP conecta con la propiedad de GA4 de Leanalytics:

¿Puedes hacer una tabla con los 10 eventos más comunes de Leanalytics con el MCP de GA4?

El resultado es el siguiente. Algo que me ha sorprendido es que al no indicarle ventana de tiempo me ha dado información de los últimos 30 días en lugar de los 28 que, a menudo, se usan por defecto en GA.

Importante destacar que por el camino Claude Desktop te pide permiso para usar una herramienta en concreto y muestra la siguiente figura. Debo reconocer que no le he dado a “permitir siempre” por el tema cuotas, por ello recomiendo que si empiezas le des a “permitir una vez” cada vez.

No es menor tampoco el hecho de que Claude avise de que no puede garantizar prácticas de seguridad o privacidad. Esta es una cuestión muy importante que, para uso profesional, debe evaluarse cuidadosamente.

3.2 Una tabla y revisión de calidad del dato

Vamos a subir un poquito el nivel y pedirle algo más concreto:

¿Puedes hacerme una tabla con los contenidos más visitados de Leanalytics? quiero ver sesiones, sesiones con interacción, usuarios totales y vistas de toda la ventana de tiempo disponible de GA4. Del 28 de diciembre de 2022 al 15 de julio de 2025. Que contenga los artículos: podrás identificarlos porque en la ruta de página contiene /p/.

Los resultados:

La pregunta de oro: ¿Estos resultados encajan con los de GA4? podemos verlo buceando en los datos de la propia interfaz de Google Analytics. Centrémonos en las 511 visitas que tiene el primer artículo de la lista. Como podemos ver, en la siguiente figura devuelve 526 en la misma ventana de tiempo.

No es mucho 15 de diferencia y está claro que está en fase experimental, pero podemos preguntarle al propio MCP por qué sucede esa desviación. He probado el siguiente prompt adjuntando la imagen de GA4.

como puedes ver, te he pedido vistas y tu me devuelves 511 cuando en la interfaz de GA4 devuelve 526 (adjunto): ¿Por qué sucede esto si es la misma ventana de tiempo?

Su respuesta:

¡Vaya! parece que fui yo a la hora de cambiar algún título o alguna URL (puede ser, la verdad). Si tratamos de checkearlo te das cuenta de que este artículo en particular debió tener algunos asuntos en materia de ruta de página (que debo reconocer que no recuerdo). Doy por buena la respuesta del MCP a pesar de que los datos no encajen del todo, ya que me encaja que haya habido un error por mi lado por aquél entonces.

Lo interesante de esto: no he tenido que meterme en exploraciones o en GBQ a indagar y elucubrar sino que he colaborado con mi MCP como si fuera un colaborador más de mi organización que puede darme pistas e hipótesis sobre por qué no sucede algo como debería.

Si vuelves a la figura 21.16 hay otra señal de que debo tener un problema con títulos o URL ya que la fila 15 y 16 coinciden, lo cual puede llevar a desviaciones entre lo que devuelve la API y lo que muestra GA4. Continuemos.

3.3 ¿Algún contenido sobresale de manera estadísticamente significativa?

¿Puedes aplicar un test estadístico (t-test o Anova One-Way) y decirme si hay una diferencia estadísicamente significativa entre las sesiones que ha generado un contenido y los demás? Deseo saber si la diferencia de sesiones entre un contenido u otro es estadísticamente significativa para saber qué contenidos debería hacer a partir de ahora si me guío por la métrica sesiones.

¡Menuda pregunta! le estamos pidiendo que aplique un test y un poquito de estadística inferencial para evaluar si existen diferencias relevantes entre un contenido u otro. Veamos qué resultado nos da (mientras escribo esas líneas, debo apuntar que ha tardado varios minutos en responder):

Dejando a un lado que la mayoría de herramientas de IA generativa te hacen sentir como si hubieras cambiado el mundo por su efusividad y entusiasmo, vamos a evaluar lo que dice:

1. El 006 funcionó según datos de Google Analytics extraordinariamente bien. Esto es correcto por información que tengo yo de la interfaz de Substack.

2. Comete el error de comparar el 006 con la media del resto top-10 cuando hay contenidos (como el 020) que no llevan tanto tiempo y debemos recordar que hay contenido evergreen que envejece bien como el de este caso y otros que envejecen peor (por ejemplo, un contenido de alternativas a Google Optimize), así que aglutinar el 006 contra un promedio del resto puede dar a diagnósticos erróneos.

3. Sin embargo… mea culpa. Yo no indiqué tener en cuenta esto en el prompt y me da la oportunidad de reflexionar sobre la temporalidad del contenido y la precisión de mi consulta mientras leo su respuesta. Ahí está parte de la gracia de esta tecnología. Este prompt no era bueno. Mi indicación era imprecisa.

Vale, veámoslo con el tiempo en página: hazme un barplot con los contenidos en los que los usuarios han pasado más tiempo para poder comparar unos u otros. Hazlo solo del top 10 de contenidos en cuanto a sesiones y del 28 dediciembre de 2022 al 15 de julio de 2025

El resultado:

Una de las gracias de Claude Desktop es que muestra gráficas muy resultonas, lo que permite jugar un poco con métodos de visualización de datos. Esto, conectado al hecho de que Claude Desktop puede integrarse con Clarity MCP Server, Stripe o Airtable la convierte en una gran solución:

La asociación de ideas que hace el MCP de GA4 con Claude es muy poderosa desde un punto de vista de análisis descriptivo: está arrojando insights que, por ejemplo, contradicen lo anteriormente mencionado (que el 006 es un valor atípico dentro de mi cartera de contenidos).

Esto también nos ayuda a entender no solamente que la precisión del prompt importa, sino también el conocimiento que arrojamos en el prompt. Es ese conocimiento lo que hace que entonces los insights puedan ser de mayor calidad. Como suelo decir “La IA no nos librará del deber del conocimiento”.

¿Por qué? Porque cuanto más sepamos de cálculo, principios estadísticos, sentido de las métricas, eventos, del propio negocio, herramientas y demás, más jugo podremos sacar de estas soluciones. Para mí, es como la calculadora para el matemático: no lo sustituyó, sencillamente multiplicó sus capacidades.

Volviendo al análisis de contenido: el MCP ha arrojado un análisis descriptivo interesante que puede ser más profundo si se le añaden más métricas, contexto, fuentes de datos como Clarity o conocimiento del propio analista.

¿Tiene sentido lo que dice el MCP con lo que sé que funciona en Leanalytics? Sí, el contenido técnico ha funcionado mejor que otro tipo de contenidos, aunque se mencione que contenidos no técnicos como El Pensamiento Problem-Centric o ¿Existen los Growth Hackers? han funcionado muy bien.

4. Rápidas reflexiones

Mientras escribo estas líneas, Anthropic lanza que va a modificar los límites semanales de Claude Pro y Max, lo que me hace señalar el elefante en la habitación: ¿dónde encontramos las organizaciones el equilibrio entre aprovechar las ventajas competitivas de la IA generativa con el apalancamiento que puede ocasionar y el duro golpe ante subidas agresivas en cuotas?

Eso también me hace pensar sobre el futuro de la IA a veinte años vista. Probablemente separará aún más a las pequeñas empresas de las más grandes, las cuales podrán asumir un nivel de inversión que las empresas más humildes no podrán. Nada nuevo bajo el sol ya que nadie dijo que esto debía ser democrático.

Como cuestión técnica, este MCP corre en local y aunque en LIN3S ya le hemos dado al coco sobre cómo servitizar esto de manera segura (cuidado aquí…), escalable, eficiente y rentable, no es algo que en apenas 10 días desde su lanzamiento oficial parezca simple (ni mucho menos).

El futuro es este y lo tenemos aquí.

Reinventarse o morir.

¡Feliz verano!

Pero solo hasta septiembre. Me tomaré un descanso en verano para recargas pilas. Sin embargo, quiero dejarte por aquí una lectura relajada sobre un tema que me absorbió desde la primera vez que oí hablar de él: el análisis causal.

Con esta edición doy el pistoletazo de salida a una nueva serie de contenido dedicada a este fantástico tema. Me lo voy a tomar con calma. Lo voy a disfrutar como un buen whisky y no descarto crear entre medio otros contenidos o incluso otras series (sí, sé que tengo algunos pendientes).

Sin más dilación, empieza la 20ª edición de Leanalytics.

Introducción a Análisis Causal + Calculadora Diff-in-Diff (Parte 1)

1. Mis primeras vivencias

Oí hablar por primera vez de análisis causal en 2023 cuando Alberto Labarga me dejó caer esta palabra clave en una tarde fría de enero y me dijo “esto empieza a estar de moda en el campo de la ciencia de datos”. Me llamó poderosamente la atención la palabra causal porque siempre ha sido el sueño húmedo de todos los que nos dedicamos al marketing: establecer causa y efecto de nuestras acciones.

Desde ese día, todo lo que han publicado hasta hoy editoriales como O’Reilly, Packt, Manning, Penguin Random House o incluso algunas traducciones a castellano que ha traído Anaya a nuestro país han acabado en mi estantería y (casi) todos han acabado leídos.

Esos libros desbloquearon en mí un universo nuevo. Una nueva manera de pensar y de entender el análisis de iniciativas de marketing desde una perspectiva que aúna técnica de alto nivel con una mirada cualitativa de las cosas. Esto me ha permitido (hasta la fecha):

• En 2024, introducir en el área de CRO & Insights de LIN3S un protocolo de análisis con CausalImpact que nos permite identificar causa-efecto en aquellas variantes ganadoras lanzadas al 100% de los usuarios mediante un análisis se serie temporal. Si has trabajado con nosotros en el último año y medio estarás cansado de escuchar la palabra “ITSA”.

• Hablando de esto: en la edición sobre análisis ITSA de productos digitales profundizo en técnicas asociadas a establecer un cierto grado de causalidad aplicada a negocio digital y explico cómo reportar y las ventajas que tiene este método con respecto a otros más típicos.

• En Experimentación Online, en el último capítulo sobre tendencias futuras, apunto a que el análisis causal será norma en el futuro del negocio digital y recomiendo algunos libros y personas a seguir para estar al día.

1.1 ¿Qué relación guarda el Test AB con la causalidad?

Hace 3 meses tuve la oportunidad de asistir a un programa organizado por Economic AI en el que enseñaban análisis causal con una librería llamada DoubleML creada por ellos mismos. Sobre esta librería he construido la calculadora de diferencia en diferencias que encontrarás más abajo.

Allí vi que se repetía algo que me agradó y que he encontrado como “opinión más común” en libros, ponencias y formaciones de este tipo: “El Test AB (o RCT según el ámbito) es el Gold Standard de la Causalidad.” Como mucho, quizás superado por técnicas de meta-análisis como la combinación de p-valor que expliqué en este webinar y que popularizó a principios del 2024 Ron Kohavi para negocio online (aunque antes ya había escrito sobre ello en su libro).

El mismo Kohavi hace suya una frase de Winston Churchill para referirse al Test AB: “Many forms of Government have been tried, and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed, it has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.”

Es decir, te podrá gustar más o menos el test AB, pero sigue siendo el mejor método y el más fiable para establecer causa-efecto acerca de una acción de marketing, un medicamento o un estudio sociológico. Otra cosa es que analices mal y tengas juicios/prejuicios sobre esta técnica de análisis.

Pero… ¿Qué hacemos cuando es imposible hacer un test AB?

Aquí entra el análisis causal.

2. ¿Por qué Análisis Causal?

Un ejemplo memorable que explica muy bien por qué necesitamos análisis causal es este que explicaron en la formación de Economic AI: un modelo de Machine Learning (como una regresión o un modelo de clasificación) podría determinar que llevar un mechero en el bolsillo provoca cáncer de pulmón (y lo mejor: el modelo sería satisfactorio técnicamente hablando).

Esta afirmación, por pura lógica, es ridícula. Sin embargo abre la puerta a una idea incómoda para algunos: los modelos de ML tienden a trabajar con asociaciones mediante el aprendizaje de patrones complejos en los datos, mientras que la inferencia causal aprende de relaciones causales y va más allá de las puras “correlaciones” (Nota: a aquellos puristas de ML, dadle cierta distancia emocional al uso de la palabra “correlación” en este contexto).

Para bajarlo a tierra, veámoslo con un ejemplo:

• Desde una perspectiva de modelado predictivo que busca predecir el churn rate, nos preguntaríamos: ¿cómo podemos construir una serie de reglas que predigan Y (el churn) utilizando las features X (una serie de variables)? Así, surgirían nuevas preguntas específicas que ML puede responder:

  • ¿Cuán bien podemos predecir a los usuarios que se irán?

  • ¿Qué variables explican mejor el churn?

• Pero desde una perspectiva causal las preguntas serían diferentes: ¿cómo influye causalmente la acción D (una iniciativa, tratamiento o intervención) sobre el resultado Y (una métrica o efecto determinado, por ejemplo)? Así, surgirían nuevas preguntas que específicamente el análisis causal puede responder:

  • ¿Por qué los usuarios se van?

  • ¿Cómo podemos retener más usuarios?

Esta imagen del libro “The Book of Why” de Judea Pearl (uno de los padres de la causalidad) es demoledora y creo que envejecerá francamente bien. Fíjate que “las máquinas” están debajo de todo en el campo de “la asociación” mientras que un poco más arriba reside el ser neandertal que interactúa con el mundo (intervention) y desde ahí lo comprende.

Finalmente, en lo más alto el ser humano actual que imagina cosas que realmente no han pasado y aplica “contrafactuales” (de esto ya hablamos parcialmente en esta edición, pero profundizaremos más en siguientes ediciones).

El análisis causal permite dar respuesta técnica a una cuestión que genera quebraderos de cabeza a los científicos de datos: la explainability. Es decir, a explicar por qué suceden los fenómenos que nos rodean de manera empírica. Esta es la razón de ser del análisis causal y el motivo por el que me interesó tanto es porque CRO hunde sus raíces en la causalidad: en entender cómo los usuarios se comportan y qué output generan estos a partir de un estímulo nuevo que hemos construido (nuestra variante).

3. Vocabulario y conceptos clave

3.1 DAGs

Conocidos en inglés como Directed Acylic Graphs (DAGs) nos permiten comunicar, detectar relaciones e identificar los problemas relacionados para establecer causalidad alrededor de una pregunta de investigación general o específica.

3.1.1 Mediators

“X afecta a Z causalmente a través de Y”. Esto significa que condicionar en Y o bloquearlo puede afectar a Z.

3.1.2 Confounders

“Y induce una asociación no causal (es decir, una correlación) en X y Z”. Interactuar con Y podría afectar esta asociación que podemos percibir entre X e Y. Piénsalo así: podemos ver en una gráfica que cuando crece X crece Z, pero eso no significa que uno cause otro o que aumentar X genere aumentos en Z. Es la expresión gráfica de la manida frase “correlación no implica causalidad”.

3.1.3 Colliders

“Y no induce una relación en X y Z”. Algo divertido sobre este efecto es el Collider Bias que abre la puerta a falsas asociaciones que a menudo hacemos sobre los fenómenos que nos rodean (en futuras ediciones profundizaremos en ello).

Un ejemplo de este sesgo: en algunos estudios se ha observado que la asistencia a clase puede reducir la probabilidad de obtener buenas notas. Sin embargo, esto puede ser un collider bias, ya que la asistencia a clase y las notas pueden influir en la probabilidad de ser encuestado (o de completar el estudio). Al restringir el análisis a los encuestados, se puede crear una asociación falsa entre asistencia y notas.

3.2 Métricas

Dentro del ámbito del análisis causal hay una serie de métricas que debes conocer para futuras ediciones ya que utilizaremos este vocabulario a menudo. No te preocupes: en siguientes ediciones te redigiré a este apartado para refrescar estas cuestiones.

Las métricas más comunes serían:

• ATE (Average Treatment Effect): El efecto causal promedio que un tratamiento tiene sobre el resultado en toda la población. Es la diferencia en los resultados si todos los usuarios fueran tratados versus si nadie lo fuera.

  • Es decir, es el efecto causal global que se estimaría si toda la población estuviera expuesta al tratamiento (o no) respectivamente.

• ATT (Average Treatment Effect on the Treated): El efecto causal promedio del tratamiento específicamente en el subgrupo de usuarios que sí recibieron la intervención. Compara sus resultados observados con lo que les habría sucedido sin tratamiento o intervención.

  • Es decir, es el efecto promedio en aquellos que SÍ han formado parte del grupo con tratamiento.

• GATE (Group Average Treatment Effects): consiste en el efecto promedio del tratamiento de un subgrupo.

• CATE (Conditional Average Treatment Effect): El efecto causal promedio del tratamiento para usuarios que comparten un conjunto específico de variables o covariables predefinidas. Permite analizar la heterogeneidad del efecto.

• APO (Average Potential Outcome): El valor esperado del resultado (Y) para un nivel de tratamiento específico (D).

  • Es decir, permite estimar el resultado promedio si todos los individuos hubieran recibido un tratamiento particular o no.

3.3 Covariables

Las covariables son un elemento troncal que no solamente son relevantes en temas de análisis causal, también en métodos como CUPED y de reducción de varianza se utilizan este tipo de variables.

Las covariables son variables que pueden influir tanto en el resultado que nos interesa (Y) como en la asignación del tratamiento (D). En el análisis causal es clave para controlar el confounding, que ocurre cuando una variable afecta tanto la probabilidad de recibir el tratamiento como el resultado, creando una asociación no causal entre el tratamiento y el resultado observado.

En un análisis como los que debemos enfrentarnos a menudo en análisis causal, donde la asignación del cambio/tratamiento no es aleatoria (como sí sucede en un test AB normal de negocio digital), las covariables son fundamentales para intentar replicar las condiciones de un experimento aleatorio.

Si se controlan todas las variables de confusión, se asume que el tratamiento es "tan bueno como asignado aleatoriamente" condicionalmente a esas covariables, lo que permite estimar el efecto causal con mayor rigor.

Importante: Solo se deben considerar aquellas covaribles que son pre-tratamiento (es decir, no afectadas por el tratamiento en sí y que son previas, a menudo, al Día D). De hecho, la inclusión de "malos controles" o "colliders" (variables que son efectos comunes de otras variables) puede introducir sesgos, incluso si parecen estar correlacionadas con el resultado o el tratamiento.

¿Por qué nos interesa conocer todo esto? Porque a continuación adjunto una calculadora de diferencia en diferencias, un clásico dentro del análisis causal que forma parte del universo de las técnicas cuasi-experimentales y que representa una buena alternativa cuando no podemos usar Tests AB.

4. Diff-in-diff calculator

Pero… ¿qué es diferencia en diferencias? es un método utilizado para evaluar el efecto de una intervención comparando los cambios en los resultados entre un grupo tratado y un grupo de control. Sé lo que estás pensando: “¿pero esto no es como un test AB?”

Pues no, porque un test AB generalmente implica la aleatorización de la asignación del tratamiento en un único punto en el tiempo (una serie de semanas, habitualmente), mientras que en diff-in-diff se enfoca en el cambio en el tiempo de los resultados para el grupo que ha recibido el tratamiento o intervención comparando con el cambio a lo largo del tiempo para el grupo de control.

Un ejemplo simple: queremos evaluar el impacto de una campaña de email marketing en las ventas. Se seleccionan dos ciudades diferentes (Zaragoza y Pamplona, que comparten en nuestros negocios varios patrones comunes) y en una se implementa la nueva campaña (tratamiento) y en la otra se mantiene la antigua (grupo de control).

Se comparan las ventas antes y después de la implementación en ambas ciudades. La diferencia en el cambio de ventas entre la ciudad tratada y la de control revelaría el efecto causal de la nueva campaña.

¿Cómo funciona la calculadora?

Aquí tienes la calculadora de diferencia en diferencias. Esta es una calculadora un poco avanzada y no descarto hacer otra un poco más simple y accesible para aquellos más noveles en este campo. Lo estudiaré :D

¿Cómo funciona? Esta calculadora implementa un análisis de Diferencias en Diferencias utilizando DoubleML. Mediante una carga de CSV (con un formato determinado y necesario) permite calcular el efecto de una intervención de manera causal, proporcionando tanto la estimación puntual como un intervalo de confianza para una interpretación básica.

Tras la carga de datos (es decir, del CSV), se calcula la diferencia en la variable de resultado (Y) entre el período post-intervención y el pre-intervención para cada unidad y selecciona las covariables (X) del período base. Las covariables no son obligatorias.

Finalmente, se estima diff-in-diff con DoubleMLDID. La calculadora se enfoca en el "Average Treatment effect on the Treated" (ATT) e incluye un diagnóstico para evaluar supuestos como el balance de covariables y el solapamiento de propensiones.

5. Recursos de verano

Espero haberte generado ganas de aprender más y más de análisis causal. Con esta edición solamente quería dejar una serie de ideas clave encima de la mesa:

1. El análisis causal va un paso más allá que el ML tradicional en ciertas cuestiones.

2. ML funciona con asociaciones y no establece causas. Responder al por qué de cualquier cosa requiere de un profundo conocimiento sobre análisis causal.

3. El análisis causal es una solución muy válida en escenarios donde no podemos aplicar Tests AB, aunque ciertamente es una alternativa muy técnica y no accesible para todas las organizaciones y perfiles.

4. El análisis causal consiste en entender las relaciones, comprender cómo funcionan y abrazar una nueva manera de mirar el mundo.

En siguientes ediciones entraremos en cuestiones más técnicas y, de hecho, será la dirección estratégica de contenido de los siguientes meses de Leanalytics. Hasta entonces, ahí tenéis la calculadora y aquí un listado de libros sobre análisis causal que pueden ser una buena lectura. Están puestos en orden recomendada de lectura de menos complejo a más:

• The Book Of Why - Judea Pearl

• Causal Inference in Python - Mateus Facure

• Causal Inference for data science - Aleix Ruiz de Villa

• Inferencia y descubrimiento causal en Python - Aleksander Molak

• Causal AI - Robert Osazuwa

¡Feliz verano!

En esta edición voy a presentar un caso que hemos vivido en LIN3S recientemente: un test AB que ha generado 3M$ perfectamente imputables a la P&L. No Bullsh*t. Te contaré cómo se nos ocurrió y el aprendizaje que extrajimos para que pueda inspirarte en tus próximos experimentos e ideas de producto.

Ahora sí, empieza la 19ª edición de Leanalytics:

Un test AB de 3 millones de dólares

Contexto del negocio

Imagina un negocio digital multipáis transaccional: un comercio electrónico que opera en varios mercados y que cuenta con el flujo tradicional y lineal de cualquier producto de este tipo.

En la figura 19.1 ves la representación gráfica del flujo. En él podemos ver cómo el flujo va desde la búsqueda de un restaurante, pasa por la llamada a una API de un famoso callejero utilizado en este tipo de plataformas para seleccionar el restaurante y finaliza con la compra.

Fuimos contratados para aplicar CRO dentro del negocio digital y eso hacemos: trabajar para mejorar negocios digitales. La cuestión es que el marketing digital es solo una parte del negocio digital como muestro en la figura 19.2.

Ejecutar CRO únicamente pensando en marketing puede ser limitado. Encontrar oportunidades para influir en el comportamiento del usuario puede requerir un enfoque más holístico que incluya análisis de los procesos, costes, tecnología, dirección de producto, estructura de ingresos y costes, entre otros.

Gracias a este enfoque holístico, pudimos encontrar la oportunidad que a continuación voy a relatarte.

La oportunidad y la hipótesis

El equipo de CRO detectó un punto de mejora en el flujo de la figura 19.1. A raíz de una reunión con el equipo de producto se detectó una oportunidad que daría pie a uno de los tests más exitosos que he visto.

La API que se destaca en la primera figura, en esencia, se utilizaba para recomendar direcciones a partir de lo que el usuario escribía. Nada que no puedas imaginar y que no haya en cientos de productos digitales.

¿Qué podría salir mal?

A menudo, las API de este tipo tienen un coste a partir de un número determinado de usos. Sin embargo, recuerda que este negocio digital cuenta con millones de usuarios debido a que es multipaís y a que su uso puede tener cierto nivel de recurrencia mensual.

A continuación, el punto de mejora que detectó el equipo de CRO:

Oportunidad: la API genera un coste de 3 millones de euros cada año sumando todos los mercados y el flujo tiene serias mejoras de usabilidad que no aseguran que la API genere una buena experiencia para el usuario que influya en la venta. 

Dimos con algo muy interesante: un centro de costes que bien puede considerarse un centro de gasto si conseguimos generar el mismo volumen de ventas e ingresos con un flujo alternativo que no consuma esa API.

La hipótesis (H1) que planteamos no giraba tanto en torno a la idea de mejorar los flujos (ya que era bastante largo en total y sucedía mucho antes de los eventos de conversión clave como purchase). Más bien, nos centramos en una idea más realista: podemos crear un flujo visual que sin el uso de dicha API (que desde luego tenía su utilidad práctica) mantenga el mismo nivel de ingresos sin penalizar la experiencia.

Hipótesis alternativa (H1): Si establecemos un flujo alternativo que no consuma la API, entonces las ventas no se verán afectadas y la empresa ahorrará 3 millones de dólares.

Hipótesis nula (H0): Si establecemos un flujo alternativo que no consuma la API, entonces las ventas sí se verán afectadas y la empresa no ahorrará 3 millones de dólares.

Pero no todo iba a ser tan fácil.

La solución y el test AB

La API servía para algo. Crear un flujo alternativo que no realizara dicho consumo implicó diversas reuniones con producto, diseño, negocio y tecnología y al final había una cuestión de riesgo: había que añadir, sí o sí, una pantalla más.

Esa “pantalla más”, personalmente no me generaba ningún tipo de fricción. Es bien sabido que cada vez el número de pasos en muchos flujos importa menos. Sin embargo, había que convencer a mucha gente para este test y, desde luego, hubo nervios y tensión (lógico, por otro lado).

Se propuso hacer un test AB que, conceptualmente, era así (aunque la realidad suele ser más compleja): la versión en blanco es el grupo de control y en gris la variante propuesta con un paso más.

Métricas primarias, secundarias y terciarias: resultados

Para evaluar este test no bastaba con simplemente quedarse con la variante por no emitir ese gasto. Era importante evaluar un conjunto de métricas de manera cuidadosa. Como veréis, no se utilizaba OEC en dicho proyecto. Algunas de las métricas que protagonizaron el análisis fueron:

- Métricas primarias: selección de restaurantes, purchase, revenue, ARPU.

- Métricas secundarias: Visualización de producto, AOV, consumo de cupones, tipología de productos y cupones consumidos...

- Métricas terciarias: devoluciones.

¿El resultado?

Aplicamos el proceso de diagnóstico de experimentos online que usamos en LIN3S y no se detectó ningún efecto significativo de manera práctica o estadística. De hecho, las pequeñas diferencias que podía haber iban más a favor de la variante que del grupo de control, aunque no eran tan grandes como para escudriñar que eran significativas.

No obstante, recordemos: no buscábamos que la variante fuera mejor. Buscábamos construir una versión suficientemente sólida que no afectara a las ventas ya que la variante ya contenía un ahorro de 3 millones de dólares por sí misma.

¿Durante cuántas semanas se dejó corriendo el experimento? La verdad es que esta es una pregunta típica. Aunque se recomendaba por nuestros análisis que estuviera durante 4 semanas, lo dejamos mucho más (6-8 semanas) para poder capturar un espectro más amplio y variable de usuarios por cuestiones del propio negocio (y, por qué no, justificar mejor la decisión).

Aprendizajes de este experimento

Este test hizo darme cuenta (o, más bien, recordó) muchas cosas que, a continuación, voy a enumerar:

1. La experimentación sirve como instrumento para gestionar el riesgo. Puedes imaginar que hubo dudas, preguntas y nervios fruto de la incerteza que esta idea (que no el test) generaba. El test no tenía la culpa: el test era el mecanismo para poner a prueba la idea de manera fidedigna y minimizando el riesgo.

2. CRO debe ir más allá de la optimización de pantalla aisladas. Abrazar un enfoque y metodología holísticas que vayan, incluso, más allá del marketing, es necesario para encontrar “las grandes oportunidades”.

3. Aunque hubiéramos detectado esta oportunidad al principio del proyecto, no hubiéramos podido trabajar sobre esta idea si no hubiéramos ganado previamente la confianza de los stakeholders clave. CRO es un ejercicio coral y las grandes misiones requieren de más colaboración si cabe. No esperes hacer esto el primer día en un proyecto nuevo.

Y hasta aquí esta edición. Espero que te haya gustado. Si es así, compártelo con tus amigos y amigas para dar a conocer que la experimentación va más allá del color de unos botones.

Que la fuerza te acompañe.

Compartir

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.

He aquí la gran pregunta. Si llevas un tiempo dedicado a esto más tarde o más temprano te harán esta pregunta y la respuesta no es nada simple. De entrada es un ¡no! pero conforme avanzas y aprendes un poco de este oficio te das cuentas de que hay aproximaciones técnicas que pueden permitirnos desentrañar la respuesta a esta repetida pregunta.

Ahora sí, empieza CRO: técnicas para bajas muestras.

Disclaimer

En primer lugar, en este post me pondré especialmente técnico, aún así, pienso que va a ser de fácil seguimiento (o eso pretendo) porque no tenemos tú y yo ningún tipo de prisa cuando se trata de experimentación y bajas muestras, ¿verdad?

En segundo lugar, no esperes soluciones mágicas. La ausencia de una muestra suficiente para experimentar es un problema por cuestiones elementales que se detallarán a continuación.

Sé lo que estás pensando: “¿por qué hacer un post sobre bajas muestras si tener una muestra pequeña es un impedimento para experimentar?” Debo decirte, querido lector, que lo importante no es el tamaño de la muestra, sino lo que haces con ella. Pensar que lo único que importa es la n es falaz.

Ahora sí, empezamos.

¿Qué es una muestra pequeña?

Esta es la primera pregunta que deberíamos hacernos. ¿No dependerá del contexto empresarial? ¿no dependerá de lo que queramos medir? ¿no dependerá de la población? ¿cómo saber de entrada si tenemos una capacidad de obtención de muestra suficiente en nuestro activo digital?

En el contexto de la experimentación online controlada, la obtención de la muestra no sucede como vemos en la siguiente imagen. En la carrera habitualmente aprendes que la muestra se obtiene de un conjunto poblacional previo pero no podemos olvidar que cuando ejecutamos un test AB no es necesariamente así.

En la mayoría de negocios online, cuando planeamos un experimento online controlado, estamos tratando de hacer una inferencia sobre los futuros usuarios (recurrentes o nuevos, en función del tipo de segmentación) desde que se activa el experimento.

Eso implica que, aunque puede haber una cierta cadencia y frecuencia común en el comportamiento de los usuarios antes y después del experimento, bien sabrás que la naturaleza del tráfico puede variar en función de múltiples causas: cambios en estrategias de puja, updates de Google, promociones agresivas en canales de adquisición específicos, problemas de rendimiento web que afectan a la velocidad, entre otros.

“Hic sunt dracones” se mostraba en los viejos mapas e indicaba ese territorio inexplorado y desconocido y es que, no nos engañemos, nadie (ya seas una empresa grande, pequeña o gigantesca) puede saber si mañana no habrá una caída/subida en tu sitio web de un canal concreto que provocará un tipo de tráfico y comportamiento en métricas cuya naturaleza es nueva.

La muestra necesaria en un experimento dependerá entonces de otra clase de cuestiones más allá de lo que uno pudo aprender en “estadística 1 y 2”. No profundizaré en esta cuestión ahora, pero no hace mucho la buena gente de Spotify publicó un estudio sobre la cuestión del tiempo como valor fundamental en la validez de los experimentos, más allá de la muestra.

¿Qué es entonces una muestra pequeña? Será aquél insuficiente para tomar una decisión en base al cálculo realizar para estimar el tamaño de la muestra. No obstante, el cálculo de la muestra no se hace como pudiste aprender en la carrera: no se tiene en cuenta la población previa para un test AB clásico, sino otra serie de cuestiones.

¿Cómo se calcula el tamaño de la muestra?

En mi libro “Experimentación Online: metodología, estrategia, datos y casos reales” que sale a la venta el 27 de marzo de 2025, dedico una muy buena parte a la compleja e interconectada cuestión del cálculo de la muestra para explicar una serie de cuestiones (deberás leerlo para enterarte 😉).

Sin tampoco entrar en harina, te diré que el cálculo de la muestra en un test AB depende de cuestiones como el tipo de hipótesis (una o dos colas), el nivel de significancia, la potencia o la asunción de la varianza de cada grupo una vez lanzado el test, entre otras cuestiones. De hecho, hay varias maneras de calcular la muestra como apuntó en su día Evan Miller en LinkedIn.

La fórmula más esencial del cálculo de la muestra es la siguiente y quiero que la retengas, porque nos irá de perlas que la tengas presente a lo largo de las técnicas que voy a presentar a continuación:

Ahora sí, empezamos con una serie de aproximaciones para escenarios con bajas muestras, iremos de más típicas y básicas a más avanzadas y técnicas.

Aproximaciones para bajas muestras

1. Modificar MDE

Como muchos de aquí sabrán, la muestra de un test AB se determina a partir del MDE lo cual abre la puerta a una cuestión que ya se explicó en la edición 10 de Leanalytics.

• Si necesitamos identificar como significativo un impacto menor, neccesitaremos más muestra.

• Si necesitamos identificar como significativo un impacto mayor, neccesitaremos menos muestra.

La calculadora de Evan Miller bien lo muestra. En la siguiente figura vemos que para detectar un impacto de 5 puntos porcentuales (de 10 a 20) solamente necesitaríamos 831 usuarios por grupo. La duración del experimento dependerá de cuánto tiempo tardas en tener todo ese tráfico.

Sin embargo, si el MDE es inferior, como en la siguiente figura, veremos que es necesaria mucha más muestra, lo que aumentaría el número de semanas en las que un experimento debería estar activo. Esto no tiene necesariamente nada que ver con el hecho de calcular el MDE de manera relativa o absoluta, es por el tamaño del efecto que quieres detectar (14,25% - 15,75%).

Pros y contras de utilizar el MDE

Este método nos mostraría que entonces “la muestra necesaria” no es una cuestión del tráfico que tenemos, sino del impacto que queremos o podemos medir de manera fiable. Sin embargo, este método tiene una serie de pros y contras.

Pros:

1. Es sencillo de aplicar ✅

2. Es modulable ✅

3. Es (más) fácil de explicar a stakeholders no orientados a la experimentación online que otros métodos ✅

Contras:

1. Está sujeto a la famosa frase de Ronald H Coase: “if you torture the data long enough, it will confess to anything” ❌

2. Está duramente condicionado, también, al efecto que estás generando mientras el experimento está en producción, lo cual obliga a una estimación de la muestra dinámica e iterativa 💡

3. Generar un impacto del 50% en los primeros días puede llegar a ser sencillo y no ser suficientemente fiable aunque tengas la muestra necesaria y un impacto estadísticamente significativo. No tiene en cuenta aspectos como los efectos de novedad o la regresión a la media que puede haber en tests AB. ❌

La configuración del MDE es una cuestión controvertida a la que dedico varias páginas en el libro “Experimentación Online” a cómo realmente llevar a cabo esta cuestión pero, ya te adelanto: ninguno de los métodos que se mostrarán en esta edición tiene solo pros y cero contras, lo cual señala la naturaleza de este trabajo.

2. Selección de métricas

Imagina un comercio electrónico en el que deseamos hacer un experimento en la página de producto ya que hemos detectado un punto de mejora a la hora de añadir a carrito: todo un clásico, ¿verdad?

Vale: ¿qué métrica utilizas? A priori hay dos grandes escuelas: si hacces la certificación de Optimizely te recomendarán que utilices como métrica primaria add_to_cart y nada más mientras que en otros foros se recomendará que trabajes con una baraja de métricas como add_to_cart, begin_checkout y purchase, tanto como primarias como guardrail metrics.

No olvides: no existe un procedimiento estándar porque no existe academia en todo esto. La experimentación online es un oficio en el que hay una importante capa de ciencia pero, incluso en estadística o el tratamiento avanzado de datos al final todo consiste en el enfoque que tú le das al problema.

Veamos en acción cómo la elección de la métrica puede modificar tu diagnóstico de un experimento online. En la siguiente figura vemos el escecnario en el que solo tenemos en cuenta como métrica primaria (la que principalmente determinará qué variante gana) add_to_cart. La diferencia relativa entre ambos grupos es del 6% y tenemos una p-valor de 0.0079.

Sin embargo, en la siguiente figura, cuyo escenario es el de que solo tenemos en cuenta métricas más lejanas al lugar en el que sucede el experimento (en este caso purchase) vemos lo siguiente:

1. Mismo crecimiento en purchase: +6%

2. Misma muestra: 80.000 por grupo

¿Qué cambia?

1. Número de conversiones (1600-1696) y por ende el conversion rate de ambos grupos y la diferencia absoluta (2,00 a 2,12), aunque no la relativa (6%)

2. Un intervalo de confianza más amplio en la figura 17.7 que en la 17.6

3. Z-Score menor en 17.7 (1.6897) que en 17.6 (2.4151).

Además, la p-valor es de 0.0455. Es decir, aunque es estadísticamente significativa, está más cerca de nivel de significancia (0.05). ¿Qué significa todo esto?

Aquí debemos hacer una pequeña pausa y entender una serie de conceptos. El afán por contar con una muestra suficiente tiene un único objetivo en el contexto de los experimentos online: poder tomar una decisión lo más fiable posible. Si no contamos con la muestra suficiente, a priori, la decisión que tomemos es menos fiable (que no significa errónea). Es una cuestión de probabilidad y de gestión de riesgo.

Sin embargo, aquí tenemos la misma muestra, pero lo que ha cambiado primariamente ha sido el número de conversiones y los parámetros asociados. Así, el efecto que generemos también va a condicionar duramente la muestra necesaria ya que en el escenario de la figura 17.7 tenemos una p-valor de 0.0455 que, si bien es estadísticamente significativa, podría tratarse de un falso positivo.

Habitualmente, los tests cuya p-valor está cerca de 0.05 son más proclives a caer en falsos positivos o incluso en falsos negativos, arrojando la idea de gradualidad en la p-valor resultante de un experimento. Así, técnicas como meta-análisis con técnicas como Stoufer o Fischer permiten averiguar si realmente nuestros experimentos son realmente fiables.

Así, la selección de la métrica a la hora de analizar un experimento online también condiciona el tamaño de la muestra necesaria y, sobre todo, la fiabilidad de nuestro diagnóstico. Esto es especialmente relevante cuando trabajamos con métricas más alejadas del punto de cambio (purchase), donde la varianza y variabilidad inherente puede requerir muestras más grandes para alcanzar el mismo nivel de fiabilidad.

Pros y contras de seleccionar métricas cercanas al punto de cambio como primarias

Pros:

1. Es sencillo de aplicar ✅

2. Aumenta la fiabilidad 💡

3. Como podemos esperar MDE más altos, podríamos contar con menor muestra para obtener la misma fiabilidad. ✅

Contras:

1. ¿Qué hacemos con las transacciones y los ingresos? ¿los tenemos únicamente en cuenta como guardrail metrics? es demasiado naíf ❌

2. Puedes cometer el error de aplicar mejoras locales que no afectan (o incluso empeoran) a nivel global, lo que afectará tus proyectos de experimentación online a medio plazo. ❌

3. Permutation Tests

Ahora sí, vamos a empezar con la parte más técnica de esta edición. Descubrí los tests de permutación cuando leí este libro sobre estadística aplicada a ciencia de datos a principios de 2021 y desde entonces siempre lo he tenido en la recámara como aproximación antes escenarios con bajas muestras.

Un test de permutación “es un test de significancia estadística para el estudio de diferencias entre grupos. Fue desarrollado por Ronald Fisher y E.J.G. Pitman en 1930. La distribución del estadístico estudiado (media, mediana…) se obtiene calculando el valor de dicho estadístico para todas las posibles reorganizaciones de las observaciones en los distintos grupos. Dado que implica calcular todas las posibles situaciones” (Fuente: https://cienciadedatos.net/documentos/23_resampling_test_permutacion_simulacion_de_monte_carlo_bootstrapping)

Veamos esto con un ejemplo. Imagínate que apenas cuentas con un puñado de usuarios (15 usuarios por grupo) y a cada usuario se le adjudica un ticket medio determinado. Lo que hacemos cuando aplicamos un t-test, por ejemplo, es determinar si la diferencia en la media entre ambos grupos es estadísticamente significactiva.

La aproximación en un test de permutación es lo que vemos en la siguiente figura (el gif de las alpacas): un test de permutataciín realiza n remuestreos (resasmpling) y recalcula el mismo número de veces la diferencia entre ambos y la p-valor resultante.

¿Cómo funciona esto exactamente? Cada nueva permutación (es decir, combinación posible en un intercambio de usuarios de grupo de control a variante y viceversa) te entrega una nueva p-valor y un nuevo resultado del experimento sin añadir nueva muestra. Así, con cada nueva permutación podemos afinar la p-valor rseultante como se ve en la figura 17.9 que, al final, resulta lineal cercana a 0.80 de p-valor (resultado estadísticamente no significativo).

Fíjate que en la primera permutación la p-valor fue muy, muy reducida y conforme se realizan permutaciones cada vez es más lineal. Esto es útil para aumentar la fiabilidad de los diagnósticos de un experimento online incluso con bajas muestras. Si lo prefieres ver con números cómo evoluciona la p-valor conforme se realizan permutaciones, lo puedes ver en la figura 17.10.

Fíjate que de la permutación 10 a la 25 apenas la p-valor se modifica, sin embargo, de la 1 a la 5 hay un cambio abismal. Cada nueva permutación añade una capa más de información y contexto sobre esta muestra inicialmente reducida.

Pros y contras de permutation test

Pros:

1. Permite no caer en falsos positivos o negativos con muestras muy, muy reducidas. ✅

2. Añade una capa extra de información ante este tipo de escenarios. ✅

Contras:

1. Es un poco más avanzado y ante stakeholders no técnicos puede ser complejo de abordar ❌

2. Funciona mejor conforme la muestra es más pequeña. Conforme aumenta la muestra, la p-valor final resultante es muy similar a lo que obtienes con un t-test💡

3. No aporta más potencia estadística al experimento, por lo tanto, no es como tal una solución perfecta para trabajar con bajas muestras ❌

4. CUPED

¿Recuerdas la siguiente figura? Te dije que la retuvieras. Ha llegado el momento de refrescar otra vez el cálculo del tamaño de la muestra. A continuación, vamos a desglosar esa fórmula a ver de qué se compone exactamente:

1. n: representa el tamaño de la muestra necesaria.

2. σ2: es la varianza de la población (o la estimación de esta).

3. δ: representa el MDE

Como ya señalé en el caso de las métricas, la variabilidad (es decir, la varianza) de los datos influye directamente en el diagnóstico pero, como podemos ver en esta fórmula simplificada, también en el cálculo de la muestra interviene la varianza.

Así, el tamaño de la muestra no se ve únicamente afectado por el efecto que queremos detectar, sino también por la varianza que tenemos entre manos, lo cual es un tema interesantísimo porque existen métricas con más varianza (ingresos, datos continuos) que otras (añadidos a carrito, datos discretos). A priori:

1. Cuanto mayor es la varianza de los grupos de un test AB, más muestra será necesaria independientemente del efecto.

2. Cuanto menor es la varianza de los grupos de un test AB, menor muestra será necesaria independientemente del efecto.

Así, la pregunta sobre la cual trabaja CUPED es la siguiente: ¿podemos reducir la varianza para así necesitar menos muestra? Fíjate que aquí no se trata tanto de trabajar con pequeñas muestras, sino de trabajar para reducir la muestra necesaria para realizar un diagnóstico adecuado.

Veamos esto con un ejemplo: tenemos un ecommerce de moda y deseamos evaluar si la variante de un test AB genera más ingresos que el grupo de control de manera estadísticamente significativa. Como tememos que habrá usuarios que realizarán transacciones muy elevadas y otras más reducidas, es posible que haya una varianza bastante elevada.

CUPED es una técnica diseñada para mejorar la potencia (es decir, la capacidad para determinar que existe un efecto cuando realmente existe) de un experimento reduciendo la varianza de los datos.

¿Cómo lo hacemos? mediante datos preexistentes como covariables para ajustar los resultados del test y eliminar parte de la varianza no explicativa (lo que podríamos considerar “ruido”). En vez de depender únicamente del resultado del test para explicar las diferencias entre control y variante, CUPED usa correlaciones basadas en datos históricos para «limpiar» ese ruido inherente. Esto significa que podemos identificar mejor los efectos de nuestra intervención con una muestra más pequeña.

Al aplicar CUPED hemos logrado reducir la varianza en ambos grupos en un 27.5%. Esto significa que si antes necesitábamos 10 000 usuarios para detectar un efecto, ahora bastarían aproximadamente 7,250. Dicho de otro modo, un experimento que originalmente duraba 4 semanas se podría reducir a cerca de 2.9 semanas.

Pros y contras de CUPED

Pros:

1. Es un método contrastado que permite reducir la muestra de un experimento. ✅

2. No compromete a la potencia estadística del experimento al modificar la varianza ✅

Contras:

1. Funciona mejor con datos con alta varianza. Si no hay alta varianza, no funciona tan bien ❌

2. Si no tienes unas covariables, es decir, unas métrias que explican otras métricas para dibujar una correlación, no te funciona CUPED correctamente. La covariable y la métrica objetivo deben tener una correlación significativa (r > 0.3). Si no, no te servirá CUPED según Alex Deng. ❌

3. Es un tema súmamente técnico que requiere de una costumbre en la organización por el tratamiento de datos de forma avanzada 💡

Esto no acaba aquí

Como estás viendo no hay un método único, elegante y simple de trabajar con bajas muestras y, realmente, todo tiene unos pros y unas cotnras esenciales. No venía aquí a arrojaros soluciones simples a problemas complejos y casi irresolubles: la muestra suficiente es una cuestión obligatoria pero, como ves, hay atajos y aproximaciones interesantes.

Tanto es así que esto es solo una muestra de algunas aproximaciones. El resto lo compartí en un webinar gratuito que puedes ver en YouTube. Si además, te interesa la parte más técnica de CRO, tienes que saber que estamos trabajando en un programa avanzado de CRO.

CRO será técnico o no será.

Un año de crecimiento, alegrías y aprendizaje. Un año memorable, la verdad. Lavando los platos —algo que recomiendo para mantener la mente en blanco y desconectar— me encontré pensando en datos y en una serie de aprendizajes antintuitivos adquiridos.

¡Cachis! volví a pensar en CRO.

Anyway… Quiero compartir contigo algo que he aprendido o he reforzado este año. En esta 16ª edición hablo de cinco aspectos de diseño y datos con los que me he topado y que me han llamado poderosamente la atención.

Ahora sí, empieza “Cinco aprendizajes de UX en 2024 (con datos)”

Espero que os guste.

¿Qué veremos?

1. Tendencia a lo descriptivo

2. Personalización y complejidad

3. Configuración de precios con datos

4. Findability

5. Los funnels

6. Bonus track: “esos botones no convierten más”

1. Tendencia a lo descriptivo

A poco que hayas leído o tengas unos mínimos de copywriting te habrás topado con ese principio (casi evidencia del marketing) de que un copy que apela a la emoción y al beneficio es mejor, convierte e incita más a la acción que un copy descriptivo y gris.

Esto creo que proviene de la publicidad tradicional: la época dorada de la publicidad del pasado siglo en la que los creativos publicitarios construían conceptos a través de insights (pero de verdad) para enamorar y despertar el recuerdo a una audiencia determinada.

No seré yo quien diga que un buen copy no te agita la patata. Sin embargo, debo confesar que el resultado de muchos experimentos de 2024 (y unos cuantos más de tiempos anteriores) me está induciendo a creer que hay una poderosa tendencia a lo descriptivo.

¿A qué me refiero con esto? Todos estos ejemplos son de productos en industrias muy conocidas y que todos vosotros consumís a menudo y reconocéis:

• CTAs con copys más descriptivos han generado hasta un +80% de leads (B2C) en varios tests AB.

• Pantallas de apps en gran consumo (B2C) cuyo copy apelaba a una mera y formal descripción del servicio tenía mejor rendimiento que nuestra variante que apelaba a lo “guay” que era apuntarse a nuestro programa de fidelidad (-12% de registros).

• Títulos de páginas principales de sitios web (B2C) en los que una descripción gris y correcta de la empresa conducía al usuario a interactuar con el buscador en mayor medida (+27% de tasa de search) que “el típico copy molón”

¿Puede ser que sencillamente no se acertara con el copy? Claro. ¿Puede ser que sencillamente sea una mera cuestión de sectores y tipología de usuario? Faltaría más. Sin embargo, detecto que este comportamiento hacia lo descriptivo y directo está generando un impacto estadísticamente significativo en muchas y muy diversas industrias B2C (usuario final).

Por suerte, tenemos pruebas en las dos direcciones: cambiar hacia descriptivo o moverte hacia copy emotivo genera en un importante porcentaje de veces la victoria al copy más simple y directo al hueso. ¿Las causas? quizá es que vamos a toda velocidad en dispositivos mobile y apenas leemos… no tengo causas probables de este fenómeno.

Aprendizaje clave 1/5: Prueba en 2025 una comunicación más directa y descriptiva y sobre todo que explique al usuario qué hay al otro lado del clic. Esto puede mejorar significativamente el rendimiento de tu activo digital.

2. Personalización y complejidad

Ofrecer productos que el usuario necesita en el momento preciso en función de su contexto ha sido una de las grandes promesas en el negocio digital y aunque hay grandes avances al respecto con herramientas como DynamicYield, Optimizely o soluciones propias, la cuestión de la personalización guarda una complejidad propia más allá de la técnica.

En este año hemos trabajado en iniciativas vinculadas a la personalización online como la que muestro en la siguiente imagen de la app de Just Eat (no trabajamos con ellos, solo ejemplo). Imaginemos que decidimos personalizar la oferta y la categoría en función de la hora del día:

• Por la mañana ponemos productos, restaurantes y categorías más típicas de consumo (dulces, desayunos, entre otros).

• Por la tarde y por la noche ponemos otros productos, restaurantes y categorías propias de estos horarios. Esto no debería ser difícil ya que deberíamos disponer de un histórico de datos apto para ello.

Como buenos amantes de la experimentación online, decidimos lanzar un test AB para poner a prueba el impacto de esta iniciativa que tiene mucho, mucho sentido. Estos fueron los datos:

Sí, había algo más de transacciones, sin embargo, no había una inmensa diferencia entre grupo de control (sin ninguna personalización) y variante (con personalización). No hace falta mencionar que había muestra suficiente, no hubo ningún error de medición ni de implementación y que el análisis del experimento se hizo con este proceso que aplicamos en LIN3S.

¿Qué pasó? Como bien explica Anna Ambrozevich en su canal o Val Swisher y Regina Lynn en su libro “Personalization Paradox” en ocasiones confundimos entregar al usuario “lo que quiere” con generar influencia sobre su consumo habitual para empujar una métrica.

El usuario que entra por la mañana, con gran probabiidad, ya iba a a consumir su café o su desayuno y que se lo pongas a menos de clics de distancia no aumenta el porcentaje de conversión de esa sesión. No estás generando una venta que no iba a ocurrir ya. No estás influyendo en consumo: no estás generando cambios en su comportamiento.

Esto conecta con otra frase gloriosa del libro “Data science for business” cuando habla del retargeting publicitario y de la causalidad: ¿qué está haciendo el anuncio con retargeting? influir en el comportamiento del usuario para aumentar la venta o se está dirigiendo a usuarios que ya les iban a comprar?

Con este dato nos encontramos entonces con otra realidad muy propia del complejísimo mundo de la personalización online:

1. Muchas de las métricas de un programa de personalización son a largo plazo y están fuera del alcance de un test AB. Aplicar un holdout test es el camino.

2. Para generar impacto, la personalización debe influir en el comportamiento del usuario hacia comportamientos que no iba a realizar inicialmente.

3. La dictadura del dato: independientemente del resultado se decidió lanzar a producción debido a que, desde luego, existe un valor más allá de las métricas y del test AB. Hacer que el usuario encuentre antes lo que ya buscaba tiene un valor difícil de capturar en una herramienta de analítica.

Aprendizaje clave 2/5: tus iniciativas de personalización deben influir en una acción que el usuario no iba a hacer a priori (y ahí está la dificultad de esta disciplina) y que aporta un valor en el negocio. Ante este escenario, prepárate para comportamientos antintuitivos.

3. Pricing y clustering

Existen modelos de negocio, especialmente en SaaS o gaming en el que puedes encontrar distintas dinámicas para la introducción de precio y del depósito de vidas para, por ejemplo, continuar jugando.

Candy Crush Saga es un ejemplo perfecto para ello. Tendríamos un primer bundle por 1,99 €, una oferta semanal de 0,99 €, una oferta diaria por 3,99 € y dos más por 1,99 € y 7,99 €. Este juego ofrece distintas opciones de revenue para poder adaptarse a los usuarios.

Con la suficiente data, Candy Crush Saga podría crear un sistema de precio dinámico basado en datos pasados y esto podría mejorar la rentabilidad del proyecto en líneas generales. Sin embargo, para hacer esto necesitamos entender muy bien qué clase de clusters tenemos y para ello, aplicar modelos como DBScan puede ser buena práctica.

En la siguiente imagen, veis 4 grupos en total basados en el promedio de tiempo de sesión (y) y el dinero que se introduce en la plataforma en cuestión (x). En este caso se diferencian cuatro grupos una vez se aplica DBScan:

Cuando realizamos este análisis (con otro cliente con el que trabajamos) nos dimos cuenta de que habíamos subestimado uno de los modelos de pricing, ya no solamente por el hecho de que era uno de los más usados (eso ya se sabía), sino que dicho método en cuestión esta directamente relacionado con el consumo de funcionalidades extra (DLC), como se ve en la siguiente imagen:

El diagnóstico: cuando se realiza un proceso de dynamic pricing no solo es útil contar con análisis histórico, sino también haber realizado un ejercicio de clustering con métodos como K-means, DBScan y Optics. Gracias a eso, podemos ubicar el precio que toca al usuario que toca.

¿Cuál es entonces el aprendizaje a nivel UX?

Aprendizaje clave 3/5: Diseño, producto y analítica avanzada deben ir de la mano. Las preguntas han cambiado y así es como debemos empezar a tener encuentros entre distintos campos y áreas (con el dato bajo el brazo). Si quieres aplicar precios dinámicos no basta con realizar un sistema que aprenda de datos históricos: necesitas segmentar con métodos avanzados si quieres acertar.

4. Findability

En negocios tipo SaaS o con un gran volumen de información, no puedes demeritar el valor de atacar “findability”. Este concepto, en esencia, apunta a lo fácil que es encontrar aquello que se pretende buscar.

Exponer el buscador y que este gane protagonismo en URL clave como, por ejemplo, la home o las páginas de destino es algo muy útil. Cambios como los que ves en la siguiente imagen son muy obvios.

Cambios así han mejorado la tasa de visualización de productos en tasas de hasta un +40 %, lo cual, hemos detectado que mejora sustancialmente el consumo de productos, tiempo medio de sesión, entre otros. En esta imagen puedes ver los datos reales de un test AB lanzado en 2024 en el que se mejora un buscador y aumenta en un +13% la visualización de productos.

Es importante igualmente detectar estos incrementos una vez se lanzan a producción: ¿acaso no puede haber falsos positivos en un test AB? una manera interesante de evaluarlo es con un análisis avanzado de series temporales que detecta la significancia estadística antes y después del cambio.

Obvio disclaimer: ¿modificar un buscador en la home puede mejorar la findability? No necesariamente. Independientemente de que contengas la muestra necesaria puedes estar comiéndote un novelty effect de campeonato. Esto puede provocar falsos positivos y un coste de oportunidad tremendo si no se detecta. Por ello, análisis posteriores sobre la métrica objetivo son obligatorios.

Independientemente de ello, ¿esto redunda en ventas o más revenue? en el marco de un test AB, como también pasa en el caso de la personalización online, puede llegar a pasar inadvertido el efecto de un cambio en páginas lejanas al evento final de conversión, lo cual no quita que debas tener en cuenta dichas métricas en materia de análisis.

Aprendizaje clave 4/5: No debes infravalorar el efecto de bola de nieve positivo o negativo que puede provocar un cambio sutil o grande en tu sitio web, aunque apunte indirectamente en ventas.

5. Los funnels

Este 2024 hemos tenido una serie de discusiones con analistas digitales ante la siguiente situación: un test ABC en el que se hace una modificación pequeña en una página concreta (imagina, por ejemplo /cart/) en dos de los grupos (B y C) para evaluar si hay un impacto significativo en las transacciones finales si lo comparas con control (A).

En esta imagen puedes ver lo que de alguna manera hace un test ABC: se modifica un elemento de una pantalla concreta, sin embargo, el resto de las pantallas sigue exactamente igual. Las páginas de checkout son las mismas entre los tres grupos.

En este test ABC, lógicamente, se medía también si el usuario avanzaba a la siguiente pantalla (begin_checkout) y aquí es donde viene la película de verdad: La visión de funnel como un embudo en el que si añades más usuarios a un extremo saldrán más por el otro lado es falso.

El usuario bien puede avanzar debido a que has mejorado la ubicación del botón o el diseño integral del carrito, pero eso no tiene por qué incidir en las transacciones. Es un clásico ver cómo una variante genera más begin checkouts que el grupo de control pero genera un número similar de purchases (y sí, el volumen de la muestra y el ciclo de compra están contemplados).

El motivo por el que sucede esto es que has tocado de forma satisfactoria una tecla (sí, hay más begin checkouts) que al usuario no le afectaba en su flujo de compra. Es decir, no le generaba ningún tipo de fricción negativa que afectara de manera causal a la venta.

Sé lo que estás pensando: "Vale, pero entonces busquemos por qué el usuario más adelante no compra finalmente aún metiendo más usuarios". Eso es una falacia. No pasa nada. Piensa que lo que le sucede al grupo de control y a la variante es exactamente igual en los pasos siguientes a begin checkout, es decir, aquello que sucede en nuestra variante también sucede en el grupo de control, por ende, no se puede inferir que eso que encuentres genera diferencias concretas en variante y no en control (es decir, afecta igual).

Importante: No se trata de un error de medición. Se trata de entender que cuando trabajamos con un producto digital investigar y encontrar buenos puntos de mejora y/u oportunidades es lo que de verdad hace que se mueva la aguja.

👉🏼 En este ejemplo, el problema o la oportunidad no estaba en el carrito. No estaba probablemente en esa pantalla. Estaba en otra página del sitio web, si es que hay algo.

Aprendizaje 5/5: CRO es un trabajo rico que cubre desde aspectos muy técnicos hasta aspectos tan complejos y antiintuitivos como el propio ser humano. A fin de cuentas, estamos lidiando con comportamiento de consumo, por lo que la analítica en estos contextos te pone ante situaciones así, en las que debes reinterpretar un básico simplista del marketing digital: el funnel.

Si haces CRO en 2025, prepárate para situaciones así.

6. “Esos botones no convierten más”

En 2024 se hizo popular un estudio que apuntaba a que los botones redonditos convertían mucho más que los botones rectangulares. Tanto es así, que se adjuntaban otras fuentes que hacían el mismo diagnóstico.

¡Qué peligroso es no leer! Por suerte, varios expertos del gremio bucearon en esos estudios y, en esencia, llegaron a la siguiente conclusión: esos estudios no tienen muestra suficiente o el diseño del experimento es cuanto menos cuestionable.

Es decir, no hay evidencia de que los botones redondos conviertan mejor. Fake news.

Tanto es así, que Jurjen Jongejan se divirtió ejecutando un test con la suficiente muestra para demostrar (aunque obviamente un único test no es prueba suficiente) que no era así. Omoda es uno de los retailers más grandes de países bajos.

Pensar y defender que un botón redondo genera más clic que uno rectangular es, sencillamente, una muestra de que quién lo dice no ha enfrentado sus suposiciones a comportamiento con datos y análisis (con el tremendo error a largo que eso significa).

Aprendizaje Bonus Track: no te creas todo lo que ves en LinkedIn o Twitter. De hecho, tampoco te creas lo que lees aquí. La duda bien utilizada es un importante motor de crecimiento. UX es un fantástico oficio que necesita urgentemente de un mayor rigor estadístico para no caer en falacias como esta.

Y hasta aquí la última edición de 2024.

En 2025 seguiremos, seguramente conectando en mayor medida la parte más técnica con la parte de UX: dos mundos que conectan ciencia y arte que deben ir más de la mano.

En 2025, trabajaremos para que eso sea así.

Felices fiestas.

Parece que a muchas personas les ha resonado esta frase que he ido repitiendo durante este año en algunos posts en LinkedIn y Twitter (me niego a llamarla X). Todo este afán por la técnica proviene de otra frase mía que no ha cuajado tanto porque quizás no la he voceado en los foros correctos: “El estratega deberá ser más analista y el analista más estratega”.

Leanalytics nace con el propósito de acercar ciertos elementos técnicos y bajarlos al suelo. En esta 15ª edición hablo de K-means, un algoritmo no supervisado muy conocido en el ámbito de la ciencia de datos que, sin duda, todo especialista en CRO o analista debería conocer.

Ahora sí, empieza K-means: de la teoría a la práctica.

Espero que os guste.

Esto es lo que vamos a ver en esta edición:

1. Qué es

   1. La distancia o similitud

   2. Linkage

   3. Definición de k-means

2. K-means paso a paso

3. Cómo seleccionar k

4. Caso kaggle

5. Evaluación del modelo y caso y Caso GA4

¿Qué es K-means?

La distancia o similitud

Antes de nada, el agrupamiento no supervisado persigue un objetivo muy claro: identificar patrones o grupos en los datos basándose en la similitud de sus características. Esto se consigue a partir de:

• Un conjunto de objetos descritos por un vector.

• Una métricca que nos defina el concepto de “similitud”

Este concepto de similitud es fundamental. En esencia, es la forma de cuantificar cómo de similares son dos objetos, variables o puntos en el espacio. Consideraremos que habrá similitud cuando cualquier distancia contenga las tres condiciones siguientes:

1. No negatividad: la distancia siempre debe ser positiva.

2. Simetría: la distancia de la A la B debe ser la misma que de la B a la A.

3. Desigualdad triangular: la distancia debe coincidir con la idea de que es el camino más corto entre los dos puntos.

Con estas tres condiciones, tendremos la definición de lo que llamamos distancia o similitud.

Linkage

El principio de un algoritmo aglomerativo es que se obtienen todos los datos como algo individual hasta que se obtienen una serie de grupos, es decir, sucede el agrupamiento de objetos.

Para construir esos grupos se necesita entender el concepto de distancia y el concepto de enlace (linkage). Algunos de los criterios clave, son:

• Simple linkage: Utiliza la distancia mínima. Muy sensible entonces al ruido en el dataset.

• Complete linkage: Utiliza la distancia máxima. No es tan sensible al ruido en el dataset pero entonces es más sensible a los outliers. No obstante, puede dar en ocasiones mejores resultados que simple linkage.

• Average linkage: Utiliza la distancia media. Es un método que intenta coger lo mejor de los dos anteriores y resolver sus problemas sin conseguirlo.

• Centroid linkage: La distancia entre dos grupos será la distancia entre sus dos centroides. Es decir, la posición central de cada grupo.

Aunque K-means no utiliza directamente criterios de enlace como el simple, complete o average linkage, comparte el mismo principio de medir distancias para agrupar objetos similares. Sin embargo, en lugar de calcular distancias entre puntos o grupos, K-means utiliza un enfoque centrado en los centroides.

Un centroide es el punto medio de un grupo. Se calcula como la media de todas las características de los datos dentro del grupo. En cada iteración, K-means ajusta los centroides y reasigna los puntos al grupo más cercano, optimizando así la similitud dentro de cada grupo.

Definición de k-means

K-means es un algoritmo de agrupamiento no supervisado que sirve para dividir un dataset en "clusters" basados en las similitudes de sus características. A diferencia de otros métodos, este algoritmo requiere que decidas previamente cuántos grupos (k) quieres formar.

Por ejemplo, si estás segmentando clientes en función de su comportamiento de compra, podrías elegir dividirlos en tres grupos (k=3): compradores frecuentes, ocasionales y nuevos. El algoritmo, entonces, identificará los grupos asignando cada cliente al grupo más cercano, calculado en función de su posición en el espacio de datos.

K-means paso a paso

1. Seleccionar K

Antes de comenzar, seleccionaremos el número de clusters k, que determina cuántos grupos queremos identificar en los datos.

2. Calcular centroides

Asignaremos cada observación xi​ al cluster Ct cuyo centroide inicial ct esté más cerca, según una métrica de distancia (por ejemplo, la distancia centroide).

3. Nuevo cálculo

Una vez que las observaciones han sido asignadas a sus respectivos clusters, recalcularemos los centroides de cada cluster como el promedio de las observaciones asignadas.

4. Criterio de parada y cambio

Como criterio de parada, evaluaremos si las asignaciones de las observaciones a los clusters han cambiado. El algoritmo finalizará cuando los cambios sean mínimos o cuando la suma de las distancias cuadradas dentro de los clusters deje de mejorar significativamente.

5. Repetir

Repetiremos los pasos 2, 3 y 4 hasta que los clusters se estabilicen y ya no haya cambios significativos en las posiciones de los centroides.

Cómo seleccionar k

Puede ser común pensar que k puede escogerse de forma arbitraria, pero no tiene por qué ser así. De hecho, la manera idónea es escoger el número de k óptimo en función de las caracter´sticacs del dataset.

El más conocido es el método Elbow, que te presento a continuación:

El método Elbow es una técnica que se utiliza para determinar el número óptimo de clusters en K-means. Se basa en analizar cómo cambia la suma de distancias cuadradas intra-cluster (inercia) a medida que aumentamos el número de clusters. El objetivo es identificar un "codo" en la gráfica, donde el decremento de la inercia comienza a ser más lento.

El codo estaría en 3, ya que es el punto donde la pendiente de la curva comienza a disminuir significativamente.

• De k = 1 a k = 3, hay una enorme caída de la inercia. Esto indica que agregar más clusters (k) mejora considerablemente la compactación dentro de los grupos.

• De k = 3 en adelante, la caida de la inercia es mucho más gradual. Esto indice que agregar más clusters no mejora tan significativamente el modelo.

Con este dataset, entonces, el número óptimo de grupos es de 3.

Caso Kaggle

En este dataset puedes descargar un CSV que es el que uso para ejecutar el modelo k-means para encontrar unos sub-grupos a partir, en este caso, del scoring de gasto y los ingresos anuales.

Lógicamente, se han formado 5 grupos a raíz de la ejecución del método elbow y el resultado, ante esas dos variables fue de cinco, como se ve en la siguiente imagen:

Para ejecutar estos dos elementos, deberíamos ejecutar estos dos códigos:

Evaluación del modelo y Caso GA4

Pero… el modelo debe evaluarse.

No basta con que una gráfica luzca bien.

En esta profesión nada se mide a ojímetro. Todo tiene una métrica, un parámetro: un dato.

Sin embargo, la evaluación del modelo lo mostraré con un caso práctico en Dadadata. Jorge Carrión, gran profesional y mejor persona, ha abierto su Substack a otros profesionales que solemos crear contenido por una buena causa: AYUDAR A VALENCIA POR LA CRISIS DE LA DANA. Este contenido estará solo disponible si te suscribes a su canal (aquí más info sobre esto).

Solo si te suscribes en dadadata (por una buena causa) recibirás el 8 de diciembre de 2024 el contenido sobre evaluación del modelo K-means en el marco de un caso real. Esto es fundamental y es el elemento crítico para dar por bueno un modelo de K-means.

¡Y hasta aquí puedo leer!

Este es el último glosario que haré sobre esta temática. Detrás quedan 153 términos en total divididos por glosario de datos o glosario de diseño y esta edición, en la que nos centramos en el dominio tecnológico.

La tecnología es algo básico. Ahora estás leyendo estas líneas por una plataforma llamada Substack (sustentada con tecnología). Todo acción de marketing se sustenta en tecnología y entenderla te convertirá en mejor profesional. En esta 14ª edición se muestra un glosario de 51 conceptos de CRO orientado a tecnología dividido en tres apartados: profesionales entry-level, intermediate y advanced.

Ahora sí, empieza El Glosario de CRO orientado a tecnología

Espero que os guste.

Antes de empezar, en LIN3S buscamos a personas para el área de CRO, específicamente para dos posiciones: CRO developer y CRO specialist. ¿Quieres unirte? ¡Te esperamos!

Conocer una definición no significa saber aplicarla. Sin embargo, por algún sitio hay que empezar. Aquí tienes un listado de 51 términos divididos en función de la seniority del perfil de CRO, es decir, lo que creo que un entry-level, intermediate y advanced debería conocer.

A continuación, el glosario orientado a tecnología.

Entry-level

1. Client-Side Testing: Proceso de ejecución de experimentos en el navegador del usuario final, utilizando principalmente JavaScript para modificar la interfaz y el contenido después de la carga inicial de la página. Permite pruebas rápidas y visuales, aunque puede introducir problemas de rendimiento y latencia si no se gestiona bien. Se debe asegurar una sincronización precisa para evitar flickering.

2. Server-Side Testing: Ejecución de tests en el servidor antes de enviar el contenido al cliente. Permite cambios estructurales y de contenido completos, independientemente de las limitaciones del navegador. Ideal para experimentos que afectan la lógica de negocio, ya que mantiene la integridad de los datos y mejora la seguridad en aplicaciones con datos sensibles.

3. JavaScript Rendering: Proceso mediante el cual el navegador ejecuta JavaScript para renderizar o actualizar dinámicamente elementos en el DOM (Document Object Model). En experimentos de CRO, permite realizar cambios de forma reactiva en la interfaz, aunque puede aumentar la carga en el cliente si no se optimiza adecuadamente.

4. APIs (Application Programming Interfaces): Permiten la comunicación entre sistemas, ofreciendo acceso controlado a datos y funciones de back-end. Son esenciales en experimentación, ya que facilitan el intercambio de información en tiempo real y habilitan integraciones en múltiples aplicaciones o plataformas.

5. Cache Busting: Técnica utilizada para invalidar y actualizar recursos almacenados en caché del navegador, como archivos de imagen, scripts o estilos CSS, asegurando que los usuarios reciban la versión más reciente tras cambios o actualizaciones.

6. Single Page Application (SPA): Aplicación web que carga una única página HTML y actualiza dinámicamente el contenido según sea necesario. Las SPAs requieren un manejo cuidadoso de rutas y eventos de usuario en experimentos, dado que los cambios de contenido y estados se gestionan desde el cliente. Id con cuidado si experimentáis aquí.

7. Cookie: Fragmento de datos almacenado en el navegador que permite la persistencia de la exposición de un usuario a una variante específica durante un periodo. Utilizada en experimentos para rastrear la asignación a variantes.

8. Session Storage: Almacenamiento temporal de datos en el navegador que persiste solo durante una sesión de usuario. En experimentos, asegura que el usuario permanezca en la misma variante durante la sesión actual, sin continuidad en visitas futuras.

9. Local Storage: Almacenamiento persistente de datos en el navegador sin una expiración automática. No debe usarse para datos sensibles, ya que es accesible a través de JavaScript en el navegador.

10. QA (Quality Assurance): En el marco de CRO, QA es el proceso que asegura que los tests funcionen correctamente en todos los entornos de usuario, incluyendo distintos navegadores, dispositivos y sistemas operativos.

11. Lazy Loading: Técnica que retrasa la carga de contenido hasta que se necesita, reduciendo el tiempo inicial de carga de la página.

12. User-Agent Detection: Proceso de identificación del dispositivo y navegador que el usuario está utilizando, crucial en client-side testing para asegurar la compatibilidad de variantes en diferentes entornos. Herramientas como VWO permiten descargar información de este tipo.

13. Segmentation: Técnica básica de dividir a los usuarios en grupos específicos en función de características (ubicación, dispositivo, comportamiento) para crear tests para públicos más específicos.

14. Event Listeners: Elementos de código que capturan las interacciones del usuario (como clics o scroll) en el navegador.

15. Snippet: Fragmento breve de código que se inserta en una página web para realizar tareas específicas, como capturar eventos de usuario o aplicar cambios visuales en tests A/B.

16. Tag Management: Sistema de etiquetado que organiza y controla las etiquetas de seguimiento y scripts en un sitio web. Vital para un proyecto de CRO en entorno web.

17. Flickering: Efecto visual que ocurre cuando un usuario ve brevemente la versión de control de una página antes de que se cargue la variante.

Intermediate

1. Experiment Bucketing: Es el proceso de asignar usuarios a una variación de una flag de acuerdo con las reglas de la misma. Los SDK de herramientas como Optimizely evalúan los ID de usuario y sus atributos para determinar qué variación deberían ver.

2. Feature Flagging: Mecanismo que permite habilitar o deshabilitar funcionalidades sin necesidad de despliegues completos. Facilita la experimentación, ya que permite realizar cambios en tiempo real y probar nuevas funcionalidades de manera segmentada.

3. API Rate Limiting: Restricción en el número de solicitudes permitidas a una API en un periodo específico.

4. Data Anonymization: Proceso de eliminación de información identificable de los datos de usuario, asegurando la privacidad y cumpliendo con regulaciones de protección de datos. En experimentos, permite analizar comportamiento sin comprometer la seguridad de los datos personales.

5. Roll-out: Lanzamiento habitualmente total que permite desplegar variantes antes de un lanzamiento completo al 100 % de los usuarios.

6. DataLayer Integration: Uso de capas de datos que conectan la información del usuario con sus interacciones en el sitio, permitiendo segmentar los experimentos de manera más interesante.

7. Dynamic Allocation Algorithms: Algoritmos (como Thompson Sampling) que ajustan dinámicamente la distribución del tráfico hacia variantes basándose en el el número de conversiones en tiempo real.

8. SDK: Conjunto de herramientas y bibliotecas que permite a los desarrolladores integrar funcionalidades específicas en aplicaciones.

9. Remote config: Herramienta de Firebase que permite modificar el comportamiento y la interfaz de una app sin necesidad de actualizarla en la tienda. En CRO, Remote Config puede generar tests A/B y hasta elementos de personalización online.

10. Parámetros: En el contexto de Firebase, permiten personalizar la experiencia del usuario sin necesidad de actualizaciones en la tienda y pueden segmentarse por condiciones, como ubicación geográfica, versión de la app, y propiedades de usuario de GA4.

11. Mutually excluded experiments: Cuando lanzas dos tests AB al mismo tiempo y modificas la su configuración para que los que participen en un grupo no participen en el otro.

12. Data retention policies: Normas que definen el tiempo que los datos de usuario se almacenarán en un sistema.

13. Houldout group test: Test que sirve para comparar dos o más experiencias con métricas a largo plazo. Habitualmente implica que se ha hecho un test AB previamente para evaluar impacto en métricas más cortoplacistas.

14. Holdback Group: Segmento de usuarios que no recibe ningún cambio (grupo de control) y actúa como una base de comparación, habitualmente en holdout group tests.

15. Cross-device tracking: Proceso que permite identificar y rastrear al mismo usuario a través de múltiples dispositivos (móvil, tablet, escritorio), asegurando que reciba la misma variante experimental en todas sus interacciones.

16. Monitorización de tiempo de carga: Herramienta que mide el tiempo de carga y rendimiento de cada variante.

17. Feature Testing: Proceso de prueba de funcionalidades concretas de una app para verificar su efectividad o usabilidad.

Advanced

1. Client Hints: Método que permite al navegador proporcionar información sobre sus capacidades al servidor, permitiendo respuestas optimizadas.

2. Custom Rollbacks: Funcionalidad que permite revertir variantes experimentales sin interrupción si los resultados no son satisfactorios. Con server-side testing en Optimizely, los rollbacks son instantáneos y personalizables, minimizando impactos en la experiencia del usuario.

3. CDP: Integración de una plataforma de datos de clientes (CDP) que centraliza y organiza datos de usuario provenientes de múltiples fuentes. En experimentación, la integración con CDPs permite utilizar datos de cliente para, por ejemplo, personalización avanzada, maximizando la relevancia de cada variante.

4. Audience Segmentation with CDPs: Segmentación de usuarios basada en datos centralizados de una CDP.

5. Data Lake Integration: Integración de un data lake para almacenar datos experimentales y de usuario a gran escala. Permite un análisis avanzado e histórico de experimentos, integrando datos de la CDP y ofreciendo un repositorio central para el análisis de tendencias y el desarrollo de estrategias de largo plazo.

6. Real-Time Bidding Integration: Integración con sistemas de bidding en tiempo real (RTB) para experimentos que personalizan la experiencia publicitaria en función de los datos de usuario.

7. Synthetic Data: Método que construye un grupo de control simulado combinando datos históricos, usado en experimentación para evaluar cambios en entornos donde el control directo no es posible.

8. Multi-touch attribution: Análisis que asigna valor a cada punto de contacto en el recorrido del usuario.

9. Google Cloud Data Fusion: Herramienta de integración de datos de Google Cloud que automatiza los flujos de ETL entre diversas fuentes, incluyendo CDPs y Data Lakes.

10. Vertex: Plataforma de Google Cloud que permite el desarrollo de modelos de machine learning avanzados para segmentación y personalización en experimentación.

11. BigQuery ML: Herramienta de machine learning integrada en BigQuery que permite a los analistas y científicos de datos crear y entrenar modelos de aprendizaje automático directamente en bases de datos SQL sin mover los datos.

12. Muestreo estratificado: Método en el cual la población se divide en estratos homogéneos según una o más variables clave. Posteriormente, se seleccionan muestras aleatorias de cada estrato proporcionalmente al tamaño del estrato en la población total. Este enfoque reduce la varianza dentro de cada estrato y aumenta la precisión del estimador.

13. Muestreo por conglomerados: Procedimiento que agrupa a la población en conglomerados (subgrupos heterogéneos) basados en características naturales o geográficas, y luego selecciona al azar algunos conglomerados para estudio completo. Este método es eficiente en grandes poblaciones y reduce costes, aunque aumenta la varianza entre conglomerados.

14. AutoML: Herramienta de Google Cloud que permite automatizar la creación y optimización de modelos de machine learning sin requerir conocimientos avanzados en programación.

15. DoWhy: Librería de Python desarrollada para facilitar el análisis causal y la inferencia en experimentos y estudios observacionales. DoWhy integra métodos estadísticos y de machine learning para modelar relaciones causales y analizar los efectos de intervenciones, permitiendo a los investigadores establecer hipótesis causales y probarlas con rigor.

16. Pyro: Una librería de deep probabilistic programming desarrollada por Uber que permite modelar relaciones causales complejas mediante métodos probabilísticos y machine learning

17. EconML: Librería de Python desarrollada por Microsoft que proporciona herramientas avanzadas para el análisis causal aplicado, especialmente en contextos económicos y de ciencias sociales.

Espero que te haya gustado este listado. Como ves llega un punto en el que la tecnología se basa no solamente en que los experimentos salgan bien, sino también de que los datos generados lleguen correctamente y luego poder ser transformados en el formato que toque.

En las ediciones 015 y 016 trataremos un tema que llevo año y medio metiéndome y creo que ya estoy preparado para escribir sobre él: causalidad.

Nos vemos en dos semanas.

En todo caso, se practica y se aprende a navegar en sus mareas. De la misma manera sucede con CRO, por eso en LIN3S a la fase de implementación la llamamos “Practice”.

El diseño es un pilar igual de fundamental que la de datos para un correcto proyecto de experimentacón online, por ello, en esta 13ª edición se muestra un glosario de 51 conceptos de CRO orientado a diseño dividido en tres apartados: términos que deben conocer profesionales entry-level, intermediate y advanced.

Ahora sí, empieza El Glosario de CRO orientado a diseño

Espero que os guste.

Antes de empezar, en LIN3S buscamos a personas para el área de CRO, específicamente para dos posiciones: CRO developer y CRO specialist. ¿Quieres unirte? Haz clic encima de la imagen y mira las oportunidades que tenemos en estos momentos.

Conocer una definición no significa saber aplicarla en distintos contextos. No obstante, por algún sitio hay que empezar. Aquí tienes un listado de 51 términos divididos en función de la seniority del perfil, es decir, lo que creo que un entry-level, intermediate y advanced debería conocer.

Si quieres ver el Glosario de CRO orientado a data puedes verlo aquí.

A continuación, el glosario orientado a diseño.

Entry-level

1. User Interface (UI): Estructura visual y de interacción de todos los elementos en una plataforma digital que facilita la comunicación entre el usuario y el sistema, diseñándose con principios de usabilidad y accesibilidad para optimizar la eficiencia y satisfacción del usuario.

2. User Experience (UX): Enfoque integral que abarca todas las interacciones del usuario con el producto, evaluando factores de usabilidad, utilidad, estética y accesibilidad para generar experiencias consistentes y alineadas con las expectativas y emociones del usuario.

3. Visual Hierarchy: Organización intencional de elementos gráficos y textuales basada en principios de percepción visual, como tamaño, contraste y proximidad, para dirigir la atención del usuario hacia componentes críticos de conversión en el orden deseado.

4. Color Psychology: Uso de teorías psicológicas sobre el impacto emocional y conductual de los colores, aplicado para influir en la percepción del usuario y promover respuestas específicas como confianza, urgencia o calma.

5. Whitespace/Negative Space: Estrategia de diseño que utiliza el espacio vacío para separar elementos, reduciendo la carga cognitiva y mejorando la claridad y percepción estética, optimizando la facilidad de lectura y navegación.

6. Typography: Selección y combinación de fuentes y estilos tipográficos que influyen en la jerarquía visual, legibilidad y tono comunicacional del diseño, facilitando la comprensión y reforzando la identidad de la marca.

7. Accessibility: Conjunto de prácticas de diseño que garantizan que una interfaz pueda ser usada por personas con diversas capacidades, incluyendo alternativas visuales y controles adaptables, cumpliendo con normativas de accesibilidad (e.g., WCAG).

8. Consistency in Design: Uso sistemático de patrones visuales, terminología y estructuras de navegación a lo largo de una interfaz para reducir el esfuerzo de aprendizaje del usuario y promover una experiencia de uso predecible y confiable.

9. Hick's Law: Principio de usabilidad que establece que el tiempo de decisión aumenta con el número de opciones presentadas, siendo clave para estructurar menús y elementos interactivos de manera que faciliten la toma de decisiones rápida y eficiente.

10. Gestalt Principles: Teorías de percepción visual que explican cómo los humanos organizan y perciben patrones en elementos visuales, aplicadas en diseño para estructurar información de manera intuitiva y coherente.

11. Affordances: Propiedades percibidas de los elementos de diseño que sugieren al usuario cómo deben usarse, integrando señales visuales (e.g., sombreado, iconografía) que faciliten la interacción intuitiva y reduzcan la ambigüedad.

12. Visual Feedback: Mecanismos visuales inmediatos que indican al usuario que su interacción ha sido reconocida (e.g., cambio de color en botones), mejorando la comprensión de la interfaz y reduciendo la incertidumbre en la navegación.

13. Anchoring Effect: Sesgo cognitivo por el cual la primera información recibida establece una referencia que influye en decisiones posteriores, aplicable en el diseño para guiar percepciones sobre precios, valor o calidad.

14. Proximity Principle: Ley de percepción visual que afirma que los elementos cercanos entre sí son interpretados como relacionados, permitiendo estructurar el contenido de manera que se facilite su comprensión inmediata y sin esfuerzo.

15. Fitts' Law: Principio de interacción que establece que el tiempo para alcanzar un objetivo depende de su tamaño y distancia en pantalla, informando decisiones de diseño en términos de accesibilidad y disposición de elementos interactivos.

16. Peak-End Rule: Teoría psicológica que postula que la experiencia de un usuario se basa principalmente en el momento de mayor intensidad emocional y en el final de la interacción, lo cual es fundamental para diseñar flujos de usuario memorables y satisfactorios.

17. Behavioral Economics: Campo que combina economía y psicología para entender cómo y por qué los usuarios toman decisiones, aplicándose en diseño para estructurar elementos de manera que influyan en el comportamiento del usuario, como en la elección de productos o en la disposición de precios, maximizando la conversión sin manipulación.

Intermediate

1. Cognitive Load Theory: Teoría que aborda la capacidad limitada del cerebro para procesar información, recomendando simplificar las interfaces para reducir la fatiga cognitiva y optimizar la retención.

2. Zeigarnik Effect: Fenómeno por el cual las tareas incompletas se recuerdan mejor que las completadas, aplicado en diseño para motivar la finalización de procesos como formularios o suscripciones.

3. Heuristic Evaluation: Método de análisis basado en principios de usabilidad que permite identificar problemas en la interfaz, proporcionando insights para mejorar la experiencia del usuario.

4. User Flow Mapping: Creación de diagramas de navegación que representan el recorrido del usuario dentro del sitio, identificando barreras y puntos críticos para optimizar la experiencia y facilitar la conversión.

5. Information Scent: Teoría que explica cómo los usuarios siguen señales (visuales y textuales) para anticipar si un enlace o contenido los llevará al objetivo deseado, mejorando la navegación intuitiva.

6. Mental Models: Representaciones internas y expectativas previas de los usuarios sobre el funcionamiento de una interfaz, usadas en diseño para reducir fricciones y mejorar la usabilidad.

7. Framing Effect: Sesgo cognitivo en el que la presentación de información afecta la percepción del usuario, influenciando sus decisiones y reacciones, útil en la estructura de mensajes y precios.

8. Chunking: Técnica de agrupación de información en bloques manejables que facilita la comprensión y retención del contenido, reduciendo la carga cognitiva en el usuario.

9. Triggers (Nir Eyal's Model): Elementos diseñados para incitar una acción en el usuario. External Triggers se presentan como estímulos externos (notificaciones, mensajes), mientras que Internal Triggers se originan en el usuario, como emociones o necesidades, fomentando la interacción autónoma.

10. Behavioral Triggers and Loops: Ciclo de diseño que busca establecer hábitos mediante la creación de un loop de activación, acción, recompensa y repetición, formando un ciclo de compromiso a largo plazo.

11. Loss Aversion: Sesgo cognitivo en el que las personas tienden a preferir evitar pérdidas antes que obtener ganancias, aplicado en CRO para diseñar incentivos que eviten la sensación de pérdida.

12. Scarcity Principle: Estrategia que utiliza la percepción de escasez (e.g., "últimas unidades") para aumentar el valor percibido y motivar la conversión, basándose en la urgencia y el miedo a perder una oportunidad.

13. Paradox of Choice: Teoría que establece que demasiadas opciones pueden reducir la satisfacción y la decisión del usuario, recomendando limitar las alternativas para mejorar la conversión.

14. Foot-in-the-Door Technique: Técnica de persuasión que consiste en solicitar un pequeño compromiso inicial (e.g., suscripción gratuita) para luego facilitar la aceptación de compromisos más grandes, como una compra.

15. Nudge Theory: Enfoque de diseño que emplea pequeños "empujes" o sugerencias para influir en las decisiones del usuario sin eliminar opciones, optimizando su comportamiento de manera sutil y efectiva.

16. Recency Effect: Tendencia a recordar mejor los últimos elementos de una lista o secuencia, aplicable en diseño para estructurar contenido y CTA al final de un recorrido o interacción.

17. Decoy Effect: Estrategia de CRO en la que se introduce una tercera opción menos atractiva que guía al usuario hacia una de las dos opciones restantes, influenciando la elección y maximizando la conversión.

Advanced

1. Design Tokens: Elementos básicos (colores, espaciados, tipografía) convertidos en valores reutilizables dentro de un design system, facilitando la consistencia visual y la escalabilidad en múltiples plataformas.

2. Dual-Process Theory (Kahneman): Teoría de economía del comportamiento que explica cómo el cerebro utiliza dos sistemas de pensamiento (rápido e intuitivo vs. lento y racional), fundamental para diseñar interfaces que guíen decisiones intuitivas y minimicen la carga cognitiva.

3. Atomic Design: Metodología que estructura componentes de diseño en niveles jerárquicos (átomos, moléculas, organismos, plantillas y páginas), promoviendo la consistencia y escalabilidad en el desarrollo de interfaces.

4. Game Mechanics in UX: Uso de mecánicas de juego (e.g., recompensas, desafíos, progresión) para incrementar el compromiso y fomentar la lealtad del usuario en la interfaz, aplicando teoría de juegos para estructurar experiencias.

5. Cobra Effect: Fenómeno donde una solución bien intencionada produce efectos adversos no previstos, importante en CRO para anticipar respuestas no deseadas a cambios en la interfaz y evitar optimizaciones contraproducentes.

6. Fogg Behavior Model: Modelo que describe cómo el diseño puede influir en el comportamiento al ajustar motivación, habilidad y triggers, creando interfaces que inciten a la acción de manera natural y sin fricciones.

7. Nash Equilibrium in UX Design: Principio de teoría de juegos aplicado al diseño, en el que las decisiones de los usuarios se equilibran sin incentivos para cambiar sus elecciones, útil para diseñar interacciones equilibradas en plataformas colaborativas.

8. Modularity in Design Systems: Estructura que permite la creación de componentes independientes y reutilizables dentro de un design system, facilitando la adaptación y personalización sin comprometer la coherencia visual.

9. Prospect Theory (Kahneman y Tversky): Teoría que describe cómo las personas evalúan pérdidas y ganancias, aplicada en CRO para estructurar ofertas y mensajes de manera que maximicen el atractivo de las decisiones percibidas como “ganancia”.

10. Feedback-Driven Iteration: Enfoque de diseño basado en la recopilación continua de feedback del usuario para realizar mejoras progresivas, clave en la evolución de design systems y la optimización de la experiencia.

11. Signaling Theory: Enfoque de diseño que emplea señales visuales para comunicar valor y confianza, influyendo en las decisiones del usuario sobre la calidad o seguridad de una acción, crucial en transacciones en línea y diseño de productos.

12. Efecto Hotelling: Fenómeno de teoría de juegos y economía que explica cómo las opciones tienden a alinearse en competencia, aplicable en diseño para optimizar la diferenciación y posicionamiento de características en productos o servicios.

13. Uncertainty Management in User Flows: Estrategias de diseño que buscan reducir la incertidumbre del usuario en flujos complejos, proporcionando puntos de retroalimentación y simplificación de opciones para mejorar la toma de decisiones y reducir la fricción.

14. Microcopy in UX: Uso de texto breve y directo en elementos específicos de la interfaz (como botones, errores o ayudas) para orientar al usuario y reducir la ambigüedad en la navegación y decisiones.

15. Counterfactual Thinking in UX: Enfoque que analiza cómo el usuario podría reaccionar en escenarios alternativos no experimentados directamente, aplicando hipótesis de diseño para mejorar la toma de decisiones y prevenir errores.

16. Choice Architecture: Estructuración de opciones en la interfaz de usuario para guiar decisiones hacia opciones óptimas, aplicando principios de economía del comportamiento para reducir fricción en la selección y maximizar la conversión.

17. Exploration vs. Exploitation Dilemma: Estrategia de diseño basada en teoría de juegos que equilibra entre ofrecer al usuario opciones nuevas (exploración) y reforzar opciones exitosas (explotación), optimizando la retención y el descubrimiento en la interfaz.

Como estoy dciendo a lo largo de esta serie de glosaros, conocer y cantar como un loro los términos puede hacerlo cualquiera. Usarlos cómo y cuándo tocan va de práctica y es esta la que hace al maestro.

Al final de esta edición entenderás esta frase inicial. Originalmente iba a hacer un único glosario de términos y yo mismo me sorprendí cuando vi que se acumulaban más de 150. Así, he decidido hacer un listado temático en función de cada ámbito del CRO.

En esta 12ª edición se muestra un glosario de 51 conceptos de CRO dividido en tres apartados: términos que deben conocer profesionales entry-level, intermediate y advanced.

Ahora sí, empieza El Glosario de CRO orientado al dato.

Espero que os guste.

Conocer una definición no significa saber aplicarla en distintos contextos. No obstante, por algún sitio hay que empezar. Aquí tienes un listado de 51 términos divididos en función de la seniority del perfil, es decir, lo que creo que un entry-level, intermediate y advanced debería conocer.

Entry-level

1. Exploratory Data Analysis (EDA): Proceso preliminar de análisis de datos que utiliza técnicas visuales y estadísticas para identificar patrones, anomalías y características principales, facilitando la formulación de hipótesis iniciales.

2. Hypothesis Testing: Proceso de contrastar datos observados contra una hipótesis nula para evaluar si se debe rechazar en favor de la hipótesis alternativa, utilizando criterios estadísticos como la p-valor

3. Control Group: Grupo de referencia que no recibe el cambio experimental, utilizado para evaluar el efecto de la intervención mediante la comparación con el grupo tratado.

4. Variant: Versión del experimento con modificaciones aplicadas que se compara con el grupo de control para evaluar su impacto en las métricas objetivo.

5. Conversion Rate: Proporción de usuarios que completan la acción deseada (e.g., compra, registro) en un sitio web, utilizada como métrica clave en experimentos de optimización.

6. Nivel de significancia: Grado de certeza de que un resultado observado no se debe al azar, determinado mediante una prueba de hipótesis, usando un umbral de significancia predefinido (generalmente α = 0.05). Un resultado es estadísticamente significativo si la probabilidad de observarlo bajo la hipótesis nula es menor que este umbral.

7. Confidence Interval: Rango de valores calculado a partir de datos muestrales que, con una alta probabilidad, contiene el verdadero valor del parámetro poblacional. Por ejemplo, un intervalo de confianza del 95% para una media indica que, en el largo plazo, el 95% de los intervalos construidos a partir de diferentes muestras incluirán el valor verdadero de la media poblacional.

8. P-Value: Probabilidad de obtener un resultado igual o más extremo que el observado bajo la suposición de que la hipótesis nula es verdadera.

9. Minimum Detectable Effect (MDE): El efecto mínimo que un experimento puede detectar con una potencia y un nivel de significancia específicos, usado para planificar el tamaño de muestra.

10. Statistical Power: Probabilidad de detectar un efecto verdadero si este existe; un nivel comúnmente aceptado es del 80% o superior para asegurar la robustez de los resultados.

11. Sample Size: Número de observaciones requeridas para alcanzar un nivel de significancia y potencia especificados, determinante en la validez estadística del experimento.

12. Lift: Incremento porcentual en una métrica clave como resultado de la intervención, utilizado para medir el efecto de cambios en campañas y optimizaciones.

13. Rango intercuartílico (IQR): Medida de dispersión que representa la diferencia entre el tercer cuartil (Q3) y el primer cuartil (Q1), cubriendo el 50% central de los datos.

14. One-Tailed Test: Prueba de hipótesis que evalúa si el efecto de la intervención ocurre en una sola dirección (e.g., solo mejora en lugar de empeora).

15. Two-Tailed Test: Prueba de hipótesis que evalúa si el efecto de la intervención se manifiesta en cualquiera de las dos direcciones (mejora o empeora).

16. Outliers: Observaciones que se desvían significativamente de la tendencia general, lo que puede distorsionar las estimaciones y resultados si no se manejan adecuadamente.

17. Sample Ratio Mismatch (SRM): Desajuste en la proporción de asignación de muestras a cada grupo, indicando posibles errores en la aleatorización que pueden invalidar el experimento.

Intermediate

1. Bayesian A/B Testing: Método basado en inferencia bayesiana para evaluar la probabilidad de que una variante sea mejor que el control, proporcionando distribuciones posteriores en lugar de p-valor.

2. Sequential Testing: Técnica que permite monitorear resultados en intervalos continuos durante el experimento, controlando la tasa de error y evitando paradas tempranas incorrectas.

3. Interaction Effect: Fenómeno en el que el efecto de una variable independiente sobre la dependiente depende del nivel de otra variable, indicando efectos combinados no aditivos.

4. Análisis de Distribución: Evaluación de la forma, dispersión y patrones de una variable, usando gráficos y pruebas estadísticas para identificar sesgos y validar supuestos. Fundamental para interpretar diferencias entre grupos en experimentos.

5. Holdout Group: Subgrupo de usuarios que se excluye intencionalmente de un experimento para evaluar el impacto real de una intervención después de su implementación.

6. ANOVA: Prueba paramétrica que compara las medias de tres o más grupos para determinar si existen diferencias significativas entre ellos.

7. Kruskal-Wallis Test: Prueba no paramétrica que compara la distribución de tres o más grupos independientes cuando no se cumple la suposición de normalidad.

8. False Positive Rate: Proporción de veces que se rechaza incorrectamente la hipótesis nula, indicando un error de Tipo I.

9. False Negative Rate: Proporción de veces que no se rechaza la hipótesis nula cuando es falsa, indicando un error de Tipo II.

10. Campbell's Law: Principio que establece que cuando una métrica se utiliza como objetivo, tiende a distorsionarse al ser optimizada, perdiendo su valor como indicador.

11. Simpson's Paradox: Fenómeno en el cual una tendencia observada en grupos separados se invierte cuando los datos se combinan, revelando interpretaciones engañosas.

12. Engagement Bias: Sesgo que ocurre cuando usuarios altamente comprometidos tienen más probabilidad de ser expuestos a una intervención, sobreestimando el impacto del cambio.

13. Quasi-Experiment: Diseño experimental sin aleatorización completa, utilizado para estimar relaciones causales en entornos observacionales con menor control.

14. CUPED (Controlled Pre-Experiment Data): Técnica que utiliza datos previos al experimento para ajustar las métricas iniciales y reducir la varianza, mejorando la precisión.

15. Mann-Whitney U Test: Prueba no paramétrica utilizada para comparar dos grupos independientes cuando las distribuciones no son normales. Evalúa si la distribución de las observaciones difiere significativamente entre los grupos, basándose en la comparación de rangos.

16. Bonferroni Correction: Ajuste del nivel de significancia para reducir la probabilidad de falsos positivos cuando se realizan múltiples pruebas.

17. Welch’s T-Test: Prueba paramétrica que compara las medias de dos grupos cuando las varianzas son desiguales y los tamaños de muestra difieren.

Advanced

1. Double Machine Learning (DoubleML): Técnica de estimación causal que combina machine learning y métodos econométricos en dos etapas. Ajusta las covariables con modelos predictivos y luego realiza estimaciones causales en los residuos resultantes, minimizando el sesgo de regularización en entornos de alta dimensionalidad.

2. Stouffer's Test: Prueba combinatoria que utiliza el promedio ponderado de valores-Z de múltiples pruebas independientes para evaluar una hipótesis conjunta. Proporciona un valor-Z acumulado que ajusta la contribución de cada prueba según su tamaño muestral y varianza.

3. Interrupted Time Series Analysis (ITSA): Método cuasi-experimental que mide el impacto de una intervención observando cambios en la tendencia y el nivel de la serie temporal. Utiliza modelos lineales segmentados para detectar rupturas estructurales significativas antes y después del cambio.

4. Difference-in-Differences (DiD): Técnica para estimar el efecto causal de una intervención comparando cambios en grupos tratados y de control. Asume que las diferencias entre grupos habrían permanecido constantes en ausencia de la intervención (supuesto de paralelismo).

5. Hawthorne Effect: Fenómeno donde los sujetos cambian su comportamiento por saberse observados, generando un sesgo en los resultados experimentales. Frecuente en tests de UX y CRO, puede confundir el verdadero efecto del cambio.

6. Propensity Score Weighting (PSW): Técnica que ajusta las diferencias en covariables pretratamiento utilizando puntajes de propensión como pesos para cada observación. Emula un diseño experimental aleatorizado, mejorando la comparabilidad entre grupos.

7. Collinearity: Situación donde dos o más variables independientes están altamente correlacionadas, causando inestabilidad en las estimaciones de regresión. Resulta en coeficientes imprecisos y altos errores estándar, afectando la interpretación de los efectos individuales.

8. CUSUM (Cumulative Sum Control Chart): Técnica de monitoreo que detecta cambios en una serie temporal acumulando las desviaciones respecto a un valor de referencia. Identifica puntos de quiebre estructurales cuando el acumulado excede un umbral crítico.

9. ROC Curve: Gráfico que muestra la relación entre la tasa de verdaderos positivos (sensibilidad) y la tasa de falsos positivos a distintos umbrales. Evalúa la capacidad discriminativa de un modelo, siendo ideal para comparar clasificadores.

10. Monte Carlo Simulation: Técnica de simulación basada en distribuciones probabilísticas que evalúa la incertidumbre y el riesgo en sistemas complejos. Genera múltiples escenarios aleatorios para predecir el comportamiento bajo condiciones variables.

11. Bootstrapping Test: Técnica de remuestreo que crea múltiples subconjuntos de datos para estimar distribuciones e intervalos de confianza. Permite evaluar la significancia de resultados sin suponer normalidad, aumentando la robustez del análisis.

12. Bayesian Structural Time Series (BSTS): Modelo de series temporales bayesiano que usa componentes estructurales (tendencia, estacionalidad, ciclos) para construir contrafactuales. Mide el impacto de cambios en un entorno sin grupos de control.

13. Hierarchical Linear Models (HLM): Técnica de modelado para analizar datos organizados en niveles jerárquicos, estimando efectos simultáneos a diferentes niveles (e.g., usuario, página, campaña). Captura la variabilidad dentro y entre grupos.

14. R-Squared (R²): Medida de la proporción de variabilidad de la variable dependiente explicada por las independientes en un modelo de regresión. Indica qué tan bien las variables predicen el resultado observado, con valores más altos reflejando un mejor ajuste.

15. RMSE (Root Mean Square Error): Métrica que calcula la raíz cuadrada de la media de los errores cuadráticos entre valores predichos y reales. Indica la magnitud promedio de los errores, evaluando la precisión de los modelos en regresión.

16. ARIMA Models: Modelo de series temporales que combina componentes autorregresivos (AR), de diferenciación (I) y de media móvil (MA) para predecir valores futuros en datos estacionarios. Captura patrones históricos para extrapolar tendencias.

17. SARIMA Models: Extensión de ARIMA que incorpora componentes estacionales para modelar patrones recurrentes en intervalos regulares (e.g., mensuales, trimestrales). Ideal para series con estacionalidad marcada y variaciones cíclicas.

Como he dicho al principio, conocer y cantar como un loro los términos puede hacerlo cualquiera. Sin embargo, usarlos cómo y cuándo tocan es algo que va mucho más allá de tu capacidad de aprendizaje.

Requiere tiempo, sudor y cicatrices.

La práctica hace al maestro.

Hace mucho tiempo que no escribo y pido disculpas por dejar esta trilogía a la mitad desde hace tanto tiempo. No hay excusas más allá del foco en otras áreas de mi vida, pero el momento ha llegado:

En esta 11ª edición finaliza la trilogía sobre Python y su relación con AB testing. A continuación, nos introduciremos en un proceso paso a paso que seguimos en LIN3S para la interpretación de datos con Python.

Ahora sí, empieza Test AB con Python (III): Exploratory Data Analysis.

Espero que os guste.

Los puntos de esta edición:

1. Importancia del análisis de datos en AB testing

2. Proceso de diagnóstico pàra tests AB

   1. Definición de tipología de datos

   2. Definición de hipótesis y por qué importa

   3. Carga de datos

   4. EDA: Exploratory Data Analysis

   5. Evaluación de distribución

   6. Ejecución del test estadístico

3. Epílogo de la trilogía

Importancia del análisis de datos en AB testing

Ya he contado en algunas formaciones y webinars un suceso que tuve a principios de 2022 cuando todo lo que podía salir mal, salió mal. Se trataba de un split test con dos versiones, nada que no hubiera hecho antes.

Como se ve en la imagen, calculé la p-valor de este test y resultaba muy prometedor al ser menor a 0.05, es decir, podíamos inferir que existía significancia estadística y que la variante se podía lanzar a producción.

O eso creía…

Sin embargo, ahondé un poco más y casi por accidente di con este boxplot, desde luego, a simple vista, ya se ve que algo no funciona como debería:

Esas “bolitas” que tiene la variante son outliers, es decir, valores atípicos. Estos no deben preocuparnos especialmente en el marco de un test AB ya que, se supone, su distribución debería ser homogénea entre los dos grupos (control y variante). Sin embargo, aquí vemos que la inmensa mayoría de valores atípicos se había ido a la variante.

¿Qué había pasado?

En resumen, el equipo de marketing de esta empresa —estaba como consultor freelance por aquél entonces— había enviado tráfico directamente a la URL de la variante en unas promociones concretas.

1. La promoción aumentó las conversiones.

2. Estos usuarios “no podían” dirigirse al grupo de control ya que se les enviaba directamente a la URL de la variante.

3. Como sucedió a lo largo de una semana (un poco largo) el cálculo de la p-valor no pudo salvar estos datos atípicos.

4. Además, no saltó el aviso de SRM de la herramienta de testing.

Es decir, todo lo malo que podía pasar, pasó.

¿Qué hice?

Se decidió repetir el test, pero aproveché para eliminar las ventas de ese periodo con outliers para calcular la p-valor. El resultado lo tienes en la siguiente imagen y fue muy similar cuando se repitió el experimento. Es decir, se pasó de una significancia estadística indiscutible a favor de la variante a unos datos, con el segundo test, que no auguraban un impacto en el negocio.

Esta es la razón por la que pienso que debe haber un proceso de exploración de datos previo al cálculo de la p-valor. No entender las características de la distribución de tus datos únicamente hará que tomes peores decisiones y que caigas en los falsos positivos y falsos negativos.

En esta edición te quiero enseñar un proceso de trabajo para que esto no te pase.

Proceso de diagnóstico para tests AB

1. Definición de tipología de datos

No todos los datos son iguales. En muchas ocasiones, en marketing digital, tratamos a revenue y a transacciones y eso es un error. La tipología de dato no solo determina en ocasiones el tipo de test que ejecutarás, sino también la manera de visualizarlo y del tratamiento que debes darle.

En AB testing, habitualmente, nos enfocamos en:

• Datos discretos: En general, son números enteros.

  • Ejemplo: Número de transacciones, clicks, leads generados, entre otros.

    • Con este tipo de dato se usa habitualmente t-test (cuando la muestra es grande ya que el t-test debe ejecutarse con datos continuos), regresión de Poisson cuando sigue una distribución de Poisson, mann-whitney U cuando es un test AB con distribucción no paramétrica y ANOVA o Kruskal-Wallis cuando es un ABC/n test con distribución normal.

• Datos continuos: En general, son decimales o fracciones. Pueden tomar cualquier valor dentro de un rango.

  • Ejemplo: Revenue, Tiempo en página, ARPU

    • Con este tipo de dato se usa habitualmente t-test, mann-whitney U cuando es un test AB y ANOVA o Kruskal-Wallis cuando es un ABC/n test

• Categóricos nominales: Son aquellos que representan una categoría o tag y NO tienen un orden numérico.

  • Ejemplo: Categoría de dispositivo (es decir, mobile, desktop, tablet...), Fuente/medio del usuario (organic/google, paid/google...)

    • Con este tipo de dato se usa habitualmente:

      • Con muestra grande: Chi-squared (en algún caso, se puede usar G-test de independencia)

      • Con muestra pequeña: Fischer's exact test

• Categóricos ordinales: Son aquellos que representan una categoría o tag y SÍ tienen un orden implícito.

  • Ejemplo: Puntuación de una encuesta (muy satisfecho, satisfecho, poco satisfecho, muy poco satisfecho).

    • Con este tipo de dato se usa habitualmente:

      • 2 grupos: Mann-Whitney U

      • 3 grupos o más: Kruskal-wallis

Como puedes ver, estamos mencionando muchos tipos de test, pero, ¿qué es exactamente todo esto?

Un error muy común en AB testing es utilizar las calculadoras en línea para calcular la p-valor, pero como se puede deducir, estas utilizan un método único para devolver la p-valor (habitualmente z-test o t-test), sin embargo, el tipo de test que ejecutes te devolverá una p-valor u otra, modificando, a veces en gran medida, tu diagnóstico.

Es por ello que debes seguir un proceso que te ayude a seleccionar qué clase de diagnóstico ejecutar. Como se puede ver, hay más elementos además de la tipología de datos que determinan el tipo de test y vamos a continuar con los siguientes pasos una vez vistos los tipos de datos y los tipos de tests que pueden ser más habituales.

2. Definición de hipótesis

¿De verdad es tan importante definir la hipótesis? ¿En qué cambiará mi resultado escribir o no la hipótesis? Más allá de lo importante que es seguir un proceso o el hecho de que definir una hipótesis ayuda a ordenar tu pensamiento y especialmente tus métricas primarias, hay un factor técnico que a veces se olvida.

Existen tipos de hipótesis: one-tailed y two-tailed.

Si armamos una hipótesis con esta estructura básica estaremos armando una hipótesis one-tailed, la más típica en CRO ya que a menudo hacemos tests para aumentar una métrica:

• Hipótesis alternativa (H1): Si _____ entonces aumentará la métrica objetivo.

• Hipótesis nula (H0): Si ____ entoneces no aumentará la métrica objetivo.

Sin embargo, si armáramos una two-tailed sería así:

• Hipótesis alternativa (H1): Si _____ entonces la métrica objetivo será superior o inferior.

• Hipótesis nula (H0): Si ____ entoneces no aumentará la métrica objetivo.

¿Hay visto la diferencia? en la H1 indica que será superior o inferior, es decir, diferente a la hipótesis nula. Esto es importante porque determina la naturaleza del test y sobre todo el resultado de la p-valor. Bien puedes verlo en la calculadora en línea de test AB y comparar los resultados entre one-sided y two-sided.

Es decir, definir el tipo de hipótesis determina si debes escoger un sub-tipo de test: los de una cola o los de dos colas.

3. Cargar los datos

Hay libros enteros dedicados a esta subsección del proceso de diagnóstico, ya que cubriría toda la parte relacionada con carga, transformación de datos, data wrangling, entre otros.

De alguna manera, al final este paso deberíamos tratar de obtener algo tal que así si hiciéramos un test AB en el que queremos medir impacto en transacciones y revenue:

Es fundamental destacar la importancia de la calidad del dato: no se puede hacer CRO sin una calidad mínima.

4. EDA: Exploratory data analysis

Como ya sabemos, es fundamental antes de calcular la p-valor hacer una descripción de la distribución de los datos. En algunos tests AB deberá ser más concienzuda y en otros menos, ya que dependerá del tipo de test, la sección de la web/app que manipulemos, entre otros.

Esta fase es útil para, por ejemplo, detectar valores atípicos (outliers) y entender mejor a qué dataset nos estamos enfrentando. Sin embargo, esta fase no es tan simple, ya que en función del tipo de datos que tengamos deberemos usar una serie de visualizaciones u otras (por eso el paso 1 es tan determinante).

Para simplificar esto, nos centraremos en datos continuos y discretos, ya que son los mayores protagonistas en evaluación de tests AB.

4.1 Situación A: Datos continuos (revenue)

Montamos un dataset básico ccon 500 registros. Recuerda que si usas pd.read_scv(“file.csv”) puedes cargar datos de CSV procedentes, por ejemplo, de una exploración de GA4.

Con datos continuos es recomendable no usar gráficos de barras, sino en su lugar hacer uso de un histograma. Aquí tienes un ejemplo. Verás que el histograma y el Kernel Density Estimate (kde) serán principales aliados para el paso 5.

Otro tipo de visualización muy útil para datos continuos y discretos es también el boxplot. Me declaro muy fan de esta visualización porque creo que no existe ninguna gráfica que enseñe tanto en tan poco espacio.

Un primo hermano del diagrama de caja es el de violín, que si bien añade una camap más visual de información con su forma, debe reconocer que no me gusta tanto (a gustos colores). No obstante, no se puede negar su potencial.

Con estos tipos de visualizaciones podemos hacernos a la idea de la distribución de los datos. Por ejemplo, podemos saber que son dos grupos bastante similares aunque el grupo de control ha sumado más valores atípicos que la variante (lo cual no es necesariamente malo). Probablemente, no exista significancia estadística a favor de la variante, pero debemos seguir con el análisis.

4.2 Situación B: Datos discretos (add to carts)

Repetimos la operación, sin embargo, debemos tener en cuenta que estos tienen característicass diferentes. Por ejemplo, no es recomendable hacer uso de histograma con ellos y es más habitual utilizar gráficos de barras.

Cargamos los datos con estos datos ficticios:

Ejecutamos un barplot. Se vislumbra de forma visual que la variante funciona mejor que el grupo de control. Es interesante entender y ver que el tipo de dato determina el tipo de visualización porque será fundamental para interpretar el tipo de distribución en el siguiente paso.

En esta fase, podemos trabajar con gráficas similares, pero quiero aprovechar para mostrar una visualización infra-utilizada: el stripplot, que es útil para observar la distribución de puntos (valores) dentro de las categorías que estás comparando.

Y cómo no, el boxplot, como he dicho soy muy fan. Podemos ver que es similar salvo que la mediana es superior en la variante. ¿Puede ser eso suficiente para ser estadísticamente significativo? Eso deberemos verlo calculando la p-valor, pero para ello debemos saber qué test usar, lo que viene determinado, también, por el tipo de distribución de datos.

5. Evaluación de distribución

Evaluar qué clase de distribución tenemos es particularmente importante, ya que de ello depende qué clase de test ejecutar para evaluar si tenemos significancia estadística o no. No obstante, la manera de evaluar qué clase de distribución tenemos también depende del tipo de dato, así que veremos a continuación cómo encarar este tema.

5.1 Datos continuos (revenue)

Aquí mostraremos el histograma con KDE, es decir, con Kernel Density Estimate.

Esto lo usamos para mostrar cómo los datos se distribuyen en el eje de valores, proporcionando una idea clara de dónde se concentran los valores. Esto es útil para identificar los modos (picos en la distribución) y para ver la forma de la distribución de los datos (simétrica, sesgada, etc.).

En este caso, vemos que hay dos barras que están unidas en un mismo punto. Podríamos pensar que se trata de una distribución bimodal ligera, por eso, ejecutamos el siguiente gráfico:

Viendo este gráfico, podemos advertir que no es unimodal. No obstante, si quieres asegurarte, puedes ejecutar este código con Hartigan’s Dip Test:

Una manera adicional de diagnósticar qué clase de distribución tenemos es mediante skewness y kurtosis para entender la asimetría (skewness) y el grado de valores atípicos que tenemos (kurtosis).

Después, aplicaríamos Shapiro-Wilk test o Kolmogorov-Smirnov para definir si tenemos o no una distribución normal, cosa fundamental como vimos en el diagrama inicial de toma decisiones.

Aquí el cálculo de skewness y kurtosis

Skewness: 0 es perfectamente simétrico

• 0.23 indica unaligera asimetría positiva, lo que significa que la cola derecha de la distribución es un poco más larga o más pesada que la izquierda. En otras palabras, hay algunos valores de revenue altos que están arrastrando la cola derecha, pero no de manera extrema.

Kurtosis: 3 sería una distribución normal (mesocúrtica)

• 3.30 indica que la distribución tiene un ligero apuntamiento mayor que la normal (leptocúrtica).

Y a continuación, con Shapiro podemos ver que se trata de una distribución normal ya que la p-valor es mayor a 0.05:

Una cosa interesante que puede añadirse a este análisis de la distribución es un Q-Q Plot, que permitiría evaluar cómo la distribución de nuestro dataset es fidedigna a una distribución normal téórica. En nuestro caso:

La línea de puntos está encima de la línea roja salvo en los extremos. Esto es un caso muy típico en métricas como revenue. Esto significa que podría haber outliers pero como vimos en el anterior paso (EDA), si existen, probablemente estén perfectamente distribuidos en ambos grupos.

Existen métodos como z-score e IQR para averiguar cuáles son específicamente esos outliers a los que apunta el Q-Q plot, sin embargo, en este contexto, no sería necesario y forma parte de un análisis de otro tipo. En siguientes ediciones profundizaremos en regresiones y análisis estadístico avanzado.

Nuestro diagnóstico: Disponemos de una distribución normal, por lo que podemos usar tests paramétricos. Probablemente, t-test sea la mejor opción.

5.2 Datos discretos (add to carts)

Como dijimos en anteriores secciones, los datos discretos son distintos a los continuos. Tanto es así que si ejecutamos un histograma, nos encontramos con esto:

¿Qué clase de distribución es esto? Pues bien, con datos discretos es habitual encontrarte cosas así, especialmente en marketing digital. Por ello, trabajar una distribución de Poisson cuando tenemos datos discretos y ver si encaja con este tipo de datos es lo que debemos hacer a diferencia de con los datos continuos.

¿Qué hacemos en el siguiente gráfico? Calculamos la media (que en el contexto de Poisson se hace llamar lambda) ya que en Poisson la media y la varianza son equivalentes y evaluamos si esta línea ajustada a la media encaja con nuestros datos reales.

Como podemos ver en este gráfico, en absoluto encajan. No obstante, con chi-squared aplicando un test de bondad de ajuste podríamos verlo con números. No, no sigue una distribución de Poisson.

¿Qué hacemos ahora? Habría que bucear y ver qué clase de distribución es esta. Un paso habitual es evaluar si tenemos una distribución binomial negativa, pero creo que queda claro que tenemos una distribución apta para tests no paramétricos en cuyo caso, Mann-Whitney U es interesate.

6. Ejecución del test

6.1 Datos continuos (revenue)

Como puede verse, nuestra variante no resultó ser la ganadora (p-valor = 0.5313).

6.2 Datos discretos (add to carts)

Como puede verse, nuestra variante sí resultó ser la ganadora (p-valor = 0.0192).

¿Qué pasaría si ejecutamos otros tests con estos mismos datos? He hecho la prueba y especialmente sangrante con p-valor pequeñas. Si hubieras usado t-test o z-test con los datos discretos te habría dado como perdedora la variante, por lo que habrías caído en un falso negativo.

El motivo por el que esto sucede es simple: Mann-Whitney se basa más en rangos y habitualmente resulta menos sensible a valores atípicos mientras que t-test, por ejemplo, se centra en medias. ¿Esto significa que Mann-Whitney es mejor? No. Sigifica que elegir el test es crítico para el éxito de tu proyecto de CRO.

7. Conclusión y Epílogo

Este proceso de diagnóstico muestra la profundidad que existe a la hora de diagnosticar un test AB. Me ha quedado largo y podría haber añadido aspectos de correcciones de Bonferroni ante comparaciones múltiples (Cosa crítica en CRO también y que tendrá su propio capítulo) o FDR.

Profundizar en la parte técnica y de datos de CRO es una de las cosas más sorprendentes que he vivido jamás. Cómo a través de datos podemos llegar a un nivel de tal abstracción. Un reto al que, sin duda, las organizaciones que quieran llegar lejos deberán recorrer.

¿Quieres profundizar en analítica de datos con Python y no sabes cómo empezar? He escrito un libro con Joseba Ruiz llamado “Analítica de datos con Python para marketing digital” que te ayudará a dar los primeros pasos en este mundo tan fascinantes.

May the CRO be with you.

Veremos si esta edición se asemeja a El Padrino II y podremos ser ejemplo de una historia que supera a su antecesora o nos convertiremos en Matrix: Reloaded, más conocida como la película que nadie reclamó y que ojalá nunca se hubiera producido.

En esta 10ª edición continúa la trilogía sobre Python y su relación con AB testing. A continuación, nos introduciremos en algunos aspectos clave que debemos conocer antes de experimentar.

Si no estás familiarizado con Python o ningún otro lenguaje, te recomiendo que eches un vistazo a la primera parte de esta trilogía, en la que enseño los más básicos de Python.

Ahora sí, empieza:

Test AB con Python (II): Preparar el experimento

Los puntos que se tratan en esta edición:

1. Introducción

2. Nivel de significancia

3. Potencia estadística

4. MDE

5. Randomization unit & SRM

6. Sample size calculation con Python

7. Experiment duration con Python

8. Avance: Cálculo de SRM con Python

Antes de empezar

Se puede encontrar mucha información relacionada con AB testing y Python, sin embargo, Leanalytics se centra —especialmente en esta trilogía— en Online Controlled Experiments, es decir, en experimentos dentro de un sitio web o aplicación. Es importante señalar esta cuestión puesto que los AB tests se aplican a menudo en otros campos como, por ejemplo, medicina o biología.

Uno de los motivos principales por los que se hace esta distinción es porque en un test AB en la mayoría de las disciplinas puedes disponer de un gran control sobre la condición de los individuos del grupo de control y de la variante, pero en Online Controlled Experiments muy pocas veces tendrás el mismo control.

En Online Controlled Experiments los individuos no son personas únicas que consumen en tu sitio web. La métrica usuarios no es una métrica que indique el número de personas que entran en tu sitio web. Las métricas asociadas a usuarios son en muchas ocasiones fruto de la inferencia de un algoritmo cuyo output es que una serie de cookies determinadas —que recordemos, funcionan a nivel de navegador, nunca de dispositivo— son un único usuario.

Como todo modelo de aprendizaje automático tiene un error rate determinado —en el caso de GA4 un 2%—, estamos trabajando con la asunción de que un usuario es una persona determinada, lo cual es tecnológicamente falso. En este hilo de Twitter explico cómo funciona el recuento de usuarios en GA4 con el algoritmo HyperLogLog++ y las consecuencias que esto genera en AB testing.

La estadística en una población volátil

En un mundo en el que no puedes de forma 100% veraz asegurar que estás separando personas entre grupo de control y variante y en el que, además, la población de tu sitio web cambia cada día en función de factores coyunturales como updates de Google, modificaciones en las estrategias de PPC de tus competidores o de tu empresa, aparición de nuevas plataformas e incluso cookies, parecería que la estadística purista no tiene cabida en Online Controlled Experiments.

Para los que no conozcáis a Picanumeros —que, querido lector/a, te recomiendo seguir YA—, es profesor de estadística de la Universidad de Granada y es uno de los más prolíficos creadores de contenido sobre estadística en Twitter. Le pregunté hace varias semanas sobre este asunto y esto fue lo que me contestó:

Lo que debemos extraer de esto que apunta Picanumeros (¡Mil gracias, amigo!) es que ante un mundo tan caótico como el online hay que aportar fuentes externas que ayuden a dar color a tu diagnóstico, especialmente si haces CRO y experimentación online. Es un tema que ya se trató de forma marginal en esta edición de Leanalytics.

Es decir, no podemos ser especialmente puristas con la estadística, lo cual no significa que haya que repudiarla. Es fundamental conocer estadística básica para hacer CRO, pero también es necesario saber que los individuos con los que estamos trabajando tienen asociadas unas características muy, muy específicas.

Ahora sí, AB Testing con Python

Significance Level

Antes de iniciar experimentos debemos tener en cuenta una serie de cosas muy relacionadas con estadística. Una de ellas es el nivel de significancia, la cual podemos definir así:

Es decir, decimos que el resultado de un experimento ha sido estadísticamente significativo cuando es poco probable —que no imposible— que haya sido debido al azar.

Esto es importante debido a que no deseamos que nuestros experimentos —que apenas tendrán unas semanas de duración— arrojen resultados que no podemos trasladar al resto de los usuarios futuros de la web.

Sobre falsos positivos y falsos negativos, puedes leer Leanalytics 004 y Leanalytics 005 respectivamente, sin embargo, quiero apuntar a la idea de que debemos ser muy cuidadosos con el Type I Error (Falso positivo) y significance level. Si tu nivel de significancia lo ubicas al 0,05 tu Type I Error será también del 0,05.

En la práctica, cuando haces experimentos online puedes modificar tu alpha (significance level) en función de aquello con lo que quieres experimentar. Como bien sabes, hay entornos más sensibles que otros a nivel comercial o incluso a nivel de desarrollo y es valorable modificar el nivel de significancia si lo consideramos adecuado.

Sin embargo, hay que hacerlo en función del contexto y la importancia real y ponderada de la situación, puesto que en la práctica es muy goloso que tanto clientes como colaboradores del mismo consideren que todas las áreas —o aquellas en las que ellos tienen influencia— son las más críticas del negocio. No todo merece un nivel de significancia máximo.

Sin ningún tipo de duda, esta decisión la debe tomar el CRO y habitualmente siempre se trabajará con 0.05 para simplificar los procesos de experimentación e interpretación de los resultados. Aún así, si quieres un rango, este puede servirte:

Statistical Power

Este es un concepto que va fuertemente ligado con los experimentos online y también con los Type II Error —también conocidos como falsos negativos—. Aquí una definición:

Si observas la gráfica de debajo, como hemos ubicado alpha en 0.05 y la p-valor es inferior a alpha (0.03), podemos rechazar la hipótesis nula. Sin embargo, la potencia estadística tiene una gran importancia también en la preparación de un experimento.

La potencia estadística representa la probabilidad de detectar un efecto en el total de una población cuando éste es real. Como puedes ver en la imagen inferior tiene una relación direccta con los Type II Error. Imagina que un test AB determina que no hay un efecto superior de la variante con respecto al grupo de control y realmente sí hay un efecto: Se trataría de un falso negativo.

Statistical Power y Type II Error -es decir, los falsos negativos- son complementarios. Si estimas que la potencia estadística es de 0.80, significa que tu Type II Error Rate es del 0.20.

Por convención, la potencia estadística se ubica a menudo en 0.80, pero al igual que con el nivel de significancia debemos entender que va a depender del contexto: El contexto determina en qué punto deberías ubicar tu statistical power.

Sin embargo, si deseas un rango aproximado, en entornos en los que tenemos poco tiempo —por una promoción limitada en la que no ha habido tiempo para maniobrar debidamente, por ejemplo—, ubicar en 0.70 puede ser una opción y, si queremos ser muy cuidadosos porque va a tocar temas sensibles —habitualmente con Hippos—, un 0.90.

Statistical Power y Significance Level juegan un papel complementario en la interpretación de los resultados y en la preparación de un experimento, puesto que la potencia estadística nos permite entender en qué medida se ha detectado un efecto o no por su relación con los falsos negativos.

Minimum Detectable Effect (MDE)

¿Qué es exactamente MDE?

Es decir, es el efecto mínimo que necesitamos percibir en un experimento para considerar que realmente existe una significancia estadística. Este valor debería estimarse antes de realizar cualquier experimento online y existen varias maneras de calcularse (D de Cohen, diferencia relativa, absoluta, entre otros).

Si el efecto observado —es decir, el resultado del experimento— es:

• Menor a MDE, entonces no existe significancia estadística ni significancia práctica.

• Mayor a MDE, entonces sí existe significancia práctica, pero no se garantiza que exista significancia estadística.

Como ratio aproximado, podríamos plantearnos un MDE del 1% si estamos trabajando con un portal especialmente grande, como Facebook, Instagram o Netflix, minetras que para negocios más modestos, deberíamos aumentar el MDE.

Existen calculadoras que ayudan a evaluar algunos de estos parámetros que se están enseñando en esta edición y que probablemente conozcas, como la calculadora de Optimizely, Statsig o CXL.

Randomization Unit & Sample Ratio Mismatch

Es decir, si el total de tu población está basado en diez usuarios y realizas un AB test, cinco usuarios se dirigirán a un lado y otros cinco a otro. Randomization Unit es el quién o el qué que se agrupa en el grupo de control o la variante.

Cuando diseñamos un experimento es importante evaluar previamente debido a que puede llegar a haber discrepancias en la distribución de los usuarios entre grupo de control y variante. Esto puede provocar que establecer causalidad sea un auténtico quebradero de cabeza.

Aquí entra Sample Ratio Mismatch —también conocido como SRM—, es decir, la desviación que puede llegar a haber entre el grupo de control y la variante, lo que afecta a la capacidad que tenemos de hacer inferencias con los resultados de nuestros experimentos.

Hay muchas herramientas para calcular si tu experimento ha sufrido de SRM. Una que recomiendo por su sencillez es la de Lukas Vermeer: SRM checker, aunque cada vez más herramientas de AB testing tienen SRM checker incorporado por defecto. Más adealante, después de sample size calculation, mostraremos cómo calcularlo con Python.

Sin embargo, con Python, sería algo tal que así. Te recuerdo que en la edición 009 de Leanalytics se hizo una introducción a Python para seguir el código:

Sample Size: Cálculo con Python

Conectado a los usuarios está el cálculo de la muestra. Para ello debemos tener en cuenta los factores previamente explicados: MDE, Power y significance level. El motivo por el que puede ser francamente sano calcular antes el tamaño de la muestra es que nos permite no cometer errores ni caer en sesgos de confirmación como muy bien se explica en este blog de Airbnb sobre errores en experimentación.

La fórmula del tamaño de una muestra es dependiente de una serie de factores y quizás haré un post algún día centrado únicamente en el cálculo de tamaños mínimos de muestra o de muestreo en general, porque tiene mucho que ver en función de si haces one-tailed o two-tailed experiments:

Para hacer un cálculo sencillo con Python y saber el tamaño de la muestra que necesitamos, podemos usar el siguiente código

from statsmodels.stats.power import TTestIndPower

mde = 0.10 #minimum detectable effect
alpha = 0.05 #significance level, usamos la convención estándar
power = 0.80 #statistical power, usamos la convención estánda

analysis = TTestIndPower()

result = analysis.solve_power(mde, power = power,nobs1= None, ratio = 1.0, alpha = alpha)
print('Sample Size: %.3f' % round(result))

¿Qué resultado devuelve? 1.571 usuarios. Es decir, necesitaríamos 1.571 usuarios para cada versión del experimento —en total 3.142 usuarios— si aplicamos esta función. Si pruebas con otros valores verás que el tamaño de la muestra cambia:

• Versión con MDE (0,10), alpha (0,05) y power (0.80): 1.571 usuarios por versión

  

• Versión con MDE (0,01), alpha (0,05) y power (0.95): 259.895 usuarios por versión

Como convención:

• Si el nivel de significancia desciende, aumenta el tamaño de la muestra

• Si la potencia estadística aumenta, aumenta el tamaño de la muestra

• Si MDE desciende, aumenta el tamaño de la muestra

Experiment duration

Para evaluar la duración que necesitamos de un experimento, necesitamos tener en cuenta:

1. La naturaleza del experimento (tipo de hipótesis, por ejemplo)

2. Establecer MDE, Power y alpha

3. Calcular el tamaño de la muestra

Y una vez tienes estos valores, es tan simple como seguir esta fórmula:

Es decir, trabajaríamos con algo tal que así:

#duration days

sample_size = 14000 #entre los dos grupos
number_unique_visitors_per_day = 10000
perc_daily_traffic_allocated = 0.10

duration = sample_size / (number_unique_visitors_per_day * perc_daily_traffic_allocated)
print('duration days are', round(duration))

Si necesitamos 14.000 usuarios debido al cálculo del tamaño de la muestra —7.000 en el grupo de control y 7.000 en la variante—, tenemos un sitio web con 10.000 visitantes por día y un 10% de usuarios que van a ser afectados por ese experimento —debido a que no todos los usuarios de tu web van a ser afectados por tu experimento—, nos daría que necesitamos que el experimento dure 14 días.

Cálculo con Python de SRM

Aquí va un avance de la edición 011 de Leanalytics. Una pregunta que debes hacerte durante tus proyectos de experimentación online, una vez ya estás capturando resultados, es si tu experimento ha sufrido de SRM. No recomiendo fiarse siempre de herramientas de terceros puesto que dudo que mis incentivos estén en todo momento alineados a los suyos, así que quiero presentarte cómo calcularlo con Python.

Imaginemos un dataset como este, formado por las columnas user_id, version, minutes_play (se testea los minutos de reproducción de un video) y dos columnas que devuelven un booleano que nos permite evaluar en engagement.

Si ejecutamos el siguiente código, verás que la p-valor devuelve 0.010041820594939122. El código muestra los usuarios que ha habido en cada grupo (1600 y 1749) y los usuarios que deberían haber llegado (1675 y 1675)

from scipy.stats import chisquare 
chisquare([1600,1749],f_exp = [1675,1675])

Como la p-valor devuelve 0,01 periódico se considera que no hay Sample Ratio Mismatch en este experimento y, por lo tanto, los datos tienen significancia estadística. Esto es muy importante de cara a poder realizar una inferencia correcta entre los usuarios que han habitado nuestro experimento de dos semanas y el resto de usuarios preentes y futuros.

Conclusiones

¿Quién dijo que hacer CRO y experimentación online era fácil?

Deben tenerse en cuenta múltiples factores.

• Tecnológicos: Todo lo relacionado con el conteo de usuarios

• Estadísticos: Todo lo relacionado con alpha, power, inferencia, muestras, entre otros.

• Empresariales: CRO es lectura de contexto e interpretación de la realidad en función de datos

Solamente se ha arañado la superficie ante muchas cuestiones. En siguientes ediciones profundizaré en temas concretos como MDE, SRM o el cálculo de muestras mínimas.

En la última edición veremos qué podemos hacer con los datos que hemos recogido de un test AB y qué clase de decisiones deberíamos tomar en diferentes escenarios.

Solamente hemos arañado la superficie.

CRO no es solo poner dos versiones de una web.

La experimentación online es una de las disciplinas más completas que hay.

CRO es coral.

CRO también se puede hacer con Python.

Fuentes:

• Wes McKinsey - Python for data analysis

• Joel Grus - Data Science from scratch

• Github de Leihua Ye

• Dan Lee

Durante los últimos años en el mundo del marketing (especialmente desde que llegaron los desarrolladores) se ha debatido mucho sobre si es necesario conocer un lenguaje de programación para hacer marketing digital. Están los que dicen que sí y están los amantes del nocode —a los que algún día dedicaré una edición o un hilo— que claman sobre la falta de necesidad mientras te animan a comprar un curso de Notion.

En esta 9ª edición empieza una trilogía sobre Python y su relación con AB testing. En esta primera parte empezaremos con una introducción a Python para que aquellos poco familiarizados con el código puedan entender la parte II y III.

Ahora sí, empieza:

Test AB con Python (I): Introducción básica a Python

Antes de comenzar con aspectos de experimentación con Python, muchos de los que siguen Leanalytics son marketers, CROs, designers y managers (gracias por estar ahí ❤️) y no tienen por qué conocer ningún lenguaje de programación, sin embargo, quiero que esta trilogía sea disfrutable y enriquecedora para todo el mundo.

Por ello, esta edición se va a centrar en aspectos básicos de Python que te servirán para interpretar el código. De esta manera podrás disfrutar mucho más la parte II y III y, quién sabe, quizá es un primer paso para una nueva aventura formativa. Si ya conoces otro lenguaje de programación como JavaScript o C, esta edición no te servirá de mucho, pero te animo a continuar si tienes curiosidad.

Introducción a Python

Esto son los temas que se cubrirán en la edición 009. Por supuesto, es una pequeñísima porción de todo lo que este lenguaje de programación puede ofrecer y que te servirá para que puedas seguir mínimamente el código de la parte II y III de esta trilogía. Es una selección de elementos concretos que te servirán como guía, no para picar código.

A continuación, el índice:

1. Anaconda y Jupyter Notebook

2. Integer, Float, String & Boolean

3. Lista, Tupla y Diccionario

4. Funciones

5. Librerías e importación

1. Anaconda y Jupyter Notebook

Python es un lenguaje de programación que se puede ejecutar en diferentes plataformas, tales como Jupyter Notebook, Google Colab, editores de texto como Sublime o IDEs (integrated development environment) como PyCharm o Visual Studio —este último, en la fecha en la que escribo este post, es uno de los IDE más usados según GitHub.—

Más allá de definiciones, debemos entender que Python es un lenguaje de programación que se puede ejecutar en diferentes plataformas. Una de las más típicas formas de empezar en Python es instalando Anaconda.

El primer paso es acceder a Anaconda e instalar la plataforma en tu ordenador. Antes de hacerlo asegúrate de tener suficiente espacio en el ordenador (“Minimum 5 GB disk space to download and install.” según la documentación oficial).

Aquí los links con la guía de instalación en función del sistema operativo:

• Instalar en MacOs

• Instalar en Windows

• Instalar en Linux

La instalación es sencilla y funciona como la de cualquier otro programa que descargues de Internet. Como puedes ver en esta captura de pantalla (de la versión de MacOs) no tiene un gran misterio:

Si sigues los pasos que marca la documentación aparecerá una aplicación en tu ordenador. Si haces click, verás algo similar a esto. Como puedes ver, está RStudio, Spyder o Jupyter Notebook.

Si haces click en Jupyter Notebook se abrirá un programa en una pestaña de tu navegador y verás una interfaz con un listado de carpetas y archivos similar al de la siguiente imagen. Si haces click en “New” y después haces click en “Python 3” se abrirá un archivo que tiene la capacidad de ejecutar Python.

Otra manera habitual de manipular archivos en Jupyer Notebook es usar archivos con el formato .ipynb, que es el formato de archivo de Jupyter Notebook. Una vez los tienes disponibles en tu ordenador (en local), puedes abrirlos desde Jupyter Notebook.

¿Por qué Jupyter Notebook?

La razón para usar Jupyter Notebook es —sobre todo para aquellos que comienzan—la sencillez. Es bastante intuitivo para aquellos profesionales no tan orientados a la informática y, además, dispone de la capacidad de importar librerías fundamentales de forma muy sencilla. Así luciría un archivo .ypynb cuando lo abres en Jupyter Notebook.

Aún así, Python también se puede usar en Google Colab y otras plataformas. Lo habitual es que en un entorno de ciencia de datos profesional se use Visual Studio o PyCharm, aunque en entornos académicos es común Jupyter Notebook por su capacidad de mezclar texto y ejecución de código.

2. Integer, float, string & boolean

Dentro de Python existen varios tipos de datos. Entender con qué tipo de dato estás trabajando es fundamental ya que, como también sucede en Excel, hay ciertas funciones que puedes aplicar o no en función —en el caso de Excel— del formato. Ese formato del dato es lo que determina que podremos hacer o no en Python.

2.1 Integer

Como puedes ver, Jupyter Notebook es capaz de entender solamente escribiendo el número “2” que es un número y cómo operar con él para convertirlo en un “4”. Una nota importante es que un integer es también un número negativo y como puedes ver, se ve de color verde en Jupyter Notebook.

2.2 Float

Como puedes ver, un float es un número decimal positivo o negativo que tiene un comportamiento similar a los integers y que, por ejemplo, en el precio de los ecommerce son muy típicos.

Sin embargo, fíjate que el valor que devuelve —independientemente de ser también 4— es decimal. Esto, aparentemente, significa que el valor que devuelve la suma de dos floats es también un float. Podemos confirmarlo así:

Esta es una buena oportunidad para enseñar un concepto clave en Python y otros lenguajes de programación: las variables. Podemos convertir una variable “a” en un valor determinado (2.2) y, como puedes ver en la celda de respuesta “Out [3]” devuelve el mismo valor que en el caso anterior, solo que como si fuera un float.

En la celda “In [4]” usamos una función llamada type() que permite entender de qué tipo de dato se trata, en este caso, la variable “c” —que contiene el valor 4.0— y como es visible en la celda de respuesta “Out [4]” nos devuelve el tipo de dato: float.

2.3 String

¿Por qué devuelve 24? La razón es que no puedes sumar dos strings ya que una string es una cadena de texto, por lo tanto, cuando aplicas el símbolo “+” lo que estás haciendo es “unir” ambos valores. ¿Por qué puede ser útil sumar dos cadenas de texto? Pues, por ejemplo, para unir el número del DNI —que puede interesarnos que sea una cadena de texto, pues rara vez haremos cálculos con él— con su respectiva letra si, en un archivo, están separados.

2.4 Boolean

¿Por qué da error? ¿No hemos usado el símbolo “=”? El motivo es que estamos usando un símbolo erróneo: “=”. Cuando queremos asignar igualidad sobre dos objetos, debemos usar este símbolo: “==” y para asignar desigualdad debemos usar este símbolo “!=”, como puedes ver en el siguiente ejemplo:

Em ambos casos devuelve “True” debido a que en el primer caso se aplica “==” y en el segundo “!=”. Como puedes ver en la siguiente captura de pantalla la palabra “True” y “False” se marcan en verde, lo cual determina que son palabras reservadas.

Como resumen, estos serían los tipos de datos más básicos:

3. Lista, Tupla y Diccionario

3.1 Listas

Como puedes ver, las listas son una estructura que contienen datos que pueden ser de distinta índole: floats, integers, strings e incluso otras listas. Una manera de declarar una lista es usar el símbolo “[ ]” y añadir dentro los distintos valores.

Si aplicamos type() a la lista que hemos creado, nos devuelve el tipo de dato que es. Esto indica que existen normas, funciones y métodos que podemos y no podemos aplicar cuando estamos trabajando con una lista.

3.2 Tuplas

Aparentemente, la tupla es similar a la lista solo que se usa el símbolo “( )”. Entonces, ¿por qué utilizar tuplas? ¿cuál es la diferencia entre tuplas y listas? Como puedes ver, si usamos el método append(), podemos añadir valores nuevos a las listas:

Sin embargo, con las tuplas —como dice la propia definición— son “inmutables” y, por lo tanto, una vez se crean no se pueden añadir nuevos valores ni eliminar los existentes.

¿Qué se puede hacer ante la necesidad de modificar una tupla? Crear otra nueva o declarar una variable como lista y convertirla en lista—con la función list()—, puesto que estas sí son mutables.

Entonces, ¿porqué crear tuplas? Parecería que son menos útiles que las listas si no podemos modificarlas. Existen múltiples razones, como, por ejemplo, por razones de rendimiento y, también, al ser inmutables, pueden llegarse a convertir en útiles claves de un diccionario.

3.3 Diccionario

Un diccionario, a diferencia de una lista o una tupla, se estructura a través de una clave (en este caso, Spain, Portugal y United Kindom) y un valor (Madrid, Lisboa y London). La utilidad de los diccionarios es que son prácticos cuando necesitamos estructurar información a través de una clave y un valor.

Con los diccionarios se pueden hacer muchísimas cosas, pero para el fin de esta edición de Leanalytics no se profundizará más. Solamente, ten presente de que en este tipo de datos se usa “{ }” y están basados en clave-valor.

4. Funciones

¿Recuerdas que en la seccción anterior se enseñó “type()”? Esta era una función que devuelve el tipo de dato de esa variable que añadíamos (boolean, list, string, dict, entre otros). Más específicamente, una función es:

En Python, se crean funciones usando el término “def” y la estructura que ves en la siguiente imagen. Si ves “def” es que se está declarando la creación de una función. Esta función lo único que hace es decir “hola”.

Sin embargo, podemos complicarlo añadiendo el nombre. En la siguiente imagen estamos creando una función que espera que el programador inserte un parámetro cuyo valor es “juan”, pero podría ser cualquier otro elemento (fíjate en “Out[32]”, en este caso, devuelve una tupla):

Por supuesto, se pueden realizar funciones con números. En este caso creamos una función que espera dos parámetros (a y b) y que, por sí solo, los divide y devuelve un valor (c) que es el resultado de la división:

¿Qué sucede si solo ponemos un parámetro en una función que requiere dos parámetros? Python te avisa en “TypeError” de que todavía falta el argumento b:

Crear tus propias funciones es básico porque permite automatizar tareas repetitivas o que sabemos que serán comunes en todos los proyectos, por ello la creación de funciones adhoc para proyectos es elemental.

En esta gráfica de DataCamp, se muestran funciones en relación al tipo de dato (ya que no todas las funciones funcionan con todos los tipos de dato) y se añaden algunos elementos que no están dentro del ámbito de esta edición y que pueden ser útiles: DataFrames, operadores lógicos, arrays, entre otros.

Sin embargo, ¿es necesario que hagamos todas las funciones? ¿es posible que podamos beber de alguna fuente con muchísimas funciones y solamente crear aquellas que sean muy específicas para problemas concretos? Sí, eso ya existe y reside en el siguiente bloque:

5. Librerías e importación

Imagina que necesitas hacer una predicción del tráfico orgánico del próximo trimestre o aplicar una desviación típica para averiguar lo dispersos que están los datos con respecto a la media. ¿Necesitarías hacer una función a mano y reflejar el cálculo con Python? Posiblemente puedas hacerlo, pero no deberías ya que tardarás mucho tiempo.

Para ahorrar tiempo, se usan librerías que, en esencia, contienen esas funciones y métodos que pueden ayudarnos a agilizar el trabajo. Por ejemplo, imagina que deseas averiguar si existe una correlación entre el precio de la vivienda en Barcelona con otra serie de dimensiones que tienes en un CSV, ¿Cómo se podría hacer?

Si usas el método corr() —que pertenece a la librería Pandas— en un DataFrame (en este caso, llamado “bcn”) se aplica por defecto el coeficiente de correlación de Pearson, aunque se podría modificar y usar el de Kendall o el de Spearman en función de la naturaleza del DataFrame. Aquí un ejemplo de los valores que devuelve este método en este DataFrame:

Nota para los developers: En aras de la sencillez de la comprensión, no es necesario que el lector novel en programación entienda la diferencia entre métodos y funciones y, en este caso, se tratan como si fueran lo mismo, aunque realmente no lo son. Profundizar en esto sería algo que obligaría ahondar en otros campos como, por ejemplo, las clases y no es ese el objetivo de esta edición.

¿Cómo se importan librerías en Jupyter Notebook?

Así de sencillo. Se usa la abreviación “pd” para pandas y “np” para numpy por pura convención. Así, cuando se utilizan métodos que requieren usar el nombre de la librería no es necesario poner el nombre completo, como es el caso de pd.to_datetime.

La lamentable dualidad

El auge de nocode e incluso de IAs como ChatGpt han puesto en duda la idea de si es necesario saber programar. Considero que no todas las profesiones lo necesitan, sin embargo, aquellos que quieran dedicarse a un marketing digital de cierto nivel están, a medio plazo, obligados a entender con profundidad un lenguaje de programación.

La autonomía que te da dominar un lenguaje de programación no tiene parangón. Dedicándole tiempo y esfuerzo puedes convertirte en un profesional mucho más válido y capaz de desarrollar ideas y ejecutarlas por ti mismo en lugar de depender de otros. En mí, marcó un antes y un antes.

La misión de Leanalytics no es enseñar Python, sin embargo, es un lenguaje de programación que, al ser idóneo para la manipulación del dato, permite navegar en la vorágine de datos que a veces representa la experimentación online y, sobre todo, la inferencia.

En la siguiente edición entraremos de lleno en los test AB y Python. Si este post te ha animado a aprender Python, dejo al final de todo unos recursos que creo que pueden ser útiles.

Que la fuerza te acompañe.

Fuentes:

• Wes McKinsey - Python for data analysis

• Joel Grus - Data Science from scratch

• Joseba Ruiz - Forecasting Organic Search traffic with Python

• Cheatsheet - DataCamp

Recursos adicionales

• Sobre Python: www.datacamp.com

• Sobre Experimentación: Mucho de lo que voy a enseñar lo aprendí de Ronny Kohavi, VP de Experimentación de Airbnb, Amazon y Bing (casi nada). Ahora mismo está ofreciendo un curso sobre Test AB en Maven que está francamente bien. Como fui alumno suyo en Sphere en un programa sobre experimentación online tengo un código de descuento SPHERE8REC500 con el que puedes ahorrar 500$ en el curso.

Posiblemente una de las palabras más sonadas de los últimos años en el ámbito del marketing digital. Se ha clamado y escrito mucho sobre lo que significa Growth Hacking y lo que un Growth Hacker realmente hace —no con mucho éxito, puesto que la mayoría de las personas del ámbito del marketing siguen sin saberlo—.

En esta 8ª edición desarrollaré la siguiente cuestión:

¿Existen los Growth Hackers?

¿Qué es Growth Hacking?

Menuda pregunta. Nada fácil de contestar. ¿Por qué? Porque Sean Ellis, creador y mayor divulgador de la metodología con su libro el método hacking growth, no define de forma clara y precisa qué es Growth Hacking. Puedes verlo claramente en este excelente resumen de Bookstraping.

De hecho, Andrew Chen, una de las mayores personalidades en materia de growth en el mundo, emitió ya hace varios años una definición en su clásico artículo ‘Growth Hacker is the new VP of Marketing’ que, cuanto menos, hace aguas por todos lados:

Si se desglosa la definición, observarás lo siguiente:

“Growth hackers are a hybrid of marketer and coder…”

Esto es falso. Sean Ellis fue el primero en aplicar esta metodología y viene de empresariales. No sabe picar código lo suficiente como para tomar las riendas de un proyecto en cuanto a tecnología. De hecho, puedes hacer Growth Hacking sin la obligatoriedad de saber programar.

…one who looks at the traditional question of “How do I get customers for my product?

Es maravilloso. Como si los directores de marketing de los últimos 75 años nunca se hubieran hecho la pregunta “¿Cómo consigo más clientes?”. Gracias, Growth Hackers. Pensar que marketing solo se basa en brand awareness es una señal inequívoca de que, el que habla, no ha leído, ni sabe, ni ha practicado nunca buen marketing.

Sean Ellis dijo esto en esta entrevista para Mixpanel. De nuevo, nos deja sin definición formal. Sin embargo, abre la puerta a una verdad incómoda: Se ha confundido por completo el concepto de lo que es Growth Hacking e incluso menciona lo siguiente: “You can’t get educated until you realize you’re uneducated,”

Si no tenemos definición de Growth Hacking no podemos manipular el concepto. No podemos debatir, ni construir, ni crecer. Cada uno acaba hablando de su libro y eso genera una ambigüedad en el ámbito que a nadie —o a muy pocos— favorece.

Una complicada cuestión, —posiblemente— solucionada

En 2018, en paralelo a mi carrera profesional (por aquel entonces como consultor y ahora en LIN3S), comencé dando clases de Growth Hacking y Analítica Digital. Ahora, soy director en el Master de Growth Hacking en IEBS Business School y profesor de Growth Hacking en el Postgrado de innovación y emprendimiento de EUNCET Business School.

Llegado el momento tuve la necesidad de explicar en qué consiste la metodología a alumnos, clientes o stakeholders. A raíz de esto, creé una propia y es la que usamos en IEBS para articular todos los módulos:

Sin profundizar más allá (quizá en una siguiente edición), se trata de una metodología —y no en una disciplina como SEO o analítica— que detecta problemas y oportunidades, los traduce en métricas a superar y tiene por objetivo implementar experimentos para corregir esos problemas y/o aprovechar esas oportunidades previamente detectadas.

Si te fijas, tenemos aquí un amplio compendio de skills necesarias para ejecutar esta metodología en un contexto de negocio:

• Conocimientos de negocio (digital y/o tradicional)

• Analítica

• Creatividad

• Experimentación

• Tecnología

• Marketing digital (con sus pertinentes disciplinas)

• …

Es aquí donde nace nuestro protagonista: El Growth Hacker. Ese perfil que, según dónde busques información, parece que sabe hacer todo esto. TODO. Automatizar, detectar, crear, diseñar, analizar, experimentar…

¿Será verdad? ¿Existirá este perfil?

¿Qué no es un Growth Hacker?

Si buscamos “definición growth hacking” aparecerán aproximadamente 2M de resultados, pero ¿cuál es la calidad de esta información?

Como podemos ver en esta imagen, un Growth Hacker es al mismo tiempo un perfil analítico, creativo, ágil, multi-tasking y que, no sé por qué hilarante objetivo de negocio, debe crecer un x10 a final del periodo.

Desde luego, no parece realista, sobre todo si tenemos en cuenta la complejidad creciente que existe en cada una de las disciplinas de marketing (analítica web/app, SEO, PPC, Email marketing, Marketing Automation…) que en algún momento se deberá usar para experimentar.

Si continuamos más abajo con más fuentes vemos lo mismo. De hecho, existen incongruencias, como en “Analítico” donde se menciona que el growth hacker toma decisiones basadas en datos (ah, ¿en marketing off/on no?) o en “Creativo” donde se apunta que la redefinición de las características de un producto digital debe provenir de la creatividad (disruptiva, a poder ser).

Obviamente, no existen perfiles así. Debido a la complejidad inherente a crecer un negocio digital, a la sofisticación de las disciplinas y de la tecnología y a la exigencia de la propia metodología, parece evidente que el growth hacker es, probablemente, un personaje ideal y en absoluto real. Cuando pensamos en un Growth Hacker pensamos en “la idea de un growth hacker” y no tanto en algo tangible y realista del que practica la metodología.

Emergen dos conclusiones obvias:

• Como consecuencia de que Growth Hacking no ha sido definido correctamente, no se puede definir lo que es o lo que hace un Growth Hacker.

• Growth Hacking no es una metodología que ejecuta un solo individuo. Es una metodología coral en la que intervienen distintos perfiles.

¿Existen los Growth Hackers?

Antes de responder a esta pregunta, debemos entender cuándo se aplica Growth Hacking y en qué contexto empezó esta metodología.

Empezó en Silicon Valley en la primera mitad de la década del 2010, en pleno apogeo de la cultura startup. Una startup en Silicon Valley no tiene absolutamente nada que ver con una startup en España. Mientras aquí celebramos una ronda de 500k€, ellos, por aquel entonces, adquirían a través de rondas decenas de millones de euros. Eso genera, automáticamente, una capacidad incomparable de crecimiento y, sobre todo, contratación de distintos perfiles.

Existe una convención en cuanto a cuándo aplicar la metodología: Se recomienda aplicar Growth Hacking en empresas en fase de crecimiento y no de introducción. De hecho, Sean Ellis, Andrew Chen o Brian Balfour lo han repetido en diferentes ocasiones (abajo en las notas, los enlaces). Los motivos son los siguientes:

1. Una empresa en fase de introducción rara vez tiene materia prima con la que ejecutar experimentos online (no hay histórico de datos y en ocasiones hay muy poco tráfico)

2. Una empresa en fase de introducción —En España— habitualmente, no puede invertir en un equipo completo para ejecutar esta metodología

3. Una empresa en fase de introducción debe enfocarse, entre otras cosas, en hallar el product-market fit (entre otras cosas).

El Growth Hacker en EEUU es adecuado en una startup debido a que el potencial de inversión allí es bastante más amplio que el de una startup en España y, además, ese perfil se encargará del crecimiento porque habrá otros perfiles que le acompañarán en ese viaje.

Por otro lado, las startups en España no buscan aplicar Growth Hacking. Buscan crecimiento. Pero buscan una persona —el Growth Hacker— para que gestione todo el crecimiento de una organización. Buscan la narrativa mágica. La solución mágica. Es lógico: Ya que la promesa del Growth Hacker como perfil es esa: Una fantasía fruto de la indefinición.

Así, este perfil puede tener sentido cuando una empresa da sus primeros pasos y necesita a un profesional polivalente, pero eso no significa que este vaya a aplicar Growth Hacking. De hecho, aplicará —o debería aplicar— las mismas técnicas que un digital marketer aplicaría.

Si volvemos al framework de Growth Hacking, veremos que esta metodología solo se entiende bajo el prisma del trabajo en equipo:

1. Posiblemente, necesites a una persona que sepa analizar tu producto digital y extraer conclusiones significativas

2. Necesitarás a profesionales que puedan generar ideas, soluciones y experimentos relevantes

3. Obviamente, también a personas capaces de implementar estos experimentos

4. Finalmente, una persona dedicada a organizar este equipo con perfiles tan diferentes: El Head of Growth.

Pastilla roja o pastilla azul

En España, lo que conocemos como Growth Hackers son perfiles generalistas adecuados en contextos muy concretos: Como, por ejemplo, en una fase de introducción en el que la empresa no puede contratar a un equipo completo.

Muy probablemente, este profesional en ese contexto no ejecutará realmente Growth Hacking. Hará otras cosas —muy importantes— que son condición sine qua non para aplicar la metodología, pero es comparar al que prepara el fórmula 1 con aquél que lo conduce.

Así, estos perfiles no es que no existan. Sencillamente una sola persona no puede hacer todo lo que la metodología requiere. Esto genera preguntas muy incómodas: ¿Los Growth Hackers hacen realmente Growth Hacking? ¿En qué espacio del equipo de growth se les ubica? ¿Qué hace exactamente dentro del framework? ¿Es el Head of Growth el Growth Hacker?

El problema real es el siguiente:

La polisemia de los términos genera ambigüedad: Tanto de expectativas, como de procesos y, sobre todo, de cómo incorporar la experimentación a una compañía.

Si el Growth Hacker es aquella persona que hace Growth Hacking tenemos un problema, porque Growth Hacking —bien hecho y desde que empezó con Sean Ellis en Dropbox— es una metodología que requiere un equipo multidisciplinar: No es de lobos solitarios.

Ahora bien, sí es cierto que una persona suficientemente generalista y capaz puede hacer Growth Hacking, pero será un Growth Hacking básico. ¿El motivo? No hay una persona que pueda analizar como los negocios actuales requieren hoy en día, idear y diseñar soluciones adecuadas o implementar cualquier experimento. Solamente en negocios en fase de introducción se toleraría esa poca profundidad en la calidad de los resultados.

Es probable que leas esto y te vengan personas a la cabeza que dicen que pueden hacer todo esto. No seré yo quien lo niegue. Tampoco intento convencerte de si es posible hacer tantas cosas y tan diferentes en un mismo proyecto y con garantías.

Tú decides si compras —lo que para mí es una fantasía— que un único Growth Hacker puede generar todo ese crecimiento en una organización o si, quizás, es más una cuestión de trabajo en equipo ordenado por una metodología y un buen proceso. Es menos sexy lo segundo, pero, a mí, me parece más realista.

Tú decides.

Pastilla roja o pastilla azul.

PD: Esto no es una crítica a esta maravillosa metodología que tantas alegrías me ha generado en lo profesional. Es una crítica a la mala aplicación y a la exagerada generación de expectativas que no hace ningún bien a nadie: Growth Hacking es coral.

Fuentes de la 8ª edición:

1. Entrevista a Sean Ellis (1)

2. Entrevista a Sean Ellis (2)

3. Andrew Chen - The Growth Hacker is the new VP of marketing

4. Sean Ellis - El método hacking growth

5. Resumen de Bookstraping

Google anunció la semana pasada que el 30/09/2023 Google Optimize dejará de estar disponible. Así nos deja la herramienta más conocida de AB testing y algunos contienen el aliento. Parecería que CRO es hacer AB testing pero en absoluto es así. En esta edición abordaremos esta cuestión:

‘CRO es más que Google Optimize’

De una día para otro, Google anuncia el sunset de Google Optimize sin demasiada información sobre su sustituto, aunque en los mentideros del ramo se rumorea que se integrará dentro de GA4. Hasta entonces, toca esperar…

GO ha sido la herramienta reina de la experimentación y ha servido a la mayoría para aproximarse a la bella disciplina del CRO. Todo eran ventajas: Se integraba adecuadamente a GA, era fácil de instalar, sencilla de usar y además gratuita.

Toca buscar alternativas independientemente de lo que comunique Google (En las notas he puesto algunas). Aparecen players que aprovechan esta única oportunidad y las redes sociales se inundan de expertos y de debates sobre la mejor alternativa y parece que CRO brilla un poco menos sin su herramienta estrella.

Pero AB testing es una porción muy pequeña de todo lo que hace un/a CRO...

CRO es también Research

Uno podría pensar que como CRO es Conversion Rate Optimization puede llegar a tener sentido que, a través de la experimentación, podamos encontrar las mejores formas de modificar el comportamiento online de nuestros usuarios. Se crearía una variante con nuestra hipótesis, un grupo de control y lo que mejor funcione sería lo que al final implementaríamos.

Ya traté en la edición 003 de Leanalytics que este es un pensamiento un poco simplista en términos estadísticos o de comportamiento online, pero en esta edición quiero poner el foco en este punto: AB testing es un medio para un fin y no el fin en sí mismo.

Si dedicas tu tiempo a testear ideas al estilo ‘probemos cosas, a ver qué pasa’ sin hacer un análisis cuantitativo y cualitativo del usuario y del negocio para detectar un problema a superar, sencillamente no estarás apuntando a la dirección correcta. Ejecutarás muchos experimentos pero jamás aportarás valor real al negocio.

El test AB o cualquier otro tipo de método de online testing persigue:

Como habrás percibido, se intuyen tres pasos elementales de esta definición:

1. Primero, detectamos el problema a superar (investigación cuantitativa y cualitativa)

2. Luego, desarrollamos una hipótesis para solventar el problema (basada en la investigación previa y nuestra experiencia)

3. Finalmente, ponemos a prueba la hipótesis (a través de AB testing) y evaluamos

Lo cual, hace que podamos llegar a esta conclusión:

Si aceptamos que el tiempo que debe dedicarse a research es muy amplio porque debemos encontrar oportunidades y posibles soluciones válidas (hipótesis), nos daremos cuenta que la porción de tiempo más famosa de CRO es también la porción de tiempo más pequeña.

Pero la cosa no acaba aquí.

Como he dicho antes, AB testing es el medio para un fin y no el fin en sí mismo. Estos tests sirven para evaluar qué funciona mejor y subir a producción esa variante ganadora o mantener lo que ya teníamos.

Pero no todo tiene que pasar por ahí.

No todo pasa por AB Testing

Imagina el siguiente caso (con cambios pertinentes) que me sucedió en 2019.

Eres la persona responsable de CRO en un SaaS B2B y, tras tu proceso de investigación, has averiguado lo siguiente:

“El 86% de los usuarios que se dirigen a una de nuestras core features (la cual es fundamental para que estos lleguen al ahá moment) lo hacen a través de una llamada telefónica o un email a nuestro equipo comercial. Esto hace que el proceso sea lento y tedioso porque hay veces que el equipo comercial no puede atender a esas llamadas y se pierden oportunidades.”

La solución que planteas: Los usuarios hacen preguntas que parecen razonables, sin embargo, existe una moda clara en 6 preguntas en concreto. Como no se desea modificar la interfaz ni los copys del sitio web, planteas instalar un chatbot que responda satisfactoriamente y con todo lujo de detalles a esas 6 preguntas.

Resultado: Disminuyó el número de llamadas y correos al equipo comercial y aumentó la productividad, así como el número de usuarios que se registraban para probar esa feature en particular.

Este caso tan simple sirve para ejemplificar lo siguiente:

La solución siempre depende íntegramente de la naturaleza del problema. Por esta condición, muchas de las soluciones que un buen especialista de CRO promueve no tienen por qué pasar por ejecutar un AB testing.

Los consultores de CRO se dedican a optimizar y/o mejorar la experiencia dentro de un producto digital con el fin de mejorar una métrica determinada (a poder ser económica). Si eso implica ejecutar experimentos online o no, depende de aquél problema u oportunidad que se haya detectado.

La naturaleza del problema siempre determina el medio por el cual se solventa, lo cual pone de manifiesto que CRO conlleva en la práctica la capacidad de ofrecer un abanico más amplio de soluciones.

CRO es también proceso y personalización

Como dice Ricardo Tayar en esta entrevista con Itnig, muchos de los proyectos de CRO acaban siendo proyectos de personalización de la experiencia, debido a que los negocios digitales son cada vez más complejos y que esos tiempos románticos en los que cambiar el color de un botón aumentaba tus ventas un +1000% ya pasaron a la historia (opinión que comparto).

Cuando se habla de personalización enseguida nos viene a la mente un nivel de personalización proficiency como el de Netflix, sin embargo, cosas tan accesibles como la personalización en función del UTM de campaña que aún ofrece Google Optimize es un pecado no verlo más a menudo en, por ejemplo, campañas de Facebook o Google Ads. Por no mencionar otro tipo de reglas: como parámetros de consulta, cookies propias, variables creadas previamente en GTM de JS personalizado…

Sin embargo, es fundamental, para ofrecer experiencias enriquecedoras para el usuario y fructíferas para el negocio, diseñar procesos de trabajo orientados a la detección de problemas, generación de soluciones aptas y personalizadas y su implementación ya sea a través de experimentación o no.

En el libro Design for behaviour change de Stephen Wendel se plantea un proceso llamado DECIDE que, aunque si bien es cierto que no está dirigido a proyectos de CRO, tiene muchos puntos en común:

En el libro de Ricardo Tayar, CRO Profesional Estrategia y Práctica (que recomiendo leer), se plantea un proceso de nada más y nada menos que 12 pasos para estructurar un proyecto de CRO. Como puedes ver, el proceso de testing tiene su propia sección (7) pero no es la única ni la parte más importante de todo el proceso.

Más allá de la fase de test, hay fases completas de análisis a través de datos, encuestas, entrevistas en profundidad, análisis del negocio y de los problemas/oportunidades clave, etc.

Para hacer CRO necesitas un sistema. Un proceso articulado y por supuesto revisable en el tiempo que permita la detección y explotación de oportunidades y que, obviamente, combina muchas disciplinas diferentes: UX/UI Design, Data, Product, IT, entre otros.

CRO es también víctima de su naming

CRO es muchas cosas.

• Es negocio (como debería ser todo)

• Es diseño, al aplicar muchas soluciones sobre una interfaz

• Es behaviour change si además añadimos la capa comportamental a todo proceso de CRO

• Es data, al necesitar apoyarse en el tratamiento y explotación del dato para evaluar el resultado de los experimentos o encontrar los segmentos de usuario más interesantes, entre otros

• Es research, al incorporar en muchos proyectos a especialistas en investigación cualitativa.

• Es tecnología, al tener que entender cómo funciona la tecnología en la que se sustenta el negocio digital

• Es proceso, ya que para ejecutar correctamente esta disciplina es necesario articular un proceso que recoja todo el aprendizaje y aúne la manera de trabajar en la organización.

• Pero también es Conversion Rate Optimization y cuando pensamos en estas palabras pensamos automáticamente en AB testing y experimentación, lo que canibaliza casi sin remedio a toda la disciplina.

Google Optimize se ha ido y no tengo grandes expectativas con su sustituto.

Pero no pasa nada.

¿Se podrá hacer CRO sin Google Optimize?

Sí, desde luego. Hay más herramientas en el mercado.

Pero lo más importante es que CRO es más.

Es mucho más que AB Testing.

Fuentes de la 7ª edición:

1. Ricardo Tayar - CRO profesional Estrategia y práctica

2. Stephen Wendel - Design for behaviour change

3. Google Optimize Sunset announcement

4. Brief history of Netflix personalization

5. Alternativas a GO:

   1. VWO

   2. AB Tasty

   3. Amplitude

   4. Optimizely

   5. Convert

“Debemos satisfacer las necesidades de nuestros clientes”

“Conocer las motivaciones de los usuarios”

“Desarrollar productos y servicios en función de lo que demandan”

¿Y si este no fuera siempre el enfoque correcto?

Si así fuera, le estaríamos atribuyendo un pensamiento mecanicista al comportamiento de consumo. Un pensamiento racional en el que el consumidor (1) ha investigado y diagnosticado lo que le sucede de forma correcta, (2) comparado soluciones disponibles y (3) adquirido la que más se ajusta a su bolsillo.

En esta edición presento un enfoque que ha cambiado, para bien, mi manera de entender marketing, estrategia y la dirección de proyectos:

‘El Pensamiento Problem-Centric’

¿Qué es Problem-Centric?

“Necesito crecer en ventas”. El briefing de mis 4 últimos años como consultor podría resumirse en esta frase. La situación es simple: Una empresa (habitualmente una startup) quiere crecer en ventas a través de vender más.

Si se aplica el pensamiento Customer-Centric a esta situación, como marketer, obtendríamos lo siguiente:

1. Hemos detectado la necesidad de nuestro cliente: No vende lo que quiere vender.

2. Investigamos soluciones para que nuestro cliente venda lo que quiere vender.

3. Impulsamos las acciones que, a priori, son más proclives al éxito: vender más.

El esquema es similar a lo que propone Kotler en su obra: “los productos o servicios no generan necesidades, sino que los productos o servicios satisfacen y se adaptan a necesidades previamente detectadas”:

Este enfoque es un error. Es simplista y confunde el objetivo con la necesidad y no tiene en cuenta los factores de causa-consecuencia que existen en las empresas. En muchos casos, las soluciones que podamos impulsar e incluso la investigación que desarrollemos no serán fructíferas (ni en insights ni en rentabilidad) porque no estarán solventando ningún problema.

What’s the problem?

La película Moneyball es una las grandes películas ejemplares de CPS (Complex Problem Solving) y todo lo que esta disciplina conlleva. En esta escena, Brad Pitt habla con su staff técnico sobre cuál es verdaderamente el problema que están intentando solventar.

El problema, según su equipo, es que “tienen que conseguir nuevos jugadores para reemplazar aquellos que los equipos de baseball más grandes les han quitado”

“MEEEEEEEEEC” dice Brad Pitt, que responde:

“Hay equipos ricos, hay equipos pobres, luego hay 15 metros de mi***a y después estamos nosotros. Es un juego injusto. Somos donantes de órganos para los equipos ricos. Les entregamos nuestros riñones a Boston y el corazón a los Yankees y os pasáis el día hablando como si vendiéramos pantalones. Tenemos que pensar diferente.”

Algo parecido sucede en muchas ocasiones cuando intentamos desarrollar soluciones para problemas de nuestros clientes: Confundimos problemas, causas y consecuencias. En el caso de Moneyball, el staff técnico confundía las consecuencias (que los equipos ricos les quitaban jugadores) con el core o causa raíz del problema (No tienen recursos y son incapaces de prosperar si juegan al mismo juego que los grandes).

Si nos vamos al ejemplo de la empresa que desea vender más, la situación es similar: No estás vendiendo como querrías debido a una serie de causas raíz. Vender menos no es el problema raíz, sino una consecuencia de no hacer las cosas bien: de una serie de causas a detectar. Debemos detectar estas causas, conocer la naturaleza del problema global que tenemos en la mesa y priorizar las posibles soluciones disponibles.

Este cambio en el enfoque hace que veamos una situación con una amplitud de miras superior. En lugar de poner el foco en una necesidad ambigua que atacar (vender más es ambiguo por naturaleza), pondremos el foco en elementos más tangibles y que realmente están siendo causa de una consecuencia particular.

Un ejemplo: En lugar de pensar en canales o en optimización del sitio web, probablemente la causa por la que no se generan ventas se debe a una propuesta de valor endeble, una política de precios obsoleta o, sencillamente, que el mercado ya está agotado, no se puede crecer más en ventas y debe crecer en otros nuevos.

La importancia de poner el foco en el verdadero problema y sus diversas causas no es una cuestión de semántica o de framework mental. Es una cuestión de toma de conciencia de que en ocasiones confundimos lo que verdaderamente es un problema y arrojamos soluciones que, lógicamente, no pueden generar impacto en el negocio a corto o lago.

Poner el foco en el problema es la esencia del Pensamiento Problem-Centric.

Las buenas empresas no satisfacen necesidades, resuelven problemas

Guillermo de Haro Rodríguez, director académico en IE Business School y co-autor del libro El pequeño libro de la filosofía estoica junto a Javier Recuenco, Presidente de Mensa España y CSO en Singular Solving, tuvo la amabilidad de hacerme llegar un caso que cambió mi manera de ver las empresas. Este caso se recoge en este libro y deseo compartirlo a continuación contigo.

El caso: La tienda de los suicidas

Debes crear una empresa que vende artículos para personas que quieren suicidarse. Piensa que debes generar rentabilidad y por lo tanto cierto nivel de recurrencia. ¿Qué producto o servicio les vas a ofrecer? ¿En qué nichos te enfocarás? ¿Cuánto les cobrarás? ¿Cómo satisfarás sus necesidades asociadas al suicidio?

Este caso, como se menciona en el libro, es un problema irresoluble. Si vendes un buen producto o servicio, te quedas sin cliente. Si vendes un producto o servicio que no satisface la necesidad de tu cliente, no te pagan y por lo tanto tu empresa va a quiebra.

Uno podría pensar en las siguientes soluciones:

1. Teléfono de la esperanza

2. Ofrecer servicios psicológicos

3. Píldoras de muerte retardada

4. Entre otros

Sin embargo, como se dice en el libro:

Para resolver este acertijo debemos pensar en lo que hay más allá de lo que expresa nuestro cliente: ¿Qué problema quiere resolver alguien que se quiere suicidar? Y no, no es morir. Un suicida es una persona que tiene un problema y considera que la única solución posible es la muerte. Al pensar en cómo matarlo nos centramos en el producto, no en el problema que quiere resolver.

¿Qué problema le hace pensar a esta persona en el suicidio como solución?

Cuando realizas esta pregunta estás poniendo el foco en las causas raíz. En aquello o aquellas cosas que provocan ese comportamiento. De esta forma, emergen clusters de causas y problemas a atajar. Aparecen tipos de cliente y de solución a medida. Aparecen mercados que podemos priorizar en función del volumen, capacidad económica, entre otros. Aparece un mercado con futuro y aparecen oportunidades para esta empresa.

Tomar conciencia de que una empresa debe ir muchas veces más allá de la necesidad percibida por los clientes es uno de los motivos por los que el Pensamiento Problem-Centric está un paso más allá del Pensamiento Customer-Centric clásico en marketing, que pone en el centro del desarrollo de producto las necesidades percibidas y expresadas de los clientes.

Customer-Centric, mercados y Doritos

Durante mi etapa como consultor freelance asesoré a varias startups que, lógicamente, habían realizado algún tipo de novedad que generaba muchas veces una nueva categoría o atacaban necesidades nicho y todavía lejos de la fase mainstream.

Este framework tan simple (y que, obviamente, se adapta a la naturaleza del caso) ayuda a enfocar los esfuerzos en, normalmente en una startup, un único punto. Obviamente, el rendimiento potencial de las categorías de la derecha no será el mismo que el de las categorías de la izquierda.

Si nos fijamos en el mundo del Software as a Service, existe una batalla encarnizada para averiguar si exactamente esa mejora o esa nueva feature va a mover la aguja o va a representar una mejora en la rentabilidad de la empresa.

Algo que aprendí cuando monté We Are Hiring con Edgar Sanjuán y Pol Gasull es que existen no solamente necesidades percibidas y no percibidas, sino que podemos complicarlo un poco más y poner en cuestión si nuestros usuarios nos expresan (o no) mejoras reales o nos dicen simples cosas al azar.

Preguntar a alguien sobre qué elementos harían que un producto fuera mejor es una cuestión compleja para el que responde porque se le atribuye la capacidad de valorar de forma racional el consumo, el cual es irracional también en software.

Un caso que me gusta explicar en clases es el Caso Doritos. En resumen, Doritos aplicó Design Thinking y detectó que a las mujeres no les gustaba mancharse los dedos cuando comían Doritos ni tampoco el crujir típico de este snack. Como consecuencia, lanzaron “Doritos para mujeres” que, obviamente, no crujían al morder ni manchaban los dedos. Pasó lo que tenía que pasar: Las redes sociales ardieron y la compañía tuvo que dar un paso atrás y pedir perdón en Twitter.

La moraleja no es que la investigación de mercados sea ineficaz (en absoluto), sino que la percepción de las necesidades y el comportamiento de consumo tiene una naturaleza irracional y muchas veces difícil de expresar con exactitud.

PepsiCo tenía datos suficientes para aseverar que a un porcentaje importante de mujeres le molestaba esos dos elementos concretos de Doritos, pero, sin razón aparente, el mercado se comportó de otra manera.

Si tomamos conciencia de que se pueden o no percibir necesidades y se pueden o no expresar de forma adecuada, nos daremos cuenta de que estaremos en un campo de minas muy complejo.

Probablemente, poner ciegamente en el centro al cliente no sea siempre lo mejor.

Conclusión

Como dice Javier Recuenco “La naturaleza del problema determina todo”.

Determina si tienes un problema resoluble o irresoluble o si tienes el tiempo y recursos suficientes para hacer todas aquellas cosas que tu empresa necesita hacer para solventarlo.

Decir que tu empresa cae porque no tiene la suficiente rentabilidad es quedarse a la orilla de la cuestión. ¿Por qué tu empresa no genera la suficiente rentabilidad? ¿Alto coste? ¿Baja facturación? ¿A qué se debe?

¿Tu ecommerce debería facturar más? ¿Por qué la solución pasa por invertir más en PPC? ¿Por qué experimentación? ¿Por qué SEO? Es el problema y su naturaleza el que determina el pool de acciones disponibles.

En el mundo B2B, es complicado que una empresa pueda auto-diagnosticarse y saber si necesita una metodología como Design Thinking o Growth Hacking o una disciplina como CRO, SEO, Email Marketing, entre otros. Es responsabilidad también de los proveedores ayudar a los clientes a enfocar qué problema hay sobre la mesa y sus causas.

En este sector es muy común confundir las consecuencias generadas (perder cuota de mercado) con problema-raíz reales (propuesta de valor irrelevante) y eso hace que muchas veces emitamos soluciones simples a problemas que, de fondo, son más complejos.

Y es así como puedes acabar.

Como en la 1ª foto de esta newsletter que lees, la que está más arriba

En crossroads.

Perdido o perdida.

Después de haber hecho todo.

Sin haber generado nada

Sin entender qué pasó

¿Qué pudo fallar?

Te equivocaste con el problema

Por lo que tus soluciones, no podían llevarte a ningún lado.

Fuentes de la 6ª edición:

1. Javier Recuenco & Guillermo de Haro - El pequeño libro de la filosofía estoica

2. Moneyball

3. HBR - Design thinking y PepsiCo

4. Crítica a Doritos para mujeres

5. Tweet de Doritos rectificando su decisión

Veremos si es así. En la pasada edición tratamos los falsos positivos y los riesgos que representan a la hora de tomar decisiones basadas en datos. En esta edición profundizaremos en la otra cara de la moneda: Los falsos negativos y los errores que cometemos a la hora de experimentar. Así empieza…

‘Datos y toma de decisiones en CRO (Parte 2)’

En Leanalytics 004 definimos ‘Falso negativo’:

Imagina que la variante (B) de nuestro experimento ofrece unos resultados poco prometedores o peores que los de nuestro grupo de control (A). Decides quedarte como estás. No vas a implementar algo que empeora o no mejora. Los datos han dictaminado sentencia. Sin embargo, puede tratarse de un falso negativo y que realmente tu variante sí sea la mejor opción.

Los falsos negativos generan la pérdida de oportunidades. Una investigación previa puede generar un insight prometedor y podemos experimentar con él a través de un test AB, pero los resultados del experimento pueden devolvernos que nuestra hipótesis es falsa, es decir, que nuestra variante no genera el impacto esperado.

A decir verdad, los falsos positivos pueden ser más destructivos para una organización por el coste directo que suponen, mientras que los falsos negativos no tienen un impacto tan grande (al menos a corto plazo) en la cuenta de explotación o en el mismo proyecto.

¿Cómo lidiar con el falso negativo?

El Poder Estadístico

El poder se define así:

¿Qué papel juega el poder estadístico en AB testing?

Uno puede pensar en el poder estadístico como la sensibilidad de un radar que escanea el cielo en busca de un dron: Queremos que sea capaz de encontrar cualquiera de ellos y por ello aumentar su sensibilidad es primordial. Si por el contrario queremos únicamente detectar aviones de +300 pasajeros, probablemente será un malgasto aumentar hasta tal nivel el grado de sensibilidad.

Otro dicho típico dice así: ‘Absence of Evidence does not mean Evidence of Absence’. Esto significa que si en un AB test hay una gran potencia (es decir, una gran sensibilidad) y no encontramos evidencias es, de facto, evidencia de que hay ausencia.

Pero hay un problema: Diseñar un experimento para que tenga un elevado poder hacia cualquier efecto mínimo de interés resultará en unos intervalos de confianza mucho menos amplios, los cuales tienen un efecto directo con los errores de tipo 1.

Es decir, intentar paliar en exceso los falsos negativos hace que haya más falsos positivos.

La potencia estadística es un cálculo que se realiza en la fase previa del experimento que, en experimentos digitales, se basa en valores hipotéticos y que no tiene un uso a posteriori de la ejecución del mismo. Si volvemos al ejemplo anterior, es similar a usar un radar que detecta objetos y, ya después, calcular si se tenía la sensibilidad apropiada una vez el radar está en funcionamiento.

Es por eso que, al menos en Online Experimentation, se recomienda, para evaluar a posteriori, utilizar intervalos de confianza o calcular p-valor para la hipótesis nula. Estos pueden responder a la pregunta más importante: ¿Qué tan bien respaldan los datos la inferencia que pretendo realizar?

En futuras ediciones ahondaremos un poco más en aspectos relacionados con el tamaño de la muestra, uno de los factores que de mejor manera pueden aumentar el poder estadístico. A continuación, evaluaremos algunos de los errorers más típicos que cometemos a la hora de experimentos

Errores en experimentación

1. Seleccionar métricas que no corresponden a objetivos comerciales

El número de clicks en un botón rara vez será un buen objetivo para tu experimento. El motivo es simple: no refleja la consecución del objetivo final de la empresa (captar leads, vender más, entre otros).

Imagina que configuramos un experimento y seleccionamos como objetivo del mismo la tasa de clicks en ‘Shop Now’. La opción de snowboard genera un mayor CTR que la opción de ciclismo, pero como los visitantes gastan mucho más dinero de media cuando eligen la oferta de ciclismo, los ingresos esperados de exponer dicha oferta a un visitante determinado son más elevados.

Un test AB cuya métrica objetivo fuera CTR elegiría una oferta que no maximizaría los ingresos.

2. Detener las pruebas antes de tiempo

El tiempo es un factor clave. Como puedes ver en esta gráfica, si detuviéramos el test antes de tiempo consideraríamos que la oferta ganadora sería la de color azul. El motivo de esto es que el número de observaciones es reducido, lo que genera que existe una alta probabilidad de que haya outliers solamente por casualidad.

A medida que el experimento se estira en el tiempo y captura más datos, el porcentaje de conversión converge hacia un punto más realista. Como podemos ver, la oferta de color rojo habría sido una oferta rápidamente descartable, pero si esperamos podemos ver que alcanza un ratio más interesante.

3. Cambiar el flujo de tráfico durante el experimento

Si iniciamos un experimento con una asignación de tráfico para el grupo de control del 80% y para la variante del 20%, no podemos modificar esa asignación a, por ejemplo, 50% respectivamente durante el experimento.

Existen distintos riesgos asociados a esto, pero el que para mí es más importante es el siguiente: Si el ciclo de venta del producto es elevado, es decir, se tarda varios días en realizar una compra, dichas conversiones demoradas pueden afectar a los informes.

Así, en esa primera experiencia en la que la asignación de tráfico pasó de 50% a 80% y el tiempo de conversión promedio son 2 días, tan solo los visitantes del 50 % de la población se están convirtiendo el primer día de la prueba; a pesar de que hoy el 80 % de la población esté entrando en la experiencia. Esto puede hacer que parezca que la tasa de conversión cae, pero se volverá a normalizar cuando este 80 % de los visitantes acaben convirtiendo.

4. La novedad y el comportamiento del usuario

Debemos tener en cuenta que, en ocasiones, una novedad en un sitio web puede ocasionar que aquellos usuarios recurrentes interactúen con ella solamente por tratarse de una novedad. Esto es ajeno a la estadística, pero no podemos olvidar que nuestros usuarios más fieles están acostumbrados a nuestro sitio web y al ver un cambio pueden sentir curiosidad, hacer clic y navegar.

También puede suceder a la inversa: Puede suceder que lanzamos una inmejorable oferta y que, al principio, los usuarios apenas interactúan con ella por la falta de costumbre y familiaridad con la misma. Para evaluar si está sucediendo el efecto de novedad, es recomendable segmentar el experimento entre usuarios nuevos y usuarios recurrentes

5. La importancia de la investigación y la segmentación

CRO tiene mucho de investigación, tanto cuantitativa como cualitativa. Si se plantea un proceso de experimentación como un “probemos cosas a ver qué pasa” sencillamente no se está entendiendo nada de esta disciplina.

La investigación, además, aporta un beneficio muy importante: Permite encontrar insights y hallar segmentos de usuarios que serán nuestro público objetivo. De esta manera los experimentos serán más fiables y estadísticamente significativos, por no decir que generarán mucho más valor para el negocio.

Lanzar un experimento para el 100% del sitio web rara vez tiene sentido. Hay que priorizar. ¿Qué queremos? ¿Testear a los usuarios mobile? ¿De todas las edades? ¿A todos por igual sin hacer distinción entre nuevos y recurrentes? ¿No diferenciaremos entre los que han iniciado sesión y los que no?

CRO es la suma de muchas disciplinas y entre ellas, también reside la investigación.

6. Engagement Bias

Unido a los 2 anteriores puntos nos encontramos con este sesgo. 'Engagement Bias' sucede cuando no generas el mismo efecto entre los usuarios que tienen engagement con tu marca y los que no. Es decir, aquellos usuarios que todavía están en fases de descubrimiento e investigación no reaccionan a ese mismo estímulo del mismo modo.

La manera de solucionar este sesgo es ampliar el tiempo de ejecución de experimentos o segmentar de manera correcta el experimento entre aquellos usuarios más recurrentes y aquellos usuarios que están todavía en fase de descubrimiento. De este sesgo hablamos en Leanalytics 003

Experimentar, leer datos y tomar decisiones

Al inicio de esta serie que acaba ahora, podemos ver que no hemos hablado de otra cosa que de datos. Números arriba, números abajo, ratios y experimentos. Todo esto debería generar una seguridad tácita de control y de que tomaremos mejores decisiones.

Nada más lejos de la realidad.

Podemos ver que existen huevos de serpiente como los falsos positivos, los falsos negativos o directamente mala praxis a la hora de ejecutar un experimento por una falta, no tanto de cultura de dato, sino de una falta de conocimiento en la exploración del dato.

Data-Driven Decision Making era como empezaba esta serie y aunque, sin duda, la cultura de tomar decisiones basadas en datos es algo muy interesante, debemos ser también críticos con aquellos datos que tenemos delante.

¿Se pueden tomar malas decisiones basadas en buenos datos? Desde luego.

Fuentes de la 5ª edición:

1. Frederik Graveter, Larry B Walnau - Statistics for the behavioral economics

2. Georgi Z. Georgiev - Statistical Methods in Online A/B Testing: Statistics for data-driven business decisions and risk management in e-commerce

3. Frederik Graveter, Larry B Walnau - Statistics for the behavioural economics

4. Stephen Wendel - Designing for behaviour change

El concepto estrella de los últimos 15 años. Ninguna conferencia tech sin él. Tomar decisiones basadas en datos es inherente a la experimentación, por ello, en esta 4ª edición de Leanalytics (que como me quedó un poco larga la he dividido en partes) hablaremos de:

‘Datos y toma de decisiones en CRO’

En la pasada edición de Leanalytics hablamos de cómo la estadística tiene un papel fundamental en técnicas de experimentación. En esta edición (y las siguientes) profundizaremos un poco más y trataremos el escabroso tema de los falsos positivos, los falsos negativos y los errores típicos que podemos cometer cuando experimentamos.

Falsos positivos

Imagina que ejecutas un test AB y los resultados de la variante son holgadamente superiores. Esperas un poco y llegas a la conclusión de que la opción B es la correcta. Lo tienes todo atado y bien atado, pero ¿es posible que sea un falso positivo?

Los falsos positivos pueden acabar con tu proyecto. Imagina que encuentras una oportunidad, convences a tu organización de que ese es el camino correcto y que se debe invertir en ella. Tienes los datos y estos te amparan.

La organización empieza a movilizar recursos y nada mueve la aguja. Se quema más dinero. Se invierte en más recursos humanos y técnicos y nada. ¿Por qué? La respuesta es evidente: Viste un espejismo. No fueron sesgos. Fueron los datos. Fue un falso positivo.

Falsos negativos

Existe la otra cara de la moneda en el asunto del falso positivo y es el falso negativo.

En este caso, imagina que ejecutas un test AB y los resultados de la variante son definitivamente peores que el grupo de control, cuando, realmente esa variante generaría mucho mejor rendimiento que el grupo de control.

Los falsos negativos significan la pérdida de una oportunidad. En este caso, los datos concluyen que no existe ese sendero en el que la organización podría invertir y lograr amplio rendimiento. Como sucede con los falsos positivos, fueron los datos los que dictaminaron sentencia.

Y como dice Al Gore, aquí viene una verdad incómoda:

No podemos hacer que los falsos positivos y los falsos negativos desaparezcan al 100%. De hecho, se intercambian entre sí. Diseñar experimentos para que la tasa de falsos positivos sea reducida aumenta la tasa de falsos negativos.

Falsos positivos & significancia estadística

Aceptados estos dos incómodos compañeros de viaje (en futuras ediciones de Leanalytics se profundizará en cómo lidiar con esto, pero para los lectores más impacientes, dejo este enlace), podemos llegar a la cuestión de “qué ratio de falsos positivos estoy dispuesto a tolerar”.

Por convención, la tasa de falsos positivos suele estar en un 5%. Imagina que trabajamos con una herramienta de detección de gatitos y perritos a través de imágenes. De cada 100 imágenes, cometeríamos un error 5 veces. Diríamos que una imagen contiene una gatito cuando realmente no es un gatito en un 5% de ocasiones.

Esta tasa tiene una estrecha relación con la significación estadística y p-valor, pero para profundizar en ello, usaremos el azar. Imagina que quiero saber si esta moneda está trucada o no, es decir si cae más veces por el lado de la cara que por el lado de águila, es decir, que la probabilidad no es del 50% para ambos lados.

Para decidir si está trucada o no, lanzaremos la moneda 100 veces y calcularemos el porcentaje de resultados de cada lado. Ya sea por aleatoriedad, el viento o porque somos un poco torpes, no esperamos exactamente 50 caras y 50 cruces, pero ¿cuánta desviación de 50 es demasiado? ¿Cuándo consideramos que tenemos pruebas suficientes para rechazar la afirmación de que la moneda es, realmente, justa?

¿Estarías dispuesto a concluir que la moneda es injusta si 60 de cada 100 lanzamientos fueran cara? ¿o mejor 70? Definitivamente, necesitamos un método para trabajar con la tasa de falsos positivos.

Primero, supondremos que la moneda no está trucada (esta sería nuestra hipótesis nula) y buscaremos pruebas convincentes contra esta hipótesis nula a partir de los datos. Para constituir una evidencia convincente, calculamos la probabilidad de cada resultado posible asumiendo que la hipótesis nula es verdadera.

Es decir, calculamos la probabilidad de que 100 lanzamientos produzcan una cara, dos caras, tres caras y así sucesivamente hasta 100 caras (suponiendo que la hipótesis nula es verdadera, es decir, que la moneda no está trucada).

Cada uno de estos posibles resultados y sus probabilidades asociadas pueden visualizarse en la siguiente gráfica y tendría una estructura tal que así, como una distribución normal:

Una vez realizado esto, podemos comparar esta distribución (calculada bajo la premisa de que la moneda no está trucada) con los datos recopilados del experimento. Si observamos que el 55% de lanzamientos en el experimento dan cara y queremos cuantificar si esta observación es evidencia convincente de que la moneda sí está trucada contaremos las probabilidades asociadas con cada resultado que es menos probable que nuestra observación.

“La posibilidad de ver un resultado tan extremo como nuestra observación si la hipótesis nula fuera cierta” es el p-valor. Básicamente, p-valor nos ayuda a diferenciar resultados que son producto del azar, de resultados que son estadísticamente significativos. Es decir, nos ayuda a lidiar con los falsos positivos.

En nuestro caso, la hipótesis nula es que la moneda no está trucada, la observación es un 55% de caras tras realizar 100 lanzamientos y el p-valor es de 0,32. Esto se interpretaría así: Si repitiéramos muchas veces el experimento de lanzar una moneda 100 veces y calculáramos el ratio de caras con una moneda no trucada (hipótesis nula cierta), en el 32% de esos experimentos el resultado mostraría al menos 55 caras o 55 cruces.

P-valor en un test AB

¿Cómo usamos P-valor para decidir si hay evidencia estadísticamente significativa de que la moneda está trucada o que nuestra variante está generando mejoras? Como se ha dicho anteriormente, la convención dice que hay un efecto estadísticamente significativo si el p-valor es inferior a 0,05.

En el caso de la moneda, se calcula un p-valor de 0,32. Debido a que el p-valor es mayor que el nivel de significancia de 0,05, se puede concluir que no hay evidencia estadísticamente significativa que la moneda esté trucada.

Llevado al caso de un Test AB, existen dos opciones:

1. Mi variante genera un cambio en el comportamiento de los usuarios (p-valor < 0,05)

2. No hay evidencia estadísticamente significativa de que la variante genere un cambio en el comportamiento de los usuarios (p-valor > 0,05)

Si tenemos en cuenta p-valor a la hora de evaluar los resultados de los experimentos, la probabilidad de tomar mejore decisiones aumentará.

Experimentar, leer datos y tomar decisioness

Los datos no mienten, pero podemos inferir comportamientos que no son reales ni representativos.

Puedes ver cómo tu variante es superior al grupo de control. Puedes esperar un tiempo más que prudencial a obtener una gran y significactiva muestra, pero no puedes ser inmune a los falsos positivos durante la experimentación en negocios digitales.

Los falsos positivos pueden acabar contigo y tu proyecto si no creas barreras y un método de trabajo que incluye la estadística. Reducir su impacto y tomar conciencia de que existen los falsos positivos es el primer paso para tomar buenas decisiones.

Tomar decisiones basadas en datos ha sido el gran leitmotiv de estos últimos 15 años a raíz del auge digital. Creer que aquello que nos entregan los datos es significativo y representativo es poco menos que un dogma de fé y debemos formarnos para interpretar este nuevo mundo que tenemos delante de nosotros.

Tomar decisiones es difícil

Tomar decisiones basadas en datos es muy difícil

Tomar buenas decisiones basadas en datos es dificilísimo.

¿Se pueden tomar malas decisiones basadas con buenos datos? Desde luego

En Leanalytics 005, continuaré con los falsos negativos, el poder estadístico y los errores que solemos cometer los marketers en el campo de la experimentación y la interpretación de resultados.

Fuentes de la 4ª edición:

1. Frederik Graveter, Larry B Walnau - Statistics for the behavioral economics

2. Georgi Z. Georgiev - Statistical Methods in Online A/B Testing: Statistics for data-driven business decisions and risk management in e-commerce

3. Towards Data Science - Tweaking a model for lower False Predictions