Integration und Optimierung von Gebots- und Auktionsdiensten

bookmark_border Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Im Designvorschlag für Gebots- und Auktionsdienste für Android werden die Ausführung und der Datenfluss von Auktionen auf Android-Geräten mit dem Trusted Bidding- und Auktionsserver beschrieben. Damit Daten bei der Übertragung nur von datenschutzfreundlichen APIs und vertrauenswürdigen Servern verarbeitet werden, werden sie zwischen Client und Server mithilfe der bidirektionalen hybriden Public-Key-Verschlüsselung verschlüsselt.

Damit die Auktion wie oben beschrieben durchgeführt werden kann, muss die Anzeigentechnologie des Verkäufers auf dem Gerät die folgenden Schritte ausführen:

1. Daten für die Serverauktion erfassen und verschlüsseln
2. Anfrage an einen nicht vertrauenswürdigen Verkäuferservice senden
3. Antwort von einem nicht vertrauenswürdigen Verkäuferdienst erhalten
4. Antwort der Protected Audience-Auktion entschlüsseln und Auktionsergebnis abrufen

Im Rahmen von Protected Audience werden zwei neue APIs eingeführt, um Serverauktionen zu unterstützen:

1. Die getAdSelectionData API erfasst Daten für die Serverauktion und generiert eine verschlüsselte Nutzlast mit Auktionsdaten. Der Bidding- und Auktionsserver verwendet diese Nutzlast, um eine Auktion durchzuführen, das Auktionsergebnis zu generieren und zurückzugeben.
2. On-Device-Werbetechnologie-Clients können die persistAdSelectionResult API aufrufen, um das von der Serverauktion generierte Ergebnis zu entschlüsseln und die Render-URL der Gewinneranzeige abzurufen.

Die Anzeigentechnologie des Verkäufers auf dem Gerät muss Folgendes integrieren und erstellen, um eine Auktion durchzuführen:

1. Daten für den Verkäufer der Serverauktion erfassen und verschlüsseln: Die Anzeigentechnologie sollte die getAdSelectionData API aufrufen, um die verschlüsselte Nutzlast abzurufen.
2. Send request to Untrusted Seller Service Send: Eine HTTP POST- oder PUT-Anfrage, die die von der getAdSelectionData API generierte verschlüsselte Nutzlast an den nicht vertrauenswürdigen Verkäuferdienst und die vom nicht vertrauenswürdigen Verkäuferdienst zum Generieren von kontextbezogenen Ergebnissen erforderlichen Daten enthält.
3. Antwort vom nicht vertrauenswürdigen Verkäuferdienst erhalten: Die Antwort des nicht vertrauenswürdigen Verkäuferdienstes enthält das verschlüsselte Ergebnis der Protected Audience-Auktion und das Ergebnis der kontextbezogenen Auktion.
4. Antwort der Protected Audience-Auktion entschlüsseln und Auktionsergebnis abrufen:Um das Ergebnis der Protected Audience-Auktion zu entschlüsseln, sollte die Anzeigentechnologie des Verkäufers die persistAdSelectionResult API aufrufen. Anhand des von persistAdSelectionResult generierten Ergebnisses können Anbieter von Anzeigentechnologien feststellen, ob die Auktion von einer kontextbezogenen Anzeige oder einer Anzeige für geschützte Zielgruppen gewonnen wurde, und gegebenenfalls den URI der Gewinneranzeige für geschützte Zielgruppen.

Für Serverauktionen unterstützte Funktionen

Wir möchten alle Funktionen unterstützen, die derzeit für On-Device-Auktionen verfügbar sind. Die Zeitleiste für die Unterstützung dieser Funktionen bei Serverauktionen sieht so aus:

Serverauktionen mit Protected Audience APIs ausführen

Im Entwicklervorschau-Track stellt AdSelectionManager zwei neue APIs bereit: getAdSelectionData und persistAdSelectionResult. Mit diesen APIs können AdTech-SDKs in Gebot- und Auktionsserver eingebunden werden.

Daten für eine Serverauktion erfassen und verschlüsseln

