いますぐ対応したい!DigiTrust IDとは

 2019.02.27  デジタル・アドバタイジング・コンソーシアム株式会社

先日、プレスリリースにて発表させていただきましたが、DACおよびプラットフォームワン(以下P1)の提供するSSP「YIELDONE」とDSP「MarketOne®」は、IAB Tech Labの提供する共通Cookie IDソリューション「DigiTrust ID」に対応します。

とはいえ、そもそも“共通Cookie IDソリューション“というもの自体が、聞きなれない方も多いかと思います。本記事では、”共通Cookie IDソリューション“がどのような背景で生まれ、「DigiTrust ID」を使うとどのようなメリットがあるのか、ご説明いたします。

Cookie Syncのしくみ

「DSP」と「SSP」、「DMP(データ・マネジメント・プラットフォーム)」と「DSP」、ヘッダービッディングサービス※1とSSP等、異なる事業者同士でRTBによる広告取引をしたり、データ連携をする際に必要不可欠な仕組みがCookie Syncです。

※1:ヘッダービディングサービスに関する詳細は、以下記事をご参照ください。

関連記事

HeaderBiddingってどんなもの?仕組みやメリットについてご紹介。 

同じブラウザでも、「SSP①」では【ABC123】というIDで識別されていたとしても、ドメインの異なる「DSP①」では【DEF567】というIDで識別されている可能性があります。

RTB取引を例にお話しますと、インターネットユーザーが媒体社のwebサイトにアクセスすると、SSPタグが呼ばれて、ビッドリクエストという形でDSPに対してオークションが開かれます。この流れはご存知の方も多いかと思いますが、その際に「DSP①」としては、そのインターネットユーザーが自社のIDでいうどれのIDにあたるのか?が非常に重要です。

それを把握するためには、事前に「SSP①」と「DSP①」の間でCookie Syncを行い、「SSP①」で【ID: ABC123】と付与されたブラウザと「DSP①」で【ID: DEF567】と付与されたブラウザが同一のブラウザであることがわかる、マッピングテーブルを作る必要があります。この処理は通常、インターネットユーザーが多数訪れる媒体社サイトにSSPやDSPのタグを貼ってもらい、サイト表示の裏側で行っています。そのため、インターネットユーザーは意識することはありません。

 

Cookie Syncで起こり得る問題

大変すぐれた仕組みであるCookie Syncですが、だんだん問題があることもわかってきました。

問題は大きく二つあります。一つめは、それぞれの事業者が別々のブラウザ群に対してIDを独自に発行しているので、Cookie Syncをおこなうと、どうしてもマッチしないID群(欠損)が生じてしまうことです。

なぜそうなるのかは分かっていませんが、マッチするIDの比率(マッチレート)の平均値はだいたい70%といわれています。言い換えれば、マッチしないID(=欠損)が30%程度生じているということです。

Cookie Syncで起こり得る問題

DSPとSSPの間だけでやっている分には許容範囲かもしれませんが、Cookie Syncの輪が広がっていくと、アドサーバとSSPの間でも30%欠損し、SSP-DSPでも30%欠損し、DMP-DSPでも30%欠損し・・・と続けていくと、媒体社では100%あったCookie ID総数が、7掛け、7掛けを続けていくことで、70%、49%、34%、、と減り、最終的に広告ターゲティングで活用できるID数は非常に少なくなってしまいます。

一方、GoogleやFacebook、Amazon等のように、自社サイトでIDを発行し自社データを使って自社のアドサーバで広告配信しているような、すべて内部のシステムを使うことができるプラットフォームは、Cookie SyncをしないのでIDの総数も減りません(他社システムとはCookie Syncをしています)。彼らと比べると、Cookie Syncをしなければいけないサードパーティのアドテク事業者がいかに不利な立場にいるか、がお分かりいただけるかと思います。

Cookie Syncで起こり得る問題


二つ目の問題は、「DSP①」は「SSP①」だけでなく、「SSP➁」や「SSP③」、「DMP①」、「DMP➁」等、関係があるすべての事業者とCookie Syncをする必要があるため、媒体社のwebサイトにはCookie Syncするためのタグが非常に多く貼られていることです。IAB/DigiTrustによると、媒体サイトに張られている(SSPやDSPなどの)サードパーティタグの数は平均で88個だそうです。多数のタグと裏側でのCookie Sync処理は、インターネットユーザーがwebサイトを閲覧しようとした際、読み込みから表示までの時間が増えるといった影響を与えています。

DigiTrust IDとは 

“共通Cookie IDソリューション”は、そうしたCookie Syncが持つ問題を背景に生まれました。

