Publicidad programmatic in-app: cómo compran los DSP inventario en apps móviles

La mayoría de los media buyers empiezan en la open web. El modelo mental que viene con ella — una URL de página, una cookie, un referrer, un dominio que puedes añadir a una whitelist — funciona razonablemente bien ahí. Luego ese mismo comprador activa inventario de apps móviles y la mitad de esas señales desaparecen sin hacer ruido. No hay URL. No hay cookie de terceros. El campo de dominio está vacío y, en su lugar, llega un bundle ID que parece una cadena de palabras al revés.

No se trata de una versión reducida de la compra en web. El inventario in-app circula por una cadena de suministro distinta, lleva un conjunto diferente de identificadores, usa formatos publicitarios que la web nunca tuvo y se verifica con otro archivo. Un DSP que trate una impresión en app como si fuera una impresión web comprará lo que no debe, interpretará mal sus propios informes y gastará dinero en ubicaciones que no puede ver.

Esta guía explica cómo funciona realmente la publicidad programmatic in-app: qué contiene una bid request de app, cómo se sitúa la capa de SDK y mediación entre un publisher y tu plataforma, qué formatos debe soportar un DSP, cómo cambiaron la identidad y la medición después de que las plataformas móviles endurecieran la privacidad y qué debe configurar un propietario antes de comprar tráfico de apps a escala.

¿Qué es la publicidad programmatic in-app?

La publicidad programmatic in-app es la compra automatizada de ubicaciones publicitarias dentro de aplicaciones móviles — juegos, apps de noticias, utilidades, apps de streaming — mediante subastas en tiempo real en lugar de órdenes de inserción directas. La mecánica es la misma que se usa en el resto del programmatic: una ubicación queda disponible, una bid request la describe, los compradores conectados responden con un precio y la puja válida más alta gana la impresión.

Lo que cambia es el entorno. Una app móvil no es un navegador. No tiene un almacén de cookies compartido, ni barra de direcciones, ni un modelo de objetos del documento que un anuncio pueda inspeccionar. Todo lo que el anuncio necesita — renderizado, medición, gestión de clics — tiene que proporcionarlo el código que el publisher ha compilado dentro de la propia app, y por eso el kit de desarrollo de software (SDK) es el rasgo que define este canal.

La subasta subyacente sigue la misma secuencia descrita en nuestra guía sobre cómo funciona el real-time bidding. Si entiendes una subasta OpenRTB en la web, ya entiendes el noventa por ciento de la subasta in-app. El resto es de lo que trata este artículo.

En qué se diferencia una bid request in-app de una web

En OpenRTB, una bid request describe su inventario mediante un objeto site o un objeto app. Nunca debería llevar ambos. Esa única bifurcación es la que le indica a tu bidder en qué mundo está comprando, y casi todas las diferencias prácticas se derivan de ella.

El objeto app identifica la aplicación por su bundle ID — el nombre del paquete en Android o el ID numérico de la App Store en iOS —, además de una URL de la tienda, el nombre de la app y un bloque del publisher. En lugar de una URL de página y un referrer, tu lógica de segmentación y bloqueo tiene que basarse en el bundle. En lugar de una cookie, el dispositivo se identifica mediante un ID publicitario restablecible que se envía en el objeto device, cuando el usuario lo ha permitido.

Hay dos campos que merecen especial atención en el lado de la compra. El primero es device.lmt, el indicador de limitación del seguimiento publicitario: cuando está activado, el usuario ha rechazado la publicidad personalizada y cualquier segmento de audiencia vinculado a ese dispositivo debe ignorarse, no reutilizarse discretamente. El segundo es app.bundle, porque un bundle mal formado o que no coincide es la señal más habitual de tráfico de apps tergiversado.

La cadena de suministro in-app: SDK, mediación y exchange

En la web, un publisher puede añadir un socio de demanda pegando un tag. En una app, añadir demanda implicaba tradicionalmente integrar otro SDK y publicar una nueva versión de la app pasando por la revisión de la tienda. Esa fricción dio forma a todo el canal, y es la razón por la que una capa intermedia — la mediación — se convirtió en estándar.

