El primero que llega no siempre es el que más paga

Vuelve a la lonja del artículo anterior . Tienes una caja de pescado y cuatro compradores dentro del edificio. Hay dos formas muy distintas de venderla.

La primera es ir puesto por puesto. Empiezas por el comprador que, según tu experiencia, suele pagar mejor y le preguntas si la quiere. Si dice que sí, se la queda. Si dice que no, pasas al siguiente, y así hasta que alguien la compre o se acaben los compradores. Es un sistema sencillo y predecible, pero tiene un problema evidente: el primero que dice que sí se lleva la caja, aunque el tercero hubiera pagado el doble por ella ese día.

La segunda es subirte a una tarima, enseñar la caja a todos a la vez y pedir que cada uno diga cuánto ofrece. Te quedas con la oferta más alta. Ya no dependes de tu memoria sobre quién suele pagar mejor, porque cada comprador te dice cuánto vale para él esa caja concreta, ahora. Pero, para que funcione, todos tienen que estar en la sala, dispuestos a pujar y con las reglas de la subasta claras.

En la publicidad digital, a la primera forma se le llama waterfall, o cascada. A la segunda, bidding, o puja. Y, como pasa en muchas lonjas reales, lo más habitual hoy no es elegir una de las dos, sino combinarlas.

Este es el sexto artículo de la serie sobre monetización publicitaria. En el primero vimos cómo funciona el mercado publicitario. En el segundo , qué modelo de monetización encaja con cada producto. En el tercero , cómo colocar los anuncios sin estropear la experiencia. En el cuarto , cómo leer los números. Y en el quinto , qué es la mediación, para qué sirve y cuándo merece la pena. Aquel artículo terminaba con una pregunta que dejamos en el aire a propósito:

Cuando la mediación pregunta a varios compradores, ¿cómo decide quién se queda con cada hueco?

Hoy toca responderla. Al terminar, deberías poder explicar qué ocurre por dentro en cada tipo de configuración, por qué muchas combinan ambos modelos, qué piezas técnicas pueden hacer que pierdas dinero sin darte cuenta y cómo comparar configuraciones sin dejarte engañar por una sola cifra.

Una impresión, varias fuentes posibles

Lo que ya sabemos de la mediación

Un repaso rápido, solo lo imprescindible. La mediación no trae usuarios ni crea huecos publicitarios. Lo que hace es coordinar a varios compradores, las redes publicitarias, para que compitan por cada hueco que tu aplicación ya tiene. A cada uno de esos compradores, dentro de la mediación, se le suele llamar fuente de demanda o fuente de anuncios (en AdMob, ad source). Puede ser una red externa o la propia red de la plataforma que hace de mediador, como vimos con AdMob, que organiza la lonja y además compra en ella.

Todo lo que veremos hoy ocurre después de que tu aplicación haya decidido que en ese momento cabe un anuncio. Si la decisión de mostrarlo es mala, ningún modelo de mediación la arregla.

El recorrido de una solicitud, en dos líneas

Para seguir cada modelo vamos a usar un único hueco de nuestra aplicación de siempre, la de los 20.000 usuarios diarios. Un usuario de España termina una partida y la aplicación quiere mostrarle un intersticial. Pide un anuncio a la mediación, que mira su configuración, decide a qué fuentes preguntar y en qué orden, y devuelve un anuncio, o ninguno.

Lo que cambia entre modelos es justo esa parte central: a quién se pregunta, cuándo y con qué información se compara lo que responde cada uno.

Las cifras que usaremos son redondas e inventadas. Sirven para ver el mecanismo, no como referencia de lo que paga ninguna red. El orden y el resultado reales dependen de la plataforma, del inventario, de la configuración y de lo que cada fuente tenga disponible en cada momento.

Waterfall: las fuentes se prueban por turnos

Cómo se ordenan las fuentes y qué representa el eCPM configurado

En un waterfall, la mediación tiene una lista ordenada de fuentes. Pregunta a la primera. Si tiene anuncio, se queda con el hueco. Si no, baja a la segunda, y así sucesivamente, como el agua que cae de un escalón a otro. De ahí el nombre.

