« 2009年7月 | Main | 2009年9月 »

ブログ「Web屋のネタ帳」が月間100億PVを突破しました

サイバーエージェント社のブログサービス「アメーバブログ」が月間100億PV（ページビュー）を達成したそうですが、 この「ネタ帳」も負けてはいません。お互いがんばりましょう。

てな感じで、以下、言ったもの勝ちのチキンレースで周りが踏めないアクセルをいきなり全開にして玉砕に向かうサイバーエージェントを生暖かく見守る識者の図。

ポイントをいくつかまとめる。

  1. アメブロの各ユーザーに提供されるアクセス解析機能で「アクセス数」あるいは「総アクセス数(PV)」という文字で明確に表示される数字には、RSSフィードに対するアクセスが含まれていたり、User-Agentが明らかにWindowsでもMacでもないモノ＝検索エンジンのロボットやRSSリーダー＝によるアクセスが含まれている。普通ならこれはページビュー数として含めない。
  2. しかし実際のところ、何をもって「普通なら」と言うべきなのか？ つまり、PV数には標準的な定義が無い、という恐ろしい現実がある。それはミスリードとチキンレースの温床ともなっている。
  3. しかるに、アメブロに乗り換えただけでアクセスＵＰ！という気の毒な巷のユーザーの声やそれに乗じたようなサイバー社の各種の広報活動で発表するPV数、その他の傍証を見るに、本来なら含めるべきでない数字まで本気でPV数に含めてしまっているようだ。で、「月間100億PV達成だ」と。なんなのよそれ。 見て見て！今日はGooglebotが10回も見に来てくれたんだよ！rss.xmlには50回もだよ！と喜ぶようなWeb屋はサイバーエージェントぐらいである。
  4. 傍証のひとつとして、ちょっと古いが2005年のとある記事を紹介しよう。

    はてな、3月の月間PVが2億8,500万突破 japan.internet.com(2005/4)

    株式会社はてなは2005年4月6日、同社が運営する各サービスの2005年3月の総PVが2億8,500万を突破、総ユーザー数21万8,000人を達成した。

    前回の発表と比べると、PVは4,500万増えて前月比19％増、ユーザー数は1万3,000人増えて前月比6％増となった。

    この他、2005年3月のロボット訪問率は13％、ロボットを除いたPVは2億4,900万だった。
    このように、まっとうな知恵と羞恥心をもつWeb屋はロボットによるアクセスについてはじめから計算外にするかあるいは何らかの但し書きをつけるものだ。
  5. それにしても、2005年段階のhatena.ne.jpでロボット率13%と。この前後数年での、商用／学術研究用それぞれの検索エンジンの乱立とその性能アップ、アドセンスのようなコンテンツマッチ型広告の出力のためのコンテンツ解析クローラー、SEO対策のためのサイト側での何らかの措置、RSS/XMLでのデータフィードの普及とそれを活用した各種Webサービスの開発競争、違法なエロページなどを監視するための各サイト内パトロール要員またはそのツールによるアクセス、その他もろもろ考えると、2009年現在では大手サイトでも非人間／非通常ブラウザによるPVは全体の半分を超えてしまうのではないだろうか。人気の無いサイトであってもロボットはやってくるので、ブログのように更新頻度がそこそこ高くなる種類のサイト（RSSファイル更新されまくり、update ping打ちまくり）ほど、PV数に含まれるロボット率は高まってしまいやすいだろう。例えばアメブロとかアメブロとかアメブロとか。
  6. と思っていたら、こんな記事が発見。

    4～5割のロボットを無視するAnalyticsの解析方式 (現場でプロが培ったGoogle Analyticsの使い方 第2回　1ページ目 ascii.jp 2009/6)

    「ロボット」とは、人間の操作ではなく、自動でWebサーバーにアクセスするプログラムのことです。検索エンジンの「クローラー」とも呼ばれるロボットは、Webページのリンクをたどって、新しいページがないか、更新されたページがないかを探し、Webページの内容を取得していきます。また、RSSリーダーが、定期的にRSSフィードの更新を確認しにくるために実行するプログラムもロボットです。

    ロボットによるアクセスは、日によって変動があり、もっとも多い4月5日の場合、総ページビューの約49％、もっとも少ない4月20日の場合、35％がロボットです。1年を通じてみると、ロボットによるアクセスの方が人間よりも多い日も数日あり、「人間以外によるアクセス」というWebのもう1つの側面が見えてきます。

    4～5割のロボットを無視するAnalyticsの解析方式 (現場でプロが培ったGoogle Analyticsの使い方 第2回　3ページ目 ascii.jp 2009/6)

    Google Analyticsは、「Webは人間が使うもの」という概念にもとづいて開発されたアクセス解析ツールです。ページを見たり、物を買ったり、資料を請求したりといった人間の行動を把握したい場合は、ページビューに限らず、Google Analyticsのようにロボットを計測対象にしないアクセス解析ツールの指標を使うべきです。
    うん、まっとう。そういうことだよな。
  7. 一言で言うと、「広告営業のつもりでページビューが50億だの100億だの言うんならそのロボット率の数字もセットで示してプレゼンしろよトーシロがっ！（※死語）出直して来い！」 と、CAの営業がアメブロとか言い出したらはっきりこう言ってあげましょう。
  8. もうひとつ傍証をあげると、例えばYahooがIR情報として出している2009年6月の1ヶ月のPV数は464億ページビュー。これってYahooトップと検索結果ページはもちろんYahooニュースとかヤフオクとかYahooブログとかその他もろもろYahooホニャララの一切がっさいを含めてのこの数字。つまり、Yahoo全体をもってしてもアメブロ4個半しかないと。 んなわきゃない、どちらかの数字が何らかの形でおかしいと考えるのがまっとうな業界人だろう。
  9. 逆に、挙げるべきでない（ような気がする）傍証が、Google Ad Plannerによる数値。 例えばこれ。2009年7月のameblo.jpは月間13億PVくらいしかないことになっている。この数字の誤差がどれほどなのか、正直わからない。前にも書いたとおりGoogle Ad Plannerが出す数値が微妙であるケースはけっこうある。 とはいってもこの規模のサイトの自己申告100億PVでGoogle神による他己申告13億PVじゃ、やっぱり誤差にしちゃ大きすぎるよという気持ちはわかる。
  10. なお、「広告なんだからインプレッション数で図るべきであってPV数とからめるべきではない」といったような意見もあるようだが、まるで話が違う。Web広告営業の現場では「ページビュー数、つまりアクセス数はですね．．．」というプレゼンと「インプレッション数がですね．．．」というプレゼンとでは、前者のほうが、スポンサー側担当者の老若男女を問わず「ピンとくる」可能性がかなり高いという現実がある。したがって営業マンもIR担当もPV数を前面に押し出すしかない。サイバーもYahooもその他もろもろも実際そうしているわけだし。プレスリリースにまんまとのって提灯記事にした日経産業新聞とかあるわけだし。つまり、この問題の本質は、実際に現場でステークホルダーの行動に影響を与えてしまっている数字の出し方が怪しいというところにある。PV数とインプレッション数は異なるので云々という広告理論の話は別のところでやるべき。

