Diese Seite wurde von der Cloud Translation API übersetzt.

Integration und Optimierung von Gebots- und Auktionsdiensten

Im Entwurfsvorschlag Gebots- und Auktionsdienste für Android werden die Ausführung und der Datenfluss der laufenden Auktionen unter Android über den vertrauenswürdigen Gebots- und Auktionsserver beschrieben. Damit Daten während der Übertragung nur von datenschutzfreundlichen APIs und vertrauenswürdigen Servern verarbeitet werden, werden Daten zwischen dem Client und dem Server mit der bidirektionalen Hybrid-Public-Key-Verschlüsselung verschlüsselt.

Abbildung des Ablaufs für geschützte Zielgruppen 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 bei Protected Audience.

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

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

Protected Audience führt zwei neue APIs ein, um das Ausführen 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 nutzt diese Nutzlast, um eine Auktion auszuführen, das Auktionsergebnis zu generieren und das Auktionsergebnis zurückzugeben.
AdTech-Clients auf dem Gerät können die persistAdSelectionResult API aufrufen, um das von der Serverauktion generierte Ergebnis zu entschlüsseln und die erfolgreiche Anzeigen-Rendering-URL zu erhalten.

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

Daten für die Serverauktion für Verkäufer erfassen und verschlüsseln: Die Anzeigentechnologie-Anbieter sollten die getAdSelectionData API aufrufen, um die verschlüsselte Nutzlast zu erhalten.
Anfrage an nicht vertrauenswürdigen Verkäuferdienst senden: Eine HTTP POST- oder PUT-Anfrage mit der verschlüsselten Nutzlast, die von der getAdSelectionData API generiert wurde, an den nicht vertrauenswürdigen Verkäuferdienst 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 verschlüsselte Ergebnis der geschützten Zielgruppenauktion und das kontextbezogene Auktionsergebnis.
Auktionsantwort für geschützte Zielgruppe entschlüsseln und das Auktionsergebnis abrufen:Zum Entschlüsseln des Auktionsergebnisses der geschützten Zielgruppe muss der Verkäufer die persistAdSelectionResult API aufrufen. Anhand des von persistAdSelectionResult generierten Ergebnisses können AdTech-Teams feststellen, ob die kontextbezogene Anzeige oder die geschützte Zielgruppe die Auktion gewonnen hat. Außerdem wird gegebenenfalls der URI der gewinnenden geschützten Zielgruppe ermittelt.

Unterstützte Funktionen für Serverauktionen

Unser Ziel ist es, alle Funktionen zu unterstützen, die derzeit für On-Device-Auktionen verfügbar sind. Für die Unterstützung dieser Funktionen bei Serverauktionen gilt folgende Frist:

	On-Device-Auktion		Serverauktion
	Entwicklervorschau	Beta	Entwicklervorschau	Beta
Gewinnberichte auf Ereignisebene	1. Quartal 2023	3. Quartal 2023	–	4. Quartal 2023
Abfolgebasierte Vermittlung	1. Quartal 2023	4. Quartal 2023	–	Q1 24
Frequency Capping-Filterung	2. Quartal 2023	3. Quartal 2023	–	4. Quartal 2023
Kontextbezogene Anzeigen zum Filtern an den Workflow für die Anzeigenauswahl übergeben	2. Quartal 2023	1. Quartal 2024	–	–
Interaktionsberichte	2. Quartal 2023	3. Quartal 2023	–	4. Quartal 2023
Delegierung für benutzerdefinierte Zielgruppen einrichten	3. Quartal 2023	4. Quartal 2023	–	4. Quartal 2023
Abrechnung ohne CPM	3. Quartal 2023	4. Quartal 2023
Berichterstellung Fehler beheben	3. Quartal 2023	4. Quartal 2023	3. Quartal 2023	4. Quartal 2023
Open Bidding-Vermittlung	–	–	–	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 privater Aggregation	–	–	–	3. Quartal 2024

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 die Gebots- und Auktionsserver eingebunden werden.

