Diese Seite wurde von der Cloud Translation API übersetzt.

Integration und Optimierung von Gebots- und Auktionsdiensten

Das Entwurfsangebot Gebots- und Auktionsdienste für Android beschreibt die Ausführung und den Datenfluss von Auktionen unter Android mithilfe von Trusted Bidding und dem Auktionsserver. Damit Daten bei der Übertragung nur von datenschutzfreundlichen APIs und vertrauenswürdigen Servern verarbeitet werden, werden Daten zwischen dem Client und dem Server mithilfe der bidirektionalen Hybrid-Public-Key-Verschlüsselung verschlüsselt.

Illustration des Datenflusses der geschützten Zielgruppe. In drei Spalten wird dargestellt, wie Daten zwischen Geräten, nicht vertrauenswürdigen Verkäuferdiensten und einer vertrauenswürdigen Ausführungsumgebung verschoben werden. — Der Auktionsablauf von Protected Audience.

Um die Auktion wie zuvor beschrieben durchzuführen, muss der Anzeigentechnologie-Anbieter des Verkäufers auf dem Gerät folgende Schritte ausführen:

Daten für Serverauktionen erfassen und verschlüsseln
Anfrage an nicht vertrauenswürdigen Verkäuferdienst senden
Antwort von einem nicht vertrauenswürdigen Verkäuferdienst erhalten
Protected Audience-Auktionsantwort entschlüsseln und das Auktionsergebnis abrufen

Protected Audience führt zwei neue APIs ein, um die Ausführung von Serverauktionen zu unterstützen:

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 das Auktionsergebnis zurückzugeben.
AdTech-Clients auf dem Gerät können die persistAdSelectionResult API aufrufen, um das Ergebnis der Serverauktion zu entschlüsseln und die erfolgreiche Anzeigen-Rendering-URL abzurufen.

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

Daten für Serverauktionsverkäufe erfassen und verschlüsseln: Der Anzeigentechnologie-Anbieter sollte die getAdSelectionData API aufrufen, um die verschlüsselte Nutzlast abzurufen.
Anfrage an nicht vertrauenswürdigen Verkäuferdienst senden: Eine HTTP POST- oder PUT-Anfrage mit der verschlüsselten Nutzlast, die von der getAdSelectionData API an den nicht vertrauenswürdigen Verkäuferdienst des Verkäufers generiert wurde, sowie Daten, die vom nicht vertrauenswürdigen Verkäuferdienst zum Generieren von kontextbezogenen Ergebnissen benötigt werden.
Antwort vom nicht vertrauenswürdigen Verkäuferdienst erhalten: Die Antwort eines nicht vertrauenswürdigen Verkäuferdienstes enthält das Ergebnis der verschlüsselten Protected Audience-Auktion und das kontextbezogene Auktionsergebnis.
Auktionsantwort der geschützten Zielgruppe entschlüsseln und Auktionsergebnis abrufen:Zum Entschlüsseln des Ergebnisses der Protected Audience-Auktion sollte der Anzeigentechnologie-Verkäufer die persistAdSelectionResult API aufrufen. Anhand des von persistAdSelectionResult generierten Ergebnisses können Anzeigentechnologie-Anbieter feststellen, ob die kontextbezogene Anzeige oder Anzeige für geschützte Zielgruppen die Auktion gewonnen hat. Außerdem kann der URI der Anzeige für die erfolgreiche geschützte Zielgruppe angegeben werden.

Für Serverauktionen unterstützte Funktionen

Unser Ziel ist es, alle Funktionen zu unterstützen, die derzeit für On-Device-Auktionen verfügbar sind. Der Zeitplan für die Unterstützung dieser Funktionen in Serverauktionen sieht so aus:

	On-Device-Auktion		Serverauktion
	Entwicklervorschau	Beta	Entwicklervorschau	Beta