さて、そう遠くない将来、サイバーエージェントによる恥ずかしげもない幼稚な行動に始まったデジタル押し紙によるバブルがはじけるとき、ネガティブインパクトを食らうのはCA一社ではなくWeb業界全体に広がってしまいかねない。

そこで、Yahooほどの圧倒的なモノがないサイトは、いまのうちになんらかの形で保険をかけておくべきじゃなかろうか。 さっき、Google Ad Plannerの信頼性がいまいちという話をしたが、信頼性を上げる方法があるのだ。

Google Analytics データ公開可能に::SEM R (2009/5)

なお、Googleは5月5日にGoogle Ad Plannerの公開データをGoogle Analyticsの実測データに置き換え可能にしたことを発表している。Google Ad Plannerはメディアプランニングツールで、指定したサイトのページビュー（PV）やユニークユーザ（UU）、年代、性別、学歴、年収などのデモグラフィック情報を参照できる。これらはGoogleによる独自予測データだが、Analyticsのデータに置き換えることでステークホルダーに対し適切な情報を提供できるようになる。

とあるサイトで実際やってみた結果が下記。 このネタ帳のサイトの数値ではない。neta.ywcafe.netみたいにサブドメインを切っているのでうまく設定できなかったので、以下の画像は筆者の知り合いのサイトのものである。したがってAdPlannerで公開とはいえ数値について筆者の口からはなにも言えないのでツッコまないように。

