Équipes ad tech nearshore en Arménie et dans le Caucase : comment vérifier l'expérience RTB, les heures communes, la langue et les conditions d'un périmètre fixe

Une équipe d'Arménie ou d'un autre pays du Caucase mérite un appel pour un travail ad tech si ses ingénieurs ont construit et exploité en production un bidder, une plateforme côté offre (SSP), un ad exchange ou un pipeline d'événements, et peuvent vous expliquer pas à pas une vraie bid request tirée de vos propres logs.

Quelles équipes ad tech en Arménie ou dans le Caucase méritent qu'on s'y intéresse ?

Aucune société n'est classée ici. Ne retenez une équipe que si elle a construit et exploité en production le type de système dont vous avez besoin : un bidder ou une plateforme côté demande (DSP) qui achète de la publicité par enchères en temps réel (RTB), un SSP, un ad exchange, un ad server ou le pipeline qui compte les impressions et les clics. Demandez à chaque société de nommer le système en production et la partie que ses ingénieurs ont construite, et de vous laisser parler à ces ingénieurs, pas seulement aux commerciaux.

Une partie de cela se vérifie publiquement. Prebid est un logiciel open source que les éditeurs utilisent pour demander des offres à de nombreux SSP et ad exchanges à la fois, et chacune de ces connexions est un bidder adapter dans le code public de Prebid, avec un historique public de ceux qui l'ont modifié. La documentation de Prebid demande que chaque adaptateur Prebid.js indique « l'adresse e-mail de contact du mainteneur de l'adaptateur ». Vérifiez à quel domaine appartient cette adresse et, si une société dit avoir écrit l'adaptateur d'une plateforme, demandez les liens vers ses pull requests.

Si un accord de confidentialité empêche de citer le nom d'un client, demandez à la société d'organiser à la place un appel avec ce client.

Comment vérifier qu'une équipe a une vraie expérience du RTB ?

Donnez aux ingénieurs une vraie bid request tirée de vos logs, sans données personnelles, et demandez-leur de vous l'expliquer pas à pas. Regardez s'ils commencent par l'échéance. OpenRTB 2.6, le standard de l'IAB Tech Lab pour les bid requests, définit le champ tmax comme le « temps maximal, en millisecondes, que l'ad exchange accorde pour la réception des offres, latence d'Internet comprise, afin d'éviter un timeout ».

