Dzięki obiektowi SupplyChain Object 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 SupplyChain Object.
- 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 SupplyChain Object
Obiekt SupplyChain, zwany też schainschain 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.
// 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ółpracowania 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 identyfikatorem 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 oraz określania stawek przez kod w nagłówku bez opłat, a także innych form zapośredniczenia.
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?
