Integration und Optimierung von Gebots- und Auktionsdiensten

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 and Auction-Server beschrieben. Damit Daten bei der Übertragung nur von datenschutzfreundlichen APIs und vertrauenswürdigen Servern verarbeitet werden, werden die Daten zwischen Client und Server mit bidirektionaler Hybrid Public Key Encryption verschlüsselt.

Damit die Auktion wie oben beschrieben ausgefü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äuferservice erhalten
4. Protected Audience-Auktionsantwort entschlüsseln und Auktionsergebnis abrufen

Für die Durchführung von Serverauktionen werden zwei neue APIs eingeführt:

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

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

1. Daten für die Serverauktion des Verkäufers erfassen und verschlüsseln: Die AdTech-Plattform sollte die getAdSelectionData API aufrufen, um die verschlüsselte Nutzlast abzurufen.
2. Anfrage an den Dienst für nicht vertrauenswürdige Verkäufer senden: Eine HTTP POST- oder PUT-Anfrage mit der verschlüsselten Nutzlast, die von der getAdSelectionData-API generiert wurde, an den Dienst für nicht vertrauenswürdige Verkäufer und Daten, die vom Dienst für nicht vertrauenswürdige Verkäufer zum Generieren kontextbezogener Ergebnisse benötigt werden.
3. Antwort vom Dienst eines nicht vertrauenswürdigen Verkäufers erhalten: Die Antwort vom Dienst eines nicht vertrauenswürdigen Verkäufers enthält das verschlüsselte Protected Audience-Auktionsergebnis und das kontextbezogene Auktionsergebnis.
4. Protected Audience-Auktionsantwort entschlüsseln und Auktionsergebnis abrufen:Um das Protected Audience-Auktionsergebnis zu entschlüsseln, muss die Anzeigen-Technologie des Verkäufers die persistAdSelectionResult API aufrufen. Das von persistAdSelectionResult generierte Ergebnis hilft Anzeigentechnologien, zu ermitteln, ob die kontextbezogene Anzeige oder die Anzeige für geschützte Zielgruppen die Auktion gewonnen hat, und gegebenenfalls die URI der Anzeige für geschützte Zielgruppen, die die Auktion gewonnen hat.

Unterstützte Funktionen für Serverauktionen

Wir möchten alle Funktionen unterstützen, die für die Auktion auf dem Gerät verfügbar sind. Der Zeitplan für die Unterstützung dieser Funktionen in der Serverauktion ist wie folgt:

Serverauktionen mit Protected Audience APIs ausführen

Im Developer Preview-Track stellt AdSelectionManager zwei neue APIs bereit: getAdSelectionData und persistAdSelectionResult. Mit diesen APIs können Ad-Tech-SDKs in Bidding- und Auktionsserver eingebunden werden.

Daten für eine Serverauktion sammeln 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 zu verhindern, dass Daten an andere Apps weitergegeben werden, enthält diese Datei Informationen von allen Käufern auf dem Gerät. Weitere Informationen zu dieser Entscheidung finden Sie im Abschnitt Datenschutzaspekte und Strategien zur Optimierung im Abschnitt Größenaspekte.

Um auf die API zuzugreifen, muss der Zugriff auf die Protected Audience API aktiviert sein und die Berechtigung ACCESS_ADSERVICES_CUSTOM_AUDIENCE muss 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 es verwendet wird, um Registrierungsprüfungen durchzuführen, bevor die Anfrage bearbeitet wird.
2. Das Feld coordinatorOriginUri ist optional.
   1. Wenn diese Option festgelegt ist, sollte sie 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 enthalten 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 Ursprung des Koordinators angegeben ist, wird der Standardkoordinator verwendet.
   4. Es ist zwar höchst unwahrscheinlich, dass sich die Koordinator-URL ändert, es wird jedoch 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)
}

Nachdem die Anfrage validiert wurde, werden die Käuferdaten auf dem Gerät in BuyerInput und ProtectedAudienceInput zusammengestellt. Das endgültige Nutzlastobjekt wird dann mit bidirektionaler Hybrid Public Key Encryption verschlüsselt.

GetAdSelectionDataOutcome

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

