Skrócenie czasu oczekiwania na aukcji interfejsu Protected Audience API

W interesie wszystkich jest zapewnienie sprawnego działania interfejsu Protected Audience API:

  • Użytkownicy internetu oczekują, że witryny będą wczytywać się szybko. Oznacza to, że deweloperzy powinni efektywnie korzystać z interfejsu Protected Audience API, aby nie nadużywać ograniczonych zasobów urządzenia, takich jak zasoby obliczeniowe czy sieciowe, które są niezbędne do wczytywania witryn i zawartych w nich reklam.
  • Wydawcy chcą, aby ich witryny wczytywały się szybko, zapewniając użytkownikom wydajne i responsywne działanie. Wydawcy chcą też skutecznie reklamować swoje treści, aby zmaksymalizować przychody.
  • Reklamodawcy i technolodzy reklam chcą, aby ich reklamy wyświetlały się szybko, aby zapewniać jak największą użyteczność.

W tym dokumencie przedstawiamy sprawdzone metody implementacji interfejsu Protected Audience API, które pozwolą Ci zapewnić maksymalną wydajność witryny.

Sprawdzone metody dotyczące kupujących (oferentujących)

Aby mieć pewność, że optymalizujesz skuteczność aukcji interfejsu Protected Audience API, stosuj te sprawdzone metody.

Mniej właścicieli grup zainteresowań

Aby chronić licytujących korzystających z interfejsu Protected Audience API w taki sam sposób, w jaki przeglądarka chroni różne źródła w internecie za pomocą izolacji witryny, przeglądarka używa drogich zasobów (takich jak procesy systemu operacyjnego), aby chronić poszczególnych właścicieli grup zainteresowań.

Aby zminimalizować wydatki na te bardzo drogie zasoby, kluczowe jest posiadanie jak najmniejszej liczby właścicieli grup zainteresowań. Unikaj tworzenia różnych grup zainteresowań należących do różnych subdomen. Jeśli na przykład adtech.example miałaby grupy zainteresowań należące do cats.adtech.example i dogs.adtech.example, przeglądarka prawdopodobnie użyłaby 2 oddzielnych procesów do uruchamiania skryptów ustalania stawek.

ustalanie stawek w mniejszej liczbie grup zainteresowań,

Przed wywołaniem skryptu generateBid() kupującego przeglądarka musi przeprowadzić znaczną konfigurację i przygotowanie, na przykład utworzenie nowego czystego środowiska do wykonywania kodu JavaScript oraz zanalizowanie i wczytanie kodu generateBid().

  • Grupy zainteresowań, które obejmują użytkowników, którzy nie są obecnie celem aktywnej kampanii reklamowej, powinny mieć puste listy kreacji reklam. Zapobiega to wykonywaniu przez Protected Audience API funkcji generateBid() w przypadku grup zainteresowań bez odpowiednich reklam.
  • Połączenie podobnych grup zainteresowań zmniejszy liczbę wyświetleń, w których musi się ona pojawić.generateBid() W usłudze userBiddingSignalsmożesz przechowywać dodatkowe metadane o użytkowniku, więc mniejsza liczba grup zainteresowań nie musi oznaczać mniej skutecznego kierowania.
  • Interfejs Protected Audience API obsługuje określone przez sprzedawcę limity liczby grup zainteresowań oraz interfejs API, który umożliwia kupującym określenie względnego priorytetu ich grup zainteresowań. Dzięki tym limitom możesz znacznie ograniczyć liczbę uruchamianych skryptów określania stawek.

Wykluczanie grup zainteresowań z określania stawek w usłudze Key/Value