Daten für eine Serverauktion erheben 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 den 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 und im Abschnitt Überlegungen zur Größe die Strategien, um diesen zu optimieren.

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

Der Aufrufer muss das Feld seller in der Anfrage festlegen, da es zum Ausführen von Registrierungsprüfungen verwendet wird, bevor die Anfrage bereitgestellt wird.

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

Nachdem die Anfrage geprüft wurde, werden die Käuferdaten auf dem Gerät in BuyerInput und ProtectedAudienceInput zusammengefasst. Das letzte Nutzlastobjekt wird dann mit der bidirektionalen Hybridverschlüsselung mit öffentlichem Schlüssel verschlüsselt.

GetAdSelectionDataOutcome

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

adSelectionId: Eine opake Ganzzahl, um diesen Aufruf von getAdSelectionData zu identifizieren. 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, und wird auch für die reportImpression API und reportEvent API benötigt.
adSelectionData: Das sind die verschlüsselten Auktionsdaten, die für den Gebots- und Auktionsserver erforderlich sind, um Auktionen durchzuführen. Diese Methode enthält:
1. Gefilterte Daten zu benutzerdefinierten Zielgruppen basierend auf Frequency Capping, App-Installationsfiltern und den Anforderungen an Serverauktionen für benutzerdefinierte Zielgruppen.
2. In einer zukünftigen Version wird sie App-Installationsdaten enthalten.

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

Fehler, Ausnahmen und Fehlerbehandlung

Wenn die Daten zur Anzeigenauswahl aufgrund von ungültigen Argumenten, Zeitüberschreitungen oder einem übermäßigen Ressourcenverbrauch nicht erfolgreich generiert werden können, gibt der OutcomeReceiver.onError()-Callback ein AdServicesException mit folgendem Verhalten zurück:

Wenn getAdSelectionData mit ungültigen Argumenten eingeleitet wird, gibt AdServicesException eine = Ausnahme als Ursache an.
Bei allen anderen Fehlern wird ein AdServicesException mit IllegalStateException als Ursache zurückgegeben.

Anfrage an nicht vertrauenswürdigen Verkäuferdienst senden

Mit AdSelectionData kann das SDK auf dem Gerät eine Anfrage an den Anzeigendienst 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 SDK auf dem Gerät ist für die Codierung dieser Daten verantwortlich. Wir empfehlen, eine platzsparende Lösung zu verwenden, z. B. das Senden der Anfrage in Form von „multipart-data“ oder „form-data“ an den Anzeigendienst des Verkäufers.

Antwort von einem nicht vertrauenswürdigen Verkäuferdienst erhalten

Wie in der Erläuterung zu Gebots- und Auktionsservern beschrieben, werden Aufrufe von kontextbezogenen Anzeigen an Partnerkäufer gesendet, wenn der nicht vertrauenswürdige Verkäuferdienst die Anfrage erhält.

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

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 nicht vertrauenswürdige Verkäuferdienst sendet eine Antwort an das Gerät, die eine kontextabhängige Anzeige und / oder ein verschlüsseltes Ergebnis der Protected Audience-Auktion enthält.

Nach Erhalt der Antwort kann der AdTech-Code des Verkäufers festlegen, dass nur die kontextbezogene Anzeige in der Antwort verwendet wird. Wenn er feststellt, dass das Protected Audience-Ergebnis einen inkrementellen Wert bietet, kann er das Protected Audience-Ergebnis durch Aufrufen der PersistAdSelectionResult API entschlüsseln.

PersistAdSelectionResult API

