Protected Audience: przewodnik po integracji

Protected Audience (wcześniej FLEDGE) w implementacjach na Androida obejmuje zazwyczaj integrację między aplikacjami reklamodawców, aplikacjami wydawców oraz sprzedawcami i kupującymi. Ten przewodnik jest przeznaczony dla partnerów, którzy planują zarządzać niestandardowymi odbiorcami i organizować aukcje, w tym sieci technologii reklamowych, które działają zarówno jako kupujący, jak i sprzedawcy. Różne kampanie reklamowe mogą mieć różne cele i nie wszystkie funkcje Protected Audience API są używane we wszystkich przypadkach użycia. W tym przewodniku opisujemy kroki niezbędne do obsługi bardziej specjalistycznych przypadków, gdy tylko jest to możliwe.

Aby przygotować się do produkcyjnego wdrożenia Protected Audience na dużą skalę, partnerzy mogą rozpocząć testy, wyśmiewając się z punktów integracji z innymi stronami. Ten przewodnik zawiera szczegółowe informacje o tym, jak zintegrować Protected Audience z aplikacjami na Androida, aby ułatwić Ci planowanie integracji. Może to obejmować funkcje, które nie są jeszcze wdrożone na obecnym etapie Piaskownicy prywatności w wersji przedpremierowej dla programistów aplikacji na Androida. W takich przypadkach przedstawiamy wytyczne dotyczące harmonogramu.

Proces integracji Protected Audience obejmuje 4 kluczowe etapy podejmowane przez różnych partnerów ds. technologii reklamowych:

1. Kupujący tworzy grupy niestandardowych odbiorców.
2. W ramach procesu wyboru zwycięska reklama jest wybierana.
   1. Aplikacja sprzedawcy inicjuje wybór reklamy.
   2. Usługi reklamowe wykorzystują kod filtrowania po stronie zakupu i określania stawek.
   3. Usługi reklamowe uruchamiają kod decyzji sprzedawcy.
3. Zwycięska reklama jest renderowana w aplikacji sprzedawcy.
4. Raporty o wyświetleniach reklam są dostępne zarówno dla kupującego, jak i dla sprzedawcy.

Poniższy diagram przedstawia te kroki:

Proces niestandardowego zarządzania odbiorcami i wyboru reklam w ramach Protected Audience API.

Terminologia

• Reklamodawca: firma, która dociera do użytkowników za pomocą kupowania zasobów reklamowych.
• Wydawca: firma sprzedająca zasoby reklamowe dostępne razem z jej treściami.
• Kupujący: firma z branży technologii reklamowych, która ułatwia reklamodawcom kupowanie zasobów reklamowych.
• Sprzedawca: firma z branży technologii reklamowych, która ułatwia wydawcom sprzedaż zasobów reklamowych.
• Sieć: firma z branży technologii reklamowych, która pełni zarówno funkcję kupującego, jak i sprzedawcy.
• Posiadane i obsługiwane: firma, która pełni rolę wydawcy, sprzedawcy i kupującego.
• Partnerzy integracyjny: wszystkie firmy, z którymi współpracujesz, aby przeprowadzić integrację z Protected Audience.

Wymagania wstępne, zaangażowanie partnera integracyjnego i konfiguracja

W tej sekcji omawiamy wstępne czynności, które pomogą Ci zrozumieć, jak działa ten program, jak rozpocząć jego integrację i jak nawiązać kontakt z partnerami integracyjnymi w ramach tej implementacji. Działania te mogą odbywać się równolegle.

Przewodnik po wdrażaniu funkcji Protected Audience API.

Poznaj Protected Audience API

Pierwszym krokiem jest zapoznanie się z interfejsami API i usługami Protected Audience API.

