スマフォのリワード広告におけるUDIDに依存しない設計案

前回のまとめ

前エントリで触れたとおり、スマートフォンのUDIDの問題点というのは、自分の把握する限り３つあった。

1. サーバとのセッションを管理するための認証に使われてしまっている
2. アプリケーションをまたがっての行動トラッキングに使われてしまっている
3. スマフォにおけるリワード広告がUDIDが取れることに依存した実装になっている。

このうち、1. に関しては代替案があり、ほぼ既存のユーザビリティを損なわない形に実装できるものなので、単に実装側の怠慢か知識不足に帰結されると感じている。今の時点でこれほど安易に使われてしまっているのは残念なことではあるかもしれないが、今後改善できる余地がある。

2. に関しては、実はデバイス固有IDであることについてはそれほどこの時点では問題ではなく、単にトラッキングされることに対してユーザの同意も拒否も介在する余地が無い、というところを問題にしている。たとえば、もしAdNetwork固有のIDを生成して割り振れたとしても（実際にはそれは無理なのだが）ユーザがそのトラッキングについて受入の許認可ができない時点でアウトと宣告される。つまりは、3rd Party Cookie的なオプトイン・アウトの仕組みが提供され無い限り、そもそも無理筋のビジネスモデルではないか、というのが自分の感想だ。

で、問題は 3. だ。

スマフォのリワード広告はevilなのか？

リワード広告について、ビジネスモデルの健全性を疑う声もあるようだが、僕はそこは今回とは分けて考えるべきである、という意見である。少なくとも個人的には、アコギなことをしている、という印象までは抱かない。もっと言うと、そのシステムがはたして世界にどういう結末をもたらすのか、という点で、第三者的な興味がある。もし、広告ビジネス自体を卑下して、そんなものはだめだ、という立場を取る人がいたとしたら、あさはかだな、とは思う。

ビジネス自体をやめろ、というのは簡単だ。もし無断かつ回避できない行動追跡のようにevilであるというコンセンサスが確立している場合には、正直そういうしかない。でも、リワード広告については、そこまでevilとは思わなかった。これは、先日の調査の結果、いままでの自身の価値観に照らし合わせて判断したもののため、いやそうじゃないよ、という意見もあるかもしれない。もしそうなら是非その点についてコメントなりで教えていただきたい。

ただし、ビジネス自体はありとしても、あたりまえながら実装においてはルールが存在し、 UDIDの収集によってそれを実現するのは、ルール違反といえる。また、起こりうるプライバシー問題についての想像力がない、という意味で、センスがない。

しかしながら、世の中はルール以外のところで動いているようだ。このままだとUDIDがとれなくなるんだったらMACアドレス（のハッシュ値）でやっちゃえばいいじゃん、という流れになるかもしれない。これは避けるべきところだ。

スマフォにおけるリワード広告のフロー（推定）

今回、正直に告白すると、自分はiOSネイティブのまともなアプリを作ったことは全くない。なので、実際とかけ離れた推測になっていた場合はご容赦いただきたい。

スマフォアプリのリワード広告で、肝となるのは、ユーザが該当アプリをダウンロードしたかどうかをどうやって把握するのか、ということだ。これさえできるのであれば、別にUDIDというのは必ずしも必要ではない。

今、リワード広告を掲載するアプリをA（ソーシャルゲームのようなものを想定すると良い）、広告主のアプリをBとしてみる。おそらく現在は以下のフローになっている。これはもちろん推測。

1) ユーザは、アプリAのゲームを楽しんでいる。
2) ユーザは、アプリA内のゲーム内での仮想通貨ポイントが欲しくなった。
3) ユーザは、アプリA内に表示されている広告をクリックする。
4) アプリAは、ユーザのスマフォのUDIDを取得し、サーバ上でユーザ情報に紐付けた後、App Storeを起動してアプリBのページへ遷移させる。
5) ユーザは、アプリBをスマフォにダウンロードする。
6) アプリBは、初回起動時にスマフォのUDIDを取得し、ゲームAのサーバに送信する
7) アプリAは、サーバ側でUDIDを照らし合わせて、そのユーザに対してポイントを付与する
8) ユーザは、アプリAにおいて、仮想通貨ポイントをゲットできた！

ここで、アプリAとアプリBで、ユーザのセッションを突き合わせるという目的のためにUDIDが使われているのがわかる。つまり、アプリ間でセッションの連携さえ出来るのならばこれは解決される。

スマフォアプリ間でセッションを共有する方法

今回、iPhoneアプリ間で連携する方法には、一般的に以下の方法がある、ということを教えいていただいた。

iOSの中で、アプリケーション同士が連携するためのしくみ - More the iPhone Development Playground

URLによるアプリの起動
Pasteboardによるデータ共有
UIDocumentInteractionControllerによるファイルの受渡し

このうち、URLによるアプリ起動によって解決できる可能性があるのではないかと考え、以下のようなフローを考えてみた。（４以降が変更点）

1) ユーザは、アプリAのゲームを楽しんでいる。
2) ユーザは、アプリA内のゲーム内での仮想通貨ポイントが欲しくなった。
3) ユーザは、アプリA内に表示されている広告をクリックする。
4) アプリAは、アプリA内で一時的にUUIDを生成し、ユーザ情報に紐付けた上で、ユーザをApp StoreのアプリBのページへ遷移させる。
5) ユーザは、アプリBをスマフォにダウンロードする。
6) アプリAは、4)で生成したUUIDをURLにパラメータとしてつけて、アプリBを起動する。
7) アプリBは、パラメータでもらったUUIDをアプリAのサーバへ送信する
8) アプリAは、サーバ側でUUIDを照らし合わせて、そのユーザに対してポイントを付与する
9) ユーザは、アプリAにおいて、仮想通貨ポイントをゲットできた！

こちらのフローだと、一旦6)でアプリAからアプリBを明示的に起動する、というフローが発生してしまうが、目的は達成されている。受け渡しされるのはアプリケーションの橋渡しをするための一時的なIDであるため、漏えいしても悪用されることはない。

UDIDを用いたフローが、即座にポイントが獲得できるのに対し、この提案はアプリケーションの確認となる 6)のユーザインタラクションが入ってしまうため「ユーザビリティが損なわれる！」と憤慨するかもしれない。実際、ターゲットユーザ層を考えると、そのあたりのわかりにくさによる離脱は十分考えられるため、そんな要素は極力無くしたいというのが、ビジネスを企画する側の本音だろう。

ただ、申し訳ないのだが、今回の件でUDIDなど端末固有IDを利用することによるビジネス上のリスクというのは十分にわかったはずだ。デバイスIDを広く収集させてしまうことについての忌避感は、まともなベンダーならかならず感じていることだ。iOSでAppleがやったことは、世間的に見てむしろ常識的な対応なのだ。さてじゃあAndroidではそんなことはないと誰がいっているか？そのようなリスクをとってまで最初のフローに固執するのはなぜだ？もしスマフォアプリのリワード広告というビジネスを継続させたいなら、今のところこれしかありえない、というのが自分の結論になる。

もちろん、まだ他の実装方法もあるかもしれない。その中には、ユーザインタラクションを損なわない妙案もあるかもしれない。残念ながら自分には見つけられなかったが、まあそこまで頑張る義理というのもない。

＃ちなみにもしかしたらAndroidだったらIntentによってユーザのインタラクションを介さずにバックグラウンドでパラメータ渡しができるのかもしれない。そうすれば既存のユーザビリティを著しく損なうということはない。