Jeśli kupujący na podstawie sygnałów z serwera z zaufanymi stawkami w czasie rzeczywistym stwierdzi, że na niektóre grupy zainteresowań nie powinny być ustalane stawki (np. kampania jest wyłączona, wstrzymana lub wyczerpała budżet albo nie powinna ustalać stawek dla danego wydawcy), może przekazać tę informację przeglądarce za pomocą odpowiedzi priorityVector na żądanie dotyczące pobierania sygnałów z zaufanymi stawkami. Jeśli wynikowy produkt rzadkich kropek priorityVector i prioritySignals jest ujemny, przeglądarka pominie wywołanie funkcji generateBid() w przypadku tej grupy zainteresowań. Więcej informacji o tym mechanizmie znajdziesz w sekcji „Filtrowanie i przypisywanie priorytetów grupom zainteresowań” w tym objaśnieniu.

Ponowne używanie środowiska wykonawczego JavaScript

Zanim przeglądarka wykona generateBid(), musi zainicjować nowe środowisko wykonywania kodu JavaScript. Może to zająć sporo czasu, ponieważ jest to równoznaczne z czasem potrzebnym na wykonanie minimalnego generateBid(). Czas można zaoszczędzić, używając trybów wykonywania grup według pochodzenia lub zamrożonego kontekstu.

Tryb group-by-origin może używać ponownie środowisk wykonania w przypadkach, gdy grupy zainteresowań są złączane na podstawie tej samej domeny i prawdopodobnie nie wymagają zmian w skrypcie ustalania stawek. Więcej informacji znajdziesz w sekcji group-by-origin w opisie. Tryb zamrożonego kontekstu może wykorzystywać potencjalnie wszystkie środowiska wykonania, ale może wymagać wprowadzenia zmian w skrypcie ustalania stawek. Więcej informacji znajdziesz w frozen-context w wyjaśnieniu.

Ponowne używanie skryptów ustalania stawek

Jeśli to możliwe, używaj tego samego skryptu ustalania stawek w przypadku grup zainteresowań. Zapobiega to konieczności pobierania, analizowania i kompilowania wielu skryptów (co powoduje dodatkowe żądania sieci). Użytkownicy mogą nadal różnicować stawki na podstawie informacji o grupach zainteresowań (np. name lub userBiddingSignals) przy użyciu tego samego skryptu.

Bez nagłówków HTTP kontrolujących pamięć podręczną skrypt ustalania stawek nie jest przechowywany w pamięci podręcznej. Podaj odpowiednie nagłówki, aby mieć pewność, że skrypt nie będzie niepotrzebnie pobierany. Jeśli na stronie odbywa się kilka aukcji jednocześnie, skrypt ustalania stawek tego samego licytującego zostanie użyty ponownie, jeśli jest już w pamięci, ignorując semantyczne buforowanie. Jeśli aukcje są przeprowadzane sekwencyjnie, przeglądarka będzie przestrzegać mechanizmu pamięci podręcznej HTTP.

Pamiętaj, że przeglądarka wczytuje skrypt ustalania stawek w czasie ustalania stawki (dla generateBid()) oraz w czasie raportowania (dla reportWin()). Jeśli nagłówki kontroli pamięci podręcznej nie są ustawione, przeglądarka pobiera ten sam skrypt 2 razy, po jednym razie w każdym z tych okresów.

Dlatego zalecamy ustawienie nagłówków kontroli pamięci podręcznej we wszystkich skryptach.

Użyj ponownie trustedBiddingSignalsUrls

Opóźnienia w sieci i wykorzystanie zasobów mogą być bardzo duże. Zmniejszenie liczby pobieranych sygnałów z zaufanych źródeł ustalania stawek w czasie rzeczywistym może pomóc w zmniejszeniu tego opóźnienia.

Pobieranie sygnałów z zaufanych źródeł ustalania stawek może być łączone, gdy trustedBiddingSignalsUrl jest używany ponownie w przypadku wielu grup zainteresowań. Jeśli to możliwe, używaj tych samych wartości trustedBiddingSignalsUrl dla wszystkich grup zainteresowań.

