ひょっとして、Ajax をうまく使って Google Bigtable みたいなフレキシブルDBシステムを作れるんじゃね？
今日、会社でWebサイトのユーザー特性についての情報共有やってて、もっと正確なトラッキングができる方法ないかな？ と思った。
ちょうど、Google の Webサービス（Google App Engine）が一般公開されることになったのも一つのきっかけだったけど、Bigtable は使えるんじゃないか、と。
そうはいっても、いきなり Google App Engine に参入するのは、会社として決断できるはずもない。だから、現在運用しているサーバに Bigtable のようなフレキシブルなDBシステムを構築できないかと考えた。また、専任でプログラマーを常駐させていないこともあり、サーバーサイドのプログラミング作業は最小限に抑えたいというのもあった（コストの節約）。
正直、私が書いちゃってもいいんだけど、サーバー側のプログラムいじる権限がないのでね。
で、Ajax を使う方法を思いついた。
1.（まず前提として）Bigtableとは？
Bigtable とは、Google が従来のRDBでは扱いきれないほど大きなデータを読み書きできるデータベースシステムで、行だけでなくコラム（列）も自由に拡張できるフレキシブルなもの。主に「行」「コラム」「タイムスタンプ」で構成される。すなわち、行キー＋コラムキー＋タイムスタンプで一つのキーが割り当てられ、値が格納される。この場合の値は、BLOB型と言われる構造データでバイナリデータを格納できるのが特長である。またRDBと比べてHDDへのアクセスが少ないため、データを高速処理するのも大きな長所となっているようだ。
逆に、欠点としては、RDBと比べてデータの格納効率が悪くなることだろうか。また、SQLコマンドを使うことに慣れ親しんだプログラマーにとってはなじまない方法になるかもしれない。Google App Engine （β版）をリリースするに当たって、Google はGQL（ベタやな〜）と言われる専用言語を用意しているので多少はましなのかな？
2. Bigtable の構造を、Webサーバのファイルシステムに置き換える
Bigtable のデータは、Google のサーバ内の独自ファイルシステム（GFS）に格納してある。GFSについて説明するとかなり複雑なので、ここでは割愛するが、とりあえず、このシステムを通常のWebサーバで再現することは不可能に近いと思う。そこで、Webサーバのファイルシステムに擬似的に Bigtable を格納する方法を考えてみる。と言っても、すごく単純な方法。
Bigtable のキーは「行キー＋コラムキー＋タイムスタンプ」なので、これを単純にファイル名にしてしまうのもいいけど、せっかくなので、ディレクトリ構造に割り当ててみたい。すなわち、格納ディレクトリの下に「行キー」ディレクトリを作成し、さらにその下に「コラムキー」ディレクトリを置き、「タイムスタンプ」ファイルを作る。拡張子は何でもいいんだけど、わかりやすいように“.dat”にしとこう。
こんな感じになる。→［行キー］/［コラムキー］/［タイムスタンプ］.dat
本物の Bigtable はバイナリデータを格納できるが、ここでは最終的に JavaScript で扱うことが前提なので、JSONやXML、（X）HTML、カンマ区切りテキスト、プレーンテキストなどが望ましい（JSON or プレーンテキストが一番楽と思う）。
3. サーバーサイドプログラムをつくる
サーバーサイドプログラムは、後で修正などしなくてもいいように、汎用性の高いものを作っておく。本物の Bigtable のコマンドが、Set（追加）、Delete（削除）、Lookup（検索） なので、ここでもこの3つそろえておけば十分足りると思う。本物の Bigtable の場合は、トランザクション処理と書き込みエラーの対策として、別途 Apply コマンドが送られたときに初めて処理が実行される。仮にトラッキングで使うとしたら、トランザクションは要らなそうだし、タイムスタンプ残しながら追記していくことになるので、書き込みエラーも考えにくい（エラーになっちゃったら書き込もうが書き込むまいが同じこと）。
と考えると、Apply コマンドは無くても良さそうだけど、どこで使うことになるかわからないし、Google が経験上必要と言っているので、つけといた方がいいかもしれない。
各コマンドの内容は
Set →
【入力】［行キー］（そのレコード固有のID）＋［コラムキー］（コラム名＝レコードの項目名）＋［タイムスタンプ］（ファイルを書き込んだ時間）＋値（［タイムスタンプ］に書き込む内容）
【出力】書き込みの成否
レコードを更新する場合は、
- “［行キー］/［コラムキー］”ディレクトリが存在するかどうか確認。無い場合は作成
- 値を取得。
- すでに“［タイムスタンプ］.dat”のファイルがある場合は“［タイムスタンプ］.bak”などにリネーム
- “［タイムスタンプ］.dat”を作成し、値をプリント＆保存
- 4.まで成功した場合は、“真”を出力し、“［タイムスタンプ］.bak”を削除。失敗した場合は“偽”を出力し、“［タイムスタンプ］.bak”を“［タイムスタンプ］.dat”に戻す。
Delete →
【入力】［行キー］、［コラムキー］、［タイムスタンプ］の任意な組み合わせ
レコード全体を消したい場合は、［行キー］のみ。全てのタイムスタンプにおけるコラムを消したい場合は、［行キー］＋［コラムキー］、一つのタイムスタンプだけレコードを消したい場合は、［行キー］＋［タイムスタンプ］という具合に組み合わせれば、（疑似）データベース内のデータを自由に削除することができます。
【出力】書き込みの成否
Lookup →
【入力】［行キー］、［コラムキー］、［タイムスタンプ］の任意な組み合わせ
【出力】検索結果を配列で出力（と思ったけど JavaScript で使うから、eval関数で配列に変換可能なテキスト）
Apply → 上の3つのコマンドを実行
4. Ajaxを組み込む
というか xmlHttpRequest で非同期通信する。
send関数で［行キー］、［コラムキー］、［値］、それから、実行コマンドを指定してサーバーに送る。
新規追加の場合、重複を避けるため［行キー］はサーバーサイドで発行する。その際、例えばトラッキングのようにユーザーが認知しない形でのデータを取得したい場合は、認証のために［行キー］を Cookie に残しておく。
（詳細は割愛）
Ajaxでのデータ通信は、セキュリティ的にやばくなる場合がままあるので、細心の注意を払う。
5. セキュリティ
6. トラッキングに特化した場合
使用目的をトラッキングに特化した場合（個人情報を扱わない場合に限る）は、セキュリティなどをあまり考えなくてすむかもしれない。例えば、“［タイムスタンプ］.dat”をWebサーバのルートディレクトリ以下に格納すれば、（サーバーサイドプログラムを介さず）xmlHttpRequest で直接読み込むことも可能になる。データファイルは外部から丸見えだけどね。この場合、JavaScriptにはファイルシステム関数がないので、マスター情報を記録するデータファイルを別途用意する必要があるかもしれない。
なんだかややこしそうですが、3のサーバーサイドプログラムさえ作り込んでおけば、あとはクライアント側の JavaScript をコーディングするだけで自在にデータベースを作り替えてしまうことができます。サーバーサイドの運営を外部業者に委託するなどの理由で、コストパフォーマンスが悪かったり、スピーディな運用が難しかったりする場合は、かなり効果的ではないかと思います。
サーバー負荷がいまいち読めませんが、トラッキングやその結果を反映したパーソナライズドページの生成やセグメント広告の展開とかだったら、検索する行キー・コラムキーが明確なので、CPU負荷もメモリ負荷も最小限で収まるはず。フリーワード検索とか行うには、もう一工夫必要になりますが。
ちょっと荒いですかね？
AISASに代わる消費者行動理論はICSAS
AIDMAとAISAS
消費者行動理論を語る上で耳にタコができるくらい聞かされてきた“AIDMA”。今更かもしれないが、これは以下に示される“リアル世界で”の典型的な消費者行動である。
- A
- Attention（注意・注目）
- I
- Interest（興味・関心）
- D
- Desire（欲求・購買欲）
- M
- Memory（記憶・保留）
- A
- Action（行動・購入）
AIDMAの典型的な例として、私はうなぎ屋を思い出す。
夕飯の食材を買いにスーパーに向かう主婦が、うなぎ屋から漂ってくる美味しそうな臭い（Attention）に誘われ足を止める（Interest）。美味しそうなので、今晩はうなぎにしようかと考える（Desire）。しかし、うなぎは高いし、スーパーでもっと良い食材が手に入るかもしれないので、その場では買わない（Memory）。スーパーで買い物をしたが、やはりメインはうなぎだと思い、うなぎ屋に戻って購入する（Action）。
別にうなぎ屋でなくてもいいのだが、だいたいこんな感じだと思う。
リアル社会の消費者行動は、確かに、AIDMA（もしくはMを除いたAIDA）で説明できることが多い。そして、多くの広告戦略が、この理論をベースに展開されてきたことに、疑いの余地はないだろう。
しかし、Webの登場によって、状況は大きく変わった。すなわち、欲しいと思ったものをPCなどの情報端末から即座に購入できるため、DesireとMemoryのプロセスが不要になってしまったのだ。そのかわり、興味・関心を抱いたものを検索（Search）するプロセスと、購入した商品の情報を共有（Share）するプロセスが追加された。
これが、いわゆる“AISAS”である。
- A
- Attention（注意・注目）
- I
- Interest（興味・関心）
- S
- Search（検索）
- A
- Action（行動・購入）
- S
- Share（共有）
AISASはマイナーな行動理論
Webサービスの普及によりドラスティックな変化を遂げた消費者の購買モデル。その革新的な進化を示す理論がAISASと言われているが、私はどうも釈然としない。どうしても、Attentionが見つからないからだ。
強いて言えば、YAHOO! JAPANやmixiなどのメガサイトに掲出されるビッグバナー広告などがそれに当たるだろうか。しかし、これらはどちらかというとスルーされる対象であって、Web上で買い物をする場合の主要な導線とは言い難い。
ブログパーツなども、Attentionを喚起するのに有効だろう。しかし、これも脇役的な広告パターンだろう。
私たちがWeb上で買い物をするとき、どのように行動するか思い出せばわかりやすいと思う。まず、買いたいものや興味のあるものが頭に浮かび、それを検索するのではないだろうか？ あるいは、Amazonや楽天などに直接アクセスする。もし、不明な点や不安な点があれば、mixiやOKWAVEで他のユーザーに聞いてみたり、２ちゃんねるの書き込みを調べたりするだろう。
どちらにしても、Webユーザーの行動はInterestからスタートすると考えて、まず間違いない。
ただし、例外がある。テレビや屋外広告、雑誌や新聞の広告など、マスなメディアで周知してからWebサイトに誘導するという、いわゆるクロスメディアだ。テレビCMなどで「続きはWebで」と言って、検索フォームに“○○”と入れるように指示するアレ。
しかし、これは厳密にWebの広告モデルとは言えないだろう。クロスメディアは、あくまでも主たるマスメディアに対する従のWebという考え方。しかも、これはマスメディアが多くの人に見られているということが前提なのである。テレビの視聴率がふるわず、雑誌・新聞の発行部数が減っている現状を考えれば、将来的に有望とは言えない。
このように考えると、Webにおいて、AISASは非常にマイナーな行動原理であることがわかる。
AISASの矛盾
AISASには、大きな欠陥がある。それは、最後のS、“Share”の部分だ。商品を購入し、そのレビューをネット上に残し、次に購買するカスタマーに助言とヒントを与える。AmazonやiTMS、楽天など、多くのB2Cサイトがこの機能を導入している。
しかし、AISASモデルには、このShareを受け入れるプロセスが存在しないのだ。注目して（Attention）、興味を持ち（Interest）、検索し（Search）、購入（Action）。そして、共有＝口コミ情報を流す（Share）。購入の前に共有を受ける＝口コミ情報を見る（Shared）は無くてよいのか？
AISASは、Shareの部分が途切れており、次の購買に繋がらない欠陥モデルと言わざるを得ない。
AISASの正体（推測）
少しうがった見方をしてみよう。そもそも、AISASを提唱したのは広告会社である。広告会社は、簡単に言ってしまえば、AIDMAモデルやAISASモデルで言うところの“AI”の部分で商売をしている。“AI”を作り込んで、最終的にActionにつなげるのが、彼らの仕事だ。そのためには、派手な広告を打って、消費者の興味・関心を集めようとする。
ところが、Webの消費者は、Action前の検討段階に必ず第三者意見（Shared）を聞こうとする。そして、その意見によって、最終的な購買を決断するのだ。
これは、広告会社にとって非常に都合の悪い話と言える。
Webでの購買行動がAttentionから始まることがごく稀で、しかも、Actionの前でSharedが商品購入を阻害してしまう。Webにおける広告会社の存在価値を揺るがしかねない話だ。
広告会社にとって、Attentionは必ず無くてはならないし、Sharedはあってはならないプロセスなのである。
これが、AISASという言葉が生まれた理由…いや、こんな言葉しか生まれなかった理由ではないだろうか。
AISASに代わる理論
Web上の消費者行動は、AttentionではなくInterestから始まる。この考えは、Webサービスが全般的に、ユーザー主導のPULL行動に基づいていることからも、かなり有力である。Interestは、一部Attentionからも生まれうるが、必然性（例えば、水道が壊れた、など）からも発生するし、多くは趣味や志向などから発生するだろう。
そして、Web上の消費者は、関心を持ったら、ブラウザを起ち上げキーワードで検索する。
では、Interestの次はSearchか？
私は、Searchだと少し狭すぎるような気がする。気になる情報について、キーワード検索する前にmixiやOKWAVE、２ちゃんねるなどで質問する人も少なくないからだ。「ググレカス」とか言われそうだけど。Amazonや楽天でレビューを読んで参考にしたい人もいるだろうし、SNSの日記やメッセージ機能で情報を集める人も多いはずだ。
ここは、Contact（接触）という言葉でまとめるのが適切だと思う。
Contactは、あくまでも接触という一つのプロセスなので、この後には当然Shared（第三者意見）が来る。
そして、Sharedを聞いて始めてAction（購入）するか否かを決定するのである。
まとめると、以下のようになる。
ICSAS
読み方は「イクサス」かな？
Webを使い倒している人たちには、あまりに意外性のないモデルかもしれないけど、わかっていない昔の人たちを説得するには使える言葉ではないかと思う。
実際の消費者行動と当てはめてみる
自宅で10年ほど使い倒した洗濯機が壊れたとしよう。必需品だけに、早急に買い替えなくてはならない。しかも、洗濯機なんて滅多に買い替えないものだから、これに関しては10年前の知識しか持ち合わせていない。最近の洗濯機はどんなのがあるんだろう？ と思う（Interest）。
とりあえず、最初に何をするだろうか？ 私なら最初にAmazonか楽天あたりにアクセスし（Contact）、レビューに目を通しながら（Shared）商品を探すだろう。あるいは、掲示板やSNSのコミュニティに質問トピックを作り（Contact）助言を募る（Shared）のもいいかもしれない。キーワード検索し（Contact）、ブログなどから情報を得る（Shared）のも有効だろう。
そして、実際に購入経験のある人の意見や、関連する詳細情報などを集めて検討し、納得のいく商品を買う（Action）。
商品の到着を待って、それなりに使い倒し、感想をWeb上に書き込む（Share）。
どうです？ 意外とスッキリしませんか？
異論反論などありましたら、コメント、トラックバック、newsingなどでご意見いただきたいと思います。
あと“ICSAS”について、「すでに似たようなのあるから！」みたいなご指摘もいただければ幸いです。