Berichte zu Gewinnen auf Ereignisebene	1. Quartal 2023	3. Quartal 2023	–	4. Quartal 2023
Vermittlung der Vermittlungsabfolge	1. Quartal 2023	4. Quartal 2023	–	Q1 24
Filterung nach Frequency Capping	2. Quartal 2023	3. Quartal 2023	–	4. Quartal 2023
Kontextbezogene Anzeigen zur Filterung an den Anzeigenauswahl-Workflow übergeben	2. Quartal 2023	1. Quartal 2024	–	–
Interaktionsberichte	2. Quartal 2023	3. Quartal 2023	–	4. Quartal 2023
An der benutzerdefinierten Zielgruppendelegierung teilnehmen	3. Quartal 2023	4. Quartal 2023	–	4. Quartal 2023
Abrechnung ohne CPM	3. Quartal 2023	4. Quartal 2023
Debugging- berichte	3. Quartal 2023	4. Quartal 2023	3. Quartal 2023	4. Quartal 2023
Vermittlung für Open Bidding	–	–	–	1. Quartal 2024
Filter für App-Installationsanzeigen	2. Quartal 2023	1. Quartal 2024	–	1. Quartal 2024
Währungsverwaltung	–	–	–	1. Quartal 2024
K-Anon-Integration	–	1. Quartal 2024	–	1. Quartal 2024
Einbindung der privaten Aggregation	–	–	–	3. Quartal 2024

Serverauktionen mit Protected Audience APIs ausführen

In der Entwicklervorschau bietet AdSelectionManager zwei neue APIs: getAdSelectionData und persistAdSelectionResult. Mit diesen APIs lassen sich AdTech-SDKs in Bidding- und Auktionsserver einbinden.

Daten für eine Serverauktion erfassen und verschlüsseln

Die getAdSelectionData API generiert die erforderlichen Eingaben für Gebots- und Auktionskomponenten wie BuyerInput und ProtectedAudienceInput und verschlüsselt die Daten, bevor das Ergebnis dem Aufrufer zur Verfügung gestellt wird. Um Datenlecks in Apps zu vermeiden, enthalten diese Daten Informationen von allen Käufern auf dem Gerät. Weitere Informationen zu dieser Entscheidung finden Sie im Abschnitt Überlegungen zum Datenschutz und Strategien zu ihrer Optimierung im Abschnitt Überlegungen zur Größe.

Für den Zugriff auf die API muss der Zugriff auf die Protected Audience API aktiviert sein und die Berechtigung ACCESS_ADSERVICES_CUSTOM_AUDIENCE muss im Manifest des Aufrufers definiert werden.

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

GetAdSelectionDataRequest

Der Aufrufer muss das Feld seller in der Anfrage festlegen, da es für Registrierungsprüfungen verwendet wird, bevor die Anfrage bearbeitet wird.

Das Feld coordinatorOriginUri ist optional.

Wenn dieser Wert festgelegt ist, 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.

Der Koordinator muss auf der Liste der genehmigten 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

Wenn kein Koordinatorursprung angegeben wird, wird der Standardkoordinator verwendet.
Auch wenn es höchst unwahrscheinlich ist, dass sich die URL des Koordinators ändert, wird dringend empfohlen, einen Mechanismus zur dynamischen Verwaltung dieser URL zu implementieren. Dadurch wird sichergestellt, dass künftige Änderungen an der URL berücksichtigt werden können, ohne dass eine neue SDK-Version erforderlich ist.

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

Nach der Überprüfung der Anfrage werden die On-Device-Käuferdaten in BuyerInput und ProtectedAudienceInput zusammengefasst. Das letzte Nutzlastobjekt wird dann mit bidirektionaler Hybrid-Key-Verschlüsselung verschlüsselt.

GetAdSelectionDataOutcome

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

