Notificación

Accede a consejos de optimización personalizados, averigua el estado de tu cuenta y descubre si has terminado de configurarla en la versión mejorada de Mi página de AdMob.

Guía de implementación del mapeado de contenido

En el caso de cada bloque de anuncios, se puede mapear de forma individual el contenido que hay alrededor de cada anuncio mediante setContentUrl() o setNeighboringContentUrls(). Ten en cuenta que cada bloque de anuncios debe usar solo un tipo de mapeado de contenido, no ambos.

Para utilizar el mapeado de contenido, sigue estos pasos:

  1. Instala la versión del SDK de anuncios de Google para móviles que corresponda:
    • Android: 19.0.0 o versiones posteriores para AdMob y 19.5.0 para Ad Manager
    • iOS: 6.12.0 o versiones posteriores
  2. Decide qué tipo de mapeado de contenido quieres usar para cada uno de tus bloques de anuncios. 
  3. Comprueba que las URLs que vas a transferir sean públicas (que el rastreador pueda acceder a ellas). Consulta más información sobre cómo hacer que tu sitio sea totalmente rastreable para AdMob o Ad Manager.Recuerda que no es necesario que la URL esté disponible para los usuarios.

Cómo mapear contenido por completo y con precisión

Asegúrate de que el contenido se mapee con una URL que represente lo que ven los usuarios en la aplicación. Las URLs que transfieras deben proporcionar una imagen completa y precisa del contenido que rodea al anuncio.

Nota: Aunque aceptamos capturas de pantalla de tu aplicación para asignar contenido, el formato HTML es el método recomendado.

Los ejemplos que se muestran a continuación te ayudarán a entender mejor a qué nos referimos con información completa y precisa.

Ejemplo 1: Mapeado completo (incluye todo el contenido alrededor de un anuncio)

Las URLs que transfieras deben representar por completo el contenido que hay alrededor del anuncio y contener todos los elementos adyacentes al anuncio, incluidos los que puedan aparecer en la misma pantalla o ventana gráfica que este.
En la figura 1, hay un feed de noticias de la página principal con dos elementos de contenido, el contenido A y el contenido B, que se deben mapear por separado. Tenemos tres ejemplos de mapeo para el contenido A: dos ejemplos buenos y uno malo.
En el mapeado A1, el mapeado del contenido A está completo porque la URL transmite el encabezado, la imagen y el mismo párrafo que ven los usuarios directamente encima del anuncio. Este mapeado coincide por completo con el contenido que ven en la aplicación.
En el mapeado A2, el mapeado del contenido A es aún más completo porque la URL transmite la versión completa del párrafo (por ejemplo, el feed muestra un resumen de una noticia, pero puedes transferir todo el artículo). Transferir toda la información es la mejor forma de asegurarte de que se representa por completo el contenido que rodea el anuncio.
En el mapeado A3, el mapeado del contenido A no está completo, ya que la URL solo transmite el encabezado y el mismo párrafo que ven los usuarios directamente encima del anuncio. Este mapeado no incluye la imagen, por lo que no representa por completo el contenido que hay alrededor del anuncio.
Nota: No debes transmitir información personal identificable (IPI) ni cualquier otra información que infrinja el acuerdo de privacidad con los usuarios. En AdMob o Ad Manager, puedes eliminar cualquier información personal identificable (como nombres completos, direcciones de correo electrónico o parámetros de geolocalización) que haya en las URLs de contenido que envías a Google.
 
Necesitamos que el contenido de la aplicación esté asignado de forma completa y precisa, pero todo lo que se considere IPI puede retirarse o sustituirse por un identificador único antes de enviar las URLs de contenido a Google.
Ilustración de la exhaustividad del mapeado de contenido.

Figura 2

El mapeado del contenido B sigue el mismo patrón que el del contenido A.

Ejemplo 2: Mapeado preciso

Las URLs que transfieras deben representar de manera precisa el contenido que hay alrededor del anuncio. Ten en cuenta que el contenido no puede ser preciso si no está completo.
En la figura 2, volvemos a intentar mapear un feed de noticias de la página principal. Esta vez, tenemos dos ejemplos de mapeado para el contenido A del feed de noticias.
En el mapeado A1, el mapeado del contenido A es preciso porque transmite los elementos correctos que coinciden con el contenido de la aplicación.
En el mapeado A2, el mapeado del contenido A no es preciso porque mapea el contenido Z, que no está relacionado con el contenido A. Esta no sería una representación precisa del contenido que hay alrededor del anuncio.

Ilustración de la precisión del mapeado de contenido.

Figura 2

