IDFA とCookie の制限がマーケティングに与える影響とその対策

IDFA が 2021 年初頭より iOS / iPadOS 14 以降でオプトイン方式に変更されるというニュースが駆け巡りました(※)。IDFA はネイティブアプリで広告などのトラッキングにも使われており、広告出稿という視点からも大きなインパクトがあります。

この仕様変更やITPおよびサードパーティ Cookie の廃止は、オンライン広告におけるユーザのトラッキングを根本的に変えるほどの大きな影響を与え得ること、そして、引き続き集客していくためには、広告配信に必要なピクセルまたはタグを最新のものにアップデートしていくだけではなく、サービスそのものの設計から考え直すべきであることをご紹介したいと思います。

2020年9月3日、Appleは、IDFA使用制限の開始時期を2021年以降に延期することを公表しました。

IDFA がどのように使われてきたか

そもそもIDFAとは

IDFA (IDentifier For Advertisers) とは、Apple iOS / iPadOS 上で端末ごとに割り振られる一意の ID のことを指します。この ID は、単体では個人情報などのユーザを特定するいかなる情報とも独立したもので、ユーザが任意のタイミングでリセット可能なものです。

なお、Android にも Advertising ID; AAID と呼ばれる同様の ID が存在し、こちらも同じようにユーザが任意のタイミングでリセット可能です。

IDFA と名寄せ

この IDFA は、それ単体ではそのユーザが誰かを特定できるものではありません。ですが、Facebook や Google、 Twitter といったコンシューマ向けプラットフォーム (以下プラットフォーム) と組み合わせることで、複数デバイスを名寄せしてプラットフォーム側ユーザと紐付けることが可能となります。

たとえばスマートフォンで Facebook や Instagram を使おうとすると、Facebook が提供しているネイティブアプリを使う場合がほとんどです。このネイティブアプリは Facebook / Instagram にログインすると同時に IDFA を Facebook に送信しています。これにより、 Facebook / Instagram 上のユーザと IDFA が紐付きます。

また、スマートフォンではそれ以外の色々なネイティブアプリを使っているかと思います。これらのネイティブアプリでは、例えば広告配信であったりログイン機能の利用など、様々な目的のために Facebook が提供するネイティブアプリ向け SDK (以下 Facebook SDK) がアプリ内に実装されていることがあります。

この Facebook SDK がネイティブアプリ内に実装されていると、アプリ起動のタイミングから Facebook に各種イベントを送信します。このときに IDFA があわせて送信されており、Facebook 側では特に Facebook にログインしているかに関わらず Facebook や Instagram のユーザと紐付けることが可能になります。

各ネイティブアプリで見た商品が Facebook や Instagram 上でリタゲーティングされたり、利用を止めたネイティブアプリの広告が表示されるのは、こういった仕組みで IDFA とプラットフォーム側のユーザが紐付けられた結果なのです。

クロスデバイストラッキング

このようにネイティブアプリ上では IDFA、そして Web では Cookie を利用してプラットフォーム側ユーザと紐付けられることにより、デバイスの垣根を越えて、そしてネイティブアプリと Web の境界を越えてのユーザトラッキングが可能となっていました

これが近年のデジタル広告において精度が高い広告配信を可能にしていた点であり、Google や Facebook / Instagram が莫大な利益を上げるための源泉でした。

ユーザトラッキング手法の根本的な変化

ネイティブアプリ面: IDFAのオプトイン化

こういった IDFA とプラットフォーム側のユーザを紐付ける手法は、一方で本来は「匿名」であった IDFA を骨抜きにすることになります。

このことを承けて、Apple は iOS / iPadOS 14 よりネイティブアプリで IDFA を取得する際は「取得していいかをダイアログで明示的に確認する」オプトイン方式に移行することとしました。

オプトイン形式となった場合、

  • なぜそのようなダイアログが表示されたか
  • そのダイアログで「許可」または「OK」することでどういうメリットがあるか

が分からない限りは許可しないパターンが多いのではないでしょうか。その結果、ネイティブアプリは IDFA を取得することができなくなります。