設定前↓


設定後↓

こんな感じで、少なくともPV数（とUU数？）については自サイトのAnalyticsで計測されたデータを公開させるようにできる。

AdPlannerは正直まだ改善の余地があると思う。情報の信頼性はもちろん使い勝手の面でも。 だが、Analyticsからのデータの反映に時間がかかることもあるかもしれないし、 今後の機能強化／改善も見越して、早めに行動に移しておいて損はないんじゃなかろうか。

たとえば、ややマイナーサイトだが、琉球新報はAnalyticsのデータを自分のサイトで公開している。が、更新されてなくて古い。 そこで、Adplanner上で「正直、こんだけのPV数なんですよ、ほら、Analyticsのデータで出てるでしょ」といつでも言えるようにしておけば、信頼性がより高い情報（しかも常に最新）を交渉の出発点にできるという点で、大局的に見ていい仕事につながる気がする。ウチのサイトでそんなこと出来ないよというあなた！？残念、もうすでに水増しチキンレースにご参加でしたかそうでしたか。

see also:

2009年8月10日 | Permalink | Comments [1] | Trackbacks [2]

こんなにカンタン！GoogleアドプランナーとAnalyticsのデータ連携による正確なPV数の公開

タイトルは釣りなんだ。すまない。設定方法などの具体的ハウツーをここで書く気はない（準備が面倒だ）。 しかし言いたいのは、

  1. 昨日(8/10)、筆者が公開した記事で、「琉球新報という地方新聞社のサイトがGoogleAnalyticsによるPV数などを自社公開してるよ、更新されてなくてデータが少し古いのがナンだけどね。だから、AnalyticsのデータをAdPlannnerと連携させて公開しちゃうってのはどうだろう？」ということをほんの一例としてチラっと書いただけなのに、
  2. その翌日(8/11)にはこんなコメントがあって、
    こんばんは。
    琉球新報のなかのひとです。言及ありがとうございました。

    AdPlannerを通じてAnalyticsのデータを公開する方法というのがあったのですね。知りませんでした。
    もともと両方の数字に大きな違いはなかったんですけど、Analyticsに置き換える設定をしてみましたよ。

    いい仕事につながりますように…
  3. おお、まじかよ。と思ってGoogle Ad Plannerを見てみたら本当に設定されてた。

一連の経緯の経過時間＝24時間前後。 ね、カンタンでしょ？要は「やるかやらないか」の問題でしかないのだ。

もしも「俺のサイトじゃGoogleWebマスターツールもGoogleAnalyticsもまだ使ってないんだ」としても、そのセッティングにかかる費用と時間がナンボのものだろう？ Analyticsを無償で使えるのは月間500万PVまでだって？ならAdwordsに一日100円上限の予算で広告出しとけばいいじゃん。その費用は、自前でSiteCatalistだのVisionalistだのRTMetricsだのを有償で買って運用する金額と比べてもやはりナンボのものかと。そもそも500万PVに及ばないサイトならそんなこと気にする必要もないし。ただしAdwords支払いのための会社名義のクレジットカードの発行と使用許可を得るのが大変だという組織人の方はご愁傷様です（笑）

それから「いまさら解析ツールを乗り換えろというのか！」と勘違いする方もいると思うが、そんな必要はないしそもそも今使ってる解析ツールを変えろとは誰も一言も言っていない。WebAlizerでログ解析してようとvisionalistでパケット解析してようとSiteCatalistでJavaScript埋め込んでようと、GoogleAnalyticsのJavascriptコードとは干渉しやしないのだから。

