Integration und Optimierung von Gebots- und Auktionsdiensten

Der Entwurfsvorschlag Gebots- und Auktionsdienste für Android enthält Details zum Durchführung und Datenfluss von Auktionen auf Android-Geräten mithilfe von Trusted Bidding und Auktionsserver. Um sicherzustellen, dass Daten bei der Übertragung nur von datenschutzfreundlichen APIs und vertrauenswürdigen Servern werden die Daten zwischen den Client und Server mit einem bidirektionalen öffentlichen Hybridschlüssel Verschlüsselung.

</ph>

Um die Auktion wie zuvor beschrieben durchzuführen, muss die Anzeigentechnologie des Verkäufers auf dem Gerät führen Sie die folgenden Schritte aus:

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

Protected Audience führt zwei neue APIs ein, um Serverauktionen:

1. Die getAdSelectionData API erfasst Daten für die Serverauktion und eine verschlüsselte Nutzlast mit Auktionsdaten. Die Gebots- und Der Auktionsserver verwendet diese Nutzlast, um eine Auktion durchzuführen, die Auktion zu generieren. und gibt das Auktionsergebnis zurück.
2. AdTech-Kunden auf dem Gerät können die persistAdSelectionResult API aufrufen, um Das Ergebnis der Serverauktion entschlüsseln und die erfolgreiche Anzeige abrufen Rendering-URL.

Die Anzeigentechnologie des Verkäufers auf dem Gerät muss Folgendes integriert und erstellt werden, eine Auktion durchführen:

1. Daten für Serverauktionen erfassen und verschlüsseln: Der Anzeigentechnologie-Anbieter sollte getAdSelectionData API aufrufen, um die verschlüsselte Nutzlast abzurufen.
2. Anfrage an nicht vertrauenswürdigen Verkäuferdienst senden: HTTP POST oder PUT Anfrage mit der von getAdSelectionData generierten verschlüsselten Nutzlast API auf ihren nicht vertrauenswürdigen Verkäuferdienst und Daten, die von den nicht vertrauenswürdigen um kontextbezogene Ergebnisse zu generieren.
3. Antwort von einem nicht vertrauenswürdigen Verkäuferdienst erhalten: Antwort von nicht vertrauenswürdigen Verkäufern des Verkäuferdienstes das verschlüsselte Ergebnis der Protected Audience-Auktion enthalten würde. und das kontextbezogene Auktionsergebnis.
4. Entschlüsseln Sie die Antwort einer Protected Audience-Auktion und rufen Sie das Auktionsergebnis ab: Um das Ergebnis der Protected Audience-Auktion zu entschlüsseln, sollte der AdTech-Verkäufer einen Aufruf die persistAdSelectionResult API. Das von Mit persistAdSelectionResult können Anzeigentechnologie-Anbieter ermitteln, Anzeige oder Protected Audience-Anzeige hat die Auktion gewonnen und den URI der erfolgreichen Anzeige. eine Protected Audience-Anzeige.

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. Die Zeitplan für die Unterstützung dieser Funktionen in Serverauktionen:

Serverauktionen mit Protected Audience APIs ausführen

In der Entwicklervorschau bietet AdSelectionManager zwei neue APIs: getAdSelectionData und persistAdSelectionResult. Diese APIs ermöglichen Anzeigentechnologie SDKs, die in Bidding- und Auktionsserver integriert werden können.

Daten für eine Serverauktion erfassen und verschlüsseln

Die getAdSelectionData API generiert die erforderlichen Eingaben für Bidding und Auktionskomponenten wie BuyerInput und ProtectedAudienceInput und verschlüsselt die Daten, bevor sie das Ergebnis, das dem Aufrufer zur Verfügung steht. Um Datenlecks in Apps zu vermeiden, Die Daten enthalten Informationen von allen auf dem Gerät vorhandenen Käufern. Weitere Informationen zu im Abschnitt Überlegungen zum Datenschutz und Strategien zur können Sie dies im Bereich Überlegungen zur Größe optimieren.

Für den Zugriff auf die API muss der Zugriff auf die Protected Audience API aktiviert sein und die Die Berechtigung ACCESS_ADSERVICES_CUSTOM_AUDIENCE muss in der das Manifest des Aufrufers.

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 für die Ausführung verwendet wird bevor Sie die Anfrage bearbeiten.
2. Das Feld coordinatorOriginUri ist optional.
   1. Wenn dieser Wert festgelegt ist, sollte er dem Schema, dem Hostnamen und dem Port der die während des Bereitstellung des B&A-Servers des Verkäufers.
   2. 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

   3. Wenn kein Koordinatorursprung angegeben wird, wird der Standardkoordinator verwendet.
   4. 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 On-Device-Käuferdaten in BuyerInput und ProtectedAudienceInput. Das letzte Nutzlastobjekt wird dann mit bidirektionaler Hybrid-Public-Key-Verschlüsselung verschlüsselt.

