La forma incorrecta es mirar alguna variable durante el período del experimento y buscar grandes desviaciones (como algunos sugirieron), ya que esas variables podrían verse afectadas por el experimento en sí (incluso si no lo crees). Por el contrario, si elige alguna variable que claramente no se ve afectada por el experimento (por ejemplo, lluvia), entonces no está realmente probando el sesgo en su muestra que podría importar sus métricas.
Michael Hochster mencionó una idea que usamos: mirar hacia atrás en el tiempo ANTES de que el experimento comenzara a ver si la división introducida por su función de aleatorización / hash estaba equilibrada para las métricas clave. Suponiendo (y este es un requisito importante) que use una función de aleatorización / hash diferente para cada experimento (por lo que no hay efecto de arrastre), antes de que comience el experimento, debe mirar una prueba de A / A (sin diferencia) y el Las métricas clave deben estar equilibradas. Esto se describe en la Sección 3.5.4 en el documento Cinco resultados desconcertantes explicados
La extensión obvia de lo anterior es probar múltiples semillas o funciones hash y elegir la mejor, es decir, la que minimiza el delta en las métricas clave que le interesan en el período AA previo al experimento. Esta característica es una parte integral de la plataforma de experimentación de Bing.
- ¿Cuánto peso tiene un certificado de posgrado de Harvard en ciencia de datos?
- Si hiciera un curso de ciencia de datos en Hyderabad, ¿qué instituto sugeriría?
- ¿Cuáles son las mejores revistas de estudios de datos críticos?
- Actualmente, tengo SAP HANA como un conjunto de habilidades. ¿Debo elegir la ciencia de datos como mi futura carrera?
- ¿Cuáles son los buenos hitos para el aprendizaje de big data?
Otra prueba que debe hacer es lo que llamamos una prueba SRM, o un desajuste de la relación de muestra. Ver ConversionXL AB Pitfalls, trampa # 3 (diapositiva 13). Si ejecuta un experimento con porcentajes iguales asignados a Control / Tratamiento (A / B), debe tener aproximadamente el mismo número de usuarios en cada uno.
Como ejemplo, si ejecuta un experimento del 50/50% y obtiene 821,588 usuarios en control y 815,482 usuarios en tratamiento, entonces tiene un sesgo con alta probabilidad. La proporción de 50.2% en lugar de 50% tiene un valor p de 1.8e-6, por lo que la probabilidad de que esta división (o más extrema) ocurra por casualidad es menor a 1 en 500,000. Un simple verificador SRM está disponible en srmCheck.xlsx
Finalmente, más importante que verificar el sesgo en una sola muestra, uno debe buscar sesgos en el “sistema” o en la forma en que se estiman los std-devs. Esto se puede hacer mediante la ejecución de múltiples pruebas A / A y ver si las métricas son estadísticas diferentes el 5% del tiempo. Algunas métricas requieren el uso del método delta o bootstrapping (consulte la Sección 5 en Siete trampas). En algunos casos, los valores extremos pueden tener un gran impacto, por lo que es útil limitar o truncar.
Si bien no se aceptará ningún documento porque detalla un error tonto, la realidad es que los errores son una gran fuente de “sesgo” en la práctica. Es necesario ejecutar pruebas A / A para generar confianza en el sistema.
