Protected Audience: przewodnik po integracji

Wdrożenia Protected Audience (wcześniej FLEDGE) na urządzeniach z Androidem zwykle wymagają integracji aplikacji reklamodawców, aplikacji wydawców, sprzedawców i kupujących. Ten przewodnik jest przeznaczony dla partnerów, którzy planują zarządzać niestandardowymi listami odbiorców i przeprowadzać aukcje, w tym sieci reklamowych, które działają zarówno jako kupujący, jak i sprzedający. Różne kampanie reklamowe mogą mieć różne cele, a nie wszystkie funkcje list odbiorców chronionych są używane we wszystkich przypadkach użycia. W tym przewodniku staramy się wskazać czynności potrzebne do obsługi bardziej specjalistycznych przypadków.

Aby przygotować się do wdrożenia Protected Audience w produkcji na dużą skalę, partnerzy mogą rozpocząć testowanie, symulując punkty integracji z innymi podmiotami. Aby ułatwić Ci planowanie integracji, w tym przewodniku znajdziesz obszerne informacje o tym, jak zintegrować Protected Audience z aplikacjami na Androida. Może to obejmować funkcje, które nie zostały jeszcze zaimplementowane na obecnym etapie Piaskownicy prywatności w wersji Androida przeznaczonej dla deweloperów. W takich przypadkach podajemy wskazówki dotyczące harmonogramu.

Proces integracji z Protected Audience składa się z 4 kluczowych etapów, które zależą od różnych typów partnerów technologicznych:

1. Kupujący tworzy listy niestandardowych odbiorców.
2. Proces wyboru reklamy wybiera reklamę zwycięską.
   1. Aplikacja sprzedawcy inicjuje wybór reklamy.
   2. Usługi reklamowe wykonują kod filtrowania i określania stawek po stronie kupującego.
   3. Usługi reklamowe wykonują kod decyzji po stronie 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 sprzedawcy.

Te kroki ilustruje diagram poniżej:

Terminologia

• Reklamodawca: firma, która angażuje użytkowników poprzez kupowanie zasobów reklamowych.
• Wydawca: firma sprzedająca zasoby reklamowe, które są dostępne wraz z jej treściami.
• Kupujący: firma zajmująca się technologiami reklamowymi, 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 technologiczna zajmująca się reklamą, która działa zarówno jako kupujący, jak i sprzedający.
• Należy do firmy i jest przez nią zarządzana: firma, która pełni rolę wydawcy, sprzedawcy i kupującego.
• Partnerzy ds. integracji: firmy, z którymi musisz współpracować, aby przeprowadzić integrację z Protected Audience.

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

W tej sekcji znajdziesz opis wstępnych czynności, które pomogą Ci zrozumieć, jak działa Protected Audience, jak rozpocząć integrację z Protected Audience oraz jak współpracować z partnerami ds. integracji w zakresie wdrażania tej funkcji. Te działania mogą być wykonywane równolegle.

Poznaj Protected Audience

Najpierw zapoznaj się z interfejsami Protected Audience API i usługami.

1. Najpierw przeczytaj propozycję projektu, aby zapoznać się z interfejsem Protected Audience API i jego możliwościami.
2. W przewodniku dla deweloperów znajdziesz informacje o tym, jak wdrożyć kod i wywołania interfejsu API potrzebne do realizacji Twoich przypadków użycia, oraz usługi potrzebne do integracji z Protected Audience.
3. Prześlij opinię na temat projektu i wdrażania interfejsów Protected Audience API, usług i dokumentacji.
4. Zarejestruj się, aby otrzymywać powiadomienia o najnowszych funkcjach Piaskownicy prywatności.

Konfigurowanie i testowanie przykładowych aplikacji

Po zapoznaniu się z podstawami Protected Audience opisanymi wcześniej skonfiguruj i przetestuj przykładowe aplikacje.

1. Gdy będziesz gotowy do rozpoczęcia integracji, skonfiguruj środowisko programistyczne za pomocą najnowszej wersji Piaskownicy prywatności dla programistów.
2. Skonfiguruj wymagane punkty końcowe serwera. Aby rozpocząć ten proces, użyj przykładowych mocków z ulubionym rozwiązaniem do testowania interfejsu API.
3. Aby zapoznać się z zarządzaniem listami odbiorców niestandardowych, przepływem pracy związanym z wybieraniem reklam i raportowaniem wyświetleń, użyj kodu z naszej aplikacji przykładowej.

