Cookie規制によるインターネット広告の現状とその対策

第2回では、Cookie(クッキー)の利用規制によってサイトを横断した計測ができなくなることと、それによってコンバージョン計測、入札の最適化、リターゲティング広告といったインターネット広告の重要なパーツが使えなくなることを紹介しました。今回は、こうした規制がすでに始まっている中で、実際にどういった影響が出ており、どのような対策があるのかを見ていきます。

Cookieフリーへの対応の現状

ここまで見てきたCookie規制の話には、将来起こる可能性のある不確かな未来の話も一部含まれますが、大多数はSafari の規制であるITP(Intelligent Tracking Prevention)によって既に起こっている現在進行形の話です。

実際に、3rd Party Cookie(サードパーティ・クッキー)はSafariにおいて2020年3月からフルブロックとなっており、1年以上前から利用できません。それでは、なぜ効率の悪化が大きな問題になっていないのでしょうか。それは、1st Party Cookie(ファーストパーティ・クッキー)併用の抜け道が存在しているからだと考えられます。

テクニカルな話になりますが簡単に説明すると、広告プラットフォームは広告をクリックしたユーザーに、ユーザーの識別子として任意のID(ここではjaneとします)を発番して、リンク先に付与する(リンクデコレーション)ことができます。この情報は、あくまで広告プラットフォームの中で発番したIDなので、クロスサイトトラッキング規制とは無関係に情報として持つことができます。

一方で広告主側の視点から見ると、janeという識別子が付与されたURLで来訪したユーザーがいることを、サイトのアクセス情報として把握することができます。

このユーザーのコンバージョンも、広告主側の視点では「janeという識別子付きのURLでサイトに来訪し、その後コンバージョンした」という自社サイト内の行動として計測が可能です。

それぞれ、あくまで広告配信プラットフォームとクライアントサイトの自社サイト内行動のデータのはずが、リンククリック時に発番したjaneというIDによりひもづけられることで、結果的にサイトを横断した計測ができることになります。

この手法を使えば、1st Party Cookieベースで24時間以内のコンバージョンであれば計測できるため、ITPによる計測欠損の影響が小さく抑えられてきた、と考えられます。

それではこの仕組みがあれば、広告主としては特に対策しなくても今まで通りの計測を維持できるのでしょうか。以下の2つの理由から、その答えはNoです。

1. 1st Party Cookie併用型計測の持続可能性の問題

リンクデコレーションの方式もブラウザCookieに依存した手法です。サイト来訪時にデコレーションされたIDと、自社サイト内でのコンバージョン情報をひもづけることができなければ成り立たない手法ですが、このひもづけには1st Party Cookieを利用しています。つまりその意味で、Cookieフリーの手法にはなっていません。

Apple社はすでに、1st Party Cookieも計測目的の場合の有効期限を短縮しています(ITP2.2)し、追加規制のリスクもあります。加えてATT(App Tracking Transparency)の規制では、アプリからの遷移は許諾がない限りユーザー単位では発番できなくなっています。

2. リンクデコレーションでは原理的に計測できないコンバージョンの存在

2つめの理由は、リンクデコレーションはあくまで広告クリック後に発番されるIDなので、リンクをクリックしない経路での来訪はカバーできないということです。例えばビュースルーコンバージョンは、この手法ではカバーできません。

Cookieフリーに対応するために広告主が取りうる対策

より持続可能性の高い計測のために広告主が取りうるアプローチは大きく2つあります。1つ目は1st Party Cookie併用型計測の基盤を強化して、持続可能性を維持・向上すること。2つ目はデコレーションに依存しない、別の識別子を利用することです。

なお、以下はあくまで技術的な観点での議論であり、ユーザーからの許諾については適切に取得できている前提の話です。

1つ目の持続可能性の維持・向上のために取りうるアプローチは、サーバーサイド計測の採用です。いままでのCookieによる計測は、すべてブラウザ側に計測を依存してきていました。しかし、ユーザーがサイトにアクセスするときは、ブラウザはあくまでインタフェースであり、最終的なアクセスが発生するのはサーバーです。

ブラウザレイヤーの情報は、ブラウザ事業者の規制次第で利用できなくなるため、発想を切り替えてサーバーレイヤーの情報を使う、というのがサーバーサイド計測のアプローチです。

サーバー側のアクセスログにはいろいろな情報がありますが、ITPで制限が掛けられているのはJavaScriptで発行されたCookieについてなので、サーバー側で発行されたCookie情報については利用が可能で、これを使うことでリンクデコレーションとコンバージョンフラグを、24時間を超えた長期間にわたってひもづけることができるようになります。

ただし1st Party Cookie併用型の計測は、あくまでリンクデコレーション方式の延長線上なので、リンクデコレーション自体の規制や、リンクを介さないビュースルーコンバージョンはカバーできません。そのために使われる手法が2点目の、別の識別子の利用です。

計測の維持とは、究極的には広告プラットフォームでの接触者と、広告主サイトでのコンバージョン情報のひもづけがゴールです。つまり、広告プラットフォーム側でどのユーザーかが特定できれば良いわけです。

そこで、CookieやクリックIDといった案件ごとに発番される識別子ではなく、より汎用的に利用可能なメールアドレスや電話番号といった識別子を使う、という手法が生まれています。ユーザーが申込時に登録したメールアドレスなどの情報を広告プラットフォームに送り、広告プラットフォーム側ではもともと自社に登録されているメールアドレスと照合し、ひもづいた場合はそのユーザーがコンバージョンしたと判定する、という順番になります。

以上を整理すると、サーバーサイドのアクセスログ情報を利用してリンクデコレーションによるひもづけを維持・強化するアプローチと、申込時のフォーム入力情報から取得したユーザーの個人情報を利用するアプローチに分けることができます。どちらか片方の実装で良いかというと、可能な限り両方を実装することで計測カバー率を向上させることができます。

では、これらの情報を使った計測を行うためにはどのような実装が求められるのでしょうか。

従来のタグ計測の場合は、サイトにタグと呼ばれるJavaScriptのコードを追加すれば、自動的に情報を収集し、収集した情報を各広告プラットフォームに送ってくれました。

一方で、サーバーアクセスログやフォーム入力情報の収集は、タグの設置ほど簡単ではありません。サーバー側のアクセスログを取得するために、サイトが設置してあるサーバーから出力されるログデータを集めたり、あるいはフォーム入力情報を取得するために基幹システムに格納されたデータから必要な情報を抽出したりしなければなりません。

さらに関連部署も多岐にわたり、要件定義や仕様確認などで莫大なコミュニケーションコストや実装費用がかかってきます。タグを貼って終わり式の他力本願ではなく、自分たちで計測基盤を整えていくという「自助努力」が求められるようになっていると言えるでしょう。

また、こうして集めた情報を各広告プラットフォームに送るわけですが、多くの場合プラットフォーム側はあくまで情報の受け口しか用意していません。送る情報の中身は広告主次第であり、仮に計測維持に全く無意味な情報しか送られていなくても、プラットフォーム側が教えてくれるわけではありません。

なので、見た目上は情報を集めて送る実装をしていたとしても、ふたを開けてみると計測の維持には全く無意味だった、という悲劇もありえます。ベンダー任せではなく、中身をきちんと確認することが重要だと言えるでしょう。