1. Zacznij od zapoznania się z propozycją projektu, aby zapoznać się z interfejsem Protected Audience API i jego możliwościami.
2. Przeczytaj przewodnik dla programistów, aby dowiedzieć się, jak umieszczać kod i wywołania interfejsu API, których potrzebujesz w swoich zastosowaniach, oraz jakie usługi są potrzebne do integracji z Protected Audience.
3. Prześlij opinię na temat projektowania i wdrażania interfejsów API Protected Audience API, usług oraz dokumentacji.
4. Zarejestruj się, aby otrzymywać informacje o najnowszych funkcjach Piaskownicy prywatności.

Konfigurowanie i testowanie przykładowych aplikacji

Po zapoznaniu się z podstawami Protected Audience API, jak opisaliśmy wcześniej, skonfiguruj i przetestuj przykładowe aplikacje.

1. Gdy wszystko będzie gotowe do rozpoczęcia integracji, skonfiguruj środowisko programistyczne w najnowszej wersji Piaskownicy prywatności dla programistów.
2. Skonfiguruj wymagane punkty końcowe serwera. Aby uruchomić ten proces, użyj przykładowych próbek z preferowanym rozwiązaniem testowym interfejsu API.
3. Aby zapoznać się z niestandardowym zarządzaniem odbiorcami, procesem wyboru reklamy i raportowaniem wyświetleń, utwórz rozwidlenie kodu i uruchom go w naszej przykładowej aplikacji.

Zaangażowanie partnera w zakresie integracji

Zaplanuj rozmowy z partnerami integracyjnymi, aby omówić testowanie i wdrażanie Protected Audience na Androida, w tym kształt sygnałów przekazywanych między stronami. W przypadku kupujących dyskusje powinny obejmować strategie tworzenia i łączenia niestandardowych list odbiorców, co może obejmować omówienie ich definiowania. Wspólnie z partnerami integracyjnymi określ ramy czasowe integracji, od wstępnego testowania do wdrożenia, a także za obszary odpowiedzialne za poszczególne strony projektu.

Konfiguracja wersji beta (dostępna w IV kwartale)

Zarejestruj swoją organizację w Piaskownicy prywatności na Androida. Rejestracja jest wymagana, aby deweloperzy technologii reklamowych działali zgodnie z zasadami Piaskownicy prywatności i umożliwili im definiowanie tożsamości w wielu pakietach SDK i domenach.

Kwestie architektoniczne

Z myślą o kupujących i sprzedawcach funkcja Protected Audience umożliwia im przeprowadzanie aukcji reklam na urządzeniach. Podczas projektowania należy wziąć pod uwagę kilka ważnych kwestii:

Listy odbiorców i reklamy remarketingowe są przechowywane na urządzeniu.

W przeciwieństwie do reklam w całości przechowywanej na serwerach informacje o odbiorcach i reklamy remarketingowe są przechowywane na urządzeniu. Reklamy kontekstowe, które nie opierają się na danych z urządzenia do kierowania, pozostaną na serwerach. Platformy technologii reklamowych muszą się rozwijać, aby uwzględnić popyt na reklamy rozkładany na serwery i urządzenia.

Procesy określania stawek i aukcji odbywają się na urządzeniu

Oprócz przeprowadzania aukcji na serwerach platformy technologii reklamowych mają teraz możliwość ustalania cen i pozycjonowania żądań reklam przechowywanych na urządzeniu.

Technologie reklamowe często tak samo jak obecnie biorą udział w aukcjach reklam kontekstowych. Po zakończeniu aukcji sprzedawca może przeprowadzić aukcję na danym urządzeniu, aby ocenić zapisany na nim popyt na remarketing. Ponieważ te procesy działają teraz na urządzeniu, należy pamiętać o obowiązujących istniejących limitach, aby mieć pewność, że aukcja zakończy się w sposób zgodny z założeniami różnych partnerów integracyjnych w różnych przypadkach użycia remarketingu.

Strategia dotycząca danych