Określ odpowiednie nagłówki kontrolne pamięci podręcznej HTTP, aby zapewnić pobieranie z pamięci podręcznej zaufanych sygnałów licytacji w przypadku wszystkich miejsc na reklamę na danej stronie internetowej. Unikaj ustawiania wartości trustedBiddingSignalsSlotSizeMode na slot-size, ponieważ uniemożliwi to buforowanie w miejscach docelowych reklam, jeśli ich rozmiary się różnią, ponieważ żądany adres URL będzie się różnić.

Mniejsze pobieranie zaufanych sygnałów ustalania stawek w czasie rzeczywistym

Opóźnienia w sieci mogą być bardzo duże, a na ich wielkość ma bezpośredni wpływ ilość danych przesyłanych podczas pobierania sygnałów zaufanych stawek w czasie rzeczywistym.

Zalecamy przechowywanie danych dotyczących reklam lub grup zainteresowań w grupie zainteresowań, a nie w usłudze sygnałów wiarygodnego określania stawek w czasie rzeczywistym. Zarezerwuj dane sygnałów wiarygodnego określania stawek w czasie rzeczywistym tylko dla tych sygnałów, które są naprawdę w czasie rzeczywistym, np. budżetowanie kampanii lub przełączniki wyłączające.

Każdy sygnał, który można aktualizować codziennie lub rzadziej, powinien być przechowywany w grupie zainteresowań i aktualizowany za pomocą aktualizacji dziennych.

Nie zwracaj sygnałów wiarygodnego ustalania stawek w przypadku grup odbiorców według zainteresowań, które zostały odfiltrowane zgodnie z opisem w sekcji „Odfiltrowywanie grup odbiorców według zainteresowań z usługi klucz-wartość”.

Priorytetyzacja grup zainteresowań

Sprzedawcy będą używać limitów czasowych, aby ograniczyć sposób wykorzystywania zasobów przeglądarki na stronach wydawców. Gdy perBuyerCumulativeTimeouts są używane do ograniczenia czasu potrzebnego kupującym na pobieranie zaufanych sygnałów ustalania stawek i wykonywanie skryptów ustalania stawek, ważne jest, aby kupujący nadawali priorytety grupom zainteresowań, tak aby te, które najprawdopodobniej wygrają aukcję, były wykonywane jako pierwsze. Jeśli np. parametr perBuyerCumulativeTimeouts ma wartość 100 ms, a pobieranie zaufanych sygnałów licytujących przez oferentę trwa 50 ms, a każde wywołanie perBuyerCumulativeTimeouts – 10 ms, a na urządzeniu jest 10 grup zainteresowań, tylko połowa z nich będzie miała szansę na obliczenie stawek.generateBid() W tym przykładzie kupujący powinien nadać priorytety grupom zainteresowań w kolejności od grupy o największym do najmniejszego prawdopodobieństwem wygrania.

Grupy zainteresowań mogą zawierać priorytety statyczne zdefiniowane za pomocą pola priority. Grupy zainteresowań mogą też używać priorytetów dynamicznych, które można obliczyć na podstawie usługi zaufanych sygnałów ustalania stawek i zwrócić do przeglądarki w odpowiedzi na pobranie zaufanych sygnałów ustalania stawek (priorityVector).

Pamiętaj, że gdy przeglądarka wykonuje grupy zainteresowań od najwyższego do najniższego priorytetu, może to powodować przeplatanie grup zainteresowań z różnych źródeł łączenia, co może uniemożliwić optymalizację group-by-origin.

Sprawdzone metody dla sprzedawców

Zadbaj o monitorowanie i optymalizację skuteczności aukcji Protected Audience API.

Równoległe wczytywanie aukcji