Una plataforma de mediación vive dentro de la app como un único SDK y gestiona todas las fuentes de demanda conectadas detrás de él. La mediación inicial funcionaba con un waterfall jerarquizado, llamando a las redes una a una según su precio medio histórico. Las configuraciones actuales usan in-app bidding, que pide a todas las fuentes conectadas que pujen simultáneamente por la misma impresión — el mismo cambio estructural descrito en nuestra comparativa de header bidding vs waterfall.

Desde el punto de vista de tu DSP, la consecuencia práctica es la distancia. Entre la app y tu bidder puede haber una plataforma de mediación, una supply-side platform y uno o varios revendedores, cada uno quedándose una parte y cada uno capaz de añadir o perder señal por el camino. Acortar y auditar esa cadena es precisamente el objetivo de la supply path optimization, y tiene más peso en app que en la web porque la cadena suele ser más larga.

La cadena de suministro también determina lo que puedes exigir. Una conexión directa con un SSP te permite negociar un feed limpio a nivel de bundle y pedirle cuentas a alguien por él. Un feed de un revendedor en el cuarto salto rara vez te ofrece ninguna de las dos cosas. Nuestra checklist sobre cómo conectar SSPs a tu DSP se aplica aquí por completo, con un añadido: pregunta específicamente si el feed es supply de app directo o agregado.

Formatos in-app que un DSP debe soportar

El inventario de apps depende del formato de una forma en que el display web no lo hace. Los juegos, en particular, monetizan con ubicaciones a pantalla completa y basadas en recompensas, y una plataforma que solo sirve banners quedará excluida de la mayor parte del supply valioso antes incluso de empezar a pujar.

• Banner. Ubicaciones pequeñas y fijas ancladas en la parte superior o inferior de la pantalla. Bajo coste, gran volumen y renderizadas a través del contenedor MRAID en lugar de un iframe simple.
• Intersticial. Una unidad a pantalla completa que se muestra en una pausa natural, como entre niveles de un juego o después de un artículo. Más atención, precio más alto y requisitos creativos más estrictos.
• Rewarded video. El usuario elige ver un vídeo a cambio de moneda dentro de la app o de una vida. Las tasas de finalización son altas porque el intercambio es explícito, y el formato está dominado por el supply de gaming.
• Native. Un anuncio renderizado con el diseño y el estilo propios de la app, montado a partir de assets separados de título, imagen y llamada a la acción en lugar de una única creatividad fija.
• Playable. Una demo interactiva breve, usada sobre todo en campañas de instalación de apps, que se entrega como una creatividad interactiva autónoma.

Dos estándares técnicos sostienen la mayor parte de esto. MRAID define cómo se comunica una creatividad rich media con el SDK anfitrión — cómo se expande, se cierra o abre un click-through. VAST define cómo se describen una creatividad de vídeo y sus eventos de tracking. Un DSP que compra inventario de apps necesita ambos, además de la estructura de assets native, o una gran parte de sus respuestas se descartará directamente por incompatible.

El soporte de formatos también cambia cómo interpretas el rendimiento. Una finalización de rewarded video no es comparable con una visualización de banner, y promediarlas en una única cifra combinada oculta qué formato está funcionando de verdad. Desglosar el win rate, el CPM y los informes de conversión por formato es el mínimo útil para las campañas en app.

Identidad y medición dentro de las apps

Las apps nunca usaron cookies de terceros. Usaban un identificador publicitario emitido por la plataforma: el IDFA en iOS y el Google Advertising ID en Android. Ambos pueden ser restablecidos por el usuario y ambos están vinculados al dispositivo y no al navegador, lo que históricamente hizo que la segmentación en app fuera más estable que la web, no menos.

Eso cambió con App Tracking Transparency. Desde iOS 14.5, una app debe pedir permiso al usuario antes de acceder al IDFA para hacer seguimiento entre apps, y sin ese permiso el identificador no está disponible. Android ha avanzado en una dirección similar con su propia opción de exclusión y el trabajo de Privacy Sandbox. El resultado es un gran volumen de tráfico de apps que es realmente anónimo a nivel de dispositivo.

