Skrócenie czasu oczekiwania na aukcji interfejsu Protected Audience API

Dbanie o wydajność interfejsu Protected Audience API leży w interesie wszystkich użytkowników:

  • Użytkownicy internetu chcą szybko wczytywać strony. Oznacza to, że deweloperzy powinni efektywnie korzystać z interfejsu Protected Audience API, aby nie wykorzystywać nadmiarowych zasobów urządzeń, takich jak zasoby obliczeniowe lub sieciowe, które są niezbędne do wczytywania stron i umieszczonych w nich reklam.
  • Wydawcom zależy na tym, by ich witryny szybko się ładowały, a użytkownicy byli wygodne i responsywni. Wydawcom zależy również na skutecznej reklamie, która pozwoli zmaksymalizować przychody.
  • Reklamodawcy i techniki reklamowe chcą, aby ich reklamy wyświetlały się szybko, aby zapewnić jak największą użyteczność.

W tym dokumencie znajdziesz sprawdzone metody implementacji interfejsu Protected Audience API, które pomogą Ci uzyskać maksymalną wydajność witryny.

Sprawdzone metody dotyczące kupujących (licytującego)

Aby mieć pewność, że optymalizujesz kampanię pod kątem skuteczności 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 jak przeglądarka chroni różne źródła w internecie za pomocą izolacji witryn, do ochrony właścicieli poszczególnych grup zainteresowań przeglądarka używa kosztownych zasobów (np. procesów systemu operacyjnego).

Aby zminimalizować wydatki na te bardzo drogie zasoby, kluczowa jest jak najmniejsza liczba właścicieli grup zainteresowań. Unikaj posiadania różnych grup zainteresowań należących do różnych subdomen. Jeśli np. użytkownik adtech.example miałby grupy zainteresowań należące do cats.adtech.example i dogs.adtech.example, przeglądarka prawdopodobnie użyje 2 osobnych procesów do uruchomienia skryptów ustalania stawek.

Mniej ustalania stawek dla grup zainteresowań

Przed wywołaniem skryptu generateBid() kupującego przeglądarka musi przeprowadzić szczegółową konfigurację i przygotowanie. Obejmuje to na przykład skonfigurowanie nowego środowiska wykonawczego JavaScriptu oraz analizowanie i wczytywanie kodu generateBid().

  • Grupy zainteresowań reprezentujące użytkowników, których nie jest obecnie celem aktywnej kampanii reklamowej, powinny mieć puste listy kreacji. Uniemożliwia to wykonywanie przez interfejs Protected Audience API polecenia generateBid() w przypadku grup zainteresowań bez odpowiednich reklam.
  • Połączenie grup podobnych zainteresowań spowoduje zmniejszenie liczby uruchomień programu generateBid(). Właściwość userBiddingSignals grupy zainteresowań może służyć do przechowywania dodatkowych metadanych o użytkowniku, więc mniejsza liczba grup zainteresowań nie musi oznaczać mniej skutecznego kierowania.
  • Protected Audience API obsługuje określone przez sprzedawców limity liczby grup zainteresowań, a kupującym – interfejs API do określania względnego priorytetu grup zainteresowań. Te limity mogą służyć do znacznego ograniczania liczby uruchamianych skryptów ustalania stawek.

Odfiltrowywanie grup zainteresowań z ustalania stawek w usłudze klucz/wartość

Jeśli kupujący stwierdzi na serwerze sygnału zaufanego ustalania stawek w czasie rzeczywistym, że określone grupy zainteresowań nie powinny ustalać stawek (np. kampania jest wyłączona, wstrzymana, wyczerpała budżet lub nie powinna ustalać stawek w przypadku tego konkretnego wydawcy), może poinformować o tym przeglądarkę, wysyłając odpowiedź priorityVector na pobrane sygnały ustalania stawek. Jeśli wynikowy iloczyn rozproszony rozproszony funkcji priorityVector i prioritySignals jest ujemny, przeglądarka pominie wywoływanie funkcji generateBid() w przypadku tej grupy zainteresowań. Więcej informacji o tym mechanizmie znajdziesz w sekcji „Filtrowanie i określanie priorytetów grup zainteresowań” w objaśnieniu.

Ponowne wykorzystanie środowiska wykonawczego JavaScript

Zanim przeglądarka będzie mogła wykonać polecenie generateBid(), musi zainicjować nowe środowisko wykonawcze JavaScriptu. Może to zająć sporo czasu w stosunku do tego, ile czasu może zająć minimalne wykonanie elementu generateBid(). Ten czas można zaoszczędzić, korzystając z trybów wykonywania „grupa według źródła” lub „zablokowany kontekst”.