1. adSelectionId: Eine undurchsichtige Ganzzahl zur Identifizierung dieses Aufrufs von getAdSelectionData. Der Ad-Tech-Client sollte diesen adSelectionId-Wert beibehalten, da er als Zeiger auf den getAdSelectionData-Aufruf dient. Diese Kennung ist für die persistAdSelectionResult API erforderlich, um das Auktionsergebnis vom Gebots- 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 für die Ausführung von Auktionen auf dem Gebots- und Auktionsserver erforderlich sind. Diese Methode enthält:
   1. Gefilterte Daten zu benutzerdefinierten Zielgruppen basierend auf Frequency Capping, Filtern für App-Installationen und Serverauktionsanforderungen 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 von Daten für die Anzeigenauswahl aus Gründen wie ungültigen Argumenten, Zeitüberschreitungen oder übermäßigem Ressourcenverbrauch nicht erfolgreich abgeschlossen werden kann, wird im OutcomeReceiver.onError()-Callback ein AdServicesException mit den folgenden Verhaltensweisen bereitgestellt:

1. Wenn getAdSelectionData mit ungültigen Argumenten initiiert wird, gibt AdServicesException eine IllegalArgumentException als Ursache an.
2. Alle anderen Fehler erhalten einen AdServicesException mit IllegalStateException als Ursache.

Anfrage an einen nicht vertrauenswürdigen Verkäuferdienst senden

Mit AdSelectionData kann das On-Device-SDK eine Anfrage an den Anzeigen-Service 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. Es wird empfohlen, eine speichereffiziente Lösung zu verwenden, z. B. die Anfrage als „multipart/form-data“ an den Anzeigen-Service des Verkäufers zu senden.

Antwort von einem nicht vertrauenswürdigen Verkäuferservice erhalten

Wie im Bidding and Auction Server explainer beschrieben, ruft der nicht vertrauenswürdige Verkäuferdienst nach Erhalt der Anfrage Partnerkäufer für kontextbezogene Anzeigen auf.

Der nicht vertrauenswürdige Verkäuferdienst leitet das verschlüsselte adSelectionData und AuctionConfig an den SellerFrontEnd-Dienst des Bidding and Auction-Servers weiter, der in einer 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 Protected Audience-Auktionsergebnis enthält.

Nach Erhalt der Antwort kann der Ad-Tech-Code des Verkäufers auf dem Gerät entscheiden, ob er nur die kontextbezogene Anzeige in der Antwort verwendet. Wenn er der Meinung ist, dass es einen zusätzlichen Wert hat, das Protected Audience-Ergebnis abzurufen, kann er das Protected Audience-Ergebnis 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-Objekt zurück, das mit dem Objekt identisch ist, das derzeit bei 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 undurchsichtige Kennung, die vom getAdSelectionData-Aufruf generiert wurde, dessen Ergebnis der Aufrufer entschlüsseln möchte.
2. seller: Die Ad-Tech-ID des Verkäufers muss in der Anfrage festgelegt werden, damit vor der Bearbeitung der Anfrage Registrierungsprüfungen durchgeführt werden können.
3. adSelectionResult: Das verschlüsselte Auktionsergebnis, das vom Gebots- und Auktionsserver generiert wurde und das der Aufrufer entschlüsseln möchte.

AdSelectionOutcome-Antwort

Wenn es einen Protected Audience-Gewinner gibt, gibt AdSelectionOutcome die Render-URI 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 Protected Audience-Gewinneranzeige gibt, wird eine Anzeigen-Render-URL für die Gewinneranzeige zurückgegeben. Wenn es keinen Protected Audience-Gewinner gibt, wird „Uri.EMPTY“ zurückgegeben.
• adSelectionId: Die adSelectionId, die mit dieser Serverauktion verknüpft ist.

Fehler, Ausnahmen und Fehlerbehandlung

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

1. Wenn getAdSelectionData mit ungültigen Argumenten initiiert wird, gibt AdServicesException als Ursache IllegalArgumentException an.
2. Alle anderen Fehler erhalten einen AdServicesException mit IllegalStateException als Ursache.

Datenschutz

adSelectionData ist verschlüsselt, damit Daten während der Übertragung nur für PPAPI und die vertrauenswürdigen Server zugänglich sind.

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 Filterlogik für CustomAudience
3. Änderungen an der Eingabe für den getAdSelectionData-Aufruf.

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

Um diese Lecks zu beheben, planen wir, für alle Aufrufe der getAdSelectionData API dieselbe adSelectionData zu generieren. In den ersten Versionen werden alle CustomAudiences auf dem Gerät zum Erstellen von adSelectionData verwendet. Die verschlüsselte Nutzlast wird aufgefüllt, um Größenunterschiede zu maskieren. Außerdem schränken wir den Einfluss von GetAdSelectionData-Eingabeparametern auf die generierten adSelectionData ein.