La medición se adaptó mediante marcos de atribución gestionados por la plataforma — SKAdNetwork de Apple y su sucesor, AdAttributionKit —, que reportan las conversiones de instalación de forma agregada y con retraso, en lugar de exponer una ruta clic-instalación a nivel de usuario. Para un comprador, esto significa que los datos de rendimiento de instalaciones llegan más tarde y con menos detalle que los datos de conversión web, y que el pacing de las campañas tiene que tolerar ese desfase.

La respuesta práctica no es perseguir el identificador que falta, sino apoyarse en las señales que sobreviven: el bundle, la ubicación, el formato, la geografía, la hora del día y tus propios datos de conversión first-party. Hoy, la optimización contextual y a nivel de inventario hace la mayor parte del trabajo en app, y esa es una de las razones por las que tener el control de la lógica de puja importa — puedes ponderar esas señales tú mismo en lugar de aceptar el modelo fijo de un proveedor.

Verificación del supply de apps: app-ads.txt e higiene de bundles

El inventario de apps tiene un patrón de fraude específico: la suplantación del bundle ID. Una app de poco valor o inexistente se declara como una app popular, y un comprador que segmenta esa app popular paga un sobreprecio por una impresión que nunca se produjo donde decía producirse. Como el comprador no puede abrir una URL y ver la página, el engaño es más difícil de detectar manualmente que en la web.

La respuesta del sector es app-ads.txt. El desarrollador publica un archivo de vendedores autorizados en el dominio que figura en la ficha de la app en la tienda, y cualquier comprador puede consultar ese archivo y confirmar que el vendedor que ofrece la impresión está realmente autorizado a venderla. La mecánica, y el archivo sellers.json que completa la cadena en la otra dirección, se explican en nuestro artículo sobre ads.txt, app-ads.txt y sellers.json.

Más allá del archivo, unas cuantas comprobaciones detectan la mayor parte de lo demás. Confirma que el bundle existe realmente en la tienda de apps correspondiente. Compara el nombre de app declarado con el bundle. Vigila si un mismo bundle aparece en una dispersión inverosímil de vendedores sin relación entre sí. Y trata las requests con un bundle ausente o mal formado como no comprables, no como tráfico móvil genérico.

Qué configurar antes de comprar tráfico de apps a escala

Activar el supply de apps es un ejercicio de configuración, no un interruptor. La lista siguiente refleja el orden que suele provocar menos sorpresas.

1. Separa las campañas de app y de web. Formatos distintos, identificadores distintos, benchmarks distintos. Mezclarlas hace que ninguna de las dos se pueda interpretar.
2. Activa los formatos que realmente puedes servir. Confirma el soporte de MRAID, VAST y assets native de principio a fin antes de pujar por esas ubicaciones, no después.
3. Activa la verificación de app-ads.txt. Conviértela en una condición de puja, no en un informe posterior a la campaña.
4. Empieza con una allowlist de bundles. Compra primero un conjunto conocido de apps, aprende qué funciona y luego amplía. La segmentación abierta en todo el supply de apps es la forma más cara de descubrir una blocklist.
5. Establece límites de frecuencia por dispositivo, no por cookie. La lógica de frecuencia en app se basa en el ID publicitario y tiene que degradarse de forma controlada cuando ese ID no está presente.
6. Da a las campañas de instalación una ventana de medición más larga. La atribución agregada llega tarde; juzgar un primer día con datos del mismo día te llevará a conclusiones erróneas.
7. Genera informes por bundle y por supply path. El bundle te dice qué compraste; el path te dice cuánto pagaste para conseguirlo.

Cada punto de esa lista es más fácil cuando la plataforma es tuya. En un seat alquilado, el soporte de formatos, las reglas de verificación y la lógica de puja son lo que el proveedor haya decidido exponer. En una plataforma propia, son ajustes que tú controlas — y la compra en apps es precisamente el canal en el que esos controles deciden si la inversión funciona.