Tryb group-by-origin może wielokrotnie wykorzystywać środowiska wykonawcze w przypadkach, gdy grupy zainteresowań są połączone w tym samym źródle i prawdopodobnie nie wymagają wprowadzania zmian w skrypcie ustalania stawek. Więcej informacji znajdziesz w opisie funkcji group-by-origin w wyjaśnieniu. W trybie zablokowanego kontekstu można ponownie wykorzystać wszystkie środowiska wykonawcze, ale może wymagać wprowadzenia zmian w skrypcie określania stawek. Więcej informacji znajdziesz w opisie funkcji frozen-context w objaśnieniu.

Ponowne wykorzystanie skryptów ustalania stawek

W miarę możliwości używaj tego samego skryptu ustalania stawek dla grup zainteresowań. Zapobiega to konieczności pobierania, analizowania i kompilowania wielu skryptów przez przeglądarkę (co powoduje dodatkowe żądania sieciowe). Licytujący nadal mogą rozróżniać stawki na podstawie informacji o grupach zainteresowań (np. name lub userBiddingSignals), korzystając z tego samego skryptu.

Użyj ponownie trustedBiddingSignalsUrls

Opóźnienia sieciowe i wykorzystanie zasobów mogą być bardzo duże. Mniej pobrań zaufanych sygnałów określania stawek w czasie rzeczywistym może pomóc skrócić ten czas oczekiwania.

Pobrania sygnałów dotyczących zaufanego określania stawek mogą być łączone, gdy parametr trustedBiddingSignalsUrl jest ponownie używany w wielu grupach zainteresowań. W miarę możliwości używaj tego samego atrybutu trustedBiddingSignalsUrl dla wszystkich grup zainteresowań.

Określ odpowiednie nagłówki kontrolne pamięci podręcznej HTTP, aby mieć pewność, że pobieranie zaufanych sygnałów ustalania stawek jest przechowywane w pamięci podręcznej w boksach reklamowych na danej stronie internetowej. Unikaj ustawiania parametru trustedBiddingSignalsSlotSizeMode na slot-size, ponieważ zapobiega to buforowaniu reklam w boksach reklamowych o różnych rozmiarach, ponieważ będą się różnić żądanym adresem URL.

Mniejsze pobieranie zaufanych sygnałów określania stawek w czasie rzeczywistym

Czas oczekiwania w sieci może być bardzo duży, na co bezpośrednio wpływa ilość danych przesyłanych podczas pobierania sygnału dotyczącego zaufanego określania stawek w czasie rzeczywistym.

Wolisz przechowywać w grupie zainteresowań dane dotyczące reklamy lub grupy zainteresowań, a nie korzystać z zaufanej usługi sygnałów określania stawek w czasie rzeczywistym. Zarezerwuj dane dotyczące zaufanych sygnałów ustalania stawek w czasie rzeczywistym tylko na potrzeby sygnałów uzyskiwanych w czasie rzeczywistym, takich jak ustalanie budżetu kampanii lub przełączniki działania.

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

Nie zwracaj zaufanych sygnałów ustalania stawek w przypadku grup zainteresowań, które zostały odfiltrowane w sposób opisany w sekcji „Odfiltrowywanie grup zainteresowań z ustalania stawek w usłudze klucz-wartość”.

Nadawanie priorytetu grupom zainteresowań

Sprzedawcy stosują limity czasu, aby ograniczać wykorzystanie zasobów przeglądarki na stronach wydawców. Gdy używasz funkcji perBuyerCumulativeTimeouts do ograniczania czasu, przez jaki kupujący mają czas na pobranie zaufanych sygnałów ustalania stawek i wykonanie skryptów ustalania stawek, kupujący muszą zadbać o to, aby traktowali priorytetowo swoje grupy zainteresowań, tak aby w pierwszej kolejności przeprowadzały aukcję tych, którzy z największym prawdopodobieństwem zwyciężą w aukcji. Jeśli na przykład parametr perBuyerCumulativeTimeouts ma wartość 100 ms, a pobieranie zaufanych sygnałów ustalania stawek licytującego – 50 ms, a każde wywołanie generateBid() trwa 10 ms, a na urządzeniu jest 10 grup zainteresowań, tylko połowa grup zainteresowań będzie miała szansę obliczyć stawki. W tym przykładzie kupujący powinien priorytetowo traktować grupy zainteresowań w kolejności od najbardziej prawdopodobnego do wygranej.