Zum Entschlüsseln des Protected Audience-Ergebnisses kann der AdTech-Verkäufer die zweite Protected Audience API-persistAdSelectionResult aufrufen. Die API entschlüsselt das Ergebnis und gibt ein AdSelectionOutcome zurück. Dabei handelt es sich um dasselbe Objekt, das heute von einer On-Device-Auktion zurückgegeben wird.

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 vom Aufruf getAdSelectionData generiert wird, dessen Ergebnis der Aufrufer entschlüsseln möchte.
seller: Die AdTech-ID des Verkäufers muss in der Anfrage festgelegt werden, um vor der Bereitstellung der Anfrage Registrierungsprüfungen durchzuführen.
adSelectionResult: Das vom Gebots- und Auktionsserver generierte verschlüsselte Auktionsergebnis, das der Aufrufer entschlüsseln möchte.

AdSelectionResult-Antwort

Wenn es einen Gewinner der Protected Audience-Zielgruppe gibt, gibt AdSelectionOutcome den URI des erfolgreichen Anzeigen-Renderings zurück.Nach der Entschlüsselung von adSelectionResult werden die Berichtsdaten intern gespeichert. Der OutcomeReceiver.onResult()-Callback gibt ein AdSelectionOutcome zurück, das Folgendes enthält:

URI: Bei einer Protected Audience-Anzeige, die erfolgreich ist, wird eine URL zum Rendern der Anzeige für die erfolgreiche Anzeige zurückgegeben. Wenn es keinen Gewinner der Protected Audience API gibt, wird „Uri.EMPTY“ zurückgegeben.
adSelectionId: Die adSelectionId, die dieser Serverauktionsausführung zugeordnet ist.

Fehler, Ausnahmen und Fehlerbehandlung

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

Überlegungen zum Datenschutz

adSelectionData wird 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 bei CustomAudience-Daten auf dem Gerät vorhanden.
Änderungen an der Filterlogik für CustomAudience.
Ändert die Eingabe in den getAdSelectionData-Aufruf.

Eine Änderung der adSelectionData-Größe kann zum Generieren einer App-übergreifenden ID verwendet werden, wie in der Diskussion zu 1-Bit-Leaks beschrieben. Viele Risikominderungen für 1-Bit-Leaks sind hier ebenfalls anwendbar.

Um diese Datenlecks zu beheben, möchten wir für alle Aufrufe der getAdSelectionData API dieselbe adSelectionData generieren. In ersten Releases werden alle CustomAudiences auf dem Gerät zum Erstellen von adSelectionData verwendet und die verschlüsselte Nutzlast wird mit Variationen der Maskengröße aufgefüllt. Außerdem schränken wir den Einfluss der GetAdSelectionData-Eingabeparameter auf die generierten adSelectionData ein.

Wenn Sie jedoch dieselbe adSelectionData für alle Anzeigentechnologie-Anbieter mit allen Auktionsdaten auf dem Gerät generieren, 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, ist außerdem Missbrauch durch böswillige Entitäten möglich. Weitere Informationen hierzu finden Sie in den Abschnitten Größenoptimierungen und Missbrauchsminderung.

Größenoptimierungen

Das Ad Tech-Client-SDK muss die verschlüsselten Byte von adSelectionData in den Kontext-HTTP PUT/POST-Aufruf verpacken, der an den Ad Tech-Server gesendet wird. Damit die Umlaufzeitlatenz und die Kosten geringer sind, ist es erforderlich, die adSelectionData-Größe so weit wie möglich zu reduzieren, ohne den Nutzen zu beeinträchtigen.

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

Nutzlast, die in einem festen Satz von Bucket-Größen mit Padding generiert wurde: Um das Datenleck durch Größenvariationen zu minimieren und gleichzeitig weniger Nutzlasten zu ermöglichen, empfehlen wir, für die generierte Nutzlast ein Bucketing mit fester Größe zu verwenden. Eine kleine Anzahl von Buckets, zum Beispiel bei 7, führt zu weniger als 3 Bit an Entropie pro Aufruf von getAdSelectionData.