adSelectionId: Eine opaque Ganzzahl zur Identifizierung dieses Aufrufs von getAdSelectionData. Der AdTech-Client sollte diesen adSelectionId-Wert beibehalten, da er als Verweis auf den getAdSelectionData-Aufruf fungiert. Diese Kennung wird von der persistAdSelectionResult API benötigt, um das Auktionsergebnis vom Gebots- und Auktionsserver zu entschlüsseln. Außerdem ist sie für die reportImpression und die reportEvent API erforderlich.
adSelectionData: Hierbei handelt es sich um die verschlüsselten Auktionsdaten, die für das Bidding und den Auktionsserver erforderlich sind, um Auktionen auszuführen. Diese Methode enthält Folgendes:
1. Gefilterte Daten zu benutzerdefinierten Zielgruppen basierend auf Frequency Capping, Filtern für App-Installationen und Serverauktionsvoraussetzungen für benutzerdefinierte Zielgruppen
2. In einer zukünftigen Version werden App-Installationsdaten enthalten sein.

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

Fehler, Ausnahmen und Fehlerbehandlung

Wenn die Generierung der Anzeigenauswahldaten aus Gründen wie ungültigen Argumenten, Zeitüberschreitungen oder übermäßigem Ressourcenverbrauch nicht erfolgreich abgeschlossen werden kann, liefert der OutcomeReceiver.onError()-Callback ein AdServicesException mit folgendem Verhalten:

Wenn getAdSelectionData mit ungültigen Argumenten initiiert wird, gibt AdServicesException eine Beendigungsmeldung als Ursache an.
Für alle anderen Fehler wird ein AdServicesException mit IllegalStateException als Ursache zurückgegeben.

Anfrage an einen nicht vertrauenswürdigen Verkäuferdienst senden

Mit AdSelectionData kann das SDK auf dem Gerät eine Anfrage an den Anzeigendienst seines Verkäufers senden. Dazu werden die Daten in eine POST- oder PUT-Anfrage aufgenommen:

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

Für die Codierung dieser Daten ist das On-Device-SDK verantwortlich. Es wird empfohlen, eine platzsparende Lösung zu verwenden, z. B. die Anfrage als Multipart-/Formulardaten an den Anzeigendienst des Verkäufers zu senden.

Antwort von einem nicht vertrauenswürdigen Verkäuferdienst erhalten

Wie in der Erläuterung zu Bidding und Auktionsserver beschrieben, sendet der nicht vertrauenswürdige Verkäuferdienst bei Eingang der Anfrage kontextbezogene Anzeigen an Partnerkäufer.

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

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

Der Dienst für nicht vertrauenswürdige Verkäufer 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 Anzeigentechnologie-Code des Verkäufers auf dem Gerät entscheiden, nur die kontextbezogene Anzeige in der Antwort zu verwenden. Wenn der Abruf des Protected Audience-Ergebnisses einen inkrementellen Wert hat, kann er das Protected Audience-Ergebnis durch Aufrufen der PersistAdSelectionResult API entschlüsseln.

PersistAdSelectionResult API

Zum Entschlüsseln des Protected Audience-Ergebnisses kann der Anzeigentechnologie-Anbieter für Verkäufer die zweite Protected Audience API-persistAdSelectionResult aufrufen. Die API entschlüsselt das Ergebnis und gibt ein AdSelectionOutcome zurück. Das ist dasselbe Objekt, das heute bereits von einer On-Device-Auktion zurückgegeben wurde.

Für den Zugriff auf die API 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);
}

adSelectionId: Die intransparente Kennung, die durch den getAdSelectionData-Aufruf generiert wird, dessen Ergebnis der Aufrufer entschlüsseln möchte.
seller: Die Anzeigentechnologie-ID des Verkäufers muss in der Anfrage festgelegt werden, damit Registrierungsprüfungen durchgeführt werden können, bevor die Anfrage bearbeitet wird.
adSelectionResult: Das verschlüsselte Auktionsergebnis, das vom Gebots- und Auktionsserver generiert und vom Aufrufer entschlüsselt werden soll.

AdSelectionResult-Antwort