Platformy z branży technologii reklamowych powinny uwzględniać typy danych używane w aukcjach. Obecnie informacje te są zbierane z różnych źródeł, a następnie scentralizowane na serwerze. Aukcje w ramach Protected Audience API udostępniają kilka różnych ścieżek przekazywania tych danych. Na przykład: sygnały w czasie rzeczywistym, takie jak pozostały budżet, pochodzą z usługi par klucz-wartość jako zaufane sygnały, natomiast sygnały kontekstowe, takie jak pora dnia, są wysyłane od sprzedawców podczas aukcji. Sygnały te zostały szczegółowo omówione w odpowiednich sekcjach tego przewodnika.

Opracuj rozwiązanie

Przeprowadzenie aukcji z wykorzystaniem Protected Audience API wymaga spełnienia kilku kluczowych etapów. Kupujący muszą utworzyć grupę odbiorców, podać dane o stawkach, kierować reklamy na odbiorców i skonfigurować określanie stawek. Sprzedawca musi skonfigurować i rozpocząć aukcję, ocenić kandydujące reklamy i wybrać zwycięzcę. Niektóre z nich wymagają współpracy między stronami, aby zapewnić prawidłową przebieg aukcji. Sekcje poniżej opisują szczegółowo każdy etap i wyraźnie wskazują, która strona jest odpowiedzialna za jego wdrożenie.

Kupujący: budowanie grupy odbiorców

Kupujący zwykle zarządzają niestandardowymi odbiorcami. Niestandardowi odbiorcy zarządza się na urządzeniu, więc interfejs API służący do zarządzania nimi jest wywoływany na urządzeniu.

Jeśli masz własny pakiet SDK w aplikacji reklamodawcy, możesz zaimplementować ten kod bezpośrednio poprzez joinCustomAudience().

Jeśli nie masz własnego kodu SDK na urządzeniach, rozważ nawiązanie współpracy z dotychczasowym partnerem integracyjnym, który jest również dostawcą pakietu SDK. Zidentyfikuj partnera i nawiąż z nim współpracę, by zdefiniować umowę i przepływ zadań związanych z definiowaniem niestandardowych odbiorców i zarządzaniem nimi. W tym przewodniku używa się terminu „kupujący”, niezależnie od zastosowanej metody. Oto kilka przykładów:

• Jako kupujący poproś reklamodawcę o określenie listy odbiorców. Pakiet SDK partnera integracyjnego na urządzeniu może wysyłać do kupującego zdarzenia w aplikacji. Po spełnieniu wstępnie zdefiniowanych kryteriów kupujący wysyła do pakietu SDK wiadomość z prośbą o dołączenie do grupy niestandardowych odbiorców w imieniu kupującego.
• Pakiet SDK może być bezpośrednim właścicielem listy odbiorców. Reklamodawcy współpracują z dostawcą pakietu SDK, aby określić odbiorców. SDK monitoruje zdarzenia w aplikacji i w odpowiednim momencie dołącza do listy odbiorców oraz powiadamia kupującego o dołączeniu użytkownika do tej listy.

Prototypowa kampania remarketingowa: projektowanie niestandardowej grupy odbiorców

Niestandardowa lista odbiorców to grupa użytkowników o podobnych zainteresowaniach, którym mogą wyświetlać się reklamy spersonalizowane. Kupujący mogą pomagać reklamodawcom w tworzeniu w aplikacjach niestandardowych list odbiorców na podstawie aktywności użytkowników.

Protected Audience tworzy kontener na niestandardową listę odbiorców, który jest mapowany na określone niestandardowe zaangażowanie użytkownika zdefiniowane przez reklamodawcę. Obejmuje to zbiór reklam kandydujących, które można wyświetlić tej grupie odbiorców, oraz zbiór danych i mechanizmów ustalania stawek niestandardowych, które mogą służyć do filtrowania reklam i określania ich cen.

Konfiguracja i prototyp

• Za pomocą interfejsu API niestandardowych odbiorców możesz utworzyć i zapisać na urządzeniu listę odbiorców, która później będzie mogła zostać użyta w aukcji.
• Szczegółowe informacje o implementacji i korzystaniu z interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

