読者です 読者をやめる 読者になる 読者になる

端末識別番号とアクセスログの悩ましい関係

【目次】
1.端末識別番号の必要性とアクセスログへの影響
2.キャリアごとの端末識別番号取得方法とSSL通信時のアクセスログへの影響
  2.1 DoCoMo
  2.2 AU
  2.3 Softbank(iPhone,Disney Mobile含む)
  2.4 イーモバイル
  2.5 Willcom
3.端末識別番号の扱いに関して


この記事はke-tai.org ケータイの端末ID・ユーザIDの取得についてまとめてみましたに触発され書いています。今回はちょっとむずかしめの内容ですが、モバイルのアクセス解析ツール実装及び計測・分析を行っている人にとっては理解しておいてほしいものになります。逆にモバイル解析をやっていない場合は全く不要な内容です。モバイル世界の混沌さをご覧あれ。


1.端末識別番号の必要性とアクセスログへの影響

携帯端末識別番号の取得は、アクセス解析に大きな影響を与えます。ご存じのとおりモバイル端末ではAUSoftbankの一部機種を除いてCookieに非対応、またJavaScriptに関しても一部の古ブラウザ搭載端末が一部対応しているという状況です。なので、PCの計測のようにCookieを使ってユーザー特定を行うことができません。


そこでモバイルだと、携帯端末識別番号を使うことになります。つまり同じ携帯端末識別番号であれば同じユーザーとみなし、それをキーにしてセッション(サイト内遷移)をつなぐということです。逆に言えば、この端末識別番号がアクセスログ側で取得できない場合はセッションがつながらないということです。


端的に言うと「集客と成果が結びつかない」であったり「サイトの導線が見られない」ということで、アクセス解析を行う上では非常に影響が大きい内容となります。なのでセッションをつなぐことは非常に大切であり、それを実現するために端末識別番号を取得する事が大切になります。次に各キャリアでの端末識別番号取得の方法及びアクセスログへの影響を記載いたします。



2.キャリアごとの端末識別番号取得方法とSSL通信時のアクセスログへの影響

2−1DoCoMo

DoCoMoは特殊で、端末識別番号の取得の方法が複数あります。


2−1−1)utn番号(製造番号を取得する)
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
utnの詳細に関してはDoCoMoのページをご覧ください。概要としては、HTMLに記述を入れることによりフォームやリンクなどから製造番号を取得する事が出来るという物です。


ただしリンクをクリックしたり、ユーザーが遷移するたびに「携帯電話情報を送信しますか?」といったダイアログが表示されるため、ユーザビリティ的にも使いづらく、またアクセス解析のセッションをつなぐという観点からも使えません。なのでこの手法でセッションをつなげているアクセス解析ツールは皆無です。


2−1−2)iモードIDを利用する
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
2008年4月にDoCoMoが発表した仕様です。

http://example.com/index.html?guid=ON

といった形でURLにパラメータとしてguid=ONというのをつけておくとリクエストヘッダの「HTTP_X_DCMGUID」の値として端末識別番号が取得できるというものです。この値自体はキャリアのゲートウェイを通過するときにキャリア側で付与されています。また全機種対応に対応をしておりセッションを繋ぐためのキーとしては一番使いやすい方法です。ただし、いくつかの制限やサイト改修が必要となります。


A)パラメータ付与の必要性
仕様:
全てのサイト内リンクにguid=ONをつける必要がある


アクセスログからの観点:
サイトを表示したりする分には必要ないのだが、アクセスログの観点で言うと、guidが取得できないとセッションをつなげないため、途中のページでguidが抜けているとその間はセッションをつなぐことができません。つまり・・・


A→B→C→D


と実際には遷移したにもかかわらず、AとDのURLでしかguidを取得していない場合、


A→D
B→離脱
C→離脱


という3つのセッション*1(=サイトの訪問回数が「3回」)が出来てしまい、正しいセッションが取得できず、「特定のページだけやたら離脱率が高い」とか、「1訪問あたりの平均PV数が少ない」といった現象が起きます。


ちなみにUUに関しては、端末識別番号のユニークな数で数えています。では取得していない・できない場合(後述のSSLの例など)はどうなるかというと、これもツールに依存しますが、大抵は「端末識別番号を取得できないものはすべて同じ端末として扱い1UUと数える」という計測方法になっています。