GetAdSelectionDataResult

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

1. adSelectionId: eine opaque Ganzzahl zur Identifizierung Aufruf von getAdSelectionData. Der AdTech-Kunde sollte diese adSelectionId-Wert, da er als Zeiger auf den Anruf in getAdSelectionData. Diese Kennung wird für das persistAdSelectionResult API zum Entschlüsseln des Auktionsergebnisses von Bidding und Auktionsserver. Außerdem ist sie für reportImpression und reportEvent APIs
2. adSelectionData: Dies sind die verschlüsselten Auktionsdaten, die für Gebote und den Auktionsserver erforderlich sind. Diese Methode enthält: <ph type="x-smartling-placeholder">
   </ph>
   1. Daten zu benutzerdefinierten Zielgruppen basierend auf Frequency Capping und App-Installationen gefiltert Filter und Serverauktionsanforderungen 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 Daten zur Anzeigenauswahl aufgrund wie ungültige Argumente, Zeitüberschreitungen oder übermäßiger Ressourcenverbrauch. liefert der OutcomeReceiver.onError()-Callback ein AdServicesException mit folgende Verhaltensweisen:

1. Wenn getAdSelectionData mit ungültigen Argumenten initiiert wird, AdServicesException gibt eine Lieblingsausnahme wegen Ausnahmeregelung als Ursache an.
2. Alle anderen Fehler erhalten ein AdServicesException mit einem IllegalStateException als Ursache.

Anfrage an einen nicht vertrauenswürdigen Verkäuferdienst senden

Mit AdSelectionData kann das On-Device-SDK eine Anfrage an das Anzeigendienst durch Einfügen der Daten in eine POST- oder PUT-Anfrage:

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 wie das Senden der Anfrage an die Anzeige des Verkäufers Dienst als multipart/form-data.

Antwort von einem nicht vertrauenswürdigen Verkäuferdienst erhalten

Wie in der Erläuterung zu Geboten und Auktionsserver beschrieben, gilt Folgendes: erhält der nicht vertrauenswürdige Verkäuferdienst die Anfrage, sendet er Aufrufe an den Partner für kontextbezogene Anzeigen.

Der Dienst für nicht vertrauenswürdige Verkäufer leitet die verschlüsselten adSelectionData- und AuctionConfig an den SellerFrontEnd-Dienst des Gebots- und Auktionsservers in einem T-Shirt laufen.

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

Der Dienst für nicht vertrauenswürdige Verkäufer sendet eine Antwort an das Gerät, auf dem kontextbezogene Anzeige und / oder verschlüsseltes Ergebnis der Protected Audience-Auktion.

Nach Erhalt der Antwort konnte der AdTech-Code des Verkäufers auf dem Gerät entscheiden, die kontextbezogene Anzeige nur in der Antwort verwenden oder wenn sie der Meinung ist, den zusätzlichen Wert beim Abrufen des Protected Audience-Ergebnisses erzielen, Entschlüsseln Sie das Protected Audience-Ergebnis durch Aufrufen der PersistAdSelectionResult der API erstellen.

PersistAdSelectionResult API

Zur Entschlüsselung des Protected Audience-Ergebnisses kann der Anzeigentechnologie-Anbieter für Verkäufer die zweite Protected Audience API persistAdSelectionResult. Die API entschlüsselt das Ergebnis. und gibt ein AdSelectionOutcome zurück. Dies ist dasselbe Objekt, das von einer On-Device-Auktion ab.

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 ihrem 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 von getAdSelectionData generierte intransparente Kennung -Aufrufs, dessen Ergebnis der Aufrufer entschlüsseln möchte.
2. seller: Die Anzeigentechnologie-ID des Verkäufers muss in der Anfrage festgelegt werden, damit die Anfrage ausgeführt werden kann. bevor Sie die Anfrage bearbeiten.
3. adSelectionResult: Das verschlüsselte Auktionsergebnis, das von Bidding generiert wurde und Auktionsserver, den der Anrufer entschlüsseln möchte.

AdSelectionResult-Antwort

Wenn es einen Protected Audience-Gewinner gibt, gibt AdSelectionOutcome den Wert Rendering-URI der erfolgreichen Anzeige.Nach der Entschlüsselung der adSelectionResult werden die werden intern aufbewahrt. Der OutcomeReceiver.onResult()-Callback gibt Ein AdSelectionOutcome, das Folgendes enthält:

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

