IA para el growth hacking de producto: un PLG más inteligente y escalable

El crecimiento hecho a mano tiene un techo: la velocidad de un analista. Para cuando detecta la fuga en el embudo, la cohorte ya se fue. Un usuario que se atascó en el segundo paso del onboarding el martes no vuelve el jueves porque alguien haya visto la caída en el panel del miércoles. Ahí entran los modelos que deciden mientras el usuario sigue dentro, y también ahí aparece la pregunta que este texto intenta responder: cómo saber si esas decisiones automáticas ayudan o solo parecen ayudar.

Un patrón en los datos todavía no es una causa

En un modelo liderado por producto, cada clic, cada función que alguien prueba y cada pago deja un rastro. El growth hacking de hace diez años trabajaba con intuición y experimentos rápidos, y funcionaba mientras el volumen cabía en la cabeza de tres o cuatro personas. Con cientos de miles de eventos al día ya no cabe, y ahí el machine learning hace algo que el analista no puede: puntuar a cada usuario en cada sesión y proponer la siguiente acción mientras el equipo duerme.

El problema está en lo que ese operador incansable no sabe hacer. Un modelo detecta que quienes invitan a un compañero en la primera semana se quedan el doble, pero no distingue si la invitación provoca la retención o si solo invitan los equipos que ya iban a quedarse. Si empujas a todo el mundo a invitar y la causa era la segunda, el gráfico de invitaciones sube y la retención no se mueve. Separar una cosa de otra exige un diseño que permita atribuir el resultado, y ese diseño casi siempre es un experimento con grupo de control.

Lo que promete la IA es pasar de contar lo que pasó a decidir qué hacer: prever que un usuario se va a atascar e intervenir antes, o ajustar el precio de un grupo antes de que se vaya. Ese salto se apoya en tres piezas: un hallazgo, una acción ligada a él y un experimento que diga si la acción funcionó.

La IA comprime las tres, porque lee el comportamiento casi en tiempo real, recomienda el siguiente paso y puede generar hipótesis por sí misma. Comprimirlas no elimina ninguna. Un equipo que se queda con el hallazgo y la acción y se salta el experimento obtiene un sistema muy rápido para equivocarse con confianza.

Booking.com lo documentó con datos propios en el artículo que presentó en KDD 2019 sobre 150 modelos de machine learning en producción: las mejoras que un modelo muestra en la evaluación offline no se traducen de forma fiable en mejoras de negocio, y una subida de alrededor del 30% en la latencia llegó a costar en torno a un 0,5% de conversión. Lo que un modelo hace con tus usuarios solo se sabe midiéndolo con ellos.

Cada etapa del embudo falla de una forma distinta

En adquisición, el objetivo es el usuario correcto: aquel cuyo perfil y primeras sesiones anticipan un uso sostenido. Un modelo puntúa cada registro según su probabilidad de pagar (lead scoring). El presupuesto se mueve hacia las campañas que de verdad rinden, y el onboarding se adapta a lo que cada persona parece buscar en vez de enseñar a todos la misma primera pantalla. El fallo aquí es silencioso. Un modelo entrenado con los mejores clientes del trimestre pasado solo busca gente parecida a ellos. Poco a poco reduce la captación a un único perfil y deja seca la parte alta del embudo.

La defensa consiste en reservar una parte fija del presupuesto, por ejemplo entre el 5 y el 10% (un umbral que cada equipo ajusta), para tráfico que el modelo no elige. Sin esos datos, el modelo nunca descubre que se equivocaba con los segmentos que dejó de comprar.

La activación es donde el valor se gana o se pierde, y el momento pesa más que el mensaje. El modelo agrupa a los usuarios por comportamiento y separa a los que se activan de los que no. Su verdadera tarea es detectar el instante en que un usuario nuevo está a punto de atascarse y mostrarle un aviso útil justo ahí.

Un aviso impecable que llega un día tarde no rescata a nadie. Uno sencillo, disparado en el momento de duda, sí puede hacerlo. Por eso la métrica que conviene vigilar aquí es el tiempo hasta el primer valor, medido en horas, y no solo la tasa de activación a 30 días.

