Declarar vendedores autorizados con archivos ads.txt o app-ads.txt

Preguntas frecuentes sobre los archivos ads.txt y app-ads.txt


¿Qué información debe incluirse en los archivos ads.txt y app-ads.txt?

En estos archivos deben incluirse tantas líneas distintas como exchanges y plataformas de oferta estén autorizados a vender su inventario. En cada una de esas líneas, deben añadirse tres datos (más un cuarto campo opcional) con el formato siguiente:

<Field #1>, <Field #2>, <Field #3>, <Field #4>

  • <Field #1>: es el nombre de dominio canónico del sistema al que se conectan los postores. Puede ser el dominio operativo del sistema, si no es igual al del dominio corporativo superior, para facilitar la búsqueda de IP inversa y las consultas WHOIS, así como para determinar claramente la propiedad del sistema. En la SSP o el exchange se puede publicar el nombre de dominio que se va a utilizar.

    En las cuentas de vendedor de Google, el nombre de dominio es siempre google.com.

  • <Field #2>: es el identificador del editor asociado a la cuenta del vendedor o del distribuidor que se encuentra en el sistema indicado en el campo 1. Debe contener el mismo valor que el especificado en una transacción de SSP o exchanges (como las solicitudes de puja de OpenRTB). Normalmente, en OpenRTB es el campo publisher.id. En OpenDirect, suele ser el ID de la organización del editor. 

    En el caso de las cuentas de vendedor de Google, usa el ID de editor que se muestra en cada cuenta (por ejemplo, pub-0000000000000000). Para encontrarlo, siga estos pasos:

    En su declaración, incluya solamente el prefijo pub- y el código numérico de 16 dígitos. Elimine el prefijo específico del producto (por ejemplo, ca- o ca-video-). Si obtiene ingresos a través de varias cuentas de Ad Manager o de AdSense, debe incluir cada cuenta en una fila distinta, con su código pub- correspondiente.
    Los dominios o aplicaciones en los que haya un archivo ads.txt o app-ads.txt en el que no esté incluido el ID de editor del vendedor dejan de monetizarse mediante Ad Manager, y Google no compra anuncios en los sitios web ni en las aplicaciones correspondientes. Le recomendamos que incluya en sus archivos ads.txt y app-ads.txt los ID de editor de todos los sitios web que quiere monetizar. Consulte cómo actualizar archivos ads.txt y app-ads.txt en Ad Manager. Si utiliza la Gestión de Partners a Escala, le recomendamos que colabore con sus partners secundarios para que incluyan su ID de editor en sus archivos ads.txt/app-ads.txt.
  • <Field #3>: es el campo donde debe incluirse el tipo de cuenta o relación. Este campo no distingue entre mayúsculas y minúsculas al interpretar datos.
    • El valor "DIRECT" indica que el editor (es decir, el propietario del contenido) controla directamente la cuenta que se indica en el campo 2, así como que existe un contrato comercial y directo entre el editor y el sistema de publicidad.

      Los editores de Google que controlan directamente la cuenta indicada en el campo 2 deben especificar el valor "DIRECT".

    • El valor "RESELLER" indica que el editor ha autorizado a otra entidad a controlar la cuenta que se indica en el campo 2 y a distribuir su espacio publicitario mediante el sistema del campo 1.

      Los editores de Google que no controlen directamente la cuenta indicada en el campo 2 deben especificar "RESELLER". Por ejemplo, una cuenta de Ad Manager en la que se use la Gestión de Partners a Escala debe indicar el valor "RESELLER" en el inventario que no se gestione directamente desde la cuenta.

  • <Field #4> (Opcional): es el ID que identifica de forma única al sistema de publicidad de una entidad emisora de certificados, que se corresponde con la lista de entidades del campo 1. Trustworthy Accountability Group (TAG) es una entidad emisora de certificados, por lo que TAGID se incluiría en este campo.

    En las cuentas de vendedor de Google, el ID de TAG es f08c47fec0942fa0.

¿Qué medidas toma Google en los archivos ads.txt y app-ads.txt?

Google analiza el contenido de todos los archivos ads.txt o app-ads.txt alojados en un dominio raíz o aplicación para determinar qué cuentas de vendedor tienen permiso para servir anuncios en ese dominio o aplicación.

A continuación hace una subasta y devuelve el anuncio ganador en respuesta a las solicitudes de los sitios web que tienen archivos ads.txt o app-ads.txt que incluyan un ID de editor indicado correctamente. Si el ID incluido en el archivo no es correcto, las solicitudes no se llevarán a subasta.

Los archivos ads.txt o app-ads.txt nuevos y actualizados se detectan automáticamente, pero los cambios pueden tardar hasta 24 horas en surtir efecto.

¿Qué ocurre si un archivo ads.txt o app-ads.txt está alojado en un subdominio?

Si hay subdominios, Google rastrea y aplica los archivos ads.txt que haya, siempre que se haga referencia a ellos en el archivo ads.txt ubicado en el dominio raíz. En la herramienta de gestión de ads.txt de Ad Manager aún no aparecen los subdominios que se han rastreado.

Los subdominios no se usan en los archivos app-ads.txt y se ignorarán si se detectan. Asegúrese de que el archivo app-ads.txt no esté en un subdominio.