Wenn die On-Device-Daten die maximale Bucket-Größe überschreiten, wird anhand der unten aufgeführten Strategien wie Prioritätswerte entschieden, welche Daten verworfen werden.
Käuferkonfiguration: Wir prüfen die Durchführbarkeit, ob Käufer eine Nutzlastkonfiguration pro Käufer einrichten können. Diese Konfiguration ist nützlich, um zu ermitteln, an welchen Auktionen ein Käufer teilnehmen möchte. Sofern möglich, könnte ein AdTech-Käufer während der Registrierung einen Endpunkt registrieren, von dem Protected Audience die Nutzlastkonfiguration täglich regelmäßig abruft. Alternativ stellen datenschutzfreundliche APIs eine API bereit, über die Anzeigentechnologie-Käufer diesen Endpunkt registrieren können.

Mit dieser Konfiguration wird dann der Beitrag eines Käufers zu adSelectionData bewertet, der für jede getAdSelectionData-Anfrage generiert wird.

In der Konfiguration der Nutzlast des Käufers können Käufer Folgendes angeben:
1. Liste der zugelassenen Verkäufer: Benutzerdefinierte Zielgruppen von Käufern werden nur dann der Nutzlast hinzugefügt, wenn der getAdSelectionData-Aufruf 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ößenbeschränkung pro Verkäufer: Der Käufer kann eine Größenbeschränkung pro Verkäufer festlegen, um die Datengröße festzulegen, die mit der Nutzlast gesendet wird, 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 verwenden möchte. Mit dem SellerFrontendService werden nur käuferspezifische Daten an jeden BuyerFrontendService weitergeleitet. Durch die Definition einer Größenbeschränkung pro Verkäufer kann ein Käufer also explizit steuern, welche Datenmenge über den BuyerFrontendService seines Gebots- und Auktionsservers für Auktionen eines Verkäufers aufgenommen und verarbeitet wird.
Verkäuferkonfiguration: Wir prüfen derzeit die Durchführbarkeit einer Auktionskonfiguration pro Verkäufer, mit der Verkäufer Auktionsparameter zur Steuerung der Nutzlastgröße und Auktionsteilnehmer definieren können. Sofern möglich, kann der Verkäufer bei der Registrierung den Endpunkt angeben, von dem Protected Audience die Auktionskonfiguration pro Verkäufer in regelmäßigen Abständen abrufen könnte. Mit dieser Konfiguration werden dann die Zusammensetzung und die Limits von adSelectionData ermittelt, 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 sehen werden. Außerdem können sie Limits für den Beitrag der einzelnen Käufer zur Nutzlastgröße festlegen.

In der Konfiguration für die Auktion von Verkäufern können Verkäufer Folgendes angeben:
1. Liste der zugelassenen Käufer: Bei Auktionen, die vom jeweiligen Verkäufer initiiert wurden, können nur Käufer auf der Zulassungsliste benutzerdefinierte Zielgruppen zur Auktion hinzufügen. Die Auktionskonfiguration muss täglich aktualisiert werden, um die Zulassungsliste mit der Zulassungsliste für serverseitige Käufer auf dem neuesten Stand zu halten.
2. Größenbeschränkung pro Käufer: Verkäufer können ein Limit pro Käufer angeben, um die von jedem Käufer in die an den SellerFrontendService gesendete Nutzlast hochgeladene Datengröße zu regulieren. Überschreitet der Käufer das Größenlimit pro Käufer, wird die in der Nutzlastkonfiguration des Käufers festgelegte Priorität „CustomAudience“ verwendet, um die Daten im Rahmen der erwarteten Limits abzurufen.
3. Priorität pro Käufer: Verkäufer dürfen Prioritäten für einzelne Käufer festlegen. Mit der Käuferpriorität wird festgelegt, welche Käuferdaten in der Nutzlast beibehalten werden sollen, wenn die Nutzlastgröße die maximal zulässige Größe überschreitet.
4. Maximalgrößenlimit für die Nutzlast: Verschiedene Verkäufer haben möglicherweise unterschiedliche Ressourcenzuweisung und möchten ein maximales Größenlimit für die Auktionsnutzlast auf Anfrage festlegen. Das maximale Größenlimit bezieht sich auf die Buckets mit fester Größe, die von der Protected Audience API festgelegt wurden.
Änderungen bei benutzerdefinierten Zielgruppen
1. Priorität für benutzerdefinierte Zielgruppe festlegen: Käufer können in einer benutzerdefinierten Zielgruppe einen Prioritätswert angeben. Im Feld priority werden benutzerdefinierte Zielgruppen identifiziert, die in eine Auktion einbezogen werden sollen, wenn die Anzahl der benutzerdefinierten Zielgruppen des Käufers die Größenbeschränkungen pro Verkäufer oder pro Käufer überschreitet. Ein nicht angegebener Prioritätswert in einer benutzerdefinierten Zielgruppe würde standardmäßig auf 0.0 gesetzt werden.
Änderungen an Nutzlastdaten
1. In der Nutzlast gesendete Daten reduzieren: Wie unter Nutzlast von Gebots- und Auktionsdiensten beschrieben, wird eine höhere Nutzlast durch benutzerdefinierte Zielgruppendaten ads, Gebotssignale von Nutzern und Android-Signale gesteuert. Höhere Nutzlasten können durch folgende Werte gesenkt werden:
  1. Wenn der Client Anzeigen-Rendering-IDs (anstelle von Anzeigenobjekten) in der Nutzlast sendet.
  2. Wenn der Client keine Anzeigendaten in der Nutzlast sendet
  3. Es werden keine Gebotssignale für Nutzer in der Clientnutzlast gesendet.