Wenn jedoch für alle Ad-Tech-Anbieter dieselbe adSelectionData mit allen On-Device-Auktionsdaten generiert wird, entsteht eine große Nutzlast, die bei jedem Aufruf des Ad-Tech-Servers übertragen werden muss. Wenn alle benutzerdefinierten Zielgruppen auf dem Gerät verwendet werden, um die Auktionsnutzlast zu generieren, ist das Ökosystem auch anfälliger für Missbrauch durch böswillige Akteure. Diese Bedenken werden in den Abschnitten Größenoptimierungen und Maßnahmen gegen Missbrauch behandelt.

Größenoptimierungen

Das AdTech-Client-SDK muss die verschlüsselten Bytes von adSelectionData in den kontextbezogenen Aufruf HTTP PUT/POST einfügen, der an den AdTech-Server gesendet wird. Um die Latenz und die Kosten für die Roundtrip-Zeit zu senken, muss die Größe von adSelectionData so weit wie möglich reduziert werden, ohne die Nützlichkeit zu beeinträchtigen.

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

1. Nutzlast, die in einer festen Anzahl von Bucket-Größen mit Padding generiert wird: Um das Risiko von Datenlecks durch Größenvariationen zu minimieren und gleichzeitig niedrigere Nutzlasten zu ermöglichen, empfehlen wir, für die generierte Nutzlast Buckets mit fester Größe zu verwenden. Wenn Sie die Anzahl der Buckets gering halten, z. B. 7, werden pro Aufruf von getAdSelectionData weniger als 3 Bit an Entropie offengelegt.

   Wenn die Daten auf dem Gerät die maximale Bucket-Größe überschreiten, werden Strategien wie Prioritätswerte verwendet, um zu entscheiden, welche Daten verworfen werden.

2. Käuferkonfiguration: Wir prüfen, ob es möglich ist, dass Käufer eine Nutzlastkonfiguration pro Käufer einrichten. Diese Konfiguration ist nützlich, um zu ermitteln, an welchen Auktionen ein Käufer teilnehmen möchte. Wenn möglich, könnte ein Käufer-Ad-Tech-Unternehmen bei der Registrierung einen Endpunkt registrieren, von dem Protected Audience die Nutzlastkonfiguration täglich abrufen würde. Alternativ könnten datenschutzfreundliche APIs eine API bereitstellen, mit der Anzeigentechnologien von Käufern diesen Endpunkt registrieren können.

   Diese Konfiguration wird dann verwendet, um den Beitrag eines Käufers zu adSelectionData zu bewerten, der für jede getAdSelectionData-Anfrage generiert wird.

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

   1. Liste der zulässigen Verkäufer: Die benutzerdefinierten Zielgruppen des Käufers werden der Nutzlast nur hinzugefügt, wenn der getAdSelectionData-Aufruf von einem Verkäufer auf der Zulassungsliste initiiert wird. Wir rufen die Nutzlastkonfiguration täglich ab, um die Zulassungsliste auf dem neuesten Stand zu halten.
   2. Größenbeschränkung pro Verkäufer: Der Käufer kann eine Größenbeschränkung pro Verkäufer festlegen, 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 bereitstellen möchte. Der SellerFrontendService leitet nur käuferspezifische Daten an die einzelnen BuyerFrontendServices weiter. Durch die Definition eines Größenlimits pro Verkäufer kann ein Käufer die Menge der Daten, die vom BuyerFrontendService seines Gebots- und Auktionsservers für von einem Verkäufer durchgeführte Auktionen aufgenommen und 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 der Ad-Tech-Anbieter des Verkäufers bei der Registrierung den Endpunkt angeben, von dem Protected Audience die Auktionskonfiguration des jeweiligen Verkäufers in regelmäßigen Abständen abrufen kann. Diese Konfiguration wird dann verwendet, um die Zusammensetzung und die Limits von adSelectionData zu bestimmen, die für jede getAdSelectionData-Anfrage generiert werden.

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

   Mit der Auktionskonfiguration für Verkäufer können Verkäufer Folgendes angeben:

   1. Liste der zulässigen Käufer: Bei Auktionen, die vom angegebenen Verkäufer initiiert werden, können nur die Käufer auf der Zulassungsliste benutzerdefinierte Zielgruppen für die Auktion beitragen. Die Auktionskonfiguration muss täglich aktualisiert werden, damit die Zulassungsliste mit der serverseitigen Käuferzulassungsliste übereinstimmt.
   2. Größenbeschränkung pro Käufer: Verkäufer können eine Beschränkung pro Käufer festlegen, um die Datengröße zu regulieren, die von jedem Käufer in die Nutzlast hochgeladen wird, die an SellerFrontendService gesendet wird. Wenn der Käufer das Größenlimit pro Käufer überschreitet, wird die in der Konfiguration der Käufer-Payload festgelegte CustomAudience-Priorität verwendet, um die Daten innerhalb der erwarteten Grenzwerte zu erhalten.
   3. Priorität pro Käufer: Verkäufer können die Priorität pro Käufer festlegen. Mit der Käuferpriorität wird festgelegt, welche Käuferdaten in der Nutzlast beibehalten werden sollen, wenn die Nutzlastgröße das Nutzlastgrößenlimit überschreitet.
   4. Maximales Größenlimit für die Nutzlast: Verschiedene Verkäufer haben möglicherweise unterschiedliche Ressourcenzuweisungen und möchten ein maximales Größenlimit für die Auktionsnutzlast pro Anfrage festlegen. Das maximale Größenlimit würde die von der Protected Audience API festgelegten Bucket-Größen berücksichtigen.

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. Das Feld priority wird verwendet, um benutzerdefinierte Zielgruppen zu identifizieren, die in eine Auktion aufgenommen werden sollen, wenn die Anzahl der benutzerdefinierten Zielgruppen des Käufers die Größenbeschränkungen 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. Weniger Daten in der Nutzlast senden: Wie in Nutzlastoptimierung für Gebots- und Auktionsdienste beschrieben, wird eine höhere Nutzlast durch benutzerdefinierte Zielgruppendaten ads, Nutzergebotsignale und Android-Signale verursacht. Höhere Nutzlasten können durch Folgendes reduziert werden:
      1. Der Client sendet Anzeigen-Render-IDs (anstelle von Anzeigenobjekten) in der Nutzlast.
      2. Der Client sendet keine Anzeigendaten in der Nutzlast.
      3. Keine Gebotssignale für Nutzer im Client-Payload senden.

