2021.04.02
登場背景と目的
「SupplyChain object」「Sellers.json」はいずれも、デジタル広告サプライチェーンにおける、SSPを含むベンダーの広告取引の透明性・信頼性を向上させることを目的として、IAB Tech LabのOpen RTBワーキンググループからリリースされた技術仕様です。
同じ目的によって生まれた既存の仕組みのひとつとして、同じくIAB Tech Labが仕様策定した「ads.txt」が挙げられます。「ads.txt」はドメイン詐称（Domain Spoofing）を中心としたアドフラウドの排除を行うための取り組みの一環として多くの媒体で採用されています。
関連記事：アドフラウドを防ぐ「ads.txt」の仕組みとメリット
「ads.txt」を活用すれば、媒体社がどのベンダー（SSPやアドネットワーク等）に対して広告在庫の販売を許可しているのかを確認することが可能です。しかし、それでもいくつかの課題は残っていました。例えば、ひとつの広告インプレッション（広告表示）の取引に多くの事業者が複雑に絡み合って関与しているケースにおいては、中間にいるすべての関係者を明らかにすることはできませんでした。そのため、悪意ある中間事業者が不正をしていた場合、検知ができないという問題がありました。
この問題を解決するために生まれた仕組みが、「SupplyChain object」及び「Sellers.json」です。これらを導入することにより、広告インプレッションにおける、媒体社からDSPまでの金銭の流れに参加するすべての仲介者を識別し、複雑なサプライチェーンにおける透明性・信頼性を向上させることが可能です。
ではそれぞれについて、詳しくご紹介します。
「SupplyChain object」とは？
「SupplyChain object」は、SSPからDSPに、RTBオークション前に送信されるBidRequest（入札リクエスト）において、その広告取引に関与した事業者を記録する仕組みです。広告枠を購入したい広告主・広告会社（DSP）は、事業者から送信されたBidRequestに含まれる「SupplyChain object」を参照することで、取引開始から完了までに関与した（中間事業者を含む）全事業者の履歴を確認することができます。
例えば、「abc.com」の在庫を「YieldOne®」が販売、「事業者B」がリセール、さらに「事業者C」がリセールを行う際のイメージを以下に示します。
※YieldOne®同様、事業者Bも事業者CもSupplyChain objectに対応していることが前提となります。
このように、複数のベンダーに渡ってBidRequestが送信される際、サプライパスに関する情報を文字通り「チェイン（連鎖）」させる仕組みになっています。
「Sellers.json」とは？
一方「Sellers.json」は、簡単に言えば、媒体社が設置する「ads.txt」のSSP（ベンダー）版です。「ads.txt」は、媒体社が許可するSSPなどの販売業者を記載するテキストファイルであるのに対し、「Sellsers.json」は「ベンダーが認可する媒体社や再販業者」を記載するファイルです。
「Sellers.json」のファイルには、ベンダー自体の情報（問い合わせ先メールアドレスや住所など）や、取引のある媒体社の再販業者の情報（IDや社名、媒体社ドメイン、媒体社 or 再販業者など）が含まれます。また、「ads.txt」同様Webサーバーに置かれる静的なファイルであることから、BidRequestの情報量が膨大になることを避けられるというメリットがあります。
導入によりもたらされるメリット
「SupplyChain object」及び「Sellers.json」の導入によるもっとも大きな目的やメリットは「広告取引の透明性の向上」にあります。
「ads.txt」にこの２つの技術が加わることで、広告主・広告会社は、「SupplyChain object」（当該取引に関与した全事業者の履歴）、「sellers.json」（各事業者が認証した仕入れ元の事業者リスト）、「ads.txt」 （媒体社が広告販売の委託先に認定した事業者リスト）の3つを照合することができるようになり、これまでは見えていなかった中間の取引経路を含む、取引の一連の経路をすべて確認できるため、不正取引があった場合、検知することが可能となります。
では、バイヤーにとっては具体的にどのように透明性を確認できるのか、冒頭の「abc.com」「YieldOne®」「事業者B」「事業者C」を用いた例で説明します。
冒頭と同じ以下の配信構造で考えます。
まず、すべての事業者が「SupplyChain object」に対応していれば、DSPは事業者Cから、下図のような情報を含んだBidRequestを受け取ります。ここから、「abc.com→YieldOne®→事業者B→事業者C」という順番でこの在庫が流れてきたことがわかります。
※事業者CがDSPに渡すサプライチェーンオブジェクトイメージ
それを元に、それぞれの事業者の「Sellers.json」を参照します。下図では、事業者Cは「在庫の仕入れ元として事業者Bと取引がある」ことを認めている、という確認ができます。
同様に、事業者Bの「Sellers.json」にはYieldOne®、YieldOne®の「Sellers.json」にはabc.comの情報が記載されていることを確認します。
最後に、「abc.com」のads.txtから、それぞれの事業社が、販売先として媒体社から許可されているかどうかも参照します。
ここまでの確認フローを一枚にまとめたのが、プレスリリースにも掲載している下図になります。
以上から、広告インプレッションの取引経路におけるすべての登場人物がどのように関係しているかどうかや、互いに認証された事業者であることなどが明確に分かります。
まとめ
「SupplyChain object」や「Sellers.json」は、複雑に絡み合って見えなくなっていたサプライチェーンの全容を明らかにするための取り組みです。
「YieldOne®」ではいち早くこれらへの対応を開始しましたが、ここまでに説明したようなすべての広告取引経路の透明化が実現されるには、広告取引に関わる事業者すべてが「ads.txt」ならびに「SupplyChain object」「Sellers.json」に対応する必要があります。1事業者に取り組みで成し得るものではなく、全事業者が対策を講じることで不正取引を対処でき、ひいてはデジタル広告全体の信頼性を向上することに繋がります。
本記事をご覧いただきました関係事業者様はぜひ対応をお願いします。また、お知り合いに関係者がいらっしゃる方は、ぜひ本記事をシェアいただけますとうれしく思います。
DAC及びプラットフォーム・ワンでは、引き続き広告取引の透明性・信頼性向上のための取り組みを積極的に行い、ドメイン詐称をはじめとするアドフラウドの排除を推進していきます。