Po skonfigurowaniu list niestandardowych odbiorców kupujący mogą obsługiwać różne przypadki użycia. Obejmuje to m.in. definiowanie reguł określania stawek dla typu reklamy lub kampanii, na którą są kierowane reklamy, oraz definiowanie listy reklam kandydujących. W tej sekcji omówiono kwestie związane z wypełnianiem i używaniem kluczowych pól w niestandardowej liście odbiorców.

Adres URL logiki ustalania stawek

Aukcje są prowadzone na urządzeniu, więc kupujący muszą wdrożyć punkt końcowy, który może zwracać logikę ustalania stawek w postaci kodu JavaScript. W naszym przewodniku dla programistów opisano wymagane podpisy dotyczące metod. Logika ustalania stawek ma dostęp do określonych sygnałów o użytkowniku podczas aukcji, jak opisano w kilku kolejnych sekcjach. Logikę ustalania stawek i konfigurację sygnałów użytkownika wyjaśniono w dalszej części tego artykułu.

Sygnały dotyczące określania stawek przez użytkowników

Kupujący mogą za pomocą UserBiddingSignals przekazywać w przyszłych aukcjach na danym urządzeniu posiadane przez siebie informacje na temat użytkownika lub samego kupującego. Mogą to być na przykład:

• Inne grupy odbiorców, do których użytkownik został dodany.
• własne statystyki dotyczące użytkownika, które reklamodawca dysponuje.

Ponieważ te sygnały są dostępne podczas aukcji, kupujący mogą w jej trakcie wykonywać działania związane z ustalaniem stawek niestandardowych, m.in.:

• Podnieś lub obniż stawkę na podstawie sygnałów ustalania stawek.
• Odfiltrowywanie konkretnych reklam z aukcji.

Dane dotyczące zaufanego określania stawek

W ramach wdrożenia Protected Audience API kupujący mogą za pomocą pary klucz-wartość uzyskiwać podczas aukcji dostęp do informacji w czasie rzeczywistym. W ramach tymczasowego mechanizmu kupujący i sprzedawca mogą pobierać te sygnały ustalania stawek z dowolnej usługi, w tym z tej, którą obsługują samodzielnie. Najczęstszym przykładem jest wyszukanie pozostałego budżetu na reklamy. W fazie programowania można symulować usługę i tworzyć na jej podstawie próbny punkt końcowy. Instrukcje konfiguracji znajdziesz w katalogu FledgeServerSpec w naszym repozytorium przykładowej aplikacji na GitHubie.

Pole TrustedBiddingData składa się z adresu URL i zestawu kluczy. Oto kilka kwestii, które należy wziąć pod uwagę podczas projektowania struktury kluczowej:

• Najprostszym sposobem jest dodanie klucza, który będzie odpowiadał bezpośrednio tworzonej grupie odbiorców. Usługa para klucz-wartość może wtedy zawierać wszystkie istotne informacje powiązane z odbiorcami.
• Budżet i stan reklamy to ważne kwestie, które należy wziąć pod uwagę w czasie rzeczywistym.
• Maksymalna stawka lub inne sygnały, które można wykorzystać, aby wycenić reklamę w aukcji. Te informacje można umieścić w reklamie na liście AdData, ale przechowywanie ich w usłudze klucz-wartość ułatwia ich aktualizowanie w razie potrzeby.

Lista AdData

Podczas tworzenia kampanii remarketingowej reklamodawcy zwykle uwzględniają wiele różnych typów reklam do wyświetlania użytkownikowi w danej grupie odbiorców, np. reklamują różne rabaty w zależności od wcześniejszego zaangażowania użytkownika w aplikację. Grupa odbiorców niestandardowych zawiera listę AdData, która zawiera reklamy kandydujące.

Ilość informacji dołączanych do każdej reklamy zależy od kupujących. Kwestie do rozważenia:

• Listę AdData można aktualizować na 2 sposoby:
  • Gdy aplikacja ma widoczną aktywność na pierwszym planie, może zainicjować listę, gdy dołączy użytkownika do niestandardowej listy odbiorców.
  • Podczas codziennej aktualizacji pobieranie inicjowane w tle. Urządzenie wysyła żądanie do obiektu daily_update_url uwzględnionego w wywołaniu joinCustomAudience i oczekuje odpowiedzi zawierającej zaktualizowaną listę AdData.
• Dodatkowe informacje o reklamach można uzyskać w trakcie aukcji. Przed aukcją urządzenie wysyła żądanie do usługi par klucz-wartość kupującego, która została podana w polu trustedBiddingData w polu joinCustomAudience. Jest to nowa usługa wchodząca w skład wdrożenia Protected Audience API przez kupujących. Więcej informacji o tej usłudze omówimy w dalszej części tego dokumentu.
• Podanie identyfikatora kreacji w reklamie może pomóc w wykonaniu określonych działań w odniesieniu do konkretnych kreacji. Reklamodawcy mogą na przykład wstrzymywać określone kreacje, a Ty chcesz pobierać ich identyfikatory z usługi par klucz-wartość w czasie rzeczywistym, a potem dopasowywać je do reklam na liście AdData.

Pole AdData powinno zawierać parametr render_url. URL renderowania zwycięskiej reklamy remarketingowej jest używany do renderowania reklamy. Oto kilka kwestii, które warto wziąć pod uwagę:

• URL renderowania ma próg k-anonimowości, dlatego nie uwzględniaj wąskich parametrów. Więcej informacji o tym progu k-anonimowości opublikujemy później.
• Ten adres URL powinien zawierać wszystkie informacje niezbędne do renderowania reklamy. Jeśli np. chcesz wyświetlać określone produkty, umieść identyfikatory produktów jako parametry w adresie URL.

Jedynym wymaganym polem w trakcie prototypowania jest pole renderUri, które wskazuje zasoby renderowania reklamy. Pole metadanych w komponencie AdData można zignorować podczas tworzenia rozwiązania. Przechodząc na wersję produkcyjną, zastanów się, jakie metadane są dla Ciebie istotne, ponieważ mogą one służyć do określania stawek.

Godzina aktywacji i wygaśnięcie

Możesz skorzystać z pól aktywacji i czasu wygaśnięcia, gdy chcesz, aby niestandardowa lista odbiorców kwalifikowała się do udziału w aukcjach tylko we wstępnie zdefiniowanym czasie. Pamiętaj, że istnieją pewne ograniczenia dotyczące opóźnienia aktywacji oraz różnic między czasem aktywacji a wygaśnięciem. Przykładowe zastosowania:

• Nieaktywny użytkownik (np. nie korzystał z aplikacji reklamodawcy w ciągu ostatnich 7 dni)
  • Za każdym razem, gdy użytkownik otworzy aplikację, kupujący może wywołać funkcję joinCustomAudience i skonfigurować activation_time tak, aby ustawiała sygnaturę czasową na 7 dni do przodu.
  • Jeśli upłynęło 7 dni od ostatniego uruchomienia aplikacji przez użytkownika, kwalifikuje się ona do ustalania stawek.
• Lista odbiorców sezonowa (dotyczy tylko konkretnego okresu w najbliższej przyszłości)
  • Kupujący może z wyprzedzeniem zacząć definiować odbiorców niestandardowych, którzy powinni móc określać stawki tylko w ustalonym wcześniej (niedalekiej) przyszłości.
  • Jeśli na przykład reklamodawca zakończy kampanię letnią w Stanach Zjednoczonych w 2022 r., jego kupujący może zadzwonić pod numer joinCustomAudience i skonfigurować activation_time jako sobotę, 20 sierpnia 2022 r. Jeśli kampania ma trwać tylko tydzień, kupujący może ustawić datę ważności na 27 sierpnia 2022 r. Po tym czasie niestandardowa lista odbiorców jest odfiltrowywana przez platformę podczas wyboru reklamy, a następnie będzie odfiltrowywana przez tę platformę.

