amBrain
AdTechOct 26, 20267 Min. Lesezeit

Nearshore-Ad-Tech-Teams in Armenien und im Kaukasus: wie Sie RTB-Erfahrung, gemeinsame Stunden, Sprache und Festpreisumfang prüfen

Real-Time BiddingTeams im AuslandZentralasien und KaukasusPartnerprüfung
Bild konnte nicht geladen werden
Inhaltsverzeichnis

Wie Sie prüfen, ob ein Nearshore-Team in Armenien, Georgien oder Aserbaidschan wirklich Real-Time-Bidding-Systeme (RTB) betrieben hat, was UTC+4 für Ihre Arbeitszeiten bedeutet und welche Ad-Tech-Aufgaben zu einem festen Umfang passen.

Ein Team aus Armenien oder einem anderen Land im Kaukasus ist für Ad-Tech-Arbeit einen Call wert, wenn seine Entwickler einen Bidder, eine Supply-Side-Plattform (SSP), eine Ad Exchange oder eine Event-Pipeline gebaut und in Produktion betrieben haben und Ihnen einen echten Bid Request aus Ihren eigenen Logs Schritt für Schritt erklären können.

Die kurze Antwort: Rechnen Sie mit sechs oder sieben gemeinsamen Bürostunden mit Mitteleuropa, fünf oder sechs mit London und höchstens einer mit New York, und vereinbaren Sie deshalb, wer in Ihrer Traffic-Spitze Bereitschaft hat. Hören Sie die Entwickler vor der Unterschrift sprechen. Geben Sie einen festen Umfang nur für Arbeit mit Spezifikation und Abnahmetest, und lassen Sie Ziele wie Gewinnquote oder Cloud-Kosten draußen.

Welche Ad-Tech-Teams in Armenien oder im Kaukasus sind einen Blick wert?

Hier wird keine Firma in eine Rangliste gesetzt. Nehmen Sie ein Team nur dann auf die Shortlist, wenn es die Art System, die Sie brauchen, gebaut und in Produktion betrieben hat: einen Bidder oder eine Demand-Side-Plattform (DSP), die Werbung per Real-Time Bidding (RTB) einkauft, eine SSP, eine Ad Exchange, einen Ad Server oder die Pipeline, die Impressions und Klicks zählt. Bitten Sie jede Firma, das Live-System zu nennen und den Teil, den ihre Entwickler gebaut haben, und Sie mit diesen Entwicklern sprechen zu lassen, nicht nur mit dem Vertrieb.

Manches davon lässt sich öffentlich prüfen. Prebid ist Open-Source-Software, mit der Publisher Gebote bei vielen SSPs und Exchanges gleichzeitig anfragen, und jede dieser Anbindungen ist ein Bidder-Adapter im öffentlichen Code von Prebid, mit einer öffentlichen Historie, wer ihn geändert hat. Die Dokumentation von Prebid verlangt, dass jeder Prebid.js-Adapter „die Kontakt-E-Mail des Maintainers des Adapters“ angibt. Prüfen Sie, zu welcher Domain diese E-Mail gehört, und wenn eine Firma sagt, sie habe den Adapter einer Plattform geschrieben, bitten Sie um die Links zu ihren Pull Requests.

Wenn eine Vertraulichkeitsvereinbarung den Namen eines Kunden schützt, bitten Sie die Firma, stattdessen einen Call mit diesem Kunden zu organisieren.

Wie prüfen wir, ob ein Team echte RTB-Erfahrung hat?

Geben Sie den Entwicklern einen echten Bid Request aus Ihren Logs, ohne personenbezogene Daten, und lassen Sie sich ihn Schritt für Schritt erklären. Achten Sie darauf, ob sie mit der Deadline beginnen. OpenRTB 2.6, der Standard des IAB Tech Lab für Bid Requests, definiert das Feld tmax als die „maximale Zeit in Millisekunden, die die Exchange für den Eingang von Geboten einschließlich der Internetlatenz gewährt, um ein Timeout zu vermeiden“.

