Protected Audience: przewodnik po integracji

Implementacje interfejsu Protected Audience (wcześniej FLEDGE) na Androidzie zwykle obejmują integrację między aplikacjami reklamodawców, aplikacjami wydawców, sprzedawcami i kupującymi. Ten przewodnik jest przeznaczony dla partnerów, którzy planują zarządzać niestandardowymi listami odbiorców i przeprowadzać aukcje, w tym dla sieci technologii 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 Protected Audience są używane we wszystkich przypadkach. W tym przewodniku staramy się w miarę możliwości wskazywać kroki, które należy wykonać w bardziej specjalistycznych przypadkach.

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

Proces integracji interfejsu Protected Audience API obejmuje 4 główne etapy, które są realizowane przez różne typy partnerów technologii reklamowych:

1. Kupujący tworzy niestandardowe listy odbiorców.
2. Proces wyboru reklamy wyłania zwycięską reklamę.
   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 dotyczące wyświetleń reklam są udostępniane zarówno kupującemu, jak i sprzedawcy.

Te kroki ilustruje poniższy diagram:

Terminologia

• Reklamodawca: firma, która angażuje użytkowników poprzez kupowanie zasobów reklamowych.
• Wydawca: firma, która sprzedaje zasoby reklamowe dostępne obok jej treści.
• 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 pomaga wydawcom sprzedawać zasoby reklamowe.
• Sieć: firma z branży technologii reklamowych, która działa zarówno jako kupujący, jak i sprzedający.
• Należące do firmy i przez nią obsługiwane: firma, która jest wydawcą, sprzedawcą i kupującym.
• Partnerzy integracyjni: firmy, z którymi musisz współpracować, aby skutecznie przeprowadzić integrację z Protected Audience.

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

W tej sekcji znajdziesz zestaw początkowych działań, które pomogą Ci zrozumieć, jak działa Protected Audience, jak rozpocząć integrację z tym interfejsem API i jak współpracować z partnerami integracyjnymi w zakresie wdrażania Protected Audience. Te działania mogą być wykonywane równolegle.

Zapoznaj się z Protected Audience

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

1. Zacznij od przeczytania propozycji projektu, aby zapoznać się z interfejsem Protected Audience API i jego możliwościami.
2. Więcej informacji o tym, jak włączyć kod i wywołania interfejsu API potrzebne w Twoich przypadkach użycia, oraz o usługach niezbędnych do integracji z Protected Audience, znajdziesz w przewodniku dla deweloperów.
3. Przesyłaj opinie dotyczące projektu i wdrożenia interfejsów Protected Audience API, usług i dokumentacji.
4. Zarejestruj się, aby otrzymywać aktualizacje i być na bieżąco z najnowszymi funkcjami 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(-a) do rozpoczęcia integracji, skonfiguruj środowisko programistyczne za pomocą najnowszej wersji przedpremierowej Piaskownicy prywatności dla programistów.
2. Skonfiguruj wymagane punkty końcowe serwera. Aby rozpocząć ten proces, użyj przykładowych atrap z wybranym rozwiązaniem do testowania interfejsu API.
3. Skopiuj i uruchom kod w naszej przykładowej aplikacji, aby zapoznać się z zarządzaniem odbiorcami niestandardowymi, procesem wyboru reklam i raportowaniem wyświetleń.

Zaangażowanie partnera integracyjnego

Zaplanuj rozmowy z partnerami integracyjnymi, aby omówić testowanie i wdrażanie interfejsu Protected Audience API na Androidzie, w tym kształt sygnałów przekazywanych między stronami. W przypadku kupujących dyskusje powinny obejmować strategie tworzenia niestandardowych list odbiorców i dołączania do nich, 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 po wdrożenie, oraz obszary, za które każda ze stron jest odpowiedzialna w procesie projektowania.

Konfiguracja wersji beta (dostępna w IV kwartale)

Zarejestruj swoją organizację w Piaskownicy prywatności na Androida. Rejestracja jest wymagana, aby mieć pewność, że deweloperzy technologii reklamowych działają zgodnie z zasadami Piaskownicy prywatności. Umożliwia ona deweloperom technologii reklamowych określanie swojej tożsamości w wielu pakietach SDK i domenach.