Współpraca z partnerem integracyjnym

Zaplanuj rozmowy z partnerami ds. integracji, aby omówić testowanie i wdrażanie Protected Audience na urządzeniach z Androidem, w tym kształt sygnałów przekazywanych między stronami. W przypadku kupujących dyskusje powinny dotyczyć strategii tworzenia i łączenia list odbiorców niestandardowych, co może obejmować dyskusje na temat sposobu definiowania list odbiorców. Współpracuj z partnerami ds. integracji, aby określić harmonogram integracji (od wstępnych testów do wdrożenia) oraz obszary, za które odpowiada każda ze stron.

Konfiguracja wersji beta (dostępna w IV kwartale)

Zarejestruj swoją organizację w Piaskownicy prywatności na Androida. Rejestracja jest wymagana, aby zapewnić, że deweloperzy technologii reklamowych działają zgodnie z zasadami Piaskownicy prywatności. Pozwala też deweloperom technologii reklamowych określić swoją tożsamość w różnych pakietach SDK i domenach.

Uwagi dotyczące architektury

Protected Audience umożliwia zarówno kupującym, jak i sprzedawcom prowadzenie aukcji reklam na urządzeniu. Ty i Twoi partnerzy ds. integracji powinniście wziąć pod uwagę kilka ważnych kwestii:

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

W przeciwieństwie do obecnego przechowywania reklam wyłącznie na serwerach informacje o odbiorcach i reklamy remarketingowe są przechowywane na urządzeniu. Reklamy kontekstowe, które nie wykorzystują danych z urządzenia do kierowania, pozostają na serwerach. Platformy technologiczne do obsługi reklam muszą się rozwijać, aby uwzględniać popyt na reklamy rozłożony między serwery i urządzenia.

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

Oprócz przeprowadzania aukcji na serwerach platformy technologiczne reklamowe mają teraz możliwość ustalania cen i rankingu popytu na reklamy przechowywanego na urządzeniu.

Typowym podejściem jest przeprowadzanie aukcji reklam kontekstowych w sposób analogiczny do tego, w jaki odbywają się one obecnie. Po zakończeniu aukcji sprzedawca może uruchomić aukcję na urządzeniu, aby ocenić popyt z remarketingu zapisany na urządzeniu. Ponieważ te procesy są teraz wykonywane na urządzeniu, warto pamiętać o dotychczasowych limitach, które zapewniają prawidłowe działanie aukcji w różnych przypadkach użycia remarketingu, zgodnie z projektem różnych partnerów integracyjnych.

Strategia dotycząca danych

Platformy technologiczne związane z reklamami powinny uwzględniać typy danych używanych w aukcjach. Obecnie te informacje są zbierane z różnych źródeł, a następnie centralizowane na serwerze. Aukcje Protected Audience oferują kilka różnych ścieżek przekazywania tych danych. Przykład: sygnały w czasie rzeczywistym, takie jak pozostały budżet, pochodzą z usługi klucz-wartość jako zaufane sygnały, podczas gdy sygnały kontekstowe, takie jak pora dnia, są wysyłane przez sprzedawców podczas przeprowadzania aukcji. Te sygnały są opisane bardziej szczegółowo w odpowiednich sekcjach tego przewodnika.

Tworzenie rozwiązania

Aby przeprowadzić aukcję z użyciem Protected Audience, musisz wykonać kilka kluczowych czynności. Kupujący muszą tworzyć listy odbiorców, podawać dane o stawkach, kierować reklamy na odbiorców i konfigurować stawki. Sprzedawca musi skonfigurować i wywołać aukcję, ocenić reklamy kandydujące i wybrać zwycięzcę. Niektóre z tych etapów wymagają współpracy obu stron, aby aukcja mogła przebiegać prawidłowo. W sekcjach poniżej znajdziesz szczegółowy opis każdego etapu i informacje o tym, która strona jest odpowiedzialna za jego wdrożenie.

Kupujący: tworzenie listy odbiorców

Kupujący zwykle zarządzają niestandardowymi grupami odbiorców. Grupami odbiorców niestandardowymi zarządza się na urządzeniu, dlatego interfejs API do zarządzania tymi grupami został zaprojektowany do wywoływania na urządzeniu.

Jeśli w aplikacji reklamodawcy jest dostępny własny pakiet SDK, możesz zaimplementować ten kod bezpośrednio za pomocą joinCustomAudience().