¿Listo para comprar inventario de apps en tu propio DSP?

AdTech Europe proporciona la tecnología de demand-side platform que utilizan agencias, ad networks y equipos de compra de medios que prefieren ser dueños de su infraestructura en lugar de alquilar el acceso a la de otros. Todos los planes incluyen escalado ilimitado de QPS, branding white-label y acceso a más de 1.000 integraciones de SSP que cubren web, app y canales emergentes, de modo que el supply de apps forma parte de la plataforma y no es un complemento que tengas que negociar por separado.

A septiembre de 2026, el White Label DSP cuesta $500 al mes, sin cuota de alta y con contrato mes a mes, y se despliega en 24 horas. Una DSP License cuesta $25,000 en un único pago, y una DSP Acquisition con propiedad total del código fuente cuesta $50,000 en un único pago; ambas están disponibles en cinco cuotas mensuales y se despliegan en un plazo de cinco a siete días hábiles. Los detalles actualizados están siempre en la página de precios.

Si tienes previsto añadir inventario de apps a tu mix de compra y quieres repasar formatos, verificación del supply y configuración del bidder a partir de tus propias campañas, puedes agendar una reunión de estrategia programmatic con el equipo.

Preguntas frecuentes

¿Qué es la publicidad programmatic in-app?

La publicidad programmatic in-app es la compra automatizada de ubicaciones publicitarias dentro de aplicaciones móviles mediante subastas en tiempo real. La mecánica de la subasta es la misma que en el resto del programmatic, pero el inventario se describe con el bundle ID de una app en lugar de con una URL de página, y el anuncio lo renderiza un SDK dentro de la app en lugar de un navegador.

¿En qué se diferencia una bid request in-app de una bid request web?

Una request in-app lleva un objeto app de OpenRTB en lugar de un objeto site. Eso significa un bundle ID y una URL de la tienda en lugar de un dominio y una URL de página, un ID publicitario del dispositivo en lugar de una cookie, y señales de formato para unidades intersticiales, rewarded o playable que la open web no utiliza.

¿Qué es app-ads.txt y por qué importa en la compra de apps?

App-ads.txt es un archivo publicado en el sitio web del desarrollador de la app que enumera los vendedores autorizados a vender el inventario de esa app. Los compradores lo usan para confirmar que quien ofrece una impresión en app tiene realmente derecho a venderla, y es la principal defensa contra la suplantación del bundle ID.

¿Se pueden seguir segmentando audiencias en apps después de App Tracking Transparency?

La segmentación de audiencias a nivel de dispositivo solo funciona cuando el usuario ha concedido permiso y el identificador publicitario está presente en la request. Para el resto del tráfico de apps, la segmentación se basa en señales contextuales y de inventario como el bundle, la ubicación, el formato, la geografía y la hora, además de tus propios datos de conversión first-party.

¿Por qué necesita un DSP soporte de MRAID y VAST para el inventario de apps?

MRAID define cómo interactúa una creatividad rich media con el SDK del publisher, y VAST define cómo se describen las creatividades de vídeo y sus eventos de tracking. Sin ambos, una gran parte de las ubicaciones en apps rechazará o descartará tu creatividad, de modo que esas bid responses nunca se convertirán en impresiones servidas.

¿Qué es la mediación en la publicidad en apps móviles?

La mediación es una capa dentro de la app que gestiona varias fuentes de demanda a través de un único SDK, lo que evita al publisher tener que integrar cada socio por separado. La mediación antigua funcionaba con un waterfall jerarquizado; el in-app bidding actual pide a todas las fuentes conectadas que pujen a la vez por la misma impresión.

¿Necesitas tu propio DSP para comprar inventario in-app?

No, pero la propiedad cambia lo que puedes controlar. En una plataforma propia defines tú mismo el soporte de formatos, las reglas de verificación del supply, las allowlists de bundles y la lógica de puja, en lugar de trabajar dentro de la configuración que exponga un seat alquilado.