Przejrzystość stawki dzięki obiektowi SupplyChain

Dzięki obiektowi SupplyChain kupujący i pośrednicy mogą zobaczyć wszystkie podmioty, które sprzedają lub odsprzedają zasoby reklamowe. SupplyChain współpracuje z plikami ads.txt/ads.txt i ads.txt, aby zapewnić przejrzystość ekosystemu reklam.

1. Wydawca wysyła pytanie o stawkę.
2. Kupujący otrzymuje pytanie o stawkę i dane z obiektu SupplyChain.
3. Kupujący wyszukuje tożsamości wszystkich pośredników, którzy sprzedają zasoby reklamowe.
4. 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.

Jak działa obiekt SupplyChain

Obiekt SupplyChain, zwany też schain, jest częścią pytania o stawkę OpenRTB i składa się z „węzłów”. Każdy węzeł w obiekcie 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.

Wskazówka: aby system Google mógł utworzyć kompletny obiekt SupplyChain, wydawcy nadrzędni z zasobami reklamowymi zarządzanymi w MCM muszą udostępnić identyfikatory sprzedawcy (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 szczegółowych informacji znajdziesz w dokumentacji dla deweloperów OpenRTB i 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 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 za pomocą Otwartego ustalania stawek, obiekt schain ma 2 węzły: 1 dla „google.com” z seller_id w pliku sellers.json i 1 dla partnera zysku giełdy.

Tak jak Google tworzy węzeł dla google.com przed wysłaniem pytania o stawkę, 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 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) 

Ta funkcja jest w wersji 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.

Więcej informacji o parametrze 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 analizowania schain

Zgodnie z dokumentacją IAB serializacja obiektu SupplyChain wygląda tak:

• Właściwości obiektu {SupplyChainObject}!{SupplyChainNode array}. SupplyChainObject i węzła SupplyChainNode 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

Uwaga: zawartość atrybutu 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:

Serializacja z użyciem przecinków w przypadku pustych pól opcjonalnych

1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1,,,,

Serializacja bez użycia przecinków w przypadku pustych pól opcjonalnych

1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1

Dowiedz się więcej o obiekcie SupplyChain.

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.

 

Uwaga: wszystkie dodatkowe węzły dołączone do obiektu 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

Ten przykład przedstawia obiekt SupplyChain oznaczony jako kompletny w przypadku wydawców podrzędnych i nadrzędnych w MCM, przy czym Google jest giełdą.

"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?

Tak. W ramach procesu zapraszania wydawców podrzędnych w MCM wydawcy podrzędni konfigurują pliki ads.txt, aby zweryfikować własność poszczególnych witryn, które do nich należą i są przez nich zarządzane.

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?

Łańcuch dostaw zostanie oznaczony jako kompletny, ale kupujący mogą uznać ruch za „nieautoryzowany”, ponieważ w SupplyChain znajduje się węzeł, w którym witryna nie jest określona w pliku ads.txt jako autoryzowany sprzedawca. Aby uniknąć tych błędów, wymagane jest zaktualizowanie pliku ads.txt w taki sposób, aby wydawca nadrzędny w MCM był oznaczony jako DIRECT (np. MCM-parent-example.com, identyfikator Seller-ID wydawcy podrzędnego w MCM, DIRECT).