Compartir a través de

Microsoft Monetize: directrices de pruebas de modificadores de segmento

  • Artículo

En este documento se describen los requisitos técnicos, las recomendaciones y los procedimientos recomendados de prueba para los clientes que planean integrar el modificador de segmento con sus campañas.

Requisitos técnicos

Los clientes que deseen usar modificadores de segmento deben ser competentes con las tareas y los conceptos que se enumeran a continuación:

  • Mecánica de subastas: los clientes deben comprender los conceptos básicos de la subasta para crear un modelo de usuario que no infravalore a los usuarios.
  • API de segmento de Batch: los clientes que realizan integraciones más sólidas (que requieren fuentes masivas de datos de segmento que entran en Monetize) se beneficiarán de un conocimiento práctico del servicio de segmento de Batch. Para los clientes que agregarán valores modificadores a través de los desencadenadores de píxeles, consulte Modificadores de nivel de página a continuación.
  • Creación de audiencia: los clientes son responsables de crear sus propios segmentos de audiencia para la segmentación, ya sea mediante la recopilación a través de píxeles de segmento o el cálculo sin conexión en función de su propio análisis.
  • Optimización: para las campañas orientadas al rendimiento, los clientes deben comprender cómo funciona nuestro algoritmo de optimización V7 para evitar redundancias si su modelo de usuario se usará junto con el nuestro. La optimización de Microsoft Advertising usa el rendimiento de los anunciantes anteriores con el mismo objetivo de píxel/clic y los datos de rendimiento en nuestra propia definición de inventario. Por lo tanto, un modificador que intenta tener en cuenta la combinación domain:user luchará contra nuestra propia optimización.
  • Datos de nivel de registro: los clientes pueden usar fuentes de distribución de datos de nivel de registro para realizar análisis de bajo nivel sobre el rendimiento de su modelo. Dado que los datos de nivel de registro incluyen los identificadores de usuario individuales a los que se aplica el modificador, el análisis de la relación exacta entre los valores del modificador y la elevación general será mucho más fácil.

Requisitos analíticos

Uno de los elementos clave del modificador de segmento es que el cliente es responsable de crear el modelo de optimización. Como resultado, Microsoft Advertising no tendrá visibilidad sobre la ciencia exacta detrás del rendimiento del modelo. Además, debido a las restricciones en nuestra base de datos de usuarios, Microsoft Advertising tampoco tendrá visibilidad sobre los valores individuales detrás de cada usuario. Por lo tanto, el cliente debe aceptar la mayor parte del análisis de prueba. Esto incluye análisis periódicos y diarios del rendimiento del modificador de segmento; puesto que el cliente creó el modelo, el cliente debe poder analizarlo.

Microsoft Advertising puede medir la elevación en un nivel alto o guiar los procedimientos recomendados de pruebas de rendimiento.

Pruebas de procedimientos recomendados

La mejor manera de probar el modificador de segmento (o cualquier estrategia de compra) es usar el método Test/Control, también conocido como pruebas A/B.

Estas son las recomendaciones para diseñar una prueba:

  • Estrategia de prueba/control: normalmente al diseñar una prueba A/B, los clientes tienden a divisiones de 10/90 en la segmentación de grupos de usuarios. Esto suele deberse a que están probando una psa creativa frente a psa para medir la verdadera elevación posterior a la vista, ya que gastar el dinero de su cliente en una PSA no es lo que se paga a la mayoría de los compradores. Sin embargo, con el modificador de segmento, el enfoque casi siempre debe ser 50/50. Si el cliente también quiere probar el rendimiento con otra estrategia de compra, como una oferta base, debe usar una configuración de pruebas 10/45/45.
  • Medición del ascensor: La medición del ascensor puede ser difícil. Algunas métricas de rendimiento, como eCPC al optimizar un clic, se cortan y secan de forma justa. Sin embargo, la optimización a una conversión posterior a la vista es más nebulosa, ya que un usuario podría haber "visto" un creativo en el sentido de que se sirvió en la página y, a continuación, se convirtió. Pero si la creatividad estaba fuera de la vista del usuario (por ejemplo, debajo del pliegue y el usuario no se desplazaba hacia abajo para verla), la creatividad no incitaba realmente al usuario a realizar la acción. Teniendo esto en cuenta, estas son nuestras recomendaciones para un enfoque de pruebas basado en los objetivos de rendimiento:
    • Clic: 50/50 split, Test/Control
    • Post Click: 10/45/45 Test/Control, con un objetivo de rendimiento en cada campaña y un PSA en el grupo de 10 usuarios
    • Post View: 10/45/45 Test/Control, con un objetivo de rendimiento en cada campaña y un PSA en el grupo de 10 usuarios