La retención se entiende mejor como consecuencia que como campaña: la gente se queda cuando percibe valor de forma continua. El modelo ayuda en tres cosas. Predice quién se va a ir con tiempo para actuar. Recomienda la forma de recuperarlo con más opciones de funcionar. Y destaca las funciones que encajan con cada tipo de usuario, en vez de las que marketing quiere empujar.

El margen es la condición que suele olvidarse. Una predicción de abandono con dos días de antelación sirve para un producto de uso diario y llega tarde para uno que se abre una vez al mes.

La monetización es la palanca que más se desaprovecha. La elasticidad se puede probar por segmentos en vez de suponerla, el upsell se puede sincronizar con el momento en que el usuario está listo y una caída de engagement se puede leer como riesgo de ingresos semanas antes de la baja. En suscripción, una predicción creíble del valor de vida del cliente acaba gobernando tanto el gasto de adquisición como los experimentos de precio.

La salvedad: un modelo de CLV entrenado con las cohortes de hoy se equivocará con algún segmento en cuanto el producto o el mercado se muevan. Una regla práctica es comparar cada mes el valor predicho con el ingreso real a 90 días por decil de usuarios y reentrenar cuando el error del decil superior pase del 20%, un umbral configurable y no un estándar del sector.

Una North Star que se recalibra necesita a alguien que firme

Con cuatro etapas y otros tantos modelos tirando cada uno de su métrica, el riesgo es que cada modelo optimice su trozo y el producto empeore en conjunto: el scoring trae usuarios que activan rápido pero no se quedan, y el modelo de upsell presiona justo a quien estaba a punto de irse.

Un framework North Star alinea producto, clientes y negocio en torno a una única métrica guía. Su punto débil clásico es que esa métrica se fija una vez y envejece: las acciones que hace un año predecían retención dejan de hacerlo cuando cambian el producto o el mercado.

La IA puede convertir esa métrica fija en una North Star dinámica. El sistema reevalúa de forma continua qué comportamientos anticipan la retención a largo plazo, reajusta el peso de cada uno a medida que llegan datos nuevos y reordena los paneles para que el foco del equipo siga al mercado. Funciona como una brújula que se recalibra sola, con una condición: una persona aprueba cada cambio de peso antes de que llegue a los objetivos del equipo.

La razón es vieja y conocida en economía: cuando una cifra se convierte en objetivo, deja de medir bien. La gente y los sistemas aprenden a moverla sin mover lo que de verdad importaba.

Una métrica que se recalibra sola deriva hacia lo que es fácil de mover, y nadie lo nota hasta que la retención real se separa del indicador. La firma humana no frena al sistema. Le obliga a explicar por qué el peso de una acción sube antes de que el equipo empiece a perseguirla.

El bucle compone el acierto y también el error

Lo que cambia respecto al growth hacking clásico es que las tácticas quedan conectadas en un ciclo que aprende de sí mismo. Reforge lo popularizó en 2018 con el ensayo «Growth Loops are the New Funnels», firmado entre otros por Andrew Chen: el resultado de cada vuelta alimenta la siguiente en lugar de caer al fondo de un embudo.

Con IA, el sistema observa lo que pasa dentro del producto, predice quién va a activarse o abandonar, actúa sin esperar a la siguiente reunión de planificación y devuelve cada resultado al modelo como dato de entrenamiento. Si cada vuelta deja el sistema mejor calibrado, el crecimiento se compone. Si no, el mismo mecanismo compone el error, y por eso cada paso necesita su salvaguarda:

1. Observar. Reúne comportamiento y transacciones sobre una identidad de usuario unificada; si el mismo usuario aparece partido entre dispositivos, el resto del bucle aprende sobre fragmentos.
2. Predecir. Estima el resultado (activación, churn, expansión) solo en los segmentos con historial suficiente; donde los datos escasean, una heurística explícita rinde más que un modelo mal alimentado.
3. Actuar. Lanza una sola intervención por hipótesis y déjala atribuible; varias acciones a la vez sobre el mismo usuario vuelven ilegible qué movió el resultado.
4. Aprender. Devuelve el resultado al modelo, pero mide contra un grupo de control que nunca tocaste; sin ese testigo, acabas acreditando al modelo lo que hizo la estacionalidad.