Kwestie architektoniczne

Zarówno kupujący, jak i sprzedawcy mogą dzięki Protected Audience przeprowadzać aukcje reklam na urządzeniu. W projektach należy uwzględnić kilka kluczowych kwestii:

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

W przeciwieństwie do obecnego sposobu przechowywania reklam w całości na serwerach informacje o odbiorcach i reklamy remarketingowe są przechowywane na urządzeniu. Reklamy kontekstowe, które nie korzystają z danych na urządzeniu do kierowania, nadal będą przechowywane na serwerach. Platformy technologii reklamowej muszą uwzględniać popyt na reklamy rozproszony między serwery i urządzenia.

Procesy ustalania stawek i aukcji odbywają się na urządzeniu.

Platformy technologii reklamowych mają teraz możliwość ustalania cen i rankingu popytu na reklamy przechowywane na urządzeniu, a nie tylko przeprowadzania aukcji na serwerach.

Powszechnym podejściem jest to, że technologie reklamowe przeprowadzają aukcje reklam kontekstowych tak jak obecnie. Po zakończeniu aukcji sprzedawca może przeprowadzić aukcję na urządzeniu, aby ocenić popyt na remarketing zapisany na urządzeniu. Biorąc pod uwagę, że te procesy działają teraz na urządzeniu, należy pamiętać o istniejących limitach, które pozwalają sprawdzić, czy aukcja przebiega w całości zgodnie z założeniami różnych partnerów integracyjnych w różnych przypadkach użycia remarketingu.

Strategia dotycząca danych

Platformy technologii reklamowych powinny uwzględniać typy danych używanych na aukcjach. Obecnie te informacje są zbierane z różnych źródeł, a następnie centralizowane na serwerze. Aukcje z użyciem Protected Audience API oferują kilka różnych sposobów 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, natomiast sygnały kontekstowe, takie jak pora dnia, są wysyłane przez sprzedawców podczas przeprowadzania aukcji. Sygnały te są szczegółowo opisane w odpowiednich sekcjach tego przewodnika.

Tworzenie rozwiązania

Przeprowadzenie aukcji z użyciem Protected Audience API obejmuje kilka kluczowych etapów. Kupujący muszą utworzyć listę odbiorców, dostarczyć dane o licytowaniu, kierować reklamy na odbiorców i skonfigurować licytowanie. Sprzedawca musi skonfigurować i uruchomić aukcję, ocenić reklamy kandydatów 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ółowe informacje o każdym etapie oraz wyraźne wskazanie, która strona jest odpowiedzialna za wdrożenie.

Kupujący: budowanie listy odbiorców

Kupujący zwykle zarządzają niestandardowymi grupami odbiorców. Grupy odbiorców niestandardowych są zarządzane na urządzeniu, dlatego interfejs API do zarządzania nimi jest przeznaczony do wywoływania na urządzeniu.

Jeśli w aplikacji reklamodawcy znajduje się Twój pakiet SDK, możesz zaimplementować ten kod bezpośrednio za pomocą joinCustomAudience().

Jeśli nie masz własnego kodu SDK na urządzeniach, możesz nawiązać współpracę z dotychczasowym partnerem integracyjnym, który jest też dostawcą pakietu SDK. Znajdź tego partnera i współpracuj z nim, aby określić umowę i przepływ pracy związany z definiowaniem niestandardowych list odbiorców i zarządzaniem nimi. W tym przewodniku używamy terminu „kupujący” niezależnie od zastosowanego podejścia. Przykładowe podejścia:

• Poproś reklamodawcę o zdefiniowanie odbiorców. Pakiet SDK partnera integracji na urządzeniu może wysyłać zdarzenia w aplikacji do kupującego. Gdy zostaną spełnione wstępnie zdefiniowane kryteria, kupujący wysyła do pakietu SDK wiadomość z prośbą o dołączenie do listy odbiorców niestandardowych na urządzeniu klienta w imieniu kupującego.
• Pakiet SDK może być bezpośrednim właścicielem odbiorców. Reklamodawcy współpracują z dostawcą pakietu SDK, aby zdefiniować listę odbiorców. Pakiet SDK monitoruje zdarzenia w aplikacji i w odpowiednim momencie dołącza użytkownika do grupy odbiorców oraz powiadamia kupującego, że użytkownik został dodany do grupy odbiorców.