Fragen Sie dann nach den Benachrichtigungen, die einem Bidder mitteilen, was mit seinem Gebot geschehen ist. OpenRTB 2.6 beschreibt drei. Eine Exchange sendet eine Gewinnbenachrichtigung, „wenn das Gebot gewinnt (was nicht unbedingt bedeutet, dass die Anzeige ausgeliefert, gesehen oder abrechenbar ist)“. Eine Abrechnungsbenachrichtigung sendet sie, „wenn ein gewinnendes Gebot nach den exchange-spezifischen Geschäftsregeln abrechenbar wird“, und eine Verlustbenachrichtigung, „wenn bekannt ist, dass ein Gebot verloren hat“. Ein Team, das seine Ausgaben mit den Rechnungen einer Exchange abgeglichen hat, kann Ihnen sagen, welche Benachrichtigung sein System gezählt hat und was es getan hat, als die Zahlen auseinanderliefen.

Vier weitere Fragen:

  • Was passiert mit einem Gebot, das erst nach tmax fertig ist, und wie sehen Sie, wie viele Gebote zu spät kommen?
  • Wie behandelt Ihr Bidder den Mindestpreis in einem Request, das Feld bidfloor, das OpenRTB als „Mindestgebot für diese Impression, ausgedrückt als CPM“ definiert?
  • Erzählen Sie uns von einem Vorfall bei Spitzenlast: was kaputtging, was Sie gemessen und was Sie geändert haben.
  • Wer hätte Bereitschaft für unser System, und zu welchen Zeiten?

Verwenden Sie die meiste Zeit auf den Vorfall, denn die Fragen zu den Feldern lassen sich allein aus der Spezifikation beantworten.

In welcher Zeitzone arbeiten Teams in Armenien, Georgien und Aserbaidschan?

UTC+4, das ganze Jahr. Laut der Zeitzonendatenbank der IANA stellt keines der drei Länder die Uhren um, Europa und die USA dagegen schon. Bei einem Arbeitstag von 9 bis 18 Uhr auf beiden Seiten teilt ein Team in Jerewan, Tiflis oder Baku:

  • sechs Bürostunden mit Berlin, Paris oder Amsterdam im Winter und sieben im Sommer
  • fünf Stunden mit London im Winter und sechs im Sommer
  • eine Stunde mit New York, solange in den USA Sommerzeit gilt, und keine im Winter
  • keine Bürostunden mit Kalifornien

Auktionen hören um 18 Uhr nicht auf. Liegt Ihre Traffic-Spitze zwischen 20 und 23 Uhr an der US-Ostküste, ist das in Jerewan etwa zwischen 4 und 8 Uhr morgens. Vereinbaren Sie schriftlich, wer in Ihrer Spitze Bereitschaft hat, wie schnell er reagiert und wie er jemanden auf Ihrer Seite erreicht.

In welchen Sprachen wird das Team arbeiten?

OpenRTB und die Dokumentation von Prebid erscheinen auf Englisch, ein Ad-Tech-Entwickler muss also gut Englisch lesen. Unter Druck darin zu schreiben und zu sprechen ist eine eigene Fähigkeit, und die Website einer Firma verrät Ihnen nicht, wer sie hat.

Finden Sie heraus, in welcher Sprache die Entwickler Ihres Projekts und ihr Teamleiter Tickets, Code-Reviews und Incident-Berichte schreiben und in Calls sprechen werden, und hören Sie sie vor der Unterschrift in einem Videocall. Bitten Sie dann um einen schriftlichen Incident-Bericht, den das Team verfasst hat, ohne Kundendaten, und lesen Sie ihn so, wie Sie einen Bericht Ihrer eigenen Mitarbeiter lesen würden.

Welche Ad-Tech-Arbeit passt zu einem festen Umfang?

Ein fester Umfang funktioniert, wenn drei Dinge zutreffen: Die Arbeit hat eine schriftliche Spezifikation, es gibt einen Abnahmetest, den beide Seiten ausführen können, und das Ergebnis hängt nicht vom Kalender eines Partners ab.

