Anuncios de banner en la aplicación iOS

Hoy estamos abriendo una serie de artículos sobre lo que generalmente no se habla en conferencias y reuniones técnicas. Esta y las publicaciones posteriores le dirán cómo funciona el mecanismo de monetización en la aplicación de entretenimiento iFunny iOS popular en los Estados Unidos, que estamos desarrollando.

La publicidad es una de las principales formas de monetizar aplicaciones gratuitas. Pero ahora, ¿qué opciones había en 2011 cuando apareció iFunny? El servicio se creó originalmente como un negocio fuerte y sostenible, por lo que desde el primer día la compañía decidió no coquetear con los usuarios y no participar en juegos con capitalización condicional.

En ese momento, la opción principal para la monetización era crear una versión gratuita y simplificada del servicio, y luego tratar de vender la funcionalidad principal. El consumidor era joven, inexperto y no estaba listo para desprenderse de cantidades superiores a un dólar.

Las matemáticas simples mostraron que con una conversión del 10%, obtener un ARPU de más de 10 centavos es una tarea casi imposible.

Luego tuve que pensar en cómo más puedes monetizar el producto. El modelo publicitario ya ha funcionado muy bien en la web, y se podría suponer que pronto también florecerá en los teléfonos.
En general, el comienzo del modelo de monetización de publicidad móvil puede considerarse la aparición de AdWhirl, un servicio que le permitió integrar el SDK de las redes publicitarias y rotarlas. Su apariencia nos permitió elevar FillRate a un promedio del 50% en el mercado y hacer que los ingresos del modelo publicitario sean al menos comparables a las ventas de un dólar. El principio mismo de la implementación de todas las posibles fuentes de demanda y la organización de la competencia entre ellas se ha convertido en el principal impulsor del crecimiento en la industria publicitaria y continúa siendo explotado hasta nuestros días.

Pero cuanto más complejo es el sistema, menos estable se vuelve, lo que es absolutamente inaceptable para grandes servicios del nivel iFunny. Comenzando a moverse en esta dirección en 2011, la compañía creó uno de los mecanismos más efectivos para trabajar con pancartas móviles y publicidad nativa y aumentó sus ingresos por usuario en 40 veces, lo que permitió desarrollar no solo proyectos internos, sino también invertir en otras compañías.

MoPub y compañía

Desde 2012, nos hemos mudado de AdWhirl a MoPub.

MoPub es una plataforma de publicidad móvil con la capacidad de agregar sus propios módulos, que incluye varias herramientas excelentes:

• Mercado de MoPub: intercambio publicitario propio;
• mediador de redes publicitarias para trabajar con redes externas;
• Un mecanismo de pedido que le permite colocar pancartas de forma independiente en su propia aplicación y personalizar sus pantallas.

Las principales ventajas de MoPub:

• capaz de trabajar con la mayoría de las redes publicitarias;
• mecanismo claro para conectar nuevas redes de terceros;
• código abierto
• una gran cantidad de configuraciones y objetivos básicos;
• Una gran comunidad alrededor de la red, incluso hay una conferencia propia.

MoPub también tiene desventajas:

• No se aceptan solicitudes de grupo en GitHub y no hay ninguna reacción a ellas;
• El panel de control es muy complejo, y para el desarrollador, mientras se depura, lleva algún tiempo profundizar en su estructura.

El poder de la verdad

Como dijo el héroe de una película rusa: "La fuerza es la verdad". En esta parte, hablaré sobre las dificultades que nosotros, como desarrolladores de aplicaciones, tuvimos que enfrentar después del primer millón de descargas de iFunny, el crecimiento de la audiencia y el tráfico publicitario de más de 100 socios.

Contenido

El mercado publicitario es una "casta" muy cerrada de empresas tecnológicas, pero al mismo tiempo, los agregadores tienen una gran red de socios: desde grandes empresas que trabajan con millones de presupuestos hasta pequeñas empresas adaptadas a públicos específicos.

Esta cercanía y fragmentación de los socios, a pesar de la moderación previa del banner y las reglas bastante estrictas sobre el contenido publicitario, no permite que los vendedores de publicidad más honestos publiquen creatividades que estén prohibidas o estropeen la experiencia del usuario en la aplicación.