Prototyp kampanii remarketingowej: projektowanie niestandardowej listy odbiorców

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

Protected Audience tworzy kontener dla niestandardowej listy odbiorców, który jest mapowany na określone niestandardowe zaangażowanie użytkowników zdefiniowane przez reklamodawcę. Obejmuje to zbiór reklam, które mogą być wyświetlane tym odbiorcom, oraz zbiór niestandardowej logiki określania stawek i danych, które można wykorzystać podczas aukcji do filtrowania i wyceniania reklam.

Konfiguracja i prototyp

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

Uwagi dotyczące projektu

Kupujący mogą obsługiwać różne przypadki użycia, konfigurując niestandardowe listy odbiorców. Obejmuje to określanie logiki ustalania stawek w przypadku typu reklamy lub kampanii, na które kierowani są odbiorcy, określanie listy reklam do wyświetlenia i podobne kwestie. Ta sekcja zawiera wskazówki dotyczące wypełniania i używania niektórych kluczowych pól w przypadku niestandardowych list odbiorców.

Adres URL logiki określania stawek

Aukcje są przeprowadzane na urządzeniu, więc kupujący muszą wdrożyć punkt końcowy, który może zwracać logikę określania stawek w formacie JavaScript. Wymagane sygnatury metod opisuje nasz przewodnik dla programistów. Logika określania stawek ma dostęp do niektórych sygnałów dotyczących użytkownika podczas aukcji, co opisujemy w kolejnych sekcjach. Logika określania stawek i konfiguracja sygnałów użytkowników zostały omówione w dalszej części tego artykułu.

Sygnały dotyczące ustalania stawek przez użytkowników

Kupujący mogą używać UserBiddingSignals, aby przekazywać do przyszłych aukcji na urządzeniu informacje o użytkowniku, które ma reklamodawca lub sam kupujący. Mogą to być na przykład:

• Inne listy odbiorców, do których został dodany użytkownik.
• Dane własne reklamodawcy dotyczące użytkownika.

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

• Podnoszenie lub obniżanie stawek na podstawie sygnałów uwzględnianych przy określaniu stawek.
• odfiltrowywać z aukcji konkretne reklamy;

Dane dotyczące określania stawek zaufanych

W ramach implementacji Protected Audience kupujący mogą uzyskiwać dostęp do informacji w czasie rzeczywistym podczas aukcji z usługi klucz-wartość. Jako tymczasowy mechanizm kupujący i sprzedawca mogą pobierać te sygnały określania stawek z dowolnej usługi, w tym z usługi, którą sami obsługują. Najczęstszym przykładem jest sprawdzanie pozostałego budżetu na reklamy. Podczas programowania można imitować tę usługę i programować na podstawie tego imitowanego punktu końcowego. Instrukcje konfiguracji znajdziesz w katalogu FledgeServerSpec w naszym przykładowym repozytorium aplikacji w GitHubie.

Pole TrustedBiddingData składa się z adresu URL i zestawu kluczy. Oto kilka kwestii, które warto wziąć pod uwagę przy projektowaniu struktury kluczy:

• Jednym ze sposobów jest uwzględnienie klucza, który jest mapowany w stosunku 1:1 do tworzonych odbiorców. Usługa klucz-wartość może wtedy zawierać wszystkie istotne informacje powiązane z odbiorcami.
• W czasie rzeczywistym należy brać pod uwagę budżet i stan reklamy.
• Maksymalna kwota stawki lub inne sygnały, których można użyć do ustalenia ceny reklamy na aukcji. Możesz uwzględnić te informacje 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 zwykle rozważają wiele różnych typów reklam, które można wyświetlać użytkownikom z danej listy odbiorców, np. reklamowanie różnych rabatów w zależności od wcześniejszego zaangażowania użytkownika w aplikację. Lista odbiorców niestandardowych zawiera listę AdData z reklamami do wyświetlenia.

