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.
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.
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:
Verwenden Sie die meiste Zeit auf den Vorfall, denn die Fragen zu den Feldern lassen sich allein aus der Spezifikation beantworten.
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:
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.
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.
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:
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.
Neben den üblichen Bedingungen halten Sie schriftlich fest:
Der Artikel über die Wahl eines Unternehmens in Osteuropa oder im Kaukasus behandelt die Register-, Sanktions- und Zahlungsprüfungen.
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.
Bringen Sie Ihre aktuelle Architektur und den Fehlerfall mit, der Sie beunruhigt - wir gehen ihn in einer halben Stunde gemeinsam durch.
Termin buchen