Nowoczesne połączenia sieciowe i procesory wielordzeniowe świetnie radzą sobie z wykonywaniem wielu działań jednocześnie. Przeglądarka może prowadzić aukcję Protected Audience równolegle z innymi działaniami. Najlepiej zrobić to, dzwoniąc na numer runAdAuction() jak najszybciej. Ponieważ niektóre dane wejściowe do funkcji runAdAuction() mogą być niedostępne na początku, np. te, które są wysyłane z powrotem do przeglądarki w ramach odpowiedzi kontekstowej, przeglądarka umożliwia wywołanie funkcji runAdAution(), zanim dane te będą dostępne, oraz przesyłanie tych danych w późniejszym czasie za pomocą obietnic JavaScript. Aby uzyskać jak najkrótszy czas oczekiwania na wynik aukcji, należy wywołać funkcję runAdAuction(), gdy znane są dane wejściowe interestGroupBuyers. Dzięki temu wiele części aukcji może się rozpocząć natychmiast, w tym pobieranie sygnałów dotyczących określania stawek w czasie rzeczywistym.

Monitorowanie aukcji

zbierać dane o aukcjach, Przeglądarka może przekazywać sprzedawcom dane o opóźnieniach, które dostarczają wielu informacji o tym, jak czas jest wykorzystywany na aukcjach sprzedawcy.per-buyer Sprzedawcy mogą używać tych danych, aby szukać sposobów optymalizacji aukcji, w tym dowiedzieć się, jak najskuteczniej ustawić czas oczekiwania. Sprzedawcy mogą udostępnić kupującemu dane o opóźnieniach, aby pomóc mu w dalszej optymalizacji.

Uczestnicy mogą mieć statystyki dotyczące skuteczności ustalania stawek w przypadku swoich grup zainteresowań, ale mogą nie mieć możliwości porównania tych danych z danymi innych uczestników. Porównywanie względnych wskaźników wygranych i odsyłania stawek przez różnych licytujących może pomóc w identyfikowaniu przypadków, w których zasoby obliczeniowe na potrzeby licytowania były marnowane, ponieważ grupy zainteresowań nigdy nie generowały odpowiednich stawek lub licytowanie było nadmierne, a kreacje nie były zatwierdzone.

Ochrona przed wolno działającymi skryptami ustalania stawek

Skrypty ustalania stawek, które zajmują zbyt dużo czasu, mogą spowolnić aukcję Protected Audience API dla wszystkich zaangażowanych stron. Użycie limitów czasu może zapobiegać spowolnieniu aukcji, a jednocześnie pozwolić odzyskać przychody, gdy aukcja jest powolna.

Sprzedawcy powinni używać wartości perBuyerCumulativeTimeouts, aby zapobiegać wolnym aukcjom i nadal akceptować stawki, gdy aukcja jest wolna i dochodzi do limitu czasu. Użycie funkcji perBuyerCumulativeTimeouts jest lepsze niż użycie funkcji perBuyerTimeouts i perBuyerGroupLimits, ponieważ funkcja perBuyerCumulativeTimeouts nie ma zdania na temat liczby grup zainteresowań ani szybkości generateBid() (np. wiele grup zainteresowań, które szybko ustalają stawki, i niewielka liczba grup zainteresowań, które ustalają stawki powoli, mogą zakończyć działanie przed upływem limitu czasu).

Warto też używać pola konfiguracji aukcji signal, aby zaimplementować ogólny limit czasu aukcji. Pozwoli to uniknąć zbyt długich aukcji w przypadkach, gdy pobieranie i wykonywanie scoreAd() sygnału zaufanej oceny zajmuje zbyt dużo czasu.

Co dalej?

Chcemy wspólnie z Tobą rozmawiać, aby mieć pewność, że stworzyliśmy interfejs API dla wszystkich użytkowników.

Omów interfejs API

Podobnie jak inne interfejsy API Piaskownicy prywatności, ten interfejs API jest udokumentowany i omawiany publicznie.

Eksperymentuj z interfejsem API

Możesz eksperymentować i uczestniczyć w rozmowach na temat interfejsu Protected Audience API.