Zakres informacji, które mają być uwzględniane w przypadku poszczególnych reklam, zależy od decyzji kupujących. Kwestie, które warto wziąć pod uwagę:

• Listę AdData można zaktualizować na 2 sposoby:
  • Gdy aplikacja ma widoczną aktywność na pierwszym planie, może zainicjować listę, gdy doda użytkownika do odbiorców niestandardowych.
  • Podczas codziennej aktualizacji pobieranie jest inicjowane w tle. Urządzenie wysyła żądanie do daily_update_url zawartego w wywołaniu joinCustomAudience i oczekuje odpowiedzi zawierającej zaktualizowaną listę AdData.
• Dodatkowe informacje o reklamach można uzyskać w momencie aukcji. Przed aukcją urządzenie wysyła żądanie do usługi klucz-wartość kupujących podanej w polu trustedBiddingData w joinCustomAudience. Usługa klucz-wartość to nowa usługa, która jest częścią implementacji Protected Audience przez kupujących. Więcej informacji o tej usłudze znajdziesz w dalszej części tego dokumentu.
• Umieszczenie identyfikatora kreacji w reklamie może pomóc Ci w wykonywaniu określonych działań w przypadku konkretnych kreacji. Na przykład reklamodawcy mogą wstrzymywać wyświetlanie konkretnych kreacji, a Ty chcesz pobierać identyfikatory tych kreacji z usługi klucz-wartość w czasie rzeczywistym, a następnie dopasowywać je do reklam na liście AdData.

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

• Adres URL renderowania ma próg k-anonimowości, więc unikaj uwzględniania wąskich parametrów. Więcej informacji o tym progu k-anonimowości opublikujemy w późniejszym terminie.
• Ten adres URL powinien zawierać wszystkie informacje niezbędne do wyświetlenia reklamy. Jeśli na przykład chcesz wyświetlać określone produkty, umieść identyfikatory produktów 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 w AdData. W miarę wdrażania rozwiązania w środowisku produkcyjnym zastanów się, które metadane są dla Ciebie istotne, ponieważ można ich używać podczas generowania stawek do dostosowywania ceny.

Czas aktywacji i czas wygaśnięcia

Pola czasu aktywacji i wygaśnięcia możesz wykorzystać w przypadkach, gdy niestandardowa lista odbiorców powinna kwalifikować się do aukcji tylko w określonym czasie. Pamiętaj, że istnieją pewne ograniczenia dotyczące tego, jak długo można opóźnić czas aktywacji oraz jaka może być różnica między czasem aktywacji a czasem wygaśnięcia. 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ćjoinCustomAudience i skonfigurować activation_time, aby był sygnaturą czasowąjoinCustomAudience za 7 dni.
  • Grupa 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 przedziale czasu w najbliższej przyszłości).
  • Kupujący może z wyprzedzeniem zdefiniować grupy odbiorców niestandardowych, które powinny kwalifikować się do określania stawek tylko w określonym czasie w (niedalekiej) przyszłości.
  • Jeśli na przykład reklamodawca prowadzi w Stanach Zjednoczonych w 2022 r. kampanię na koniec lata, kupujący może wywołać funkcję joinCustomAudience i skonfigurować 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 tej dacie platforma będzie odfiltrowywać niestandardowych odbiorców podczas wybierania reklam, a ostatecznie usunie ich z pamięci.

Kupujący i sprzedawcy: wybór reklamy

Wybór reklamy wymaga współpracy kupujących i sprzedających. Można to podzielić na 4 etapy:

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 na podstawie konfiguracji określonej przez sprzedawcę. Logika ustalania stawek kupującego jest wykonywana w celu wybrania reklamy i stawki.
4. Wykonuje się logikę decyzji sprzedawcy, aby ocenić kandydatów i wybrać zwycięską reklamę.

Aby ułatwić proces tworzenia, możesz symulować odpowiedzi usług dla kupujących i sprzedawców, w tym logikę licytowania i oceniania. Dzięki temu możesz skupić się na opracowywaniu elementów istotnych w Twoim przypadku użycia. Instrukcje konfigurowania pozornych punktów końcowych znajdziesz w katalogu FledgeServerSpec na GitHubie, a instrukcje zastępowania konieczności pobierania zdalnego JavaScriptu – w przewodniku dla programistów.

