アプリ操作データダッシュボード（アプリ監視・管理プラットフォームの構築方法）

APP 監視および管理プラットフォームを構築するにはどうすればよいでしょうか?

編集者注: データ監視管理プラットフォームは、さまざまなビジネスのプロセスとニーズに応じて変化しますが、原則は同じです。この記事の著者は、仕事でのプロジェクト実践と経験に基づき、主に 0-1 プラットフォームの製品企画と設計における APP 管理、データ監視、権限管理機能の設計経験を共有し、皆さんの参考と学習に役立てています。

J銀行は2021年4月中旬、銀行内の数十のモバイルアプリケーションの集中監視と管理を強化するために、APP監視および管理プラットフォームを構築し、モバイルアプリケーションの集中管理を実現し、データ指標システムを確立してデータの可視化を実現し、運用データの監視とデータ分析を実施してモバイルアプリケーション運用に対するデータサポートを提供しました。甲党の指導者たちはこのプロジェクトを非常に重視し、最優先事項として挙げ、強力な支持を与えた。

J銀行は、銀行内および子会社内の複数のアプリを監視・管理するために、主にアプリ管理、レビュー管理、運用監視、ユーザー権限管理の機能を含むアプリ監視・管理プラットフォームを構築しました。このプラットフォームは銀行の内部バックエンドとして、ビジネス機能の運用の実用性と利便性に重点を置いており、パーソナライズに対する要件は高くありません。対象ユーザーは、銀行内の内部プラットフォームユーザー、主に上級管理職、ビジネスマネージャー、営業担当者です。

プロジェクトはアジャイルモードで実行されます。当社は、当事者 A のプロジェクト マネージャーと協力して、プロジェクトの進捗状況に関するコミュニケーションと理解を促進します。要件ドキュメントとビジネスルールを解釈し、要件ビジネスプロセス全体を整理し、グループディスカッションを組織します。

需要分析プロセスでは、不明瞭な要件についてグループディスカッションを実施し、地域をまたいだ事業部門とのリモートビデオ会議（Xiaoyu Yilian を使用）を開催しました。また、定期的にビデオ会議を使用して、地域や部門間で結果を確認しました。

人的資源は限られており、要求範囲は広いです（7 つのモジュール、24 の二次メニュー機能）。評価後、私はすぐに上司にサポートを申請し、さらに 2 人のプロダクト マネージャーを任命しました。人的資源（チームには合計 6 人のプロダクト マネージャー）が限られており、専門レベルも限られており（ジュニア 2 人、中級 3 人、シニア 1 人）、時間も限られているため、需要分析、部門間の共同コミュニケーション、範囲の確認、製品設計、部門内レビューなど、多くのリンクを通じて、すべてのプロジェクト範囲の要件の高精細プロトタイプ設計を完了することは、やや非現実的です。

私はすぐにA社のプロジェクトマネージャーにフィードバックし、プロジェクトの実施範囲を2つのフェーズに分割することを提案しました。この段階では、まずプロジェクトの主な機能モジュールを設計して実装し、第 2 フェーズで二次機能を追加する必要があります。当事者 A のプロジェクト マネージャーは私の提案に耳を傾け、適時に当事者 A のリーダーに報告しました。最初のフェーズの実施範囲を狭めることを提案することで、その後のプロジェクトタスクを成功裏に完了するための強固な基盤が築かれました。

調整:チーム (合計 6 人) を率いて監視プラットフォームの需要分析を実施し、高解像度のプロトタイプ設計とチーム コラボレーション プロトタイプのバージョン管理のための Axure の使用を調整しました。フォント、トーン、レイアウトを統一し、コンポーネントライブラリを使用して高精細なプロトタイプを作成します。このようにして、私たちが設計した高精細プロトタイプは、ビジュアルスタイルとスタイル仕様（フォント、ボタン、フォーム、テーブルなどを含む）が統一されています。

トレーニング:これまでの製品設計の経験に基づいて、まずチーム メンバーに要件を理解してもらい、ビジネス プロセスに精通してもらい、ビジネス ロジックを理解してもらいます。私はビジネス プロセスを整理し、プロトタイプの設計を実施し、ジュニア プロダクト マネージャー向けに Axure スキルの短期集中トレーニングを実施しました。

調整とトレーニングを経て、製品設計を開始しました。ここでは主に、APP 監視および管理プラットフォームの APP 管理、データ監視、権限管理の機能設計とエクスペリエンスについて説明します。