Die getAdSelectionData API generiert die erforderliche Eingabe für Gebots- und Auktionskomponenten wie BuyerInput und ProtectedAudienceInput und verschlüsselt die Daten, bevor das Ergebnis für den Aufrufer verfügbar gemacht wird. Um Datenlecks zwischen Apps zu verhindern, enthalten diese Daten Informationen von allen Käufern, die sich auf dem Gerät befinden. Weitere Informationen zu dieser Entscheidung finden Sie im Abschnitt Datenschutzaspekte. Strategien zur Optimierung finden Sie im Abschnitt Größe.

Damit Sie auf die API zugreifen können, muss der Zugriff auf die Protected Audience API aktiviert und die Berechtigung ACCESS_ADSERVICES_CUSTOM_AUDIENCE im Manifest des Aufrufers definiert sein.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. Der Aufrufer muss das Feld „seller“ in der Anfrage festlegen, da damit vor der Bearbeitung der Anfrage die Registrierung geprüft wird.
2. Das Feld coordinatorOriginUri ist optional.
   1. Wenn festgelegt, sollte dies dem Schema, dem Hostnamen und dem Port der Koordinator-URL entsprechen, die beim Bereitstellen des B&A-Servers des Verkäufers konfiguriert wurde.
   2. Der Koordinator muss in der Liste der zugelassenen Koordinatoren aufgeführt sein:

      Anbieter	URI	URI-Ursprung	Standard
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Ja
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	Nein

   3. Wenn kein Koordinator-Ursprung angegeben ist, wird der Standardkoordinator verwendet.
   4. Es ist zwar sehr unwahrscheinlich, dass sich die URL des Koordinators ändert, aber es wird dringend empfohlen, einen Mechanismus zur dynamischen Verwaltung dieser URL zu implementieren. So können zukünftige Änderungen an der URL berücksichtigt werden, ohne dass eine neue SDK-Version erforderlich ist.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

Nach der Validierung der Anfrage werden die Käuferdaten auf dem Gerät in BuyerInput und ProtectedAudienceInput zusammengeführt. Das endgültige Nutzlastobjekt wird dann mithilfe der bidirektionalen Hybrid Public Key Encryption verschlüsselt.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome wird als Ergebnis der getAdSelectionData API generiert. Es enthält folgende Elemente:

1. adSelectionId: eine nicht transparente Ganzzahl, um diese Aufrufung von getAdSelectionData zu identifizieren. Der AdTech-Client sollte diesen adSelectionId-Wert speichern, da er als Verweis auf den getAdSelectionData-Aufruf dient. Diese Kennung ist für die persistAdSelectionResult API erforderlich, um das Auktionsergebnis vom Bidding- und Auktionsserver zu entschlüsseln. Sie ist auch für die reportImpression und reportEvent APIs erforderlich.
2. adSelectionData: Dies sind die verschlüsselten Auktionsdaten, die vom Bidding- und Auktionsserver zum Ausführen von Auktionen benötigt werden. Diese Methode enthält:
   1. Gefilterte Daten zu benutzerdefinierten Zielgruppen basierend auf Frequency Capping, App-Installationsfiltern und Anforderungen an Serverauktionen für benutzerdefinierte Zielgruppen.
   2. In einer zukünftigen Version werden Daten zu App-Installationen enthalten sein.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Fehler, Ausnahmen und Fehlerbehandlung

Wenn die Generierung der Daten für die Anzeigenauswahl aus bestimmten Gründen wie ungültigen Argumenten, Zeitüberschreitungen oder übermäßigem Ressourcenverbrauch nicht erfolgreich abgeschlossen werden kann, enthält der OutcomeReceiver.onError()-Callback einen AdServicesException mit den folgenden Verhaltensweisen:

1. Wenn getAdSelectionData mit ungültigen Argumenten gestartet wird, gibt AdServicesException die IllegalArgumentException als Ursache an.
2. Bei allen anderen Fehlern wird ein AdServicesException mit einer IllegalStateException als Ursache zurückgegeben.

Anfrage an einen nicht vertrauenswürdigen Verkäuferdienst senden

Mit AdSelectionData kann das On-Device-SDK eine Anfrage an den Werbedienst des Verkäufers senden, indem die Daten in eine POST- oder PUT-Anfrage aufgenommen werden:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