Wenn es einen Protected Audience-Gewinner gibt, gibt AdSelectionOutcome den erfolgreichen Rendering-URI der Anzeige zurück.Nachdem adSelectionResult entschlüsselt wurde, werden die Berichtsdaten intern gespeichert. Der OutcomeReceiver.onResult()-Callback gibt einen AdSelectionOutcome-Wert zurück, der Folgendes enthält:

URI: Wenn es eine erfolgreiche Protected Audience-Anzeige gibt, wird eine Rendering-URL für die erfolgreiche Anzeige zurückgegeben. Wenn es keinen Protected Audience-Gewinner gibt, wird „Uri.EMPTY“ zurückgegeben.
adSelectionId: Die adSelectionId, die dieser Serverauktionsausführung zugeordnet sind.

Fehler, Ausnahmen und Fehlerbehandlung

Wenn getAdSelectionData mit ungültigen Argumenten initiiert wird, gibt AdServicesException einen IllegalArgumentException als Ursache an.
Für alle anderen Fehler wird ein AdServicesException mit IllegalStateException als Ursache zurückgegeben.

Überlegungen zum Datenschutz

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

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

Änderungen an CustomAudience-Daten auf dem Gerät vorhanden.
Änderungen an der Filterlogik für CustomAudience.
Ändert die Eingabe für den getAdSelectionData-Aufruf.

Die Änderung der adSelectionData-Größe kann zum Generieren einer anwendungsübergreifenden Kennung verwendet werden, wie in der Diskussion über 1-Bit-Datenlecks erwähnt. Viele Abhilfemaßnahmen für 1-Bit-Datenlecks treffen auch hier zu.

Um diese Speicherlecks zu beheben, planen wir, für alle Aufrufe der getAdSelectionData API denselben adSelectionData zu generieren. In ersten Releases werden alle CustomAudiences auf dem Gerät zum Erstellen von adSelectionData verwendet und die verschlüsselte Nutzlast wird auf Maskengrößenvariationen aufgefüllt. Außerdem begrenzen wir den Einfluss von GetAdSelectionData-Eingabeparametern auf die generierte adSelectionData.

Wenn jedoch für alle Anzeigentechnologie-Anbieter, die alle Auktionsdaten auf dem Gerät verwenden, dieselbe adSelectionData 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 zum Generieren von Auktionsnutzlast verwendet werden, wird das System außerdem für Missbrauch durch böswillige Entitäten geöffnet. Wir haben diese Bedenken in den Abschnitten Größenoptimierungen und Missbrauchsminderung unten behandelt.

Größenoptimierungen

Das AdTech-Client-SDK muss die verschlüsselten Byte von adSelectionData in den kontextbezogenen Aufruf HTTP PUT/POST an den AdTech-Server bündeln. Bei geringerer Umlaufzeit und zu geringeren Kosten muss die adSelectionData-Größe so weit wie möglich reduziert werden, ohne den Dienst zu beeinträchtigen.

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

In einem festen Satz von Bucket-Größen mit Auffüllung generierte Nutzlast: Um Datenlecks aus Größenvariationen zu minimieren und gleichzeitig weniger Nutzlasten zu erhalten, empfehlen wir, für die generierte Nutzlast ein Bucketing mit fester Größe zu verwenden. Wenn Sie die Anzahl der Buckets beispielsweise klein halten, führt dies zu weniger als 3 Bits an entgangenen Entropie pro Aufruf an getAdSelectionData.

Wenn Gerätedaten die maximale Bucket-Größe überschreiten, wird anhand der unten beschriebenen Strategien wie Prioritätswerte entschieden, welche Daten gelöscht werden.
Käuferkonfiguration: Wir prüfen, ob es möglich ist, Käufern die Möglichkeit zu geben, eine Nutzlastkonfiguration pro Käufer einzurichten. So lässt sich ermitteln, an welchen Auktionen ein Käufer teilnehmen möchte. Sofern möglich, könnte ein Käufer-Anzeigentechnologie bei der Registrierung einen Endpunkt registrieren, von dem Protected Audience täglich regelmäßig die Nutzlastkonfiguration abruft. Alternativ wird in datenschutzfreundlichen APIs eine API zur Verfügung gestellt, damit Anzeigentechnologie-Anbieter für Käufer 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.