APP 管理とは、銀行の複数の APP を集中管理することであり、主に上場申請、上場廃止申請、バージョン管理などが含まれます。

1) 上場申請

APP上場申請とは、APPがアプリケーションマーケットに出品される前の上場申請です。必要な情報には、予備的な市場調査、実現可能性分析、製品計画プラン、APP バージョンプラン、ビジネスの説明、APP 体験パッケージ、APP 法令遵守レポートなどが含まれますが、これらに限定されません。関連部門 (例: インターネット金融部門、金融技術部門、法務部門、広報部門) が共同で検討し、最終的に決定結論を出力します。

ビジネスプロセスは次のとおりです。

APP上場申請を提出後、審査管理で申請記録を閲覧することができます。記録の[詳細]をクリックすると、記録されたAPPの基本情報、アプリケーション情報の一覧、レビュープロセスが表示されます。申請記録を変更するには、記録の [変更] をクリックし、変更後に送信します。変更後も確認が必要になります。

2) 上場廃止申請

アプリがリストから削除される理由はさまざまですが、運用上の理由により企業がアプリを積極的に削除する場合や、アプリ市場のレビューなどの理由により受動的に削除する場合などがあります。

• アプリを自発的に棚から削除したい場合は、アプリケーション マーケットの関連手順に従ってください。なお、APP を販売終了にする際には、顧客からの苦情や法的紛争を回避するために、運営チームが出口戦略、顧客への説明、苦情処理、世論対応計画、事業移行計画などの資料を準備する必要があります。
• アプリが受動的に削除された場合は、削除の理由を明確にし、問題を解決して修正した後、アプリマーケットへの掲載を再度申請する必要があります。モバイル アプリがアプリケーション マーケットから撤退した後は、プラットフォームに報告する必要があります。

ビジネスプロセスは次のとおりです。

上場廃止申請が提出されると、審査管理で申請記録を閲覧できるようになります。記録の[詳細]をクリックすると、記録されたAPP基本情報、申請情報の一覧、審査プロセスなどが表示されます。申請が失敗した場合にのみ、記録に[変更]ボタンが表示されます。 [変更]をクリックすると、上場廃止申請情報を修正します。変更後、送信しても審査が必要になります。

3) バージョン管理

アプリケーションマーケットでAPPバージョンが更新された後、プラットフォームに登録する必要があります。バージョン管理では、APP バージョン記録を追加する機能を提供します。この機能では、各 APP バージョンの情報 (開発者、リリース日、更新日、バンドル ID バージョン、APP ID など)、シェルフ ステータス (さまざまなアプリケーション マーケットを含む)、バージョン記録 (さまざまなアプリケーション マーケットを含む、主な情報には、アプリケーション名、バージョン番号、更新日、更新ログ、スクリーンショット、アプリケーションの説明が含まれます)、バージョン比較 (比較の種類には、更新ログとアプリケーションの説明が含まれます)、バージョン統計などが表示され、APP のバージョン変更が表示されます。バージョン記録は次のとおりです。

データ監視は APP 指標システムに基づいています。データダッシュボード（コックピット）を使用して、APPの動作やその他のデータを視覚的なチャート形式で表示し、指標に基づいてAPPデータの変化を監視および測定します。データ監視は、主にデータ収集とデータ表示の 2 つの部分に分かれています。

1) データ収集

APP データ収集には、外部データ収集と内部データ収集が含まれます。

1.1 外部データ収集

外部データとは、アプリがリリースまたはアップデートされた後の、アプリ市場や専門データプラットフォームにおけるアプリのパフォーマンスを指します。

アプリケーションマーケットには主にApp StoreとAndroid（主にHuawei、Xiaomi、VIVO、OPPO、Meizu、App Store、Baidu、360）が含まれます。 APPのダウンロード量とインストール量は、さまざまなアプリケーションマーケットを通じて収集できます。

Analysys Data や Baidu Index などの専門的なデータ プラットフォーム。専門的なデータ プラットフォームを通じてデータを収集し、APP の人気度を観察できます。

1.2 内部データ収集

内部データとは、ユーザーのクリックデータ、行動パス、トラフィックなど、アプリ内のユーザー行動データを指し、アプリ内にポイントを埋め込むことで取得できます。特に新バージョンの機能については、設計・開発中に対応する追跡ポイントを追加して、機能のリリース後のデータの変化を観察し、データ収集の検証と分析を実施する必要があります。これは、次期バージョンの機能計画において重要な指針となります。