我々が対応するIAB Tech Labが提供する「DigiTrust ID」以外にも、The Trade Deskが提供する「Unified ID」やLiveRampが提供する「IDL Mapper Sidecar」(Cookieだけではない)といったソリューションもあります。Advertising ID Consortiumは、上記の3つの共通IDソリューションの採用を推奨しています。 詳しくはこちらをご参照ください 

参考URL

Advertising ID Consortium 

 

DigiTrust IDとは 

IAB Tech Lab傘下の非営利団体です。もともとはIAB Identity Standards Working Groupの活動からスピンアウトした団体でしたが、業界にとって公益性が非常に高いソリューションであるため、2018年4月にIAB Tech Labが買収し傘下に収めました。

Rubicon ProjectやPubMatic、MediaMath、OpenXといった錚々たるグローバルプラットフォームをはじめ、DACが提携しているBidSwitchも対応しており、IABによるとグローバルで流通しているビッドリクエストの65%にDigiTrust IDが付与されているほどの普及状況だそうです。

「DigiTrust」の仕組みとしては、異なる事業者間で共通のCookieドメイン(digitru.stドメイン)発行のIDを使って、RTBやデータ連携を行う、というものになります。各事業者はDigiTrustとの間で一度Cookie Syncすれば、DigiTrust ID参加の別事業者とはCookie Syncする必要がなくなり、DigiTrust IDで取引や連携が可能になります。

DigiTrust IDとは

DigiTrsut IDでは、1社対1社で個別にCookie Syncするよりも、他事業者が行った別企業とのCookie Sync成果を参加企業すべてが享受できるため、マッチレート(マッチするIDの比率)は向上し、理論上は限りなく100%に近づき、先ほどの(SSPやDSPなどの)サードパーティのアドテク事業者が抱えるID総数の低下問題は解消されます。また事業者ごとで都度Cookie Syncする必要がなくなるため、媒体社サイトに貼られるタグの数が減り、ページの読み込みから表示時間が短くなるという、インターネットユーザー側の課題も解決されます。加えて、インターネットユーザーはDigiTrustをオプトアウトするだけで、参加企業すべてがターゲティング配信に活用できなくなるので、プライバシー保護的にも優れています。

DigiTrust IDは、Cookie Syncという基幹技術を採用する限り、業界が向き合い続けなければいけない問題を解決する革新的な技術なのです。別の視点から捉えると、アプリ広告の世界におけるIDFAを、ウェブ広告の世界にも構築しようという取り組みともいえます。

 

DigiTrust IDによるメリット

立場ごとに、ビジネス的なメリットについて説明します。

セルサイド(媒体社やSSP、ADEX事業者)

DigiTrust IDの導入によってバイサイドとのマッチレートが向上することで、自社から提供できるIDつきインプレッションが増えるので、これまでIDなしで売っていたインプレッションが、より高単価で売れる可能性があります。取引規模にもよりますが、セルサイドの売上が大幅に増加する可能性があります。

バイサイド(DSP、広告エージェンシー、広告主)

DigiTrust IDの導入によってセルサイドとのマッチレートが向上することで、自社で識別できる広告リクエストが増えるので、オーディエンスターゲティングができる広告在庫が増える可能性があります。それによって、オーディエンスターゲティングキャンペーンの予算消化がスムーズになる可能性があります。

 

おわりに

アドテクというと先に導入した会社だけがメリットを享受できるようなイメージがあるかもしれませんが、前述のとおり、参加企業が増えれば増えるほど全体のマッチレートは向上し、ユーザー体験も向上するモデルなので、DACでは協調領域として捉えて、IABと連携しつつ日本における普及活動を進めています。

DigiTrustの仕様や行く末を決めるIAB Tech Lab DigiTrust ID Working Groupでは、現在iOS SafariにおけるITP 2.0機能(クロスサイトトラッキングのデフォルト拒否)への対応を検討していたり(ITP 1.1の段階ではDigiTrustのしくみで回避できていた)、媒体社主導で導入した際の同意ポップアップを進化させて、IAB基準に準拠したCMP(同意取得・管理・流通プラットフォーム)機能の搭載を検討しており、その動向からは目が離せません。こちらも引き続きウォッチし、最新の取り組みについてはキャッチアップを行っていきたいと思います。

なお今回は割愛しましたが、実装方法(※2)、費用等についてさらに知りたい方は以下を参照するか、DACあるいはP1の担当者までご連絡くださいませ。

※2:媒体社主導のファーストパーティドメインでやる方法と、アドテク主導のサードパーティドメインでやる方法があります。

 関連URL

 

今回ご紹介した内容に関して、興味を持っていただきましたら以下よりお問い合わせください。

お問い合わせ

RECOMMEND関連記事


RECENT POST「MarketOne®」の最新記事


この記事が気に入ったらいいねしよう!