La pregunta interesante es quién decide ese orden. En un waterfall, las fuentes se ordenan por un eCPM asignado a cada una. Ese valor no es lo que la red ofrece por este hueco concreto. Es una estimación de lo que suele pagar de media, que en unos casos introduces tú a mano y en otros calcula la propia plataforma a partir de datos históricos. En AdMob, por ejemplo, la documentación lo explica así: el waterfall llama a las fuentes una a una según el eCPM medio que se ha configurado, no según lo que la fuente está dispuesta a pagar.

Esa diferencia es la clave de todo el modelo. Supongamos que nuestra mediación tiene tres fuentes en cascada:

Y supongamos que, para el hueco de este usuario concreto, en este momento concreto, la Red A tiene un anuncio por el que pagaría el equivalente a 2,50 €, mientras que la Red B tiene un anunciante que pagaría 5,00 €. ¿Qué pasa? La mediación pregunta a la Red A, que tiene anuncio, y se lo queda. La Red B ni siquiera llega a enterarse de que el hueco existía. Hemos vendido por 2,50 € algo por lo que alguien habría pagado el doble.

No es un fallo de la mediación. Es exactamente lo que se le pidió: preguntar en orden según una media. Y las medias, por definición, se equivocan en muchos casos concretos.

Waterfall con tres fuentes ordenadas por eCPM asignado: Red A (4,00 €), Red B (3,00 €) y Red C (1,00 €). La mediación pregunta primero a la Red A, que tiene un anuncio que vale 2,50 € para este hueco, y se lo queda. La Red B, que habría pagado 5,00 €, nunca llega a ser consultada. Debajo, una nota: el orden lo decide una media histórica, no lo que cada red ofrece ahora.

Qué pasa cuando una fuente no responde, no tiene anuncio o no puede servirlo

Cada escalón de la cascada puede terminar de tres formas que conviene distinguir:

• La fuente responde que no tiene anuncio. Es el caso más limpio. La mediación baja al siguiente escalón.
• La fuente no responde a tiempo. La mediación no espera indefinidamente: hay un tiempo límite, un timeout, a partir del cual da la respuesta por perdida y sigue bajando. Ese tiempo ya se ha consumido.
• La fuente dice que sí, pero el anuncio no llega a servirse. Por ejemplo, porque falla al cargar su contenido. Según la plataforma y el formato, la mediación podrá intentarlo con el siguiente escalón o no, pero en cualquier caso se ha perdido tiempo.

Fíjate en el patrón: cada “no” cuesta tiempo. Si la Red A tarda en contestar que no tiene nada, y luego la Red B tarda en contestar que tampoco, cuando la Red C entrega por fin su anuncio puede que el usuario ya esté en la siguiente partida. En el artículo anterior vimos cómo esas esperas podían comerse casi la mitad de lo que la mediación había ganado. En un waterfall largo, ese riesgo crece con cada escalón.

Ventajas y límites

El waterfall tiene virtudes reales, y por eso sigue existiendo:

• Control. Sabes exactamente en qué orden se pregunta y puedes razonar sobre él.
• Simplicidad conceptual. Es fácil de explicar y de depurar: si algo va mal, puedes recorrer la lista escalón a escalón.
• Compatibilidad. Casi cualquier red puede participar en una cascada, aunque no tenga capacidad de pujar en tiempo real.

Y tiene límites igual de reales:

• El orden es imperfecto por diseño. Se basa en medias, y cada hueco concreto vale lo que vale, no la media. Ya hemos visto el resultado: vender barato cuando había alguien dispuesto a pagar más abajo en la lista.
• Las esperas se acumulan. Cada fuente sin anuncio añade tiempo antes de llegar a la siguiente.
• Requiere mantenimiento. Los precios del mercado cambian por temporada, país o campaña. Un orden que tenía sentido en septiembre puede estar desfasado en diciembre, y si los valores asignados no se revisan, la cascada sigue preguntando en un orden que ya no refleja la realidad.

Si tuvieras que resumirlo, el waterfall cambia precisión por control: sabes qué hace, pero lo hace basándose en lo que pasaba antes, no en lo que pasa ahora.

Bidding: varias fuentes compiten por la oportunidad

Qué significa que una fuente puje en tiempo real

En el bidding, la mediación no pregunta por turnos. Envía la oportunidad a todas las fuentes que participan a la vez, y cada una responde con una puja: cuánto está dispuesta a pagar por ese hueco concreto, en ese momento, sabiendo lo que se sabe de él (formato, país, plataforma, consentimiento, etc.). Gana la oferta más alta.