もちろんGoogle Analyticsにも問題はある。自分サイトのアクセス状況をGoogleにすべて握られることになるからだ。それを怖いと思うか思わないかは人それぞれ。ただしすでにAdsense広告をはってたりするんならその主張は自己否定だと思う（笑）。ただ、Googleは例えばBlogspot（Google傘下のブログサービス）のアクセス状況をアドプランナー上では一切公開する気が無いらしい。これはある意味不公平で、ずるい。

もっと問題なのは、GoogleAnalyticsは Javascriptに頼っているので、モバイル（日本の携帯電話）によるアクセスはカウントできないということ。モバイルによるアクセスが多いサイトではこれは困る。 Yahooアクセス解析なら、Javascriptが動かない端末の場合は画像ビーコンを使うようになっているっぽいのでモバイルサイトでも使える．．．のかなと思ったら無理だと。うーむ。

2009年8月11日 | Permalink | Comments [0] | Trackbacks [0]

au one net（旧名称DION）で、ようやく、連続ドットのメールアドレスが取得不可になったの巻

すでに手垢つきまくりのネタではありますが、大手プロバイダ／キャリアによるRFC違反のメールアドレスの配布の件です。au one net（旧名称DION）が、ようやく陥落。

キャプチャ取得元↓
メール基本仕様 (dion (h以降) ドメインの仕様): メールを使おう | au one net

2009年4月初旬の画像↓

2009年8月14日現在の画像↓

正確にいつからこうなったのかつかめなかったのが残念。 さておき、これまでの間にドット連続しまくりのメルアドを取得してしまったユーザー様にはなんて説明しているのやら。

なお、同じくKDDI株式会社のau（携帯）については相変わらずの ウソ解説掲載中。↓
Eメールアドレス変更方法 | 迷惑Eメール防止方法 | au by KDDI

see also:

2009年8月15日 | Permalink | Comments [0] | Trackbacks [1]

HACHI－約束の犬－を見てきた。字幕上映してる映画館が少ないのでご注意。

夏休みなんでちょっと脱線。

映画でも見ようかということになったんだが、時期が時期だけにご家族向けばっかり。ヤンクミは特に興味無いしアニメ見ないしハリポタはもう見たしGIジョー？うーん。仮面ライダー？全部乗せはラーメンのトッピングだけにしとけと。アマルフィ？えー。はずしそう。

というわけで、余計なこと考えずに安心して見れそうなHACHIに決定．．．したんだが、どこも吹き替え版ばかりで字幕上映している映画館がびっくりするほど少ないのでご注意ください。ちなみに吹き替え版のリチャードギアの声はソフトバンク犬の北大路欣也らしい（笑）。しかしやはりあれは、リチャードギアが「ハチー！」とややぎこちなく日本名を発音するあたりに味があるのだ。字幕版をおすすめする。 結局、ネットで探してお台場のメディアージュで見た。ついでに潮風公園でガンダムも。すごい人出。あれはお祭りの縁日でも最近みない。フジテレビの作戦にはまりすぎですねすいません。

内容的には80年代（だっけ？）の映画「ハチ公物語」のリメイクであり、つまり皆が知る忠犬ハチ公のストーリーそのまんまである。ハリウッド版リメイクにありがちなおかしなデフォルメもなく、アメリカ東海岸に日本犬の迷い犬？で名前がハチ？という無理が出そうな設定も意外とすんなりまとめている。ヨボヨボに年をとって薄汚れたハチを見たリチャードギアの奥さんが「ハチ、まだ待っていたの．．．」と抱きしめるあたりで観客一人残らず号泣。

くそ暑い夏の夕暮れに頭を使わず安心して泣ける一本です。

2009年8月16日 | Permalink | Comments [0] | Trackbacks [0]

PCでmixiを見ているユーザーの使用ブラウザ比率。IEが7割、Firefoxが1割