Saltarse el paso 4 rompe el bucle de una manera que no aparece en ningún panel. D. Sculley y sus coautores de Google describieron el mecanismo en «Hidden Technical Debt in Machine Learning Systems» (NeurIPS 2015): cuando un modelo influye en los datos con los que luego se reentrena, se forma un bucle de retroalimentación oculto.

El modelo que decide a quién enviar un aviso solo ve después cómo reaccionaron quienes lo recibieron. Cada vuelta se entrena sobre su propio efecto, y el modelo se vuelve cada vez más seguro de algo cada vez menos cierto. El grupo de control es lo único que corta ese circuito, y tiene un precio que conviene calcular antes de empezar.

Cuánto cuesta el grupo de control, con números

Imaginemos un SaaS, con cifras redondas e inventadas, que recibe 20.000 registros al mes y el 30% se activa en la primera semana. El equipo lanza un modelo que dispara avisos contextuales y reserva un 10% de los registros como grupo de control: 2.000 usuarios que siguen viendo el onboarding de siempre.

Al cabo de un mes, el grupo tratado (18.000 usuarios) se activa al 33%. La diferencia es de 3 puntos. ¿Es real o es suerte? Con estos tamaños, el azar por sí solo mueve la diferencia en torno a 1 punto (el error estándar sale de la raíz de 0,30 × 0,70 / 2.000 + 0,33 × 0,67 / 18.000, unos 1,08 puntos). Tres puntos son casi el triple de ese ruido, así que la mejora es real con bastante seguridad.

El coste del control también se puede contar: 2.000 × 3 puntos = 60 activaciones que no se produjeron ese mes porque esos usuarios no recibieron la mejora.

Ahora cambia un solo dato: el modelo mejora la activación en 1 punto, no en 3. Con el mismo control, 1 punto queda por debajo de un error estándar y la prueba no distingue el efecto del ruido. Quedan dos salidas, ampliar el control al 20% o esperar dos o tres meses, y las dos cuestan.

De ahí sale una regla de decisión: el tamaño del grupo de control se fija a partir del efecto mínimo que te importaría detectar. Si el efecto esperado es pequeño y el tráfico escaso, el bucle automático tardará tanto en aprender que una regla manual medida contra el mismo control puede ser la mejor opción.

Más tests por semana también fabrican más falsos positivos

La experimentación hecha a mano está limitada por las personas que la operan: alguien diseña la variante, espera a que haya señal y lee el resultado, así que los tests por trimestre dependen del tamaño del equipo.

La IA rompe ese techo. Permite lanzar tests multivariantes a una escala que nadie gestionaría a mano, la IA generativa produce microvariantes de texto y diseño que antes no se probaban por falta de tiempo, y los modelos bayesianos pueden acortar la espera al estimar la probabilidad de que una variante gane.

Esa última promesa tiene letra pequeña. Hay que fijar de antemano qué se espera antes de ver datos (el prior), cuándo se para el test y cuánto se acepta perder si se elige mal. Ramesh Johari y sus coautores mostraron en «Peeking at A/B Tests» (KDD 2017) que mirar los resultados todo el rato y parar en cuanto salen bien multiplica los falsos ganadores, muy por encima del 5% prometido. Un sistema automático que revisa cada hora es el caso extremo de ese vicio. Acabará declarando ganadoras a variantes que solo tuvieron una buena tarde.

La escala agrava el problema por otra vía. En un producto maduro la mayoría de las variantes no mueven nada, así que cada test nuevo aporta sobre todo oportunidades de error. Si lanzas diez veces más tests con la misma tasa de éxito real, las falsas victorias crecen en la misma proporción, y cada una que llega a producción se convierte en un dato de entrenamiento más del bucle.