¿Google admite redirecciones?

Google admite una única redirección HTTP a un destino fuera del dominio raíz original (por ejemplo, example1.com/ads.txt redirige a example2.com/ads.txt). Consulte la actualización de IAB.

No obstante, se pueden crear varias redirecciones si estas llevan a una ubicación incluida en el dominio raíz original. Por ejemplo:

  • example.com/ads.txt redirige a www.example.com/ads.txt
  • example.com/ads.txt redirige a subdomain.example.com/ads.txt
  • example.com/ads.txt redirige a example.com/pagina/ads.txt

¿Qué debo hacer si mi sistema de gestión de contenido no me permite colocar un archivo en mi dominio raíz?

Póngase en contacto con el proveedor de su sistema de gestión de contenido, que debería ofrecerle la posibilidad de alojar el archivo ads.txt/app-ads.txt en su nombre.

¿Qué ocurre si Ad Manager no detecta el archivo ads.txt o app-ads.txt que he publicado en mi dominio?

Aunque se haya publicado un archivo ads.txt o app-ads.txt en un dominio, es posible que en la herramienta de gestión de ads.txt y app-ads.txt de Google Ad Manager el estado del dominio aparezca como "No se ha encontrado ningún archivo ads.txt", ya sea porque el archivo se ha implementado incorrectamente o por otros motivos relacionados con el rastreo. Más información sobre cómo comprobar si se pueden rastrear los archivos ads.txt y app-ads.txt

¿Qué ocurre si los compradores ven URL vacías o en blanco en las solicitudes de puja?

A continuación se indican algunos motivos por los que las URL de solicitudes de puja pueden aparecer en blanco o vacías:

  • Falta un archivo ads.txt o app-ads.txt en alguno de sus dominios raíz. Google analiza el archivo ads.txt o app-ads.txt de un dominio para verificar que un editor está autorizado a monetizar los dominios que se envían a los compradores en una solicitud de puja. Si falta el archivo ads.txt o app-ads.txt de un dominio, las solicitudes de puja pueden incluir URL en blanco o vacías. 

    Debe subir un archivo ads.txt o app-ads.txt a cada dominio por separado. Revise Administrar y luego Gestión de ads.txt para confirmar que se ha subido un archivo ads.txt o app-ads.txt a cada uno de sus dominios.
  • Puede que se haya producido un error de implementación si se ha publicado un archivo ads.txt o app-ads.txt en un dominio, pero Ad Manager no lo ha detectado. Consulte más información sobre cómo gestionar archivos ads.txt y app-ads.txt en Ad Manager y cómo comprobar que puedan rastrearse
  • Quizá haya algún problema con la forma en que se ha implementado el atributo de anulación "page_url" de una etiqueta Google Publisher Tag o los passbacks, lo que podría causar que se transfiera un valor de URL anulado no válido en solicitudes de anuncios a Ad Manager, y URLs en blanco o vacías en las solicitudes de puja que reciben los compradores.
¿Qué ocurre si veo dominios que no reconozco?

A continuación se indican algunos motivos por los que la página "Ads.txt" podría incluir un nombre de dominio que no reconozca:

  • El código de anuncio está anidado en varios iframes o usa un servidor de anuncios, un gestor de rendimiento u otra SSP para insertar el código de anuncio en iframes. Si el código del anuncio está anidado en un iframe, no podemos determinar la información del sitio correcta para incluir en la solicitud de anuncio. Esta situación puede producirse cuando la página incluye un iframe que apunta a otra URL del sitio que contiene la etiqueta que debe mostrarse.
  • Hay sitios web que sirven el contenido de su sitio desde su propio dominio. Por ejemplo, los resultados de la Búsqueda de Google almacenados en la memoria caché, la caché de Accelerated Mobile Pages (AMP) de Google y el Traductor de Google pueden recuperar su contenido y después publicarlo desde un dominio de Google sin iframes.

  • Se han reenviado páginas web en clientes de correo.

  • Se ha duplicado el contenido entre editores (es decir, se ha copiado de uno y pegado en otro).
     

Sugerencias sobre qué hacer si no reconoce algún dominio:

  • Si el código de un anuncio está anidado en varios iframes, es posible que deba transferir la URL de la página por la que los usuarios están navegando.
  • Si utiliza un servidor de anuncios, un gestor de rendimiento u otra SSP y ve dominios que no reconoce, póngase en contacto con el equipo de gestión de cuentas de la SSP y pregunte cómo puede asegurarse de que sus solicitudes de anuncios se envían con la información de sitio web correcta.

¿Cómo puedo configurar archivos ads.txt y app-ads.txt en WordPress?

Para crear archivos ads.txt o app-ads.txt en WordPress, le recomendamos que utilice un complemento. Si ya usa uno para colocar anuncios, posiblemente incluya una función con la que crear archivo ads.txt o app-ads.txt. Para empezar, puede probar con esta búsqueda.

¿Cómo puedo configurar archivos ads.txt y app-ads.txt en Blogger?

Puede consultar cómo hacerlo en el Centro de Ayuda de Blogger.

¿Te ha resultado útil esta información?
¿Cómo podemos mejorar esta página?