Nota:

En el caso de los enfoques Post Click y Post View , si el usuario también se dirige a usuarios sin cookies, debe configurar una campaña independiente destinada al grupo de usuarios 101 con un objetivo de rendimiento de clic.

Recomendaciones de campaña

La configuración de la campaña tendrá un gran impacto en el proceso de prueba. En la versión 7 de optimización, el rendimiento continuo de las campañas bajo un nuevo anunciante afecta a las ofertas de aprendizaje de las nuevas campañas. Por lo tanto, las campañas adecuadas para las pruebas deben tener los siguientes atributos:

  • Campañas de rendimiento continuas: Probar una campaña nueva puede tener un impacto en la comprensión de la verdadera elevación de un modificador, ya que carecemos del contexto histórico del rendimiento de una campaña. Idealmente, la campaña seleccionada para la prueba modificadora debería haber estado en curso durante al menos un mes o más, por lo que podemos saber en la prueba qué tipo de métricas de rendimiento debemos esperar de la campaña de control.
  • Presupuesto diario alto: Un presupuesto diario bajo puede dar lugar a datos incoherentes debido a la distribución del presupuesto entre grupos de usuarios. En general, cuando se usa Test/Control en un público, mejor será el presupuesto diario. Aunque un gasto diario mínimo de 250,00 USD debería funcionar, se recomienda 500,00 USD.

Enfoques de aplicación de ejemplo

modificadores de Page-Level

Los modificadores de nivel de página son cuando un valor modificador se rellena en una llamada de segmento de página normal. Por ejemplo, si un anunciante tiene una hipótesis de que debe modificar la puja en función del contenido del carro de la compra de un sitio de comercio electrónico, tendrá que calcular el valor relativo de los ingresos esperados para el contenido del carro y, a continuación, activar la llamada de segmento mediante el parámetro de cadena de consulta "&other=". Dependiendo de si el usuario ya está presente en el segmento modificador, se creará o actualizará una entrada en el modificador.

  • Ventajas: esto requiere la menor cantidad de infraestructura técnica de cualquiera de las implementaciones del modificador de segmento. Aunque requiere que el píxel tenga cierta lógica de cálculo, no se requiere ningún trabajo adicional.
  • Desventajas: no hay visibilidad sobre la relación entre los modificadores de los distintos usuarios; puede modificar todos los usuarios de una configuración en 1.5, lo que es redundante y aumentará el costo de los medios. Además, requiere comprimir un modelo complejo de valoración de pujas en un script en página, lo que ralentizará la ejecución de páginas y probablemente no será aceptable para todos los anunciantes.

Modificadores de API de segmentos por lotes

Este es el método más común y también el mejor método asincrónico por el que se puede aplicar el modificador de segmento. Los clientes pueden cargar su segmento modificador mediante el servicio batch segment de la API y aplicar el modificador a su campaña.

  • Ventajas: Dado que el cliente calculará sus datos de optimización sin conexión, tendrá una comprensión holística de su modelo de valoración de usuarios. Como resultado, podrán medir los datos de rendimiento exactos junto con las fuentes de distribución de datos de nivel de registro. Además, pueden aprovechar la característica de informes de errores del servicio de segmento de Batch para saber si su modelo de usuario se ha cargado correctamente (los incendios de píxeles en la página carecen de esta ventaja).
  • Desventajas: A diferencia de los píxeles en página, tenemos restricciones de volumen en las cargas de API de segmento de lote. Si el servicio de segmento de Batch se usa para cargas innecesariamente frecuentes, es probable que se pida al cliente que se mueva hacia un enfoque de integración del proveedor de datos.