Das On-Device-SDK ist für die Codierung dieser Daten verantwortlich. Wir empfehlen, eine platzsparende Lösung zu verwenden, z. B. das Senden der Anfrage an den Anzeigendienst des Verkäufers als multipart/form-data.

Antwort von einem nicht vertrauenswürdigen Verkäuferdienst erhalten

Wie im Erläuterungsartikel zu Gebot- und Auktionsservern beschrieben, sendet der nicht vertrauenswürdige Verkäuferdienst, wenn er die Anfrage erhält, Anfragen an Partnerkäufer für kontextbezogene Anzeigen.

Der nicht vertrauenswürdige Verkäuferdienst leitet die verschlüsselten adSelectionData und AuctionConfig an den SellerFrontEnd-Dienst des Bidding- und Auktionsservers weiter, der in einem TEE ausgeführt wird.

Wenn die Protected Audience-Auktion abgeschlossen ist, verschlüsselt der SellerFrontEnd-Dienst das Auktionsergebnis und gibt es als Antwort an den nicht vertrauenswürdigen Verkäuferdienst zurück.

Der nicht vertrauenswürdige Verkäuferdienst sendet eine Antwort an das Gerät, die eine kontextbezogene Anzeige und / oder ein verschlüsseltes Ergebnis der Protected Audience-Auktion enthält.

Nach Erhalt der Antwort kann der Anzeigentechnologiecode des Verkäufers auf dem Gerät entscheiden, nur die kontextbezogene Anzeige in der Antwort zu verwenden. Wenn er der Meinung ist, dass das Ergebnis der Protected Audience API einen zusätzlichen Wert hat, kann er es durch Aufrufen der PersistAdSelectionResult API entschlüsseln.

PersistAdSelectionResult API

Um das Protected Audience-Ergebnis zu entschlüsseln, kann die Anzeigentechnologie des Verkäufers die zweite Protected Audience API persistAdSelectionResult aufrufen. Die API entschlüsselt das Ergebnis und gibt ein AdSelectionOutcome zurück, dasselbe Objekt, das heute von einer On-Device-Auktion zurückgegeben wird.

Um auf die API zuzugreifen, muss der Aufrufer den Zugriff auf die Protected Audience API aktivieren und die Berechtigung ACCESS_ADSERVICES_CUSTOM_AUDIENCE in seinem Manifest definieren.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

Der Aufrufer muss in der Anfrage Folgendes festlegen:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: Die opaque Kennung, die durch den getAdSelectionData-Aufruf generiert wurde und deren Ergebnis der Aufrufer entschlüsseln möchte.
2. seller: Die AdTech-ID des Verkäufers muss in der Anfrage festgelegt sein, damit vor der Bearbeitung der Anfrage die Registrierung geprüft werden kann.
3. adSelectionResult: Das verschlüsselte Auktionsergebnis, das vom Bidding- und Auction-Server generiert wurde und das der Aufrufer entschlüsseln möchte.

Antwort „AdSelectionOutcome“

Wenn es einen Protected Audience-Gewinner gibt, gibt AdSelectionOutcome die URI für das Rendern der Gewinneranzeige zurück.Sobald adSelectionResult entschlüsselt wurde, werden die Berichtsdaten intern gespeichert. Der OutcomeReceiver.onResult()-Callback gibt ein AdSelectionOutcome zurück, das Folgendes enthält:

• URI: Wenn es eine ausgelieferte Protected Audience-Anzeige gibt, wird eine Anzeigen-Render-URL für diese Anzeige zurückgegeben. Wenn es keinen Gewinner für die Zielgruppe mit geschützten Zielgruppen gibt, wird „Uri.EMPTY“ zurückgegeben.
• adSelectionId: Die adSelectionId, die mit dieser Serverauktion verknüpft ist.

Fehler, Ausnahmen und Fehlerbehandlung

Wenn die Generierung der Daten für die Anzeigenauswahl aus bestimmten Gründen wie ungültigen Argumenten, Zeitüberschreitungen oder übermäßigem Ressourcenverbrauch nicht erfolgreich abgeschlossen werden kann, enthält der OutcomeReceiver.onError()-Callback einen AdServicesException mit den folgenden Verhaltensweisen:

1. Wenn getAdSelectionData mit ungültigen Argumenten gestartet wird, gibt AdServicesException IllegalArgumentException als Ursache an.
2. Bei allen anderen Fehlern wird ein AdServicesException mit einer IllegalStateException als Ursache zurückgegeben.

Datenschutzaspekte

adSelectionData wird verschlüsselt, damit nur PPAPI und die vertrauenswürdigen Server auf die Daten zugreifen können.

Trotz Verschlüsselung kann es aufgrund der Größe von adSelectionData zu Datenlecks kommen. Die Größe von adSelectionData kann aus folgenden Gründen variieren:

1. Änderungen an CustomAudience-Daten auf dem Gerät
2. Änderungen an der CustomAudience-Filterlogik
3. Änderungen an der Eingabe für getAdSelectionData-Anrufe.

Eine Änderung der Größe von adSelectionData kann zum Generieren einer appübergreifenden Kennung verwendet werden, wie in der Diskussion zum 1-Bit-Leak erwähnt. Viele Maßnahmen, die für ein 1-Bit-Leak gelten, gelten auch hier.

Um diese Lecks zu verwalten, planen wir, für alle Aufrufe der getAdSelectionData API dieselbe adSelectionData zu generieren. Bei den ersten Releases werden alle CustomAudiences auf dem Gerät zum Erstellen von adSelectionData verwendet und die verschlüsselte Nutzlast wird aufgefüllt, um Größenabweichungen zu verbergen. Außerdem wird der Einfluss von GetAdSelectionData-Eingabeparametern auf die generierten adSelectionData-Werte eingeschränkt.

Wenn jedoch dieselbe adSelectionData für alle Anzeigentechnologien mit allen On-Device-Auktionsdaten generiert wird, entsteht eine große Nutzlast, die jetzt bei jedem Aufruf an den AdTech-Server übertragen werden muss. Wenn alle benutzerdefinierten Zielgruppen auf dem Gerät verwendet werden, um die Auktionsnutzlast zu generieren, kann das System von böswilligen Entitäten missbraucht werden. Diese Bedenken werden unten in den Abschnitten Größenoptimierungen und Maßnahmen zur Missbrauchsbegrenzung behandelt.

Größenoptimierungen

Das AdTech-Client-SDK soll die verschlüsselten Bytes von adSelectionData in den HTTP PUT/POST-Kontextaufruf an den AdTech-Server verpacken. Um die Latenz und die Kosten der Rundreisezeit zu senken, muss die Größe von adSelectionData so weit wie möglich reduziert werden, ohne die Nutzbarkeit zu beeinträchtigen.

Wir planen, die folgenden Optimierungen in den kommenden Releases zu untersuchen und gegebenenfalls einzuführen, um die Größe von adSelectionData zu reduzieren:

1. Nutzlast, die in einer festen Bucket-Größe mit Padding generiert wird: Um die Datenlecks durch Größenabweichungen zu minimieren und gleichzeitig kleinere Nutzlasten zu ermöglichen, empfehlen wir die Verwendung von Bucketing mit fester Größe für die generierte Nutzlast. Wenn Sie die Anzahl der Buckets klein halten, z. B. auf 7, führt dies zu weniger als 3 Bit Leckage-Entropie pro Aufruf von getAdSelectionData.

   Wenn die On-Device-Daten die maximale Bucket-Größe überschreiten, werden die folgenden Strategien wie Prioritätswerte verwendet, um zu entscheiden, welche Daten gelöscht werden.

