オルタナティブ・ブログ > That's the Way to GO! >

いつの時代も「今がまさに変革期」。自分の判断を信じ、道なき道を探検中

リワード広告におけるCookieも端末IDも使わないFingerPrintを使った計測方法について

»

 

かなり久しぶりの投稿になりますが、

今回は最近よく聞かれるようになった「FingerPrint(Device Fingerprinting)」という技術について書いてみたいと思います。「なぜにリワード広告で使えるの?」までを説明するに、これまでの計測方法の経緯もあったほうがわかりやすいと思ったので少し長文です。

 

直訳で「指紋」を意味するこのFingerPrintですが、

「(広告計測で使われる)FingerPrintってなんですか?ググっても日本語のサイトがあまりないんですよ。」とよく聞かれるようになりました。このFingerPrintを超ざっくり言うと「アクセスする端末のブラウザから取得できる情報(ブラウザのバージョンやプラグイン、解像度、IPアドレスなどなど)から端末を推測する技術」といった感じになります。

2010年ころにElectronic Frontier Foundation(電子フロンティア財団)から「How Unique Is Your Browser?」といった感じ公開されており、ブラウザからどのような情報が取得でき、どのようなアルゴリズムによって特定(推測)ができるか、その精度についても触れられており、Electronic Frontier Foundationのサイトよりデモをみることも可能です。

Cookieも端末IDも使用せずに端末を推測する技術として、海外の企業がこのFingerPrintの基礎技術を使い、独自にカスタマイズして製品化していたりします。

 

さて、何故このような端末を推測するIDが必要になるのか。

順を追って説明してみたいと思います(概念の理解が大事だと思うので、いろんな詳細は省いてありますのであしからず)。

もともとスマートフォンアプリにおける広告計測ではUDIDやMACアドレスといった端末IDが使われていました。図にするとこんな感じです。

20131023_027

広告掲載を行うメディアアプリが、ユーザの端末ID(UDIDとかMACアドレス)を取得し、広告アプリのインストール時にユーザの端末IDを取得し、突き合わせる。シンプル イズ ベストな計測方法でした(*1)。対象の端末IDがあったらポイント付与、なかったら付与しないと行いった感じです。もちろん、一度広告アプリをインストールしたかの有無はシステムに保持しておき、重複チェックなどを行っていました。ただし、広告掲載メディアで端末IDを取得するので、アプリメディアである必要がありました。

 

そこで、登場したのがブラウザのCookieを使った計測方法です。

Cookieとはブラウザに書き込めるメモ領域みたいなもので、いろんな情報を保存しておくことができます。

20131023_028

このCookieを用いた計測方法は、クリック時のセッションID(クリック毎に発行されるランダムなID)をブラウザのCookieに保存しておき、広告アプリ起動時に(ブラウザが起動し)照合するやり方です。広告掲載メディアでは端末IDが取得できないため、誰がクリックしてインストールしたかを知ることができないため、Cookieに保存するセッションIDを使うといった仕組みになっています。計測SDKでは引き続き、端末IDを取得し、重複(ユニーク)チェック判別のため使われていました。アプリ起動時にブラウザが立ち上がるので違和感があった方もいらっしゃるのではないでしょうか。

 

そして、2011年末ころから端末ID問題

(名寄せや個人特定が可能といったプライバシーの懸念)により、AppleによるUDID規制やMACアドレスを取得できなくなりました。Androidでも同様にIMEIなどの端末IDが使われていましたが、上記の問題から端末ID使っちゃダメという流れになってきました。このブログでも何度か書きました。

iOSでのUDID規制からの端末IDへの再認識とAndroidでの現状と今後(特にリワード広告業界)
http://blogs.itmedia.co.jp/jinmsk/2012/06/iosudididandroi-ad3a.html
AppleによるUDID(端末ID)を使用しているアプリの規制がいよいよ開始
http://blogs.itmedia.co.jp/jinmsk/2013/03/appleudidid-f457.html
Apple UDIDの規制に引き続きMACアドレスも規制対象に。iOS7では取得ができない?
http://blogs.itmedia.co.jp/jinmsk/2013/06/apple-udidmacio-fb08.html

 

そこで端末IDに代わり登場したのが、

広告SDKで生成するUUIDになります。以下が図になりますが、UDIDがUUIDに変わった感じです。

20131023_029

さらっと「変わった」と書きましたが、UUIDはUDIDと異なり、広告主アプリを削除すると一緒に消えてしまうため、保存領域どうする?とかいろいろ試行錯誤ありました。ユニークIDが消えてしまうと何度もポイントをもらおうと企てる人たちがいるためです。そこでiOS・Android、それぞれに生成したユニークIDを保存するといった仕組みが確立されていきました。

また、この当時、私の会社ではCookieも端末IDも使わない計測を確立させていましたが、この動きには広告を掲載するメディアと広告主アプリに組み込んでもらう計測SDK、広告案件の連携を行うときにそれと他社リワード会社との連携が必要になるため、計測法方法を合わせなければいけないといったことから、Cookie計測が主流(*2)になっていました。独自に開発した計測方法はこちらにて説明しています。

 

さて、いよいよ本題となるFingerPrintについてです。

結論からいってしまうと、この「FingerPrint」の技術単体ではリワード広告におけるユニークIDとしては利用することはできません。具体的にいうと、リワード広告の特性上、広告アプリをインストールしたユーザにインセンティブとしてポイントを付与することが必要になるため、広告計測の精度は100%を求められます。このFingerPrintの場合、精度は年々テクノロジーの進化と蓄積するデータから上がってはいるものの、100%とはいえないのです。これまでFingerPrintを検証してきたところ、以下のような懸念があります。