B)SSL通信時にguidは取得できない
仕様:
SSL通信の場合はEnd-to-End SSL通信によりキャリアのゲートウェイを通過する時もSSL通信なため、端末識別番号を取得する事ができない。


アクセスログからの観点:
成果となるページは大抵SSL内になります。なのでSSL内でもセッションがつながらないと集客効果であったり、SSL部分の導線分析(ドロップアウト率等)だったりを見ることができません。また項目A)にできたような離脱率や訪問あたりの平均閲覧ページ数に影響ができます。


対策方法:
SSL通信時に端末識別番号を取得。その端末識別番号をGETあるいはPOST*2で引き回す。ただしこの方法はあくまでもサイト内でいったんhttpのページを踏んで端末識別番号を取得していることが全体です。なので、会員登録確認メールのような、いきなりhttpsのページに飛ばしてしまう場合はセッションをつなぐことができません。


端末識別番号そのものをGETに入れてしまっていいのか?ということに関しては後述いたします。



C)ユーザー側で送信拒否が可能
仕様:
デフォルトでは送信する設定になっているが、利用者側が端末識別番号の送信を拒否する事が可能


アクセスログからの観点:
項目A)にできたような離脱率や訪問あたりの平均閲覧ページ数に影響ができます。


対策方法:
一つの方法はguidを送らないとサイトが使えないようにするという制限をかけることは可能なので、対策方法としては存在しますが、ユーザーの事を考えるとサイトの特性によっては最適な選択肢ではないかもしれません。設定拒否をしている率に関しては諸説あるものの、一般的に多くて数%といわれているので、誤差扱いにしてしまうのも考え方としてはありかもしれません。



2−1−3)uidを利用する
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
公式サイトのみが使える端末識別番号の取得方法です。guidと似ており

http://example.com/index.html?uid=NULLGWDOCOMO

という形で「uid=NULLGWDOCOMO」というパラメータをつけることにより端末識別番号の取得が可能です。このuidの番号はguidとは互換性がありません。キャリアのGWで端末識別番号をつけているということに関してはguidと変わらず、またそれによって制限もguidと同じものになります。



2−1−4)サーチエンジンからの流入に関して
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
guid及びuidの方法では、パラメータがついていて端末識別番号が取得できる状態であれば、セッションを繋げられるという内容でした。つまりhttp通信でパラメータがついたURLでゲートウェイをとおってきた場合 あるいは サイト側で端末識別番号をGETあるいはPOSTに入れていた場合に限ります。


この時、課題になるのが外部からの流入です。自分が入稿するようなURL(例:アフィリエイト・公式サイトへの入稿・アライアンス・メルマガ等)は最初からリンクのguidあるいはuidを入れておけばよいのですが、サーチエンジンの検索結果にはguid及びuidをつけることができません。

これによって何が起きるかというと(サーチエンジン以外のguidやuidをつけられないURLも含む)

サーチエンジンからAというページ流入し、B→Cと遷移した場合*3、AというURLへのアクセスはどの端末から来たかわからなくなるため以下の二つのセッションが出来てしまいます。


A→離脱
B→C


つまりサーチエンジンから流入した人が何回Cまで到達したかがわからない(つまり集客と成果の紐付けができない)ということになります。ちなみにDoCoMoの仕様で、DoCoMoリファラー(リンク元URLや検索ワード)を送ってこないという仕様があります。この事実と合わせると


サーチエンジン経由での流入数がわからない上に、サーチエンジンからのコンバージョンもわからない。


ということになります。入稿できるURLには広告コードなどをつけて、どこからの流入かというのも計測できますし、guidあるいはuidをつけることによって成果との結びつけもできます。しかし、サーチエンジン・ブログからのリンク・記事での紹介などは区別をすることが出来ません。


これに関して現在打てる対策は非常に限られています。「guidあるいはuidがついていないURLでアクセスがきたら、guidあるいはuidのパラメータをつけたURLでもう一回アクセスしてくる」という仕様を実装する事も可能です。しかし、実装に工数がかかったり、結局もう一回投げ返させているので、より多くの通信が発生したり、PVが2になってしまうというようなリスクを抱えているのも事実です。



2−1−5)(余談)guid以前の話
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
余談ですが、guidが使えるようになるまでは、公式サイトではuidを使ってセッションをつなげていました。では非公式サイトではどうしていたか?というとサイト内で端末からアクセスがあるたびにサイト内で発行したパラメータ(jsessionidなど)を使いそのパラメータの値を元にセッションをつなげていました。


