Schnittstellenverträge

Je Anbieter ein Adapter mit festem Vertrag. In Phase 1 werden ausschließlich Verträge und Testdaten geprüft – es findet kein Aufruf produktiver Netzwerk-APIs statt.

keine produktiven Aufrufe
Anmelden

Adapter je Netzwerk

Ein Adapter läuft nur im Kontext genau eines Projekts und genau eines projektgebundenen Kontos. Zugangsdaten werden ausschließlich als Vault-Referenz übergeben.

NetzwerkFähigkeitenFreigegebene ZielhostsRatenlimitProjekte mit Konto
Alpha Click
Suche
Feed
Deeplink
klick.alpha-demo.example120/Min.Good Gatherer, Trend Kiosk
Borealis Ads
Suche
Feed
Deeplink
out.borealis-demo.example60/Min.Kulturfieber
Kestrel Network
Suche
Deeplink
go.kestrel-demo.example30/Min.Good Gatherer
Lumen Partner
Feed
track.lumen-demo.example20/Min.Kulturfieber

Einheitliches Angebotsformat

Jeder Adapter liefert nach der Normalisierung dieselbe Struktur. Der Angebotsschlüssel enthält immer die Projektkennung, damit ein Angebot niemals projektübergreifend verwendet werden kann.

offerKey
projectId:networkId:externalId
projectId / networkId / accountId
Mandanten- und Kontobindung
merchantRaw / merchantKey / merchantLabel
Rohname, Dedup-Schlüssel, Anzeigename
priceCents / shippingCents / currency
Preis normalisiert in Cent, EUR
cpcCents
erwarteter Klickwert – Basis der Slotreihenfolge
targetUrl
wird vor jedem Absprung erneut validiert

Verarbeitungskette

  1. Schritt 1
    Adapter holt Rohangebote (projekt- und kontogebunden)
  2. Schritt 2
    Normalisierung + Merchant-Alias + Deduplizierung
  3. Schritt 3
    Ausschlusslisten für Merchants, Angebote und Titelmuster
  4. Schritt 4
    Faire Auswahl mit Netzwerkgewicht und Tagesquote → Entscheidungsevent

Der Redirect ist ein eigener, nachgelagerter Vorgang: Er entsteht erst durch einen Nutzerklick, wird gegen die Redirect-Richtlinie des Projekts geprüft und getrennt vom Entscheidungsevent gespeichert.