おおよその数値とはいえ、大手サイトでこういう数値が公開されるのは珍しいので参考になる。

mixi Developer Center (ミクシィ デベロッパーセンター) » mixiユーザーのブラウザ利用比率のご案内

■MSIE：約70%
■Firefox：約10%
■Safari：約10%
■その他：約10%

（2009年8月現在）

Firefroxが10%まで行っているのか。へー。 なお、mixiでは携帯で見るユーザーのほうがＰＣよりもずっと多いのでそこんとこ頭の隅にでも。

see also:

2009年8月25日 | Permalink | Comments [0] | Trackbacks [0]

緊急地震速報の誤報の原因がありがち過ぎて苦笑いな件

笑ってちゃいけないんだけどさ。でもシステム屋としては、どっかで聞いたことのあるような障害パターンすぎて。っていうか、似たようなことで身に覚えがあります。すいません。

asahi.com（朝日新聞社）：地震誤速報、ソフト改修原因　気象庁「業者が無断で」 - 社会(2009/8)

誤った変更が加えられていたのは、今回の誤報の元となった千葉県南房総市に設置された地震計のほか、千葉市の千葉測候所、兵庫県加西市観測点、大阪管区気象台の地震計。地震の情報を東京と大阪の処理システムに同時に送れるようにするため、気象庁が全国２３７台の地震計のソフトウエアの改修を明星電気に依頼。同社は２４日、手始めに４台に実施したが、依頼分の改修と同時に、地震の振幅のデータを処理するソフトウエアについても無断で変更を加えたという。

　改変点は、これまで小数点以下を切り捨てて処理していた振幅の数値を、四捨五入してより正確な数値に近づけるというものだった。しかし、振幅を表す単位を「マイクロメートル」とすべきところを誤って「ミリメートル」としてしまったため、振幅が実際よりも常に５００マイクロメートル大きくなるようになったという。

　今回の誤報では約２０倍の大きさになって伝えられ、振幅を元に計算される地震の規模を示すマグニチュード（Ｍ）は、実際にはＭ４．１だったのがＭ６．６とされた。

問題を大きくした原因が複数あるのがポイント。

1. システム屋さんは、直した箇所についての単体テストをしないで納品した（ここ最重要ポイント）
地震の振幅を数値化する部分を直したのなら、試験用の地震計にその直したソフトを入れて、防災訓練でおなじみの起揺装置みないなやつに置いて、想定どおりに数値化されるかどうかをテストすべき。あきらかにそれを怠っている。

2. クライアントに「ついでにここも直しましたよ」と報告していない
≒受け入れ側でチェックすべきポイントに含まれなくなってしまう。＆トラブったときの原因究明に時間がかかってしまう。

3. 「よかれと思ってやったこと」だけど、それはそもそもクライアントは頼んでもいないことである。
たとえばの話「Ａという障害を改修しようとしてソースコードとにらめっこしてたら、Ｂという潜在バグを見つけました。なので、ＡとＢをまとめて直しておきました。」ということはままある。見つけたバグを直さずにいられないのは、火を見かけた消防士がその場で消火活動を始めずにいられない（離れたところで大きな出火があっても）のと似たようなことで、つまり、コードを書く人間の本能である。

ところがだ。むかーーーーしの筆者の経験でこんなことがあった。 修正案件Ａといっしょに、たまたま見つけたバグＢをまとめて直して、「Ｂも発見したのでも直しといたよ」と、Aの報告書に付け加えておいたのだが、連絡の過程でＢの話が抜け落ちた。リリースしてみたら他のサブシステムＣが落ちた。何事かと思ったら、バグBはそれはバグではなく仕様だと勘違いしたほかの人間がサブシステムＣをバグＢに合わせた形で作っていたのだ。「直すんなら直す前に一言いれろよ」と先輩にめっちゃ怒られたことがある。あの頃は若かった。。。