Bei der Konfiguration der Nutzlast des Käufers können Käufer Folgendes angeben:
1. Liste der zulässigen Verkäufer: Benutzerdefinierte Zielgruppen des Käufers werden der Nutzlast nur dann hinzugefügt, wenn der Aufruf getAdSelectionData von einem Verkäufer auf der Zulassungsliste initiiert wird. Die Nutzlastkonfiguration wird täglich abgerufen, um die Zulassungsliste auf dem neuesten Stand zu halten.
2. Größenlimit 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. Dies ist nützlich, wenn ein Käufer mehr Ressourcen für die Verarbeitung von Auktionsdaten von bestimmten Verkäufern zur Verfügung stellen möchte. Der SellerFrontendService leitet nur käuferspezifische Daten an die einzelnen BuyerFrontendService weiter. Durch die Definition einer Größenbeschränkung pro Verkäufer kann ein Käufer die Datenmenge, die vom BuyerFrontendService seines Gebots- und Auktionsservers aufgenommen und verarbeitet wird, für Auktionen, die von einem Verkäufer durchgeführt werden, explizit steuern.
Verkäuferkonfiguration: Wir prüfen derzeit, ob eine Auktionskonfiguration pro Verkäufer möglich ist, mit der Verkäufer Auktionsparameter definieren können, um die Nutzlastgröße und Auktionsteilnehmer zu steuern. Wenn möglich, könnte die Anzeigentechnologie des Verkäufers bei der Registrierung den Endpunkt angeben, von dem Protected Audience aus in regelmäßigen Abständen die Auktionskonfiguration pro Verkäufer 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önnen Verkäufer bei einer Konfiguration pro Verkäufer angeben, welche Gruppe von Käufern sie in einer Auktion erwarten. Außerdem können sie den Beitrag des Käufers zur Nutzlastgröße begrenzen.

In der Konfiguration für die Verkäuferauktion könnten Verkäufer Folgendes angeben:
1. Liste der zulässigen Käufer: Bei Auktionen, die vom angegebenen Verkäufer initiiert wurden, 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 Zulassungsliste für Käufer immer auf dem neuesten Stand ist.
2. Größenlimit pro Käufer: Verkäufer können ein Limit pro Käufer angeben, um die Datengröße zu regulieren, die von jedem Käufer in die Nutzlast hochgeladen wird, die an den SellerFrontendService gesendet wird. Wenn der Käufer die Größenbeschränkung pro Käufer überschreitet, wird die in der Nutzlastkonfiguration festgelegte Priorität für die benutzerdefinierte Zielgruppe verwendet, um die Daten innerhalb der erwarteten Limits 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 Limit für die Nutzlast ü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 Nutzlast der Auktion pro Anfrage festlegen. Das maximale Größenlimit berücksichtigt die Buckets mit fester Größe, die von der Protected Audience API festgelegt wurden.
Änderungen an benutzerdefinierten Zielgruppen
1. Priorität der benutzerdefinierten Zielgruppe festlegen: Sie können Käufern erlauben, in einer benutzerdefinierten Zielgruppe einen Prioritätswert anzugeben. Mit dem Feld priority werden benutzerdefinierte Zielgruppen ermittelt, die in eine Auktion einbezogen werden sollten, wenn die benutzerdefinierten Zielgruppen des Käufers die Größenbeschränkungen pro Verkäufer oder Käufer überschreiten. Ein nicht angegebener Prioritätswert in einer benutzerdefinierten Zielgruppe wird standardmäßig auf 0.0 festgelegt.
Änderungen der Nutzlastdaten
1. In der Nutzlast gesendete Daten reduzieren: Wie unter Nutzlastoptimierung für Gebots- und Auktionsdienste beschrieben, wird eine höhere Nutzlast durch ads-Daten zu benutzerdefinierten Zielgruppen, Gebotssignalen von Nutzern und Android-Signalen verursacht. Höhere Nutzlasten können auf folgende Weise verringert werden:
  1. Der Client muss Anzeigen-Rendering-IDs (anstelle von Anzeigenobjekten) in der Nutzlast senden.
  2. Der Client sendet keine Anzeigendaten in der Nutzlast.
  3. Es werden keine Gebotssignale von Nutzern in der Clientnutzlast gesendet.