収集したデータ情報（Huawei App Marketからのダウンロード数など）をバックエンドデータベースに入力してアップロードしたり、サードパーティが提供するデータインターフェースを呼び出したりします。データ送信ビジネスプロセスは次のとおりです。

2) データの提示

収集された APP データは通常、データ ダッシュボードを通じて視覚化できます。データ ダッシュボードは複数のデータ チャートで構成されており、合理的なページ レイアウトと視覚効果のデザインを通じてデータの視覚化をより適切に表示できます。データ ダッシュボードでよく使用されるグラフには、棒グラフ (または積み上げ棒グラフ)、折れ線グラフ (または曲線)、面グラフ、円グラフ (またはドーナツ グラフ) の 4 種類があります。データ レポートは 12 個以上、データ インジケーターは数十個ありますが、すべてを提示する必要はありません。

ユーザーはダッシュボード上のデータ統計を使用して状況を把握し、問題を解決し、作業を報告できます。職務の責任が異なるユーザーには、それぞれ異なるニーズがあります。社内担当者のユーザーロールを分析します。

• セールスマン: 個人的な業務を担当し、自分自身と業務の詳細に焦点を当てます。
• ビジネス マネージャー: 特定のビジネスを担当し、ビジネス ダッシュボードに注意を払い、ビジネス トレンドに注意を払います。
• 上級管理職: 会社の発展に責任を持ち、中核指標に焦点を当て、戦略ダッシュボードに注意を払い、戦略的な意思決定を行います。

データダッシュボードは、表示場所によって主に大画面用と非大画面用の 2 種類に分けられ、コンテンツの重点も異なります。

「ビッグスクリーン」は通常、司令室のビッグスクリーンに表示されるページを指し、システムの中核となるページでもあります。まず、ビジネスの状況をできるだけ早く把握できるようにすることです。 2 番目に、中間管理職と上級管理職はビジネス データに非常に敏感であり、数字を見るだけでビジネスの異常を判断できます。

データのプレゼンテーションは主にデジタル コンテンツの形式で行われ、簡潔かつ明確で、結果が強調されます。一般的に、約 6 個のデータ指標を設定すると、最も重要な指標の分析に集中しやすくなります。

データの適時性はリアルタイム データに傾いており、一般的には早期警告を最初に提供できます。視覚効果では、動的効果に多くの労力が費やされ、チャートでのトレードオフが必要になります。

私たちはビジネスチームとコミュニケーションを取り、どのデータ指標と測定方法を使用するかを決定しました。たとえば、各アプリのトランザクションランキングをどの期間で表示するかなどです。大画面表示は以下のとおりです。

「非大画面」は通常、ビジネス モジュール内の統計ページを指し、主にシステムの日常的な使用の特定の部分のビジネス指標を分析します。データの適時性に関しては、トレンドデータがより頻繁に表示され、トレンドを通じて問題を発見して解決することができます。大画面以外のディスプレイは以下のとおりです。

2.1 データダッシュボードの設計手順

1. 表示する必要があるブロックを決定します。一般的に、最も重要な指標の分析に集中できるように、約 6 個のブロックを設定します。
2. データ指標、測定方法、優先順位、およびブロック内で分類する必要があるものをリストした後、
3. 大画面での表示の場合、デザインとレイアウトはUED/UIデザイナーによって完成されます。大画面でない場合は、Axure+echars または Axure チャート コンポーネントを使用して視覚的なチャート デザインを作成できます。

バックエンドシステムは一般に公開されておらず、社内の担当者のみが使用するため、データダッシュボードの設計は比較的シンプルになります。もちろん、UI デザイナーによるデザインサポートを備えた大画面データ ダッシュボードは、大画面の重要性を強調し、プレゼンテーション中にリーダーからより高い評価を得ることができます。

2.2 データダッシュボード設計の重要なポイントは次のとおりです。

1. シンプルで効率的、クールなインタラクションよりもチャートの表示効率を優先します。
2. 情報は関連性が高いものでなければなりません。たとえば、変化を反映するために前月比または前年比の比較を使用するなどです。
3. データ チャートの更新頻度と統計頻度はビジネス ニーズを満たす必要があり、リアルタイムで更新されるのが最適です。
4. 選択されたデータは傾向とパターンを反映できます。傾向特性のないデータの場合は、数値を直接表示する方が適切です。
5. さまざまなデータ指標 (ダウンロード数、クリックスルー率、アクティブ ユーザー数など)、さまざまなデータ特性 (変動、比較、並べ替えなど)、さまざまな測定方法 (顧客満足度など) に応じて、適切なグラフの種類を選択します。