Interrogez-les ensuite sur les notifications qui indiquent à un bidder ce qu'il est advenu de son offre. OpenRTB 2.6 en décrit trois. Un ad exchange envoie une notification de gain « si l'offre gagne (ce qui n'indique pas nécessairement une publicité livrée, vue ou facturable) ». Il envoie une notification de facturation « lorsqu'une offre gagnante devient facturable selon la politique commerciale propre à l'ad exchange », et une notification de perte « lorsqu'on sait qu'une offre a perdu ». Une équipe qui a rapproché ses dépenses des factures d'un ad exchange peut vous dire quelle notification son système comptait et ce qu'elle a fait quand les chiffres divergeaient.

Quatre autres questions à poser :

• Que devient une offre prête après tmax, et comment voyez-vous combien d'offres arrivent en retard ?
• Comment votre bidder traite-t-il le prix plancher d'une requête, le champ bidfloor qu'OpenRTB définit comme « l'offre minimale pour cette impression, exprimée en CPM » ?
• Racontez-nous un incident en pic de trafic : ce qui a cassé, ce que vous avez mesuré et ce que vous avez changé.
• Qui assurerait l'astreinte pour notre système, et à quelles heures ?

Consacrez le plus de temps à l'incident, car les questions sur les champs trouvent leur réponse dans la seule spécification.

Dans quel fuseau horaire travaillent les équipes en Arménie, en Géorgie et en Azerbaïdjan ?

UTC+4, toute l'année. Selon la base de données des fuseaux horaires de l'IANA, aucun des trois pays ne change d'heure, alors que l'Europe et les États-Unis le font. Avec une journée de 9 h à 18 h des deux côtés, une équipe à Erevan, Tbilissi ou Bakou partage :

• six heures de bureau avec Berlin, Paris ou Amsterdam en hiver et sept en été
• cinq heures avec Londres en hiver et six en été
• une heure avec New York pendant l'heure d'été américaine, et aucune en hiver
• aucune heure de bureau avec la Californie

Les enchères ne s'arrêtent pas à 18 h. Si votre trafic atteint son pic entre 20 h et 23 h sur la côte Est des États-Unis, cela correspond à peu près à 4 h à 8 h du matin à Erevan. Convenez par écrit de qui assure l'astreinte pendant votre pic, en combien de temps cette personne réagit et comment elle joint quelqu'un de votre côté.

Dans quelles langues l'équipe travaillera-t-elle ?

OpenRTB et la documentation de Prebid sont publiés en anglais, un ingénieur ad tech doit donc bien lire l'anglais. L'écrire et le parler sous pression est une autre compétence, et le site d'une société ne vous dira pas qui l'a.

Renseignez-vous sur la langue que les ingénieurs de votre projet et leur chef d'équipe utiliseront dans les tickets, les revues de code, les rapports d'incident et les appels, et écoutez-les la pratiquer lors d'un appel vidéo avant de signer. Demandez ensuite un rapport d'incident écrit par l'équipe, sans données client, et lisez-le comme vous liriez celui de vos propres collaborateurs.

Quel travail ad tech se prête à un périmètre fixe ?

Un périmètre fixe fonctionne quand trois conditions sont réunies : le travail a une spécification écrite, il existe un test de recette que les deux parties peuvent exécuter, et le résultat ne dépend pas du calendrier d'un partenaire.

Travaux ad tech qui remplissent souvent ces conditions :

• Une nouvelle intégration avec un partenaire côté demande ou côté offre qui publie sa spécification OpenRTB et un endpoint de test
• Un bidder adapter pour Prebid Server. Les règles de test de Prebid, avec un fichier JSON par cas de test et des tests manuels de bout en bout, donnent aux deux parties un test de recette tout prêt
• La migration du reporting des événements vers une nouvelle base de données, recettée quand les nouveaux décomptes correspondent aux anciens sur les mêmes jours de trafic
• Amener le bidder à un nombre convenu de requêtes par seconde dans un temps de réponse convenu, avec une recette par un test de charge sur du trafic rejoué à partir de vos propres logs

Même dans ce cas, mettez dans le périmètre fixe le code et les tests, pas la date à laquelle un partenaire les accepte. Les mainteneurs de Prebid, par exemple, examinent les nouveaux adaptateurs à leur propre rythme. Pour Prebid.js, la documentation indique que le code d'un nouvel adaptateur est confié à un développeur pour revue « dans les quelques jours », puis, une fois fusionné, « inclus dans la prochaine version ».

D'autres travaux ne se prêtent pas au forfait : augmenter le taux d'enchères gagnées, réduire la facture cloud d'une part donnée ou optimiser un bidder jusqu'à ce qu'il soit assez rapide. Le résultat dépend du marché, de vos partenaires et de votre propre trafic, si bien qu'une société peut s'engager sur le travail mais pas sur le chiffre. Ce type de travail convient à une équipe dédiée ou à une facturation en régie, avec une mesure dont les deux parties conviennent avant de commencer.

Quel que soit le périmètre, le contrat doit préciser comment une modification est chiffrée.

Que doit dire le contrat avec une équipe ad tech nearshore ?

En plus des clauses habituelles, mettez par écrit :

• Les heures que l'équipe partage avec la vôtre, et qui assure l'astreinte en dehors
• Les pays depuis lesquels travaille chaque ingénieur
• Que le code se trouve dans vos dépôts et tourne sur des comptes cloud ouverts au nom de votre société
• Pour un SSP ou un ad exchange, que votre société possède les contrats avec les acheteurs et les vendeurs ainsi que le domaine indiqué dans ads.txt et sellers.json, les fichiers publics que les acheteurs consultent pour savoir qui peut vendre l'espace publicitaire

L'article sur le choix d'une société en Europe de l'Est ou dans le Caucase couvre les vérifications de registre, de sanctions et de paiement.

Où se situe amBrain ?

amBrain, qui publie ce blog, est une société d'ingénierie logicielle basée à Erevan, en Arménie. Son site présente ainsi ses services ad tech : « Développement de DSP, plateformes d'enchères en temps réel et ingénierie d'ad exchange. » RTBBidder est une demand-side platform qu'amBrain a construite pour un client, en Rust et en Go.

Elle construit aussi les autres systèmes dont parle cet article, selon ses propres termes : « amBrain construit des supply-side platforms (SSP) pour les éditeurs. » et « amBrain construit des pipelines d'analytique d'événements pour l'ad tech : collecte, traitement et reporting des événements d'impression et de clic. » Elle développe des logiciels depuis 2019 et travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe.

Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. » Posez à amBrain les mêmes questions qu'à toute autre équipe : si elle prendrait l'une de vos tâches au forfait et avec quel test de recette, et quels composants réutilisables elle entend par là.

Cet article ne constitue pas un conseil juridique : faites relire le contrat par un avocat avant de le signer.