「丸投げした気象庁も悪い」的な意見もあるようだが、今回はそれはどうだろうね。 納品（修理）されたシステム（地震計）を受け取って点検すべきなのは気象庁だとはいえ、 「どこを直したのかを正確に教えてくれないと点検すべき範囲がわからんでしょうが。まさか１から10まで全部チェックしてたらキリないし」とも言える。 自転車のタイヤのパンクを修理してくれと頼み、修理が終わったあと持ち主が見るのはタイヤであってライトの具合まで見ないのはある意味当然。

緊急地震速報なんていう重要なシステムなんだから、気象庁でも地震計屋でもどっちでもいいからいちいち全部チェックしろ！とかいうのはそれは過剰品質というやつで、即コストに跳ね返る。数十年に1度の大地震に対応するためのシステムにどこまでコストをかけるかという問題は深遠だ。そもそも地震計って儲からないらしいしね。→ asahi.com（朝日新聞社）：放置の震度計４００カ所に　メーカー撤退、計測に支障も - 社会

緊急地震速報は、ほぼすべての処理過程で人の手を介さない、フルオートマチックのシステムである。地震計が地震の初期微動ってやつ観測するところから始まって、東京と大阪の各処理システムにその旨通信し、システムが場所や時間や予想規模を割り出して、iモードやらラジオやらテレビ局やらの各端末に速報を流すところまで、全部自動。でないと本ゆれが来るまでに間に合わない。（そもそも震源が近すぎると何やっても間に合わないけど。阪神大震災みたいな直下型とか絶対無理。）

そんなすごいシステムなんだが、しかし、「誤報」を一発やらかすと、本番のときに「また誤報か」と思ってしまう。ビル内で火災ベルが鳴り響いてもみんなすぐには動かないのと同じだが、地震速報でそれは非常に困る。初期微動から本振れまでのわずか10数秒の間に「火を消してテーブルの下へＧＯ！」を促すためのシステムなので、「あれ？また誤報かな？」という意識を挟むような時間的余裕がほとんど無い。無いはずなのに、しかし今回の一件で人々の意識にそれが生まれてしまったのだ。

このテの警報システムは本当に悩ましいねえ。

2009年8月26日 | Permalink | Comments [0] | Trackbacks [0]

だからパスワードを平文で保存するなとあれほど

このネタもまたこのブログではだいぶ手垢がついてますが、メモ代わりに。 クレジットカード番号の流出も嫌だけど、パスワードの流出はもっとタチが悪いと思う。

去年のヤフオクのID大量乗っ取り事件のころ、筆者は、 拝啓 消費者支援機構関西 様という記事を書いた。ちょうど去年の今頃（2008年9月）だ。そこでは「昨今の企業不祥事の様子から推察すると、（パスワードの流出が）発覚しても公表していない企業すらあるでしょう。また、不正アクセスに気づいてすらいない企業もあるでしょう。」と書いたが、まさにその同時期に、不正アクセスに気づいてすらいないor公表していない企業が、あったわけだ。まさに氷山の一角。

  • 通販サイト「イーサプライ」不正アクセスでカード情報5620件流出 (INTERNET Watch 2009/8)
  • esupply: お客様情報の流出のご報告とお詫び(2009/8)
    （１）経緯

    2008年8月 クレジットカード会社より、カード情報流出の可能性があるため、 当社へ調査の依頼があった。
    2008年8月 当社にて調査を実施。当社のみの調査では漏洩の事実は確認できなかったが、念の為、システムのクレジットカード情報をすべて削除し、クレジット決済を一時休止。また、サイトログイン時のパスワードのハッシュ化（暗号化）の対応を行った。
    （筆者注↑ということは、これ以前はパスワードを平文で保存していたということ）

    （途中省略）

    （３）漏洩した可能性のあるデータについて
    2002年1月～2008年8月の間にお買い物をされたお客様の個人情報
    閲覧痕跡項目：メンバーID、サイトログインのパスワード、受注番号、名前、メールアドレス、生年月日、年齢、電話番号、クレジットカード番号、クレジットカード有効期限

see also:

追記：

ここも同様。 （お詫びpdfのコピーここ）

2009年8月28日 | Permalink | Comments [0] | Trackbacks [0]