3) 権限管理

権限管理は、監視および管理プラットフォームの正常な動作を保証するための基礎です。各組織の階層、各階層のユーザー数、ユーザーの役職、対応する役職の役割と責任を管理することで、合理的な業務の割り当てと管理を実現します。

権限管理設計では、ロールベースのアクセス制御 (RBAC) モデルを採用しています。 RBAC (ロールベースのアクセス制御) モデルは、主にユーザー、ロール、権限という 3 つの基本コンポーネントで構成され、最小権限の原則、責任の分離の原則、データ抽象化の原則という 3 つの主要なセキュリティ原則に準拠しています。

1. 最小権限の原則: タスクを完了するために必要な最小限の権限セットを持つようにロールを構成します。たとえば、操作照会職は、APP 関連の求人応募の発起者であり、権限の範囲内でさまざまなデータ ビューの照会者です。業務または権限の範囲内で、各種資料の準備、各種情報の記入、求人応募の開始、データ閲覧情報の照会などを担当します。
2. 責任分離の原則: 独立した相互排他的な役割を呼び出すことで、機密性の高いタスクを共同で完了できます。例えば、金融技術部、法務部、広報部、銀行業務センターの 4 つの部門の監査担当者が共同でレビュー業務に参加することを要求するなどです。
3. データ抽象化の原則: 権限の抽象化を通じて反映できます。たとえば、操作クエリ投稿では、APP リスト アプリケーションやクエリなどの抽象的な権限を使用できます。

RBAC モデルは、ユーザー、ロール、権限間の関係を簡素化し、拡張と保守を容易にします。操作順序を制御するメカニズムは提供されていませんが、既存のビジネス ニーズを満たしています。

RBAC モデルの権限管理には、主にユーザー管理、ロール管理、権限管理が含まれます。プラットフォームのビジネスニーズに応じて、異なる部門の異なるカテゴリのユーザーに異なるロールが割り当てられ、異なるロールには異なる権限が割り当てられます。権限設定には、APP 権限設定と機能メニュー権限設定が含まれます。したがって、プラットフォーム権限管理には 2 つのソリューションがあります。

1. ロールをカスタマイズし、ロールに機能メニューの操作権限を割り当て、ユーザーに APP の操作権限を割り当てます。
2. 役割には4つの種類があります。機能メニューの操作権限はロールに割り当てられ、APPの操作権限はユーザーに割り当てられます。

ビジネス上のニーズと時間の制約により、より迅速な進行と、後でカスタム ロール機能を拡張できるオプション 2 を選択しました。

開発前にプロトタイプのユーザビリティテストを実施し、修正を加えます。ユーザビリティテスト審査に合格後、開発スケジュールを申請します。私たちは、一度に 1 つのモジュールを開発し、 1 つのモジュールをテストするというアプローチを採用しています。時間的制約と開発エンジニアの数が限られているため、モジュールが開発された後、関連するテストを実施するためにテスターがすぐに配置されます。テスト中にバグが発見された後、関係する開発エンジニアがすぐにバグを修正しました。

テストに合格した後、プロジェクトは2021年11月末に正式に開始されました。第1フェーズでは、APP管理、指標監視、権限管理の3つの機能モジュールが開始され、残りの4つの機能モジュールも順次開発されています。

APP監視および管理プラットフォームプロジェクトは時間に敏感で要求が厳しいものでしたが、チームメンバーは協力して、時間通りに、質と量を保ってタスクを完了し、A社から賞賛され、チームに報酬が与えられました。

今、このプロジェクトの製品設計から1年が経ちました。見直しにあたっては、当時の状況を思い出しながら要件を読み直しました。情報を整理して確認しながら、過去の職務経験を改めて検証することも新たな学びの方法だと気づきました。著者は、プロジェクトにどれほど忙しく取り組んでいるとしても、経験と知識ができるだけ早く体系的に蓄積されるように、タイムリーにプロジェクトを見直す必要があると考えています。

2021年10月初旬、WeChatミニプログラム監視および管理プラットフォームプロジェクトに参加し、プロジェクトと製品の要件に基づいて製品設計タスクを完了しました。

この記事はもともと @樱子 によって Everyone is a Product Manager に掲載されました。著者の許可なく複製することは禁止します。

タイトル画像は、CC0 プロトコルに基づいて Unsplash から取得したものです。