The Trade Desk se queda fuera de Safari en iOS 27: probablemente sea un error, pero el aviso para la Open Web es bastante más serio
The Trade Desk se enfrenta a un problema bastante poco habitual en Safari tras el lanzamiento de iOS 27. Según publicó AdExchanger, Apple ha incluido adsrvr.org entre los dominios que Safari bloquea de forma incondicional en dispositivos actualizados al nuevo sistema operativo. El asunto podría parecer otra batalla dentro de la larga guerra entre Apple y el tracking publicitario si no fuera por un detalle importante: adsrvr.org no sirve únicamente para identificar usuarios. The Trade Desk lo utiliza como infraestructura central para solicitar y entregar publicidad. El resultado, al menos mientras el bloqueo siga activo, es que el DSP no puede servir anuncios en Safari a usuarios de iPhone y iPad con iOS 27.
iOS 27 empezó a desplegarse el 14 de septiembre y la actualización amplió una política que Apple ya utilizaba contra dominios relacionados con brokers de datos, identificación direccionable y seguimiento entre distintas webs. En la misma lista aparecen uidapi.com, asociado a Unified ID 2.0, y dominios utilizados por ID5, LiveRamp, Permutive y Audigent, entre otros. En esos casos la intención de la medida resulta relativamente fácil de entender dentro de la política de privacidad de Safari. El caso de The Trade Desk es diferente precisamente porque la regla se ha aplicado al dominio registrable adsrvr.org y, por tanto, alcanza también a los subdominios utilizados para transportar solicitudes publicitarias.
Ian Meyers, Senior Director of Engineering en The Trade Desk, abrió el 21 de septiembre un ticket de máxima prioridad en WebKit para pedir que Apple revisara la inclusión del dominio. Allí explica que “el objetivo de la nueva lista parece ser bloquear infraestructura vinculada a identidad post-cookie, pero distingue expresamente adsrvr.org de esa función”. John Wilander, responsable de privacidad y AdTech en WebKit, contestó que Apple estaba investigando el caso. Seis días después, ante una petición de The Trade Desk para conocer cuándo habría alguna conclusión, Wilander se limitó a señalar que avisaría “si y cuando” hubiera cambios disponibles para probar. A fecha de la última actualización pública del ticket, el caso continuaba abierto, clasificado como P1 y de severidad Major. La hipótesis más benigna, y también una de las que más se repite entre profesionales que han reaccionado al caso, es que Apple se haya pasado de frenada. Quería bloquear determinados mecanismos de identidad y terminó metiendo en el mismo saco un dominio que sirve también para entregar anuncios. Es plausible, pero todavía es una interpretación, no una explicación ofrecida por Apple. Tampoco puede darse por hecho que el impacto comercial para The Trade Desk vaya a ser enorme: el ticket público documenta el fallo específicamente en Safari 27 sobre iPhone y iPad con iOS 27; no documenta afectación en Safari para macOS.
A esto se suma que la adopción de un nuevo sistema operativo es progresiva, por lo que el porcentaje de inventario afectado crecería a medida que los usuarios actualicen sus dispositivos si el problema continuase. De ahí que algunas reacciones del mercado hayan rebajado el dramatismo. Si un DSP sabe que determinado entorno no puede completar correctamente la entrega, lo lógico sería que sus sistemas terminasen reduciendo o evitando esas oportunidades y si Apple corrige la lista en pocos días o semanas, el episodio podría acabar siendo poco más que una anomalía técnica. Pero también ha aparecido la pregunta contraria, bastante más incómoda: qué sucede durante el intervalo entre la puja y la impresión. Si una plataforma participa en una subasta pero el navegador bloquea después alguna petición necesaria para completar la entrega, hay que saber exactamente en qué punto se interrumpe el flujo y si existen escenarios en los que se genere una puja ganadora sin que el anuncio llegue finalmente al usuario. Con la información pública disponible no puede afirmarse que esto esté ocurriendo, pero es el tipo de problema operativo que compradores y publishers querrán descartar.
El propio material aportado por The Trade Desk al equipo de WebKit añade otro ingrediente. El informe incluye una sesión de navegación no privada en Yahoo.com en la que las solicitudes de The Trade Desk aparecen bloqueadas mientras que las vinculadas a ad.doubleclick.net, de Google, siguen procesándose. Eso no prueba que Apple esté favoreciendo deliberadamente a Google, y sería irresponsable presentar el caso así, pero sí muestra que la regla está produciendo resultados diferentes entre dos grandes proveedores de infraestructura publicitaria dentro de la misma página. Para un sector que lleva años discutiendo sobre interoperabilidad y condiciones equitativas de acceso al open web, no es precisamente un detalle menor. También conviene separar el problema de identidad del problema de entrega. Apple lleva años reduciendo la capacidad de hacer tracking en Safari y muchas estrategias programáticas ya asumen que este navegador es un entorno distinto de Chrome. Que UID2, ID5 o LiveRamp encuentren nuevas restricciones encaja dentro de esa historia. Que una restricción diseñada alrededor de tracking alcance el dominio mediante el que un DSP solicita y sirve anuncios es otra cosa: ya no estamos hablando simplemente de perder una señal para reconocer al usuario o de comprar una impresión con menos información. Estamos hablando de no poder acceder a esa impresión desde ese proveedor. Y ahí aparece la parte que probablemente sobreviva incluso si Apple corrige mañana el error. The Trade Desk se ha posicionado durante años como una de las grandes infraestructuras independientes del open internet. Precisamente por eso depende de que ese internet sea accesible a través de capas que no controla. Safari pertenece a Apple, el sistema operativo pertenece a Apple y las reglas de WebKit las decide Apple. La industria puede desarrollar identificadores abiertos, mecanismos interoperables y DSPs independientes; después todos ellos tienen que atravesar una puerta cuyo propietario puede modificar las condiciones técnicas.
Entre las reacciones que ha provocado el caso también ha aparecido inevitablemente la pregunta de cuánto falta para que Apple desarrolle un negocio publicitario mayor alrededor de sus propios activos. El incidente actual no permite establecer ninguna relación entre ambas cosas. Apple no ha explicado públicamente que el bloqueo de adsrvr.org responda a intereses comerciales y el ticket está siendo tratado como un problema técnico de WebKit, pero la sospecha ilustra bien la desconfianza que se genera cada vez que una compañía que controla infraestructura crítica establece reglas que afectan al negocio publicitario de terceros. Por ahora, lo más prudente es no convertir unas semanas de bloqueo en una nueva crisis estructural de The Trade Desk. No existe una estimación pública fiable del impacto en ingresos, el problema afecta al parque de dispositivos que ya ha actualizado a iOS 27 y Apple continúa investigándolo y tampoco parece que el mercado haya interpretado inicialmente el episodio como una amenaza existencial para la compañía… lo relevante está en otro sitio.
Puede que Apple retire adsrvr.org de la lista, The Trade Desk recupere ese inventario y dentro de un mes casi nadie recuerde el ticket 324771 de WebKit, pero durante unos días ha ocurrido algo bastante revelador: uno de los mayores DSP’s independientes del mundo ha descubierto que una pequeña regla dentro de un navegador puede impedirle servir publicidad.
Puntos clave:
Apple ha incluido adsrvr.org, uno de los principales dominios publicitarios de The Trade Desk, en su lista de dominios bloqueados.
El bloqueo podría impedir a The Trade Desk acceder al inventario publicitario de Safari en dispositivos con iOS27.
WebKit lleva más de una semana analizando el caso, mientras sigue sin estar claro si Apple revertirá el bloqueo.
Este resumen lo ha creado una herramienta de IA basándose en el texto del artículo, y ha sido chequeado por un editor de PROGRAMMATIC SPAIN.