Kupujący i sprzedawcy: wybór reklamy

Wybór reklam wymaga współpracy między kupującymi i sprzedawcami. Można to postrzegać jako czteroetapowy proces:

1. Sprzedawcy definiują strategię zapośredniczenia.
2. Sprzedawcy konfigurują aukcję i inicjują wybór reklamy.
3. Kupujący są zapraszani do udziału w aukcji przez konfigurację określoną przez sprzedawcę. Aby wybrać reklamę i stawkę, działa logika ustalania stawek kupującego.
4. W ramach tego procesu sprzedawca oceni kandydatów i wybiera zwycięską reklamę.

W celu ułatwienia programowania można symulować odpowiedzi na pytania związane z usługą pochodzące od kupujących i sprzedawców, co obejmuje logikę określania stawek i punktacji, dzięki czemu można skupić się na opracowaniu rozwiązania odpowiedniego dla danego zastosowania. Instrukcje konfigurowania pozorowanych punktów końcowych znajdziesz w katalogu FledgeServerSpec na GitHubie, a w przewodniku dla programistów znajdziesz instrukcje zastąpienia potrzeby zdalnego pobierania kodu JavaScript.

Sprzedawcy: definiowanie strategii zapośredniczenia

Protected Audience służy do obsługi zapośredniczenia kaskadowego. Pracujemy nad tą funkcją, ale będziemy udostępniać więcej informacji, gdy tylko będą dostępne. Na razie zapoznaj się z propozycją projektu dotyczącą zapośredniczenia kaskadowego w Protected Audience.

Sprzedawcy: konfigurowanie aukcji

Sprzedawcy są odpowiedzialni za skonfigurowanie aukcji i przekazanie informacji dotyczących procesu wyboru reklamy. Sprzedawcy mogą udostępnić informacje tylko wszystkim lub wybranym stronom. Mogą to być informacje, które masz lub dane, które podajesz w imieniu kupujących.

Konfiguracja i prototyp

• Sprzedawca może konfigurować i rozpoczynać aukcję, konfigurując obiekt AdSelectionConfig i używając interfejsu API AdSelection. Aby rozpocząć aukcję, wywołaj selectAds().
• Szczegółowe informacje o implementacji i korzystaniu z interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

W tej sekcji znajdziesz kwestie związane z wypełnianiem i używaniem kluczowych pól w konfiguracji wyboru reklamy.

• Prywatne środowisko wykonawcze obejmuje na urządzeniu tylko reklamy kierowane do niestandardowych odbiorców, więc wysłanie żądania reklamy kontekstowej przed uruchomieniem takiego środowiska pozwala rozważyć dodatkowe zapotrzebowanie.

• Zanim rozpoczniesz procedurę wyboru reklamy, uruchom żądanie reklamy, aby zebrać informacje od kupujących. Następnie użyj tych informacji do skonfigurowania wyboru reklam.

• Wielu kupujących mogło utworzyć na urządzeniu niestandardowe listy odbiorców, dlatego sprzedawcy muszą użyć pola kupujący, którzy korzystają z niestandardowych list odbiorców, by wskazać konkretnych kupujących, których chcesz uwzględnić w tym procesie. Tę listę można utworzyć na wiele sposobów. Oto kilka przykładów:

  • Statyczna lista kupujących, którą sprzedawca zawsze chce uwzględniać w procesie.
  • Lista kupujących, którzy wykazują chęć wzięcia udziału w odpowiedzi na reklamę. Ta opcja jest przydatna, gdy sprzedawca współpracuje z giełdami reklam i może nie mieć pełnej wiedzy o wszystkich kupujących.