Sprzedawcy: definiowanie strategii zapośredniczenia

Interfejs Protected Audience ma obsługiwać zapośredniczenie kaskadowe. Ta sekcja jest w trakcie opracowywania. Więcej informacji podamy, gdy będą dostępne. Na razie zapoznaj się z propozycją projektu dotyczącą zapośredniczenia kaskadowego w ramach ochrony odbiorców.

Sprzedawcy: konfigurowanie aukcji

Sprzedawcy odpowiadają za konfigurowanie aukcji i przekazywanie informacji do procesu wyboru reklam. Sprzedawcy mogą udostępniać informacje wszystkim lub tylko wybranym podmiotom. Mogą to być informacje, które masz, lub informacje, które podajesz w imieniu kupujących.

Konfiguracja i prototyp

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

Uwagi dotyczące projektu

Ta sekcja zawiera wskazówki dotyczące wypełniania i używania kluczowych pól w konfiguracji wyboru reklamy.

• Prywatne środowisko wykonawcze zawiera na urządzeniu tylko reklamy kierowane na odbiorców niestandardowych, więc wysłanie wcześniej żądania reklamy kontekstowej umożliwia uwzględnienie dodatkowego popytu.

• Zanim rozpoczniesz proces wyboru reklamy, wyślij żądanie reklamy, aby zebrać informacje od kupujących. Następnie wykorzystaj te informacje do skonfigurowania wyboru reklam.

• Na urządzeniu wielu kupujących mogło utworzyć listy odbiorców niestandardowych, dlatego sprzedawcy muszą użyć pola Kupujący na listach odbiorców niestandardowych, aby wskazać konkretnych kupujących, którzy mają być uwzględnieni w procesie. Listę można utworzyć na wiele sposobów. Oto kilka przykładów:

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

• Sprzedawca może przekazywać 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. Używaj go do podawania informacji o możliwościach reklamowych, takich jak rozmiar i format reklamy.
  • Pole Sygnały dotyczące kupującego jest przekazywane do konkretnego kupującego, aby mógł on wykorzystać je w procesie ustalania stawek. Te informacje są przekazywane przez kupującego, a Ty jako sprzedawca musisz się zastanowić, jak je uzyskać na urządzeniu, aby można było ich używać podczas wybierania reklam.
  • Pole sygnały sprzedawcy to ostatni sposób, w jaki sprzedawca może przekazywać informacje w ramach tego procesu. Jako sprzedawca możesz używać tych sygnałów podczas oceniania i filtrowania reklam, np. włączając sprawdzanie 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 parametru biddingLogicUrl ustawionego podczas tworzenia CustomAudience. Możesz skonfigurować usługę testową, korzystając z podanej specyfikacji, lub zaimplementować ten punkt końcowy na prawdziwym serwerze.
• Szczegółowe informacje o wdrażaniu i korzystaniu z 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ą wysyłane w czasie rzeczywistym. Zapoznaj się z listą ograniczeń.
• W przypadku niektórych zastosowań reklam ważne jest, aby współpracować ze sprzedawcą w celu sprawdzenia, czy masz na urządzeniu wiele kandydatów do wyświetlenia reklamy i ich stawek.

Projektowanie logiki ustalania stawek

Logika określania stawek kupujących musi być zaimplementowana w JavaScript i wykonywana na urządzeniu. W przewodniku dla deweloperów znajdziesz informacje o wymaganym podpisie i szczegóły różnych parametrów przekazywanych podczas aukcji. Logika określania stawek na urządzeniu ma dostęp do dodatkowych informacji przekazywanych jako parametry do funkcji generateBid().

Dane dotyczące określania stawek za zasoby reklamowe

Sygnały określania stawek w czasie rzeczywistym z usługami par klucz-wartość

Jako kupujący możesz pobierać sygnały w czasie rzeczywistym podczas aukcji z należącej do Ciebie usługi klucz-wartość. Początkową 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 jako trustedBiddingUrl na liście odbiorców niestandardowych, 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 sygnały użytkownika