さらに、上で説明したクロスデバイスでのトラッキングが成立するためには、プラットフォーム側のネイティブアプリに加えて広告主側のネイティブアプリでも IDFA が取得できなければなりません。
つまり、ユーザトラッキングという文脈で考えると IDFA のオプトイン化は相当なインパクトがあることを意味します。

もちろん、この仕様変更は iOS / iPadOS 14 以降のみで、Android では今のところ同様の仕様変更は発表されていません。しかし、日本において 4 割超のシェアを占める iOS / iPadOS の仕様変更を無視できませんし、今後 Android 側が同様の仕様を実装しない保証もありません。

つまり、IDFA のオプトイン化とその対応はネイティブアプリ全般での喫緊の課題なのです。

Web面:サードパーティ Cookie の廃止

Web においても、ITP (Intelligent Tracking Prevention) の実装によりトラッキング目的の Cookie の使用が大幅に制限されたこと、また、Google Chrome でも 2022 年までにサードパーティ Cookie が廃止されることとなりました。

Cookie そのものは廃止されておらず、Web でのログイン機能の実装に不可欠なファーストパーティ Cookie そのものは残ります。ですが、たとえファーストパーティ Cookie であっても、ITP では機械学習を利用したフィルタリングによりトラッキング目的の Cookie と判定されると無効化されることなど、ユーザトラッキングに対する制限は年々厳しくなってきています。

つまり、プラットフォーム側のログイン情報をベースにした Cookie によるトラッキングも困になってきました。

属性情報を用いたマッチング

このような状況をうけて、Facebook は「手動詳細マッチング」と呼ばれるトラッキングタグの仕様であったり、サーバ間通信でイベント情報を送る「コンバージョンAPI」といった機能を推すようになってきました。

手動詳細マッチングは、これまでのプラットフォーム側ログイン情報を元にしたトラッキングではなく、ハッシュ化 (≒ 暗号化) されたメールアドレスや名前などの属性情報をピクセルのパラメータとして都度送信するものです。これは新規機能ではなく、また、Facebook のみならず Criteo でも同様の機能が実装されています。

属性情報を送信するのはコンバージョンAPIでも同様で、今後はユーザの行動履歴をトラッキングするための名寄せ情報としてハッシュ化された属性情報が鍵になってくることとなりました

属性情報を用いたマッチングの問題点

しかし、こういったハッシュ化された属性情報を用いたマッチングはいくつかの問題点があります。
具体的には、

  • ハッシュ化されたとはいえ「個人情報」を送信することそのものの問題点
  • ハッシュ化された属性情報のプラットフォーム側での取り扱い
  • 属性情報をどのように取得するか
  • どのようにパラメータとして引き渡すか

の4点です。

次に、これら4点について考察します。

ハッシュ化された属性情報を送信することそのものの問題点

まず第一に、ハッシュ化されているとはいえ属性情報を送信することそのものが課題でしょう。

ハッシュ化されているか否かに問わず、ユーザにとっては「『自分の個人情報』が第三者に送信される」ことそのものに違和感を感じるのがほとんどでしょう。マッチング精度を上げるためにはメールアドレスだけでなく、名前といった他の属性情報を送るべきですが、多くの属性情報を送れば送るほどユーザの不安は増大するのは言うまでもありません。

また、属性情報の送信に伴い、当然ながら利用規約であったり個人情報の取り扱いの規定も変更が必要ですし、告知も必要となります。

つまり、アプローチによっては IDFA のオプトイン化と同等のインパクトがあり得ることを想定しなければなりません。

また、ユーザの感情とは別に、個人情報保護法との兼ね合いも慎重に検討する必要があります。

ハッシュ化された属性情報のプラットフォーム側での取り扱い

Facebookの場合、属性情報はブラウザ側でハッシュ化され、生の属性情報はFacebookには送信されません。また、Facebook 側 API でもハッシュ化されたもののみがパラメータとして受け付けられています。
Facebook によると、マッチングが完了次第ハッシュ化された情報は破棄されるとのことですが、昨今の流れからすると、本当に破棄されているか不安に感じるユーザも多いかと思われます。