Die oben erwähnten Strategien ermöglichen es Anzeigentechnologien, Konfigurationen zu definieren, um die Zusammensetzung und Limits der adSelectionData-Nutzlast zu verwalten. Sie könnten aber auch zu einem Faktor für die Modulation der Größe von adSelectionData werden, indem sie Konfigurationsparameter ändern. Um dies zu vermeiden, wird die Konfiguration täglich von Protected Audience vom konfigurierten Endpunkt abgerufen.

Latenzoptimierung

Damit Serverauktionen den gewünschten Nutzen haben, müssen die getAdSelectionData API und die persistAdSelectionResult API eine niedrige Latenz pro Aufruf haben. Wir möchten API-Funktionen 2023 unterstützen. Die nachfolgende Version konzentriert sich jedoch auf Latenz-Benchmarks und Optimierungen für die APIs.

Wir untersuchen die folgenden Strategien, um die Latenz innerhalb akzeptabler Limits zu halten:

Vorabgenerierung von Protected Audience-Daten pro Verkäufer: Da die Konfiguration der Verkäuferauktionen und die Konfiguration der Käufernutzlast für eine gewisse Zeit (täglich) stabil sind, könnte die Plattform die entsprechenden Protected Audience-Daten vorab berechnen und speichern.

Dazu müsste die Plattform einen Mechanismus entwickeln, um benutzerdefinierte Zielgruppenaktualisierungen zu überwachen und die vorab generierten Protected Audience-Daten entsprechend zu ändern. Außerdem müsste die Plattform SLOs für die Race Delay-AdTech deklarieren, die zwischen den benutzerdefinierten Zielgruppenaktualisierungen und der Änderung des für die Serverauktion generierten adSelectionDatas zu erwarten ist.

Da ein Gerät ein begrenztes Berechnungsmodell für Ressourcen mit unterschiedlichen Prozessprioritäten bietet, sind wir uns bewusst, dass die Bereitstellung dieser Einrichtung vor der Generierung eine hohe Zuverlässigkeit und SLOs-Garantien beinhalten muss.

Die Vorgenerierung der Protected Audience-Daten würde dann auf
1. Der Verkäufer muss vorab generierte Protected Audience-Daten aktivieren.
2. Käufer, die an einer Auktion teilnehmen dürfen, die von einem bestimmten Verkäufer initiiert wurde
3. Benutzerdefinierte Zielgruppen pro Käufer identifizieren, die Teil der Nutzlast wären, basierend auf:
  1. Größenbeschränkungen pro Käufer, Priorität pro Käufer und maximale Größe in der Verkäuferkonfiguration
  2. Größenbeschränkung pro Verkäufer, benutzerdefinierte Zielgruppenpriorität, definiert in der Käuferkonfiguration
Eifrige Anwendung von Negativfiltern: Wenn ein Verkäufer dies bevorzugt, könnte die Plattform die adSelectionData vorab berechnen. Dazu werden Protected Audience-Daten vorab generiert und der kritische getAdSelectionData-Aufruf negativ gefiltert. Auf diese Weise können Verkäufer die niedrigere Latenz ausgleichen und gleichzeitig veraltete Negativfilter akzeptieren.