Existen varias categorías principales de contenido "obsceno" en los banners publicitarios:

• contenido porno. Recientemente, parece cada vez menos, pero sin embargo tiene lugar para ser. No podemos publicar este contenido en el artículo, por lo que la imagen no estará aquí
• alertas del sistema en pancartas, se puede ver un ejemplo en uno de los usuarios twitter.com/IfunnyStates/status/1029393804749668352
• contenido con sonido. Las redes publicitarias y las animaciones no prohíben los sonidos, pero si el sonido se reproduce sin interactuar con la interfaz, los usuarios lo perciben como un error de la aplicación y afecta negativamente la experiencia del usuario.
• Llama la atención. Un buen banner debería atraer la atención del usuario, pero esto no siempre sucede de manera honesta: a veces los videos parpadeantes caen en los banners. Otra forma deshonesta de hacer que el usuario toque el banner es simular la interfaz de la aplicación, por ejemplo, así:
  
  

Por cierto, en Rusia, un toque ordinario en este banner puede emitir una suscripción paga para algunos operadores móviles, y ni siquiera lo sabrá hasta que vea los detalles. Esta es también una forma deshonesta de trabajar con publicidad, pero los operadores en los Estados Unidos no tienen esta oportunidad.

Clics automáticos

Como muestra mi experiencia, este es un caso extremadamente negativo para los usuarios. Usando las capacidades de JavaScript, WKWebView o UIWebView, así como los agujeros dentro de la implementación de las bibliotecas publicitarias, puede crear anuncios que abrirán el contenido del banner y sacarán al usuario de la aplicación.

Para repetir este problema usando el ejemplo de MoPub, simplemente agregue el código javascript del siguiente contenido al banner:

<a href="https://ifunny.co" id="testbutton">test</a> <script>document.getElementById('testbutton').click(); </script> 

Esto funcionó durante mucho tiempo en muchas versiones de MoPub, hasta la versión 4.13.

Al explorar la implementación de MoPub, fue posible generar enlaces más complejos que permitirían no solo abrir anuncios en pantalla completa, sino también enviar al usuario a la AppStore a una aplicación específica y ni siquiera tener en cuenta la visualización del banner.

Por cierto, en las notas de la versión 4.13.0 del SDK de MoPub para iOS no hay información sobre esta solución, ya que era un agujero bastante serio en el SDK, y los socios deshonestos de MoPub lo explotaron de manera bastante activa. Como muestran los registros, que analizaré más adelante, todos los días tenía que bloquear hasta 2 millones de intentos para abrir el banner sin la interacción del usuario con él.

En el caso de MoPub, resultó ser fácil de encontrar y repetir el problema, pero otras redes con las que trabaja iFunny tienen un código cerrado, y tienes que lidiar con los clics automáticos emergentes bloqueando pancartas o incluso desconectando las redes por un tiempo.
iFunny trabaja en estrecha colaboración con todos los socios publicitarios y les informa de dichos banners. Dado que el público joven de iFunny es interesante para los anunciantes, los socios están dispuestos a conocerlos y eliminar dicha publicidad de la rotación.

Choque

Chocar siempre es malo. Peor aún, cuando suceden debido a una dependencia con fuente cerrada, y puede influir en ellos solo indirectamente. A lo largo de los años de trabajo con publicidad en iFunnu, se han identificado varios tipos de accidentes, que se pueden dividir en varios grupos.

• Sistema

Estos incluyen excepciones en la biblioteca de red, WKWebView (UIWebView), OpenGL.
Es muy difícil afectar directamente este tipo de bloqueos, pero aún fue posible afectar algunos de ellos, ya que había estudiado previamente el funcionamiento del componente WebView con WebGL.

Así es como se ve el stackrace de tales accidentes:

1 libGPUSupportMercury.dylib gpus_ReturnNotPermittedKillClient + 12
2 AGXGLDriver gldUpdateDispatch + 7132
3 libGPUSupportMercury.dylib gpusSubmitDataBuffers + 172
4 AGXGLDriver gldUpdateDispatch + 12700
5 WebCore WebCore::GraphicsContext3D::reshape(int, int) + 524
6 WebCore WebCore::WebGLRenderingContextBase::initializeNewContext() + 712
7 WebCore WebCore::WebGLRenderingContextBase::WebGLRenderingContextBase(WebCore::HTMLCanvasElement*, WTF::RefPtr<WebCore::GraphicsContext3D>&&, WebCore::GraphicsContext3D::Attributes) + 512
8 WebCore WebCore::WebGLRenderingContext::WebGLRenderingContext(WebCore::HTMLCanvasElement*, WTF::PassRefPtr<WebCore::GraphicsContext3D>, WebCore::GraphicsContext3D::Attributes) + 36
9 WebCore WebCore::WebGLRenderingContextBase::create(WebCore::HTMLCanvasElement*, WebCore::WebGLContextAttributes*, WTF::String const&) + 1272
10 WebCore WebCore::HTMLCanvasElement::getContext(WTF::String const&, WebCore::CanvasContextAttributes*) + 520
11 WebCore WebCore::JSHTMLCanvasElement::getContext(JSC::ExecState&) + 212
12 JavaScriptCore llint_entry + 27340
13 JavaScriptCore llint_entry + 24756
14 JavaScriptCore llint_entry + 24756
15 JavaScriptCore llint_entry + 24756
16 JavaScriptCore llint_entry + 25676
17 JavaScriptCore llint_entry + 24756
18 JavaScriptCore llint_entry + 24656
19 JavaScriptCore vmEntryToJavaScript + 260
20 JavaScriptCore JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 164
21 JavaScriptCore JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 348
22 JavaScriptCore JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&) + 160
23 WebCore WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) + 980
24 WebCore WebCore::EventTarget::fireEventListeners(WebCore::Event&, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1ul, WTF::CrashOnOverflow, 16ul>&) + 616
25 WebCore WebCore::EventTarget::fireEventListeners(WebCore::Event&) + 324
26 WebCore WebCore::EventContext::handleLocalEvents(WebCore::Event&) const + 108
27 WebCore WebCore::EventDispatcher::dispatchEvent(WebCore::Node*, WebCore::Event&) + 876
28 WebCore non-virtual thunk to WebCore::HTMLScriptElement::dispatchLoadEvent() + 80
29 WebCore WebCore::ScriptElement::execute(WebCore::CachedScript*) + 360
30 WebCore WebCore::ScriptRunner::timerFired() + 456
31 WebCore WebCore::ThreadTimers::sharedTimerFiredInternal() + 144
32 WebCore WebCore::timerFired(__CFRunLoopTimer*, void*) + 24
33 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 24
34 CoreFoundation __CFRunLoopDoTimer + 868
35 CoreFoundation __CFRunLoopDoTimers + 240
36 CoreFoundation __CFRunLoopRun + 1568
37 CoreFoundation CFRunLoopRunSpecific + 440
38 WebCore RunWebThread(void*) + 452
39 libsystem_pthread.dylib _pthread_body + 236
40 libsystem_pthread.dylib _pthread_start + 280
41 libsystem_pthread.dylib thread_start + 0

Además, se producen exclusivamente cuando se dejan en segundo plano. Esto se debe al hecho de que el motor OpenGL no debería funcionar cuando la aplicación está en segundo plano.

La solución aquí resultó ser bastante simple:

Al salir en segundo plano, debe tomar una captura de pantalla del banner.

Elimine la Vista publicitaria de la pantalla para que el componente WebView deje de usar OpenGL.
Cuando salga del fondo, devuelva todo como estaba.

En el código Objective-C, se ve así:

 - (void)onWillResignActive { if (self.adView.superview) { UIGraphicsBeginImageContext(self.adView.bounds.size); [self.adView.layer renderInContext:UIGraphicsGetCurrentContext()]; UIImage *adViewScreenShot = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); adViewThumbView = [[UIImageView alloc] initWithImage:adViewScreenShot]; adViewThumbView.backgroundColor = [UIColor clearColor]; adViewThumbView.frame = self.adView.frame; NSInteger adIndex = [self.adView.superview.subviews indexOfObject:self.adView]; [self.adView.superview insertSubview:adViewThumbView atIndex:adIndex]; [self.adView removeFromSuperview]; } } - (void)onDidBecomeActive { if (self.adView && adViewThumbView) { NSInteger adIndex = [adViewThumbView.superview.subviews indexOfObject:adViewThumbView]; [adViewThumbView.superview insertSubview:self.adView atIndex:adIndex]; [adViewThumbView removeFromSuperview]; adViewThumbView = nil; } } 