Fehler, Ausnahmen und Fehlerbehandlung

Wenn die Generierung der Daten zur Anzeigenauswahl aufgrund wie ungültige Argumente, Zeitüberschreitungen oder übermäßiger Ressourcenverbrauch. liefert der OutcomeReceiver.onError()-Callback ein AdServicesException mit folgende Verhaltensweisen:

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

Überlegungen zum Datenschutz

adSelectionData ist verschlüsselt, damit nur Daten bei der Übertragung zugänglich sind zu PPAPI und den vertrauenswürdigen Servern.

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

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

Mit der Größenänderung adSelectionData kann eine App-übergreifende App generiert werden wie in der Diskussion zu 1-Bit-Datenlecks erwähnt. Viele Abhilfemaßnahmen für 1-Bit-Datenlecks gelten auch hier.

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

Die gleiche adSelectionData für alle Anzeigentechnologie-Anbieter generieren, On-Device-Auktionsdaten generieren eine große Nutzlast, die jetzt übertragen werden muss. bei jedem Aufruf an den AdTech-Server. Mit allen benutzerdefinierten Zielgruppen auf dem Gerät und das Generieren von Auktionsnutzlast, Entitäten. Diese Bedenken wurden in den Artikeln Größenoptimierungen und Missbrauchsminderung unten.

Größenoptimierungen

Das AdTech-Client-SDK soll die verschlüsselten Byte der adSelectionData in den kontextbezogenen Aufruf von HTTP PUT/POST an die Anzeigentechnologie Server. Zur Senkung der Umlaufzeit und der Kosten muss adSelectionData so groß wie möglich sein, ohne den Dienst zu beeinträchtigen.

Wir planen, die folgenden Optimierungen im Veröffentlichungen verfügbar, um die Größe von adSelectionData zu reduzieren:

1. In einem festen Satz von Bucket-Größen mit Padding generierte Nutzlast: das Auslaufen von Größenvariationen zu minimieren und gleichzeitig die verwenden, empfehlen wir, für die generierte Nutzlast ein Bucketing mit fester Größe zu verwenden. Eine kleine Anzahl von Buckets, z. B. 7, 3 Bits gestohlene Entropie pro Aufruf an getAdSelectionData.

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

2. Käuferkonfiguration: Wir prüfen, ob es Käufern möglich ist, Konfiguration der Nutzlast auf Käuferbasis einrichten. Diese Konfiguration wäre nützlich um zu ermitteln, an welchen Auktionen ein Käufer interessiert ist. Wenn möglich, sollten Sie kann ein Käufer bei der Registrierung einen Endpunkt registrieren, von dem aus Protected Audience ruft die Nutzlastkonfiguration jeden Tag ab Ihre Kadenz. Alternativ können datenschutzfreundliche APIs eine API bereitstellen, AdTechs eines Käufers, diesen Endpunkt zu registrieren.

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

   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 dem nur dann Nutzlast, wenn der getAdSelectionData-Aufruf von einem Verkäufer initiiert wird. auf die Zulassungsliste setzen. Wir würden die Nutzlastkonfiguration täglich 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 wird, wenn eine Auktion von einem bestimmten Verkäufer initiiert wurde. Das ist nützlich, wenn ein Käufer mehr Ressourcen für die Verarbeitung der Auktionsdaten bestimmter Verkäufer bereitstellen. Der SellerFrontendService leitet nur käuferspezifische Daten an die beiden BuyerFrontendService ein. Durch die Definition einer Größenbeschränkung pro Verkäufer die Menge an Daten, die von einem des Gebots- und Auktionsservers den BuyerFrontendService für Auktionen durch einen Verkäufer.