Mit diesen Strategien können Ad-Tech-Unternehmen Konfigurationen definieren, um die Zusammensetzung und die Grenzwerte der adSelectionData-Nutzlast zu verwalten. Sie können aber auch die Größe von adSelectionData modulieren, indem sie Konfigurationsparameter ändern. Um dies zu vermeiden, wird die Konfiguration täglich von Protected Audience vom konfigurierten Endpunkt abgerufen.

Latenzoptimierung

Damit Serverauktionen ein wünschenswertes Maß an Nützlichkeit haben, müssen wir sicherstellen, dass die getAdSelectionData API und die persistAdSelectionResult API eine niedrige Latenz pro Aufruf haben. Wir möchten die Unterstützung von Funktionen für APIs im Jahr 2023 bereitstellen. Bei der nächsten Version werden wir uns jedoch auf Latenz-Benchmarks und Optimierungen für die APIs konzentrieren.

Wir untersuchen die folgenden Strategien, um die Latenz in einem akzeptablen Bereich zu halten:

1. Vorabgenerierung von Protected Audience-Daten pro Verkäufer: Da die Auktionskonfiguration des Verkäufers und die Nutzlastkonfiguration des Käufers über einen beträchtlichen Zeitraum (täglich) stabil sind, könnte die Plattform die infrage kommenden Protected Audience-Daten vorab berechnen und speichern.

   Dazu müsste die Plattform einen Mechanismus entwickeln, um Aktualisierungen benutzerdefinierter Zielgruppen zu überwachen und die vorab generierten Protected Audience-Daten entsprechend zu ändern. Die Plattform müsste auch SLOs für die Verzögerung angeben, die Ad-Tech-Unternehmen zwischen benutzerdefinierten Zielgruppenaktualisierungen und der Änderung des adSelectionData erwarten können, das für die Serverauktion generiert wird.

   Da ein Gerät ein eingeschränktes Ressourcenberechnungsmodell mit unterschiedlichen Prozessprioritäten bietet, ist uns bewusst, dass die Bereitstellung dieser Vorabgenerierungsfunktion mit hoher Zuverlässigkeit und SLO-Garantien einhergehen muss.

   Die Vorabgenerierung der Protected Audience-Daten würde dann auf folgenden Daten basieren:

   1. Verkäufer aktivieren die Vorabgenerierung von Protected Audience-Daten.
   2. Käufer, die berechtigt sind, an einer Auktion teilzunehmen, die von einem bestimmten Verkäufer initiiert wurde.
   3. Benutzerdefinierte Zielgruppen pro Käufer identifizieren, die basierend auf Folgendem Teil der Nutzlast wären:
      1. Größenbeschränkungen pro Käufer, Priorität pro Käufer und maximale Größenbeschränkungen, die in der Verkäuferkonfiguration definiert sind,
      2. Größenbeschränkung pro Verkäufer, Priorität der benutzerdefinierten Zielgruppe, die in der Käuferkonfiguration definiert ist.