Ejemplos de casos prácticos

Para obtener un rendimiento óptimo, es importante transferir URLs que describan detalladamente el contenido que ven los usuarios alrededor del anuncio. En primer lugar, ten en cuenta el tipo de anuncio que se muestra para decidir qué URL o URLs deberías transmitir en el mapeado de contenido. 

Los siguientes casos prácticos son ejemplos para ayudarte a decidir cómo utilizar el mapeado de contenido.

Anuncios de banner

Anuncio de banner en una sola página

Los anuncios de banner pueden aparecer en una sola página del contenido de una aplicación; por ejemplo, dentro de un artículo de noticias.

En este ejemplo, el anuncio de banner se ha implementado en una sola página y el contenido que lo rodea es estático. Esto significa que el contenido se puede transferir en una sola URL. 

En este caso, debes usar el método setContentURL() para transferir una sola URL antes de cargar la solicitud de anuncio.

Anclar anuncio de banner en una sola página

Los banners ancla siempre aparecen en la pantalla cuando el usuario se desplaza, fijado en la parte superior o inferior.

En este ejemplo, el anuncio de banner ancla se ha implementado en una sola página y el contenido que lo rodea es estático. Esto significa que el contenido se puede transferir en una sola URL.Debes enviar todo el contenido que pueda estar presente en la página mientras el banner de enlace permanece visible.

En este caso, debes usar el método setContentURL() para transferir una sola URL antes de cargar la solicitud de anuncio.

Anuncio de banner ancla en un feed

Los banners ancla siempre aparecen en la pantalla cuando el usuario se desplaza, fijado en la parte superior o inferior.

En este ejemplo, el banner ancla se ha implementado en un feed. Si implementas un banner ancla en una pantalla con varios elementos de contenido, deberás enviar una URL por cada elemento de contenido (hasta un máximo de cuatro URLs) que rodea al anuncio.Debes enviar todo el contenido que pueda estar presente en la página mientras el banner de enlace permanece visible.

En este caso, debes usar el método setNeighboringContentUrls() antes de cargar la solicitud de anuncio.

Anuncios nativos

Anuncio nativo (pantalla parcial) entre contenido

Los anuncios nativos se adaptan a la experiencia de usuario y al diseño visual de la aplicación en la que se encuentran. Los anuncios nativos pueden ocupar parte de la pantalla de una aplicación y aparecer entre diferentes contenidos, como entre artículos de noticias o fichas de compra, cuando los usuarios se desplazan o deslizan el dedo por ella. 

En este ejemplo, el anuncio nativo se muestra en consonancia con el contenido de la aplicación a medida que los usuarios se desplazan por la aplicación. Esto significa que hay contenido diferente antes y después del anuncio. 

Si tu anuncio nativo se implementa de esta forma, deberás transferir las URLs del contenido que aparece antes y después del anuncio. En este caso, debes usar el método setNeighboringContentUrls() antes de cargar la solicitud de anuncio.

Nota: Si su implementación de anuncios tiene más de dos elementos de contenido cerca del anuncio, también deberá transferir estas URLs. Puedes enviar hasta cuatro URLs que representen el resto de los elementos de contenido que pueden mostrarse en la pantalla al mismo tiempo que el anuncio.

Anuncio nativo (pantalla completa) entre contenido

Los anuncios nativos se adaptan a la experiencia de usuario y al diseño visual de la aplicación en la que se encuentran. Los anuncios nativos pueden ocupar una pantalla completa y aparecer entre el contenido de la aplicación a medida que los usuarios se desplazan por la aplicación o deslizan el dedo por ella. 

En este ejemplo, el anuncio nativo aparece entre dos contenidos distintos a medida que el usuario se desplaza. Si tu anuncio nativo se implementa de esta forma, deberás transferir las URLs del contenido que aparece antes y después del anuncio. 

En este caso, debes usar el método setNeighboringContentUrls() antes de cargar la solicitud de anuncio.
Nota: Si su implementación de anuncios tiene más de dos elementos de contenido cerca del anuncio, también deberá transferir estas URLs. Puedes enviar hasta cuatro URLs que representen el resto de los elementos de contenido que pueden mostrarse en la pantalla al mismo tiempo que el anuncio.
La interfaz de AdMob muestra un anuncio intersticial con desplazamiento vertical.

En este ejemplo se muestra el anuncio nativo cuando un usuario desliza el dedo. Independientemente de cómo se desplace el usuario, debes transferir el contenido antes y después del anuncio nativo.

La interfaz de AdMob muestra un anuncio intersticial horizontal.

Anuncios intersticiales