2. Käuferkonfiguration: Wir prüfen, ob Käufer eine Payload-Konfiguration pro Käufer einrichten können. Diese Konfiguration ist nützlich, um zu ermitteln, an welchen Auktionen ein Käufer teilnehmen möchte. Wenn möglich, kann die Anzeigentechnologie eines Käufers während der Registrierung einen Endpunkt registrieren, von dem Protected Audience die Nutzlastkonfiguration täglich abrufen kann. Alternativ können datenschutzfreundliche APIs eine API bereitstellen, mit der Anzeigentechnologie-Anbieter für Käufer diesen Endpunkt registrieren können.

   Anhand dieser Konfiguration wird dann der Beitrag eines Käufers zu den für jede getAdSelectionData-Anfrage generierten adSelectionData bewertet.

   Mit der Konfiguration der Käufernutzlast können Käufer Folgendes angeben:

   1. Zulässige Verkäuferliste: Käufer-CustomAudiences werden der Nutzlast nur hinzugefügt, wenn der getAdSelectionData-Aufruf von einem Verkäufer auf der Zulassungsliste initiiert wird. Wir würden die Nutzlastkonfiguration täglich abrufen, um die Zulassungsliste auf dem neuesten Stand zu halten.
   2. Größenbeschränkung pro Verkäufer: Käufer können eine Größenbeschränkung pro Verkäufer angeben, um die Datengröße zu bestimmen, die in der Nutzlast gesendet werden soll, wenn eine Auktion von einem bestimmten Verkäufer initiiert wird. Das ist nützlich, wenn ein Käufer mehr Ressourcen für die Verarbeitung von Auktionsdaten bestimmter Verkäufer aufwenden möchte. Der SellerFrontendService leitet nur käuferspezifische Daten an jeden BuyerFrontendService weiter. Durch Festlegen eines Größenlimits pro Verkäufer kann ein Käufer die Menge der Daten, die vom BuyerFrontendService seines Bidding- und Auktionsservers für Auktionen verarbeitet werden, explizit steuern.

3. Verkäuferkonfiguration: Wir prüfen die Machbarkeit einer Auktionskonfiguration pro Verkäufer, mit der Verkäufer Auktionsparameter definieren können, um die Nutzlastgröße und die Auktionsteilnehmer zu steuern. Wenn möglich, kann die Anzeigentechnologie des Verkäufers während der Registrierung den Endpunkt angeben, von dem Protected Audience die Auktionskonfiguration pro Verkäufer in regelmäßigen Abständen abrufen kann. Anhand dieser Konfiguration werden dann die Zusammensetzung und Limits von adSelectionData für jede getAdSelectionData-Anfrage bestimmt.

   Ähnlich wie bei der Käuferkonfiguration können Verkäufer mit einer Verkäuferkonfiguration angeben, welche Käufer sie in einer Auktion erwarten, und Limits für den Beitrag pro Käufer zur Nutzlastgröße festlegen.

   In der Auktionskonfiguration können Verkäufer Folgendes angeben:

   1. Zulässige Käuferliste: Bei Auktionen, die vom jeweiligen Verkäufer initiiert werden, können nur die Käufer auf der Zulassungsliste benutzerdefinierte Zielgruppen für die Auktion einreichen. Die Auktionskonfiguration müsste täglich aktualisiert werden, damit die Zulassungsliste mit der serverseitigen Zulassungsliste der Käufer übereinstimmt.
   2. Größenbeschränkung pro Käufer: Verkäufer können eine Größenbeschränkung pro Käufer angeben, um die Datenmenge zu regulieren, die von jedem Käufer in die an SellerFrontendService gesendete Nutzlast hochgeladen wird. Wenn der Käufer das Limit für die Größe pro Käufer überschreitet, wird die in der Käufernutzlastkonfiguration festgelegte Priorität für benutzerdefinierte Zielgruppen verwendet, um die Daten innerhalb der erwarteten Limits zu halten.
   3. Priorität pro Käufer: Verkäufer können eine Priorität pro Käufer festlegen. Anhand der Käuferpriorität wird ermittelt, welche Käuferdaten in der Nutzlast beibehalten werden sollen, wenn die Nutzlastgröße das Limit überschreitet.
   4. Maximale Größe der Nutzlast: Unterschiedliche Verkäufer können unterschiedliche Ressourcenzuweisungen haben und möchten möglicherweise ein maximales Größenlimit für die Auktionsnutzlast pro Anfrage festlegen. Die maximale Größe berücksichtigt die von der Protected Audience API festgelegten Bucket mit fester Größe.

4. Änderungen bei benutzerdefinierten Zielgruppen

   1. Priorität für benutzerdefinierte Zielgruppen angeben: Käufer können einen Prioritätswert für eine benutzerdefinierte Zielgruppe angeben. Im Feld priority werden benutzerdefinierte Zielgruppen angegeben, die in einer Auktion berücksichtigt werden sollen, wenn die Anzahl der benutzerdefinierten Zielgruppen von Käufern die zulässige Größe pro Verkäufer oder Käufer überschreitet. Wenn in einer benutzerdefinierten Zielgruppe kein Prioritätswert angegeben ist, wird standardmäßig 0.0 verwendet.