Ad-Tech-Arbeit, die diese Bedingungen oft erfüllt:

  • Eine neue Integration mit einem Nachfrage- oder Angebotspartner, der seine OpenRTB-Spezifikation und einen Test-Endpoint veröffentlicht
  • Ein Bidder-Adapter für Prebid Server. Die Testregeln von Prebid, mit einer JSON-Datei pro Testfall und manuellen End-to-End-Tests, geben beiden Seiten einen fertigen Abnahmetest
  • Die Umstellung des Event-Reportings auf eine neue Datenbank, abgenommen, wenn die neuen Zählungen über dieselben Traffic-Tage mit den alten übereinstimmen
  • Den Bidder auf eine vereinbarte Zahl von Requests pro Sekunde innerhalb einer vereinbarten Antwortzeit bringen, abgenommen durch einen Lasttest mit Traffic, der aus Ihren eigenen Logs abgespielt wird

Nehmen Sie auch dann den Code und die Tests in den festen Umfang auf, nicht das Datum, an dem ein Partner sie annimmt. Die Maintainer von Prebid zum Beispiel prüfen neue Adapter in ihrem eigenen Takt. Für Prebid.js sagt die Dokumentation, dass der Code eines neuen Adapters „innerhalb weniger Tage“ einem Entwickler zum Review zugewiesen und nach dem Merge „mit dem nächsten Release ausgeliefert“ wird.

Andere Arbeit passt nicht in einen festen Umfang: die Gewinnquote erhöhen, die Cloud-Rechnung um einen festen Anteil senken oder einen Bidder tunen, bis er schnell genug ist. Das Ergebnis hängt vom Markt, von Ihren Partnern und von Ihrem eigenen Traffic ab, eine Firma kann sich also zur Arbeit verpflichten, aber nicht zur Zahl. Solche Arbeit passt zu einem dedizierten Team oder zu Abrechnung nach Aufwand, mit einer Messgröße, auf die sich beide Seiten vor Beginn einigen.

Unabhängig vom Umfang sollte der Vertrag festlegen, wie eine Änderung bepreist wird.

Was sollte im Vertrag mit einem Nearshore-Ad-Tech-Team stehen?

Neben den üblichen Bedingungen halten Sie schriftlich fest:

  • Die Stunden, die das Team mit Ihrem teilt, und wer außerhalb davon Bereitschaft hat
  • Die Länder, aus denen jeder Entwickler arbeitet
  • Dass der Code in Ihren Repositories liegt und in Cloud-Konten läuft, die auf den Namen Ihres Unternehmens eröffnet wurden
  • Bei einer SSP oder einer Exchange, dass Ihrem Unternehmen die Verträge mit Käufern und Verkäufern gehören und die Domain, die in ads.txt und sellers.json steht, den öffentlichen Dateien, in denen Käufer nachsehen, wer die Werbefläche verkaufen darf

Der Artikel über die Wahl eines Unternehmens in Osteuropa oder im Kaukasus behandelt die Register-, Sanktions- und Zahlungsprüfungen.

Wo passt amBrain ins Bild?

amBrain, das diesen Blog herausgibt, ist ein Software-Engineering-Unternehmen aus Jerewan, Armenien. Seine Website nennt als Ad-Tech-Leistungen „DSP-Entwicklung, Real-Time-Bidding-Plattformen und Ad-Exchange-Engineering.“ RTBBidder ist eine Demand-Side-Platform, die amBrain für einen Kunden in Rust und Go gebaut hat.

Auch die anderen Systeme, um die es in diesem Artikel geht, baut es, in eigenen Worten: „amBrain baut Supply-Side-Platforms (SSP) für Publisher.“ und „amBrain baut Event-Analytics-Pipelines für AdTech: Erfassung, Verarbeitung und Reporting von Impression- und Klick-Events.“ Es entwickelt seit 2019 Software und arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler.

Zum Eigentum lautet sein Satz: „Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.“ Stellen Sie amBrain dieselben Fragen wie jedem anderen Team: ob es eine Ihrer Aufgaben mit festem Umfang übernehmen würde und mit welchem Abnahmetest, und welche wiederverwendbaren Komponenten gemeint sind.

Dieser Artikel ist keine Rechtsberatung: Lassen Sie den Vertrag von einem Anwalt lesen, bevor Sie ihn unterschreiben.

Liegt ein solcher Entwurf bei Ihnen auf dem Tisch?

Bringen Sie Ihre aktuelle Architektur und den Fehlerfall mit, der Sie beunruhigt - wir gehen ihn in einer halben Stunde gemeinsam durch.

Termin buchen