Jeśli nie masz własnego kodu pakietu SDK na urządzeniach, możesz nawiązać współpracę z dotychczasowym partnerem ds. integracji, który jest też dostawcą pakietu SDK. Znajdź tego partnera i współpracuj z nim, aby określić umowę i proces definiowania list niestandardowych odbiorców oraz zarządzania nimi. W tym przewodniku używamy terminu „kupujący” niezależnie od tego, które podejście jest stosowane. Oto kilka przykładowych podejść:

• Jako kupujący poproś reklamodawcę o zdefiniowanie listy odbiorców. Pakiet SDK partnera integracji na urządzeniu może wysyłać zdarzenia z aplikacji do kupującego. Gdy spełnione są wstępnie zdefiniowane kryteria, kupujący wysyła do pakietu SDK wiadomość o dołączeniu do listy odbiorców niestandardowych na kliencie w imieniu kupującego.
• Pakiet SDK może bezpośrednio zarządzać listą odbiorców. Reklamodawcy współpracują z dostawcą pakietu SDK, aby zdefiniować odbiorców. Pakiet SDK monitoruje zdarzenia w aplikacji i w odpowiednim momencie dołącza użytkownika do listy odbiorców, a także powiadamia kupującego o dołączeniu użytkownika do listy odbiorców.

Prototyp kampanii remarketingowej: tworzenie listy odbiorców niestandardowej

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

Protected Audience tworzy kontener dla listy niestandardowych odbiorców, który jest mapowany na określone przez reklamodawcę zaangażowanie użytkowników. Obejmuje to zbiór reklam, które mogą się wyświetlać danej grupie odbiorców, oraz zbiór niestandardowej logiki określania stawek i danych, które mogą być używane podczas aukcji do filtrowania i określania stawek reklam.

Konfiguracja i prototyp

• Użyj interfejsu API list niestandardowych odbiorców, aby utworzyć i zapisać na urządzeniu listę odbiorców, której można później używać w aukcji.
• Szczegółowe informacje o wdrażaniu i używaniu interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

Kupujący mogą obsługiwać różne przypadki użycia, konfigurując listy niestandardowych odbiorców. Obejmuje to zdefiniowanie logiki ustalania stawek dla typu reklamy lub kampanii, na którą kierowana jest ta lista odbiorców, zdefiniowanie listy reklam docelowych i inne podobne kwestie. W tej sekcji znajdziesz wskazówki dotyczące projektowania, które pomogą Ci wypełniać i wykorzystywać niektóre kluczowe pola w listach niestandardowych odbiorców.

Adres URL logiki ustalania stawek

Aukcje są przeprowadzane na urządzeniu, dlatego kupujący muszą wdrożyć punkt końcowy, który może zwracać logikę określania stawek w formie kodu JavaScript. W przewodniku dla programistów znajdziesz wymagane sygnatury metod. Logika określania stawek ma dostęp do pewnych sygnałów dotyczących użytkownika podczas aukcji, jak opisano w kolejnych sekcjach. Konfiguracja logiki ustalania stawek i sygnałów użytkownika została opisana dalej w tym artykule.

Sygnały dotyczące ustalania stawek przez użytkownika

Kupujący mogą używać UserBiddingSignals, aby przekazywać informacje o użytkowniku, które reklamodawca lub sam kupujący ma o nim, do przyszłych aukcji na tym urządzeniu. Może to obejmować takie informacje jak:

• inne listy odbiorców, do których został dodany użytkownik.
• Dane własne reklamodawcy o użytkowniku.

Ponieważ te sygnały są dostępne podczas aukcji, kupujący mogą wykonywać podczas niej operacje ustalania stawek niestandardowych, takie jak:

• podnosić lub obniżać stawki na podstawie sygnałów określania stawek.
• odfiltrowywać z aukcji konkretne reklamy;

Dane zaufane dotyczące określania stawek

W ramach wdrożenia chronionych list odbiorców kupujący mogą uzyskiwać informacje w czasie rzeczywistym z usługi klucz-wartość podczas aukcji. Jako tymczasowy mechanizm kupujący i sprzedający mogą pobierać te sygnały dotyczące określania stawek z dowolnej usługi, w tym z własnej. Najczęstszym przykładem jest sprawdzenie pozostałego budżetu na reklamy. Podczas programowania możesz utworzyć jej symulację i programować z użyciem tego punktu końcowego. 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 warto wziąć pod uwagę, projektując strukturę kluczy:

