Equipos nearshore de ad tech en Armenia y el Cáucaso: cómo comprobar la experiencia en RTB, las horas compartidas, el idioma y las condiciones de alcance cerrado

Un equipo de Armenia o de otro país del Cáucaso merece una llamada para trabajo de ad tech si sus ingenieros han construido y operado en producción un bidder, una plataforma del lado de la oferta (SSP), un ad exchange o un pipeline de eventos, y pueden explicarte paso a paso una solicitud de puja real de tus propios logs.

¿Qué equipos de ad tech de Armenia o el Cáucaso merece la pena tener en cuenta?

Aquí no hay ningún ranking de empresas. Incluye a un equipo en tu lista corta solo si ha construido y operado en producción el tipo de sistema que necesitas: un bidder o una plataforma del lado de la demanda (DSP) que compra anuncios mediante puja en tiempo real (RTB), una SSP, un ad exchange, un ad server o el pipeline que cuenta impresiones y clics. Pide a cada empresa que nombre el sistema en producción y la parte que construyeron sus ingenieros, y que te deje hablar con esos ingenieros, no solo con ventas.

Parte de esto se puede comprobar públicamente. Prebid es un software de código abierto que los editores usan para pedir pujas a muchas SSP y exchanges a la vez, y cada una de esas conexiones es un bidder adapter en el código público de Prebid, con un historial público de quién lo modificó. La documentación de Prebid pide que cada adaptador de Prebid.js indique «el correo electrónico de contacto del mantenedor del adaptador». Comprueba de qué dominio es ese correo y, si una empresa dice que escribió el adaptador de una plataforma, pide los enlaces a sus pull requests.

Si un acuerdo de confidencialidad impide revelar el nombre de un cliente, pide a la empresa que organice una llamada con ese cliente.

¿Cómo comprobamos que un equipo tiene experiencia real en RTB?

Dales a los ingenieros una solicitud de puja real de tus logs, sin datos personales, y pídeles que te la expliquen paso a paso. Fíjate en si empiezan por el tiempo límite. OpenRTB 2.6, el estándar de IAB Tech Lab para las solicitudes de puja, define el campo tmax como el «tiempo máximo en milisegundos que el exchange permite para recibir las pujas, incluida la latencia de internet, para evitar el timeout».

Después pregunta por las notificaciones que le dicen a un bidder qué pasó con su puja. OpenRTB 2.6 describe tres. Un exchange envía una notificación de victoria «si la puja gana (lo que no indica necesariamente que el anuncio se haya entregado, visto o sea facturable)». Envía una notificación de facturación «cuando una puja ganadora pasa a ser facturable según la política comercial propia del exchange», y una notificación de pérdida «cuando se sabe que una puja ha perdido». Un equipo que ha cuadrado su gasto con las facturas de un exchange puede decirte qué notificación contaba su sistema y qué hizo cuando las cifras no coincidían.

Cuatro preguntas más:

• ¿Qué pasa con una puja que está lista después de tmax y cómo ven cuántas pujas llegan tarde?
• ¿Cómo trata su bidder el precio mínimo de una solicitud, el campo bidfloor que OpenRTB define como la «puja mínima para esta impresión expresada en CPM»?
• Cuéntennos un incidente en un pico de tráfico: qué se rompió, qué midieron y qué cambiaron.
• ¿Quién estaría de guardia para nuestro sistema y en qué horario?

Dedica más tiempo al incidente, porque las preguntas sobre los campos se pueden responder solo con la especificación.

¿En qué zona horaria trabajan los equipos de Armenia, Georgia y Azerbaiyán?

UTC+4, todo el año. Según la base de datos de zonas horarias de la IANA, ninguno de los tres países cambia la hora, mientras que Europa y EE. UU. sí. Con una jornada de 9 a 18 en ambos lados, un equipo en Ereván, Tiflis o Bakú comparte:

• seis horas de oficina con Berlín, París o Ámsterdam en invierno y siete en verano
• cinco horas con Londres en invierno y seis en verano
• una hora con Nueva York mientras EE. UU. está en horario de verano, y ninguna en invierno
• ninguna hora de oficina con California

Las subastas no se paran a las seis de la tarde. Si tu tráfico tiene su pico entre las 20:00 y las 23:00 en la costa este de EE. UU., en Ereván es aproximadamente entre las 4 y las 8 de la mañana. Acuerda por escrito quién está de guardia en tu pico, en cuánto tiempo responde y cómo contacta con alguien de tu lado.

