Abres una aplicación gratuita, consultas algo durante unos segundos y en la parte inferior de la pantalla aparece un banner. Probablemente ni siquiera pienses en todo lo que ha tenido que ocurrir para que ese anuncio concreto, y no otro, termine ahí en ese momento.
Para quien desarrolla la aplicación, el proceso tampoco parece mucho más complicado al principio. Se integra un SDK publicitario, se crea un espacio en la interfaz y, con algo de configuración, empiezan a aparecer anuncios. Los primeros ingresos llegan, y todo parece relativamente sencillo.
Pero detrás de ese banner hay un mercado que funciona de forma continua, en milisegundos, con múltiples empresas participando en cada oportunidad publicitaria. Ese mercado es el que decide qué anuncio ves, cuánto vale esa visualización y, en última instancia, cuánto dinero termina ingresando la aplicación.
¿Quién decide qué anuncio aparece? ¿Por qué dos usuarios de la misma aplicación generan cantidades de dinero completamente distintas? ¿Qué significa realmente un eCPM de 3€? ¿Qué ocurre cuando se solicita un anuncio y no hay ninguno disponible? ¿Por qué tener 100.000 solicitudes no significa mostrar 100.000 anuncios? Y quizá la más importante de todas: ¿más anuncios significan necesariamente más ingresos?
Este es el primer artículo de una serie sobre monetización publicitaria, en la que iremos desde los fundamentos de cómo funciona este mercado hasta las métricas, formatos, mediación, experimentación y estrategias que permiten utilizar la publicidad como fuente de ingresos en aplicaciones, juegos y otros productos digitales.
No hace falta ningún conocimiento previo para seguir este artículo. Si terminas de leerlo y eres capaz de abrir un panel de AdMob, o de cualquier otra plataforma publicitaria, y entender lo que ves en lugar de encontrarte una colección de siglas y porcentajes indescifrables, este artículo habrá cumplido su función.
Lo primero: ¿qué vende realmente una aplicación?
Es fácil pensar que una aplicación “vende anuncios”. No es exactamente así. Lo que una aplicación tiene para ofrecer son oportunidades para que terceros muestren publicidad a sus usuarios. A ese conjunto de oportunidades se le llama inventario publicitario.
Un espacio publicitario disponible en un momento y un contexto determinados representa una oportunidad de negocio. Una aplicación del tiempo, por ejemplo, podría tener un banner fijo en su pantalla principal y un anuncio nativo insertado dentro de la previsión semanal. Ambos espacios, junto con todos los momentos en los que un usuario puede llegar a verlos, forman parte de su inventario publicitario.
Dentro de ese inventario hay dos ideas que conviene separar bien desde el principio, porque en el día a día casi todo el mundo las mezcla y las usa como si fueran lo mismo. Antes de darles nombre técnico, veámoslas con un ejemplo que no tiene nada que ver con aplicaciones.
Imagina una valla publicitaria junto a una carretera. Por un lado está el poste, el hueco vacío donde se puede colgar un cartel: siempre está en el mismo sitio, y todos los coches que pasan por esa carretera lo ven, muestren lo que muestren en cada momento. Por otro lado está el cartel concreto que hay colgado ahí hoy: puede ser un anuncio de un banco esta semana y de un supermercado la semana que viene, sin que el poste se mueva ni cambie de sitio. El poste es el espacio; el cartel es lo que se pone en ese espacio en un momento dado. Esa misma diferencia —el hueco fijo frente a lo que se coloca dentro de él— es exactamente la que existe entre un placement y una ad unit.
Placement (en español podríamos decir simplemente ubicación publicitaria) es el “poste”: el lugar y el momento, dentro de la experiencia de la aplicación, donde siempre va a poder aparecer un anuncio. Por ejemplo, “el banner de la parte de abajo en la pantalla de estadísticas” o “la pantalla completa que aparece justo al terminar un nivel del juego”. Es una descripción pensada para que cualquier persona del equipo —no solo quien programa— entienda de un vistazo de qué espacio se está hablando, sin necesidad de mirar ni una línea de código.
Ad unit (unidad publicitaria) es el “cartel”: la configuración técnica concreta que usa la plataforma publicitaria para decidir qué anuncio va a rellenar ese hueco cada vez. En la práctica es un identificador que se crea dentro de una herramienta como AdMob y que después se pega en el código de la aplicación, para que esta sepa a qué configuración pedirle un anuncio quiere mostrar en cada placement. Un mismo placement —el mismo poste— puede tener detrás una sola ad unit siempre, o varias si en algún momento se prueban distintos formatos o distintos proveedores para ver cuál rinde mejor en ese espacio concreto.
Con esta distinción clara conviene quedarse con una idea que vamos a reutilizar constantemente a lo largo del artículo: tener inventario disponible no significa que vaya a venderse, y que se venda tampoco significa necesariamente que el anuncio llegue a mostrarse. Entre esas tres cosas —tener el espacio, venderlo y mostrarlo— hay todo un proceso, y ese proceso es el que vamos a desgranar a continuación.
¿Quién participa en el mercado publicitario?
Antes de seguir avanzando conviene ponerle nombre a quién interviene en este mercado. Una forma muy simplificada de representarlo, usando solo palabras naturales por ahora, sería así:
Cada una de esas cajas tiene, además, un nombre técnico propio dentro del sector, que vamos a ir presentando uno por uno a continuación.
Es una simplificación útil para orientarse, pero la realidad tiene más matices, así que vamos a repasar cada pieza una por una.
Anunciante (advertiser). La empresa o persona que quiere promocionar algo y está dispuesta a pagar por ello. Puede ser un banco promocionando una cuenta nueva, un estudio de videojuegos buscando instalaciones para su último lanzamiento, o una tienda online buscando ventas directas.
Publisher. Somos nosotros, vistos desde el otro lado del mercado: quien tiene una aplicación con audiencia e inventario publicitario disponible para vender.
Ad network (red publicitaria). Un intermediario que conecta demanda publicitaria (anunciantes que quieren comprar) con oferta (publishers que quieren vender). AdMob es, en su forma más básica, un ejemplo de red publicitaria.
Ad exchange. Un mercado tecnológico donde compradores y vendedores intercambian inventario publicitario mediante procesos automatizados, en lugar de acuerdos negociados manualmente uno a uno. Es la infraestructura que hace posible que una oportunidad publicitaria se compre y se venda en el tiempo que tarda una pantalla en cargar.
DSP (Demand-Side Platform). Aquí conviene evitar la típica definición de manual de la industria, que suele ser incomprensible para cualquiera que no trabaje ya en ad tech. Dicho de forma sencilla: una DSP es una plataforma que ayuda a los anunciantes a decidir qué oportunidades publicitarias les interesa comprar y cuánto están dispuestos a pagar por cada una, normalmente de forma automatizada y en tiempo real.
SSP (Supply-Side Platform). Es la contrapartida de la DSP, del lado del publisher: una plataforma que ayuda a quien tiene inventario a exponerlo ante la mayor cantidad de demanda posible y a maximizar lo que se paga por él. Si la DSP responde a “¿qué me interesa comprar?”, la SSP responde a “¿cómo consigo vender mi inventario al mejor precio?”.
Mediador (mediation). Por ahora nos quedamos con una definición mínima: una capa capaz de conectar el inventario de un publisher con distintas fuentes de demanda a la vez, en lugar de depender de una sola. No vamos a entrar todavía en cómo decide qué fuente gana cada oportunidad —eso implica hablar de waterfall y de bidding, y es tan importante que le dedicaremos un artículo completo de esta serie más adelante.
Con este mapa de actores ya podemos entender qué ocurre, paso a paso, desde que una aplicación pide un anuncio hasta que ese anuncio genera dinero, pero si aun no lo has entendido, tranquilo, a continuación lo desgranamos.
Qué ocurre desde que se solicita un anuncio hasta que lo ves
Son las 18:30. Un usuario en España abre la pantalla principal de una aplicación que tiene un banner integrado. Ese simple gesto pone en marcha todo lo que viene a continuación.
La aplicación solicita un anuncio
En cuanto la pantalla con el banner se carga, la aplicación envía una ad request (solicitud publicitaria) a la plataforma publicitaria: “tengo un espacio disponible ahora mismo, ¿tienes algo para mostrar aquí?”.
Esto es importante y conviene subrayarlo desde ya: una request no es una impresión. Es solo el primer paso de un proceso que todavía puede fallar en varios puntos distintos antes de que el usuario llegue a ver nada.
La oportunidad llega al mercado
Esa solicitud no viaja vacía. Va acompañada de una serie de señales que ayudan al mercado a valorar la oportunidad: la aplicación de la que procede, el país del usuario, la plataforma (iOS o Android), el tipo de dispositivo, el formato del anuncio solicitado, el contexto dentro de la app y, cuando existe, el consentimiento del usuario para ciertos tipos de segmentación. No vamos a profundizar todavía en privacidad y consentimiento —también dará para un artículo propio—, pero conviene saber que esa señal forma parte del paquete de información desde el primer momento.
La demanda decide cuánto vale esa oportunidad
Con esa información disponible, los distintos compradores potenciales deciden si les interesa esa oportunidad concreta y, si les interesa, cuánto están dispuestos a pagar por ella. A esa oferta se le llama bid (puja).
No todos los anunciantes valoran igual la misma oportunidad. Un anunciante que solo opera en España podría pagar muy bien por una impresión española y, sencillamente, no pujar nada por una que procede de un país donde no ofrece sus servicios. El valor de una misma oportunidad publicitaria depende por completo de quién la está mirando.
Se elige un anuncio
Cuando hay varios compradores interesados en la misma oportunidad, se resuelve mediante una auction (subasta): un proceso que decide, entre todas las pujas recibidas, cuál se queda con el espacio. De momento nos quedamos con la idea a nivel conceptual —los distintos tipos de subasta (first-price, por ejemplo) son otro tema que retomaremos cuando hablemos de mediación y bidding en detalle.
La request puede quedar cubierta
Si el proceso anterior encuentra un anuncio dispuesto a ocupar ese espacio, decimos que la request ha quedado matched (una matched request, o solicitud cubierta). La proporción de solicitudes que consiguen encontrar un anuncio se llama fill rate o match rate, según la plataforma que consultes —el matiz terminológico varía un poco de una a otra, pero la idea de fondo es la misma.
No todas las solicitudes consiguen esto. Puede que, para ese formato, ese país y ese momento concreto, no haya ningún comprador interesado. En ese caso la request queda sin cubrir, y el espacio se queda vacío o se rellena con algún mecanismo de respaldo.
El anuncio está disponible, pero todavía no se ha mostrado
Aquí llega una distinción fundamental que mucha gente pasa por alto: que se haya encontrado un anuncio para esa oportunidad no significa que el usuario vaya a verlo. El usuario puede abandonar esa pantalla antes de que el anuncio termine de cargar, puede navegar a otra sección, puede producirse un error de red, o el propio proceso de renderizado puede fallar.
A la proporción de anuncios que, habiendo sido encontrados, llegan realmente a mostrarse se le llama show rate.
Finalmente ocurre una impresión
Solo cuando el anuncio llega a la pantalla del usuario y se muestra de verdad, hablamos de una impression (impresión). Es el primer momento de todo este recorrido en el que podemos decir, sin matices, que “se ha mostrado un anuncio”.
Y el usuario podría interactuar
A partir de aquí el usuario puede simplemente ignorar el anuncio —lo más habitual, con diferencia— o interactuar con él haciendo un click. A partir de ese clic pueden producirse otras acciones que le interesan específicamente al anunciante: una instalación, un registro, una compra. A esa acción final se le llama conversion (conversión).
Con eso ya tenemos el recorrido completo, de principio a fin:
Cada flecha de ese recorrido es un punto donde el proceso puede detenerse. Y ese detalle es exactamente lo que explica el siguiente apartado.
De 100.000 solicitudes a 60.000 anuncios: el embudo publicitario
Vamos a ponerle números al recorrido anterior para que se entienda con total claridad por qué las cifras de un dashboard casi nunca coinciden entre sí a simple vista.
Supongamos que una aplicación genera 100.000 ad requests en un día:
El match rate de este ejemplo es del 90%: de cada 100.000 requests, 90.000 encuentran un anuncio dispuesto a ocupar el espacio. El show rate es del 75%: de esas 90.000 matched requests, solo 67.500 llegan a mostrarse realmente. Y el CTR, que veremos con detalle en el siguiente apartado, es del 1%: de esas 67.500 impresiones, 675 terminan en un clic.
El objetivo de este ejemplo no es enseñar a optimizar nada todavía —eso vendrá en otros artículos de la serie—, sino dejar clara una idea muy simple pero que genera muchísima confusión al principio: requests no es lo mismo que impressions. Si alguna vez te has preguntado por qué el número de “solicitudes” de un dashboard publicitario es muchísimo más alto que el de “impresiones”, esta es la razón. No es un error del sistema: es el embudo funcionando exactamente como está diseñado.
CPM, eCPM, CPC, CPA… ¿qué significan realmente?
Aquí empieza el bloque de vocabulario más denso del artículo, así que vamos a tomarnos cada término con calma. Para cada uno seguiremos siempre el mismo orden: nombre, explicación cotidiana, definición técnica, fórmula cuando exista, ejemplo con números y, por último, cómo interpretarlo.
CPM — Cost Per Mille. El coste por cada mil impresiones. La “M” viene del número romano mil, no de “millón”, y es una de las confusiones más habituales para quien empieza. Se mide por cada mil y no por cada impresión individual porque el valor de una sola impresión suele ser una cifra tan pequeña —fracciones de céntimo— que trabajar con ella directamente resultaría poco práctico.
eCPM — Effective Cost Per Mille. Este es probablemente el término más importante de todo el artículo, así que le dedicamos algo más de espacio. Desde el punto de vista del publisher, el eCPM representa cuánto se está ingresando, en promedio, por cada mil impresiones mostradas:
eCPM = ingresos / impresiones × 1.000
Si 20.000 impresiones generan 30€ de ingresos, el eCPM es de 1,50€. Pero hay un matiz que conviene interiorizar cuanto antes: un eCPM de 1,50€ no significa que cada grupo concreto de mil anuncios se haya vendido exactamente por esa cantidad. Es una forma normalizada de expresar el rendimiento medio de un conjunto de impresiones que, en realidad, puede incluir anuncios pagados a precios muy distintos entre sí —algunos muy por encima de 1,50€, otros muy por debajo—. El eCPM es un promedio, no un precio fijo.
CPC — Cost Per Click. Lo que cuesta, o lo que genera, cada clic recibido, según el modelo de facturación que se esté usando en cada caso.
CPI — Cost Per Install. Extremadamente habitual en publicidad de aplicaciones móviles: el anunciante paga por cada instalación conseguida a través del anuncio, no por cada clic ni por cada impresión.
CPA — Cost Per Action / Acquisition. El coste de conseguir una acción concreta que le interesa al anunciante: un registro, una suscripción, una compra. Es el modelo más exigente para quien vende el inventario, porque solo cobra si esa acción específica llega a producirse.
CTR — Click-Through Rate. El porcentaje de impresiones que terminan en un clic:
CTR = clicks / impressions × 100
Si 100.000 impresiones generan 1.200 clics, el CTR es del 1,2%. Y aquí va una advertencia que retomaremos más adelante en el artículo: un CTR más alto no significa automáticamente que la monetización de la aplicación sea mejor. Por ahora basta con dejarlo apuntado; entenderemos por qué cuando hablemos del embudo completo y de la experiencia de usuario.
Las métricas que importan al publisher
El bloque anterior estaba centrado en el precio de cada anuncio. Este está centrado en algo distinto: las métricas que, unidas, permiten entender la salud general de la monetización de una aplicación. Conviene separarlas en dos grupos: las operativas, que describen el funcionamiento del embudo, y las económicas, que describen el dinero que entra.
Ad requests (solicitudes publicitarias). Cuántas oportunidades publicitarias ha solicitado la aplicación. Es el punto de partida de todo lo demás.
Matched requests (solicitudes cubiertas). Cuántas de esas solicitudes encontraron un anuncio dispuesto a ocupar el espacio.
Match rate / fill rate (tasa de cobertura). Los ingresos que la plataforma publicitaria estima que has generado. La palabra estimated es importante: la cifra que ves en el panel todavía puede cambiar a medida que se procesan y revisan los datos, por lo que no debe entenderse como un ingreso definitivo.
Impressions (impresiones). Cuántos anuncios llegaron realmente a mostrarse en pantalla, tras superar también el filtro del show rate.
Show rate (tasa de visualización). La proporción de anuncios encontrados que finalmente se mostraron:
show rate = impressions / matched requests
Esta métrica suele pasar desapercibida, pero es una de las más reveladoras: un show rate bajo indica que se están perdiendo anuncios ya “comprados” antes de que lleguen al usuario, normalmente por problemas de carga, de red o de comportamiento de navegación.
Estimated revenue (ingresos estimados). Los ingresos que la plataforma publicitaria atribuye o reporta. Conviene tener presente que, especialmente en las horas o días más recientes, suelen ser cifras estimadas y sujetas a ajustes posteriores, no ingresos definitivos y cerrados.
ARPU — Average Revenue Per User (ingreso medio por usuario). Cuánto ingreso genera, de media, cada usuario, normalmente calculado sobre un periodo determinado:
ARPU = ingresos / usuarios
ARPDAU — Average Revenue Per Daily Active User (ingreso medio por usuario activo diario). Este es, junto al eCPM, uno de los términos que más merece la pena dominar bien, porque va a reaparecer constantemente en el resto de la serie. Representa cuánto ingreso genera, de media, cada usuario activo durante un día concreto:
ARPDAU = ingresos diarios / usuarios activos diarios (DAU)
Si una aplicación tiene 100.000 DAU y genera 500€ diarios en publicidad, su ARPDAU es de 500 / 100.000 = 0,005 €. Dicho de una forma mucho más comprensible que la fórmula sola: cada usuario activo está generando, de media, medio céntimo de ingreso publicitario al día. Convertir una cifra abstracta como “0,005€” en “medio céntimo por usuario y día” es lo que hace que la métrica empiece a significar algo real.
Ads ARPDAU (ingreso publicitario medio por usuario activo diario). Algunas plataformas distinguen el ARPDAU total —que puede incluir compras dentro de la app o suscripciones— del generado exclusivamente por publicidad. Esta distinción será importante más adelante en la serie, cuando hablemos de monetización híbrida (publicidad combinada con compras o suscripciones).
ARPPU — Average Revenue Per Paying User (ingreso medio por usuario de pago). El ingreso medio, pero calculado únicamente entre los usuarios que llegan a pagar por algo. Tiene más sentido en modelos con compras o suscripciones que en publicidad pura, pero aparece con frecuencia en cualquier conversación sobre monetización, así que merece estar en el mapa.
DAU / MAU (usuarios activos diarios / mensuales). Usuarios activos diarios (Daily Active Users) y usuarios activos mensuales (Monthly Active Users). No son métricas publicitarias en sentido estricto, sino de producto, pero son la base sobre la que se calculan casi todas las métricas de ingreso por usuario que acabamos de ver.
Impressions per user (impresiones por usuario). Cuántos anuncios ve, de media, cada usuario. Es muy intuitiva y muy útil, y además es la puerta de entrada a un concepto que vamos a tratar en detalle un poco más adelante: la frecuencia con la que se expone a un mismo usuario a publicidad, y el punto en el que esa frecuencia empieza a jugar en contra en lugar de a favor.
¿Por qué una impresión puede valer 0,20€ de eCPM y otra 10€?
Esta pregunta parece técnica a primera vista, pero en realidad es la que cualquiera se hace tarde o temprano cuando empieza a mirar sus propios números. Y la respuesta corta es: porque el valor de una impresión nunca depende de un solo factor, sino de varios a la vez.
Geografía. No es ningún secreto que el mercado publicitario en Estados Unidos se mueve con cifras distintas a las de España, y estas a su vez distintas de las de mercados emergentes. No vamos a dar cifras universales aquí porque cambian constantemente, pero sí conviene asumir desde el principio que el país del usuario es, casi siempre, el factor que más varianza introduce.
Plataforma. iOS y Android pueden presentar dinámicas de precio distintas para el mismo tipo de inventario, entre otras cosas por diferencias en el perfil medio de gasto de sus usuarios.
Tipo de aplicación. No todas las audiencias interesan por igual a todos los anunciantes. Una aplicación de finanzas personales y una de juegos casuales atraen, de partida, a compradores muy distintos.
Formato. Un banner, un intersticial y un anuncio recompensado (rewarded), hablaremos de ellos próximamente, no compiten por el mismo dinero. Ocupan espacios distintos, interrumpen de forma distinta y, en consecuencia, se valoran de forma distinta.
Momento. La hora del día, el día de la semana, el trimestre del año. La demanda publicitaria sube con fuerza en fechas como Navidad o el Black Friday, y baja en otros periodos. A esta variación se le llama seasonality (estacionalidad), y es una de las razones por las que comparar el eCPM de un mes con el de otro sin más contexto suele llevar a conclusiones equivocadas.
Competencia. Cuantos más compradores estén interesados en una misma oportunidad, más presión al alza hay sobre lo que están dispuestos a pagar por ella. Una oportunidad muy disputada tiende a valer más, casi por definición.
Señales disponibles. El consentimiento del usuario, la capacidad de segmentación, el contexto en el que aparece el anuncio. Cuanta más información relevante tenga la demanda para decidir si esa oportunidad le interesa, mejor puede valorarla.
La conclusión de todo esto es bastante práctica: preguntar “¿cuál es un buen eCPM?” sin dar más contexto —país, plataforma, formato, tipo de audiencia, momento del año— tiene poco sentido, por no decir ninguno. Es una pregunta que solo se puede responder con matices, nunca con una cifra única y universal.
Web, aplicaciones y juegos: el mismo mercado, productos diferentes
Todo lo que hemos explicado hasta ahora —requests, matched requests, impresiones, eCPM— describe el mismo mercado subyacente, independientemente de dónde se muestre el anuncio. Pero la forma de generar y consumir ese inventario cambia bastante según el tipo de producto.
En la web, la publicidad se asocia principalmente a páginas, contenido y navegación: el usuario se desplaza entre artículos o secciones, y cada carga de página es, potencialmente, una nueva oportunidad publicitaria.
En aplicaciones, el inventario se organiza en torno a SDKs integrados en el código, sesiones de uso, pantallas concretas y el ciclo de vida de la propia app —cuándo se abre, cuándo pasa a segundo plano, cuándo se cierra—. Los placements se piensan en función de ese recorrido, no de una navegación entre páginas.
En juegos móviles, formatos como el rewarded o el intersticial tienen un peso enorme, porque encajan de forma natural con la propia mecánica del juego: entre partidas, al completar un nivel, o a cambio de una recompensa concreta que le interesa al jugador.
Las bases económicas del mercado son las mismas en los tres casos. Lo que cambia sustancialmente es cómo se crea el inventario y cómo lo consume cada tipo de usuario.
¿Más anuncios significan más dinero?
Aquí llega la primera reflexión de producto seria del artículo, y probablemente la más importante de todas.
Imaginemos una aplicación con 10.000 usuarios que hoy muestra, de media, 2 impresiones por usuario. Eso son 20.000 impresiones diarias. Si decidimos aumentar esa frecuencia a 6 impresiones por usuario, tendríamos 60.000 impresiones diarias: el triple.
La conclusión intuitiva sería que vamos a ganar el triple de dinero. Pero eso no es necesariamente cierto, y aquí está la razón: al aumentar la cantidad de anuncios que ve cada usuario, otras variables del sistema empiezan a moverse también, y no siempre a nuestro favor. El eCPM puede caer, porque la demanda disponible no crece al mismo ritmo que nuestro inventario. El show rate puede empeorar si empezamos a forzar formatos que interrumpen más la experiencia. Y, sobre todo, la experiencia de uso puede deteriorarse hasta el punto de afectar a la duración de las sesiones y a la retención de usuarios.
A este fenómeno se le llama, de forma bastante descriptiva, ad fatigue o presión publicitaria: cuanta más publicidad recibe un mismo usuario en un periodo corto de tiempo, menos tolera cada anuncio adicional, y más probable es que termine abandonando la aplicación antes de tiempo o dejando de usarla por completo.
Y aquí es donde entra un factor que se suele pasar por alto cuando se habla de monetización, y que merece su propio espacio: la recurrencia.
Por qué la recurrencia importa más que el volumen de un solo día
Es tentador mirar la monetización publicitaria como un problema de un solo día: cuántas impresiones puedo generar hoy, a qué eCPM, con qué ingreso resultante. Pero ese enfoque esconde algo esencial: una aplicación no gana dinero por lo que ocurre en un día suelto, sino por la suma de muchos días en los que el mismo usuario sigue volviendo.
Piénsalo con un ejemplo sencillo. Un usuario que abre la aplicación una sola vez y nunca regresa puede generar, en el mejor de los casos, unas pocas impresiones puntuales. Un usuario que vuelve todos los días durante meses, aunque cada sesión individual sea corta y muestre pocos anuncios, termina generando muchísimas más impresiones acumuladas a lo largo del tiempo —y, con ellas, muchísimo más ingreso total—.
Esto es exactamente lo que separa el ARPDAU del valor de vida del usuario (lifetime value, o LTV), un concepto que retomaremos con más detalle en otro artículo de la serie: el ARPDAU mide cuánto genera un usuario en un día concreto, pero el LTV mide cuánto va a generar ese mismo usuario a lo largo de toda su relación con la aplicación, sumando todas las sesiones en las que decide volver.
Por eso maximizar impresiones a corto plazo, sin cuidar la experiencia, suele ser una estrategia que se traiciona a sí misma. Si la presión publicitaria empuja a un usuario a desinstalar la aplicación o a dejar de abrirla, ese usuario deja de generar ARPDAU para siempre a partir de ese momento. Un eCPM más alto hoy no compensa perder mañana, y pasado mañana, y dentro de tres meses, a un usuario que habría seguido volviendo con moderación. La habitualidad —que el usuario vuelva una y otra vez, semana tras semana— es, casi siempre, más valiosa a largo plazo que exprimir al máximo cada sesión individual.
Esto nos lleva a una idea que se va a repetir, en distintas formas, a lo largo de toda esta serie:
Maximizar el número de anuncios mostrados y maximizar el valor real que genera una aplicación no son el mismo problema. El segundo depende del primero, pero también depende de la retención, de la frecuencia de uso y de que la experiencia siga mereciendo la pena para quien la usa.
Juntemos todo: una aplicación ficticia durante un día
Vamos a cerrar con un caso práctico que une todo lo que hemos visto hasta ahora, porque creemos que es la mejor forma de comprobar si los conceptos han quedado claros de verdad.
Supongamos una aplicación con 20.000 DAU (usuarios activos diarios). Cada usuario genera, de media, 5 ad requests al día. Eso nos da el punto de partida:
20.000 DAU × 5 requests/usuario = 100.000 requests
Con un match rate del 92%, obtenemos:
100.000 × 0,92 = 92.000 matched requests
Con un show rate del 80%, llegamos a las impresiones reales:
92.000 × 0,80 = 73.600 impressions
Con un eCPM de 2,50€, calculamos el ingreso del día:
73.600 / 1.000 × 2,50€ = 184€
De ahí obtenemos el Ads ARPDAU:
184€ / 20.000 DAU = 0,0092€
Y si de esas 73.600 impresiones se generaron 736 clics, el CTR es:
736 / 73.600 × 100 = 1%
Ahora hagamos la lectura humana de todos estos números juntos, sin fórmulas de por medio: nuestra aplicación ha tenido 20.000 usuarios activos hoy. Entre todos ellos han generado 100.000 oportunidades publicitarias. Hemos encontrado un anuncio para el 92% de esas oportunidades, pero solo el 80% de los anuncios encontrados llegó realmente a mostrarse. Las 73.600 impresiones resultantes generaron 184€, lo que equivale a un eCPM de 2,50€ y a un ARPDAU publicitario de 0,0092€ por usuario activo y día.
Dicho de otra forma: cada usuario activo nos deja, de media, menos de un céntimo diario en publicidad. Es una cifra minúscula vista de forma aislada. Pero, como acabamos de ver en el apartado anterior, esa cifra tan pequeña es exactamente la que se multiplica por 20.000 usuarios hoy, y se vuelve a generar mañana, y pasado mañana, siempre que esos usuarios sigan teniendo motivos para volver.
Lo importante no es memorizar las siglas
No vamos a cerrar este artículo con una simple lista de lo aprendido. Volvamos, en su lugar, al banner del principio.
Al empezar a leer, el proceso probablemente parecía tan simple como: app → anuncio → dinero. Ahora sabemos que, en realidad, ese proceso se parece mucho más a esto:
Y detrás de cada uno de esos ingresos, sostenidos en el tiempo y no en un único día, hay una combinación muy concreta de factores: usuarios que vuelven con frecuencia, un buen fill rate, un buen show rate y un eCPM razonable para su mercado. Esa combinación es la que convierte publicidad en ingresos realmente sostenibles, y no en un pico puntual que se agota en cuanto deja de renovarse la audiencia.
Aprender qué significa cada sigla es útil, y a partir de ahora ya deberías poder movilizarlas con soltura. Pero entender cómo se relacionan entre sí es mucho más importante que memorizarlas de forma aislada.
Y una vez entendido cómo funciona este mercado, aparece una pregunta bastante más interesante que cualquiera de las que hemos respondido hoy: ¿deberíamos monetizar todas las aplicaciones exactamente de la misma manera? Esa pregunta es la que abre el segundo artículo de esta serie, dedicado a qué modelo de monetización encaja mejor con cada tipo de aplicación.
Happy Earning!!