・ブラウザがアップデートされるとIDが変わってしまう
FingerPrintの特性上、 ブラウザの情報に依存してしまう部分が強いため、ブラウザのアップデート(多くの場合はOSのアップデート)によって計測自体ができなくなってしまうといったリスクがあります。iOS6系からiOS7へのアップデートでもブラウザのアップデートが行われたのですが、そのときIDは変わってしまいました。

・生存期間が短い
上記懸念事項からもあるとおり、推測されるIDが同じである期間(勝手に生存期間と呼んでます)が、どうしても短くなってしまうといったことが挙げられます。これまで社内で検証してきた感じ、最長でも1ヶ月といった感じでした。

・同じ場所、同じバージョンの端末、同じOSだと一緒のIDになってしまう
当然のことながら、接続元IPアドレスから端末まで一緒だと同じIDが発行されてしまいます。日本でのモバイルの場合、アメリカとは異なりひとつのIPでカバーする範囲が広く、モバイル環境でも同じIDとなりうる可能性があります。

・場所が変わるとIDも変わる
「FingerPrint」発行ロジックのひとつにIPアドレスを含めた場合(IPアドレスの見る範囲にもよりますが)、当然ながらIDは変わります。

・ブラウザが変わると計測できない
これはCookie計測と同様のリスクのため懸念ではないのですが、100%を求めることを考えるとやはり考えざるを得ないリスクになります。

 

「ここまでひっぱって!」とあるかと思いますが、

リワード広告で使用するためには、これまでの計測技術を組み合わせ、部分的にカスタマイズすることにより可能になります。 これまで培ってきたリワード広告計測における経験と、技術の組み合わせにより、ひとつの計測方法を見いだせました。

計測方法を説明していきたいと思います。以下が計測の概念になります。

20131023_030

冒頭で説明した通り、

FingerPrintは「アクセスする端末のブラウザから取得できる情報(ブラウザのバージョンやプラグイン、解像度、IPアドレスなどなど)から端末を推測する技術」です。仕組みでいうと(1)JavaScriptでブラウザ情報を取得しFingerPrintを発行します(図ではFPIDとしてます)。ことあとアプリ起動時にもFingerPrint を発行(*3)し照合します。この照合の中でFingerPrintのウィークポイントをクリアすべく、これまでリワード広告の計測で行われてきた、いくつかのロジックを組み合わせています。

まず、(2)FPIDを発行しクリックURLに設定。FPID発行にはスクリプトを動作させるのですが、3G環境でもページの表示には影響しない程度のレスポンスで行えます。そして、(3)クリック時にFPIDが送られてきます。

(4)~(6)はこれまでと一緒で、(7)でアプリSDKのウェブビューからFPIDを取得します。アプリのウェブビューは通常のブラウザのWebKitを使用しているため、同じFPIDを取得することができます。そして、(8)UUIDの生成日時をチェックします。これは過去にインストールされている場合、UUIDの生成日時が古いため、重複で弾くことを目的としています。

(9)SDKから成果通知を行い、(10)成果判断を行います。これまでCookieでやっていた認証と重複チェックがメインとなり、成果対象であったら(11)ポイント付与するといった流れになります。

 

ざっと概要について説明しましたが、

精度的にはテスト的にプロモーションを何度か行ったのですが、ほぼ100%に近いかたちでの照合が行え、「リワード広告におけるID利用は可能」と判断しています。仮にFingerPrintが取得できなかった場合の補完的な意味合いで、(3)でFPIDがなかったらCookie計測を行うといったロジックを加える事により、確実さを向上させたりと今後いろいろなカスタマイズが必要ですが、今のところ一定の精度を保てています。

リワード広告の場合、瞬間的な配信がほとんどで、ブラウザのバージョンアップや場所が変わることによりIPアドレスが変わってしまうことなど、考慮しなくてもいいレベルだと実績値から鑑みることができます。FingerPrint単体をユニークIDやユーザIDの代替としての利用は難しいとしても、組み合わせることにより実用レベルまでもっていけるといったいい例になるのではと考えています。

*1 シンプルが故に、広告アプリが起動する毎に通知を行う仕様が一般的で鬼のような通知がサーバを痛めつけていましたがいい思い出です。

*2 「主流」と書きましたが、あくまでも日本国内の話で、北米を中心とした海外では端末IDに関する団体の動きがありましたが、端末IDを使わないといった判断はせずに、Appleの端末IDの規制が行われるまでUDID、MACアドレスを当たり前のように使っていました。順番としてUDIDの規制→MACアドレスを使う(またはOpenUDID)→iOS7でMACアドレスが取得できない→IDFAといった流れになっています。

IDFAはiOS6からAppleから提供された広告のトラッキング向けのIDになります。このIDについてリワード広告で使えるかというと、答えはNOです。iOS6.1のアップデートでIDのリセットが行えるようになり、いくらでもユニークIDを発行できてしまいユニーク性を担保できません。何度も書きましたがリワード広告におけるユニークIDは端末特定ではなく、成果認証のために用いられるため、これではユニークIDとして使えないといった判断です。また、アプリからでしか取得できず、ブラウザからは取得できないのも理由のひとつです。今回のFingerPrintも同様のIDとなるため、混乱しそうだったので補足として書いています。このへんは別の機会で書きたいと思います。

*3 スマートフォンにおけるアプリ内ウェブビューにJavaScriptを仕込みIDを発行します。アプリのウェブビューは通常のブラウザのWebKitを使用しているため、同じFingerPrint IDが取得できます。Cookieの場合、アプリ内ウェブビューとブラウザとでは保存領域が異なるためCookie計測ができない理由がここにあります。

 

 著:
Comment(0)