¿En qué idiomas trabajará el equipo?

OpenRTB y la documentación de Prebid se publican en inglés, así que un ingeniero de ad tech tiene que leer bien en inglés. Escribirlo y hablarlo bajo presión es otra habilidad, y la web de una empresa no te dirá quién la tiene.

Averigua qué idioma usarán los ingenieros de tu proyecto y su jefe de equipo en los tickets, las revisiones de código, los informes de incidentes y las llamadas, y escúchalos usarlo en una videollamada antes de firmar. Después pide un informe escrito de un incidente que haya redactado el equipo, sin datos del cliente, y léelo como leerías uno de tu propio personal.

¿Qué trabajo de ad tech encaja en un alcance cerrado?

Un alcance cerrado funciona cuando se cumplen tres cosas: el trabajo tiene una especificación escrita, hay una prueba de aceptación que ambas partes pueden ejecutar y el resultado no depende del calendario de un socio.

Trabajos de ad tech que a menudo cumplen esas condiciones:

• Una nueva integración con un socio de demanda o de oferta que publica su especificación OpenRTB y un endpoint de pruebas
• Un bidder adapter de Prebid Server. Las reglas de prueba de Prebid, con un archivo JSON por cada caso de prueba y pruebas manuales de extremo a extremo, dan a ambas partes una prueba de aceptación ya hecha
• Trasladar los informes de eventos a una nueva base de datos, con la aceptación cuando los nuevos recuentos coinciden con los antiguos en los mismos días de tráfico
• Llevar el bidder a un número acordado de solicitudes por segundo dentro de un tiempo de respuesta acordado, con la aceptación mediante una prueba de carga con tráfico reproducido a partir de tus propios logs

Aun así, mete en el alcance cerrado el código y las pruebas, no la fecha en que un socio los acepte. Los mantenedores de Prebid, por ejemplo, revisan los nuevos adaptadores a su propio ritmo. Para Prebid.js, la documentación dice que el código de un nuevo adaptador se asigna a un desarrollador para su revisión «en unos pocos días» y que, una vez fusionado, se «incluye en la siguiente versión».

Otros trabajos no encajan en un alcance cerrado: subir la tasa de subastas ganadas, reducir la factura de la nube en un porcentaje fijo o ajustar un bidder hasta que sea lo bastante rápido. El resultado depende del mercado, de tus socios y de tu propio tráfico, así que una empresa puede comprometerse con el trabajo, pero no con la cifra. Ese trabajo encaja mejor con un equipo dedicado o con tiempo y materiales, con una medición que ambas partes acuerden antes de empezar.

Sea cual sea el alcance, el contrato debe indicar cómo se valora un cambio.

¿Qué debe decir el contrato con un equipo nearshore de ad tech?

Además de las cláusulas habituales, deja por escrito:

• Las horas que el equipo comparte con el tuyo y quién está de guardia fuera de ellas
• Los países desde los que trabaja cada ingeniero
• Que el código está en tus repositorios y se ejecuta en cuentas en la nube abiertas a nombre de tu empresa
• En una SSP o un exchange, que tu empresa es la dueña de los contratos con compradores y vendedores y del dominio que figura en ads.txt y sellers.json, los archivos públicos que los compradores consultan para saber quién puede vender el espacio publicitario

El artículo sobre cómo elegir una empresa en Europa del Este o el Cáucaso cubre las comprobaciones de registro, sanciones y pagos.

¿Dónde encaja amBrain?

amBrain, que publica este blog, es una empresa de ingeniería de software de Ereván, Armenia. Su web enumera sus servicios de ad tech como «Desarrollo de DSP, plataformas de pujas en tiempo real e ingeniería de ad exchanges.» RTBBidder es una demand-side platform que amBrain construyó para un cliente, en Rust y Go.

También construye los demás sistemas de los que trata este artículo, en sus propias palabras: «amBrain construye supply-side platforms (SSP) para editores» y «amBrain construye pipelines de analítica de eventos para ad tech: recopilación, procesamiento e informes de eventos de impresión y de clic». Desarrolla software desde 2019 y trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo.

Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables». Hazle a amBrain las mismas preguntas que a cualquier otro equipo: si aceptaría alguna de tus tareas con alcance cerrado y con qué prueba de aceptación, y a qué componentes reutilizables se refiere.

Este artículo no es asesoramiento jurídico: haz que un abogado lea el contrato antes de firmarlo.