5. Änderungen an Nutzlastdaten

   1. In der Nutzlast gesendete Daten reduzieren: Wie in der Optimierung der Nutzlast von Bidding- und Auktionsdiensten beschrieben, wird eine höhere Nutzlast durch Daten zu benutzerdefinierten Zielgruppenads, Nutzergebotssignale und Android-Signale verursacht. Höhere Nutzlasten können durch Folgendes gesenkt werden:
      1. Der Client sendet Anzeigen-Render-IDs (anstelle von Anzeigenobjekten) in der Nutzlast.
      2. Der Client sendet keine Anzeigendaten in der Nutzlast.
      3. Es werden keine Gebotshinweise für Nutzer in der Clientnutzlast gesendet.

Mit den oben genannten Strategien können Anbieter von Anzeigentechnologien Konfigurationen definieren, um die Zusammensetzung und Limits der adSelectionData-Nutzlast zu verwalten. Sie können aber auch ein Faktor für die Modulation der adSelectionData-Größe sein, indem Konfigurationsparameter geändert werden. Um dies zu vermeiden, wird die Konfiguration täglich von Protected Audience vom konfigurierten Endpunkt abgerufen.

Latenzoptimierung

Damit Serverauktionen eine zufriedenstellende Leistung bieten, müssen die getAdSelectionData API und die persistAdSelectionResult API eine geringe Latenz pro Aufruf haben. Wir möchten 2023 Funktionsunterstützung für APIs anbieten. Bei der nächsten Version liegt der Schwerpunkt jedoch auf Latenzbenchmarks und Optimierungen für die APIs.

Wir prüfen die folgenden Strategien, um die Latenz innerhalb akzeptabler Grenzen zu halten:

1. Vorabgenerierung von Daten zu geschützten Zielgruppen pro Verkäufer: Da die Auktionskonfiguration des Verkäufers und die Käufernutzlastkonfiguration über einen längeren Zeitraum (täglich) stabil bleiben, können die entsprechenden Daten zu geschützten Zielgruppen vorab berechnet und gespeichert werden.

   Dazu müsste die Plattform einen Mechanismus entwickeln, mit dem Aktualisierungen von benutzerdefinierten Zielgruppen überwacht und die vorab generierten Daten für geschützte Zielgruppen entsprechend angepasst werden. Die Plattform muss außerdem SLOs für die Verzögerung bei der Anzeigentechnologie angeben, die zwischen Aktualisierungen von benutzerdefinierten Zielgruppen und der Sichtbarkeit der Änderung in der für die Serverauktion generierten adSelectionData auftreten kann.

   Da ein Gerät ein begrenztes Ressourcenberechnungsmodell mit unterschiedlichen Prozessprioritäten bietet, müssen wir dafür sorgen, dass diese Vorabgenerierungsfunktion eine hohe Zuverlässigkeit und SLO-Garantien bietet.

   Die Daten für geschützte Zielgruppen werden dann auf der Grundlage der folgenden Informationen vorab generiert:

   1. Der Verkäufer aktiviert die Vorabgenerierung von Protected Audience-Daten.
   2. Käufer, die an einer von einem bestimmten Verkäufer initiierten Auktion teilnehmen dürfen.
   3. Bestimmen von benutzerdefinierten Zielgruppen pro Käufer, die Teil der Nutzlast sein sollen, basierend auf:
      1. In der Verkäuferkonfiguration festgelegte Größenbeschränkungen, Prioritäten pro Käufer und maximale Größenbeschränkungen
      2. Größere Beschränkung pro Verkäufer, Priorität der benutzerdefinierten Zielgruppe in der Käuferkonfiguration festgelegt

