Cualquier ajuste en el tratamiento de datos restringido por solicitud que configure se aplicará en todo el mundo. Por ejemplo, si añade parámetros de tratamiento de datos restringido a la solicitud de un usuario que sea de un estado de EE. UU. pertinente, se activará el modo de tratamiento de datos restringido y solo se servirán anuncios no personalizados.
- Configuración del tratamiento de datos restringido para páginas que utilicen etiquetas de AdSense y GPT
- Configuración del tratamiento de datos restringido para otras etiquetas
Configuración del tratamiento de datos restringido para páginas que utilicen etiquetas de AdSense y GPT
Solicitar anuncios
De forma predeterminada, cuando se envían solicitudes de anuncios a Google, no se limita el tratamiento de datos ni cómo se sirven anuncios personalizados. La selección de estos anuncios se basa tanto en el contenido de las páginas web como en el historial de los usuarios que las visitan. Google permite el envío de señales mediante etiquetas de anuncio para cumplir normativas y por motivos de privacidad, como:
- Configurar anuncios no personalizados en etiquetas de anuncio de editores de Google
(Ad Manager, AdMob, Android y iOS, y AdSense) - Etiquetar solicitudes de anuncios para usuarios del EEE que no han llegado a la edad de consentimiento
(Ad Manager, AdMob y AdSense) - Etiquetar solicitudes de anuncios como contenido dirigido a niños (TFCD)
(Ad Manager, AdMob y AdSense)Los editores pueden optar por el parámetro TFCD para etiquetar solicitudes de usuarios menores. El tratamiento de datos restringido también se activará si se define el parámetro TFCD.
En este artículo se explica cómo solicitar el modo de tratamiento de datos restringido mediante etiquetas de anuncio. Cuando se active el tratamiento de datos restringido, Google limitará el uso de los datos y solo servirá anuncios no personalizados. Si quiere activar el tratamiento de datos restringido para todos los usuarios que estén en los estados de EE. UU. pertinentes y visiten su propiedad, no es necesario hacer cambios en su etiquetado de anuncios. Consulte más información sobre el tratamiento de datos restringido, incluido cómo activarlo en la interfaz, en los Centros de Ayuda de Google Ad Manager, AdMob o AdSense.
Si prefiere activar el tratamiento de datos restringido solo para algunos usuarios, las etiquetas de anuncio asíncronas de Google Publisher Tag (GPT) y AdSense o Ad Exchange ofrecen a los editores la posibilidad de activar el tratamiento de datos restringido en páginas concretas. Esta opción puede ser útil si va a mostrar el enlace de rechazo "No vender ni compartir mi información personal". En el caso de los usuarios que se decanten por esta opción, puede determinar que incluir ese enlace es suficiente para cumplir las obligaciones normativas. Consulte los artículos sobre cómo ayudar a que los editores de Google Ad Manager, AdMob o AdSense cumplan las leyes de privacidad de los estados de EE. UU. para obtener más información sobre el modo de tratamiento de datos restringido.
- En las etiquetas GPT, inserte el siguiente fragmento de código:
googletag.pubads().setPrivacySettings({
'restrictDataProcessing': true
}); - En las etiquetas de anuncio asíncronas de AdSense y Ad Exchange, inserte este otro fragmento de código:
<ins class="adsbygoogle"
style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-0123456789abcdef"
data-ad-slot="0123456789"
data-restrict-data-processing="1"></ins>
Con estos métodos, se activará el tratamiento de datos restringido en las solicitudes de anuncios posteriores que se hagan a Google desde páginas que incluyan las siguientes etiquetas: GPT, etiquetas de anuncio asíncronas de AdSense o Ad Exchange (adsbygoogle.js
) y el SDK de IMA. Para comprobar que una etiqueta de anuncio está restringiendo el tratamiento de datos, vaya a las herramientas para desarrolladores de su navegador, localice la solicitud en cuestión y busque el parámetro &rdp=1
.
Estas mismas APIs permiten inhabilitar el tratamiento de datos restringido (y volver a activar la personalización de anuncios) transmitiendo los parámetros false
y 0
, en función de la API. Si una página contiene varios tipos de etiquetas de anuncio de Google (por ejemplo, una etiqueta GPT y otra asíncrona de AdSense o Ad Exchange), tendrá que utilizar el control del parámetro rdp de cada tipo de etiqueta.
Configuración del tratamiento de datos restringido para otras etiquetas
Etiquetas de passback de GPT
Si utiliza etiquetas de passback de GPT, puede marcar una solicitud de anuncio como tratamiento de datos restringido mediante la misma API googletag.pubads().setPrivacySettings
que se emplea en las etiquetas GPT tradicionales.
Ejemplo de código:
<script async
src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>
<div id='gpt-passback'>
<script>
window.googletag = window.googletag || {cmd: []};
googletag.cmd.push(function() {
googletag
.defineSlot('/123/sports', [300, 250], 'gpt-passback')
.addService(googletag.pubads());
googletag.pubads().setPrivacySettings({
'restrictDataProcessing': true
});
googletag.enableServices();
googletag.display('gpt-passback');
});
</script>
</div>
Solicitudes sin etiquetas
Si utiliza la función de solicitudes sin etiquetas, puede marcar que una solicitud de anuncio es de tratamiento de datos restringido añadiendo el parámetro rdp=[int]
directamente a la URL de la solicitud de la etiqueta. Le recomendamos que incluya el parámetro al principio de la etiqueta para que no se trunque. Especifique rdp=1
para marcar la solicitud de anuncio como tratamiento de datos restringido. Si se omite este parámetro, de forma predeterminada se inhabilitará el tratamiento de datos restringido y se permitirán los anuncios personalizados.
Ejemplo de código:
https://securepubads.g.doubleclick.net/gampad/ad?iu=/12345/adunit&sz=728x90&rdp=1&c=12345
SDK de anuncios de Google para móviles
Puede consultar más información sobre el SDK de anuncios de Google para móviles en el sitio para desarrolladores de aplicaciones.
- AdMob: SDK de anuncios de Google para móviles iOS y SDK de anuncios de Google para móviles Android
- Ad Manager: SDK de anuncios de Google para móviles iOS y SDK de anuncios de Google para móviles Android
SDK de anuncios multimedia interactivos de Google (para vídeo)
En las solicitudes de vídeo, puede indicar a Google que quiere aplicar el tratamiento de datos restringido a su contenido de vídeo. Para hacerlo, puede añadir una etiqueta maestra de vídeo creada manualmente (solo en Ad Manager) o utilizar los SDKs de IMA específicos de cada plataforma (SDK de IMA para HTML5, SDK de IMA para iOS, SDK de IMA para Android y SDK de IMA para Google Cast).
Si su reproductor de vídeo utiliza la función de inserción dinámica de anuncios de Ad Manager, también puede incluir el parámetro rdp=1 en las solicitudes de vídeos bajo demanda o de emisiones en directo para que se utilice en el resto de las solicitudes de anuncios incluidas (SDKs de inserción dinámica de anuncios para HTML5, Cast, iOS, Android, Roku y tvOS).
Etiquetas de anuncio de editores de Google antiguas
Hay otros tipos de etiquetas de anuncio de Google que no admiten solicitudes de anuncios con tratamiento de datos restringido; por ejemplo, las antiguas etiquetas GAM y GUT, y las etiquetas síncronas de AdSense o Ad Exchange (show_ads.js
). Recomendamos hacer la migración a alguna etiqueta que admita tanto anuncios personalizados como el modo de tratamiento de datos restringido.
AdSense para búsqueda
De forma predeterminada, en las solicitudes de anuncios a Google no se limita el tratamiento de datos y se sirven anuncios personalizados. La selección de estos anuncios se basa tanto en la consulta de búsqueda como en el historial de los usuarios que hacen las búsquedas. Cuando se active el tratamiento de datos restringido, Google limitará el uso de los datos y solo servirá anuncios no personalizados.
Puede activar el tratamiento de datos restringido en función de cada solicitud, como se describe más abajo, o pedir a su gestor de cuentas que desactive la personalización en propiedades concretas.
- En el caso de la etiqueta de anuncios de búsqueda para la Web, añada el texto siguiente al atributo
pageOptions
de la etiqueta de este tipo de anuncios:personalizedAds: false,
- Si se utiliza la etiqueta de AdMob:
builder.setAdvancedOptionValue("csa_personalizedAds", "false");
- Si se utiliza la etiqueta de iOS:
[request setAdvancedOptionValue:@"false" forKey:@"personalizedAds"];
Las solicitudes en las que se utilice cualquiera de estos métodos activarán el tratamiento de datos restringido y el servicio de anuncios no personalizados. Este parámetro no tiene estado, por lo que, si no se define en las solicitudes posteriores del usuario, se adoptará el comportamiento predeterminado (es decir, se volverán a solicitar anuncios personalizados).
Accelerated Mobile Pages (AMP)
<amp-ad type="doubleclick">
o <amp-ad type="adsense">
.En las solicitudes de anuncios procedentes de páginas AMP, los editores pueden elegir entre restringir el tratamiento de datos para todos los usuarios que estén en los estados de EE. UU. pertinentes o restringirlo de forma selectiva siguiendo las instrucciones que se indican más abajo para desactivar la personalización. Los editores pueden activar el tratamiento de datos restringido mediante la configuración para desactivar la personalización. Estos términos se emplearán como sinónimos en todo el artículo.
Solicitar anuncios no personalizados para usuarios de los estados de EE. UU. pertinentes.
Si utiliza etiquetas AMP de AdSense o etiquetas AMP de DoubleClick sin Real Time Config (RTC), puede activar el tratamiento de datos restringido desde las interfaces de Google Ad Manager o AdSense sin tener que hacer ningún cambio en sus páginas AMP.
Si sus etiquetas de anuncio AMP utilizan Real Time Config (RTC), solo se enviarán solicitudes de RTC si se da el consentimiento o si no es necesario darlo. Nota: Puede permitir que se envíen solicitudes específicas de RTC independientemente del estado del consentimiento. Puede evitar que se envíen solicitudes de RTC a los usuarios que verán anuncios no personalizados (los que estén en los estados de EE. UU. pertinentes) mediante los siguientes componentes y configuraciones (amp-geo
y amp-consent
):
<!-- Configure el componente amp-geo de forma que detecte usuarios finales de EE. UU. Por ahora, amp-geo solo admite la detección geográfica a nivel de país, pero pronto estará disponible la detección del estado de EE. UU. Especifique "unknown" cuando no se pueda determinar el país mediante amp-geo e incluya el valor "unknown" al menos en un grupo -->
<amp-geo layout=nodisplay>
<script type="application/json">
{
"ISOCountryGroups": {
"us": ["us"],
"eea": ["preset-eea", “unknown”]
}
}
</script>
</amp-geo>
<!-- Configure el componente amp-consent de forma que bloquee las solicitudes y recoja el consentimiento de los usuarios. Más adelante lo configuraremos para que rechace automáticamente el consentimiento, así que realmente no lo solicitará a los usuarios. Este componente evita las solicitudes de RTC e indica a Ad Manager y a AdSense que sirvan anuncios no personalizados. -->
<amp-consent layout="nodisplay" id="consent-element">
<script type="application/json">
{
“consentInstanceId”: “my_consent”,
“consentRequire”: false,
“geoOverride”: {
“us”: {
“consentRequired”: “remote”,
“checkConsentHref”: “https://your-endpoint”
}
}
</script>
</amp-consent>
Dado que amp-geo
todavía no puede detectar los estados de EE. UU. pertinentes, debe proporcionar un endpoint que indique a la página AMP si se necesita el consentimiento del usuario mediante el ajuste checkConsentHref
. AMP espera que el endpoint envíe un objeto JSON. Consulte más información sobre la respuesta de los endpoints en la documentación del sitio AMP.
Si la opción de configurar un endpoint no le sirve, el equipo de AMP está desarrollando una función que se lanzará próximamente para ayudar a detectar usuarios de los estados de EE. UU. pertinentes. Hasta que esa función esté disponible, puede aplicar la configuración del consentimiento a todos los usuarios de EE. UU. como solución temporal. La configuración de amp-consent
es así:
<!-- Configure el componente amp-consent de modo que bloquee las solicitudes y recoja el consentimiento de todos los usuarios que estén en EE. UU. -->
<amp-consent layout="nodisplay" id="consent-element">
<script type="application/json">
{
“consentInstanceId”: “my_consent”,
“consentRequire”: false,
“geoOverride”: {
“us”: {
“consentRequired”: “true”
}
}
</script>
</amp-consent>
Debe añadir el atributo data-block-on-consent
a cualquier componente amp-ad
de la página, tal como se indica a continuación: _auto_reject
indica a los anuncios que no esperen al mensaje de solicitud de consentimiento, sino que pasen a servir anuncios no personalizados directamente.
<!-- Por último, se configura la etiqueta de anuncio para que rechace el consentimiento automáticamente -->
<amp-ad data-block-on-consent="_auto_reject"
width=320 height=50
type="doubleclick"
data-slot="/4119129/mobile_ad_banner">
</amp-ad>
Servir anuncios personalizados o no personalizados en función del consentimiento
Dado que no es posible utilizar código JavaScript personalizado en las páginas AMP, la configuración del componente amp‑consent
y los atributos data‑block‑on‑consent
y data‑npa‑on‑unknown‑consent
se usan para determinar si se solicitarán anuncios personalizados o no personalizados. En caso de que haya configurado el componente amp-consent
y lo haya vinculado a todas las etiquetas <amp-ad>
de una página mediante data-block-on-consent
:
- Si el componente
amp-consent
detecta que un usuario ha dado su consentimiento (es decir, que ha respondido afirmativamente al mensaje que se lo pide), los anuncios se solicitan de la forma habitual. - Si el componente
amp-consent
detecta que un usuario no ha dado su consentimiento (es decir, que ha respondido negativamente al mensaje que se lo pide), se solicitan anuncios no personalizados. - Si el componente amp-consent no detecta ninguna respuesta por parte del usuario (porque el usuario ha ignorado el mensaje de consentimiento), hay dos posibilidades:
- De manera predeterminada, no se envía ninguna solicitud de anuncio.
- Cuando
data-npa-on-unknown-consent
tiene el valortrue
, se solicitan anuncios no personalizados.
- Si configura el componente
amp-geo
de tal manera que el consentimiento no pueda aplicarse basándose en la ubicación geográfica de un usuario, las solicitudes se enviarán de la forma habitual.
Si las etiquetas <amp-ad>
no usan data-block-on-consent
o si el componente amp-consent
no está bien configurado, las solicitudes se enviarán de la forma habitual.
A continuación se muestra un ejemplo de una configuración con la que se solicita el consentimiento a todos los usuarios de los estados de EE. UU. pertinentes, y que da como resultado el comportamiento descrito anteriormente:
<!-- Configure el componente amp-geo de forma que detecte usuarios finales de EE. UU. Por ahora, amp-geo solo admite la detección geográfica a nivel de país, pero pronto estará disponible la detección del estado de EE. UU. Especifique "unknown" cuando no se pueda determinar el país mediante amp-geo e incluya el valor "unknown" al menos en un grupo -->
<amp-geo layout=nodisplay>
<script type="application/json">
{
"ISOCountryGroups": {
"us": ["us"],
"unknown": ["unknown"]
}
}
</script>
</amp-geo>
<!--Configure el consentimiento para usuarios que estén en EE. UU. -->
<amp-consent layout="nodisplay" id="consent-element">
<script type="application/json">
{
“consentInstanceId” : “my_consent”,
“consentRequired”: false,
“geoOverride”: {
“us”: {
“consentRequired”: “true”,
“promptUI”: “myConsentFlow”
}
}
}
</script>
<div id=”myConsentFlow”>...</div>
</amp-consent>
<!-- Por último, se configura la etiqueta de anuncio para que espere al consentimiento cuando sea necesario o solicite anuncios no personalizados si no se detecta ninguna respuesta al mensaje de solicitud de consentimiento -->
<amp-ad data-block-on-consent
data-npa-on-unknown-consent=true
width=320 height=50
type="doubleclick"
data-slot="/4119129/mobile_ad_banner">
</amp-ad>
Puede crear su propio endpoint para solicitar el consentimiento de los usuarios de forma selectiva configurando la página de modo que envíe una solicitud POST de CORS a un endpoint a través de checkConsentHref
. Para obtener más información, consulte la documentación de amp-consent.