Twoja funkcja generateBid ma dostęp do dodatkowych sygnałów użytkownika podczas przeprowadzania aukcji na urządzeniu. Te sygnały są przekazywane w polach contextual_signals i per_buyer_signals. Wszystkie te pola są obiektami JSON, których format musi być zdefiniowany przez kupujących i sprzedawców.

Pole contextual_signals zawiera informacje, które mogą być istotne dla użytkownika. 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 dotyczący użytkownika może być istotny w Twoim przypadku użycia, prześlij opinię, abyśmy mogli ją rozpatrzyć.

Pole per_buyer_signals jest udostępniane logice określania stawek. Sprzedawca ustawia te wartości podczas tworzenia konfiguracji aukcji. Kupujący i sprzedawcy muszą współpracować, aby sprawdzić, czy te dane znajdują się na urządzeniu i są przekazywane do logiki ustalania stawek. Przykłady zastosowań tego pola:

• filtrowanie pod kątem bezpieczeństwa marki; Sprzedawca może poinformować kupujących o niektórych informacjach klasyfikacyjnych dotyczących aplikacji, która wysyła żądanie reklamy, a kupujący może użyć tych informacji do odfiltrowania niektórych reklam.
• Wysyłanie wektora dystrybucyjnego do modelu ML, który uwzględnia informacje kontekstowe.

Sprzedawcy: ocena i wybór zwycięskiej reklamy

Konfiguracja i prototyp

• Sprzedawca może dodać logikę oceniania do scoreAd()funkcji JavaScriptscoringLogicUrl, która jest wyświetlana z AdSelectionConfigparametru ustawionego podczas tworzenia scoringLogicUrl. Możesz skonfigurować usługę testową, korzystając z podanej specyfikacji, lub zaimplementować ten punkt końcowy na prawdziwym serwerze.
• Szczegółowe informacje o wdrażaniu i korzystaniu z interfejsu API znajdziesz w przewodniku dla programistów.

Projektowanie logiki oceniania

Sprzedawcy wdrażają logikę oceniania w JavaScript, która jest wykonywana na urządzeniu. W przewodniku dla deweloperów znajdziesz informacje o wymaganym podpisie i szczegóły dotyczące różnych parametrów przekazywanych podczas aukcji. Dodatkowo logika oceniania na urządzeniu ma dostęp do dodatkowych informacji przekazywanych jako parametry do funkcji scoreAd.

Dane do oceny zasobów reklamowych

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

Jako sprzedawca możesz pobierać sygnały w czasie rzeczywistym podczas aukcji z należącej do Ciebie usługi klucz-wartość. Wstępną implementację tej usługi znajdziesz 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 sygnały użytkownika

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

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

Sprzedawcy: wyświetlanie reklamy

Sprzedawcy muszą wyświetlać zwycięską reklamę. Więcej informacji o tym, jak wyświetlane są zwycięskie reklamy, znajdziesz w projekcie. Ten obszar jest w trakcie projektowania.

Raportowanie wyników wyświetleń

Konfiguracja i prototyp

• Kupujący i sprzedawcy mogą dodawać logikę raportowania do funkcji JavaScriptreportWin(), która jest wyświetlana odpowiednio z parametru biddingLogicUrl lub scoringLogicUrl. Możesz skonfigurować usługę testową, korzystając z podanej specyfikacji, lub zaimplementować ten punkt końcowy na prawdziwym serwerze.
• Szczegółowe informacje o wdrażaniu i korzystaniu z interfejsu API znajdziesz w przewodniku dla programistów.

Uwagi dotyczące projektu

Kupujący i sprzedawcy muszą zaimplementować funkcję reportWin w kodzie JavaScript zwracanym przez skonfigurowane punkty końcowe. Ta metoda umożliwia przesyłanie danych z powrotem na 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 po integracji.

Polecane dla Ciebie

• Uwaga: tekst linku jest wyświetlany, gdy JavaScript jest wyłączony.
• Przewodnik dla programistów dotyczący interfejsu Protected Audience API na Androidzie
• Obsługa kierowania na niestandardowych odbiorców za pomocą interfejsu Protected Audience API
• Ograniczenie liczby wyświetleń w Protected Audience