Mit den oben genannten Strategien können Anzeigentechnologie-Anbieter Konfigurationen definieren, um die Zusammensetzung und Limits der adSelectionData-Nutzlast zu verwalten. Sie könnten aber auch durch eine Änderung der Konfigurationsparameter zu einem Faktor zur Modulation der adSelectionData-Größe werden. Um dies zu vermeiden, wird die Konfiguration täglich von Protected Audience vom konfigurierten Endpunkt abgerufen.

Latenzoptimierung

Damit Serverauktionen den gewünschten Nutzen erzielen, müssen die getAdSelectionData API und die persistAdSelectionResult API eine niedrige Latenz pro Aufruf haben. Unser Ziel ist es, die Unterstützung von Funktionen für APIs 2023 zu ermöglichen. In der nachfolgenden Version geht es jedoch um Latenz-Benchmarks und -Optimierungen für die APIs.

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

Vorgenerierung von Protected Audience-Daten pro Verkäufer: Da die Konfiguration der Auktionen und die Nutzlast des Käufers für einen erheblichen Zeitraum (täglich) stabil bleibt, könnte die Plattform die infrage kommenden Protected Audience-Daten vorab berechnen und speichern.

Dazu muss die Plattform einen Mechanismus erstellen, um benutzerdefinierte Zielgruppenaktualisierungen zu überwachen und die vorab generierten Protected Audience-Daten auf der Grundlage der Aktualisierungen zu ändern. Außerdem müsste die Plattform SLOs für die Race-Verzögerung von AdTech deklarieren, die zwischen Aktualisierungen benutzerdefinierter Zielgruppen und der Änderung der für die Serverauktion generierten adSelectionData-Werte zu erwarten ist.

Da ein Gerät ein Berechnungsmodell mit begrenzten Ressourcen und unterschiedlichen Prozessprioritäten bereitstellt, sind wir uns bewusst, dass die Bereitstellung dieser Vorgenerierungseinrichtung mit hoher Zuverlässigkeit und SLO-Garantien verbunden sein muss.

Die Vorgenerierung der Protected Audience-Daten basiert dann auf
1. Der Verkäufer muss zustimmen, Protected Audience-Daten vorab zu generieren.
2. Käufer können an einer Auktion teilnehmen, die von einem bestimmten Verkäufer initiiert wird.
3. Benutzerdefinierte Zielgruppen pro Käufer identifizieren, die Teil der Nutzlast sind, basierend auf folgenden Faktoren:
  1. Größenbeschränkungen pro Käufer, Priorität pro Käufer und maximale Größe, definiert in der Verkäuferkonfiguration
  2. Größenbeschränkung pro Verkäufer und Priorität für benutzerdefinierte Zielgruppen, definiert in der Käuferkonfiguration.
