Archivo de notas de versiones de Authorized Buyers del 2024

Estas notas de versiones están archivadas y solo las proporcionamos para su comodidad. Puede que no reflejen las funciones actuales del producto. Para ver las notas de las versiones más recientes, consulte el artículo Notas de la versión de Authorized Buyers.
Mostrar todo    Ocultar todo

Segundo trimestre del 2024

8 de abril Actualización de la subasta en tiempo real (RTB), Retirada del protocolo RTB de Google, ID proporcionado por el editor para RTB, SKOverlay compatible con todos los formatos de mApp a pantalla completa

Informes y optimización

Actualización de subastas en tiempo real

El 15 de abril del 2024, Google discontinuará las métricas video_completion_rate y click_through_rate del campo BidRequest.Imp.metric en las solicitudes de puja de OpenRTB junto con los campos BidRequest.AdSlot.video_completion_rate y BidRequest.AdSlot.click_through_rate en las solicitudes de puja de RTB de Google.

Otras novedades de productos o del Centro de Ayuda

Retirada del protocolo RTB de Google

Google retirará el protocolo de Authorized Buyers de Google el 15 de febrero del 2025 para adaptarse mejor al resto del sector. Los postores deben migrar al protocolo OpenRTB antes de que llegue ese momento. Se proporcionará más información para ayudarle con la migración.

ID proporcionado por el editor para RTB

Los identificadores proporcionados por el editor (PPIDs), que ya están en versión beta abierta, permiten que los editores envíen un identificador para limitar la frecuencia y personalizar anuncios basados en intereses en todos los dispositivos. Los editores gestionan qué postores de Authorized Buyers, postores de Subasta Abierta y SDKs reciben PPIDs. Solo los compradores de Authorized Buyers, los postores de Subasta Abierta y los postores de SDK habilitados por un editor determinado recibirán el PPID de ese editor. El ID proporcionado por el editor (PPID) no está disponible con IDs de usuario de terceros, como google_user_id, hosted_match_data, IDs de dispositivo, ni tampoco en el EEE. Consulte las notas de la versión para desarrolladores para conocer las especificaciones de protocolo. 

SKOverlay ahora es compatible con todos los formatos de aplicaciones móviles a pantalla completa

Ahora admitimos SKOverlay en todos los formatos de aplicación móvil a pantalla completa en iOS.

Para determinar la idoneidad de SKOverlay, los postores pueden hacer referencia a skadn.skoverlay en la solicitud de puja. Para utilizar esta función, los postores tendrán que definir en Google un valor para skadn.itunesitem en el objeto SKAdNetworkResponse. Los postores también deben definir el objeto skadn.skoverlay en la respuesta a la solicitud de puja para Google, tal como se indica abajo. 

  • Definir delay_seconds (protocolo Google) o delay (protocolo OpenRTB)
  • Solo vídeo: definir endcard_delay_seconds (protocolo de Google) o endcarddelay (protocolo OpenRTB)

Primer trimestre del 2024

25 de marzo Actualizaciones de la personalización y el seguimiento en dispositivos móviles

Política

Actualizaciones de la personalización y el seguimiento en dispositivos móviles

A partir del 21 de marzo del 2024, en las solicitudes de puja ya no se prohibirá la personalización de anuncios si los usuarios no dan su consentimiento a la transparencia en el rastreo de aplicaciones (ATT) en iOS 14.5 o versiones posteriores, o si eliminan su ID de publicidad en Android. Los siguientes campos deben seguir utilizándose para conocer la configuración de seguimiento y personalización de los usuarios:

  • Seguiremos rellenando el campo non_personalized_ads_reason con el motivo adecuado para otras situaciones en las que no se permita la personalización. Este campo ya no se incluirá si un usuario no acepta la transparencia en el rastreo de aplicaciones (ATT) en iOS 14.5 o versiones posteriores, o si elimina su ID de publicidad en Android.

  • Si un usuario no ha dado su consentimiento a la política ATT en iOS 14.5 o versiones posteriores o ha eliminado su ID de publicidad en Android, seguiremos definiendo limit_ad_tracking = true / lmt = 1. Para obtener información más detallada sobre el estado de ATT, consulte los campos app_tracking_authorized/atts.

11 de marzo Dar consentimiento para las solicitudes de coincidencia de cookies del EEE y el Reino Unido

Otras novedades de productos o del Centro de Ayuda

Dar consentimiento para las solicitudes de coincidencia de cookies del EEE y el Reino Unido

Las solicitudes iniciadas por partners a flujos de coincidencia de cookies en tiempo real de Google en el EEE y el Reino Unido deben proporcionar el consentimiento de los usuarios finales, de acuerdo con la Política de Consentimiento de Usuarios de la Unión Europea de Google, a través de uno de estos dos mecanismos:

  • Una cadena TCFv2 en el parámetro de URL gdpr_consent
  • El parámetro de URL process_consent=T después de obtener el consentimiento de los usuarios

A partir del 6 de marzo del 2024, las solicitudes que estén sujetas a la Política de Consentimiento de Usuarios de la Unión Europea y no proporcionen señales de consentimiento afirmativas recibirán una respuesta de error.

El ID de red del vendedor se retira del protocolo de Google

El ID de red del vendedor se quitó del protocolo de Google en febrero del 2024. Para recibir una información similar que permita identificar a un editor, empiece a utilizar el campo ID de editor (BidRequest.publisher_id). Más información sobre el ID de editor

26 de febrero Ninguna novedad

No hubo notas de la versión el 26 de febrero del 2024.

12 de febrero Ninguna novedad

No hubo notas de la versión el 12 de febrero del 2024.

29 de enero Ninguna novedad

No hubo notas de la versión el 29 de enero del 2024.

15 de enero: Motivos de errores de VAST mostrados en la interfaz de Creatividades

Solución de problemas

Motivos de errores de VAST mostrados en la interfaz de Creatividades

En la interfaz de Creatividades, puede encontrar más información para solucionar los motivos de los errores. Más información sobre cada uno de estos errores y cómo resolverlos

Política

API de subida en bloque

Los partners deben obtener el consentimiento de los usuarios finales, de acuerdo con la Política de Consentimiento de Usuarios de la Unión Europea de Google, antes de añadir un usuario a una lista. Los partners de tecnología publicitaria que usan la API de subida en bloque deben indicar que han obtenido el consentimiento legal adecuado mediante la marca process_consent.

A partir de enero del 2024, las solicitudes sin process_consent=true devolverán un error de consentimiento, pero se seguirán procesando sin cambios. A partir de marzo del 2024, las solicitudes sin process_consent=true se descartarán por completo.

Concordancia de cookies

Las solicitudes iniciadas por partners a flujos de coincidencia de cookies en tiempo real de Google en el EEE y el Reino Unido deben proporcionar el consentimiento de los usuarios finales, de acuerdo con la Política de Consentimiento de Usuarios de la Unión Europea de Google, a través de uno de estos dos mecanismos:

  • Una cadena TCFv2 en el parámetro de URL gdpr_consent
  • El parámetro de URL process_consent=T después de obtener el consentimiento de los usuarios

A partir de marzo del 2024, las solicitudes que estén sujetas a la Política de Consentimiento de Usuarios de la Unión Europea y no proporcionen señales de consentimiento afirmativas recibirán una respuesta de error.

¿Te ha resultado útil esta información?

¿Cómo podemos mejorar esta página?
Búsqueda
Borrar búsqueda
Cerrar búsqueda
Menú principal
3936002627927298589
true
Buscar en el Centro de ayuda
true
true
true
true
true
71030
false
false