2. Vorab-Anwendung der Negativfilterung: Wenn ein Verkäufer dies bevorzugt, kann die Plattform die adSelectionData-Werte vorab berechnen, indem sie Daten zu geschützten Zielgruppen generiert und die Negativfilterung auf den kritischen getAdSelectionData-Aufruf anwendet. So können Verkäufer die Latenz senken und gleichzeitig veraltete Daten bei der Negativfilterung akzeptieren.

   Die Plattform könnte diese Unterstützung durch eine Standardoption in der Verkäuferkonfiguration mit einem Gültigkeitslimit und einer Überschreibungsoption in getAdSelectionData bieten, um bei Bedarf die aktuellsten Daten zu berechnen. Alternativ kann die Plattform eine zusätzliche Initiatierungs-API bereitstellen, die vor getAdSelectionData aufgerufen wird, um die Auktion zu starten.

3. Nutzlastberechnung für mehrere Auktionen: In bestimmten Szenarien ist eine API mit geringer Latenz vorzuziehen, auch wenn die Daten dadurch möglicherweise veraltet sind. Dazu könnte die Plattform eine Initialisierungs-API einführen, um die gesamte Nutzlast zu berechnen und dem Aufrufer eine Referenz auf die berechnete Nutzlast zur Verfügung zu stellen.

   Bei nachfolgenden Aufrufen von getAdSelectionData kann der Aufrufer einen Verweis auf die vorab berechnete Nutzlast angeben, die für die Generierung von adSelectionData verwendet werden soll.

Alle drei oben genannten Strategien befinden sich in der ersten explorativen Phase und sollen die Richtung beschreiben, in die sich die Plattform entwickeln könnte, um die Latenz zu optimieren. Wir werden weitere Strategien vorschlagen, sobald wir detailliertere Latenzprofile der API und der Anforderungen an die Anzeigentechnologien kennen.

Minderung des Missbrauchsrisikos und Identifizierung von Missbrauch

Wie bereits unter „Datenschutzaspekte“ erwähnt, wird adSelectionData anhand aller Käuferdaten auf dem Gerät generiert.

Wenn jedoch alle Käuferdaten auf dem Gerät zum Generieren der adSelectionData-Ausgabe verwendet werden, kann sich eine böswillige Entität als Käufer ausgeben und betrügerische Käuferdaten erstellen, um die Android-Leistung zu beeinträchtigen, die Nutzlast zu vergrößern, um die Kosten für eine Anzeigentechnologie für Auktionen oder Gebote zu erhöhen usw.

Minderung von Umweltbelastungen

Einige Maßnahmen, die im Abschnitt zu Größenbeschränkungen erwähnt werden, wie die Konfiguration der Käufernutzlast mit Verkäufern auf der Zulassungsliste und die Auktionskonfiguration des Verkäufers mit Käufern auf der Zulassungsliste, können dazu beitragen, unerwartete Daten in der Nutzlast auszuschließen.

Andere Maßnahmen zur Größenbegrenzung, z. B. die Möglichkeit für SSPs, Käuferprioritäten anzugeben, ein Käuferkontingent in die generierte Nutzlast einzubauen und eine maximale Größe pro Auktionsnutzlast festzulegen, können ebenfalls dazu beitragen, die Auswirkungen von schädlichen Nutzlast-Aufblähungen zu verringern. Mit diesen Maßnahmen sollen Anbieter von Anzeigentechnologien festlegen können, mit welchen Anbietern von Anzeigentechnologien sie zusammenarbeiten, und akzeptable Limits für die zu verarbeitende Nutzlast festlegen.

Wie bereits erwähnt, müssen alle Maßnahmen zur Missbrauchsprävention und Größenbeschränkung den Datenschutzanforderungen entsprechen.

Identifizierung schädlicher Entitäten

Die oben genannten Maßnahmen schützen zwar die adSelectionData-Generierung für Serverauktionen, helfen aber nicht, böswillige Entitäten zu identifizieren oder die Plattform vor Missbrauch zu schützen, z. B. vor der Erstellung einer nie dagewesenen Anzahl von benutzerdefinierten Zielgruppen durch einen Käufer.

Um die Stabilität und Gesundheit der Plattform zu gewährleisten, müssen wir einen Mechanismus finden, mit dem schädliche Entitäten, Missbrauchsvektoren und die Motivation für die jeweiligen Angriffe identifiziert werden können. In späteren Releases werden wir Erläuterungen zu den potenziellen Missbrauchsvektoren und den Schutzmaßnahmen veröffentlichen, die wir ergriffen haben, um ihnen entgegenzuwirken.