Die Plattform könnte diese Unterstützung bieten, indem sie in der Verkäuferkonfiguration eine Standardoption mit einem Limit für die Veralterung und eine Überschreibungsoption in getAdSelectionData bereitstellt, um bei Bedarf aktuelle Berechnungen zu ermöglichen. Alternativ könnte die Plattform eine zusätzliche Initialisierungs-API bereitstellen, die vor getAdSelectionData zum Aufwärmen der Auktion aufgerufen werden kann.
Nutzlastberechnung für mehrere Auktionen: In bestimmten Szenarien ist es unter Umständen besser, eine latenzleistungsfähige API zu verwenden, allerdings auf Kosten der Datenveralterung. Zu diesem Zweck könnte die Plattform eine Initialisierungs-API einführen, um die gesamte Nutzlast zu berechnen und dem Aufrufer eine Referenz zur berechneten Nutzlast bereitzustellen.

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

Alle drei oben erwähnten Strategien befinden sich in der anfänglichen Erkundungsphase und geben an, in welche Richtung die Plattform gehen könnte, um die Latenz zu optimieren. Im Zuge der Untersuchung detaillierterer Latenzprofile der API- und Anzeigentechnologie-Anforderungen werden wir weitere Strategien vorschlagen.

Minderung und Identifizierung von Missbrauch

Wie unter „Datenschutz“ erwähnt, werden adSelectionData mithilfe aller Käuferdaten auf dem Gerät generiert.

Wenn jedoch alle Käuferdaten auf dem Gerät zum Generieren der adSelectionData-Ausgabe verwendet werden, könnte sich eine böswillige Entität als Käufer ausgeben und betrügerische Käuferdaten erstellen, um die Android-Leistung zu beeinträchtigen, Nutzlasten aufzublähen, um die Kosten für ein AdTech-Unternehmen zum Ausführen von Auktionen oder Geboten usw. zu erhöhen.

Risikominderung

Einige im Abschnitt „Überlegungen zur Größe“ erwähnte Messwerte, z. B. die Konfiguration der Käufernutzlast mit Verkäufern auf der Zulassungsliste und die Konfiguration von Verkäuferauktionen mit Käufern auf der Zulassungsliste, könnten helfen, unerwartete Daten in der Nutzlast auszuschließen.

Andere Maßnahmen zur Größenanpassung, z. B. das Festlegen der Käuferpriorität für SSPs, das Einteilen des Käuferkontingents in die generierte Nutzlast und das Festlegen einer maximalen Größe pro Auktionsnutzlast können ebenfalls dazu beitragen, die Auswirkungen einer aufgeblähten schädlichen Nutzlast zu verringern. Mit diesen Maßnahmen können Anzeigentechnologie-Anbieter definieren, mit welchen Anzeigentechnologien sie zusammenarbeiten, und akzeptable Grenzen für die zu verarbeitende Nutzlast festlegen.

Wie bereits erwähnt, müssen bei allen Maßnahmen zur Vermeidung von Missbrauch und Größenbeschränkungen Datenschutzaspekte berücksichtigt werden.

Identifizierung schädlicher Entitäten

Die oben erwähnten Maßnahmen schützen zwar die adSelectionData-Generation für Serverauktionen, helfen aber nicht, schädliche Entitäten zu identifizieren oder die Plattform vor Missbrauch wie der Erstellung einer noch nie dagewesenen Anzahl von benutzerdefinierten Zielgruppen von einem Käufer zu schützen.

Um die Stabilität und Integrität der Plattform sicherzustellen, müssen wir einen Mechanismus finden, um schädliche Entitäten zu identifizieren, Missbrauchsvektoren zu identifizieren und die Gründe für die jeweiligen Angriffe zu ermitteln. In späteren Versionen werden Erklärvideos eingeführt, in denen die möglichen Missbrauchsvektoren und -schutzmaßnahmen beschrieben werden, um ihnen entgegenzuwirken.