Dzięki obiektowi SupplyChain kupujący i pośrednicy mogą zobaczyć wszystkie podmioty, które sprzedają lub odsprzedają zasoby reklamowe. Obiekt współpracuje z plikami ads.txt
/app-ads.txt
oraz sellers.json
, aby zapewnić przejrzystość ekosystemu reklam.
- Wydawca wysyła pytanie o stawkę.
- Kupujący otrzymuje pytanie o stawkę i dane z obiektu SupplyChain.
- Kupujący wyszukuje tożsamości wszystkich pośredników, którzy sprzedają zasoby reklamowe.
- Kupujący indeksuje i weryfikuje dostawców uprawnionych do sprzedaży zasobów reklamowych.
W stosownych przypadkach Google automatycznie utworzy obiekty w ramach pytania OpenRTB lub protokołu Google RTB.
Jak działa obiekt SupplyChain
Obiekt SupplyChain, zwany też
, jest częścią pytania o stawkę OpenRTB i składa się z „węzłów”. Każdy węzeł w obiekcie schain
schain
odpowiada konkretnemu podmiotowi uczestniczącemu w pytaniu o stawkę, które uwzględnia wszystkie podmioty zaangażowane w bezpośredni przepływ płatności za zasoby reklamowe.
sid
) swoich wydawców podrzędnych za pomocą Ad Managera lub interfejsu API.
// Przykładowy obiekt
"schain": {
"complete": 1,
"nodes": [{
"asi":"google.com",
"sid":"pub-1234567891234567", // Ten sam identyfikator seller_id wydawcy w sellers.json
"hp":1
}],
"ver":"1.0"
}
Więcej informacji znajdziesz w dokumentacji dla deweloperów OpenRTB i w dokumentacji IAB.
Wygląd obiektu SupplyChain różni się w zależności od sposobu współpracy z kupującymi.
Wydawcy sprzedający bezpośrednio w Google
W przypadku wydawców, którzy sprzedają zasoby reklamowe bezpośrednio za pomocą Ad Managera, AdMob lub AdSense, obiekt schain
zawiera tylko 1 węzeł dla „google.com” z seller_id
w pliku sellers.json.
Wydawcy korzystający z Otwartego ustalania stawek
W przypadku wydawców, którzy współpracują z giełdami zewnętrznymi przy pomocy Otwartego ustalania stawek, obiekt schain
ma 2 węzły: 1 dla „google.com” z identyfikatorem seller_id
w pliku sellers.json i 1 dla partnera zysku giełdy.
Tak jak Google przed wysłaniem pytania o stawkę tworzy węzeł dla domeny „google.com”, tak giełda zewnętrzna odpowiada za dodanie swojego węzła przed przekazaniem pytania.
Wszyscy pośrednicy nieobsługujący płatności
W obiekcie SupplyChain Object nie ma pośredników, którzy nie obsługują płatności. Dotyczy to określania stawek przez kod w nagłówku po stronie klienta, określania stawek przez kod w nagłówku bez opłat, udostępniania zasobów reklamowych i innych form zapośredniczenia.
Wydawcy, którzy korzystają z pośredników płatności przed wysłaniem żądania (Beta)
Funkcje w wersji beta mogą być niedostępne w Twojej sieci. Data udostępnienia tej funkcji dla wszystkich pojawi się w informacjach o wersji.
Wydawcy korzystający z pośredników płatności na etapie przed wysłaniem żądania do Google Ad Managera muszą przekazywać obiekt SupplyChain
zgodnie z wytycznymi IAB. Obiekt SupplyChain
powinien zawierać tylko pośredników bezpośrednio zaangażowanych w przepływ płatności za zasoby reklamowe. Do takich pośredników może należeć technologia serwera reklamowego firmy zewnętrznej używana przez wydawcę. Obiekt SupplyChain
można wysłać w żądaniu reklamy za pomocą parametru schain
.
Opis
Parametr łańcucha dostaw (schain
) może mieć wartość zmienną, która powinna być zserializowanym obiektem SupplyChain. Gdy ten parametr jest uwzględniony, Google dodaje węzeł do wszystkich otrzymanych obiektów schain
przed wysłaniem ich do kupujących.
Zapoznaj się z pełną dokumentacją IAB dotyczącą przesyłania informacji SupplyChain za pomocą tagu (a nie OpenRTB).
Wymagania dotyczące poprawnego analizowaniaschain
Zgodnie z dokumentacją IAB serializacja obiektu SupplyChain
wygląda tak:
- Właściwości obiektu
{SupplyChainObject}!{SupplyChainNode array}. SupplyChainObject
i węzłaSupplyChainNode
są rozdzielane przecinkami, co oznacza, że można pominąć pola opcjonalne, a odpowiednie separatory w postaci przecinków można opcjonalnie wykluczyć. - Każdy element
SupplyChainNode
jest oddzielony znakiem „!
”. - Jeśli wartość dowolnej właściwości zawiera znaki, które wymagają zakodowania na potrzeby adresu URL (np. „
,
” lub „!
”), przed serializacją należy ją zakodować na potrzeby adresu URL.
Kolejność serializacji
Właściwości obiektu SupplyChainObject
są serializowane w tej kolejności:
ver,complete
Właściwości węzła SupplyChainNode
są serializowane w tej kolejności:
asi,sid,hp,rid,name,domain,ext
ext
zależy od giełdy. Google Ad Manager nie analizuje tej właściwości.Przykłady serializacji obiektu SupplyChain
Poniżej znajdziesz 2 przykłady serializacji powyższego obiektu SupplyChain
:
1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1,,,,
1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1
Przykłady użycia
schain=1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1,,,,
Jeśli wartość parametru asi
wynosi exchange,1
, serializacja ze znakami modyfikacji będzie wyglądać tak:
1.0,1!exchange%2C1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1
Wymagania i zalecenia
Chociaż ten parametr nie jest wymagany do wyświetlania reklam w przypadku konkretnej implementacji lub typu transakcji, muszą go używać wydawcy korzystający z pośredników płatności na etapie przed wysłaniem żądania do Google Ad Managera. Dotyczy to również wydawców, którzy korzystają z serwerów reklamowych firm zewnętrznych.
SupplyChain
powinny być również reprezentowane w pliku ads.txt lub app-ads.txt wydawcy, ponieważ w przeciwnym razie kupujący mogą uznać ruch za nieautoryzowany.Wydawcy korzystający z Zarządzania wieloma klientami
Zarządzanie wieloma klientami (MCM) umożliwia wydawcom nadrzędnym zarabianie na zasobach reklamowych wydawców podrzędnych na 2 sposoby: indywidualnie w ramach typu przekazania Zarządzanie kontem lub na większą skalę w ramach typu przekazania Zarządzanie zasobami reklamowymi.
Partnerzy korzystający z Zarządzania kontem
W przypadku wydawców nadrzędnych i podrzędnych, którzy korzystają z typu Zarządzanie kontem, obiekt schain
zawiera 1 węzeł z identyfikatorem sprzedawcy wydawcy podrzędnego, a łańcuch jest oznaczony jako kompletny. U wydawców, którzy korzystają z Zarządzania kontem, przychody pojawiają się na koncie wydawcy podrzędnego. Wydawca podrzędny jest traktowany jako wydawca końcowy. Informacje o wydawcy nadrzędnym nie są uwzględniane w obiekcie schain
.
Partnerzy korzystający z Zarządzania zasobami reklamowymi
Obiekt SupplyChain jest teraz oznaczony jako kompletny w przypadku wydawców korzystających z Zarządzania zasobami reklamowymi w MCM. Dostępny jest 1 węzeł dla wydawców podrzędnych MCM i 1 węzeł dla wydawców nadrzędnych MCM, a łańcuch jest oznaczony jako kompletny.
W ramach tej aktualizacji wydawcy nadrzędni zarządzający zasobami reklamowymi w MCM muszą udostępnić identyfikatory sprzedawcy (SID) swoich wydawców podrzędnych przy użyciu frontendu lub interfejsu API Ad Managera.
Przykład kompletnego obiektu SupplyChain
"schain" : {
"ver": "1.0",
"complete" : 1,
"nodes" : [
// Węzeł dla wydawcy podrzędnego w MCM
{
"asi":"mcm-parent-example.com", // To tylko przykład. Pamiętaj, aby wpisać rzeczywistą domenę wydawcy nadrzędnego.
"sid":"52e41fac28963d1e058a106f", // Identyfikator sprzedawcy wydawcy podrzędnego w pliku seller.json wydawcy nadrzędnego
"hp":1,
},
// Węzeł dla wydawcy podrzędnego korzystającego z Zarządzania zasobami reklamowymi w MCM
{
"asi":"google.com",
"sid":"pub-1234567891234567", // Identyfikator wydawcy nadrzędnego w MCM w pliku sellers.json firmy Google
"hp":1,
}
]
}
Najczęstsze pytania
Dlaczego wydawcy nadrzędni w MCM muszą tworzyć pliki sellers.json?
Publiczne udostępnienie informacji o partnerach przez uwzględnienie ich w pliku sellers.json to ważny krok, który ułatwia nabywcom reklam weryfikację zasobów reklamowych.
Dowiedz się więcej o specyfikacji plików sellers.json opracowanej przez organizację IAB.
Czy wszyscy wydawcy podrzędni muszą mieć prawidłowy plik ads.txt?
Jeśli plik ads.txt wydawcy podrzędnego nie zawiera wiersza, w którym wydawca nadrzędny w MCM jest określony jako DIRECT (np. MCM-parent-example.com, identyfikator Seller-ID wydawcy podrzędnego w MCM, DIRECT), ale zawiera wiersz Google z identyfikatorem wydawcy nadrzędnego (np. google.com, identyfikator PUB ID wydawcy nadrzędnego w MCM, RESELLER, f08c47fec0942fa0), czy będzie to miało negatywny wpływ na przychody? Czy łańcuch dostaw będzie kompletny?