Weitere Informationen zu den Auktionsfunktionen der Protected Audience API
Wir arbeiten daran, die Funktionen der Protected Audience API allgemein verfügbar zu machen. Vielleicht fragen Sie sich, wann die Protected Audience API-Dienste und -Funktionen verfügbar sein werden. Hier finden Sie eine Liste der Funktionen der Protected Audience API mit Angabe des Zeitpunkts, zu dem sie unterstützt werden.
Zeitachse der Verfügbarkeit von Funktionen
Funktion | Verfügbar für Tests | Status |
---|---|---|
Berichte zu gewonnenen Auktionen auf Ereignisebene | Jetzt | Bis mindestens 2026 unterstützt. Mit dieser Funktion soll der Übergang von Drittanbieter-Cookie-Berichten zu Berichten der Protected Audience API erleichtert werden. Diese Berichte werden daher nicht mehr unterstützt, sobald Anbieter von Anzeigentechnologien Zeit hatten, ihre Meldemechanismen zu aktualisieren. |
Triggerbasierte Aggregation | Jetzt | Verfügbar zum Testen in Chrome Canary/Dev M113 und höher sowie in Chrome Beta/Stable M115 und höher. |
Verwendung einer Vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) für den Schlüssel/Wert-Dienst | Jetzt | Ab dem 3. Quartal 2025 erforderlich. |
Umgrenzte Frames | Jetzt | Frühestens 2026 erforderlich. |
Verbesserte Einbindung der Protected Audience API und der Attribution Reporting API | 2. Quartal 2023 | Verfügbar für Tests in Chrome Stable M112 und höher. |
K-Anonymität | Jetzt | Artikel zur K-Anonymität |
Gebots- und Auktionsdienste | Geplanter Testzeitraum: 2. Halbjahr 2023. | In Entwicklung. |
Zusätzliche Funktionen
Funktion | Verfügbar für Tests | Status |
---|---|---|
Gebotshinweise für Nutzer auf Ereignisebene für die Modellierung (GitHub-Problem) | 2023 | Im 2. Quartal 2023 in Chrome verfügbar. |
Berichte zur Latenz nach Käufer | 2023 | Im 1. Quartal 2023 in Chrome verfügbar. |
Zeitlimit für die Echtzeit pro Käufer | 2023 | Im 1. Quartal 2023 in Chrome verfügbar. |
Berichts-ID des Käufers für benutzerdefinierte Aufschlüsselungen | 2023 | Verfügbar in Chrome im 3. Quartal 2023. |
Unterstützung für direkte Verkäuferziele | 2023 | Im 1. Quartal 2023 in Chrome verfügbar. |
Anzeigekosten mit eingeschränkter Genauigkeit bei der Abrechnung nach Cost-per-Click | 2023 | Im 2. Quartal 2023 in Chrome verfügbar. |
Währung für das höchste Gebot und das Gebot mit der höchsten anderen Bewertung | 2023 | Verfügbar in Chrome im 3. Quartal 2023. |
Makrounterstützung für Drittanbieter-Anzeigen-Tracker (3PAT) | 2023 | Verfügbar in Chrome im 3. Quartal 2023. |
Unterstützung für ausschließendes Targeting auf Interessengruppen | Ende 2023 | Voraussichtlich im 4. Quartal 2023 in Chrome verfügbar. |
Sichere Weiterleitung von Auktionssignalen ohne Webbundles Github-Problem |
Ende 2023 | Voraussichtlich im 4. Quartal 2023 in Chrome |
Bulk-Löschen von Interessengruppen GitHub-Problem |
Ende 2023 | Voraussichtlich im 4. Quartal 2023 in Chrome |
Obergrenze für Interessengruppen von 1.000 auf 2.000 erhöht GitHub-Problem |
Ende 2023 | Voraussichtlich im 4. Quartal 2023 in Chrome |
Unterstützung für Gebote und Auktionen – Beta 1 Erläuterung |
Origin-Test, Ende 2023 | Voraussichtlich im 4. Quartal 2023 in Chrome (über Ursprungstest) |
Real Time Monitoring API Erläuterung |
Ende des 2. Quartals oder Anfang des 3. Quartals 2024 | Voraussichtlich in Chrome Ende des 2. Quartals oder Anfang des 3. Quartals 2024 Wir prüfen auch Verbesserungen, die in der Erläuterung für zukünftige Arbeiten aufgeführt sind. Wir planen, die Richtung bis zum 1. Quartal 2025 festzulegen und erwarten, bis zum 1. Quartal 2026 eine überarbeitete Lösung zu präsentieren, abhängig von den Einführungszeitplänen der zugrunde liegenden Technologien. |
Berichte zu gewonnenen Auktionen auf Ereignisebene
Wir hatten ursprünglich angegeben, dass die Berichte zu Geboten auf Ereignisebene eine vorübergehende Lösung sind. Für die Erstellung von Zusammenfassungsberichten wird die Private Aggregation API verwendet. Nachdem wir uns das Feedback angehört und die relative Komplexität von aggregationsbasierten Lösungen, insbesondere für die Abrechnung, untersucht haben, haben wir uns entschieden, die Unterstützung für Berichte zu Auktionsgewinnen auf Ereignisebene mit reportResult()
- und reportWin()
-Funktionen, die sendReportTo()
aufrufen können, nicht einzustellen.
Berichte zu Auktionsgewinnen auf Ereignisebene werden bis mindestens 2026 unterstützt. Wir informieren Sie rechtzeitig, bevor die API auf alternative Lösungen umgestellt wird.
Berichte zu Auktionsverlusten werden weiterhin über die Private Aggregation API unterstützt.
Triggerbasierte zusammengefasste Berichte
Während einer Protected Audience-Auktion können Sie einen aggregierbaren Bericht senden, wenn er durch ein Ereignis ausgelöst wird. Verwenden Sie dazu die Methode contributeToHistogramOnEvent()
der Private Aggregation API. Das auslösende Ereignis kann von der Auktion selbst stammen, z. B. ein Gewinn oder Verlust. Diese aggregierbaren Berichte werden dann an einen bereitgestellten Aggregationsdienst gesendet, mit dem Sie einen abschließenden Zusammenfassungsbericht mit Ergebnissen zu Auktionsverlusten erstellen können. Das Ereignis kann auch von einem eingegrenzten Frame außerhalb der Auktion stammen. Verwenden Sie dazu die window.fenced.reportEvent()
der Fenced Frame Ads Reporting API, um die Einreichung aggregierbarer Berichte auszulösen.
Weitere Informationen finden Sie im Abschnitt contributeToHistogramOnEvent()
der Seite „Private Aggregation“.
Verwendung einer vertrauenswürdigen Ausführungsumgebung für den Schlüssel/Wert-Dienst
Mit dem Schlüssel/Wert-Dienst der Protected Audience API können in der Auktion Echtzeitsignale abgerufen werden, wenn das Gebot vom Käufer generiert und die Anzeige vom Verkäufer bewertet wird. Der Schlüssel/Wert-Dienst muss in einer Trusted Execution Environment (TEE) ausgeführt werden, um die Daten der Nutzer zu schützen.
Es ist nicht erforderlich, den Schlüssel/Wert-Dienst in einem TEE auszuführen. Wir informieren Sie mindestens 12 Monate vor der Einführung der Pflicht zur Verwendung von TEEs. Bis dahin können Sie Ihren eigenen Server für Echtzeit-Schlüssel/Wert-Signale verwenden. Der Key/Value-Dienst kann bis Ende des ersten Quartals 2023 mit der On-Device Protected Audience API in einem TEE mit benutzerdefinierten Funktionen (UDFs) getestet werden.
Fenced Frames
Umzäunte Frames sind ein neues HTML-Element, das die Kommunikation zwischen den Inhalten und dem Einbettungscode einschränkt. Es wird zum Rendern von Inhalten auf der Grundlage von websiteübergreifenden Daten verwendet. Die Protected Audience API rendert Inhalte in einem abgegrenzten Frame.
Nachdem wir eng mit verschiedenen Stakeholdern zusammengearbeitet und die erheblichen Anstrengungen zur Umsetzung dieser Änderung geprüft haben, werden in Chrome erst ab mindestens 2026 abgegrenzte Frames zur Verfügung gestellt,um die Inklusion des gesamten Systems zu gewährleisten. Chrome wird dies rechtzeitig ankündigen. Bis dahin musst du, wenn du keine eingezäunten Frames verwendest, einen iFrame verwenden, um die nicht transparente URN zu rendern. Beachten Sie außerdem, dass Verkäufer weiterhin die Verwendung von abgegrenzten Frames verlangen können.
Vorschlag | Status |
---|---|
Änderungen an der Web API für urn to config Erläuterung |
Im 1. Quartal 2023 in Chrome verfügbar. |
Creative-Makros in Fenced Frames for Ads Reporting (FFAR) GitHub-Problem |
Ab dem 3. Quartal 2023 in Chrome verfügbar. |
Automatische Beacons einmal senden GitHub-Problem |
Verfügbar im 3. Quartal 2023 in Chrome. |
Serialisierbare Fenced Frames-Konfigurationen GitHub-Problem |
Verfügbar im 3. Quartal 2023 in Chrome. |
Zusätzliche Formatoption für Makros für Anzeigengrößen für geschützte Zielgruppen GitHub-Problem |
Verfügbar im 4. Quartal 2023 in Chrome. |
Automatische Beacons, die an alle registrierten URLs senden GitHub-Problem | GitHub-Problem |
Verfügbar im 4. Quartal 2023 in Chrome. |
Verlassen von Anzeigeninteressengruppen aus Urn-iFrames und Frames von Anzeigenkomponenten aktivieren
GitHub-Problem |
Ab dem 1. Quartal 2024 in Chrome verfügbar |
Einführung von „reserviert.top_navigation_start/commit“
GitHub-Problem, GitHub-Problem |
Im 1. Quartal 2024 in Chrome verfügbar |
Cookie-Einstellung in ReportEvent erst nach 3PCD deaktivieren
GitHub-Problem |
Im 1. Quartal 2024 in Chrome verfügbar |
Unterstützung für automatische Beacons in plattformübergreifenden Subframes hinzufügen
GitHub-Problem |
Im 1. Quartal 2024 in Chrome verfügbar |
Cross-Origin-Subframes zulassen, reportEvent() -Beacons zu senden
GitHub-Problem |
Im 2. Quartal 2024 in Chrome verfügbar |
Verbesserte Integration der Protected Audience API und Attribution Reporting
Vor Kurzem wurden Herausforderungen bei der Einbindung der Attribution Reporting API und der Protected Audience API beschrieben, insbesondere bei eingezäunten Frames.
Für Berichte auf Ereignisebene mit der Protected Audience API haben wir einige erste Verbesserungen vorgeschlagen, um diese Integration zu vereinfachen. Weitere Informationen finden Sie im Erläuterungsvideo. Die Integration ist sowohl für eingegrenzte Frames als auch für iFrames verfügbar. Berichte auf Ereignisebene können in Chrome Stable ab Version M112 getestet werden.
Für Nutzer, die Attributionsberichte mit der Protected Audience API benötigen, arbeiten wir an flexibleren Lösungen, um mit aggregierten Berichten mehr Gebotssignale zu erfassen. Sobald diese Lösung verfügbar ist, veröffentlichen wir einen entsprechenden Vorschlag.
Gebots- und Auktionsdienste
Wir haben einige Bedenken hinsichtlich der Latenz der Protected Audience API gehört und arbeiten aktiv daran, die On-Device-Latenz zu verbessern. Sowohl Chrome als auch Android planen, Gebots- und Auktionsdienste als zusätzliche Möglichkeit zur Ausführung von Gebots- und Bewertungslogik neben On-Device-Auktionen anzubieten. Bidding and Auction Services ist eine Protected Audience API-Lösung für die Durchführung von Auktionen außerhalb des Geräts, die unserer Meinung nach eine noch schnellere Leistung ermöglicht.
On-Device-Auktionen werden weiterhin unterstützt. Die Verwendung der Gebots- und Auktionsdienste ist nur dann erforderlich, wenn sie zu Ihren Anwendungsfällen passt.
Weitere Informationen finden Sie in diesem Blogpost.
Nächste Schritte
Wir möchten mit Ihnen ins Gespräch kommen, um eine API zu entwickeln, die für alle funktioniert.
Über die API diskutieren
Wie andere Privacy Sandbox APIs wird auch diese API dokumentiert und öffentlich diskutiert.
Mit der API experimentieren
Sie können Tests zur Protected Audience API durchführen und sich an Diskussionen beteiligen.