今日、すべての企業がビッグデータを愛しており、ほぼすべての企業が間違いなくデータサイエンスアナリスト部門を持っています。 ただし、業界では製品アナリストとは何か、定量分析に焦点を当てているデータサイエンティストやUX研究者との違いについて明確な理解はありません。
次のような製品アナリスト部門が増えています。
- 目標と指標を設定し、製品開発のベクトルを決定する
- 現象の性質を探り、因果関係を特定する
- 予測アルゴリズムを構築する
この記事では、機械学習に専念している専門家を簡単に無視し、 Wrikeでの製品分析の役割のビジョンと、製品チームが毎日作業しなければならないタスクについて説明します。
定性的対定量的
原則として、開発者とパイマは数字が大好きです。定量データは、現在の状態を正確に把握し、ダイナミクスを示し、市場の見通しを評価するのに役立ちます。 同時に、数字自体が、人々の動機、選択の根本原因、さらなる行動について答える機会を提供しないことを忘れがちです。
定量的前の質的：質的方法がより良いデータサイエンスをサポートする方法
そのため、Wirkeでは、定性的および定量的研究を組織するアナリスト間で明確な区分けを行いません。 それどころか、私たちの意見では、小さなチーム（私たちの約10人）で、これらのスキルを可能な限り組み合わせて、定量的手法を使用して定性分析のアイデアを開発する必要があります。
実際、研究に関しては、アナリストから2つの期待が寄せられています。 彼はできる必要があります：
- 有望な製品成長ポイントを見つける
- 問題を定式化およびスケーリングして検証する
次に、これらの2つの期待について詳しく説明し、アナリストがビジネスの問題に対する理解と、スケーリングと検証に役立つ定量的手法との関係をどのように果たすかを示します。
1.製品の成長ポイントを見つける
アナリストは、問題とタスクをスケールアップすることにより、有望な製品成長ポイントを見つける人です。
製品アナリストのタスクを理解する最初のステップは、それが属する問題のクラスを判別することです。 通常、次の3つのタイプの研究が区別されます。
- 問題の発見-ユーザーが特定の製品機能以外でどのような問題を抱えているかわからない場合。 これは通常、インタビューの段階です。
- 問題の検証-特定のタスクがあることはわかっているが、非常に多くのユーザーがそれらを持っていることを確認したい場合。 これは、さまざまな調査の段階です。
- ソリューションの検証（ソリューションの検証）-考案またはプロトタイプ化された特定のソリューションをテストするとき。 ステージプロトタイピングまたはベータテスト。
アナリストは研究の3つの段階すべてに関与しますが、作業の主な焦点は通常、問題と解決策の検証にあります。 プロダクトマネージャーがアナリストとマーケティング担当者とともに、さまざまな顧客と20回のインタビューを行ったとします。 これらの結論が信頼でき、表明された問題が実際にすべてのユーザーに関連していることをどのように理解しますか？ 規模を評価することにより、発見された開発の可能性の客観性を確保する方法は？ 言い換えれば、インタビューで見つけたことが本当に製品の潜在的な成長ポイントであることをどのように検証するのでしょうか？
ここで、定性的研究と定量的研究を結びつけるツールの使用とデータの操作に関する知識を最大限に活用することができます。 規模を理解し、規模を判断する最も正しい方法を見つけることが、製品アナリストの主要な能力です。 分析的なアプローチにより、顧客の苦痛を収集するプロセスを変更することができ、製品チームによる検証に近づくことができた、ほんの一例です。
会話を認識して分析する
Wrikeにはアカウントマネージャー（ 顧客成功マネージャー ）の部門があり、その主なタスクは、販売を目的としてではなく、製品の使用経験を向上させることです。 ビデオを通じて顧客を呼び出し、現在の苦労について話し合い、ベストプラクティスを伝え、回避策を提案し、新機能の開発状況について報告します。 これらの会話はすべて長い間録音されており、食品組織では実際には使用されていませんでした。パイマは、顧客の苦痛に関する一般的な考えを得るために、アカウントマネージャーと個人的に通信することを好みました。 これにより、「壊れた電話」要素が追加される可能性があり、ユーザーがこの問題に直面した状況を常に明らかにするわけではありませんでした。
製品分析のイニシアチブプロジェクトの1つは、パイプラインの開発でした。これにより、会話が理解可能なテキスト形式に変わりました。 Google Speech API、および句読点を配置するためのいくつかの追加モデルを使用して、 単一のインタビューではなく、マネージャーとクライアントとの多くの会話に 基づいて、機能のいくつかの問題と要件の範囲をすばやく把握できました。 このシンプルなソースのおかげで、一部の機能や問題に関連するキーワードの全面的な検索を実行したり、特定のソリューションを必要とするユーザーの性質を評価したり、これが最も頻繁に浮上したコンテキストを理解することもできました。 現在、センチメンタル分析モデルのテストも行っています。これは、製品の個々の部分に対する満足度の平均レベルを自動的に把握し、製品チームに通知するのに役立ちます。
2.仮説を策定、スケーリング、検証する
アナリストとは、適切な抽象化レベルで問題を定式化し、それを測定し、重要性をチェックし、アクションの推奨事項を提示できる人です。
研究の段階に関係なく、ユーザーと製品との相互作用を評価し、さらなる開発計画を立てるのに役立つさまざまなレベルの仮説があります（詳細については以下で説明します）。 ここでは、必要な仮説のレベルを正しく評価し、情報を収集するツールまたはその検証を選択するというタスクがしばしば発生します。 実際、プロセスは次のとおりです。
- 仮説の定式化 -たとえば、「特定のコホートのユーザー管理者が週次レポートに基づいて請求できるようにすることが重要です。」
- 使用統計の収集 -古典的な分析タスク-は、上記で定式化された仮説に数値が応答できるかどうかを理解することです。
- フィードバックの収集 -マーケティング、メーリングリスト、または社内のフィードバックツールを通じて調査を実施
- 結果の分析と検証 -統計で結果を確認します。 関連性
製品アナリストを統計に精通している人と区別するのは彼であることが多いため、3番目の段落について説明しましょう。
フィードバック収集
多くの企業は、ロギングシステムをセットアップし、Googleアナリティクスなどの分析サービスを自社製品に固定すると、分析プラットフォームの準備はこれで終了すると考えています。 しかし、残念ながら、このアプローチでは、最も重要な要素は忘れられます-ユーザーからのフィードバックの必要性、適切なタイミングで彼のタスクと彼が直面している困難について彼に尋ねる能力。
したがって、チームが何らかのマーケティング調査だけでなく、内部メカニズムを通じてユーザーを控えめに調査し、ユーザーからフィードバックを収集するための十分なツールを持っていることが重要です。
内部QFFツール（定性的フィードバックフォーム）を使用して仮説を策定および検証し、考えられるユーザーエクスペリエンスシナリオを3段階のピラミッド（製品→機能→相互作用）として検討します 。
- 製品レベル
- 機能レベル
- 特定の相互作用レベル
それぞれをもう少し詳しく見て、問題を理解するために使用するメトリックを示しましょう。
1.製品レベル
ここでは、ユーザーエクスペリエンスの目標到達プロセスの最も広く最も機能的な部分を理解することが重要です。 これは、製品全体または単一のタスクを解決するための一連の機能に満足しているかどうかにかかわらず、最もグローバルな質問に対する答えを見つけたいという欲求です（たとえば、休日の調整には、カレンダー機能、タスクステータス、スケジューリングアルゴリズムなどの相互作用が必要になる場合があります）。
このような状況に適用する必要のある明確に規制されたメトリックはなく、常に微妙な違いがあります。 ただし、原則として、この抽象化レベルでは、NPS（ネットプロモータースコア）またはSUS（システムユーザビリティスケール）メトリックについて説明しています。 メトリックスは議論の余地はありませんが、原則として、それでも業界標準であり、数四半期のスケールで目標を設定するのに役立ちます。
2.機能のレベル
このレベルでは、特定の機能に直接関連するより具体的な質問をします。 上記の例から-すでに一般的に「休日の調整」の問題ではなく、カレンダーなどの製品の特定の部分のみを取り上げることができます。 彼らは知覚についてどのくらい快適ですか？ なぜ人々はそれらを使用するのですか？
調査の段階によって、質問が異なるだけでなく、ユーザーから収集した指標も異なる場合があります。 最も単純なのは満足度であり、さまざまなスケール（3つの絵文字またはリッカートスケール）、CES（顧客努力スコア）を使用してタスクごとに読むことができます-ユーザーがいくつかのタスクを実装するのはどれほど難しいか簡単です。
3.相互作用のレベル
このレベルのタスクは、ユーザーが製品で実行した特定の反復を評価することです（たとえば、ボタンをクリックしました）。 同時に、この相互作用の結果が、測定または制御できない特定のアクションまたはソリューションであることが重要です。 原則として、ここでは満足度とその後の特定の決定の採用について話します。たとえば、マネージャーがカレンダーを見て、従業員が休暇を終了する時期を理解しましたか？ データエクスポート形式はユーザーに適していますか？ それ以降のすべてのアクションはユーザーの頭または製品の外部でのみ発生するため、反復を評価する他の方法はありません。
実際、相互作用評価のレベルは、特定のイベントを評価する必要があるサポートやその他のサービスでよく使用されるCSAT（顧客満足度）メトリックを評価する試みです。 同時に、CESのようなメトリックもここで使用できますが、より「ローカルな」形式で使用できます。
結果の分析と検証
仮説を修正し、質問を定式化し、製品のユーザーエクスペリエンスの適切なレベルで検証調査を実施した後、今回は統計と仮説テストの分野で、アナリストから特別な才能を必要とするタスクが発生します。
実際、各調査の後、アナリストは作業の結果を含む結果をどの程度の信頼で信頼できるかを確認する必要があります。 大企業での仕事の要因は答えに影響しますか？ そして、従業員の地位？
これらの仮説はすべて、必要なツールを使用して慎重に確認されます。A/ Bテストを正しく実行するなど、アナリストに直接依存するのは、特定の状況ごとに適用されるアプローチです。 原則として、回帰分析はしばしば使用できますが、唯一の普遍的なソリューションではありません。 独自の適用分野と解釈分野があります。 特定の方法は常にアナリストの裁量に任されています。
結論の代わりに
上記では、アナリストの仕事の2つの主要なケースのみを明らかにしましたが、同時に、彼の仕事のすべての段階について意図的に話しませんでした-すべてのタイプの研究の詳細な説明、仮説の定式化、およびデータの正しい収集は別の記事の価値があります。 ただし、分析からの期待のそのような高レベルの定式化とその作業の主要な方法の修正でさえ、製品チームを大幅に強化し、より良い製品を作るのに役立つと信じています。
データ内の成長点を見つけて（構造化されていない場合でも）、仮説を正しく定式化し、現在および将来のすべてのユーザーに対してスケーリングおよび検証する機能-これらは製品アナリストを区別する特性です。 したがって、このような要件が最も明確な結果をもたらし、運用ルーチンに滑り込まないことを確信しているため、これらの原則を他のチームに大胆に推奨します。
Wrikeのすべての分析をサポートする定量分析、ビッグデータ、インフラストラクチャについてお知りになりたい場合は、サンクトペテルブルクオフィスでの会議にご来場ください。 さて、または単に訪問してください。