2. Schnelle Anwendung von Negativfiltern: Wenn ein Verkäufer dies wünscht, kann die Plattform die adSelectionData vorab berechnen, indem sie Protected Audience-Daten vorab generiert und Negativfilter vor dem kritischen getAdSelectionData-Aufruf anwendet. So könnten Verkäufer die Latenz senken und gleichzeitig die Veraltung beim negativen Filtern in Kauf nehmen.

   Die Plattform könnte diese Unterstützung bieten, indem sie in der Verkäuferkonfiguration eine Standardoption mit einem Aktualitätslimit und in getAdSelectionData eine Überschreibungsoption bereitstellt, um bei Bedarf die aktuellste Berechnung zu ermöglichen. Alternativ könnte die Plattform eine zusätzliche Initialisierungs-API bereitstellen, die vor getAdSelectionData aufgerufen wird, um die Auktion vorzubereiten.

3. Nutzlastberechnung für mehrere Auktionen: In bestimmten Szenarien kann es vorzuziehen sein, eine latenzarme API zu verwenden, auch wenn die Daten dadurch veralteter sind. Dazu könnte die Plattform eine Initialisierungs-API einführen, um die gesamte Nutzlast zu berechnen und dem Aufrufer einen Verweis auf die berechnete Nutzlast zu geben.

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

Diese drei Strategien befinden sich in der ersten Explorationsphase und sollen die Richtung beschreiben, in die sich die Plattform entwickeln könnte, um die Latenz zu optimieren. Wir werden weiterhin zusätzliche Strategien vorschlagen, sobald wir detailliertere Latenzprofile der API und der Anforderungen an Anzeigentechnologie untersucht haben.

Minderung des Missbrauchsrisikos und Identifizierung von Missbrauch

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

Wenn jedoch alle Käuferdaten auf dem Gerät verwendet werden, um die adSelectionData-Ausgabe zu generieren, könnte sich eine böswillige Einheit als Käufer ausgeben und betrügerische Käuferdaten erstellen, um die Android-Leistung zu beeinträchtigen, die Nutzlast aufzublähen, um die Kosten für eine Ad-Tech-Firma für die Durchführung von Auktionen oder Geboten zu erhöhen usw.

Problembehebung

Einige Maßnahmen, die im Abschnitt zu Größenbeschränkungen erwähnt werden, z. B. die Konfiguration der Käufer-Payload mit autorisierten Verkäufern und die Konfiguration der Verkäuferauktion mit autorisierten Käufern, können dazu beitragen, unerwartete Daten in der Payload auszuschließen.

Andere Maßnahmen zur Berücksichtigung der Größe, z. B. die Möglichkeit für SSPs, die Käuferpriorität anzugeben, die Platzierung von Kontingenten pro Käufer in der generierten Nutzlast und die Festlegung einer maximalen Größe pro Auktionsnutzlast, können ebenfalls dazu beitragen, die Auswirkungen von böswilligen Nutzlasten zu verringern. Mit diesen Maßnahmen sollen Ad-Tech-Unternehmen festlegen können, mit welchen Ad-Tech-Unternehmen sie zusammenarbeiten, und akzeptable Grenzwerte für die Nutzlast festlegen, die sie verarbeiten müssen.

Wie bereits erwähnt, müssen alle Maßnahmen zur Missbrauchsbekämpfung und Größenbeschränkungen den Datenschutzbestimmungen entsprechen.

Identifizierung schädlicher Entitäten

Diese Maßnahmen schützen zwar die adSelectionData-Generierung für Serverauktionen, helfen aber nicht dabei, böswillige Unternehmen zu identifizieren oder die Plattform vor Missbrauch zu schützen, z. B. vor der Erstellung einer beispiellosen Anzahl von benutzerdefinierten Zielgruppen durch einen Käufer.

Um die Stabilität und Integrität der Plattform zu überprüfen, benötigen wir einen Mechanismus, mit dem wir schädliche Einheiten, Missbrauchsvektoren und die Motivation für die jeweiligen Angriffe identifizieren können. In späteren Versionen werden wir Erklärungen einführen, in denen die potenziellen Missbrauchsvektoren und die vorhandenen Schutzmaßnahmen beschrieben werden.