目次
『クッキーレス時代と向き合う』連載の趣旨
ユーザーを識別し、情報を記録・保持することができるCookieは、リターゲティングや行動ターゲティング、アトリビューション分析などに幅広く利用されており、企業のデジタルマーケティング活動に欠かせない技術でした。
一方、EUで施行となったGDPRや米国カリフォルニア州のCCPAといった法規制に加え、AppleのITPや2023年を予定しているChromeの3rd Party Cookieサポート終了といったWebブラウザの仕様変更など、グローバルかつ業界全体でCookieの利用を制限する動きが出てきています。
そこで本連載では目前に迫っているクッキーレス時代の到来に向けて、識者との対談を通じ、その全容を明らかにすると同時にマーケターが今から準備できることを明らかにしていければと考えています。
第6回は、デジタルメディア測定、データおよび分析のソフトウェアプラットフォーム大手であるDoubleVerifyの日本法人代表 武田隆さんに、クッキーレス時代の効果計測について聞きました。
※参考リンク：
今回の話し手：株式会社電通デジタルの三谷壮平さん
第7回となる今回は、株式会社電通デジタルの三谷壮平さんに、三谷さんが考えるクッキーレス時代の効果計測とターゲティングの全容を聞きました。
話し手：
株式会社 電通デジタル
ソリューション戦略部 部長 三谷壮平さん
聞き手：
アタラ合同会社
マネージャー／コンサルタント 高瀬優
広告 x CRM x 機械学習でLTVを最大化
高瀬：2021年7月、御社はCookieに依存しない新しい計測基盤として「X-Stack Connect（クロススタック・コネクト）」を開発・提供開始されました。これは、2018年10月から提供されている「X-Stack」の機能をCookieレスに対応させるべく大幅に強化・拡充されたものということですが、まずは「X-Stack」がどういったソリューションなのかを教えてください。
※参考リンク：
三谷：「X-Stack」の要素を分解すると、データの統合、予測モデルの構築、ワンストップでの施策接続の3要素に分けられます。
これまで、広告領域とCRM領域が分断していることが多かったと思うのですが、それぞれの情報を統合データベースに格納することで、広告とCRMのデータをかけ合わせた機械学習を行い、例えば配信プラットフォームやCRMツールなどの各顧客接点のチャネルにつなげていくことの全体像を「X-Stack」と呼んでいます。
これまでの広告領域は、Webコンバージョンタグで計測できるコンバージョン地点、例えばトライアルを最大化するような最適化をかけていくことが多かったと思うのですが、本来のクライアントの事業成果はその先のLTV（顧客生涯価値）だったりします。
本当はLTVを最大化したいと思いつつ、今までデータがつながっていなかったから、トライアルを最大化することに目標を据えざるを得なかったという状況だったと思うのです。
そういった背景を踏まえ「X-Stack」では、Webコンバージョンではなく事業成果に対する目標ROASを使った最適化を目指しています。トライアル地点でのコンバージョンの価値が同じ1だったとしても、より優良顧客になりやすい人と、そうではない人という濃淡はあります。事業成果を最大化するのであれば、1年後の売上が1,000円の人たちを獲得するよりも、10万円の人を獲得できたほうがよいので、そこに対してきちんと最適化をかけていくということを目指しています。
生命保険会社の導入事例では、見積保存に対して最適化していたのを、成約への最適化に切り替えたことでROASが上がりました。これは結局、見積保存時点での成約確率を予測する必要があるので、予測モデルを作るという課題が出てきますが、まずはWebコンバージョンやサイト内行動データをGoogle アナリティクスで計測し、CRMデータは別にクライアントから受け取り、それらをBigQuery上に集約してモデリングします。
ここでAutoMLを使ってユーザーの予測モデルを作り、最終的にはFacebook広告やGoogle 広告に送ることで、それぞれの目標ROASを回していく、ということを行っています。
集計データを媒体に送るパイプラインについては、コンバージョンAPIやサーバーサイド計測に対応する際も同じことですが、情報を集めてくる際の基盤は、従来はCookieでした。しかし、Cookieの利用が制限されてくる中で、このままCookieを使って計測に依存していると予測モデルの構築に十分なデータを集めることができませんし、計測できるデータにも偏りが生まれてしまいます。
そこで、Cookieの利用制限への対策のために主にデータ収集の部分のアプローチをアップデートし、Cookieフリーな状態を実現したのが「X-Stack Connect」です。ユーザーのプライバシー保護の観点からは問題のあったCookieの利用に依存しない、プライバシー保護に配慮した手法のことを電通デジタルでは「Cookieフリー」と呼んでおり、「X-Stack Connect」はこのCookieフリー対応ソリューションの一つと位置づけられます。Cookieフリー対応にアップデートはしていますが、最終的にデータを送るという立て付けの部分はこれまで「X-Stack」で培ってきたアセットを生かせるので、今年発表したものにも「X-Stack Connect」というネーミングを採用しました。
高瀬：CRMデータはBigQueryで統合されるのですね。
三谷：はい。基本的にわれわれはGCPベースで開発をしていますし「X-Stack Connect」の基盤も全部GCPです。やはり、Google アナリティクスデータがエクスポートできるのもBigQueryですし、あるいはAds Data Hubのような分析ソリューションにおいても結局のところBigQueryがあることが前提になってくるなど、特にGoogle 広告が関係する分野ではBigQueryなしでは分析が成り立たないのが現状です。広告以外の領域についてはAWSやSnowflakeなども含めて、事業に応じて最適なものを選定していただければと思いますが、広告領域においてはGCPに寄せたほうが結果的にスムーズかつ安価なので、基本的にはGCPベースでの実装を推奨しております。
GTM x GA4 x BigQueryで実現できる世界
高瀬：次に「X-Stack Connect」の概要についても教えてください。
三谷：その前に、これまでのブラウザベースの計測と、これからのサーバーサイドベースの計測を比較したときに、どういった点で大きく異なるのかについて整理したいと思います。
計測とは、コンバージョンの計測も、あるいはリターゲティング対象としてのフラグ立ても同様なのですが、プロセスとして、媒体側とクライアントサイト側で計測したユーザーが同一であることをひも付けることで行われます。媒体で計測されたユーザーと、クライアントサイトで計測されたユーザーが、同じAさんであることが分かって初めて、媒体での広告接触後にクライアントサイトでコンバージョンした、ということが分かるわけです。
この、媒体とクライアントサイトで同一であることを把握するために使われるのが、マッチキーと呼ばれるものです。
従来、このマッチキーとしては主にCookieベースのIDが使われていました。マッチキーを集めて成形して、最終的に媒体に送るというプロセスを整理したときに、今までのブラウザベースの場合はコンバージョンタグを埋めておけば、基本的には全て自動的に実施できました。しかしサーバーサイド計測の場合、受け皿としてのAPIは各媒体が用意してくれていますが、何を集めてどう成形するかというところまでは面倒を見てくれないので、実装者の自由演技になります。
当然、実装方法によっては意味のない実装になることもあり得るのですが、われわれは持続可能性の高い計測が担保できるように工夫をしています。今回、開発した「X-Stack Connect」は全てのパーツを独自に作ったわけではなく、マッチキーの収集の基盤としては基本的にはGoogle タグマネージャーのサーバーコンテナ（以下、sGTM）を採用しており、サイトアクセスログについてはサーバーコンテナからGoogle アナリティクス4プロパティ（以下、GA4）を呼び出し、GA4のログデータをリアルタイムエクスポートでBigQueryに流し込むという形でログを収集しています。
フォームの入力情報についても、当然クライアントの基幹システムから取ってくることもできるのですが、そうすると情報システム部門（以下、情シス）が絡んでハードルが上がるケースが多いので、実装に非常に時間がかかることも多くあります。BigQueryに直接データをエクスポートする機能がsGTMに最近できたので、われわれはその機能を使っています。これはウェブ上の変数として定義しておき、その変数として定義したものをそのまま送るイメージです。コンテナはあくまでトンネルで、データはsGTMではなくBigQueryにたまるので、セキュリティ的にも安心です。もちろん個人情報を利用することになるので、法的な許諾の整理は別途必要ですが、法的な問題がクリアしても技術的な制約で難しい、というケースにおいてはハードルを下げて導入しやすくなっているかなと思います。
このBigQueryは電通デジタルが契約しているものを貸し出すこともできるのですが、個人情報を入れる場合は基本的にクライアントに契約していただいています。つまり、クライアントが契約しているBigQueryにクライアントのデータを入れ、われわれはその作業者として業務を受託するだけです。実際のデータの受け渡しのフローには電通デジタルを介す必要がないことから、ハードルがまた一つ下げられると思っています。
そこからシグナルの収集と整形、各媒体のAPIを定期更新でたたいていくところをGoogle Compute EngineやCloud Composerで自動化していて、異常検知の仕組みも作っています。これもほぼリアルタイムで送れるので、エラーが起きたときにはSlackのチャンネルにその通知が来ます。
高瀬：ありがとうございます。この場合、あくまでGTMベースでフォームの入力情報を自動で変数として取得しBigQueryに送信することで、1st Party データをBigQuery上に蓄積してかつ計測にも活用できる仕組みになっているという理解であっていますか。
三谷：はい。さらに深い地点をゴールに置いたときには、当然この仕組みだけでは完結できず、基幹システムのデータをなんらかの形でつなげるという作業が必要になってきます。ただし、ほとんどのクライアントは、まずは今までの最適化を維持したいというニーズになると思うので、これまでタグを置いておけばよかったのに急に基幹システムにつなげる必要があるといわれてしまうと、やはり構えてしまうケースが多いです。
その反省を踏まえて、クライアントにより一層負荷がかからない形でフォームの入力情報を取る手法はないかと研究した結果、このGTMから直接BigQueryに転送する形であれば、セキュリティも担保した上でなおかつ実装も楽になるのではないかとなりました。導入費用も安くなるので、われわれとしてはこの方式をおすすめしています。
高瀬：現状そこまでCRMを活用できていないクライアント、この文脈ではタグ方式を採っていたクライアントは、今までのパフォーマンスを維持するという観点で、まず「X-Stack Connect」を導入する。導入後に1st Party データが充実してきてCRM情報も潤沢になってきたタイミングで、LTVベースで最適化していくというストーリーになるということでしょうか。
三谷：おっしゃるとおりです。
高瀬：Google 広告の拡張コンバージョンであれば、それ用の計測タグの設定、Facebook広告はコンバージョンAPIを別途設定する必要がありますが、「X-Stack Connect」の場合は、GTMで一括収集した後、それぞれの媒体に適した形で渡してくれるというイメージでしょうか。
三谷：はい。今までは、例えばコンバージョンAPIだったらそれにあわせてツールを設定し、拡張コンバージョンだったらそれにあわせた形で設定する、というケースが多かったと思いますが、結局必要となる情報は多少の差異はあれど基本的には共通です。共通していないのは、例えばFacebookの場合はFacebookログインIDが取れる、という程度の話です。
それ以外のものは、ほとんど同じマッチキーなので、われわれは出口起点で考えるのではなく、一括で基盤を作ってそれぞれつなげる形にしておけば、今後媒体が増えたときにも対応できますし、ダブルコストにならないという意味でクライアントにとってメリットが大きいと思っています。加えて、計測の基盤としてGA4もセットで導入しますので、アクセス解析ツールもついてきます。
高瀬：確かに、拡張コンバージョンやコンバージョンAPIと同様のソリューションが他媒体からリリースされる可能性はありますし、媒体ごとに実装方法が異なってくると思うので、その都度実装していくよりは「X-Stack Connect」という基盤を挟むことで、対応コストがかからないというのは素晴らしいですね。「X-Stack」との違いは、どのような点ですか。
三谷：「X-Stack Connect」は従来通りの効率がどんどん低下していくものを維持するためのソリューションで、「X-Stack」はどちらかというと、その先にある、より攻めに転ずるためのソリューションです。より深い地点のコンバージョンに対する最適化をかけていくというところで、二つのソリューションは同じ基盤の延長線上にあるので、まず現状の効率を維持できるようになったら攻めの施策につなげていきましょう、というストーリーが描けるとよいと思っています。
高瀬：実際は、なかなかこの攻めに転じられないクライアントが大半だと思います。その障壁になっていることは、三谷さんから見て、どういった部分だと思いますか。
三谷：まずは事業的に、そもそもあまりギャップがないケースはありますよね。例えば生命保険系のクライアントで、ウェブ上で申し込みが完結できて、そのあと審査に落ちる人はほとんどいないといったケースだと、Webコンバージョンと事業成果がほぼ同じで、あまりギャップがないという話になるので、そもそも事業としてあわず使えないというケースはもちろんあります。
あとは、事業成果とWebコンバージョンにギャップがあってつなげる意味があるクライアントでも、先方の事業部間の壁が障壁となるケースは多いです。われわれが相対するのはウェブの集客に対して責任を負う宣伝部の方が多いのですが、そこからの引き上げについては、例えばCRM部だったり、別部署だったりするのです。
そうすると、役割分担を侵害することになってしまって、なかなか調整が利きにくいという問題があります。全体最適としては、もちろん広げていったほうがよいと思のですが、自部署の目標としては、どうしても全体最適だけを考えていらっしゃるわけでもないので、ギャップがあって進まないということもあります。CRMのデータとつなげるためには、どうしても情シスの方との連携が必要になってくるので、情シスの方を説得するためのハードルが高いこともあるでしょう。
また、個人情報を扱うときにすでに課題になっていますが、メールアドレスや電話番号に付随するような情報を渡すのはプライバシーポリシー上できないというところもあります。われわれは法的な見解も含めていろいろアドバイスをさせていただいているのですが、法的にOKだったとしても社としてその判断をするのは難しい、など理屈ではないところで駄目になるケースが現実的にやはりどうしてもあるのです。そこは成功事例を積み重ねて啓発していくしかないと思っています。
CDP補完や簡易的な仮想CDPとしてのX-Stack Connect
高瀬：「X-Stack Connect」がリリースされる前に、各社からCookieレス関連のソリューションが立て続けに発表されました。サーバーサイドタグでの計測は各社カバーできているという認識ですが「X-Stack Connect」の強みは、どういったところになりますか。
三谷：他社の裏側の仕組みが分からないので、なかなか難しいところがありますが、われわれのソリューションは無駄が少ないという点があげられると思います。
先ほどもご説明したとおり「X-Stack Connect」はサーバーサイドGTMとGA4の基盤を採用しています。他にもタグマネジメントツールは多数存在しますが、Google 広告との相性の観点では「X-Stack Connect」の親和性が高いといえます。具体的にはGoogle 広告のコンバージョン計測において、Server-Side Taggingという、アクセスログを用いたCookieフリー計測の仕組みが最近リリースされました。ただし、Server-Side Taggingを使うための前提としてサーバーサイドGTMとGA4のセットが導入されている必要があります。サーバーサイドGTMのオプションの一つとしてこの機能があるので、他社のタグマネジメントツールを使ったらこの機能は現状使えません。
そうすると、例えばほかが全部他社のタグマネジメントツールで完結できたとしても、結局この機能を使うためにサーバーサイドGTMを追加で入れないといけないといったことが起きてくるのです。一方で「X-Stack Connect」はもともとサーバーサイドGTMとGA4がベースになっているので、ダブルコストになりにくいといえます。
あとは汎用性の部分で、意外と文字の壁があると思っています。FacebookやGoogleはもともと英語圏のものなので、例えば氏名や住所は全部アルファベットであることを想定しています。英語圏であれば、取得したものをそのまま取って出しすればよいのですが、日本語圏の場合、媒体によっては日本語で送れないのでローマ字変換する必要があります。
そういったところに海外系のタグマネジメントツールのほとんどは対応していません。本国がアルファベット環境で、変換の必要がないため仕方がない部分もあるのですが、日本で「アルファベットに変換するのは各クライアントでよろしく」といわれても困ってしまいますよね。われわれは日本語情報をもらえれば変換する仕組みまで含めて対応している点も売りだと思っています。
高瀬：Cookieレスの状況の中で、CDPも今注目を集めています。一方でCDPは導入・運用コストも相当かかってきますし、CDPを導入するまででもないというクライアントも一定数はいるという認識です。そういったクライアントにとっては「X-Stack Connect」で事足りるケースというのもあるのではないかと思うのですが、いかがでしょうか。
三谷：そうですね。やはりCDPは相当高くて、下手すると数千万円かかる場合もあります。それに対してわれわれはクライアントの環境にもよりますが、ベーシックな構造の場合、初期費用が約100万円で、ランニングコストもGCPの費用などを含めて30万円しない程度であり、これ単体だとかなり競争力がある値付けだと自負しています。
もちろんCDPのほうが機能としては圧倒的に多いですし「X-Stack Connect」でできないこともたくさんあるので、入れ替わるとはまったく考えていないのですが、手が足りていない部分のパーツとして使っていただく分にはよいのではないでしょうか。それが許容されるだけの費用の安さはこだわろうと思っています。
高瀬：確かに、その費用感だとCDP導入済みのクライアントにとってもおそらく導入しやすいと思いますし、補完関係を築けますね。「X-Stack Connect」に関して、言い足しておきたいことはありますか。
三谷：単なる1st Party Cookie利用では改善しない、という事例があるというところです。ほかのツールだと、例えばCNAMEでの1st Party Cookie化を行うから大丈夫ですよとか、NSレコードでやりますよとおっしゃっているケースも多いと思うのですが、それだと今後、ITPによって規制される可能性が残っていると思うのです。
CNAMEはすでに規制されていますし、NSレコードも安泰ではないと思っています。われわれはその検証をするために、1st PartyのブラウザCookieで計測した情報を用いてコンバージョンAPI計測を実装した場合の結果も出しているのですが、それだとせっかく実装してもコンバージョン獲得効率は従来のタグベースと比べて改善しなかったという結果になりました。
今までは、定義書に沿って実装すればちゃんとその効果が得られる、というのがAPIなどの話だったと思うのですが、今回は少しそこがずれています。これは気を付けないといけないのですが、サーバーサイド計測のAPIというのは「受け口しか用意していなくて、何を送るかは実装者の自由です」というスタンスなので、仮にCookie利用規制への対策としてはまったく意味のない実装をしていても、情報は見た目上、送れているので、ちゃんと対応していますと言えてしまうのです。
しかし、実際にそれをやってみると、まったく改善してないということもあり得るので、自由演技だからこそ、逆にその頼もうとしているベンダーがどのように実装しようとしているかはしっかりチェックしないといけません。持続可能性の高い方法で行っているかまで踏み込んで確認する必要があります。
見た目上、対応しているように見えて、実はまったく対応できていなかったという悲劇的なことになるので、ここは気を付けたほうがよいと思います。リテラシーが高くないと難しい話なのですが、自由演技だからこそある落とし穴だというのが、大事なポイントです。
CookieレスはID経済圏時代の始まり
高瀬：ここからはCookieレス時代に対する三谷さんのお考えを伺いたいと思います。Cookieレス時代になってくると、メディアプランニングの考え方も変わってくると思うのですが、三谷さんの考えるCookieレス時代のメディアプランニング教えてください。
三谷：前提として、Cookieフリーの影響範囲は大きく二つに分けられると思っています。一つ目が、ここまで見てきた広告配信とクライアントサイトの間でのサイト来訪ユーザーを特定する領域で、主にコンバージョンデータの測定やリターゲティングの追跡に関わります。
ここはサーバーサイド計測や「X-Stack Connect」といったソリューションでカバーできるのですが、二つ目の領域として、配信と在庫がクロスになる場合、ここもクロスサイト計測に該当するため、問題になってきます。
同じプラットフォームの中の話であっても、配信と在庫がクロスになるケースは3rd Party Cookieに依存している話なので規制の対象で、対策しなければいけない部分ですが、対策の主体が異なります。図の右側のオレンジ色の部分はプラットフォーム側ではなくクライアントが実装する話ですが、青色の左側部分は広告在庫との関係なので、プラットフォーマーが対策しないといけないことになっています。
ただ、対策しなければならない目的の軸では別でも、対策の手段軸でみると結果的に重なっている部分もあります。そのため、今までの議論はこの両者が混同しがちだったと思っていて、そこは分けて考えたほうがよいというのが、まず前提としての考えです。もちろんクロスサイトに該当しない、例えばFacebookなどのSNS系であれば影響は受けないのですが、日本で広告配信ボリュームの大きい、つまりマーケットシェアの大きいところですと、GDNはGoogleが配信元ですが在庫は必ずしもGoogleの自社枠ではないのでクロスになる影響を相対的に受けやすいといえます。そこの代替の話と、コンバージョン計測の代替という話は、目的が大きく異なるので、分けて考えたいと思います。
いったん目的の観点を置いておいて、手法の軸で整理しますと、Cookieフリーの実現のための手法は大きく三つに分けることができます。
一つ目が、そもそも人単位での特定をしないでも実現できるアプローチです。例えば配信の観点では、そもそもIDトラッキングを使わない、例えばコンテクスチュアルターゲティングといった配信手法があります。あるいは計測の観点では、統計的な申込数などの変化からモデルを作るMMMといった手法も人単位ではなくするアプローチに含まれるといえます。
二つ目は、集団単位にするというアプローチです。主にブラウザ事業者が提唱しており、Privacy Sandboxのように個人を特定しない広告システムの開発が進んでいます。
三つ目が、きちんと許諾を取ることで人単位の計測を維持するアプローチです。各広告配信プラットフォームの持つ許諾取得済のログインIDはこの一つです。
さて、手段軸を整理したところで、目的軸に「これからのメディアプランニング」を置いた場合に、どういった変動が起き得るかを考えましょう。先ほどの図でいうと、メディアプランニングで影響を受けるのが図の左側の領域です。
まず前提として、この領域はそもそも在庫がクロスしなければ影響を受けないため、自社在庫が中心のSNS系はスタート地点から有利だといえます。他にも、大手プラットフォームは利用者の登録時に許諾を取得したログインIDを大量に保有しています。在庫が自社ドメインやアプリ面であれば、この許諾済のログインIDを用いることでCookie規制の影響を受けません。
その結果、許諾を取れている大手メガプラットフォーム（いわゆるWalled Garden）への集中がさらに進む可能性が高いと思っています。われわれはこうしたメガプラットフォームのことを、ログインIDに基づく「経済圏」として捉え、各「経済圏」の中のデータを用いた計測やマーケティングの重要性が高まるとみています。
ただ、デジタル上の在庫総量でいうとSNS系の面だけではなく、やはりいまだにGDNをはじめとしたアドネットワークや、各種DSPといったオープンウェブ面の在庫比率が高いです。そのためGDNの効率が、3rd Party Cookieが使えなくなることで悪化した場合、その分の予算をオープンウェブ上、例えばDSPなどに振り分けていくということはあり得ると思っています。
こうした経済圏IDに対抗するための手法として、ADNW・DSP系の事業者が連合しているのがUnified ID 2.0の取り組みだと捉えています。
※参考リンク：
Unified ID 2.0によって、参画媒体の連合として擬似的な経済圏を作り、そのエコシステムの中では大手プラットフォームの経済圏と同様にターゲティングや計測ができるようにしていく、という取り組みといえるでしょう。
同様に、IDに依存しないコンテクスチュアルターゲティング系のソリューションも、メガ経済圏への対抗軸として今いろいろと手を打とうとしているのだと思います。ただ、ご存じのとおり過去の経緯として「枠から人へ」とずっと言われてきていますが、裏を返すと、枠よりも人ベースのターゲティングのほうが効率がよいからそうなっていったわけです。
それが急にCookieが使えないから「やはり人じゃなくて枠だ」となったとして、CPA重視なクライアントが満足するだけの効率でコンバージョンが取れるのかというと、難しいのではないかという気もしています。
ただし、当時と違ってコンテクスチュアルターゲティングの性能自体が大幅に進化しているので、実際にどれくらいの効率になるかはやってみなければ分かりませんし、CPA以外の指標で見たときにはこうした文脈に沿った訴求が望ましいクライアントもいると思うので、そうした可能性も含めて見ていくべきでしょう。
※参考リンク：
とはいえ今回は、Cookieに依存してきた、CPA重視のクライアントの場合の影響、というお題なので、あくまでCPAを重視した場合に、という観点で考えていきます。その場合、CPA効率を担保できるかどうかの変数として何があるかというと、話が戻るのですが、Privacy Sandbox、Unified ID 2.0だと思っています。この領域でいうとFLoCですが、参画媒体がどれだけ増えて、それによってGDNの効率がどれだけ担保できるかというところです。FLoC自体はオープンな仕組みなので、GDN以上に使いこなすADNW/DSP事業者が出てくる可能性ももちろんあります。
それなりの数の媒体社がオプトアウトせず情報がちゃんと取れて、効率が今までどおり維持できるとしたら、おそらくGDNの成果はそこまで変わらないでしょう。あとはUnified ID 2.0がどこまで広まるかによって、効率が担保できるかが変わってきます。
つまり、この二つの方法がどれだけボリュームと効率が担保できるかによって、それ以外のところがどれだけ使われるかが変わってくるのではないでしょうか。結論としては様子見だと思っていますが、論点はこの二つだと思っています。
また、コンテクスチュアルターゲティングというと、いわゆるDSP系がやるものだと思われがちですが、当然GDNでも使っています。GDN vs コンテクスチュアルターゲティングのような対立構造ではないということを強調しておきます。
Safariでは、このCookie規制はすでに起きているので、現時点ですでにGDNは例えば「人」ベースの興味関心ターゲティングをできていないし、最適化もできていないことになります。それでもある程度効率が担保できているのは、Chrome側で得た情報を元に作った学習モデルをSafariにもコンテクスチュアル情報を使って適用させているので、その分、効率が担保できているのだと想像しています。
それでいうと、もうすでに、そのコンテクスチュアルターゲティングを併用した形での最適化という経験をGoogleは持っているわけです。FLoCも入ってきますし、学習元のChromeの情報が減る中でもうまくやっていく方法をGoogleは見据えているのではないでしょうか。そう考えると、必ずしも効率が圧倒的に悪くなるかというと、そんなことはないと思うのです。ふたを開けてみないと分からないのですが。
高瀬：僕も同じ認識です。結局、Walled Gardenはオープンウェブと比較すると受ける影響としては小さいです。では、オープンウェブでどこが代替になるかといえば、三谷さんがおっしゃっているFLoCとUnified ID 2.0だと思います。
コンテクスチュアルターゲティングは、CPA偏重なクライアントだと見合わないケースが発生すると僕も思っています。先ほど三谷さんがおっしゃった「枠から人へ」に関連する獲得効率はもちろんのこと、広告在庫がプレミアム枠に限定されていたり、インプレッション課金されるなど、追加費用もどうしても発生するからです。この場合、従来からあるGDNのコンテンツターゲットで事足りるケースも多分にあるという認識です。
ちなみに、Privacy Sandboxの枠組みの中でリターゲティングについては、どう思われますか。
三谷：結局、こちらの対策をきちんととっておけば、Googleが運営している面については引き続き影響を受けないでしょう。GDNのリターゲティングがどうなるかという点では、FLEDGEがどれだけワークするかというところによるのではないでしょうか。
なぜ、そこまで影響が出ていないのかはあまり分かっていないのですが、True Lift Modelの開発者としてのポジショントーク的にはリターゲティング偏重はやめてほしいので、うまく行かないときにどうなるかを見てみたいと思いつつ、なんだかんだ広告主のニーズについて話していて特に思うのは、皆さんリターゲティングが大好きだということです。これだけニーズがあるのであれば、やはりなんらかの代替手段も出てくるのではないかと思っています。
※参考リンク：
高瀬：おっしゃるとおり、現時点でもリターゲティングに偏っているクライアントさんは実際にいらっしゃるので、全くなくなることはないと僕も思います。
三谷：FLoCのもう一つの側面としては、タグが入っていないサイトでも情報が取れるので、見方によってはある意味、情報量が増えるわけですよね。そうすると、もしかしたら逆に、今までの興味関心ターゲティングよりもFLoCベースの興味関心ターゲティングのほうが効率がよいという可能性もあり得ます。
おそらくGoogleの機械学習の精度もさらに上がるでしょうし、情報量も増えるので、リターゲティングよりも興味関心は効率が悪いとはいっても、必ずしもそうではなくなる世界もあり得ると思うのです。
高瀬：三谷さんが考える3rd Party Cookieサポート終了の前後で変わるであろうことを中心にお話しいただきましたが、逆に変わらないことはあると思われますか。
三谷：結局、先程の図の左側の議論は、FLoCが今後どうなるか、Unified IDがどうなるかによって流動的だと思うのです。現時点で結論が出る話ではありませんし、そもそもまだ発展途上です。逆に右側の議論の、コンバージョンユーザーの特定については、すでに今できることですし、ITPの影響をもう受けているので、まずこちらの対応をやり切るのがよいのではないでしょうか。
3rd Party Cookieの廃止に至るまでまだ少し時間がありますが、Privacy SandboxやUnified ID 2.0の情報をキャッチアップすべきでしょう。マーケターとしては、ご自身で難しかったとしても広告代理店に聞くなどしていただいたほうがよいはずですし、われわれも情報のキャッチアップはトッププライオリティーだと思っています。
高瀬：ありがとうございます。最後に、Cookieレス時代に向けてマーケターが今から準備できることは何かを教えていただきたいのですが、今の三谷さんの回答だと、広告代理店の方であれば最新情報にキャッチアップして、クライアントから聞かれたら正しい知識を持って進言できるようにすることでしょうか。
クライアントサイドでは、いわゆる丸投げ体質というか、広告代理店が全部なんとかしてくれるという認識を改めることから始めるべきかと思いました。
三谷：そうですね。自助努力が必要だというのは間違いないでしょう。「X-Stack Connect」を導入するにしても、結局そのタグに対する最低限の理解は必要ですし、あるいはDNS設定でドメインを振るなどの設定が必要になってくるので、今までほど「お任せして終わり」とはならないと思っています。
こういう話のとき、いつも1st Party データを準備しておきましょうという話になりがちで、もちろんそれも大事なのですが、クライアントによっては必ずしも1st Party データを取れる事業ではないこともあります。では、それでもう何もできなくて終わりなのかというと、そんなことはありません。
例えばデータクリーンルームを使って、1st Party データではなくデータクリーンルームの中での興味関心属性を使って自社の顧客像を再現し、定点観測していくという使い方もあると思うのです。それにしても自社顧客を興味関心属性で作るという変換は必要になりますが、顧客データで完結するので、1st Party データを、わざわざ許諾を取って集めなくてもいいわけです。
むしろ、われわれとしては1st Party データがないクライアントにおいても、自社のアセット、例えばCookieベースのアセットや「X-Stack Connect」で取ったような個人情報を使わない情報であったとしても、データクリーンルームを使うことによって今までのマーケティングよりも進化させていくことができると思っていますし、逆にそういったパッケージを作っていかないといけないのではないかと思っています。
Walled Gardenについても、個人的にはUnified ID 2.0と並列なのではないかと思っています。つまり、Walled Gardenは全て垂直統合になっていますが、ID部分だけ擬似的に共通化しているのがUnified ID 2.0だと考えると、このIDで統一された世界という意味で、オープンウェブとはいえ、これも一つのWalled Gardenだと捉えられます。
その意味でいうと、Walled Garden、弊社では最近「経済圏マーケティング」ということが多いのですが、これは別にGoogle、Facebookに限った話ではなく、楽天やYahoo!という、その経済圏で1 IDで統一化されている世界が並列でいくつかあるうちの一つとして、Unified ID 2.0というのも今後あり得ると思います。そこは、われわれとしてはウォッチしていかないといけないと思っています。
高瀬：ありがとうございます。おっしゃるとおり、サイズは大小違いがあれど、今後は経済圏がたくさん増えていくと思います。そうした中で、検討しないといけないWalled Gardenがたくさん出てくるので、マーケター受難な時代が来そうですね。
三谷：そこは併用するために1st Party データでもいいですし、クラスタリングした顧客像でもいいですし、何かしら物差しを作って、それをベースに併用していくことが今後、求められると思います。また、われわれとしても、そういったパッケージを作っていきたいと思っています。
高瀬：確かに、その物差しがないと検討もできないですね。本日はありがとうございました。
※当記事の内容、所属、肩書きなどは、記事公開時点のものです。
facebook
X (twitter)
LINE
