Microsoft Monetize: almacén de cookies del lado servidor
Los datos de usuario, como los segmentos y el número de veces que un usuario ha visto una creatividad determinada, son una parte importante del proceso de segmentación y toma de decisiones para la mayoría de las campañas. Por este motivo, es necesario mantener datos coherentes y completos sobre un usuario independientemente de dónde, cuándo o cómo los "veremos" en todo el panorama de Internet.
Tradicionalmente, los datos del usuario se almacenan en la cookie del explorador del usuario, pero en muchas subastas, Microsoft Advertising no tiene acceso al explorador. (Por ejemplo, cuando se nos pasa una llamada de anuncio del lado servidor desde un intercambio). Por lo tanto, ¿cómo reconocemos a ese usuario y accedemos a sus datos de usuario pertinentes en varios sitios y plataformas? Para ello, hemos diseñado el almacén de cookies de Microsoft Advertising, un sistema de almacenamiento de datos de usuario del lado servidor. Con el almacén de cookies y la sincronización de usuarios, podemos:
Sincronice los datos de id. de usuario y frecuencia en todos los asociados de suministro de Microsoft Advertising.
Almacene los datos de cookies, tanto los suyos como los nuestros, en el lado servidor, para que sea accesible en cada llamada de anuncio.
Nota:
Para obtener una lista exacta de las cookies establecidas por la Plataforma de Microsoft Advertising e información detallada sobre lo que contienen, consulte Cookies.
Asignación de identificadores de usuario
Si tuiésemos una etiqueta de Microsoft Advertising en cada página para cada impresión que pasara a través de nuestra plataforma, tendríamos acceso a la cookie para cada usuario que veamos. Pero nosotros no.
Supongamos que se pasa el inventario a través de una integración del lado servidor con Google Ad Manager, por lo que Google Ad Manager tiene acceso a la cookie, pero no lo hacemos. Cuando Google Ad Manager nos pasa una llamada de anuncio, identifican al usuario como ABC. Yahoo Ad Exchange llama al usuario 123 y AdMeld usa 007. Debemos saber que se trata del mismo usuario para poder aplicar los datos pertinentes y regular correctamente la segmentación de frecuencia.
El método exacto de asignación de identificadores varía en función de nuestro asociado de integración. Podemos realizar el mapa a través de un píxel en la página del publicador o mediante la entrega de un anuncio al usuario. Es posible que almacenemos la asignación de id. de usuario en nuestra base de datos o que la almacenen en la suya. Estas son algunas integraciones de ejemplo.
- Ad Network X almacena la asignación en su base de datos. Network X coloca un píxel en las páginas de sus editores, incluidos los mysite.com. Cuando un usuario visita mysite.com, el píxel se activa y Microsoft Advertising puede marcar al usuario como 1938 en la cookie del explorador del usuario. El píxel también redirige a Network X para informarles de que Microsoft Advertising llama a este usuario 1938 para que se pueda asignar al identificador de usuario de la red y almacenarlo para su uso futuro.
- Exchange Y almacena la asignación en su base de datos, pero no coloca nuestro píxel en la página. En su lugar, la primera vez que ofrecemos un anuncio a este usuario, desencadenamos un píxel asincrónico de usuario que agrega un identificador de usuario único a la cookie del explorador del usuario y redirige para pasar el identificador de usuario a Exchange Y.
- Para Exchange Z, Microsoft Advertising almacena el mapa de identificadores. En este caso, la primera vez que Microsoft Advertising publica un anuncio a un usuario, desencadenamos un píxel a Exchange Z, que luego nos pasa su identificador de usuario, que almacenamos. Ahora, en futuras impresiones, Exchange Z nos envía su identificador de usuario y podemos buscarlo en nuestra base de datos.
Sincronización entre centros de datos
Una de las cosas en las que estamos muy centrados es en asegurarse de que todos los datos de usuario están disponibles en todos los centros de datos de Microsoft Advertising. Actualmente tenemos centros de datos en Los Ángeles, la región metropolitana de Nueva York y Ámsterdam, y los usuarios se enrutan a la topología más cercana. Esto significa que los usuarios en medio de la Estados Unidos a veces se pueden enrutar a Nueva York y a veces a Los Ángeles. O bien, en el caso de un punto de conexión de red en un centro de datos, todo el tráfico se enrutaría al otro centro de datos.
Supongamos que tenemos un usuario en Dakota del Norte que ve un creativo seis veces. Tres de esas veces el usuario fue enrutado al centro de datos de Nueva York y tres de esas veces fueron enrutados a La.
En la séptima impresión, el usuario se enruta a Nueva York. Necesitamos saber que ya han visto este creativo seis veces, en lugar de las tres que se grabaron en Nueva York. Por lo tanto, hemos diseñado nuestros centros de datos LAX y NYM para sincronizarse pasando datos de segmentos de ida y vuelta, mientras que AMS conserva sus propias cookies exclusivamente.
Almacenamiento de datos de segmentos del lado servidor
Los datos de segmento, ya sean pasados a través de un segmento o a través de una transferencia sin conexión, se almacenan en el Almacén de cookies en lugar del explorador del usuario. De esta manera, los datos del segmento están disponibles en todos los orígenes de inventario, intercambios de terceros y agregadores de inventario.
También puede actualizar los datos de segmento en cualquier momento sin tener acceso al usuario a través de nuestra API batch segment.