La diferencia con el waterfall es de fondo. Ya no se compara una media histórica con otra media histórica. Se comparan ofertas reales para esta impresión. Si la Red B tiene hoy un anunciante que pagaría 5,00 € por este usuario, lo dice, y gana.

Una aclaración de vocabulario que evita muchas confusiones. En el primer artículo vimos que dentro de cada red sus anunciantes ya compiten entre ellos mediante subastas. El bidding de la mediación es otra capa por encima: las redes compiten entre sí, cada una con lo mejor que ha encontrado dentro. Es la “competición entre competiciones” del artículo anterior , pero ahora en tiempo real y no en fila.

Cómo se compara la puja con otras fuentes participantes

Volvamos a nuestro hueco. Supongamos que tres fuentes participan con bidding:

La mediación recibe las tres pujas, compara y la Red B gana. Las fuentes que no tienen anuncio, sencillamente, no pujan, así que un “no tengo nada” ya no añade un escalón de espera, porque todas se consultan a la vez.

Hay detalles que dependen de cada plataforma y que conviene consultar en su documentación en lugar de darlos por supuestos: qué precio paga exactamente el ganador, cuánto tiempo se espera a que lleguen las pujas o qué pasa si el anuncio ganador falla después al cargarse. Lo importante, a nuestro nivel, es la idea: cada impresión se vende a quien más la valora en ese momento, entre quienes pueden pujar.

Bidding con tres fuentes consultadas a la vez para el mismo hueco: la Red X puja 3,20 €, la Red Y puja 2,90 € y la Red B puja 5,00 €. La mediación compara las tres ofertas al mismo tiempo y gana la Red B. Debajo, una nota: las fuentes sin anuncio no pujan, así que no añaden escalones de espera.

Ventajas y límites

Las ventajas se ven claras en el ejemplo:

• Precio más ajustado a cada impresión. Se acaba el problema de vender a la primera de la lista cuando otra pagaba más.
• Menos mantenimiento manual del orden. No hay que asignar y revisar eCPM para las fuentes que pujan; el precio lo ponen ellas en cada subasta.
• Menos esperas encadenadas. Las fuentes se consultan en paralelo, no una detrás de otra.

Pero el bidding no es gratis, y sus límites son menos evidentes:

• No todas las fuentes pueden pujar. Hace falta que la red tenga esa capacidad, que la plataforma de mediación la admita y, en muchos casos, un acuerdo con la red antes de que empiece a recibir solicitudes. Si una red interesante para tu país o formato solo trabaja en cascada, no estará en la subasta.
• Requisitos técnicos. Los componentes de cada red tienen que estar en versiones compatibles y correctamente inicializados antes de pedir anuncios; si no, esa red no puja, aunque esté configurada.
• Dependencias de privacidad y política. Para pujar, una red necesita información sobre el hueco, y eso exige que esté declarada en tu aviso de consentimiento y que cumpla ciertas condiciones. Por ejemplo, AdMob indica hoy que las fuentes con bidding no sirven anuncios en aplicaciones o solicitudes dirigidas a menores. Si tu producto tiene ese público, el bidding cambia mucho de valor.
• Menos visibilidad del “porqué”. En un waterfall puedes razonar el orden. En una subasta, sabes quién ganó y por cuánto, pero tienes menos control sobre cómo decide cada red su puja.

Dicho de forma breve, el bidding cambia control por precisión: compite mejor, pero solo entre quienes pueden y saben pujar.

Waterfall y bidding juntos: el modelo híbrido

Por qué una misma mediación puede combinar ambos

Si el bidding compite mejor, ¿por qué no usar solo bidding? Porque, en la práctica, casi nunca están todas las fuentes que te interesan en condiciones de pujar. Puede que una red que funciona muy bien en tu segundo país solo trabaje en cascada. O que tengas un acuerdo directo con un anunciante que se gestiona con un precio fijo. Renunciar a esas fuentes para tener una subasta “pura” puede significar más huecos vacíos.

Por eso, lo más habitual hoy es un modelo híbrido: unas fuentes pujan, otras se consultan en cascada, y la mediación las hace convivir en la misma decisión. Es el término que usa, por ejemplo, AdMob para esta configuración.

Cómo conviven las fuentes con puja y las llamadas en cascada

La forma concreta depende de la plataforma, pero el esquema más extendido, y el que describe la documentación de AdMob, funciona así:

1. Primero, las fuentes con bidding hacen su subasta. Sale una ganadora, con su puja.
2. Esa ganadora se coloca en la cascada según el valor de su puja, como si fuera un escalón más, junto a las fuentes de waterfall ordenadas por su eCPM asignado.
3. La mediación recorre la cascada desde arriba. Si la ganadora de la subasta queda en primer lugar, se queda el hueco sin que se pregunte a nadie más. Si alguna fuente de waterfall queda por encima, se le pregunta antes a ella.

Veámoslo con nuestro hueco. En la subasta pujan la Red X (3,20 €) y la Red Y (3,40 €); gana la Red Y. En cascada siguen la Red A, con un eCPM asignado de 4,00 €, y la Red C, con 1,00 €. El orden resultante queda así:

La mediación pregunta primero a la Red A. Si no tiene anuncio, la Red Y se queda con el hueco y la Red C ni siquiera se consulta. Pero si la Red A sí tiene anuncio, se lo queda ella, y recuerda lo que vimos antes: su 4,00 € es una media. Si para este hueco su anuncio vale en realidad 2,50 €, acabamos de vender por menos de lo que la Red Y había ofrecido de forma firme.

Mediación híbrida en dos fases. En la primera, la Red X puja 3,20 € y la Red Y puja 3,40 €; gana la Red Y. En la segunda, la ganadora se inserta en la cascada según su puja: Red A (eCPM asignado 4,00 €) en primer lugar, Red Y (puja de 3,40 €) en segundo y Red C (1,00 €) en tercero. Si la Red A tiene anuncio, se lo queda aunque para este hueco valga solo 2,50 €; si no, gana la Red Y y la Red C no llega a consultarse.

Qué complejidad adicional introduce y qué no garantiza

El ejemplo deja ver lo que el modelo híbrido añade y lo que no resuelve:

• Hereda los problemas del waterfall para las fuentes en cascada. Un eCPM asignado demasiado alto puede colocar a una red por encima de pujas reales mejores. Uno demasiado bajo la deja sin oportunidades. Los valores asignados siguen necesitando revisión.
• Hereda los requisitos del bidding. Versiones compatibles, inicialización correcta, consentimiento y acuerdos con cada fuente que puja.
• Es más difícil de leer. Cuando algo cambia en los ingresos, puede venir de la subasta, de la cascada o de cómo interactúan.

Y, sobre todo, no garantiza que ganes más. Un híbrido bien configurado suele aprovechar lo mejor de ambos mundos; uno mal configurado puede tener lo peor de los dos. El modelo no decide el resultado: lo decide cómo está montado.

No confundir el modelo con la configuración

Hasta aquí hemos hablado de modelos: formas de organizar la competencia. Pero en el panel de cualquier plataforma no vas a encontrar un botón que diga “waterfall” o “bidding”. Vas a encontrar grupos, unidades, fuentes, mapeos y adapters. Conviene separar bien cada pieza, porque es aquí donde la mayoría de la gente se pierde.

Red publicitaria, plataforma de mediación y fuente de demanda

Tres términos que se solapan y que conviene tener claros:

• Red publicitaria: la empresa que compra con el dinero de sus anunciantes. Ya la conocemos.
• Plataforma de mediación: la herramienta que organiza la competencia. AdMob, por ejemplo, ofrece mediación además de ser red.
• Fuente de demanda (ad source): cómo ve la plataforma de mediación a cada participante dentro de su configuración. Una misma red puede aparecer como fuente con bidding, como fuente en cascada, o incluso, según la plataforma, de ambas formas a la vez.

Es decir, “la Red B” es una empresa, pero dentro de tu mediación es una o varias fuentes con reglas concretas.

Grupos de mediación, unidades publicitarias y mapeos

Una unidad publicitaria (ad unit) es el identificador que usa tu aplicación al pedir un anuncio, como vimos en el primer artículo . Cada hueco técnico de tu aplicación apunta a una.

Un grupo de mediación (mediation group) es el conjunto de reglas que dice: “para las solicitudes que cumplan estas condiciones, estas son las fuentes que compiten y así es como lo hacen”. Las condiciones suelen ser el formato, la plataforma, el país y las unidades publicitarias incluidas. En nuestra aplicación podría haber un grupo para intersticiales en Android desde España, con cuatro fuentes, y otro para banners en el segundo país, con dos.

Dos detalles que suelen pillar por sorpresa, al menos en AdMob:

• Si una solicitud encaja en varios grupos, se aplica solo uno, el de mayor prioridad. Los grupos no se encadenan: si en el elegido ninguna fuente tiene anuncio, no se pasa al siguiente grupo.
• Si una solicitud no encaja en ningún grupo, se atiende con un grupo por defecto que solo usa la red propia de la plataforma. Es decir, si te equivocas al definir un grupo, puede que toda esa parte de tu tráfico esté funcionando sin mediación y no te des cuenta.

Por último, el mapeo es la pieza que conecta tu unidad publicitaria con su equivalente en cada red externa. Cada red tiene sus propios identificadores, y la plataforma de mediación necesita saber, para cada unidad, a qué identificador de cada red tiene que pedir. Un mapeo que falta o apunta a una unidad equivocada suele traducirse en una red que nunca gana, sin errores visibles.

Adapter: qué conecta y por qué su versión importa

Un adapter es un pequeño componente que se añade a tu aplicación para que el SDK de la plataforma de mediación pueda hablar con el SDK de cada red. La plataforma “habla” su propio idioma; cada red, el suyo. El adapter traduce: pasa la solicitud a la red, recoge su respuesta y la devuelve en un formato que la mediación entiende.

Por eso, en una configuración con varias redes, tu aplicación no lleva solo el SDK del mediador, sino también, por cada red externa, su SDK y su adapter. Y cada uno tiene su versión. Si el adapter no es compatible con la versión del SDK de su red, o con la del SDK del mediador, lo normal es que esa red falle de forma silenciosa: está en la configuración, pero no puja, no sirve anuncios o lo hace peor de lo que podría.

Un buen hábito es tratar las versiones de SDK y adapters como una sola pieza: se actualizan juntos, siguiendo las tablas de compatibilidad que publica cada plataforma, y se comprueban antes de publicar una nueva versión de la aplicación.

El coste operativo de cada setup

En el artículo anterior dijimos que la mediación añade trabajo técnico y de gestión. Ahora podemos ver con más detalle dónde se esconde ese trabajo.

Inicialización del SDK y carga de adapters

Antes de pedir el primer anuncio, el SDK del mediador tiene que inicializarse, y con él los adapters de cada red. Si la aplicación pide un anuncio antes de que ese proceso termine, algunas redes pueden no participar en las primeras solicitudes. La guía técnica de AdMob para Android, por ejemplo, recomienda esperar a que la inicialización termine antes de cargar anuncios, precisamente para que todas las redes participen desde la primera solicitud, y señala que las fuentes con bidding requieren esa inicialización explícita.

La misma inicialización devuelve el estado de cada adapter, con cuánto ha tardado en arrancar. Es una información muy útil durante el desarrollo: un adapter que no arranca, o que tarda demasiado, es una red que no va a competir aunque aparezca en el panel.

Esto conecta con lo que vimos en el tercer artículo sobre los anuncios de apertura y la precarga: los primeros segundos de una sesión son un momento delicado, y una inicialización lenta puede afectar tanto a los ingresos como a la experiencia.

Latencia, timeouts, errores y anuncios que no llegan a mostrarse

Cada modelo tiene su propio perfil de espera:

• En un waterfall, la latencia crece con cada fuente que no tiene anuncio o no responde a tiempo antes de llegar a una que sí.
• En el bidding, las fuentes se consultan en paralelo, pero la subasta no se cierra hasta que llegan las pujas o se agota el tiempo previsto.
• En el híbrido, se suman ambas cosas: primero la subasta, luego la parte de cascada que quede por encima.

Esa espera importa porque el usuario no se queda quieto. En formatos que se precargan, como intersticiales o recompensados, un poco más de latencia puede no notarse si la carga empieza con suficiente antelación. En formatos que se piden justo cuando se van a mostrar, como un banner al abrir una pantalla, cada fracción de segundo cuenta. Y en todos ellos, un anuncio encontrado pero no mostrado no genera ingresos. Es la métrica de show rate que vimos en el cuarto artículo : la que mejor delata una configuración que gana subastas pero pierde impresiones.

Un ajuste práctico: cuando una red se gestiona a través de la mediación, algunas funciones que la propia red tiene por su cuenta conviene desactivarlas en su panel. El ejemplo clásico es el refresco automático de banners: si lo controlan a la vez la mediación y la red, el comportamiento puede volverse impredecible.

