2020年後半のFacebook Adsにおけるトラッキングを考える
2020 年のコロナ禍の中、Apple が ITP での Cookie の扱いの厳格化に引き続いて IDFAの取扱の厳格化を進めることとなった。
今回は、2020 年後半に Facebook がどのように広告でユーザをトラッキングするのかを NDA に触れない範囲で考察したい。
目次
TL; DR
まずは結論を先に書いておく。
- 既存のトラッキング手法は全て死ぬ。
- ユーザ属性を持たない / 推測できないプラットフォームは名寄せできずにパフォーマンスを落としてしまう。
- 既存のダイレクトレスポンスマーケティングを踏襲する限り、「個人情報が露出してしまうかもしれない」問題を乗り越えつつも、新しいトラッキング方法に早急に移行する必要がある。
また、シグナルを集める観点からも、エンドユーザがログインするタイミングを購買行動というストーリーにあわせて早めに設定する必要がある。 - つまり、ログインとは単純に認可・認証ではなく、オンラインマーケティングの一環として考えるべき。
これまでのトラッキング; Cookie と IDFA / Advertising ID
これまでのエンドユーザのトラッキングは、
- ブラウザの場合 – Cookie, 特にサードパーティ Cookie
- ネイティブアプリの場合 – IDFA (iOS / iPadOS) または Advertising ID (Android)
と 2 パターンだった。
今回、iOS / iPadOS の次期バージョンである 14 で IDFA がオプトイン形式になるという大ニュースが出た。
IDFA とは
IDFA とは IDentifier For Advertisers の略で、iOS / iPadOS 端末ごとに割り振られる固有の ID となる。この ID は主に広告など匿名化された状態でユーザをトラッキングするために使われ、任意のタイミングでユーザがリセットすることもできる。
この IDFA はネイティブアプリに関係なく端末で固有なので、クロスアプリでトラッキングできる。
なので、Google や Facebook / Instagram といったプラットフォーマーは自社アプリで IDFA を収集することにより、自社プラットフォーム上のユーザと IDFA を紐付けることができた。
これにより、これらプラットフォーマーが提供する SDK でもどのユーザがサードパーティアプリを使っているかを特定できるため、それらサードパーティ上の広告でのユーザ特定および広告効果測定、広告配信の最適化が可能となっていた。
iOS / iPadOS 14 で IDFA がオプトイン方式になる問題
今回、IDFA がオプトイン方式になることが発表されたが、問題はどれくらいの割合でオプトインされるかになるのは言うまでもない。
これに関連して先月出た記事の中でインパクトがあったのは、「How might IDFA deprecation have minimal impact? | Mobile Dev Memo」というもの。
これによると、アメリカで実験したところ、オプトインするかどうか (= IDFA によるトラッキングを許可するか) を聞くダイアログのボタンを「トラッキングを許可する」にすると 14% が許可、単純に「OK」にしても 17% にしかならないという。
これが日本でも広く適用できるのであれば、事実上 IDFA は死に体になってしまう。
まだ Android 上での似たような ID である Advertising ID については何も発表されていないが、少なくとも国内では iOS / iPadOS のシェアが高い以上、無視できないインパクトがあると考えた方がいい。
Cookie によるトラッキング
ここで、改めて Cookie によるトラッキングを振り返っておきたい。
広告のためにエンドユーザの行動をトラッキングする上で必要なのは、ユーザの名寄せである。
最近はスマホや PC など、複数の端末で同一人物がアクセスしてくるので、それらを名寄せし、1 人のユーザであることを特定する必要がある。
ここで重要なのは、あくまでも「一個人」としては匿名化されており、トラッキングのために個人情報は不要だということだ。
もちろん、広告ターゲティングのために性別や年齢層、年収などの属性情報が重要なのは言うまでもない。
だが、これらの情報が鍵になるのはあくまでも最適な広告配信という点であり、ダイレクトレスポンス広告またはアプリインストール広告という文脈ではこれらの属性情報は必須ではない。
広告プラットフォームは、Cookie を使ってエンドユーザの行動をトラッキングしている。具体的にはブラウザ・ドメインごとに一意の ID を振り、これを元にトラッキングしているが、これだけではあくまでも特定のドメインでのユーザおよびその行動しかトラッキングできない。
そこで、サードパーティ Cookie でプラットフォーム側のユーザ ID、例えば Google アカウントや Facebook アカウントと紐付けていた。
サードパーティ Cookie の現状
このサードパーティ Cookie については、
- Safari – iOS / iPadOS 13.4 より完全にブロック。
- Chrome – 2022 年までに廃止。
- Firefox – 2019年6月リリースの 67.0.1 以降、新規インストールした場合はデフォルトでブロック。
となっている。つまり、iOS の割合が高い日本ではすでにかなりの割合が、さらに遅くとも 2022 年にはほぼサードパーティ Cookie が死ぬことになる。
もちろんプラットフォーム側も座視しているわけではなく、例えばプラットフォーム側からのリンクに一意の ID を振るなどしてプラットフォーム側 ID との紐付けを行うなど、ハックを続けている。ただ、これについても ITP 3.0 では規制された。
そのため、プラットフォーム側はサードパーティのネイティブアプリに自社 SDK を入れさせて IDFA ベースでトラッキングする方向を推してくる向きもあった。
今回の変更で、このルートについても規制が入ることになる。
今後のプラットフォームの対応
Facebook 手動詳細マッチング
これらを承けて、Facebook は「手動詳細マッチング」と呼ばれるピクセルの設置を強力に推奨し始めた。
これは、これまでの Facebook 側 Cookie に依存して名寄せをするのではなく、ユーザのメールアドレスや名前といった属性情報をブラウザ側でハッシュ化した上で Facebook に送信し、Facebook 上に登録された属性情報と照合してユーザを特定するものになる。
この機能に関して Facebook は
- Pixel 経由で送信される属性情報は Pixel スクリプト側でハッシュ化され、Facebook では復号化できない。
- 送信されたハッシュは、マッチング処理後直ちに削除される。
- Conversions API 経由で送信する場合は、そもそも呼び出し側でハッシュ化されるので Facebook 側で復号化の余地はない。
と言っている。
が、実際に Pixel をインストールしないといけない事業者側からすると、ハッシュ化されているとはいえ「個人情報」を安直に送信することには抵抗があるし、そもそも利用規約や個人情報の取扱についての規約を変更する必要もあるだろう。
また、Pixel 経由で送信する場合、何かしらの形でエンドユーザの属性情報を Pixel の JavaScript に引き渡す必要がある。この際、以下の問題がある。
- どのように属性情報を Pixel に引き渡すか?
- サーバサイドで HTML に属性情報を埋め込む。
「生の個人情報」が HTML に含まれるため、エンドユーザまたは第三者からセキュリティに関する指摘がほぼ間違いなく入る。 - 属性情報を返す WebAPI を実装し、その API 経由で属性情報を取得する。
実装次第では悪意のある第三者の Web サイト経由で個人情報を抜き放題になるので、サーバサイドを巻き込んだ認証を考える必要があるなど、上よりも実装コストは高くなる。
- サーバサイドで HTML に属性情報を埋め込む。
- そもそもユーザがログインしていなければ属性情報を取得しようがない。
Pixel スクリプト側でハッシュ化してくれるのは便利ではあるが、生の属性情報を引き渡さないといけないのは相当厳しい問題になる。<img> タグを使えばサーバサイドでハッシュ化したものを渡せるが、Facebook 側の仕様変更に対して随時こちら側でも対応が必要になるという問題点もあるので余りお勧めではない。
なお、このように色々と問題があるようにも思えるが、同様のメカニズムは Criteo がかなり初期から実装しているものである。
Criteo ではそもそも名寄せの軸となる自前のユーザを持つプラットフォームを持たない純粋な広告配信プラットフォームのため、初期からメールアドレスなどをハッシュ化して送信するメカニズムを持っている。
これに Facebook が追随したと考えてよいだろう。おそらくは他のプラットフォームもこれに追随するのではないだろうか。
Conversions API
上にも書いたとおり、手動詳細マッチングは属性情報がソースに露出してしまう問題がある。ここがネックになる場合、Facebook Conversions API を使ってサーバ間通信でイベントを送信する方法がある。
これは、手動詳細マッチングとほぼ同じ情報をサーバ間通信で送るものになる。こちら側のサーバで属性情報をハッシュ化するため、「実は Pixel が生の属性情報を送っているのではないか」という懸念を払拭できる。
Conversions API については、一方でデメリットもある。
- 実装コストが高い。日本国内だとありがちだが、外注している場合は費用対効果が合わない可能性が高い。
- アップデートに追随する必要がある。当然ながらそのコストが問題となる。
個人的には、持続可能性の観点からも Pixel の方をお勧めしたい。
それでも属性情報を送らなければいけない理由
「どうしても『個人情報』を送らないといけないですか?」
これはマーケターならどうしても出てくる疑問だろう。これに対する回答は
YES
しかない。もちろん、ブランディング広告や Instagram のオーガニック投稿に頼るという選択肢もある。アパレルやコスメなど、商材によっては非常に有効だし、オーガニックだけでも十分なリードを獲得できるだろう。
一方で、そういった一部を除けば、リタゲーティングなどの手法に頼るケースがほとんどだろう。こういったケースに関してはエンドユーザの名寄せという観点からも属性情報の送信は必須となる。
複数の代理店を使うことの問題点
多くの広告主の場合、これらの対応を代理店に指示することだろう。複数の代理店で同一プラットフォームへの出稿を任せている例も多々あることと思う。
こういった場合、代理店に依頼しても積極的に動いてくれないパターンが多いという点には気をつけた方がいいだろう。なぜなら、Facebook ではオーディエンスなり Pixel を複数の広告アカウントで共有できるので、ある代理店が苦労して新しいトラッキングに対応したとして他の代理店はその成果にただ乗りできるからだ。
つまり、その代理店からすると競合に塩を送るようなものとなってしまう。これが積極的に動いてくれない一番の理由となる。
これの対応としてはいくつかある。具体的には、
- 代理店を一つに寄せる。
- こういった事例に対するコンサルティングを行う事業者なり代理店に別途依頼する。Facebook Marketing Partners for Technical Services と呼ばれる認証もある。
といったところだろうか。残念ながら Facebook Marketing Partners for Technical Services を取得している事業者は国内にはまだいないはずだが、ワンショットで対応してくれる代理店であったり、または筆者も含めて個人でのサポートを提供する事業者がいるかも知れない。
まずはログインから考えよう
前述の通り、Cookie の仕組みも変わりつつある今、属性情報を Pixel 経由で送信するためにはそもそも属性情報を取得する必要がある。
そして、広告主からするとそういった属性情報はユーザ登録が済んでおり、かつサイトにログインしていないと取得できない。
ここが重要なのだ。特に EC の場合、エンドユーザはカートをチェックアウトするタイミングで初めてサイトにログインするパターンが多いと思う。
だが、これでは遅すぎるのだ。これではチェックアウトイベントしか取得できないに等しく、サイト上の回遊情報はほぼ取れないと考えてよい。
もちろん、同一ブラウザ上であれば、その前のカートインや閲覧なども遡って取得はできる。だが、例えばスマホで閲覧して PC で購買するなどといった閲覧と購買が分かれてしまった場合、せっかく集めたトラッキング情報が無駄になってしまうのだ。
そのため、より最適なトラッキングを行うためにはまずエンドユーザをサイトにログインさせる必要がある。
だが、ユーザはメリットがないのにわざわざサイトにログインはしない。「会員登録でポイント進呈」「ログインすると1日に xx ポイント進呈」といった施策を打ったとしてもそこまで効率はよくないだろう。
つまり、
ユーザが
まずログインすることで
どういうメリットを得られるか
を真剣に考える必要がある、ということだ。
なぜ Amazon では皆ログインしているか、なぜ自社 EC ではチェックアウト直前にしかログインしないのか、そこを見つめた上で、ユーザがまずログインしたくなるストーリーを考える必要がある、と言った方がいいだろう。
ここまで書いてきたことは真新しいことではなく、デジタルマーケティングの先端を走る事業者であればすでに実践していることである。ではあるが、今回の一連の仕様変更により、改めて「ログインとはオンラインマーケティングの最重要パートである」ことを再確認するいい機会となった。
また、特に日本においては、開発の実働部隊とはあくまでもコスト部門であり、外注とする傾向が強かった。だが、今後、よりマーケティングであったりマーケットのトレンドの変化が早まっていくと、既存の改修サイクルでは明らかに追いつかなくなるだろう。
そういう観点でも、開発の内製化であったり、SaaS 等を利用した機能の外部化は非常に重要になってくる。
特に SaaS の利用については、単に機能を外部化するという観点ではなく、外部化することによってどういった付加価値があるか、どうレバレッジできるかを十分に検討すべきではないだろうか。