• Jednym z podejść jest uwzględnienie klucza, który w 100% odpowiada tworzonej liście odbiorców. Usługa par klucz-wartość może zawierać wszystkie istotne informacje powiązane z odbiorcami.
• Budżet i stan reklamy to ważne kwestie, które należy brać pod uwagę w czasie rzeczywistym.
• Maksymalna wysokość stawki lub inne sygnały, które można wykorzystać do określenia ceny reklamy w aukcji. Te informacje można uwzględnić w reklamie na liście AdData, ale przechowywanie ich w usłudze klucz-wartość umożliwia ich aktualizowanie w razie potrzeby.

Lista AdData

Podczas tworzenia kampanii remarketingowej reklamodawcy zazwyczaj biorą pod uwagę wiele różnych typów reklam, które mogą wyświetlać użytkownikom na liście odbiorców, np. reklamy różnych zniżek na podstawie wcześniejszych interakcji użytkownika z aplikacją. Lista odbiorców niestandardowych zawiera listę AdData z reklamami docelowymi.

Kupujący decydują, ile informacji uwzględnić w przypadku każdej reklamy. Oto kilka kwestii, które warto wziąć pod uwagę:

• Listę AdData można aktualizować na 2 sposoby:
  • Gdy aplikacja ma widoczną aktywność na pierwszym planie, może utworzyć listę, gdy dołączy do niej użytkownika.
  • Podczas codziennie wykonywanej aktualizacji w tle. Urządzenie wysyła żądanie do daily_update_url podanego w wywołaniu joinCustomAudience i oczekuje odpowiedzi zawierającej zaktualizowaną listę AdData.
• W momencie aukcji możemy poprosić o dodatkowe informacje o reklamach. Przed aukcją urządzenie wysyła żądanie do usługi klucz-wartość kupujących, która została podana w polu trustedBiddingData w joinCustomAudience. Usługa klucz-wartość to nowa usługa, która jest częścią wdrażania przez kupujących chronionych odbiorców. Więcej informacji o tej usłudze znajdziesz w dalszej części tego dokumentu.
• Dodanie identyfikatora kreacji do reklamy może ułatwić Ci wykonywanie określonych działań dotyczących konkretnych kreacji. Na przykład reklamodawcy mogą wstrzymywać wyświetlanie określonych kreacji, a Ty chcesz pobrać ich identyfikatory z usługi pary klucz-wartość w czasie rzeczywistym, a potem dopasować je do reklam na liście AdData.

Wartość AdData powinna zawierać wartość render_url. Adres URL renderowania zwycięskiej reklamy remarketingowej służy do renderowania reklamy. Oto kilka kwestii, które należy wziąć pod uwagę:

• Adres URL renderowania ma próg k-anonimowości, więc unikaj dodawania wąskich parametrów. Więcej informacji o tym progu k-anonimowości zostanie opublikowanych w późniejszym terminie.
• Ten adres URL powinien zawierać wszystkie informacje potrzebne do wyrenderowania reklamy. Jeśli na przykład chcesz wyświetlać określone produkty, umieść ich identyfikatory jako parametry w adresie URL.

Podczas tworzenia prototypu jedynym wymaganym polem jest renderUri, które wskazuje zasoby renderowania reklamy. Podczas tworzenia rozwiązania możesz zignorować pole metadanych AdData. Gdy wprowadzasz rozwiązanie do wersji produkcyjnej, zastanów się, które metadane są dla Ciebie istotne, ponieważ mogą one służyć do dostosowywania stawek podczas generowania stawek.

Czas aktywacji i czas wygaśnięcia

Pola czasu aktywacji i wygaśnięcia możesz używać w przypadkach, gdy lista niestandardowych odbiorców powinna kwalifikować się do udziału w aukcjach tylko w określonym czasie. Pamiętaj, że istnieją pewne ograniczenia dotyczące tego, jak długo można opóźnić aktywację i jaki może być czas między aktywacją a wygaśnięciem. Przykładowe przypadki użycia:

• Nieaktywny użytkownik (np. użytkownik, który nie korzystał z aplikacji reklamodawcy w ciągu ostatnich 7 dni)
  • Za każdym razem, gdy użytkownik otworzy aplikację, kupujący może zadzwonić do joinCustomAudience i skonfigurować activation_time, aby sygnatura czasowa była ustawiona na 7 dni w przyszłości.
  • Lista odbiorców kwalifikuje się do określania stawek, jeśli od ostatniego otwarcia aplikacji przez użytkownika minęło 7 dni.