Ehrgeizige Anwendung von Negativfilter: Auf Wunsch eines Verkäufers kann die Plattform adSelectionData vorab berechnen, indem Protected Audience-Daten vorab generiert und der kritische getAdSelectionData-Aufruf negativ gefiltert wird. So können Verkäufer die niedrigere Latenz ausgleichen, während sie beim negativen Filtern Veralterung 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 eine aktuelle Berechnung zu ermöglichen. Alternativ kann die Plattform eine zusätzliche Initialisierungs-API bereitstellen, die vor getAdSelectionData aufgerufen wird, um die Auktion aufzuwärmen.
Nutzlastberechnung für mehrere Auktionen: In bestimmten Szenarien bietet es sich an, eine latenzleistungsstarke API zu verwenden, allerdings auf Kosten einer erhöhten Veralterung der Daten. Zu diesem Zweck könnte die Plattform eine Initialisierungs-API einführen, um die gesamte Nutzlast zu berechnen, und dem Aufrufer einen Verweis auf die berechnete Nutzlast bereitstellen.

Für nachfolgende Aufrufe von getAdSelectionData könnte 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 anfänglichen Untersuchungsphase. Sie beschreiben die Richtung, in die die Plattform zur Optimierung der Latenz einschlagen könnte. Im Zuge der Untersuchung detaillierter Latenzprofile der API- und AdTech-Anforderungen werden wir weitere Strategien vorschlagen.

Missbrauchsbekämpfung und Identifizierung

Wie im Abschnitt zum Datenschutz erwähnt, wird 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 schädliche Entität als Käufer ausgeben und betrügerische Käuferdaten erstellen, um die Android-Leistung zu beeinträchtigen, Nutzlasten zu bloßen, um die Kosten für Auktionen oder Gebote zu erhöhen, und so weiter.

Risikominderung

Einige Messungen, die im Abschnitt „Größenüberlegungen“ erwähnt werden, wie die Nutzlastkonfiguration des Käufers, die Verkäufer auf der Zulassungsliste enthält, und die Auktionskonfiguration für Verkäufer, die Käufer auf der Zulassungsliste enthalten, helfen dabei, unerwartete Daten in der Nutzlast auszuschließen.

Andere Maßnahmen zur Größenbewältigung können ebenfalls dazu beitragen, dass SSPs die Käuferpriorität angeben, ein Kontingent pro Käufer in die generierte Nutzlast aufnehmen und eine maximale Größe pro Auktionsnutzlast festlegen. Diese Maßnahmen sollen es AdTech-Teams ermöglichen, zu definieren, mit welchen Anzeigentechnologien sie zusammenarbeiten, und akzeptable Grenzwerte für die Nutzlast festzulegen, die sie verarbeiten müssen.

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

Identifizierung schädlicher Entitäten

Die oben genannten Risikominderungen schützen zwar die Generation adSelectionData für Serverauktionen, helfen aber nicht dabei, schädliche Entitäten zu identifizieren oder die Plattform vor Missbrauch wie dem Erstellen einer nie dagewesenen Anzahl von benutzerdefinierten Zielgruppen durch einen Käufer zu schützen.

Um die Stabilität und Integrität der Plattform zu gewährleisten, müssen wir einen Mechanismus finden, mit dem schädliche Entitäten identifiziert, Missbrauchsvektoren identifiziert und die Gründe für die jeweiligen Angriffe ermittelt werden können. In späteren Versionen werden wir Erklärungen einführen, in denen die potenziellen Missbrauchsvektoren und Schutzmaßnahmen beschrieben sind, um ihnen entgegenzuwirken.