• Integración

Estos son problemas que ocurren en la unión de iFunny, Mopub y el proveedor de publicidad.
Como regla, surgen después de actualizar la biblioteca del proveedor y debido a nuevas formas de interactuar con ellos.

El último caso fue en junio de este año, después de la próxima actualización de una de las bibliotecas utilizadas. Una nueva forma de inicializar la biblioteca sugiere usar singleton para configurar la red.

Volviéndolo dos veces, como sucedió en la implementación, periódicamente causaba un friso del hilo principal, por lo que tuve que ajustar la inicialización en dispatch_once.

El departamento de control de calidad de iFunny puede probar bien las bibliotecas publicitarias, por lo que este problema se encontró durante la prueba de la actualización.

• Inesperado

Este tipo de bloqueos no se puede controlar en absoluto, ya que ocurre sin ningún cambio en el cliente.

Están asociados con la actualización del backend de los socios y la falta de compatibilidad con versiones anteriores. Tales bloqueos a menudo ocurren en grandes proveedores de publicidad, pero se solucionan rápidamente, ya que afectan una gran cantidad de aplicaciones al mismo tiempo.

Hubo casos en los que iFunny sin accidentes por día cayó del 99.8% estándar al 80%, y la cantidad de comentarios enojados en la historia fue de diez.

Rendimiento

La publicidad de banner, por regla general, utiliza componentes de WebView para mostrar publicidad, por lo que cada banner que se muestra es una inicialización de un nuevo WebView con todas sus dependencias.

Además, algunos socios también usan WebView para comunicarse con su propio backend, ya que la publicidad de banner en dispositivos móviles es un descendiente de la publicidad en la web.

Sucede que después de la actualización hay pérdidas de memoria dentro de la nueva biblioteca. Después de la aparición de la herramienta Memory Graph en Xcode, se hizo mucho más fácil encontrar fugas en bibliotecas de terceros, por lo que ahora los socios pueden ser informados rápidamente sobre ellas.

A continuación se muestra el GIF de iFunny inactivo cuando no hay publicidad para el usuario:

Soluciones

Pero a pesar de todos los problemas descritos anteriormente, iFunny es estable y todos los días sonríe entre millones de usuarios.

A lo largo de los años de trabajo activo con la publicidad, el equipo de desarrollo tiene varias herramientas que pueden monitorear con éxito los problemas de publicidad y responder a tiempo.

Sistema de registro

Ahora el sistema de registro de excepciones en iFunny se ha extendido a toda la aplicación: para esto, utilizamos nuestro propio backend con una base en ClickHouse y lo mostramos en Grafana.

Pero la primera tarea para trabajar con registros en la aplicación fue precisamente el registro de situaciones excepcionales en publicidad.

Hay varios componentes relacionados para determinar si una llamada se reenvía a iFunny. Te contaré más sobre cada uno de ellos.

IFAdView

Este es el descendiente de la clase MPAdView (es responsable de mostrar anuncios en MoPub).

