全3回予定の企画、第4回。第5回+まとめで終わる見通しが立ったので、もう少しお付き合いのほどを。
今回はモバイルユーザーってどんな特徴があるの？とかどんな意図で検索するの？とか。
前回までの流れはこちら。
===============================
Part 2: Understanding Mobile User Needs… 67
Needs Met評価は「モバイルユーザーの」要求に応えられているかを評価するので、まずはこの章全部使って「モバイルユーザーとは」というレクチャーから。
ぐっぐるさんが考えるモバイルユーザー像も見えるし、逆にこっちがどういった点を意識すべきかを考えるのにもなかなか役立つ。
デスクトップユーザーは…？
12.0 Understanding Mobile Users, Mobile Queries, and Mobile Results …67
モバイルユーザーの特徴。
① データの入力が結構な手間
…タイピングはめどいし、音声認識はミスるしで面倒。
② 画面が小さい
…機能・アプリ・サイトによってはこれが影響して使いにくいことも。
③ スマホで使いにくいサイトがある
…横スクやらFlashやらのモバイルフレンドリーテストでハネられる要素があると使いにくいよね。
④ 回線が遅くて不安定
…アプリの起動・音声コマンド認識・ウェブページの表示なんかも遅いかも。本体のスペックに引っ張られることもあるしね。
で、ぐっぐるさんとしては「スマホではその時その時に応じて、すぐに結果を返してあげることが重要。」と考えている。前々から推してるマイクロモーメントですね。
その考えが評価・検索結果にどう影響するか？勘のいい方はもうお気づきかと。最近多いあれですね。詳しくは後程。
12.1 Important Rating Definitions and Ideas …68
用語の定義。おいおい必要に応じて紹介するので略。
12.2 Understanding the Query …69
クエリの解釈をするときはGoogle検索も使ってみようね！
でも上位の結果＝正義じゃないから気を付けてね！
こういうぐっぐるさんの客観的な感じは好き。
12.3 Task Location (Locale) and User Location… 69
黙示的な地理的条件について。
各Raterの担当エリアである「Task Location」とユーザーの所在地「User Location」の影響を考えよう。
12.4 Queries with an Explicit Location… 70
「ニューヨーク ホテル」・「新宿 飲み屋」等、クエリ内でローカル意図が明示されている場合は、その地域が最優先。
「新宿 飲み屋」で検索したユーザーが札幌にいるからって「本当は札幌近くの居酒屋に行きたいんでしょ？」なんて気を回す必要はない。
12.5 Queries with Multiple Meanings… 71
クエリによっては、意図を一つに絞り込めないものもある点に注意。ぐっぐるさん的には3種類に分類。
DI(支配的解釈)…大抵この解釈だよね。
CI(一般的解釈)…こういう解釈の人も結構いそうだね。
MI(少数派解釈)…こういう解釈もないわけじゃないけど…
DIは相対的に決めてます。
アメリカで「Apple」ならDI=iPhoneのところ CI＝甘酸っぱい果物 MI…アップルさんって名前の人
リンゴがメインなんじゃないの？と思わなくもないんですが、「Apple」で検索するとなるとまあ妥当かと。
「Amazon」「Windows」なんかも同じ理屈でしょうね。
一方、アメリカでmercuryなら「水星」・「水銀」・「有名な車メーカー」がどれも有名なんで、みんなCI扱い。 DIなし。
12.6 Query Meanings Can Change Over Time… 72
時間の流れもクエリの解釈に影響するよね。
「ブッシュ」って言ってもパパブッシュだったりジュニアだったりするわけで。
定期開催イベントのページなんかは気にしておいた方がいいかと。
検索エンジン的にはできるだけ今の情報を出したいので、それが拾われやすい構成にしておきましょう。
12.7 Understanding User Intent …72
以下の全6類型に分析。
KNOW
└Know Simple
DO
└Device Action
Website
Visit as Person
KNOWは「安倍晋三」「東京」みたいな情報・知識の収集目的。
その中でも特に「安倍晋三の年齢」「東京の人口」みたいに一つのResult Blockで解決できる程度の質問がKnow Simple。
DOは「インターステラ―のDVD買いたい」「BMI計算したい」みたいな、何かするのが目的。
その中でも特に「母に電話」「5時に目覚まし」みたいに、ウェブでどうこうじゃなく端末上で何かしたいのがDevice Action。
Websiteは「ようつべ」「amazon デジカメ」など。特定のページ・サイトに行きたい。
Visit as Personは「ホテル」「みずほ銀行」など。お店とかを実際に訪問したい。
モバイルユーザーが増えたからこういった需要多いですよね
で、怖いのがKnow Simple/Device Action/Visit as Personへのぐっぐるさんの対応。
「適切な情報を、即座に出す」のが重要ということで、適切なSCRBを極めて高く評価します。
クエリによっては世界最大級のまとめサイト・ぐっぐるさんが競合になるので、ぐっぐるさんと別の価値を打ち出して勝負するか、いっそ逃げるかの見極めがますます大事になりそうな。
くわばらくわばら。
12.8 Understanding Result Blocks …78
モバイル検索結果の最小単位である「Result Block(RB)」という概念について。
見慣れた「ウェブサイトへのリンク」も１つのResult Blockだし…(WSRB、Web Search RB)
最近よく見るダイレクトアンサー系も１つのResult Block。（SCRB、Special Contents RB）
「アプリの起動」「アラーム設定」なんかのデバイス内で何かするのもResult Block。(DARB、Device Action RB)
ぐっぐるさんが「ウェブ上の情報を探すシステム」じゃなくて「ユーザーの需要に可能な限りこたえるシステム」を目指してることがわかりますね。
12.9 Rating on Your Phone Issues …86
Rater用の手順。不要。
===============================
次回はもう一つの評価軸・Needs Metのお話など。
