Piensa en la última vez que una aplicación te hizo resoplar por culpa de un anuncio. Probablemente no fue porque existiera publicidad, algo que en una app gratuita casi todo el mundo da por hecho, sino por cómo ese anuncio afectó a tu flujo de trabajo: el botón que se movió justo cuando ibas a pulsarlo, la pantalla completa que apareció al volver de copiar un código, el vídeo que te prometía una recompensa que nunca llegó. Lo que se recuerda no es el anuncio. Es la interrupción, el error, la sensación de que la aplicación dejó de estar de tu lado durante unos segundos.
Esa es la idea que recorre todo este artículo: no es la publicidad, es la experiencia. Un banner puede ocupar siempre la misma zona de la pantalla y apenas llamar la atención. Un intersticial (interstitial) puede bloquear toda la interfaz durante unos segundos. Un anuncio recompensado (rewarded) puede ser aceptado voluntariamente, e incluso buscado por el propio usuario. Los tres son formatos distintos, pero la diferencia que de verdad importa no está en su aspecto, sino en cómo se insertan en el recorrido de quien usa la aplicación: qué estaba haciendo justo antes, qué puede hacer mientras el anuncio está presente y en qué situación queda cuando desaparece.
Por eso conviene dejar de pensar en los anuncios como piezas que se pegan encima de una pantalla y empezar a pensarlos como lo que son en la práctica: eventos que ocurren dentro de un flujo. Una sesión de uso es una sucesión de intenciones, tareas, esperas y transiciones, y cada anuncio aparece en algún punto de esa secuencia. Si cae en un hueco que el flujo ya tenía, apenas se nota. Si lo corta, lo retrasa o lo desvía sin permiso, el usuario suele culpar al producto. Una misma aplicación puede usar los formatos adecuados para su modelo de negocio y, aun así, ofrecer una experiencia frustrante, simplemente porque los ha colocado en el lugar equivocado del recorrido.
Este es el tercer artículo de la serie sobre monetización publicitaria. En el primero vimos cómo funciona el mercado publicitario y el recorrido que va desde una solicitud hasta una impresión. En el segundo vimos cómo elegir un modelo de monetización coherente con cada producto y presentamos los formatos a grandes rasgos, como herramientas al servicio de esa decisión. Ahora toca la parte más visible para el usuario: cómo convertir esa decisión en una experiencia concreta, en la que la publicidad acompañe el flujo de uso en lugar de competir con él.
Formato, emplazamiento, momento y regla: cuatro cosas distintas
En el primer artículo de la serie definimos el emplazamiento (placement) con la “metáfora” de la valla publicitaria: el poste fijo donde se puede colgar un cartel, frente a la unidad publicitaria (ad unit), que es la configuración técnica que decide qué cartel se cuelga cada vez. Aquella distinción servía para entender el inventario desde el punto de vista del mercado. Para implementar publicidad dentro de una interfaz necesitamos afinar un poco más, porque en la práctica “emplazamiento” se suele usar para referirse a cuatro cosas que conviene separar.
El formato es la forma del anuncio: banner, intersticial, anuncio recompensado, anuncio nativo (native) o anuncio de apertura (app open). Describe qué aspecto tiene, cuánto espacio ocupa y cómo se relaciona con la interfaz, pero no dice nada sobre dónde ni cuándo aparece.
El emplazamiento, en sentido estricto, es el lugar concreto de la experiencia donde ese formato puede aparecer: la parte inferior de la pantalla de resultados, la quinta posición del muro (feed), la transición entre un nivel y el siguiente.
El momento de impresión es el instante exacto en el que el anuncio se muestra, y suele estar ligado a un evento de la aplicación: el usuario ha terminado una partida, ha cerrado un artículo, ha vuelto a abrir la app después de varias horas.
La regla de presentación es el conjunto de condiciones que determinan si, llegado ese momento, el anuncio puede mostrarse o no: si ha pasado suficiente tiempo desde el anterior, si el usuario tiene una compra que elimina la publicidad, si existe consentimiento, si es su primera sesión.
Un ejemplo ayuda a verlo con claridad. “Intersticial” describe el formato. “Después de completar un nivel” describe el emplazamiento y el momento. “Como máximo una vez cada cierto tiempo, nunca en los primeros niveles y nunca si el usuario ha comprado la versión sin anuncios” describe la regla de presentación. Las cuatro piezas juntas forman algo que un equipo puede implementar, probar y revisar. Cualquiera de ellas por separado es solo una intención.
Esta distinción tiene una consecuencia práctica inmediata: la mayoría de los problemas de experiencia que se atribuyen a un formato (“los intersticiales son molestos”) son en realidad problemas de momento o de regla. El formato rara vez es el culpable. Lo que falla es que no se ha definido con precisión cuándo puede aparecer, o que la regla que lo limita no existe, o existe solo en la cabeza de quien lo programó. Dicho de otro modo: tres de las cuatro piezas tienen que ver con el recorrido del usuario, no con el anuncio.
El flujo del usuario: dónde tiene sentido un anuncio y dónde no
Antes de entrar en cada formato hace falta un mapa, y ese mapa no es la lista de pantallas de la aplicación, sino el recorrido que hace el usuario a través de ellas. Es la pregunta que más influye en cómo se percibe cualquier anuncio, sea del formato que sea: ¿en qué punto del flujo se encuentra el usuario cuando aparece?
En el artículo anterior relacionamos la tolerancia a la publicidad con el tipo de aplicación y con lo que el usuario está haciendo en general. Ahora vamos a mirarlo a una escala mucho más pequeña, la del instante concreto: no qué tipo de app es, sino qué está pasando en el recorrido en el momento exacto en que se dispara el anuncio. Una misma aplicación atraviesa decenas de estados distintos en una sola sesión, y cada uno ofrece una tolerancia muy diferente.
Antes de una acción. El usuario acaba de abrir una pantalla o está a punto de empezar algo: pulsar “jugar”, abrir un documento, iniciar una búsqueda. Es generalmente un mal momento, porque el anuncio se interpone entre la intención y su cumplimiento. El usuario tiene un objetivo claro y el anuncio lo retrasa, lo que convierte la publicidad en un obstáculo explícito. La excepción natural es el anuncio recompensado que el propio usuario solicita antes de empezar, porque en ese caso el anuncio forma parte de su intención.
Durante una acción. Mientras el usuario está en mitad de una tarea —jugando una partida, escribiendo, reproduciendo un vídeo que ha elegido, completando un formulario—, el anuncio compite directamente con lo que está haciendo. Debe evitarse salvo en casos muy específicos donde el formato está pensado para ello, como un banner que convive sin interrumpir, o pausas publicitarias en contenido de vídeo largo, donde existe una convención que el usuario ya conoce y acepta.
Incluso esa convención tiene límites, y las retransmisiones en directo son el mejor ejemplo de lo contrario. En una película o en un vídeo grabado, el anuncio detiene el contenido, y cuando termina, el usuario retoma el contenido exactamente donde lo dejó. En un directo no hay pausa posible: el evento sigue ocurriendo mientras el anuncio ocupa la pantalla. Muchas plataformas de vídeo en directo insertan cortes publicitarios en cualquier momento de la emisión, sin tener en cuenta lo que está pasando, y el resultado es conocido por cualquiera que haya visto un partido, una partida o un evento en streaming: vuelves del anuncio y te has perdido el gol, la jugada decisiva o el momento que todo el mundo comenta en el chat. El usuario no solo ha sido interrumpido, sino que ha perdido algo que no puede recuperar, justo aquello por lo que estaba ahí. Es la forma más pura de anuncio “durante una acción”, y explica por qué las plataformas más cuidadosas vinculan esos cortes a pausas reales de la emisión, dejan que sean quienes emiten los que decidan cuándo lanzarlos o reducen su impacto, por ejemplo mostrando el anuncio en una ventana reducida mientras el directo sigue visible.
Después de completar una acción. Si el resultado ya está confirmado y visible, y el usuario no espera una respuesta inmediata de la aplicación, puede ser un buen momento. La clave está en ese “ya confirmado”: el usuario ha cerrado mentalmente la tarea y sabe que ha salido bien. Un intersticial que aparece después de que el usuario haya visto su puntuación final es muy distinto de uno que aparece antes de que la puntuación se muestre.
Entre unidades claramente separadas. Niveles, artículos, episodios, partidas o tareas independientes ofrecen transiciones naturales, porque el propio subproceso ya marca un final y un principio. El usuario entiende la pausa porque la estructura del contenido la hace evidente. Es, con diferencia, el momento más natural para los formatos que interrumpen.
Durante una espera inevitable. Cuando la aplicación tiene que hacer algo que lleva tiempo —procesar un vídeo, generar un informe, sincronizar datos—, un anuncio puede ocupar esa espera sin añadir fricción, siempre que se cumplan dos condiciones: que la espera sea real y no se alargue para acomodar el anuncio, y que la aplicación siga funcionando con normalidad si el proceso termina antes que el anuncio, o si el usuario prefiere hacer otra cosa mientras tanto.
Lo interesante de pensar en estados en lugar de en pantallas es que obliga a mirar la experiencia como la ve el usuario. Para el código, “volver a la pantalla principal” es siempre el mismo evento. Para el usuario puede ser el final de una tarea, el regreso de una consulta rápida o una forma de salir de un error. Solo el primero es un buen momento para un anuncio.
Con este mapa delante, cada formato se entiende mejor por la relación que mantiene con el flujo que por su aspecto. El banner convive con el recorrido sin detenerlo. El intersticial ocupa una transición. El anuncio recompensado abre un desvío que el propio usuario elige tomar. El anuncio nativo viaja dentro del contenido. Y el anuncio de apertura se coloca en el umbral de la sesión, justo antes de que el recorrido empiece. Cada una de esas relaciones tiene sus propias exigencias, y son las que vamos a ver a continuación.
Banner: convivir con el flujo sin alterarlo
El banner es el único formato que no elige un momento del recorrido: está presente durante todo él. Esa es su ventaja, porque nunca detiene al usuario, y también su exigencia, porque la única forma de que funcione es que el flujo siga exactamente igual que si no estuviera. Es el formato más sencillo de integrar y, precisamente por eso, el que más se descuida. Sus problemas no se perciben como un golpe puntual, sino como un roce continuo: una interfaz que se mueve, un botón que queda incómodo de pulsar, una zona de la pantalla que parpadea cada cierto tiempo. Ninguno de esos detalles hace que alguien desinstale la aplicación en el momento, pero todos suman.
Reservar el espacio antes de que llegue el anuncio
Cuando una pantalla se dibuja, el anuncio todavía no existe. La aplicación lo solicita, el mercado tarda unos cientos de milisegundos en responder, y el creativo tiene que descargarse y renderizarse. Si la interfaz no ha reservado el hueco que va a ocupar, en el momento en que el banner llega todo lo que está alrededor se desplaza para hacerle sitio. Es el llamado salto de diseño (layout), y es especialmente dañino porque ocurre justo cuando el usuario ya ha empezado a interactuar con la pantalla: estaba leyendo la primera línea o tenía el dedo de camino a un botón.
Cualquiera que lea noticias en el móvil conoce la versión más exasperante de este problema. Abres un artículo, empiezas a leer y, sin haber tocado nada, el texto salta de golpe: el párrafo que estabas leyendo desaparece hacia abajo, o hacia arriba, y tienes que buscar con la vista dónde te habías quedado. Unos segundos después vuelve a ocurrir, porque otro bloque publicitario más abajo ha terminado de cargar, o porque un anuncio que ya estaba se ha refrescado con otro de altura distinta. Ninguno de esos anuncios ha pedido nada al lector, pero entre todos le han quitado lo único que había ido a hacer: leer de forma continua. Es el ejemplo perfecto de por qué no es la publicidad, sino la experiencia, porque el lector no recuerda qué se anunciaba en esos bloques, recuerda que no le dejaron cumplir su objetivo, leer una noticia, artículo o texto cualquiera.
La solución es reservar la altura desde que se construye la pantalla, antes incluso de pedir el anuncio. Con banners de tamaño fijo esto es trivial, porque la altura se conoce de antemano. Con los banners adaptativos, que ajustan su tamaño al ancho disponible para aprovechar mejor la pantalla, la altura depende del dispositivo, pero los SDK habituales permiten calcularla a partir del ancho antes de hacer la solicitud. Ese cálculo es el que debería usarse para dimensionar el contenedor, de manera que cuando el anuncio llegue simplemente ocupe un espacio que ya estaba ahí.
En la web este problema tiene incluso nombre propio dentro de las métricas de rendimiento: el CLS (Cumulative Layout Shift), una de las Core Web Vitals que utiliza Google para evaluar la experiencia de una página. Un bloque publicitario sin altura mínima reservada es una de las causas más habituales de un mal CLS, con lo que el coste no es solo de experiencia, sino también de posicionamiento.
No colocarlo junto a controles accionables
Un banner pegado a la barra de navegación inferior, a un botón de acción flotante o al teclado virtual es una invitación al clic accidental. El usuario quería pasar a otra pestaña y termina en una tienda de aplicaciones. Ese clic cuenta en las estadísticas, pero no vale nada: el usuario vuelve en dos segundos, molesto, y el anunciante ha pagado por una visita sin intención alguna. Las plataformas publicitarias lo saben, y por eso sus políticas prohíben explícitamente colocar anuncios de forma que favorezca los clics involuntarios; un patrón sostenido de clics accidentales puede acabar en una limitación del servicio o en la suspensión de la cuenta.
Separar el banner de los controles con un margen claro, o con un elemento visual que marque el límite, es una decisión de diseño pequeña con un efecto grande. También conviene comprobar qué ocurre cuando aparece el teclado: en muchas pantallas con formularios, el banner inferior acaba situado justo encima de las teclas, o tapando el botón de enviar.
Fijo, adaptativo o colapsable
No todos los banners se comportan igual, y la elección afecta a la experiencia tanto como la ubicación. El banner de tamaño fijo es predecible pero desaprovecha espacio en pantallas anchas, donde queda como una franja estrecha centrada con dos márgenes vacíos. El adaptativo anclado ocupa todo el ancho y suele rendir mejor, a cambio de una altura variable que hay que calcular. Existe también una variante en línea, pensada para insertarse dentro de contenido desplazable, donde la altura puede ser mayor porque el usuario la recorre al desplazarse en lugar de tenerla siempre delante.
El caso más delicado es el banner colapsable: un banner que aparece inicialmente con un tamaño mayor, superpuesto a parte del contenido, y que el usuario puede contraer hasta su tamaño normal. Puede funcionar bien si se muestra en momentos concretos, como la entrada a una pantalla nueva, pero se convierte en una molestia si vuelve a expandirse con cada refresco. Si se utiliza, la regla de presentación tiene que dejar claro cuándo se permite la versión expandida y cuándo debe pedirse solo la normal.
Tipo de banner |
Ventaja principal | Lo que exige de la implementación |
|---|---|---|
| Fijo | Altura conocida, comportamiento predecible | Aceptar espacio desaprovechado en pantallas anchas |
| Adaptativo anclado | Aprovecha el ancho completo | Calcular la altura antes de la solicitud y reservarla |
En línea (inline) |
Se integra en contenido desplazable | Controlar que no rompa el ritmo de lectura |
| Colapsable | Más visibilidad en momentos puntuales | Limitar cuándo puede aparecer expandido |
Qué hacer cuando no hay anuncio
Como vimos en el primer artículo, no todas las solicitudes encuentran un anuncio. Para el banner, esto plantea una pregunta de diseño que casi nadie se hace hasta que lo ve en producción: ¿qué se muestra en ese hueco reservado cuando no llega nada?
Hay tres respuestas razonables. La primera es mantener el espacio vacío o con un fondo neutro, lo cual preserva la estabilidad del diseño pero deja una franja muerta. La segunda es colapsar el contenedor, lo que recupera el espacio pero reintroduce el salto de diseño si el anuncio llega más tarde. La tercera, y a menudo la más interesante, es rellenar ese espacio con contenido propio: una promoción interna de la versión sin anuncios, de otra aplicación del mismo desarrollador o de una función del producto que el usuario todavía no ha descubierto. Estos anuncios propios (house ads) no generan ingresos publicitarios directos, pero convierten un hueco vacío en una oportunidad de conversión hacia otras fuentes de ingreso, algo especialmente útil en productos con modelo híbrido.
Refrescar con moderación, y solo cuando se ve
Un banner que permanece en pantalla durante mucho tiempo puede refrescarse para mostrar un anuncio distinto, lo que genera nuevas impresiones sin que el usuario cambie de pantalla. Las plataformas suelen permitir configurar ese intervalo; AdMob, por ejemplo, admite refrescos entre 30 y 120 segundos y recomienda 60. Bajar al mínimo puede parecer una forma fácil de multiplicar impresiones, pero cada refresco es un cambio visual en la periferia de la atención del usuario, y un banner que cambia constantemente deja de ser discreto.
Hay un detalle técnico que importa más que el intervalo: no refrescar ni solicitar anuncios cuando el banner no está realmente en pantalla. Si la aplicación pasa a segundo plano, si el usuario abre un diálogo modal que lo tapa o si el banner está en una pestaña que no es la activa, seguir pidiendo anuncios solo genera solicitudes que no llegarán a verse, empeora las métricas de visibilidad del inventario y consume datos y batería.
Estar en la interfaz no es lo mismo que ser visto
Esto nos lleva a una distinción que conviene tener presente con cualquier formato, pero especialmente con el banner: que un anuncio esté renderizado en la interfaz no significa que alguien lo esté viendo. El sector utiliza un estándar de referencia, definido por el Media Rating Council
, según el cual un anuncio gráfico (display) se considera visible cuando al menos el 50% de sus píxeles permanece en pantalla durante un segundo continuo (dos segundos en el caso del vídeo). Un banner en línea que se carga al final de una lista que el usuario nunca alcanza, o uno que queda detrás de una barra de herramientas semitransparente, puede contar como impresión en algunos sistemas y no alcanzar nunca ese umbral.
Los anunciantes valoran cada vez más la visibilidad real, y un inventario con baja visibilidad termina pagándose peor. Pero, más allá del dinero, comprobar si el banner se ve de verdad es una buena forma de detectar problemas de diseño: un anuncio que nunca se ve probablemente está en un lugar donde no aporta nada a nadie.
Pantallas pequeñas, grandes y todo lo que hay en medio
Un banner que queda equilibrado en el móvil del equipo de desarrollo puede ocupar un porcentaje desproporcionado de la pantalla en un teléfono compacto en horizontal, o perderse en una tableta. También hay que contar con las zonas seguras de los dispositivos modernos —muescas, barras de gestos, esquinas redondeadas—, que pueden cortar parte del anuncio o dejarlo pegado a un gesto del sistema. Probar el emplazamiento en al menos un dispositivo pequeño, uno grande y en ambas orientaciones debería ser parte del proceso, no algo que se descubre por las reseñas.
Intersticial: ocupar una transición, no fabricarla
El intersticial (interstitial) es, por definición, una interrupción: ocupa toda la pantalla y detiene temporalmente el recorrido. Eso no lo convierte en un mal formato. Lo convierte en un formato que solo funciona en un lugar muy concreto del recorrido, las transiciones que identificamos al analizar el flujo del usuario, y que exige precisión, porque cualquier error de momento se percibe de inmediato y de forma muy directa.
Toda la implementación de un intersticial gira en torno a una pregunta que conviene hacerse antes de escribir una sola línea de código:
¿La aplicación ya ha llegado a un punto de pausa, o estamos fabricando una pausa para poder mostrar el anuncio?
Si la pausa existe —el nivel ha terminado, el artículo se ha leído, la exportación se ha completado y el resultado está en pantalla—, el intersticial aprovecha un hueco que ya estaba ahí. Si la pausa no existe y se crea artificialmente —una pantalla de carga que no carga nada, un retraso antes de mostrar un resultado que ya estaba listo—, el usuario lo nota, aunque no sepa explicar exactamente qué ha pasado.
Cargar antes, mostrar después
Un intersticial no debería solicitarse en el momento en que se quiere mostrar. Para entonces es demasiado tarde: la carga puede tardar uno o dos segundos, o fallar, y durante ese tiempo la aplicación queda en un limbo incómodo. El patrón correcto es precargarlo con antelación —al entrar en la partida, al abrir el artículo, al empezar la tarea— para que, cuando llegue el punto de pausa, el anuncio ya esté disponible y la aplicación solo tenga que mostrarlo.
Esa precarga tiene un matiz: los anuncios cargados no duran indefinidamente. En AdMob, por ejemplo, un intersticial cargado caduca al cabo de una hora. Si la aplicación precarga uno al abrirse y el usuario pasa dos horas en una tarea larga, el anuncio que se intente mostrar al final ya no será válido. La lógica de precarga tiene que contemplar esa caducidad y volver a solicitar el anuncio cuando sea necesario, en lugar de asumir que lo que se cargó una vez sigue sirviendo.
Nunca durante una acción crítica
El intersticial no debe aparecer mientras el usuario está haciendo algo que importa: rellenando un formulario, en mitad de una partida, confirmando un pago, escribiendo un mensaje. Esto parece obvio cuando se formula así, pero en el código no siempre lo es. Un intersticial que se dispara con un temporizador (“cada X minutos”) no sabe qué está haciendo el usuario en ese momento, y tarde o temprano aparecerá en el peor instante posible. Por eso es preferible ligarlo siempre a eventos de la aplicación que marquen el final de algo, nunca al paso del tiempo por sí solo.
Un caso especialmente traicionero es el del anuncio que aparece antes de confirmar que una operación ha terminado. El usuario pulsa “guardar”, la aplicación lanza la petición al servidor y, sin esperar la respuesta, muestra el intersticial. Si la operación falla mientras el anuncio está en pantalla, el usuario lo cierra y se encuentra con un error que no entiende, o peor, sin ningún mensaje, creyendo que todo se ha guardado. El orden correcto es siempre el contrario: primero se confirma el resultado y se muestra al usuario, y solo después, si procede, aparece el anuncio.
Puntos de salida claros, no pantallas sin contexto
El mejor momento para un intersticial es aquel en el que el usuario acaba de cerrar mentalmente una unidad de uso y está a punto de elegir la siguiente. El peor es aquel en el que ni siquiera sabe qué acaba de hacer. Un ejemplo típico de lo segundo es mostrar el anuncio al volver de una pantalla secundaria —ajustes, perfil, ayuda— a la pantalla principal. Desde el punto de vista del código es una transición como cualquier otra; desde el punto de vista del usuario, no ha terminado nada. Simplemente ha mirado algo y ha vuelto.
Lo mismo ocurre con el intersticial ligado a la navegación (“cada vez que se abre esta pantalla”). Convierte una acción rutinaria en una lotería: el usuario no sabe si tocar un botón le llevará a donde quiere ir o a un anuncio, y empieza a dudar antes de navegar. Las propias políticas de las plataformas desaconsejan explícitamente los intersticiales que aparecen tras cada acción del usuario o de forma inesperada.
Nunca justo después de otro anuncio
Un intersticial inmediatamente después de un anuncio recompensado que el usuario acaba de ver voluntariamente, o justo detrás de un anuncio de apertura, es una de esas combinaciones que nadie diseña a propósito pero que aparecen cuando cada formato tiene su propia lógica independiente. El usuario acaba de ceder su atención, cierra el anuncio y se encuentra con otro. La regla de presentación de cada emplazamiento debería conocer, al menos, cuándo se mostró el último anuncio de cualquier formato, no solo del suyo.
Cuando la carga falla
Si el anuncio no está disponible en el momento previsto, la aplicación debe continuar como si el emplazamiento no existiera. No debe esperar, no debe mostrar un indicador de carga, no debe reintentar en bucle. El usuario no sabe que ahí había un anuncio previsto y no tiene por qué notar su ausencia. Esta regla parece evidente, pero el error contrario es frecuente: una pantalla de transición que espera al callback del anuncio para avanzar, y que se queda bloqueada si ese callback no llega nunca.
Respetar el ciclo de vida de la aplicación
Un intersticial solo debería mostrarse con la aplicación en primer plano y la pantalla correspondiente activa. Si el usuario envía la aplicación a segundo plano justo cuando se iba a mostrar el anuncio, lo correcto es descartar esa oportunidad, no guardarla para enseñarla en cuanto vuelva. Volver a una aplicación y encontrarse un anuncio a pantalla completa, sin ningún contexto, es una de las experiencias más desconcertantes que puede ofrecer un producto. También hay que cuidar el regreso desde el anuncio: cuando el usuario lo cierra, la aplicación debería estar exactamente donde la dejó, con su estado intacto, sin recargar la pantalla ni perder lo que había en ella.
Anuncio recompensado: un desvío que el usuario elige
En el artículo anterior presentamos el anuncio recompensado (rewarded) como el formato que invierte la lógica habitual: el usuario no sufre una interrupción, sino que acepta un intercambio. Visto desde el flujo, el anuncio recompensado no corta el recorrido, sino que abre un desvío opcional: una rama que el usuario puede tomar o ignorar, y que debe devolverle al camino principal con algo que antes no tenía. Esa promesa solo se cumple si la implementación la respeta en cada paso. Un anuncio recompensado mal implementado —con una recompensa poco clara, que se dispara sin querer o que no entrega lo prometido— rompe exactamente aquello que lo hacía valioso: la confianza en que el trato es justo.
El flujo de un anuncio recompensado bien diseñado es una secuencia en la que cada paso depende del anterior, y por eso aquí sí tiene sentido verlo en orden:
- El usuario solicita la recompensa, pulsando una opción que la ofrece de forma explícita.
- La aplicación confirma qué va a recibir exactamente a cambio de ver el anuncio.
- Se muestra el anuncio, que debería estar ya cargado.
- El usuario lo completa.
- La aplicación valida que el anuncio se ha completado de verdad.
- Se entrega la recompensa y se confirma visualmente que ha llegado.
Explicar la recompensa antes, no después
El botón que ofrece el anuncio recompensado tiene que decir qué se obtiene: “Ver un anuncio para conseguir una vida extra”, “Desbloquear este capítulo viendo un vídeo”. Un botón genérico con un icono de vídeo y la palabra “Gratis” obliga al usuario a adivinar el trato, y quien no entiende un trato tiende a no aceptarlo, o a sentirse engañado si lo acepta y el resultado no era el que esperaba.
En el caso del intersticial recompensado (rewarded interstitial), la variante que aparece en una transición sin que el usuario la haya pedido, esta explicación previa no es solo una buena práctica: plataformas como AdMob exigen mostrar una pantalla introductoria que explique la recompensa y permita al usuario rechazarla antes de que el anuncio empiece. Esa pantalla es la que separa un intercambio ofrecido de una interrupción con premio de consolación.
Iniciado por el usuario y difícil de activar por error
El anuncio recompensado estándar debe empezar siempre por una acción deliberada. Esto descarta cualquier diseño en el que el anuncio arranque al tocar una zona amplia de la pantalla, al pulsar un botón que normalmente hace otra cosa o como efecto secundario de cerrar un diálogo. Si el botón de “ver anuncio” está en la misma posición donde un instante antes estaba el de “continuar”, tarde o temprano alguien lo pulsará sin querer, y el intercambio dejará de ser voluntario.
Entregar la recompensa solo cuando corresponde
Los SDK publicitarios notifican a la aplicación, mediante un evento específico, el momento en que el usuario ha ganado la recompensa. Ese evento —y no el cierre del anuncio, ni su inicio— es el que debe desencadenar la entrega. Confundir uno con otro produce dos errores opuestos: entregar la recompensa a quien cerró el anuncio a los tres segundos, o no entregarla a quien lo vio completo pero lo cerró de una forma que la aplicación no esperaba.
Cuando la recompensa tiene valor real dentro de una economía —moneda virtual, contenido de pago, ventajas competitivas—, conviene ir un paso más allá y validarla en el servidor. La verificación del lado del servidor (SSV, server-side verification) permite que la plataforma publicitaria notifique directamente al servidor de la aplicación que un usuario concreto ha completado un anuncio, de modo que la recompensa no dependa solo de lo que diga el cliente, que puede manipularse. Esa validación debe ser idempotente: si la misma notificación llega dos veces, la recompensa se entrega una sola.
Interrupciones, cierres y fallos de red
¿Qué pasa si el usuario recibe una llamada en mitad del anuncio? ¿Y si pierde la conexión cuando quedan dos segundos? ¿Y si la aplicación se cierra justo después de ganar la recompensa pero antes de guardarla? Son casos extremos, pero en una aplicación con miles de usuarios diarios ocurren todos los días. La regla general es inclinarse a favor del usuario cuando hay duda razonable: si el evento de recompensa llegó, la recompensa debe persistir aunque la aplicación se cierre inmediatamente después. Un usuario que vio el anuncio completo y no recibió nada no vuelve a pulsar ese botón.
También hay que pensar en qué ocurre cuando no hay anuncio disponible en el momento en que el usuario lo pide. Mostrar el botón y, al pulsarlo, responder con un error es frustrante. Es preferible comprobar la disponibilidad antes de ofrecer la opción, y si no hay anuncio, ocultarla, deshabilitarla con una explicación o sustituirla por una alternativa: esperar un tiempo, usar moneda acumulada o, en un modelo híbrido, comprar directamente lo que el anuncio habría desbloqueado.
Recompensas que merezcan la pena, y que sigan siendo opcionales
Una recompensa ambigua (“un bonus”) o desproporcionadamente pequeña respecto al tiempo que pide el anuncio enseña al usuario que el trato no compensa, y a partir de ahí deja de aceptarlo. Pero el error contrario es más grave: diseñar el producto de tal forma que la recompensa deje de ser un extra y se convierta en un requisito. Si progresar en un juego es prácticamente imposible sin ver anuncios, o si una función básica de una herramienta solo se desbloquea durante diez minutos a cambio de un vídeo, la opción voluntaria se ha convertido en un peaje encubierto. Técnicamente sigue siendo un anuncio recompensado, pero el usuario lo vive como un intersticial obligatorio, y con más resentimiento, porque además percibe la trampa.
Anuncio nativo: dentro del contenido, sin disfrazarse de él
Si el banner convive con el flujo desde fuera, el anuncio nativo (native) viaja dentro de él: aparece en el mismo recorrido de desplazamiento y lectura que el contenido, al mismo ritmo y con un aspecto parecido. Por eso es el formato que más trabajo de diseño exige, porque, a diferencia del resto, la aplicación no recibe un anuncio ya montado. Recibe sus piezas —titular, texto, imagen, icono, nombre del anunciante, llamada a la acción— y es la propia aplicación la que decide cómo componerlas para que encajen con el estilo de la interfaz. Esa libertad es su gran ventaja y, a la vez, su principal riesgo.
La idea que debe guiar toda la implementación cabe en una frase:
Integrar un anuncio en el contenido no significa ocultar que es un anuncio.
Una identificación visible, siempre
Todo anuncio nativo debe llevar una marca clara que lo identifique como publicidad —“Anuncio”, “Patrocinado”— y, en el caso de muchas plataformas, el icono de AdChoices o equivalente que permite al usuario saber por qué ve ese anuncio. No son elementos decorativos: son requisitos de las políticas de las redes publicitarias, y su ausencia puede bloquear la monetización de la cuenta. Pero, sobre todo, son la línea que separa la integración de la confusión.
Esa marca tiene que ser legible de verdad. Una etiqueta minúscula, en gris claro sobre fondo blanco, en una esquina donde la vista no se detiene, cumple la letra de la norma pero traiciona su intención. El mismo criterio de contraste que se aplica al resto del texto de la interfaz debería aplicarse también a la etiqueta del anuncio. Las pautas de accesibilidad web (WCAG) lo expresan con una cifra: una relación mínima de 4,5:1 para texto normal.
Dicho de forma sencilla, esa relación compara lo luminoso que es el fondo con lo luminoso que es el texto. La escala va de 1:1, cuando texto y fondo son del mismo color y no se lee nada, hasta 21:1, que es el negro puro sobre blanco puro. Un 4,5:1 significa que el color más claro es unas cuatro veces y media más luminoso que el más oscuro, lo bastante como para leerse sin esfuerzo incluso con poca vista o con el sol dando en la pantalla. Como referencia, un gris medio (#767676) sobre fondo blanco ronda justo ese 4,5:1, mientras que el gris claro tan habitual en las etiquetas de “Patrocinado” suele quedarse muy por debajo.
Respetar la jerarquía del contenido
Un anuncio nativo en un muro debería parecerse al muro en ritmo y tamaño, pero no ser indistinguible de una publicación. Usar la misma tipografía y los mismos márgenes ayuda a que no rompa la lectura; copiar exactamente el mismo diseño de tarjeta, con el mismo tipo de cabecera y los mismos botones de interacción, cruza la línea. Un buen punto de partida es preguntarse qué pensaría un usuario que ve la tarjeta durante medio segundo mientras se desplaza por la pantalla: si su primera impresión es “esto es una publicación más”, el diseño está mal.
También importa la posición. Un anuncio nativo en la primera posición de un muro compite directamente con el contenido que el usuario ha venido a ver; uno insertado a intervalos regulares, después de que el usuario ya haya recibido valor, se percibe como parte del recorrido.
Clics deliberados, no accidentales
En un anuncio nativo, solo los elementos del anuncio —el titular, la imagen, el botón de acción— deberían ser pulsables. Hacer que toda la tarjeta, incluido el espacio en blanco alrededor, abra el anuncio aumenta los clics, pero casi todos los adicionales son involuntarios, y las políticas de las plataformas lo prohíben de forma explícita. Lo mismo ocurre con los gestos: si el muro permite deslizar las tarjetas para descartarlas o guardarlas, el gesto no debería disparar un clic en el anuncio por error.
Reservar espacio para lo que puede faltar
Las piezas de un anuncio nativo no siempre llegan completas. Algunas son obligatorias (el titular, en el caso de AdMob) y otras opcionales: puede venir sin icono, sin texto descriptivo, sin valoración, o con un vídeo en lugar de una imagen. La plantilla debe estar preparada para todos esos casos sin deformarse. Esto significa definir qué ocurre con el hueco de cada elemento ausente —se oculta, se colapsa, se sustituye— y comprobar que la tarjeta sigue siendo coherente en todas las combinaciones posibles. También conviene reservar las proporciones del área multimedia desde el principio, respetando los tamaños mínimos que exige cada plataforma, para que la llegada de la imagen o del vídeo no reproduzca el mismo salto de diseño que vimos con el banner.
Accesibilidad y legibilidad
Los elementos del anuncio deben ser accesibles para lectores de pantalla igual que el resto de la interfaz, con su etiqueta de publicidad incluida, de modo que un usuario que no ve la pantalla también sepa que está ante un anuncio. Y el texto del anuncio, que no controla la aplicación, puede ser más largo de lo previsto: la plantilla tiene que truncarlo de forma elegante en lugar de desbordarse o empujar el resto del contenido.
Anuncio de apertura: en el umbral de la sesión, sin convertirlo en una barrera
El anuncio de apertura (app open) aparece en el único punto del flujo que precede a todos los demás: cuando el usuario abre la aplicación o vuelve a ella. Es un momento valioso para la monetización porque ocurre muchas veces al día y el usuario todavía no ha empezado ninguna tarea. Y es un momento delicado por exactamente la misma razón: el usuario abre la aplicación para hacer algo, y cualquier cosa que se interponga en ese primer segundo se percibe como un obstáculo.
Mostrarlo cuando la aplicación está realmente lista
En un arranque en frío —cuando la aplicación se inicia desde cero—, el anuncio de apertura debería aparecer sobre una pantalla de carga real, mientras la aplicación prepara lo que necesita, y no antes de que exista algo que mostrar después. Cuando el usuario cierra el anuncio, la aplicación tiene que estar lista para usarse en ese mismo instante. Si al cerrar el anuncio aparece otra pantalla de carga, el usuario ha pagado dos veces el mismo peaje.
Un tiempo máximo de espera
En un arranque en frío, el anuncio puede no estar cargado cuando la aplicación ya está lista. La tentación es esperar un poco más, porque el anuncio “está a punto de llegar”. El problema es que esa espera bloquea el acceso del usuario a la aplicación por algo que no pidió. La implementación debe fijar un tiempo máximo —unos pocos segundos como mucho, idealmente menos que lo que ya tardaría la carga normal—, y si el anuncio no ha llegado para entonces, la aplicación arranca sin él. El anuncio que llegue tarde puede guardarse para la próxima oportunidad válida, siempre que no haya caducado (en AdMob, los anuncios de apertura cargados caducan a las cuatro horas).
Diferenciar una apertura real de una vuelta momentánea
El caso más frecuente no es el arranque en frío, sino el regreso a una aplicación que estaba en segundo plano. Y aquí hay que distinguir con cuidado. Un usuario que vuelve a la aplicación después de varias horas está, en la práctica, empezando una sesión nueva. Un usuario que salió treinta segundos para copiar un código de verificación del correo, o para responder un mensaje, o que simplemente bloqueó la pantalla, no ha abierto nada: está continuando lo que hacía.
Mostrar un anuncio de apertura en esa segunda situación es uno de los errores más irritantes que existen, porque castiga precisamente el comportamiento multitarea que los sistemas operativos fomentan. La implementación necesita un umbral de tiempo en segundo plano por debajo del cual el regreso no cuenta como apertura, y además debe excluir los regresos que la propia aplicación ha provocado: volver de un flujo de pago, de una pantalla de permisos del sistema, de un inicio de sesión con un proveedor externo, de compartir contenido o, por supuesto, de otro anuncio que abrió el navegador.
Siempre una salida
Si algo falla —el anuncio no carga, el SDK no responde, la conexión se cae—, la aplicación debe arrancar igualmente. El anuncio de apertura nunca puede ser una dependencia del arranque. Tampoco tiene sentido mostrarlo en la primera apertura de un usuario nuevo, que todavía no conoce el producto y cuya primera impresión será, literalmente, un anuncio.
Cuando el flujo se tuerce: los estados que toda implementación debe contemplar
Hasta aquí hemos hablado del recorrido ideal: el usuario termina algo, el anuncio aparece en su sitio y el flujo continúa. Pero la experiencia real está llena de desvíos que nadie diseña: la conexión se cae, el usuario sale de la aplicación, el anuncio no llega o llega tarde. En cada uno de esos casos, lo que percibe el usuario no depende del anuncio, sino de cómo reacciona la aplicación.
Por eso un emplazamiento no es una llamada a show(). Es una pequeña máquina de estados que tiene que saber responder correctamente a todo lo que puede ocurrir entre que la aplicación decide pedir un anuncio y el momento en que el usuario vuelve a lo que estaba haciendo. La mayoría de las implementaciones contemplan el camino feliz —el anuncio carga, se muestra, se cierra— y dejan todo lo demás al azar. Y “todo lo demás” es, en producción, una parte muy significativa de los casos. El criterio para resolver cada uno es siempre el mismo: que el flujo del usuario sobreviva intacto, haya anuncio o no.
La siguiente tabla recoge los estados y situaciones más habituales, junto con lo que la aplicación debería hacer en cada uno:
| Situación | Qué debería hacer la aplicación |
|---|---|
| Anuncio cargando | Seguir funcionando con normalidad; nunca bloquear la interfaz esperando el resultado |
| Anuncio disponible | Mantenerlo listo hasta que llegue un momento válido, controlando su caducidad |
| Anuncio no disponible | Continuar sin él; ocultar opciones que dependan de él u ofrecer una alternativa |
| El usuario abandona antes de mostrarlo | Descartar la oportunidad; no mostrarlo en la siguiente pantalla “para aprovecharlo” |
| El usuario cierra el anuncio | Devolverle exactamente al estado anterior, sin recargas ni pérdida de datos |
| Error de red durante la carga | Reintentar con espera progresiva, nunca en bucle inmediato |
| Aplicación enviada a segundo plano | Cancelar la presentación pendiente y pausar refrescos y solicitudes |
| Cambio de orientación o de tamaño | Recalcular el tamaño de banners y anuncios nativos; no mostrar formatos de pantalla completa a medio giro |
| Pérdida de conexión | No solicitar anuncios; no ofrecer anuncios recompensados que no se van a poder completar |
| Usuario sin consentimiento | No solicitar anuncios hasta resolver el consentimiento, o hacerlo con las limitaciones que correspondan |
| Límite de frecuencia alcanzado | No mostrar, aunque haya un anuncio cargado y el momento sea válido |
| Usuario con compra que elimina anuncios | No inicializar ni solicitar nada en los emplazamientos afectados |
Dos de estas filas merecen un comentario adicional. La primera es el consentimiento. En regiones como la Unión Europea, la aplicación no puede solicitar anuncios personalizados sin el consentimiento del usuario, y en iOS la segmentación basada en el identificador del dispositivo depende además del permiso de seguimiento del sistema. Los SDK de gestión de consentimiento ofrecen una comprobación explícita de si ya se pueden solicitar anuncios, y esa comprobación debe hacerse antes de la primera solicitud, no después. Dedicaremos un artículo específico de la serie a la privacidad y al consentimiento, pero desde el punto de vista del emplazamiento basta con tener clara una cosa: el estado del consentimiento es una condición de entrada de la regla de presentación, igual que el límite de frecuencia.
La segunda es la del usuario que ha pagado para eliminar los anuncios. Parece trivial, pero es un error muy común que el usuario de pago siga viendo, durante un instante, el hueco reservado del banner, o que el SDK siga haciendo solicitudes en segundo plano que nunca se muestran. Para quien ha pagado por una experiencia sin anuncios, ver aunque sea el contenedor vacío es una pequeña traición. La comprobación de compra debería ocurrir antes de construir la interfaz, no después.
Una forma útil de llevar esto al código es centralizar la decisión en un único lugar, en lugar de repartirla por cada pantalla. Algo con esta forma, en pseudocódigo:
fun canShow(placement: Placement): Boolean {
if (user.hasRemovedAds) return false
if (!consent.canRequestAds) return false
if (!app.isInForeground || !placement.screen.isActive) return false
if (session.isFirstSession && placement.excludedOnFirstSession) return false
if (adHistory.secondsSinceLastFullscreenAd() < placement.minGapSeconds) return false
if (placement.frequencyCapReached()) return false
return placement.ad?.isLoaded == true && !placement.ad.isExpired
}
La ventaja de este enfoque no está en el código en sí, que cualquier equipo escribirá a su manera, sino en que obliga a hacer explícitas todas las condiciones. Cuando una regla vive dentro de un if disperso en la pantalla de resultados, nadie la recuerda seis meses después. Cuando vive en un lugar común, se puede leer, revisar y cambiar sin miedo a romper otra cosa.
Errores de emplazamiento que parecen pequeños
Los errores de monetización que más daño hacen rara vez son decisiones grandes y equivocadas. Suelen ser detalles de implementación que nadie revisa porque, vistos de uno en uno, parecen insignificantes, y casi todos tienen algo en común: rompen el flujo en un punto donde el usuario no lo esperaba. La siguiente tabla recoge los más habituales, junto con lo que realmente provocan y una alternativa razonable:
| Error | Por qué parece inofensivo | Lo que provoca en realidad | Alternativa |
|---|---|---|---|
Banner junto al botón principal |
“Así se ve más” | Clics accidentales, frustración y riesgo de sanción | Separación clara entre anuncio y controles |
| Corte publicitario en mitad de un directo | “Los cortes son normales en vídeo” | El usuario pierde un momento que no puede recuperar | Vincular los cortes a pausas reales de la emisión o mantener el directo visible |
| Intersticial al abrir cada pantalla | “Es una transición” | La navegación se vuelve impredecible | Ligarlo a finales de tarea, no a la navegación |
| Anuncio antes de confirmar una operación | “La operación tarda poco” | Errores que el usuario no ve o no entiende | Confirmar el resultado primero, anuncio después |
Banner que desplaza el contenido |
“Solo pasa una vez al cargar” | Toques en el lugar equivocado, lectura interrumpida, peor CLS en web | Reservar la altura antes de solicitar |
| Anuncio recompensado sin explicar la recompensa | “El icono ya lo dice” | Baja aceptación y sensación de engaño | Texto explícito: qué se obtiene y a cambio de qué |
| Mismo anuncio repetido en una sesión corta | “El SDK decide qué anuncio sale” | Fatiga y percepción de app saturada | Límites de frecuencia y separación entre formatos |
| Anuncio nativo indistinguible del contenido | “Así encaja mejor” | Pérdida de confianza en todo el muro | Etiqueta visible y diseño diferenciado |
| Bloquear la app esperando un anuncio | “Será solo un segundo” | Arranques y transiciones lentas o bloqueadas | Tiempo máximo y continuar sin anuncio |
| Sin plan para cuando no hay inventario | “Siempre hay anuncios” | Huecos vacíos, botones que fallan, pantallas colgadas | Comportamiento alternativo definido para cada emplazamiento |
Hay un patrón común detrás de casi todos estos errores: se han pensado desde el punto de vista del anuncio y no desde el de la persona que usa la aplicación. Cada uno de ellos mejora, al menos sobre el papel, alguna cifra del panel publicitario. Y casi todos empeoran algo que no aparece en ese panel.
Probar un emplazamiento antes de que lo vea nadie
Antes de llegar a los datos reales de usuarios, hay una fase de validación que se puede hacer sin un solo usuario externo y que evita la mayoría de los problemas que hemos descrito. No sustituye a la medición, pero filtra los errores más evidentes antes de que lleguen a producción.
Lo primero es trabajar siempre con anuncios de prueba durante el desarrollo. Todas las plataformas ofrecen unidades de prueba o la posibilidad de registrar dispositivos de prueba, y usarlas no es opcional: hacer clic en anuncios reales de la propia aplicación, aunque sea para comprobar que funcionan, puede interpretarse como actividad fraudulenta y poner en riesgo la cuenta. Las herramientas de inspección que incluyen algunos SDK —como el Ad Inspector de AdMob— permiten además ver en tiempo real qué solicitudes se están haciendo, qué fuente de demanda responde y por qué falla un anuncio cuando falla.
Lo segundo es provocar deliberadamente los estados difíciles en lugar de esperar a que aparezcan. Activar el modo avión justo antes de un emplazamiento. Enviar la aplicación a segundo plano mientras carga un intersticial. Girar el dispositivo con un anuncio recompensado abierto. Cerrar el anuncio en el primer segundo. Simular que no hay inventario, devolviendo un error forzado desde el código en una compilación de pruebas. Cada uno de esos experimentos dura un minuto y responde a una pregunta que, de otra forma, contestarían los usuarios en las reseñas.
Y lo tercero, quizá lo más revelador, es usar la aplicación durante un rato como la usaría alguien que no la ha construido: una sesión completa, sin atajos, prestando atención a cuántos anuncios aparecen, cuándo y cómo se siente cada uno. Es sorprendente la cantidad de combinaciones desafortunadas —dos anuncios seguidos, un anuncio de apertura al volver de un pago, un banner tapando un botón con el teclado abierto— que solo se descubren así.
Todo esto sirve para saber si un emplazamiento funciona bien, pero no si es la mejor opción posible. ¿El intersticial rinde más cada tres niveles o cada cinco? ¿El anuncio nativo funciona mejor en la cuarta posición del muro o en la octava? ¿Compensa ofrecer el anuncio recompensado al perder o solo desde la tienda? Responder a esas preguntas con intuición es tentador, y suele salir mal. La forma fiable de hacerlo es mediante tests A/B: mostrar dos variantes del mismo emplazamiento a grupos de usuarios comparables y comparar no solo los ingresos, sino también la retención, la duración de las sesiones o las compras. Requieren su propia metodología —tamaño de muestra, duración, qué métrica decide y qué hacer cuando ingresos y retención apuntan en direcciones opuestas—, así que les dedicaremos su espacio en próximos artículos de la serie.
No era la publicidad, era la experiencia
Volvamos al anuncio que te hizo resoplar al principio del artículo. Ahora es fácil ponerle nombre a lo que falló: un banner sin espacio reservado, un intersticial que fabricó una pausa que no existía, un anuncio de apertura que confundió una vuelta de treinta segundos con una apertura, un anuncio recompensado que no entregó lo que prometía. En ninguno de esos casos el problema era que hubiera publicidad. El problema era lo que la publicidad le hizo al recorrido.
La calidad de un emplazamiento no se decide por el formato que utiliza, sino por el lugar que ocupa en el flujo y por las reglas que lo rodean. Un banner necesita estabilidad para convivir con el recorrido. Un intersticial necesita una transición real que ocupar. Un anuncio recompensado necesita un intercambio claro que el usuario elija. Un anuncio nativo necesita transparencia para viajar dentro del contenido. Un anuncio de apertura necesita no convertir el umbral de la sesión en una barrera. Y todos ellos necesitan saber qué hacer cuando las cosas no salen como estaba previsto, porque en una aplicación con usuarios reales eso ocurre constantemente.
Una buena prueba para cualquier emplazamiento es preguntarse si el usuario podría describir lo que estaba haciendo antes y después del anuncio como un único recorrido continuo. Si la respuesta es sí, la publicidad se ha integrado en la experiencia. Si la respuesta es “estaba haciendo algo y de repente…”, da igual lo bien que rinda en el panel: la experiencia se ha roto, y el usuario lo recordará más que cualquier anuncio.
Implementar publicidad con cuidado no es una concesión que se hace a costa de los ingresos. Es la condición para que esos ingresos sigan llegando dentro de un mes, cuando el usuario se plantee si volver a abrir la aplicación o no.
Pero diseñar bien un emplazamiento es solo la mitad del trabajo. La otra mitad es comprobar si funciona: qué está ocurriendo realmente desde que se solicita un anuncio hasta que se muestra, en qué punto del embudo se pierden oportunidades, cómo afecta cada emplazamiento al comportamiento de los usuarios y por qué el ingreso inmediato no basta para evaluar una decisión de monetización. De eso tratará el próximo artículo de la serie, dedicado a la medición.
Happy Earning!!
