Zapewnienie sprawnego działania interfejsu Protected Audience API leży w interesie wszystkich:
- Użytkownicy przeglądający internet oczekują, że strony będą się szybko ładować. 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 osadzonych w nich reklam.
- Wydawcy chcą, aby ich witryny szybko się wczytywały, zapewniając użytkownikom wydajność i szybką reakcję. Wydawcy chcą też skutecznych reklam, aby zmaksymalizować swoje przychody.
- Reklamodawcy i technologie reklamowe chcą, aby reklamy wyświetlały się szybko, co zapewnia największą użyteczność.
W tym dokumencie przedstawiamy sprawdzone metody wdrażania interfejsu Protected Audience API, aby zapewnić maksymalną wydajność witryny.
Sprawdzone metody dla kupujących (licytujących)
Aby mieć pewność, że optymalizujesz skuteczność aukcji z użyciem Protected Audience API, postępuj zgodnie z tymi sprawdzonymi metodami.
Mniejsza liczba właścicieli grup zainteresowań
Aby chronić podmioty uczestniczące w aukcjach Protected Audience API w taki sam sposób, w jaki przeglądarka chroni różne domeny w internecie za pomocą izolacji witryn, przeglądarka wykorzystuje zasoby wymagające dużych nakładów (np. procesy systemu operacyjnego) do ochrony 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 sytuacji, w której różne poddomeny są właścicielami różnych grup zainteresowań. Jeśli na przykład adtech.example
ma grupy zainteresowań należące do cats.adtech.example i dogs.adtech.example,
przeglądarka prawdopodobnie użyje 2 osobnych procesów do uruchamiania skryptów
określających stawki.
Mniejsza liczba grup zainteresowań ustalających stawki
Zanim przeglądarka wywoła skrypt generateBid() kupującego, musi przeprowadzić znaczną konfigurację i przygotowanie, np. skonfigurować nowe, czyste środowisko wykonawcze JavaScript oraz przeanalizować i wczytać kod generateBid().
- Grupy zainteresowań reprezentujące użytkowników, którzy nie są obecnie celem aktywnej kampanii reklamowej, powinny mieć puste listy kreacji reklamowych. Zapobiega to wykonywaniu przez interfejs Protected Audience API funkcji
generateBid()w przypadku grup zainteresowań bez odpowiednich reklam. - Połączenie podobnych grup zainteresowań zmniejszy liczbę uruchomień funkcji
generateBid().userBiddingSignalsWłaściwość 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. - Interfejs Protected Audience API obsługuje określone przez sprzedawcę limity liczby grup zainteresowań oraz interfejs API, który umożliwia kupującym określanie względnego priorytetu ich grup zainteresowań. Te limity mogą znacznie zmniejszyć liczbę skryptów określania stawek, które mają być uruchamiane.
Odfiltrowywanie grup zainteresowań z licytowania w usłudze par klucz-wartość
Jeśli kupujący może określić na swoim serwerze sygnałów zaufanego określania stawek w czasie rzeczywistym, że określone grupy zainteresowań nie powinny ustalać stawek (np. kampania jest wyłączona, wstrzymana lub wyczerpała budżet albo nie powinna ustalać stawek w przypadku tego wydawcy), może poinformować o tym przeglądarkę za pomocą odpowiedzi priorityVector na pobieranie sygnałów zaufanego określania stawek. Jeśli wynikowy iloczyn skalarny wektora rzadkiego priorityVector i wektora prioritySignals jest ujemny, przeglądarka pominie wywołanie funkcji generateBid() dla tej grupy zainteresowań. Więcej informacji o tym mechanizmie znajdziesz w sekcji „Filtrowanie i ustalanie priorytetów grup zainteresowań” w wyjaśnieniu.
Ponowne wykorzystywanie środowiska wykonawczego JavaScript
Zanim przeglądarka będzie mogła wykonać kod generateBid(), musi zainicjować nowe środowisko wykonawcze JavaScript. Może to zająć sporo czasu, porównywalnego z czasem potrzebnym na wykonanie minimalnego generateBid(). Możesz zaoszczędzić czas, korzystając z trybów wykonywania group-by-origin lub frozen-context.
Tryb group-by-origin może ponownie wykorzystywać środowiska wykonawcze w przypadkach, gdy grupy zainteresowań są łączone w tej samej domenie. Prawdopodobnie nie będzie wymagać zmian w skrypcie licytującym. Więcej informacji znajdziesz w group-by-originopisie w wyjaśnieniu. Tryb zamrożonego kontekstu może ponownie wykorzystywać potencjalnie wszystkie środowiska wykonawcze, ale może wymagać zmian w skrypcie określania stawek. Więcej informacji znajdziesz w frozen-contextopisie 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ń. Dzięki temu przeglądarka nie musi pobierać, analizować ani kompilować wielu skryptów (co wiąże się z dodatkowymi żądaniami sieciowymi). Licytujący mogą nadal różnicować stawki na podstawie informacji o grupach zainteresowań (np. name lub userBiddingSignals), używając tego samego skryptu.
Bez nagłówków informacji o pamięci podręcznej HTTP skrypt określania stawek nie jest zapisywany w pamięci podręcznej. Określ odpowiednie nagłówki, aby uniknąć niepotrzebnego pobierania skryptu. Jeśli na stronie równolegle odbywa się kilka aukcji, skrypt licytujący tego samego reklamodawcy zostanie ponownie użyty, jeśli jest już w pamięci, z pominięciem semantyki buforowania. Jeśli aukcje są przeprowadzane sekwencyjnie, przeglądarka będzie korzystać z mechanizmu buforowania HTTP.
Pamiętaj, że przeglądarka wczytuje skrypt określania stawek w czasie określania stawek (w przypadku generateBid()) oraz w czasie generowania raportów (w przypadku reportWin()). Jeśli nagłówki kontroli pamięci podręcznej nie są ustawione, przeglądarka pobierze ten sam skrypt dwukrotnie, raz dla każdego okresu.
Dlatego zalecamy ustawienie nagłówków kontroli pamięci podręcznej we wszystkich skryptach.
Ponowne użycie trustedBiddingSignalsUrls
Opóźnienie sieci i wykorzystanie zasobów mogą być bardzo duże. Zmniejszenie liczby pobrań sygnałów z zaufanego określania stawek w czasie rzeczywistym może pomóc w zmniejszeniu tego opóźnienia.
Pobieranie sygnałów zaufanego określania stawek można łączyć, gdy trustedBiddingSignalsUrl jest ponownie używany w wielu grupach zainteresowań.
W miarę możliwości używaj tego samego trustedBiddingSignalsUrl we wszystkich grupach zainteresowań.
Określ odpowiednie nagłówki kontroli pamięci podręcznej HTTP, aby mieć pewność, że pobieranie sygnałów zaufanego określania stawek jest buforowane w przypadku wszystkich miejsc na reklamy na danej stronie internetowej. Unikaj ustawiania parametru trustedBiddingSignalsSlotSizeMode na slot-size, ponieważ uniemożliwi to buforowanie w różnych miejscach na reklamy, gdy ich rozmiary będą się różnić, ponieważ adres URL w żądaniu będzie inny.
Mniejsze pobieranie sygnałów wiarygodnego określania stawek w czasie rzeczywistym
Opóźnienie sieci może być bardzo duże, a bezpośredni wpływ na nie ma ilość danych przesyłanych podczas pobierania sygnałów z zaufanego określania stawek w czasie rzeczywistym.
Zalecamy przechowywanie danych dotyczących konkretnych reklam lub grup zainteresowań w grupie zainteresowań, a nie w usłudze sygnałów zaufanego określania stawek w czasie rzeczywistym. Rezerwuj dane sygnałów z zaufanego ustalania stawek w czasie rzeczywistym tylko dla sygnałów, które są rzeczywiście generowane w czasie rzeczywistym, np. dla budżetowania kampanii lub wyłączników.
Wszelkie sygnały, które można aktualizować codziennie lub rzadziej, powinny być przechowywane w grupie zainteresowań i aktualizowane za pomocą codziennych aktualizacji.
Nie zwracaj zaufanych sygnałów do określania stawek w przypadku grup zainteresowań, które zostały odfiltrowane zgodnie z opisem w sekcji „Odfiltrowywanie grup zainteresowań z określania stawek w usłudze klucz/wartość”.
Nadawanie priorytetu grupom zainteresowań
Sprzedawcy będą używać limitów czasu, aby ograniczać wykorzystanie zasobów przeglądarki na stronach wydawców. Gdy perBuyerCumulativeTimeouts są używane do ograniczania czasu, w którym kupujący mogą pobierać sygnały zaufanego określania stawek i wykonywać skrypty określania stawek, kupujący muszą zadbać o to, aby nadać priorytet grupom zainteresowań, tak aby najpierw wykonywały się te, które z największym prawdopodobieństwem wygrają aukcję. Jeśli na przykład wartość perBuyerCumulativeTimeouts wynosi 100 ms, pobieranie zaufanych sygnałów do określania stawek przez licytującego trwa 50 ms, a każde wywołanie funkcji generateBid() trwa 10 ms i na urządzeniu jest 10 grup zainteresowań, tylko połowa z nich będzie miała szansę na obliczenie stawek. W tym przykładzie kupujący powinien określić priorytety grup zainteresowań w kolejności od najbardziej do najmniej prawdopodobnej wygranej.
Grupy zainteresowań mogą zawierać statyczne priorytety zdefiniowane za pomocą pola priority. Grupy zainteresowań mogą też używać dynamicznych priorytetów, które można obliczać w usłudze zaufanych sygnałów do określania stawek i zwracać do przeglądarki w priorityVector odpowiedzi na pobieranie zaufanych sygnałów do określania stawek.
Pamiętaj, że gdy przeglądarka wykonuje grupy zainteresowań od najwyższego do najniższego priorytetu, może to powodować przeplatanie się grup zainteresowań z różnych źródeł dołączania, co może niweczyć optymalizację group-by-origin.
Sprawdzone metody dla sprzedawców
Monitoruj i optymalizuj skuteczność aukcji z użyciem Protected Audience API.
Równoległe aukcje
Nowoczesne połączenia sieciowe i procesory wielordzeniowe doskonale radzą sobie z wykonywaniem wielu czynności jednocześnie. Przeglądarka może przeprowadzać aukcję z Protected Audience API równolegle z innymi działaniami. Najlepiej zadzwonić do runAdAuction() jak najwcześniej. Przeglądarka wie, że niektóre dane wejściowe dla funkcji runAdAuction() mogą być początkowo niedostępne, np. te, które są odsyłane do przeglądarki w odpowiedzi kontekstowej. Dlatego umożliwia wywoływanie funkcji runAdAution(), zanim staną się dostępne, i dostarczanie tych danych wejściowych w późniejszym czasie za pomocą obietnic JavaScript. Aby uzyskać najniższe możliwe opóźnienie aukcji, wywołaj funkcję runAdAuction(), gdy znana jest wartość wejściowa interestGroupBuyers. Pozwala to na natychmiastowe rozpoczęcie wielu części aukcji, w tym pobieranie sygnałów określania stawek w czasie rzeczywistym od oferentów.
Monitorowanie aukcji
Zbieraj dane o swoich aukcjach. Przeglądarka może zgłaszać per-buyer sprzedawcom dane o opóźnieniach, które dostarczają wielu informacji o tym, jak czas jest wykorzystywany na aukcjach sprzedawcy. Sprzedawcy mogą używać tych danych do szukania sposobów optymalizacji aukcji, w tym do określania, jak najskuteczniej ustawiać limity czasu. Sprzedawcy mogą udostępniać kupującym dane o opóźnieniach, aby pomóc im w dalszej optymalizacji.
Oferujący mogą mieć wgląd w skuteczność licytowania swoich grup zainteresowań, ale nie mogą porównywać jej z innymi oferującymi. Porównanie względnych współczynników wygranych i odrzuceń stawek w przypadku różnych oferentów może pomóc w identyfikacji przypadków, w których zasoby obliczeniowe na potrzeby określania stawek zostały zmarnowane, ponieważ grupy zainteresowań nigdy nie generowały odpowiednich stawek lub dochodziło do nadmiernego określania stawek w przypadku niezatwierdzonych kreacji.
Ochrona przed skryptami wolnych stawek
Skrypty ustalania stawek, które działają zbyt długo, mogą spowolnić aukcję interfejsu Protected Audience API dla wszystkich uczestników. Stosowanie limitów czasu może zapobiegać powolnym aukcjom, a jednocześnie odzyskiwać przychody, gdy aukcja jest powolna.
Sprzedawcy powinni używać parametru perBuyerCumulativeTimeouts, aby zapobiegać powolnym aukcjom, a także akceptować stawki, gdy aukcja jest powolna i osiąga limit czasu. Używanie perBuyerCumulativeTimeouts jest lepsze niż używanie perBuyerTimeouts i perBuyerGroupLimits, ponieważ perBuyerCumulativeTimeouts nie ma opinii na temat liczby grup zainteresowań ani szybkości generateBid() (np. wiele grup zainteresowań, które szybko składają oferty, i niewiele grup zainteresowań, które składają oferty powoli, może zakończyć działanie przed upływem limitu czasu).
Aby zapobiec zbyt długim aukcjom w przypadkach, gdy pobieranie sygnałów oceny zaufania i wykonywanie scoreAd() zajmuje zbyt dużo czasu, warto też użyć pola signal konfiguracji aukcji do wdrożenia ogólnego limitu czasu aukcji.
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.