Actualizaciones, compatibilidad y reporting entre SDK, mediador y red

El mantenimiento no termina con la primera integración. Las redes publican nuevas versiones de sus SDK; los mediadores, nuevas versiones de sus adapters; las tiendas cambian requisitos; las normas de privacidad evolucionan. Con varias redes, alguna de esas piezas cambia casi cada mes.

Y luego está el reporting. Cada pieza cuenta lo que ve:

• El SDK en tu aplicación sabe qué se pidió, qué se cargó y qué se mostró.
• El mediador sabe a quién preguntó, quién ganó y por cuánto, y suele ofrecer un informe de mediación por fuente.
• Cada red informa de lo que facturó, con sus propios criterios y, a veces, con días de retraso.

Que las cifras no coincidan exactamente es normal, como ya vimos en el cuarto artículo . Lo que no es normal es una diferencia grande y sostenida para una red concreta, porque suele señalar un mapeo erróneo, un adapter desactualizado o una red que cuenta impresiones de otra forma. Revisar periódicamente esas diferencias es parte del trabajo de mantener una mediación.

Cómo comparar configuraciones sin dejarse engañar por el eCPM

Tarde o temprano vas a cambiar algo: pasar una red de cascada a bidding, añadir una fuente nueva, reordenar el waterfall. Y vas a querer saber si ha funcionado. Aquí está la trampa más común.

Leer ingresos junto con requests, impresiones, show rate y latencia

El eCPM es la cifra más tentadora de mirar, y la más engañosa por sí sola. Si eliminas de la cascada las fuentes que pagan poco, el eCPM medio sube, pero puede que llenes muchos menos huecos y que acabes ganando menos. Si añades una red que llena huecos baratos, el eCPM baja, pero quizá ganes más en total.

Por eso, al comparar configuraciones, conviene mirar siempre el conjunto:

Una configuración mejor es la que sube los ingresos por usuario sin empeorar el show rate ni la experiencia, no la que tiene el eCPM más alto.

Comparar segmentos equivalentes: país, plataforma, formato y periodo

Comparar “antes” y “después” en bloque mezcla demasiadas cosas. Lo razonable es comparar segmentos equivalentes: intersticiales de Android en España antes y después del cambio, no “toda la app”. Y en periodos comparables. Un cambio de configuración publicado a finales de noviembre coincidirá con la subida estacional de precios que ya comentamos en el cuarto artículo , y será muy tentador atribuirle un mérito que no tiene.

También ayuda cambiar una cosa cada vez y anotarlo con fecha en el registro de cambios del que hablamos en el artículo de métricas . Si un mismo día pasas una red a bidding, añades otra en cascada y actualizas tres adapters, cuando los ingresos cambien no sabrás por qué.

Algunas plataformas permiten hacer pruebas A/B de la configuración de mediación, repartiendo el tráfico entre dos variantes al mismo tiempo. Es la forma más limpia de comparar, porque elimina buena parte del ruido de estacionalidad. Cómo diseñar esos experimentos sin engañarse merece un artículo propio, y será precisamente el próximo de la serie.

Evitar atribuir mejoras a la mediación cuando cambió el volumen o la mezcla de usuarios

El error más habitual al evaluar la mediación es no darse cuenta de que cambió el tráfico, no la configuración. Si una campaña trae muchos usuarios de un país con precios altos, el eCPM medio subirá aunque la mediación no haya mejorado nada. Si una actualización de la aplicación hace que los usuarios lleguen más a menudo al final de nivel, habrá más solicitudes de intersticial y más ingresos totales, sin que el reparto entre redes haya cambiado.

La pregunta que hay que hacerse siempre es: en el mismo segmento, con un volumen comparable, ¿cada solicitud rinde más que antes? Si la respuesta es sí, la mejora probablemente sea de la configuración. Si no puedes responderla, todavía no sabes nada.

¿Cuándo tiene sentido revisar tu setup?

Señales de que el waterfall está desactualizado o mal ordenado

• Los eCPM asignados llevan meses sin tocarse, y en los informes el eCPM real de algunas fuentes se aleja mucho de su valor asignado.
• Una fuente situada arriba gana casi todas las impresiones, pero con un eCPM real claramente inferior al asignado.
• Hay fuentes en los últimos escalones que casi nunca llegan a ser consultadas, o fuentes que lo son muchas veces y casi nunca tienen anuncio.
• La latencia de carga o los anuncios perdidos crecen en un formato o país concreto.