• Odbiorcy sezonowi (odbiorcy, którzy są ważni tylko w określonym czasie w najbliższej przyszłości)
  • Kupujący może z wyprzedzeniem zacząć definiować listy odbiorców niestandardowych, które powinny być dostępne do określania stawek tylko w określonym z wyprzedzeniem (bliskim) terminie.
  • Jeśli np. reklamodawca prowadzi w 2022 r. w Stanach Zjednoczonych kampanię na koniec lata, jej kupujący może wywołać funkcję joinCustomAudience i skonfigurować parametr activation_time na sobotę 20 sierpnia 2022 r. Jeśli kampania trwa tylko tydzień, kupujący może ustawić datę wygaśnięcia na 27 sierpnia 2022 r. Po tym terminie platforma odfiltrowuje listę odbiorców niestandardowych podczas wyboru reklam, a potem usunie ją.

Kupujący i sprzedający: wybór reklamy

Wybór reklam wymaga współpracy kupujących i sprzedawców. Proces ten składa się z 4 etapów:

1. Sprzedawcy określają strategię zapośredniczenia.
2. Sprzedawcy konfigurują aukcję i inicjują wybór reklam.
3. Kupujący są zapraszani do udziału w aukcji za pomocą konfiguracji zdefiniowanej przez sprzedawcę. Wykonana zostaje logika ustalania stawek kupującego, aby wybrać reklamę i stawkę.
4. Zastosowana zostaje logika decyzyjna sprzedawcy, która przypisuje punkty kandydatom i wybiera reklamę zwycięską.

Aby ułatwić rozwój, możesz zasymulować odpowiedzi usług dla kupujących i sprzedawców, co obejmuje logikę określania stawek i oceniania, dzięki czemu możesz skupić się na tworzeniu tego, co jest istotne dla Twojego przypadku użycia. Instrukcje konfigurowania mockowych punktów końcowych znajdziesz w katalogu FledgeServerSpec na GitHubie, a instrukcje na temat pomijania pobierania JavaScriptu z dalu – w przewodniku dla programistów.

Sprzedawcy: definiowanie strategii zapośredniczenia

Protected Audience ma na celu wspieranie zapośredniczenia kaskadowego. Ta funkcja jest w trakcie tworzenia. Więcej informacji podamy, gdy tylko będzie ona dostępna. Na razie zapoznaj się z propozycją projektu dotyczącą zapośredniczenia kaskadowego w przypadku chronionych list odbiorców.

Sprzedawcy: konfigurowanie aukcji

Sprzedawcy odpowiadają za konfigurowanie aukcji i przekazywanie informacji do procesu wyboru reklamy. Sprzedawcy mogą udostępnić informacje wszystkim lub tylko wybranym stronom. Mogą to być informacje, które posiadasz lub które udostępniasz w imieniu kupujących.

Konfiguracja i prototyp

• Sprzedawca może skonfigurować i rozpocząć aukcję, konfigurując obiekt AdSelectionConfig i korzystając z interfejsu API AdSelection. Wywołaj aukcję, wywołując funkcję selectAds().
• Szczegółowe informacje o wdrażaniu i używaniu interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

W tej sekcji znajdziesz wskazówki dotyczące projektowania i wypełniania pól kluczowych w konfiguracji wyboru reklam.

• Środowisko prywatnego wykonania obejmuje tylko reklamy dla niestandardowych list odbiorców na urządzeniu, więc wcześniejsze wysłanie żądania reklamy kontekstowej pozwala uwzględnić dodatkowy popyt.

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