Anuncio intersticial en una sola página

Los anuncios intersticiales pueden ocupar una pantalla completa cuando un usuario está en una sola página, como cuando ve la ficha de un producto en una aplicación de Shopping. 

En este ejemplo, el anuncio intersticial se ha implementado en una sola página y el contenido que lo rodea es estático. Esto significa que el contenido se puede transferir en una sola URL. 

En este caso, debes usar el método setContentURL() para transferir una sola URL antes de cargar la solicitud de anuncio.

Anuncio intersticial entre contenidos

Los anuncios intersticiales pueden ocupar una pantalla completa mientras los usuarios navegan por el contenido; por ejemplo, mientras cambian de una sección a otra de su aplicación. 

En este ejemplo, el anuncio intersticial aparece entre distintas páginas de contenido. Si el anuncio intersticial se implementa de esta forma, deberás transferir las URLs del contenido que aparece antes y después del anuncio. 

En este caso, debes usar el método setNeighboringContentUrls() antes de cargar la solicitud de anuncio.
Nota: Si su implementación de anuncios tiene más de dos elementos de contenido cerca del anuncio, también deberá transferir estas URLs. Puedes enviar hasta cuatro URLs que representen el resto de los elementos de contenido que pueden mostrarse en la pantalla al mismo tiempo que el anuncio.

Anuncios bonificados

Los anuncios bonificados te permiten recompensar a los usuarios con artículos de compra en la aplicación por interactuar con un anuncio. Por ejemplo, los usuarios pueden ver un vídeo de anuncio bonificado para acceder a una noticia tras un muro de pago. 

En este ejemplo, el anuncio bonificado se muestra en una sola página (por ejemplo, el usuario ha consultado la vista previa de una noticia e interactúa con el anuncio bonificado y ha desbloqueado el artículo completo). 

En este caso, el contenido se puede transferir en una sola URL mediante el método setContentURL()

Anuncios de carga de aplicación

Los anuncios de carga de aplicación se muestran en la pantalla de carga de su aplicación cuando los usuarios abren la aplicación o vuelven a ella. 

En este ejemplo, el anuncio de carga de aplicación se ha implementado en una sola página y el contenido adyacente es estático. Esto significa que el contenido se puede transferir en una sola URL. 

En este caso, debes usar el método setContentURL() para transferir una sola URL antes de cargar la solicitud de anuncio.

Requisitos de las URLs

Ten en cuenta lo siguiente cuando selecciones URLs para usarlas en el mapeado de contenido:

  • Las URLs deben coincidir siempre con el contenido que ven los usuarios en la aplicación. Más información sobre nuestras políticas sobre contenido falso
  • No transmitas información personal identificable (IPI) ni cualquier otra información que infrinja el acuerdo de privacidad con los usuarios.
    • Puedes eliminar cualquier información personal identificable (como nombres completos, direcciones de correo electrónico o parámetros de geolocalización) que haya en las URLs de contenido que envías a Google. Necesitamos que el contenido de la aplicación esté asignado de forma completa y precisa, pero todo lo que se considere IPI puede retirarse o sustituirse por un identificador único antes de enviar las URLs de contenido a Google.
  • Google debe poder rastrear las URLs.
  • Las URLs no se deben acortar (por ejemplo, goo.gl/MiContenido).
  • El contenido que ven los usuarios en la aplicación debe tener una URL única.
    • No envíes una URL genérica para toda tu aplicación.
    • No envíes las URLs de tu aplicación de Play Store, App Store o de otras tiendas de aplicaciones.
    • No añadas parámetros de URL ni IDs de seguimiento innecesarios.
  • Si tienes un sitio web para ordenadores (como example.com) y otro sitio web para móviles (como m.example.com), elige la URL que mejor represente todo el contenido de tu aplicación. 
No uses el mapeado de contenido si el contenido no está representado en los casos prácticos de ejemplo. Si no se describe tu implementación, rellena este formulario para informarnos.

¿Te ha resultado útil esta información?

¿Cómo podemos mejorar esta página?
true
Show your support to promote DEI in Gaming by turning intentions into action!

Check out the newly launched Diversity in Gaming website, where you can find video stories and written pledges from global gaming developers. This campaign centers on 3 pillars: diverse teams, diverse games and diverse audiences showing how diversity is not just good for gamers, but for business as well. Show your support by taking the pledge to promote DEI in Gaming and share it on social!

Learn More

Búsqueda
Borrar búsqueda
Cerrar búsqueda
Menú principal
4994481266730263041
true
Buscar en el Centro de ayuda
true
true
true
true
true
73175
false
false