属性情報の取得方法

ピクセルのパラメータとして属性情報を引き渡すためには、まず属性情報を取得する必要があります。しかし、Cookie でランダムに割り振るセッション ID と異なり、ここでいう「属性情報」とはユーザのメールアドレスであったり名前などですから、

  • ユーザ登録
  • Web サイトやネイティブアプリへのログイン

の2段階が必要になります。

手動詳細マッチングに対応させる場合、一番課題になるのが実はこの箇所です。トラッキングに属性情報が必須になる反面、エンドユーザからすれば 1. ユーザ登録して 2. かつログインするという2つのハードルを越える必要があります。

仮にユーザ登録したとしても、例えば一般的な EC サイトの場合、ログインするタイミングは決済直前であることも多いでしょう。ユーザの視点からすると当たり前のことですが、これでは例えば商品閲覧やカート追加といった行動をトラッキングできないことになります。

ログインするタイミングを見据えたサイトの再設計が必要でしょう。詳しくは後述します。

属性情報の引渡し方法

最後に、ユーザがログインしたとしても、ピクセルにその属性情報を引き渡すのが課題となり得ます。

仮にピクセルをタグマネージャ経由で実装している場合、例えば HTML 内に属性情報を JavaScript 変数で埋め込んだり、または属性情報を取得できる REST API を実装して、JavaScript でアクセスするといった手法を採る必要があります。

ですが、前者の場合は、復号可能な状態で暗号化しない限りは HTML 内に属性情報が生で露出してしまい、ユーザに違和感を与えかねません。

また、後者の場合、セキュリティの観点から慎重に仕様を策定しないと、悪意の第三者にユーザの個人情報を垂れ流すきっかけになってしまいます。

つまり、属性情報を送信する段階でも技術的な課題がいくつか存在します。

いかにユーザにログインしてもらうか

ご紹介したとおり、IDFA や Cookie の制限が厳しくなる中、これまでと同じようにリタゲーティング広告やダイナミック広告といったユーザごとにパーソナライズされた広告を活用するには、属性情報をプラットフォームに送信する必要があります。広告主側からすると、その属性情報を取得するにはユーザが会員登録した上でログインする必要があるため、ユーザが如何に早いタイミングでログインするかが鍵となります。

ユーザがログインするのは、言うまでもなくユーザが必要に迫られたタイミングです。ですが、一方で大手 EC サイトを見ると、ログインしたユーザに対して適切なレコメンドであったり価格比較であったりといった「付加価値のある追加情報」を提供することで、自然にユーザがログインする状況を作り出しています。

つまり、ユーザに対してメリットを提供することで、事業者側が必要とする行動情報が自然と提供される情報を作っているのです。

これまでは、広告運用で必要なピクセルの設置であったりクリエイティブの作成であったりといった作業は、マーケティング部門で完結するタスクでした。部門を超えての作業が必要になるタイミングはデータフィードの作成などごく一部といっても過言ではなかったでしょう。

ですが、ユーザが早いタイミングでログインするためのメリットを提供するサイトの構成となると、決してマーケティング部門だけでは完結しません。

サービス運営に関わる全ての部門を結集して、「自サービスにおけるユーザの初来訪からコンバージョンまでの全体的な遷移・体験」を踏まえたサービス構成を再検討し、早期の対応が必要になります

最後に

サービスを実装する際に、ログインは避けて通れないものであるにもかかわらずコストパフォーマンスの悪い、できれば外製化したい部分だと思います。

ですが、ご紹介したとおり、ログインとは、これからのマーケティングのスタート地点そのものなのです。

弊社ソーシャルPLUSが提供するLINEのCRM活用・ソーシャルログインサービス「ソーシャル PLUS」は、単にログインを外製化するだけでなく、その後のマーケティング全体を見据えた機能を提供するものです。ソーシャルログインの導入をご検討の際は、ぜひお気軽にお問い合わせください。

タイトルとURLをコピーしました