3. Verkäuferkonfiguration: Wir prüfen, ob eine pro Verkäufer Auktionskonfiguration, mit der Verkäufer Auktionsparameter definieren können um die Größe der Nutzlast und die Auktionsteilnehmer zu steuern. Wenn möglich, sollten Sie kann der AdTech-Verkäufer den Endpunkt der bei dem Protected Audience die Auktionskonfiguration pro Verkäufer abrufen kann, in regelmäßigen Abständen. Diese Konfiguration würde dann verwendet, um die Zusammensetzung und Limits von adSelectionData generiert pro getAdSelectionData-Anfrage.

   Ähnlich wie bei der Käuferkonfiguration könnte bei einer Konfiguration für einzelne Verkäufer können Verkäufer angeben, welche Käufer sie in einer Auktion erwarten. um Limits für den Beitrag eines Käufers zur Nutzlastgröße festzulegen.

   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 die Käufer auf der Zulassungsliste „CustomAudiences“ beitragen, für die Auktion ausgewählt haben. Die Auktionskonfiguration muss aktualisiert werden. täglich, um die Zulassungsliste mit der serverseitigen Zulassungsliste für Käufer auf dem neuesten Stand zu halten.
   2. Größenbeschränkung pro Käufer: Verkäufer können pro Käufer ein Limit festlegen auf die von jedem Käufer in die zu ladende Nutzlast hochgeladen werden, an den SellerFrontendService gesendet wird. Wenn der Käufer die Größe pro Käufer überschreitet die in der Konfiguration der Nutzlast des Käufers festgelegte Priorität der benutzerdefinierten Zielgruppe, 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. Käufer Mit der Priorität wird festgelegt, welche Käuferdaten zur Nutzlast hinzu, wenn die Größe der Nutzlast das Limit für die Nutzlast überschreitet.
   4. Maximale Größe für die Nutzlast: Verschiedene Verkäufer haben möglicherweise unterschiedlichen Ressourcenzuweisungen zugewiesen werden. Vielleicht möchten Sie eine maximale Größe der Auktionsnutzlast auf Anfrage. Die maximale Größe würde die Gruppen mit fester Größe, die über die Protected Audience API festgelegt wurden.

4. Änderungen an benutzerdefinierten Zielgruppen

   1. Priorität der benutzerdefinierten Zielgruppe festlegen: Käufer können eine Priorität angeben. in einer benutzerdefinierten Zielgruppe. Das Feld priority dient für Folgendes: benutzerdefinierte Zielgruppen identifizieren, die in eine Auktion einbezogen werden sollten, wenn das der benutzerdefinierten Zielgruppen des Käufers übersteigt die Größe pro Verkäufer oder Käufer Beschränkungen. Ein nicht angegebener Prioritätswert in einer benutzerdefinierten Zielgruppe wäre die Standardeinstellung. an 0.0.

5. Änderungen der Nutzlastdaten

   1. In der Nutzlast gesendete Daten reduzieren: Weitere Informationen dazu finden Sie unter Gebote und Auktionen Optimierung der Dienstnutzlast, höhere Nutzlast nach benutzerdefinierten ads-Daten, Gebotssignalen von Nutzern und Android-Signalen. Höhere Nutzlasten könnten wie folgt reduziert werden: <ph type="x-smartling-placeholder">
      </ph>
      1. Wenn der Client Anzeigen-Rendering-IDs (anstelle von Anzeigenobjekten) an die Payload.
      2. Der Client sendet keine Anzeigendaten in der Nutzlast.
      3. Es werden keine Gebotssignale von Nutzern in der Clientnutzlast gesendet.

Während die oben erwähnten Strategien es Anzeigentechnologien ermöglichen, Konfigurationen zu definieren, Zusammensetzung und Limits der adSelectionData-Nutzlast verwalten, könnten sie auch einen Faktor für die Modulation der adSelectionData-Größe durch Ändern der Konfiguration Parameter. Um dies zu vermeiden, wird die Konfiguration täglich Zielgruppe vom konfigurierten Endpunkt.

Latenzoptimierung

Damit Serverauktionen einen sinnvollen Nutzen haben, müssen wir sicherstellen, getAdSelectionData API und persistAdSelectionResult API haben eine niedrige Latenz pro aufrufen. 2023 möchten wir APIs unterstützen. konzentriert sich auf Latenz-Benchmarks und Optimierungen für die APIs.

Wir erwägen die folgenden Strategien, um die Latenz innerhalb akzeptabler Limits:

1. Protected Audience-Daten pro Verkäufer vor dem Generieren: seit Verkäufer sind die Auktionskonfiguration und die Konfiguration der Käufernutzlast noch beträchtlicher Dauer (täglich) haben, könnte die Plattform geeignete Protected Audience-Daten.

   Dafür müsste die Plattform einen Mechanismus zur Überwachung benutzerdefinierter aktualisiert und die zuvor generierten Protected Audience-Daten basierend auf zu den Aktualisierungen. Die Plattform müsste außerdem SLOs im Rennen deklarieren. Verzögerung zwischen der Aktualisierung der benutzerdefinierten Zielgruppe und der Änderung von adSelectionData, die für die Serverauktion generiert wurden.

   Da ein Gerät ein Rechenmodell mit begrenzter Ressourcen hat, haben wir erkannt, dass die Bereitstellung dieser Anlage zur Vorgenerierung der müssen mit hoher Zuverlässigkeit und SLOs garantiert werden.

   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 können, die von einem bestimmten Verkäufer.
   3. Benutzerdefinierte Zielgruppen pro Käufer zu identifizieren, die Teil des Nutzlast basierend auf: <ph type="x-smartling-placeholder">
      </ph>
      1. Größenbeschränkungen pro Käufer, Priorität pro Käufer und maximale Größe die in der Verkäuferkonfiguration definiert sind,
      2. Größenbeschränkung pro Verkäufer, benutzerdefinierte Zielgruppenpriorität, definiert beim Käufer Konfiguration.