Grupy zainteresowań mogą zawierać statyczne priorytety zdefiniowane w polu priority. Grupy zainteresowań mogą też używać dynamicznych priorytetów, które mogą być obliczane w ramach usługi zaufanych sygnałów określania stawek i zwracane do przeglądarki z odpowiedzią priorityVector na pobranie zaufanych sygnałów ustalania stawek.

Pamiętaj, że gdy przeglądarka uruchamia grupy zainteresowań od najwyższego do najniższego priorytetu, grupy zainteresowań z różnych połączonych źródeł mogą nie działać prawidłowo, co może uniemożliwić optymalizację group-by-origin.

Sprawdzone metody dla sprzedawców

Pamiętaj, aby monitorować i optymalizować skuteczność aukcji interfejsu Protected Audience API.

Równoległe wczytywanie aukcji

Nowoczesne połączenia sieciowe i procesory wielordzeniowe świetnie sprawdzają się podczas wykonywania wielu działań jednocześnie. Przeglądarka może przeprowadzać aukcję w ramach Protected Audience API równolegle z innymi działaniami. Aby to ułatwić, jak najszybciej zadzwoń pod numer runAdAuction(). Biorąc pod uwagę, że niektóre dane wejściowe w funkcji runAdAuction() mogą być na początku niedostępne, na przykład te, które są odsyłane z powrotem do przeglądarki w odpowiedzi kontekstowej, przeglądarka zezwala na wywoływanie funkcji runAdAution() przed ich udostępnieniem i dostarczanie ich później za pomocą obietnic JavaScript. Aby osiągnąć najkrótszy możliwy czas oczekiwania na wczytanie aukcji, należy wywoływać funkcję runAdAuction(), gdy znane są dane wejściowe interestGroupBuyers. Dzięki temu wiele części aukcji może się rozpocząć od razu, w tym pobieranie sygnałów ustalania stawek w czasie rzeczywistym.

Monitorowanie aukcji

Zbieraj dane o swoich aukcjach. Przeglądarka może raportować dane o czasie oczekiwania (per-buyer) na potrzeby sprzedawców, dzięki którym uzyskasz szczegółowe informacje o czasie trwania aukcji sprzedawcy. Sprzedawcy mogą korzystać z tych danych do optymalizowania aukcji, w tym do informowania o najefektywniejszym ustawianiu limitów czasu oczekiwania. Sprzedawcy mogą udostępniać kupującemu dane o czasie oczekiwania konkretnego kupującego, aby pomóc mu w dalszej optymalizacji.

Licytujący mogą mieć wgląd w skuteczność ustalania stawek w ich własnych grupach zainteresowań, ale mogą nie mieć możliwości porównania ich z innymi. Porównanie względnych współczynników wygranych i odrzuceń stawek w przypadku różnych licytujących może pomóc w znalezieniu przypadków, w których zasoby obliczeniowe związane z ustalaniem stawek zostały zmarnowane, ponieważ grupy zainteresowań nie wygenerowały realnych stawek lub nadmiernie licytowały w przypadku niezatwierdzonych kreacji.

Ochrona przed skryptami powolnych stawek

Skrypty ustalania stawek, które zajmują zbyt dużo czasu, mogą spowolnić aukcję interfejsu Protected Audience API u wszystkich osób. Zastosowanie limitów czasu pozwoli uniknąć powolnych aukcji i jednocześnie odzyskać przychody nawet wtedy, gdy aukcja będzie powolna.

Sprzedawcy powinni korzystać z perBuyerCumulativeTimeouts, aby zapobiegać powolnym aukcjach i akceptować stawki, gdy aukcja jest powolna i minie limit czasu jej trwania. Używanie perBuyerCumulativeTimeouts jest lepszym wyborem niż perBuyerTimeouts i perBuyerGroupLimits, ponieważ perBuyerCumulativeTimeouts nie ocenia liczby grup zainteresowań ani szybkości działania generateBid() (np. wiele grup zainteresowań, które ustalają szybkie stawki, i niewiele grup, które ustalają stawki wolno, zanim to nastąpi).

Użycie pola signal konfiguracji aukcji do wdrożenia ogólnego limitu czasu aukcji to także dobry pomysł, aby uniknąć zbyt długich aukcji w przypadkach, gdy pobieranie zaufanych sygnałów o ocenie i wykonywanie scoreAd() 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.