El contexto histórico se remonta a la evolución de los modelos freemium de límites estáticos (5GB fijos en la nube) a límites dinámicos y adaptativos basados en Machine Learning. Los enfoques clásicos para evaluar la efectividad de tales intervenciones se enfrentan a la endogeneidad fundamental: el sistema limita intencionalmente a los usuarios con una alta probabilidad de conversión predicha, creando un fuerte sesgo de selección. Los métodos tempranos de análisis correlacional proporcionaron estimaciones sesgadas, ya que ignoraron el confounding by indication, llevando a una sobreestimación del efecto del 200-300%.
La formulación del problema requiere medir el Local Average Treatment Effect (LATE) en condiciones donde la asignación del límite correlaciona con la motivación latente del usuario. El modelo predice la probabilidad de conversión $P(conv|X)$ y asigna un límite cuando $P > \tau$, lo que hace que los grupos sean incomparables en características observables y no observables. La comparación directa entre usuarios con límite y sin límite resulta en overestimation, ya que el grupo tratado es intrínsecamente "más caliente" y está dispuesto a pagar.
La solución detallada se basa en el Regression Discontinuity Design (RDD) en el umbral $\tau$ del modelo de puntuación. En la vecindad del umbral (ancho $h$), la asignación del límite es cuasi-aleatoria, ya que los usuarios con $P = \tau - \epsilon$ y $P = \tau + \epsilon$ son estadísticamente indistinguibles. Se construye una regresión continua del resultado sobre la puntuación del modelo con estimación del salto (jump) en el punto $\tau$. Para aumentar la precisión, se utiliza Causal Forest para estimar la heterogeneidad del efecto, y en la implementación faseada se usa Difference-in-Discontinuities para controlar las tendencias temporales. Alternativamente, se puede aplicar Inverse Propensity Weighting (IPW) con la estimación del propensity score a través de Random Forest, pero esto requiere la condición de unconfoundedness, que rara vez se cumple en su totalidad.
Problema
En un producto B2B SaaS para la gestión de tareas se implementó un límite dinámico en el número de proyectos activos para cuentas gratuitas. Un modelo de ML analizó más de 50 características del comportamiento y bloqueó la creación de nuevos proyectos prediciendo una probabilidad de conversión superior a 0.75. El equipo de producto observó un aumento del 40% en la conversión entre los "limitados", pero no pudo separar el efecto del límite de la auto-selección de usuarios motivados. Además, la prohibición total de los límites para la prueba era imposible, ya que eso implicaría una pérdida de $200K MRR durante el mes del experimento.
Opción 1: Comparación ingenua con datos históricos
Comparar la conversión de los usuarios actuales con límite contra la cohorte de hace dos meses antes de la introducción de la función. Pros: requiere una mínima inversión en infraestructura, evaluación rápida sin cambios técnicos. Contras: ignora completamente la estacionalidad (la caída de actividad en enero), la tendencia general de crecimiento en la conversión (el producto estaba madurando) y el efecto de novedad; da una estimación sesgada hacia el alza del 35-40% debido al sesgo de selección.
Opción 2: Prueba A/B clásica con desactivación del modelo de ML
Desactivar aleatoriamente la asignación de límites para el 15% de los usuarios, permitiendo que usen el producto sin límites independientemente de la puntuación. Pros: estándar de oro para causalidad, medición directa del Average Treatment Effect (ATE). Contras: categóricamente rechazado por C-level debido al riesgo de pérdida de usuarios "calientes", ya que el grupo de control no recibiría un desencadenante para la conversión; crea un costo de oportunidad significativo y conflictos éticos (¿por qué a unos se les permite todo y a otros no?).
Opción 3: Diseño de Discontinuidad Regresional con un enfoque híbrido
Utilizar el umbral natural de puntuación (0.75) como punto de salto, comparando usuarios con probabilidad de conversión 0.74 y 0.76 como grupos localmente aleatorizados (~5000 usuarios en la ventana ±0.05). Complementar con el Synthetic Control Method para regiones donde la implementación se ha pospuesto un mes. Pros: mantiene la lógica de negocio para el 95% de los usuarios; proporciona una estimación no sesgada del efecto local (LATE) para los usuarios "marginales"; permite utilizar la variación natural sin comprometer los ingresos. Contras: requiere una muestra grande cerca del umbral (>2000 observaciones); la estimación es aplicable solo a un subgrupo con $P(conv) \approx 0.75$, no a toda la población; es sensible a manipulaciones del umbral (se requiere McCrary test para la densidad de distribución).
Solución elegida y resultado
Se eligió RDD con un ancho óptimo de ventana mediante el método Calonico-Cattaneo-Titiunik (CCT bandwidth), complementado por Causal Forest para encontrar subpoblaciones con efecto negativo. El análisis reveló que un límite estricto aporta un +12% a la conversión para usuarios "promedio" (cerca del umbral), pero -8% a la retención para usuarios avanzados (alto engagement, pero puntuación un poco por debajo del umbral). Con base en esto, se implementó un modo híbrido: límites suaves (solo advertencia) para usuarios avanzados, límites estrictos (hard cap) para usuarios promedio. El resultado final: un aumento del 8% en la conversión manteniendo la retención a 30 días en un nivel del 96% de la base, lo que generó ingresos adicionales de $450K ARR en el trimestre sin perder usuarios clave.
¿Cómo distinguir el efecto de la restricción misma del efecto de "recordatorio" (reminder effect) sobre la versión de pago?
Los candidatos a menudo interpretan el aumento de la conversión como resultado solo de la restricción financiera, ignorando que la notificación misma sobre el límite actúa como un punto de contacto de marketing. Para aislarlo, se necesita un grupo de control adicional con "notificación suave" (solo información sobre premium sin bloqueo de la función) o analizar el tiempo entre la visualización del límite y la conversión. Si la conversión ocurre instantáneamente (en el transcurso de una hora), es probable que sea un reminder effect, si ocurre entre 3-7 días después de varios intentos de superar el límite, es un efecto real de la restricción. También se puede usar instrumental variable en forma de latencia técnica en la visualización de la notificación como una variación aleatoria en la intensidad del recordatorio, aplicando regresión 2SLS.
¿Cómo tener en cuenta los efectos de red en productos colaborativos (Notion, Figma), donde la restricción de un usuario afecta la colaboración de sus colegas?
En B2B SaaS, la restricción de un miembro del equipo crea spillover effects: los colegas pueden agregar recursos en una sola cuenta o migrar a un competidor. El clásico RDD ignora estos efectos externos, violando SUTVA (Stable Unit Treatment Value Assumption). La solución sería un cluster-RDD a nivel de equipo/espacio de trabajo, donde el tratamiento se determina por la proporción de usuarios "limitados" en el equipo, o el uso de two-stage least squares (2SLS) con la cantidad de vecinos limitados en el gráfico de red como herramienta. Es importante medir la violación mediante el análisis de la actividad de la red (network adjacency matrix) entre usuarios con diferentes estados de límites, probando la hipótesis de homophily en equipos.
¿Cómo separar el verdadero efecto de la restricción de una función específica del cambio en el uso de funciones menos valiosas (substitution bias)?
Los usuarios que se enfrentan a un límite en la función A pueden migrar a la función B (por ejemplo, de hojas de cálculo a documentos de texto), lo que crea la ilusión de alta retención, pero en realidad degrada la product stickiness y la feature adoption depth. Para medirlo, se necesita un análisis de Shannon entropy del uso de funciones (medición de la diversidad del uso) o compositional data analysis (CODA). Si la entropía disminuye después de la restricción, entonces ha ocurrido canibalización dentro del producto. La política óptima debe maximizar no solo la conversión, sino el expected LTV considerando el cambio en el patrón de uso, lo que requiere modelación a través de Markov Decision Process (MDP) o contextual bandit con una función de recompensa que tenga en cuenta la profundidad de la adopción de funciones y la engagement velocity, y no solo el hecho de la conversión.