【目次】
１．端末識別番号の必要性とアクセスログへの影響
２．キャリアごとの端末識別番号取得方法とSSL通信時のアクセスログへの影響
２．１ DoCoMo
２．２ ＡＵ
２．３ Softbank(iPhone,Disney Mobile含む）
２．４ イーモバイル
２．５ Willcom
３．端末識別番号の扱いに関して
この記事はke-tai.org ケータイの端末ID・ユーザIDの取得についてまとめてみましたに触発され書いています。今回はちょっとむずかしめの内容ですが、モバイルのアクセス解析ツール実装及び計測・分析を行っている人にとっては理解しておいてほしいものになります。逆にモバイル解析をやっていない場合は全く不要な内容です。モバイル世界の混沌さをご覧あれ。
１．端末識別番号の必要性とアクセスログへの影響
携帯端末識別番号の取得は、アクセス解析に大きな影響を与えます。ご存じのとおりモバイル端末ではAUとSoftbankの一部機種を除いてCookieに非対応、またJavaScriptに関しても一部の古ブラウザ搭載端末が一部対応しているという状況です。なので、ＰＣの計測のようにCookieを使ってユーザー特定を行うことができません。
そこでモバイルだと、携帯端末識別番号を使うことになります。つまり同じ携帯端末識別番号であれば同じユーザーとみなし、それをキーにしてセッション（サイト内遷移）をつなぐということです。逆に言えば、この端末識別番号がアクセスログ側で取得できない場合はセッションがつながらないということです。
端的に言うと「集客と成果が結びつかない」であったり「サイトの導線が見られない」ということで、アクセス解析を行う上では非常に影響が大きい内容となります。なのでセッションをつなぐことは非常に大切であり、それを実現するために端末識別番号を取得する事が大切になります。次に各キャリアでの端末識別番号取得の方法及びアクセスログへの影響を記載いたします。
２．キャリアごとの端末識別番号取得方法とSSL通信時のアクセスログへの影響
２−１DoCoMo
DoCoMoは特殊で、端末識別番号の取得の方法が複数あります。
２−１−１）utn番号（製造番号を取得する）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
utnの詳細に関してはDoCoMoのページをご覧ください。概要としては、HTMLに記述を入れることによりフォームやリンクなどから製造番号を取得する事が出来るという物です。
ただしリンクをクリックしたり、ユーザーが遷移するたびに「携帯電話情報を送信しますか？」といったダイアログが表示されるため、ユーザビリティ的にも使いづらく、またアクセス解析のセッションをつなぐという観点からも使えません。なのでこの手法でセッションをつなげているアクセス解析ツールは皆無です。
２−１−２）iモードIDを利用する
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
2008年4月にDoCoMoが発表した仕様です。
http://example.com/index.html?guid=ON
といった形でＵＲＬにパラメータとしてguid=ONというのをつけておくとリクエストヘッダの「HTTP_X_DCMGUID」の値として端末識別番号が取得できるというものです。この値自体はキャリアのゲートウェイを通過するときにキャリア側で付与されています。また全機種対応に対応をしておりセッションを繋ぐためのキーとしては一番使いやすい方法です。ただし、いくつかの制限やサイト改修が必要となります。
Ａ）パラメータ付与の必要性
仕様：
全てのサイト内リンクにguid=ONをつける必要がある
アクセスログからの観点：
サイトを表示したりする分には必要ないのだが、アクセスログの観点で言うと、guidが取得できないとセッションをつなげないため、途中のページでguidが抜けているとその間はセッションをつなぐことができません。つまり・・・
Ａ→Ｂ→Ｃ→Ｄ
と実際には遷移したにもかかわらず、ＡとＤのＵＲＬでしかguidを取得していない場合、
Ａ→Ｄ
Ｂ→離脱
Ｃ→離脱
という３つのセッション*1（＝サイトの訪問回数が「３回」）が出来てしまい、正しいセッションが取得できず、「特定のページだけやたら離脱率が高い」とか、「１訪問あたりの平均ＰＶ数が少ない」といった現象が起きます。
ちなみにＵＵに関しては、端末識別番号のユニークな数で数えています。では取得していない・できない場合（後述のＳＳＬの例など）はどうなるかというと、これもツールに依存しますが、大抵は「端末識別番号を取得できないものはすべて同じ端末として扱い１ＵＵと数える」という計測方法になっています。
Ｂ）SSL通信時にguidは取得できない
仕様：
SSL通信の場合はEnd-to-End SSL通信によりキャリアのゲートウェイを通過する時もSSL通信なため、端末識別番号を取得する事ができない。
アクセスログからの観点：
成果となるページは大抵SSL内になります。なのでSSL内でもセッションがつながらないと集客効果であったり、SSL部分の導線分析（ドロップアウト率等）だったりを見ることができません。また項目Ａ）にできたような離脱率や訪問あたりの平均閲覧ページ数に影響ができます。
対策方法：
非SSL通信時に端末識別番号を取得。その端末識別番号をGETあるいはPOST*2で引き回す。ただしこの方法はあくまでもサイト内でいったんhttpのページを踏んで端末識別番号を取得していることが全体です。なので、会員登録確認メールのような、いきなりhttpsのページに飛ばしてしまう場合はセッションをつなぐことができません。
端末識別番号そのものをGETに入れてしまっていいのか？ということに関しては後述いたします。
Ｃ）ユーザー側で送信拒否が可能
仕様：
デフォルトでは送信する設定になっているが、利用者側が端末識別番号の送信を拒否する事が可能
アクセスログからの観点：
項目Ａ）にできたような離脱率や訪問あたりの平均閲覧ページ数に影響ができます。
対策方法：
一つの方法はguidを送らないとサイトが使えないようにするという制限をかけることは可能なので、対策方法としては存在しますが、ユーザーの事を考えるとサイトの特性によっては最適な選択肢ではないかもしれません。設定拒否をしている率に関しては諸説あるものの、一般的に多くて数％といわれているので、誤差扱いにしてしまうのも考え方としてはありかもしれません。
２−１−３）uidを利用する
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
公式サイトのみが使える端末識別番号の取得方法です。guidと似ており
http://example.com/index.html?uid=NULLGWDOCOMO
という形で「uid=NULLGWDOCOMO」というパラメータをつけることにより端末識別番号の取得が可能です。このuidの番号はguidとは互換性がありません。キャリアのＧＷで端末識別番号をつけているということに関してはguidと変わらず、またそれによって制限もguidと同じものになります。
２−１−４）サーチエンジンからの流入に関して
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
guid及びuidの方法では、パラメータがついていて端末識別番号が取得できる状態であれば、セッションを繋げられるという内容でした。つまりhttp通信でパラメータがついたURLでゲートウェイをとおってきた場合 あるいは サイト側で端末識別番号をGETあるいはPOSTに入れていた場合に限ります。
この時、課題になるのが外部からの流入です。自分が入稿するようなＵＲＬ（例：アフィリエイト・公式サイトへの入稿・アライアンス・メルマガ等）は最初からリンクのguidあるいはuidを入れておけばよいのですが、サーチエンジンの検索結果にはguid及びuidをつけることができません。
これによって何が起きるかというと（サーチエンジン以外のguidやuidをつけられないURLも含む）
サーチエンジンからＡというページ流入し、Ｂ→Ｃと遷移した場合*3、ＡというURLへのアクセスはどの端末から来たかわからなくなるため以下の二つのセッションが出来てしまいます。
A→離脱
B→C
つまりサーチエンジンから流入した人が何回Ｃまで到達したかがわからない（つまり集客と成果の紐付けができない）ということになります。ちなみにDoCoMoの仕様で、DoCoMoはリファラー（リンク元ＵＲＬや検索ワード）を送ってこないという仕様があります。この事実と合わせると
サーチエンジン経由での流入数がわからない上に、サーチエンジンからのコンバージョンもわからない。
ということになります。入稿できるＵＲＬには広告コードなどをつけて、どこからの流入かというのも計測できますし、guidあるいはuidをつけることによって成果との結びつけもできます。しかし、サーチエンジン・ブログからのリンク・記事での紹介などは区別をすることが出来ません。
これに関して現在打てる対策は非常に限られています。「guidあるいはuidがついていないURLでアクセスがきたら、guidあるいはuidのパラメータをつけたURLでもう一回アクセスしてくる」という仕様を実装する事も可能です。しかし、実装に工数がかかったり、結局もう一回投げ返させているので、より多くの通信が発生したり、ＰＶが２になってしまうというようなリスクを抱えているのも事実です。
２−１−５）（余談）guid以前の話
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
余談ですが、guidが使えるようになるまでは、公式サイトではuidを使ってセッションをつなげていました。では非公式サイトではどうしていたか？というとサイト内で端末からアクセスがあるたびにサイト内で発行したパラメータ(jsessionidなど）を使いそのパラメータの値を元にセッションをつなげていました。
ただし、この手法に関しては、セッション単位で新しい番号を割り当てていく方式になるため、セッションや訪問回数は取得できるのですが、ＵＵは取得できないという難点がありました。今回guidが導入されたことにより、端末識別番号取得のため（またセッションをつなぐため）にguidが一般的に使われていくことになるかと思います。
２−２）AU
ＡＵの場合は方式は一つしかなくシンプルです。
２−２−１）EZ番号（サブスクライバ番号）を利用する
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
リクエストヘッダの「HTTP_X_UP_SUBNO」の値としてサブスクライバ番号が取得できるというものです。この番号はDoCoMoの端末識別番号と違い、同じユーザー（＝同じ電話番号）であれば、端末が変わっても同一の番号になります。また全機種対応していますが、DoCoMoのutn番号同様、ユーザー側で送信を拒否する事ができます。
なおDoCoMoで課題となっていたような「SSLでは取得できない」といった問題はなく、どの環境・公式/非公式関係なく利用する事が可能です。
２−３）Softbank(iPhone,Disney Mobile含む）
Softbankの場合は二種類の方式があり、前者を利用するケースが多いようです。
２−３−１）端末ＩＤを利用する
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
USER-AGENTの中に端末識別番号が入っています。
この番号は端末が変わるごとにIDは変わります。他の端末識別番号同様、ユーザー側で送信を拒否する事ができます。また一部機種（MEXA搭載端末、702MO、702sMO、iPhone）においては端末IDを送ってきませんがDisney Mobile含むほとんどの機種に対応しています。
２−３−２）HTTP_X_JPHONE_UID
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
リクエストヘッダの「X_JPHONE_UID」というパラメータの値から端末IDが取得可能。他の端末識別番号同様、ユーザー側で送信を拒否する事ができます。また対応機種がP型以降（Ｐ型・Ｗ型・3GC型・DisneyMobile）のみで一部の古い機種及びiPhoneには対応していません。
この「X_JPHONE_UID」は実はGWと通過するときに付与されているため、DoCoMoのguidやuid同様SSLページでは取得する事ができません。
※コメントで情報をいただいたので追記
X_JPHONE_UIDはhttpのページからhttpsへ遷移するようなケースであれば、取得可能との事です。URL直打ちでやメールマガジンのリンクなどで最初のアクセスがhttpsになる場合は取得が出来ません。
３．端末識別番号の扱いに関して
端末識別番号の扱いに関してはいろいろ議論があります。その是非に関しては当記事では書きませんが、「端末識別番号はサイト側変わっても番号は一緒」「サイト内で端末識別番号をユーザー特定のキーとして使っていると端末識別番号を書き換えれば他のユーザーとしてログインが出来てしまう」などのリスクはあると思います。
サイト側の設計で対処できる部分は多分にあるので、まずはそれを気をつけるのは大前提とした上で、この番号をどう扱うか？ということを決める必要があります。アクセスログ解析ツールを提供している会社は見ようと思えば簡単に端末識別番号を見ることは可能です。ただ現状はこういった端末ＩＤを使うことによってしかセッションを繋いだりUUを計測する事ができません。ここはＰＣの世界と違い、キャリアの影響が大きい日本特有の問題なのかもしれません。