Muchas plataformas ofrecen ajustar automáticamente los eCPM asignados a partir de datos históricos. Ayuda a reducir el desfase, pero no lo elimina: sigue siendo una media.

Cuándo una configuración con bidding puede merecer evaluación

• Trabajas con redes que ofrecen bidding en tu plataforma de mediación y hoy están en cascada.
• Tu volumen es suficiente para que varias fuentes compitan de verdad en tus principales países y formatos.
• Pasas demasiado tiempo manteniendo el orden de la cascada y aun así sospechas que vendes barato.
• Tu producto no está dirigido a menores y tu flujo de consentimiento está bien resuelto, porque de ello depende que las fuentes con bidding puedan participar.

Cuándo la complejidad añadida probablemente no compensa

• Tu aplicación es pequeña, con usuarios concentrados en un país donde una sola red ya cubre bien los huecos. Como vimos en el artículo anterior , quizá ni siquiera necesites mediación.
• No tienes tiempo ni equipo para mantener SDK, adapters y mapeos al día. Una configuración avanzada mal mantenida puede rendir peor que una sencilla bien cuidada.
• Todavía no mides bien lo básico: solicitudes, impresiones, show rate e ingresos por usuario. Sin eso, no sabrás si el cambio ha servido.

La mediación organiza la competencia; el resultado depende del sistema completo

Volvamos a la lonja. Ir puesto por puesto o subir la caja a una tarima son dos formas de vender el mismo pescado. Ninguna de las dos es mejor siempre. La primera te da control y funciona con cualquier comprador, pero depende de que tu memoria sobre quién paga mejor siga siendo cierta. La segunda pone un precio más justo a cada caja, pero solo entre quienes pueden y quieren pujar. Y la mayoría de las lonjas reales hacen las dos cosas a la vez, con todo lo que eso tiene de bueno y de complicado.

Si tuvieras que quedarte con tres ideas de este artículo, serían estas. En un waterfall, las fuentes se consultan en orden según una media, y el primero que dice que sí se queda el hueco aunque otro pagara más. En el bidding, las fuentes pujan a la vez por cada impresión concreta, pero solo pueden participar las que cumplen sus requisitos. Y en un modelo híbrido, ambas formas conviven en una misma decisión, lo que puede sumar sus ventajas o sus errores según cómo esté configurado.

Y por debajo de todo eso, las piezas que de verdad deciden si la configuración funciona: grupos bien definidos, unidades bien mapeadas, adapters actualizados, una inicialización correcta y una lectura de los datos que no se quede en el eCPM.

Pero no perdamos la perspectiva de la serie. La mediación decide quién compra cada hueco; no decide si el hueco está bien colocado, si llega en buen momento ni si el usuario volverá mañana. Todo lo que vimos sobre modelos de monetización , formatos y emplazamientos y métricas sigue pesando más que cualquier ajuste de la cascada.

Queda, sin embargo, una duda que probablemente te haya ido rondando mientras leías, y que tarde o temprano se plantea cualquiera que tenga un producto con publicidad. Imagina que abres tu panel con todo lo que hemos visto en la cabeza. Sospechas que tu cascada lleva meses desordenada, o que esa red que sigue en waterfall rendiría más pujando. Pero tu configuración actual funciona, te da unos ingresos con los que cuentas cada mes, y tocarla tiene algo de salto al vacío. ¿Y si lo cambias y empiezas a ganar menos? ¿Y si ganas más, pero no por tu cambio, sino porque ha llegado diciembre? ¿Cuánto tiempo tendrías que esperar para estar seguro, y cuánto dinero estarías dispuesto a perder mientras tanto?

Dicho de otra forma: ¿hay manera de saber si un cambio mejoraría tus ingresos antes de aplicarlo a todos tus usuarios, en lugar de tocar la configuración a ciegas y cruzar los dedos? La hay, y no consiste en adivinar ni en fiarse de la intuición, sino en dejar que una parte de tus usuarios pruebe el cambio mientras el resto sigue como hasta ahora, y comparar ambos grupos en igualdad de condiciones. Es lo que se conoce como un experimento A/B, y bien planteado convierte cada duda como esta en una decisión con datos detrás. Cómo diseñarlo, qué medir y cómo leer sus resultados sin engañarte será el tema del próximo artículo de la serie.

Happy Earning!!