ただし、この手法に関しては、セッション単位で新しい番号を割り当てていく方式になるため、セッションや訪問回数は取得できるのですが、UUは取得できないという難点がありました。今回guidが導入されたことにより、端末識別番号取得のため(またセッションをつなぐため)にguidが一般的に使われていくことになるかと思います。



2−2)AU

AUの場合は方式は一つしかなくシンプルです。


2−2−1)EZ番号(サブスクライバ番号)を利用する
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
リクエストヘッダの「HTTP_X_UP_SUBNO」の値としてサブスクライバ番号が取得できるというものです。この番号はDoCoMoの端末識別番号と違い、同じユーザー(=同じ電話番号)であれば、端末が変わっても同一の番号になります。また全機種対応していますが、DoCoMoのutn番号同様、ユーザー側で送信を拒否する事ができます。


なおDoCoMoで課題となっていたような「SSLでは取得できない」といった問題はなく、どの環境・公式/非公式関係なく利用する事が可能です。



2−3)Softbank(iPhone,Disney Mobile含む)

Softbankの場合は二種類の方式があり、前者を利用するケースが多いようです。


2−3−1)端末IDを利用する
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
USER-AGENTの中に端末識別番号が入っています。

この番号は端末が変わるごとにIDは変わります。他の端末識別番号同様、ユーザー側で送信を拒否する事ができます。また一部機種(MEXA搭載端末、702MO、702sMO、iPhone)においては端末IDを送ってきませんがDisney Mobile含むほとんどの機種に対応しています。



2−3−2)HTTP_X_JPHONE_UID
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
リクエストヘッダの「X_JPHONE_UID」というパラメータの値から端末IDが取得可能。他の端末識別番号同様、ユーザー側で送信を拒否する事ができます。また対応機種がP型以降(P型・W型・3GC型・DisneyMobile)のみで一部の古い機種及びiPhoneには対応していません。

この「X_JPHONE_UID」は実はGWと通過するときに付与されているため、DoCoMoのguidやuid同様SSLページでは取得する事ができません。

※コメントで情報をいただいたので追記
X_JPHONE_UIDはhttpのページからhttpsへ遷移するようなケースであれば、取得可能との事です。URL直打ちでやメールマガジンのリンクなどで最初のアクセスがhttpsになる場合は取得が出来ません。


2−4)イーモバイル

イーモバイルは方式が一つしかなくauのそれに似ています。


2−4−1)端末IDを利用する
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
HTTPリクエストヘッダの「x-em-uid」を取得することで、EMnet対応端末から通知されるユニークなユーザIDが取得できます。他の端末識別番号同様、ユーザー側で送信を拒否する事ができます。


2−5)ウィルコム

ウィルコムでは端末IDを取得する仕様が公開されておらず、現在取得する事は不可能かと思われます(端末識別番号自体は存在するようです)。もしかしたら公式サイトを持っている会社には公開されているのかも。(そういう話を聞いたことはないですが)


3.端末識別番号の扱いに関して

端末識別番号の扱いに関してはいろいろ議論があります。その是非に関しては当記事では書きませんが、「端末識別番号はサイト側変わっても番号は一緒」「サイト内で端末識別番号をユーザー特定のキーとして使っていると端末識別番号を書き換えれば他のユーザーとしてログインが出来てしまう」などのリスクはあると思います。


サイト側の設計で対処できる部分は多分にあるので、まずはそれを気をつけるのは大前提とした上で、この番号をどう扱うか?ということを決める必要があります。アクセスログ解析ツールを提供している会社は見ようと思えば簡単に端末識別番号を見ることは可能です。ただ現状はこういった端末IDを使うことによってしかセッションを繋いだりUUを計測する事ができません。ここはPCの世界と違い、キャリアの影響が大きい日本特有の問題なのかもしれません。

*1:ツールにもよりますが、ほぼほとんどのツールで「30分以内の遷移であればセッションをつなぐ」という仕様になっており、今回のAからDという遷移が30分以内であればつながりますが、AからDにいくまで30分以上かかる場合は、A→離脱 D→離脱になってしまいます。

*2:この方式はFORMタグ内でしか利用できません

*3:BとCではguidあるいはuidが取得できる前提