2. Eifrige Anwendung von Negativfiltern: Falls der Verkäufer dies bevorzugt, konnte die Plattform den adSelectionData vorab berechnen, indem sie um Protected Audience-Daten zu schützen, und wenden negative Filter getAdSelectionData-Anruf. So können Verkäufer eine Senkung bei der negativen Filterung eine Veralterung berücksichtigt.

   Die Plattform könnte diese Unterstützung bieten, indem sie eine Standardoption im Verkäuferkonfiguration mit einem Limit für die Veralterung und einer Überschreibungsoption in getAdSelectionData, um bei Bedarf die neueste Berechnung zu ermöglichen. Alternativ könnte die Plattform eine zusätzliche Initialisierungs-API bereitstellen wird vor dem getAdSelectionData zum Aufwärmen der Auktion aufgerufen.

3. Berechnung der Nutzlast für mehrere Auktionen: In bestimmten Szenarien eine latenzfähige API auf Kosten von dass die Daten alternativ sind. Zu diesem Zweck könnte die Plattform eine Initialisierungs-API verwendet, um die gesamte Nutzlast zu berechnen und eine Referenz zu an den Aufrufer übergeben.

   Bei nachfolgenden getAdSelectionData-Aufrufen könnte der Aufrufer Folgendes angeben: Verweis auf die vorab berechnete Nutzlast, die für adSelectionData verwendet werden soll Generation.

Alle drei oben genannten Strategien befinden sich in der ersten Erkundungsphase und beschreibt, in welche Richtung die Plattform optimiert werden könnte. Latenz. Wenn wir uns ausführlichere Latenzprofile der API und der Anzeigentechnologie ansehen, zu erfüllen, werden wir weitere Strategien vorschlagen.

Minderung und Identifizierung von Missbrauch

Wie unter datenschutzrechtlichen Bestimmungen erwähnt, wird adSelectionData mithilfe von alle Käuferdaten auf dem Gerät.

Werden jedoch alle Käuferdaten auf dem Gerät verwendet, adSelectionData-Ausgabe angezeigt, kann sich eine böswillige Entität als Käufer ausgeben betrügerische Käuferdaten erstellen, um die Android-Leistung zu beeinträchtigen, Die Kosten für eine Anzeigentechnologie für Auktionen oder Gebote erhöhen usw.

Risikominderung

Einige Messwerte, die im Abschnitt zu Größenaspekten erwähnt werden, z. B. die Nutzlast des Käufers Konfiguration mit Verkäufern auf der Zulassungsliste und Konfiguration für Verkäuferauktionen mit Käufern auf der Zulassungsliste lassen sich unerwartete Daten Payload.

Andere Maßnahmen zur Größenüberlegung, z. B. das Festlegen von Käufern durch SSPs Priorität, das Einordnen des Käuferkontingents in die generierte Nutzlast und das Festlegen eines maximalen kann die Größe pro Auktionsnutzlast helfen, aufgebläht. AdTechs sollen mithilfe dieser Maßnahmen definieren können, welche mit denen sie zusammenarbeiten, und legen akzeptable Grenzwerte für die Nutzlast fest, verarbeitet werden müssen.

Wie bereits erwähnt, wurden alle Maßnahmen zur Bekämpfung von Missbrauch und zur Größenordnung müssen Datenschutzaspekte berücksichtigt werden.

Identifizierung schädlicher Entitäten

Die oben erwähnten Maßnahmen schützen die Generation adSelectionData Server-Auktionen verwenden, helfen sie nicht bei der Identifizierung schädlicher Entitäten oder zum Schutz der die Plattform vor Missbrauch wie die Erstellung einer noch nie dagewesenen Anzahl von von einem Käufer.

Damit die Stabilität und Integrität der Plattform gewährleistet werden können, müssen wir einen Mechanismus finden, um Missbrauchsvektoren zu identifizieren und die Motivation für die spezifischen Angriffe. In späteren Versionen führen wir Erklärvideos eine detaillierte Beschreibung der potenziellen Missbrauchsvektoren und Schutzmaßnahmen, die ihnen entgegenwirken.