• Ponieważ wielu kupujących mogło utworzyć na urządzeniu niestandardowe listy odbiorców, sprzedawcy muszą użyć pola Kupujący na niestandardowych listach odbiorców, aby wskazać konkretnych kupujących, których mają obejmować te procesy. Listę można stworzyć na wiele sposobów. Oto kilka przykładów:

  • Statyczna lista kupujących, których sprzedawca chce zawsze uwzględniać w procesie.
  • Lista kupujących, którzy chcą wziąć udział w reagowaniu na reklamę. Ta opcja jest przydatna, jeśli sprzedawca współpracuje z giełdami reklamowymi i może nie mieć pełnej wiedzy o wszystkich kupujących.

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

  • Pole sygnałów wyboru reklam jest dostępne dla wszystkich kupujących i sprzedawców, którzy biorą udział w aukcji w ramach prywatnego środowiska wykonawczego. Używaj go, aby podawać informacje o możliwościach reklamowych, np. rozmiar i format reklamy.
  • Pole Sygnały według kupującego jest przekazywane do konkretnego kupującego, aby służyć do ustalania stawek. Te informacje są podawane przez kupującego, a Ty jako sprzedawca musisz zastanowić się, jak uzyskać te informacje na urządzeniu, aby móc ich używać podczas wyboru reklam.
  • Pole sygnały sprzedawcy to ostatni sposób, w jaki sprzedawca może przekazać informacje do procesu. Ty jako sprzedawca używasz tych sygnałów podczas oceniania reklam i filtrowania reklam, np. włączania sprawdzania bezpieczeństwa marki.

Kupujący: określanie stawek za boks reklamowy

Konfiguracja i prototyp

• Kupujący może dodać swoją logikę określania stawek do funkcji JavaScript generateBid(), która jest wyświetlana z zestawu parametrów biddingLogicUrl podczas tworzenia CustomAudience. Możesz skonfigurować fikcyjną usługę, korzystając z podanych specyfikacji, lub zaimplementować ten punkt końcowy na rzeczywistym serwerze.
• Szczegółowe informacje o wdrażaniu i używaniu interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

• Logika określania stawek jest wykonywana na urządzeniu, a niektóre sygnały używane w aukcji są zapytywane w czasie rzeczywistym. Informacje o ograniczeniach znajdziesz na liście ograniczeń.
• W przypadku niektórych zastosowań reklam ważne jest, aby współpracować ze sprzedawcą i upewnić się, że na urządzeniu jest dostępnych kilka reklam i ich stawek.

Projektowanie strategii ustalania stawek

Logika określania stawek przez kupujących musi zostać zaimplementowana za pomocą JavaScriptu i wykonywana na urządzeniu. Przewodnik dla programistów zawiera informacje o wymaganym podpisie oraz szczegóły dotyczące różnych parametrów przekazywanych podczas aukcji. Logika określania stawek na urządzeniu ma dostęp do dodatkowych informacji przekazywanych jako parametry funkcji generateBid().

Dostarczanie danych o określaniu stawek

Sygnały ustalania stawek w czasie rzeczywistym z użyciem usług klucz-wartość

Jako kupujący możesz pobierać sygnały w czasie rzeczywistym z posiadanej usługi klucz-wartość podczas aukcji. Początkowe wdrożenie tej usługi znajdziesz w publicznym repozytorium Piaskownicy prywatności. Możesz też utworzyć własną usługę. Adres URL tej usługi jest podany jako trustedBiddingUrl w przypadku niestandardowej listy odbiorców, a platforma próbuje pobrać dane i udostępnić je funkcji generateBid za pomocą trusted_bidding_signals parameter. Musisz utworzyć własną strukturę kluczy.

sygnały kontekstowe i użytkownika.

Funkcja generateBid ma dostęp do dodatkowych sygnałów użytkownika podczas przeprowadzania aukcji na urządzeniu. Te sygnały są przekazywane za pomocą pól contextual_signals i per_buyer_signals. Wszystkie te pola to obiekty JSON, których format musi zostać zdefiniowany przez kupujących i sprzedających.

Pole contextual_signals zawiera informacje o użytkowniku, które mogą być istotne. Obiekt zawierający te sygnały jest tworzony przez Protected Audience i przekazywany do logiki ustalania stawek. Jest on przekazywany jako pusty obiekt. Jeśli uważasz, że sygnał kontekstowy o użytkowniku może być istotny w Twoim przypadku użycia, prześlij opinię do rozpatrzenia.

Pole per_buyer_signals jest udostępniane logice określania stawek. Sprzedawca ustawia te wartości podczas tworzenia konfiguracji aukcji. Kupujący i sprzedający muszą współpracować, aby te dane były dostępne na urządzeniu i przekazywane do logiki ustalania stawek. Oto kilka przykładowych zastosowań tego pola:

• Filtrowanie pod kątem bezpieczeństwa marki. Sprzedawca może przekazać kupującym niektóre informacje o klasyfikacji aplikacji, która prosi o reklamę. Kupujący może wykorzystać te informacje do odfiltrowywania określonych reklam.
• Przesyłanie wektora dystrybucyjnego dla modelu ML, który uwzględnia informacje kontekstowe.

Sprzedawcy: ocenianie i wybieranie zwycięskiej reklamy

Konfiguracja i prototyp

• Podczas tworzenia AdSelectionConfig sprzedawca może dodać swoją logikę punktacji do funkcji JavaScript scoreAd(), która jest obsługiwana przez zestaw parametrów scoringLogicUrl. Możesz skonfigurować fikcyjną usługę, korzystając z podanych specyfikacji, lub zaimplementować ten punkt końcowy na rzeczywistym serwerze.
• Szczegółowe informacje o wdrażaniu i używaniu interfejsu API znajdziesz w przewodniku dla programistów.

Projektowanie logiki punktacji

Sprzedawcy implementują logikę punktacji w JavaScript, który jest wykonywany na urządzeniu. Przewodnik dla programistów zawiera informacje o wymaganym podpisie i szczegółach różnych parametrów przekazywanych podczas aukcji. Dodatkowo logika punktacji na urządzeniu ma dostęp do dodatkowych informacji przekazywanych jako parametry do funkcji scoreAd.

Dane o ocenie dostawcy

Sygnały oceny w czasie rzeczywistym z usługami par klucz-wartość

Jako sprzedawca możesz pobierać sygnały w czasie rzeczywistym podczas aukcji z usługi klucz-wartość, której jesteś właścicielem. Początkowe wdrożenie tej usługi można znaleźć w publicznym repozytorium Piaskownicy prywatności. Adres URL tej usługi jest określony jako trustedScoringUri w konfiguracji aukcji, a platforma próbuje pobrać dane i udostępnić je funkcji scoreAd za pomocą parametru trusted_scoring_signals. Należy utworzyć własną strukturę kluczy.

sygnały kontekstowe i użytkownika.

Funkcja scoreAd ma dostęp do dodatkowych sygnałów użytkownika podczas przeprowadzania aukcji na urządzeniu. Te sygnały są przekazywane do funkcji punktacji za pomocą pola contextual_signal. To pole zawiera obiekty JSON, których format jest definiowany przez kupujących i sprzedających.

Pole contextual_signal zawiera informacje kontekstowe, które mogą być istotne w przypadku danego użytkownika. Obiekt zawierający te sygnały jest tworzony przez Protected Audience i przekazywany do Twojej logiki punktacji. Jest on przekazywany jako pusty obiekt. Jeśli uważasz, że sygnał dotyczący użytkownika może być istotny w Twoim przypadku, prześlij opinię, abyśmy mogli go wziąć pod uwagę.

Sprzedawcy: renderowanie reklamy

Sprzedawcy muszą wyrenderować reklamę zwycięską. Więcej informacji o tym, jak renderowane są reklamy, które wygrały, znajdziesz w propozycji projektu. Ta funkcja jest nadal opracowywana.

Raportowanie wyników dotyczących wyświetleń

Konfiguracja i prototyp

• Kupujący i sprzedający mogą dodać logikę raportowania do funkcji JavaScript reportWin(), która jest wyświetlana odpowiednio z parametrów biddingLogicUrl lub scoringLogicUrl. Możesz skonfigurować fikcyjną usługę, korzystając z podanych specyfikacji, lub zaimplementować ten punkt końcowy na rzeczywistym serwerze.
• Szczegółowe informacje o wdrażaniu i używaniu interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

Kupujący i sprzedający muszą zaimplementować funkcję reportWin w kodzie JavaScript zwracanym przez skonfigurowane punkty końcowe. Ta metoda umożliwia wysyłanie danych z powrotem na Twoje serwery.

Piaskownica prywatności udostępnia też interfejs Attribution Reporting API do zarządzania raportami na poziomie zdarzenia i raportami zbiorczymi. Więcej informacji znajdziesz w przewodniku integracji.

Polecane dla Ciebie

• Uwaga: tekst linku jest wyświetlany, gdy obsługa JavaScript jest wyłączona
• Przewodnik dla programistów dotyczący interfejsu Protected Audience API na Androida
• Obsługa kierowania na niestandardowych odbiorców za pomocą interfejsu Protected Audience API
• Ograniczenie liczby wyświetleń na użytkowników z listy Protected Audience