2015年12月27日日曜日

よりぬきSearch Quality Rating Guideline ⑤Needs Met(ユーザー意図との合致)

長かったこの企画もとりあえずひと段落。

前回までの流れはこちら。

Part 3: Needs Met Rating Guideline… 87

13.0 Rating Using the Needs Met Scale… 87

ようやく評価基準その2 「Needs Met」のお話。

Needs Metの評価基準を一言でいうと以下の通り。
「Need Met評価にあたっては、モバイルユーザーの観点から、検索結果がどのくらい役に立ち、満足できるかを判断すること」…デスクト(ry


評価軸は大きく分けて5段階。
==========================
① Fully Meets…
大半のユーザーがこの結果だけで満足。他の結果とかいらない。
特定のクエリと検索結果にしか適用できない。


② Highly Meets…
大半のユーザーにとって、とても役に立つ。
一部のユーザーには他の検索結果も必要かも。


③ Moderately Meets…
多くのユーザに取って、そこそこ役に立つし、一部のユーザーにはとても役に立つ。
他の検索結果も必要かも。


④ Slightly Meets…
モバイルユーザーの一部には、そこそこ役に立つかも。
”一応クエリに関係ある検索結果だけど、今一つだな…”といったもの。
大半のユーザーには他の検索結果が必要。


⑤Fails to Meet
ユーザーにとって全く不要。
全ユーザーが他の結果を必要とする状態。
==========================



13.1 Rating Result Blocks: Block Content and Landing Pages… 88

12.8で取り上げた各種のResult Block全部が評価対象になる。以上。


13.2 Fully Meets (FullyM… 90

満点。
「この情報だけあれば十分、ほかの情報は不要かも」ってぐらいじゃないとダメな特別評価。


Fully Meetsの定義は以下の通り。全部満たさないとだめ。
① ユーザーの意図がとても明確。
回答が1つに絞り込めるレベルでないとだめ。
「バラク・オバマ」は一見明確だけど、公式サイトに行きたいのか活動履歴を知りたいのかはっきりしないからFullyMに該当するRBは無し。


② そのResult Blockが、ユーザーの需要を「最低限の手間で」満たすことができる
③ ほぼすべてのユーザーに対して、「その他の検索結果は不要」というくらいに需要を満たしている。


相当厳しいので、クエリ・サイトによってはこれが取れないこともある。
「このクエリで1位は無理じゃないかな」という見極めに使おう。


Fully Meetsが発生しやすいのはこんなパターン。
① ユーザーが特定のサイト・ページに行きたがっていて、Result Blockがそのページ・サイト。
「Amazon」「Yahoo.c0m」とか。
やふー.c0mは原文ママ。誤字とかも考慮してます。


② デバイス上で何かしたくて、それに合ったDARB。
「Facebookを起動」「午前5時に目覚まし」とか。


③ ユーザーが特定の事実を求めていて、その回答を「即座に・完璧に・明らかに」提示している
「イタリアの地図見せて」「スタバの株価」とか。


③の回答でSCRB推しなあたり、ぐっぐるさん対策とても重要。




13.3 Highly Meets (HM) …99

ほぼ満点。


取り上げられてるぐらい例も、「サイト側の品質的にはほぼ問題ないけど、ユーザーの意図が1つに絞り切れないから」という物がほとんど。
大抵のサイトだとメインのKW市場は意図を一つに限定できないクエリだろうから、この評価を狙うことが重要。

13.4 Moderately Meets (MM… 107

ふつー。


大切なのは「低品質」「古すぎて現状に合っていない」「不正確」だとふつー扱いすらしてもらえない点。
無駄に更新する必要はないものの、古すぎて現状と合ってないページはアーカイブに落とすとか更新するとかの鮮度維持策は重要ですね。


13.5 Slightly Meets (SM… 109

ちょっとこれは…。


「低品質」「古すぎて現状に合っていない」「不正確」の他に「クエリに対する合致」がポイント。
クエリの意図に対して広すぎたり狭すぎたりすると不利。
例えば「リンカーンの誕生日」クエリに対して「アメリカ全大統領の誕生日リスト」は広すぎるし、
「バイク」クエリに対して「新宿のバイク屋の営業情報」は狭すぎですよね。全くあってないわけでもないけど。
情報単位の設計とかとても大事。大きいサイトは特に。

13.6 Fails to Meet (FailsM… 112

全くダメ。不要。


ユーザの意図に全くあってないとか、あまりにも「低品質」「古すぎて現状に合っていない」「不正確」とか。
しばらく前に「tripadvisor ヒルトン」で検索してるのに、ヒルトンに関するSCRB(もちろんTripAdvisorは関係ない)が表示されるバグがありましたが、これなんか典型的ですね。…がんばれぐっぐるさん。


以上でNeeds Metの主な評価基準は終わり。
「ユーザーが必要とする、正確で質のいいコンテンツを作る」という当たり前のことを評価するのも結構大変なんです。



14.1 Porn Flag …120
ここからは問題点のフラグ立てについて。
「えっち」「謎言語」「読み込めない」「モバイルで使いにくい」の4点。


まずは「えっち」フラグについて。
画像・リンク・文章・ポップアップ・目立つ広告などに「えっち」なものが入っているとPornフラグが立ちます。
なにが「えっち」で何が違うかはその地域の文化なども考えて判断してね、とのこと。
「目立つ」広告じゃなきゃいいのかという点が気になりますが、どこら辺に閾値があるかわからないので変な広告は出さないに限りますね。
Pornフラグが立つとどうなるのかは次項で。




14.2 Needs Met Rating for Porn Results …121
Pornフラグが立つと、クエリの意図に応じてNeeds Met評価が不利に。
「ポルノを見たくない人にそういったものをお出しするのは、非常にダメだよね」という判断。


① あからさまにえっち系の意図しかないクエリ
「xvideo」「チアリーダー ポルノ」等々、書きすぎるとbloggerさんがお怒りになる感じのクエリ。
こうしたクエリの場合、フラグが立っててもNeeds Met評価に影響なし。


② もしかしたらえっち系かもクエリ
「胸」「女の子 画像」「スパンキング」とか。
スパンキングが代表例として入るあたりにメリケンカルチャーを感じます。
この場合えっち系の意図はMI(少数派解釈)扱いになり、フラグが立ったページはSM評価が関の山。


③ きっと違うよクエリ
「おもちゃ」「ラクダの背の高さは?」とか。
上の2つはガイドラインに例示されてるクエリ。なんでこれを選んだのかは「大人の○もちゃ」「Camelt○e」で画像検索してみよう。
この場合「検索ユーザーにえっち系の意図は無い」という扱いになり、フラグが立ったページは最低のFM評価。


14.3 Reporting Illegal Images… 122

Rater向け手順であり不要。
イリーガルな画像は報告してね、という項目なのですが、動物系のポルノが入っているあたりがアメリカン。ギリシャ神話ならでも白鳥でも手当たり次第なのにね。


14.4 Foreign Language Flag… 123

ユーザー所在地で一般的でない言語の扱いについて。
日本だといきなりタガログ語のページを表示されたりとか。


原則は「現地人に表示して、意味がなさそうならNeeds Met評価は下がる」
例えば「タガログ語の論文」は日本だと普通ならFM評価。
だけどクエリがタガログ語なら内容に応じた評価。そのユーザーはタガログ語わかるだろうから。
「タガログ語の歌の動画」は内容によりけり。歌なので「タガログだがら必ず意味不明」とはならない。


14.5 Didn’t Load Flag …127

読み込めなかったページに立つフラグ。
「マルウェア警告」「証明書についての警告」でもこのフラグが立つ点に注意。セキュリティ大事。


14.6 Hard to Use Flag… 129

モバイルでの利用が実質不可能なページ。
文字が小さすぎ」「データ入力とか無理」「レイアウトがたがた」など。リンク先をスマホやデベロッパーモードで確認してみよう。
ちなみに評価への影響は不明。怖い。


15.0 The Relationship between E-A-T and Needs Met …130

EATとNeeds Metの関係。
ここから”E-A-T rating”・”E-A-T Slider” という謎ワードが頻出します。
131Pのコメント見た限りPage Quality評価とほぼ同じ視点で評価しているので、用語の統一ができてないだけかも。


Needs Met評価するときにはEATもそれなりに考慮してね!というだけの話。


16.0 Rating Queries with Multiple Interpretations and Intents… 132
特になし。

16.1 Rating Queries with Both Website and Visit-in-Person Intent… 132

「みずほ銀行」「セブンイレブン」みたいなチェーン店系クエリに対して、適切な内容のローカルパックがほぼ最高評価。
サイトによってはつらい判定でしょうね。

17.0 Specificity of Queries and Landing Pages …134

特になし。


18.0 Needs Met Rating and Freshness …141

「新鮮さ」に対する判断。
「古い=悪いってことはないよ。古い情報でも今でも正確なら問題はないよね。」
「でもクエリに応じて”新鮮な情報が必要かどうか”は判断するよ。」
”Windows OS"で今更Meの話をされてもちょっとね、みたいな。


19.0 Misspelled and Mistyped Queries and Results… 143

19.1 Misspelled and Mistyped Queries… 143

誤字脱字について。特に重要な点なし。
大昔に「やっふー もしかして:Yahooで検索しましたか?」みたいなページを量産する手法ありましたね。もう意味ないよね。くらい。


19.2 Name Queries …144
特になし。

19.3 Spelling Suggestion Result Blocks… 144

特になし。

20.0 Non-Fully Meets Results for URL Queries …146

特になし。

21.0 Product Queries: Action (Do) vs. Information (Know) Intent …148

「特に金額高めの商品については、EATのある情報重要だよね」
大事。

22.0 Rating Visit-in-Person Intent Queries …149

来訪目的のクエリについて。
ユーザーの近隣にある物優先なんで、適切なマイビジネス情報は把握させておきましょう。
ローカルパックは上位表示されやすいし。


Part 4: Using the Evaluation Platform …152

23.0 Introduction …152

24.0 Accessing the Evaluation Platform (EP… 152

25.0 Evaluation Platform Screenshot… 152

Rater向けのご案内。不要。

26.0 Needs Met Task Page Screenshot… 153

「タスクのプロパティにはモバイル以外にもウェブ・動画・画像などがある」
Needs Metでモバイルモバイル言ってたので「デスクトップ向け検索はどうなの」と不安になっていましたが、デスクトップはデスクトップで別に評価しているのかも。安心。

26.1 Understanding the User Location on the Task Page… 155

27.0 Notes about Using the Needs Met Rating Interface …156

28.0 Using the “Report a Problem / Release this Task” Button… 156

29.0 Reporting Results with Duplicate Landing Pages… 157

29.1 Pre-Identified Duplicates …157

29.2 Rater-Identified Duplicates… 158

Rater向けのご案内。不要。

===============================



終わった―!
長々とお付き合いいただき多謝。


おまとめも出したので、この話はいったんおしまい。

2015年12月6日日曜日

よりぬきSearch Quality Rating Guideline ④モバイルユーザーを理解しよう

全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」の影響を考えよう。
クエリの解釈が変わることがあるので注意。「Football」とか。アメリカイギリスで全く違う。


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)」という概念について。

見慣れた「ウェブサイトへのリンク」も1つのResult Blockだし…(WSRB、Web Search RB)
最近よく見るダイレクトアンサー系も1つのResult Block。(SCRB、Special Contents RB)

「アプリの起動」「アラーム設定」なんかのデバイス内で何かするのもResult Block。(DARB、Device Action RB)


ぐっぐるさんが「ウェブ上の情報を探すシステム」じゃなくて「ユーザーの需要に可能な限りこたえるシステム」を目指してることがわかりますね。



12.9 Rating on Your Phone Issues …86

Rater用の手順。不要。
===============================

次回はもう一つの評価軸・Needs Metのお話など。