El papel humano se desplaza: el equipo decide qué merece la pena probar, qué riesgos no se aceptan y qué umbral exige una victoria antes de escalarla, y la IA experimenta dentro de esos límites.

Ese ritmo choca pronto con un equipo que decide cada dos semanas. No hace falta cambiar de método: basta con que cada revisión de sprint incluya la de los experimentos abiertos. Un tablero que muestra la evidencia de cada experimento junto a las tareas hace más difícil que una iniciativa siga viva solo porque nadie la ha medido.

El stack vale lo que su capa más débil

Toda esa experimentación es tan buena como los datos que tiene detrás. La parte analítica se apoya en cuatro capas, y su orden importa. La analítica básica dice qué está pasando. La gestión de datos de clientes asegura que cada persona sea un solo usuario y no un montón de eventos sueltos. La segmentación convierte esos datos en grupos con los que se puede actuar. Y la experimentación automática comprueba si la acción funcionó.

Si la identidad está rota, la segmentación agrupa fragmentos de personas y el experimento mide efectos sobre «usuarios» que en realidad son dos o tres. Supón que un 15% de las personas aparece duplicada entre móvil y web. Una parte de ellas cae a la vez en el grupo tratado y en el de control, el control deja de ser limpio y la diferencia medida se encoge justo cuando más necesitas verla. En el ejemplo anterior, si una parte del control recibió de hecho los avisos, la mejora real de 3 puntos se mide más pequeña y puede caer por debajo del umbral de detección.

Ensambladas con los modelos, la automatización del engagement y la gobernanza, esas capas forman un sistema operativo de crecimiento (en inglés se habla de AI Growth OS):

Reunir las herramientas es la parte fácil, y es la que suele llevarse el presupuesto. Lo que distingue ese sistema de una colección de licencias es que las capas se hablen dentro de un mismo bucle: la infraestructura alimenta a los modelos, los modelos disparan los experimentos, los experimentos ajustan la personalización y la gobernanza deja todo el circuito auditable, con el grupo de control como pieza fija del diseño.

Cuándo un modelo sobra y cuándo empieza a pagar

Hay productos para los que todo lo anterior sobra. Uno con 2.000 registros al mes no tiene datos para entrenar un modelo de activación fiable ni tráfico para medirlo: como muestra el ejemplo anterior, una mejora de un punto tardaría meses en distinguirse del ruido.

Una regla escrita a mano («si a las 24 horas no ha creado su primer proyecto, mostrar la plantilla») se entiende, se audita y se cambia en una tarde. Para ese producto, el modelo es deuda técnica con aspecto de ventaja.

El precio del cómputo no cambia esa cuenta. La inferencia se abarata cada año; lo caro sigue siendo el dato limpio y el control que permite medir lo que hace el modelo.

La regla manual es la opción sensata mientras el volumen sea bajo o el comportamiento homogéneo. Deja de serlo cuando hay bastantes segmentos con patrones distintos para que una sola regla deje valor sobre la mesa, y bastante tráfico para medir efectos de un punto en semanas. Entre ambos extremos la estructura del bucle no cambia: las reglas manuales también se miden contra un grupo de control, y el modelo entra cuando la regla deja de mejorar.

Ni siquiera entonces el bucle se dirige solo. La IA se ocupa de lo que no escala (leer millones de eventos, puntuar a cada usuario, disparar la intervención en el momento justo) y devuelve al equipo el tiempo para decidir qué merece la pena perseguir. Por eso el crecimiento recae en equipos híbridos: la máquina propone y mide; la persona enmarca el problema, fija los límites y elige entre opciones que el modelo no sabe jerarquizar.

El primer paso es modesto. Elige una sola etapa del embudo, normalmente la activación porque el resultado se ve en días, y monta ahí el bucle completo de cuatro pasos con un grupo de control dimensionado para el efecto mínimo que te importa. Si en cuatro a seis semanas el modelo supera al control, extiéndelo a retención y monetización. Si no lo supera, revisa la identidad y el volumen antes de automatizar nada más.