Ungültige Werbeklicks blockieren, während die Kampagne noch läuft

Werbetreibende zahlen für jeden Klick. Ein Teil dieser Klicks stammt von Bots, VPNs, Proxys und Rechenzentren, und ein Bericht, der Wochen später eintrifft, dokumentiert nur noch den Verlust. ClickFortify ist ein unabhängiges Projekt, das ich allein entwerfe und betreibe. Seine Aufgabe: ungültigen Traffic erkennen und ausschließen, während die Kampagne noch Budget ausgibt.

Die Form des Problems

Drei Eigenschaften bestimmen fast jede Designentscheidung:

• Es hört nie auf. Klicks treffen kontinuierlich ein, rund um die Uhr und über Zeitzonen hinweg.
• Jeder Werbetreibende ist ein Mandant. Jeder hat eigene Konten, Regeln und Daten, und diese dürfen niemals ineinander durchsickern.
• Die eigentliche Aktion findet woanders statt. Einen schlechten Klick zu erkennen, ist nur die halbe Arbeit. Der Ausschluss muss über die APIs zurück in das Google-Ads- oder Meta-Werbekonto des Werbetreibenden geschrieben werden, und diese APIs haben Kontingente und schlagen gelegentlich fehl.

Bewusst Event-driven

Klicks erfassen, bewerten und Ausschlüsse synchronisieren haben sehr unterschiedliche Lastprofile. Die Erfassung kommt in Spitzen und muss schnell bleiben. Die Bewertung ist CPU-gebunden. Die Synchronisierung wird durch die API eines anderen begrenzt. Alles in einem Prozess würde den langsamsten Teil das Tempo für alle bestimmen lassen.

Deshalb ist jede Aufgabe ein eigener Service, verbunden über Events auf NATS. Ein Klick wird erfasst und veröffentlicht; die Bewertung abonniert ihn, entscheidet und veröffentlicht eine Entscheidung; die Synchronisierung greift die Entscheidungen auf, die einen Ausschluss erfordern. Jeder Service skaliert für sich, und eine langsame Werbeplattform-API staut niemals die Erfassung zurück.

Einen Klick bewerten

Kein einzelnes Signal beweist, dass ein Klick ungültig ist, deshalb kombiniert die Bewertung mehrere: Verhaltenssignale, Device Fingerprinting und die Filterung von VPN-, Proxy- und Rechenzentrums-Traffic. Weil die Bewertung von der Erfassung getrennt ist, können sich die Regeln ändern, ohne den Teil anzufassen, der verfügbar bleiben muss.

Zurückschreiben, ohne die APIs zu überlasten

Das Zurückschreiben ist der Teil, der auf interessante Weise fehlschlägt. Ausschlüsse laufen über Redis Bull Job-Queues, sodass jede Synchronisierung Wiederholungsversuche mit Backoff hat und ein Schwall von Entscheidungen zu einem gleichmäßigen Strom von API-Aufrufen wird statt zu einer Lastspitze.

// Illustrative: one queued exclusion per tenant, platform and IP
await exclusions.add(
  'exclude-ip',
  {tenantId, platform, ip},
  {
    jobId: `${tenantId}:${platform}:${ip}`, // idempotent: the same IP is never queued twice
    attempts: 5,
    backoff: {type: 'exponential', delay: 30_000},
    removeOnComplete: true
  }
);

Eine stabile Job-ID macht die Operation idempotent: Wird dieselbe IP zehnmal in einer Minute markiert, wird sie nur einmal synchronisiert.

Mandantentrennung und eine Live-Migration

Da jeder Werbetreibende eine isolierte Mandantendatenbank hat, lassen sich große Änderungen Mandant für Mandant planen statt als ein einziger riskanter Wechsel. So habe ich eine Live-Migration der Produktivdatenbanken über mehr als 500 Mandantendatenbanken nahezu ohne Ausfallzeit durchgeführt.

Was ich jemandem raten würde, der dasselbe baut

1. Betrachten Sie das Zurückschreiben in die Werbeplattform als den schwierigen Teil, nicht die Erkennung.
2. Trennen Sie Services nach Lastprofil, nicht nach Substantiv.
3. Machen Sie jeden externen Seiteneffekt idempotent, bevor Sie ihn wiederholen müssen.