El método hitTest: withEvent se reemplaza en esta clase:

 - (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event { UIView *hitView = [super hitTest:point withEvent:event]; if (hitView) { [[IFAdsExceptionManager instance] triggerTouchView]; } return hitView; } 

Por lo tanto, activamos el hecho de que el usuario interactuó con el anuncio.

IFURLProtocol

Heredamos de NSURLProtocol y describimos el método:

 + (BOOL)canInitWithRequest:(NSURLRequest *)request { __weak NSString *wRequestURL = request.URL.absoluteString; dispatch_async(dispatch_get_main_queue(), ^{ if (wRequestURL == nil) return; if ([wRequestURL hasPrefix:@"itms-appss://itunes.apple.com"] || [wRequestURL hasPrefix:@"itms-apps://itunes.apple.com"] || [wRequestURL hasPrefix:@"itmss://itunes.apple.com"] || [wRequestURL hasPrefix:@"http://itunes.apple.com"] || [wRequestURL hasPrefix:@"https://itunes.apple.com"]) { [[IFAdsExceptionManager instance] adsTriggerItunesURL:wRequestURL]; } }); return NO; } 

Este es un desencadenante para abrir la AppStore desde la aplicación, enumeramos todas las URL disponibles para esto.

IFAdsExceptionManager

Una clase que recopila desencadenantes y genera un registro de excepción en el registro.

Para dejar en claro qué tipo de disparadores son, describiré cada método de la interfaz de esta clase.

 - (void)triggerTouchView;       . <source lang="objectivec">- (void)triggerItunesURL:(NSString *)itunesURL; 

Un disparador que determina si se produce una redirección en iTunes.

 - (void)triggerResignActive; 

Un disparador para determinar la pérdida de actividad de una aplicación. Compara los dos disparadores anteriores.

 - (void)resetTriggers; 

Restablecer disparadores. Lo llamamos al dejar el fondo o cuando abrimos la AppStore nosotros mismos, por ejemplo, cuando enviamos al usuario a calificar en versiones anteriores de iOS.

 @property (nonatomic, strong) FNAdConfigurationInfo *lastRequestedConfiguration; @property (nonatomic, strong) FNAdConfigurationInfo *lastLoadedConfiguration; @property (nonatomic, strong) FNAdConfigurationInfo *lastFailedConfiguration; 

Propiedades para registrar los últimos anuncios solicitados y descargados con éxito o sin éxito. Necesario para formar un mensaje en el registro.

Se puede ver que el algoritmo resultó ser bastante simple, pero efectivo. Nos permite rastrear no solo los descubrimientos automáticos de MoPub, sino también de otras redes.

Recientemente, los anuncios con apertura automática a menudo abren SKStoreProductViewController, por lo que ahora estamos trabajando en la definición de apertura automática de este controlador. El algoritmo para definir esta excepción será un poco más complicado, pero Objective-C Runtime nos ayudará aquí.

Stand local

Basado en el sistema de registro, iFunny también comenzó a desarrollar un stand local para recibir y depurar anuncios que los usuarios ven en tiempo real.

El stand consta de:

• agente de construcción
• dispositivos
• conjunto de pruebas para cada proveedor

Una de las soluciones interesantes que se utiliza en el stand es IDFA a partir de las quejas de los usuarios por publicidad real.

Desde aproximadamente 2016, dejamos de recibir anuncios reales dirigidos a los EE. UU. Utilizando solo VPN, por lo que tenemos que reemplazar los dispositivos IDFA con IDFA para usuarios reales.

Esto se hace con bastante facilidad utilizando Objective-C Runtime y swizzling.
Debe reemplazar el método advertisingIdentifier de la clase ASIdentifierManager.

Aquí lo hacemos a través de la categoría:

 @interface ASIdentifierManager (IDFARewrite) @end @implementation ASIdentifierManager (IDFARewrite) + (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ if (AdsMonitorTests.customIDFA != nil) { [self swizzleIDFA]; } }); } + (void)swizzleIDFA { Class class = [self class]; SEL originalSelector = @selector(advertisingIdentifier); SEL swizzledSelector = @selector(swizzled_advertisingIdentifier); Method originalMethod = class_getInstanceMethod(class, originalSelector); Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector); BOOL didAddMethod = class_addMethod(class, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod)); if (didAddMethod) { class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod)); } else { method_exchangeImplementations(originalMethod, swizzledMethod); } } #pragma mark - Method Swizzling - (NSUUID *)swizzled_advertisingIdentifier { NSUUID *result = AdsMonitorTests.customIDFA; return result; } @end 

El método descrito en el artículo se utiliza para transferir el IDFA de usuario a la compilación desde el agente de compilación.

En conclusión, quiero decir que la publicidad de banner funciona muy bien en los Estados Unidos, y durante siete años de su uso activo como método principal de monetización, iFunny ha aprendido a trabajar bien con ella.

Pero a pesar del hecho de que las pancartas aportan el 75% de los ingresos de la compañía, se está trabajando en métodos alternativos de monetización y ya se ha ganado algo de experiencia en publicidad nativa y el uso de subastas de publicidad en el mercado estadounidense.

En general, hay algo que contar.