• Sprzedawca może przekazać informacje do procesu na kilka sposobów:

  • Pole sygnałów wyboru reklamy jest dostępne dla wszystkich kupujących i sprzedawców, którzy biorą udział w aukcji w prywatnym środowisku wykonawczym. Służy do podawania informacji o możliwościach związanych z reklamą, takich jak rozmiar i format reklamy.
  • Pole sygnałów dla kupującego jest przekazywane konkretnemu kupującemu, który ma go używać w procesie ustalania stawek. Informacje te są dostarczane przez kupującego, a Ty, jako sprzedawca, musisz się zastanowić, jak je pobrać na urządzenie, by wykorzystać je podczas wyboru reklamy.
  • Pole sygnałów sprzedawcy to ostateczny sposób przekazywania informacji przez sprzedawcę. Ty jako sprzedawca wykorzystujesz te sygnały podczas oceniania reklam i filtrowania reklam, na przykład w celu włączenia kontroli bezpieczeństwa marki.

Kupujący: określanie stawek za boks reklamowy

Konfiguracja i prototyp

• Kupujący może dodać swoją logikę ustalania stawek do funkcji JavaScriptu generateBid(), która jest udostępniana z zestawu parametrów biddingLogicUrl podczas tworzenia obiektu CustomAudience. Możesz skonfigurować usługę próbną, korzystając z podanej specyfikacji, lub wdrożyć ten punkt końcowy na rzeczywistym serwerze.
• Szczegółowe informacje o implementacji i korzystaniu z interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

• Logika ustalania stawek działa na urządzeniu, a niektóre sygnały wykorzystywane w aukcji są wyszukiwane w czasie rzeczywistym. Zapoznaj się z listą ograniczeń dotyczących ograniczeń.
• W niektórych przypadkach użycia reklam warto skontaktować się ze sprzedawcą, aby upewnić się, że masz wielu kandydatów reklam i ich stawki, które należy uwzględnić na urządzeniu.

Projektowanie logiki ustalania stawek

Logika ustalania stawek kupującego musi być zaimplementowana za pomocą JavaScriptu i wykonywana na urządzeniu. Przewodnik dla programistów zawiera informacje o wymaganych podpisach oraz o różnych parametrach przekazywanych podczas aukcji. Logika ustalania stawek na urządzeniu ma dostęp do dodatkowych informacji przekazywanych jako parametry do funkcji generateBid().

Dostarczanie danych o stawkach

Sygnały dotyczące określania stawek w czasie rzeczywistym w ramach usług par klucz-wartość

Jako kupujący możesz pobierać podczas aukcji sygnały w czasie rzeczywistym ze swojej usługi par klucz-wartość. Wstępną implementację tej usługi znajdziesz w publicznym repozytorium Piaskownicy prywatności. Możesz też utworzyć własną usługę. Adres URL tej usługi jest określony na niestandardowej liście odbiorców jako trustedBiddingUrl, a platforma próbuje pobrać dane i udostępnić je funkcji generateBid za pomocą trusted_bidding_signals parameter. Musisz ustalić własną strukturę kluczy.

Sygnały kontekstowe i sygnały dotyczące użytkownika

Podczas prowadzenia aukcji na urządzeniu funkcja generateBid ma dostęp do dodatkowych sygnałów użytkownika. Te sygnały są przekazywane w polach contextual_signals i per_buyer_signals. Te pola to wszystkie obiekty JSON, których format musi zostać zdefiniowany przez kupujących i sprzedawców.

Pole contextual_signals zawiera istotne informacje o użytkowniku. Obiekt, w którym znajdują się te sygnały, jest tworzony przez usługę Protected Audience i przekazywany do logiki ustalania stawek. Jest on obecnie przekazywany jako pusty obiekt. Jeśli uważasz, że sygnał kontekstowy dotyczący użytkownika może być odpowiedni dla Twojego przypadku użycia, prześlij opinię.

Pole per_buyer_signals jest dostępne dla Twojej logiki ustalania stawek. Sprzedawca określa te wartości podczas tworzenia konfiguracji aukcji. Kupujący i sprzedawcy muszą współpracować, aby mieć pewność, że te dane będą zapisywane na urządzeniu i przekazywane do Twojego systemu do określania stawek. Przykłady użycia tego pola:

• Filtrowanie pod kątem bezpieczeństwa marki. Sprzedawca może przekazać kupującym informacje o klasyfikacji aplikacji, która wysłała żądanie reklamy, a kupujący może wykorzystać te informacje do odfiltrowania określonych reklam.
• Wysyłanie żądania embedding na potrzeby modelu ML uwzględniającego informacje kontekstowe.

Sprzedawcy: oceń i wybierz zwycięską reklamę

Konfiguracja i prototyp

• Sprzedawca może dodać swoje logiki punktacji do funkcji JavaScript scoreAd(), która jest udostępniana z zestawu parametrów scoringLogicUrl podczas tworzenia obiektu AdSelectionConfig. Możesz skonfigurować usługę próbną, korzystając z podanej specyfikacji, lub wdrożyć ten punkt końcowy na rzeczywistym serwerze.
• Szczegółowe informacje o implementacji i korzystaniu z interfejsu API znajdziesz w przewodniku dla programistów.

Projektowa logika punktacji

Sprzedawcy implementują logikę punktacji w języku JavaScript, który jest wykonywany na urządzeniu. Przewodnik dla programistów zawiera informacje o wymaganym podpisie oraz o różnych parametrach przekazywanych podczas aukcji. Oprócz tego logika punktowa na urządzeniu ma dostęp do dodatkowych informacji przekazywanych jako parametry do funkcji scoreAd.

Podaj dane punktowe

Sygnały w czasie rzeczywistym w ramach usług par klucz-wartość

Jako sprzedawca możesz pobierać sygnały w czasie rzeczywistym podczas aukcji ze swojej usługi par klucz-wartość. Wstępną implementację tej usługi znajdziesz w publicznym repozytorium Piaskownicy prywatności. Adres URL tej usługi jest określony w konfiguracji aukcji jako trustedScoringUri, a platforma próbuje pobrać dane i udostępnić je funkcji scoreAd za pomocą parametru trusted_scoring_signals. Musisz stworzyć własną strukturę kluczy.

Sygnały kontekstowe i sygnały dotyczące użytkownika

Podczas prowadzenia aukcji na urządzeniu funkcja scoreAd ma dostęp do dodatkowych sygnałów użytkownika. Te sygnały są przekazywane do funkcji oceniania w polu contextual_signal. Zawiera ono obiekty JSON, których format jest zdefiniowany przez kupujących i sprzedawców.

Pole contextual_signal zawiera informacje kontekstowe, które mogą być istotne dla użytkownika. Obiekt, w którym znajdują się te sygnały, jest tworzony przez Protected Audience API i przekazywany do logiki punktacji. Jest przekazywany jako pusty obiekt. Jeśli uważasz, że sygnał dotyczący użytkownika może być odpowiedni dla Twojego przypadku użycia, prześlij opinię do rozważenia.

Sprzedawcy: renderowanie reklamy

Sprzedawcy muszą wyrenderować zwycięską reklamę. Więcej informacji o renderowaniu zwycięskich reklam znajdziesz w ofercie pakietowej. Jest on wciąż w fazie projektowania.

Raportowanie wyników wyświetleń

Konfiguracja i prototyp

• Kupujący i sprzedawcy mogą dodać logikę raportowania do funkcji JavaScript reportWin() wywoływanej odpowiednio z parametru biddingLogicUrl lub scoringLogicUrl. Możesz skonfigurować usługę próbną, korzystając z podanej specyfikacji, lub wdrożyć ten punkt końcowy na rzeczywistym serwerze.
• Szczegółowe informacje o implementacji i korzystaniu z interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

Kupujący i sprzedawcy muszą wdrożyć funkcję reportWin w kodzie JavaScript zwróconym ze skonfigurowanych punktów końcowych. Ta metoda umożliwia wysyłanie danych z powrotem na serwery.

Piaskownica prywatności udostępnia też interfejs Attribution Reporting API, który służy do zarządzania raportami zbiorczymi i na poziomie zdarzenia. Więcej informacji znajdziesz w przewodniku po integracji.