実戦事例 | 製品データ運用システムを構築する11ステップ

本稿では、著者のテンセントとYYでの実戦事例から「製品データ運用システムを構築するための11のステップ」を以下のように詳しく説明します。

ステップ1: 製品目標を設定する
ステップ2: 製品データ指標を定義する
ステップ3: 製品データインジケーターシステムを構築する
ステップ4: 製品データ要件を提案する
ステップ5: データを報告する
ステップ6～8: データの収集とアクセス、保存、スケジュール設定、計算
ステップ9: データを取得する
ステップ10: データの観察と分析
ステップ11: 製品評価とデータの適用

Blues はインターネット業界で 10 年以上のキャリアを積んできましたが、その仕事の大部分はデータ操作に費やされました。QQ Show から YY Voice、そして Thunder に至るまで、製品のデータ操作の最適化、プラットフォームの構築、分析の応用などのプロセスを経験し、製品におけるデータの重要な位置を目の当たりにしました。

多くの人は、データ操作について、デジタル統計や原因分析などしか理解していません。実際、これらはデータ操作作業のほんの一部にすぎません。データは最終的に製品に役立ちます。データ操作の焦点は操作にあり、データは単なるツールです。

データ操作は何を行いますか?私の個人的な理解は次のとおりです。

製品目標を設定し、データレポートチャネルとルールプロセスを作成し、製品データを観察し、データ警告を出し、データ変更の理由を分析し、分析結果に基づいて製品と操作を最適化し、将来のデータ傾向を予測して、製品の決定の基盤を提供し、データアプリケーションを製品の計画と操作に統合します。

簡単に言えば、データ操作では次の 5 つの問題を明確にする必要があります。

私たちは何をすべきでしょうか? ——対象データの定式化
現在の状況はどうですか? ——業界分析および製品データレポートの出力。
データ変更の理由は何ですか? ——データの早期警告、データ変更理由の分析。
将来何が起こるでしょうか？ ——データ予測;
私たちは何をすべきでしょうか? ——意思決定とデータの製品応用。

完全な製品データ運用システムを構築するにはどうすればよいでしょうか? Blues は、YY で働いた経験を整理してまとめました。全体のプロセスは次の 11 のステップに分けられますので、ご参考ください。

ステップ1: 製品目標を設定する

これはデータ操作の出発点であり、オンライン化された後に製品を評価するための基準でもあり、閉ループを形成します。目標を設定する際には、無作為に決めるのではなく、事業展開、業界の展開、競合製品の分析、過去の製品開発の傾向、製品の転換ルールなどの総合的な計算に基づいて最終決定を下す必要があります。 SMART 原則は目標を測定するためによく使用されます。

1. Sは特定の

つまり、作業指標は具体的かつ測定可能なものでなければならず、一般的なものであってはならないということです。例えば、YYボイスの基本エクスペリエンスという製品目標を設定したとき、それが製品エクスペリエンスの向上であった場合、それは十分に具体的ではなく、全員の理解に一貫性がありませんでした。当時の私たちの基本的な製品目標は、新規ユーザーの翌日のリテンションを高めることであり、非常に具体的でした。

2. Mは測定可能の略

つまり、パフォーマンス指標は定量的または行動的であり、これらのパフォーマンス指標を検証するためのデータまたは情報が利用可能であり、新規ユーザーの翌日の維持率を向上させるには、具体的な値を与える必要があるということです。

3. Aは達成可能の略

パフォーマンス指標は努力すれば達成できるものであり、高すぎたり低すぎたりする目標を設定することは避けるべきであるという意味です。新規登録ユーザーの翌日維持率は、気まぐれで到達するものではありません。当時、私たちはYYの新規ユーザーの翌日維持率の履歴データと、ゲームユーザーの新規登録ユーザーの維持率の業界参考値に基づいて、比較的挑戦的な目標を設定しました。私たちは新規登録ユーザーの翌日維持率を25％から35％に引き上げました。

4. RはRelevant（関連性）の略

他の仕事の目標と関連しており、業績指標は仕事と関連しており、新規ユーザーの翌日の維持率は、ユーザーの音声ツールの認識、ユーザーのYYプラットフォームのコンテンツに対する好みなど、ユーザーの行動と密接に関連しているため、新規ユーザーの翌日の維持率は製品のパフォーマンスとコンテンツの人気と強く相関しています。

5. Tは時間制限を意味します

目標を達成するための具体的な期限に焦点を当てます。

製品目標は、次のように定式化できます。2013 年 12 月 31 日までに、新規登録した YY Voice ユーザーの翌日の維持率を 25% から 35% に増加します。

新規ユーザーの翌日維持率の向上は、ユーザーのアクティブなコンバージョンの増加を意味し、全体的なアクティブユーザー数の増加につながります。

ステップ2: 製品データ指標を定義する

製品データ指標は、製品の健全な発展を反映する具体的な数値です。データの報告方法、計算式など、データ指標を明確に定義する必要があります。

例えば、上記の翌日維持率は、翌日維持率が比率であり、分母は新規登録され、同じ日にYYクライアントにログインしたYYアカウントの数であり、分子は分母のYYアカウントが翌日に再びYYクライアントにログインした数であると定義できます。

ここで詳細に注意してください。1日目と 2 日目には、0:00 から 24:00 など、1 日として計算される明確な時点が必要です。問題は、新しいユーザーが 1 日目の 23:00 に YY クライアントに登録してログインし、翌日の午前 1:00 にログオフすることです。上記の定義によると、データレポートの詳細がここで明確に定義されていないため、このユーザーは翌日の保持ユーザーとして記録されない可能性があります。

定義は、2 日目に再度 YY クライアントにログインすることです。上記のケースのユーザーは 2 日目にログインしていませんでしたが、実際には 2 日連続でログインしていたユーザーでした。

したがって、この定義には、追加の詳細が必要です。ユーザーのログインステータス、ハートビートパケットが 5 分ごとに報告される場合、新しいユーザーは翌日のログインユーザーとして報告できます。ユーザーが 00:05 より前にオフラインになり、翌日の 24:00 までログインしていない場合、そのユーザーは保持ユーザーとして記録されません。

プロダクトの目標に応じてデータ指標を選択します。例えばWebプロダクトの場合、PV、UV、クラッシュ率、1人あたりの平均PV、滞在時間などのデータを使用してプロダクトを測定することが多いです。製品指標システムを定義するには、製品や開発などのさまざまなチーム間の合意が必要です。データ指標の定義は明確で、十分に文書化されており、データ解釈の理解に違いが生じることはありません。

ステップ3: 製品データインジケーターシステムを構築する

提案されたデータ指標に基づいて、製品ロジックに従って指標を要約および整理し、より体系的にします。

新規ユーザーの翌日維持率は私たちが設定した中核目標ですが、実は翌日維持率だけを見るだけでは十分ではありません。製品の健全な発展をより正確に把握するためには、ユーザー維持率に影響を与えるさまざまな要因を総合的に検討する必要もあります。図 1 に示すように、これは新規ユーザー、アクティブユーザー、支払い、その他のデータを含む、一般的に使用される指標システムです。

図1 インターネット製品の共通データ指標システム

YY音声クライアント製品を作成する際には、アカウントシステム、関係チェーンデータ、ステータス認識データ、コミュニケーション能力などの4つの側面を含む次の指標システムを使用します。具体的な指標としては、図 2 に示すように、友人の数、チャンネルプログラムの視聴時間、IM チャットの継続時間、個人ステータスの切り替えと継続時間などがあります。

図2 IM製品データインジケータシステム

ステップ4: 製品データ要件を提案する

製品指標システムの構築は一夜にして達成されるものではありません。製品マネージャーは、製品開発のさまざまな段階に基づいて、さまざまな焦点を当てたデータ要件を提示します。一般的に、企業には製品要件ドキュメントのテンプレートが用意されており、製品とデータレポート開発、データプラットフォーム、その他の部門の同僚とのコミュニケーションを促進し、データ構築を実行します。起業志向の中小企業の場合、製品データ要件の提案から報告までのプロセスは 1 ～ 2 人だけで済む場合もありますが、データ指標の定義、データ計算ロジックなどのデータドキュメントを作成することも推奨されます。

図3 YY部門基本製品データ要件実装フローチャート（実装）

一般的なデータ報告要件は 2 つあります。

ボタンクリックレポートなどの標準プロトコルレポート。
カスタマイズされたプロトコルレポート。

1. 標準プロトコルを使用したデータ報告要件の例

表1 標準プロトコルのデータ要件を報告するためのサンプルテンプレート

2. カスタムプロトコルレポートデータ要件の例

表2 カスタムプロトコルレポートデータ要件のサンプルテンプレート

アプリケーション名: YY事業部 - 基本製品グループ - ゲームライブ運用日報

ステップ5: データを報告する

このステップでは、製品マネージャーのデータ要件に従って開発し、データレポート仕様に従い、レポート開発を完了し、データをデータサーバーにレポートします。データレポートの鍵となるのは、データレポートチャネルの構築です。私がテンセントで働いていたとき、データプラットフォーム部門がすでに完全なデータチャネルを構築していたため、このリンクの難しさを感じたことはありませんでした。開発には、特定のルールと、データレポート用の統合データSDKの使用のみが必要でした。その後、開発志向の会社であるYYで働いていたとき、レポートチャンネルの構築が始まり、より多くの実践と自己改善の機会が得られました。重要なリンクの 1 つはデータレポートテストですが、このリンクのテストリソースが不足していたために、かつては不要なトラブルが発生していました。

多くのスタートアップ企業は独自のデータプラットフォームを持っていないため、サードパーティのデータプラットフォームを使用できます。Web 製品の場合は Baidu Statistics (tongji.baidu.com) を使用でき、モバイル製品の場合は Umeng (www.umeng.com) や TalkingData (www.talkingdata.com) などのプラットフォームを使用できます。

たとえば、次の表は、Thunder Hubble データプラットフォーム仕様から派生したページトラフィックデータをレポートするための送信関数 send_web_pv を示しています。

表3 ページトラフィックデータを報告するための送信関数send_web_pv

次の表は、ライブブロードキャスト APP データレポートポイントの例です。（データ埋め込みとは、機能ロジックに統計ロジックを追加することです）

表4 ライブ放送アプリのデータ報告例

ステップ6～8: データの収集とアクセス、保存、スケジュール設定、計算

1. データの収集とアクセス

ETL は、抽出、変換、ロードの略語であり、ソースから宛先にデータを抽出、変換、ロードするプロセスを表すために使用されます。

ETL という用語はデータウェアハウスでよく使用されますが、その適用範囲はデータウェアハウスに限定されません。 ETL は、データウェアハウスの構築において重要な部分です。ユーザーは、データソースから必要なデータを抽出し、データをクリーンアップし、最後に、事前定義されたデータウェアハウスモデルに従ってデータをデータウェアハウスにロードします。

下の図は、製品データシステムの一般的なフローチャートです。データの収集、保存、計算は通常、図のデータセンターで完了します。

図4 データシステムフロー

データレポートを確認した後、次のいくつかのことはより技術的なものになります。まず、報告されたデータをどのように収集し、データセンターに保存するかを検討する必要があります。

（１）データ収集は２つのステップに分かれている

最初のステップは、ビジネスシステムからサーバーにレポートすることです。これは主に CGI またはバックグラウンドサーバーを介して行われます。統合された logAPI 呼び出しの後、元のフローデータが集約され、logServer に保存されます。データ量が多くなると、分散ファイルストレージの利用を検討する必要があります。一般的によく使われる外部分散ファイルストレージは主に HDFS です。ここでは詳細には触れません。

図 5: 生データのレポートとファイルへの保存のアーキテクチャ図

データがファイルに保存された後、 2 番目のステップは ETL ステージに入ることです。ETL とは、テキストからログを抽出、変換、ロードし、分析要件とデータディメンションに基づいてクリーンアップしてから、データウェアハウスに保存するプロセスを指します。

（２）テンセントを例に

テンセントのビッグデータプラットフォームは現在、主にオフラインとリアルタイムの 2 つの方向からの大量データアクセスと処理をサポートしています。コアシステムには、TDW、TRC、TDbank が含まれます。

図6 テンセントデータプラットフォームシステム

テンセントでは、データの収集、配信、前処理、管理はすべて TDBank プラットフォームを通じて実行されます。プラットフォーム全体は主に、大量のデータにおける大規模、リアルタイム、多様なデータの収集と処理の問題を解決するために使用されます。アクセスとストレージの問題は、データアクセス層、処理層、ストレージ層を含む 3 層アーキテクチャを通じて均一に解決されます。

（１）アクセス層

アクセス層は、さまざまな DB、ファイル形式、メッセージデータなど、さまざまな形式のビジネスデータとデータソースをサポートできます。データアクセス層は、収集されたさまざまなデータを内部データプロトコルに統合し、後続のデータ処理システムの使用を容易にします。

（２）処理層

次に、処理層はプラグインを使用して、さまざまな形式のデータ前処理をサポートします。オフラインシステムにとって重要な機能は、リアルタイムで収集されたデータを分類して保存することです。データは、特定のディメンション (キー値 + 時間など) に従って分類して保存する必要があります。同時に、オフラインシステムが指定された粒度でオフライン計算を実行できるように、保存ファイルの粒度 (サイズ/時間) もカスタマイズする必要があります。オンラインシステムの場合、一般的な前処理プロセスには、データフィルタリング、データサンプリング、データ変換が含まれます。

（３）データ保存層

処理されたデータは、オフラインファイルのストレージメディアとして HDFS を使用します。データストレージ全体の信頼性を確保し、最終的にこの処理済みデータを Tencent の内部分散データウェアハウス TDW に保存します。

図7 TDWアーキテクチャ図

TDBank は、ビジネスデータソースからデータをリアルタイムで収集し、前処理と分散メッセージキャッシュを実行し、メッセージのサブスクリプションに従ってバックエンドのオフラインおよびオンライン処理システムにデータを配信します。

図8 TDBankデータ収集およびアクセスシステム

TDBank は、データソースとデータ処理システムの間にブリッジを構築し、データ処理システムをデータソースから切り離し、オフラインコンピューティング TDW とオンラインコンピューティング TRC プラットフォームにデータサポートを提供します。現在、継続的な改善により、以前の Linux + HDFS モデルはクラスター + 分散メッセージキューモデルに変換され、1 日に処理できるメッセージの量が2 秒に削減されました。

実用的なアプリケーションの観点から、データの収集とアクセスを検討する場合、製品は主にいくつかの側面に重点を置く必要があります。

複数のデータソースの統合。実際のアプリケーションプロセスでは、通常、さまざまな形式のデータソースが存在します。このとき、収集とアクセスの部分では、これらのデータソースの統一された変換が必要です。
収集はリアルタイムで効率的です。ほとんどのシステムはオンラインシステムであるため、データ収集の適時性要件は比較的高くなります。
ダーティデータ処理: 分析と統計全体に影響するダーティデータについては、後続の統計分析とアプリケーション中にこのデータによって発生する多くの予測できない問題を回避するために、アクセスレイヤーで論理シールドが必要です。

2. データの保存と計算

データの報告、収集、アクセスが完了すると、データは保存段階に入ります。Tencent を例に挙げて説明を続けましょう。

テンセントは、社内コード名 TDW と呼ばれる、データを保存するための分散型データウェアハウスを保有しています。これは、数百 PB レベルのデータのオフライン保存とコンピューティングをサポートし、大規模で効率的かつ安定したビッグデータプラットフォームと、ビジネスにおける意思決定サポートを提供します。オープンソースソフトウェアのHadoopとHiveをベースに構築されており、大量のデータや複雑な計算など、企業特有の状況に基づいて多くの最適化と変革が行われています。

公開情報によると、 TDWはオープンソースソフトウェアのHadoopとHiveをベースに多くの最適化と変革を経て、テンセント最大のオフラインデータ処理プラットフォームとなっている。クラスター内のマシン総数は5,000台、総ストレージ容量は20PB以上、1日平均のコンピューティング量は500TB以上。テンセントのビジネス製品の90％以上をカバーしており、広東通のおすすめ、ユーザーポートレート、データマイニング、各種ビジネスレポートなど、これらはすべてこのプラットフォームを通じて基本的な機能を提供している。

図8、Tencent TDW分散データウェアハウス

図9 TDWビジネスダイアグラム

実用的なアプリケーションの観点から、データストレージ部分では主にいくつかの問題を考慮します。

データセキュリティ: 多くのデータは回復不可能であるため、データストレージのセキュリティと信頼性は常に最も重要です。必ず最大限のエネルギーと注意を注いでください。
データ計算と抽出の効率。ストレージソースとして、将来的には多くのデータクエリと抽出分析タスクに直面することになるため、この部分の効率を確保する必要があります。
データの一貫性: 保存されたデータは、プライマリサーバーとバックアップサーバー間で一貫している必要があります。

ステップ9: データを取得する

これは、製品マネージャーとデータアナリストがデータシステムからデータを取得するプロセスです。一般的な方法は、データレポートとデータ抽出です。

レポートの形式は、特に経験を積んだ企業の場合、データ要求の段階で明確にされるのが一般的です。通常、レポートのテンプレートが用意されており、それに従って指標を入力するだけです。より強力なデータプラットフォームでは、分析のニーズに応じてフィールド (テーブルヘッダー) を自分で選択して、セルフサービスレポートを構成および計算できます。

データレポートを設計するための原則は次のとおりです。

1. 連続サイクルクエリ機能を提供する

（１）レポートにはクエリの開始時刻が記載され、指定された時間範囲内のデータを閲覧できる必要があります。ある時点のデータしかなく、データの傾向が分からないのはタブーです。

（２）一定期間内のデータを細分化したり、要約したりすることができ、異なる段階を比較することができる。

2. クエリ条件がディメンションに一致する

（１）ディメンションの数だけ対応するクエリ条件を提供する。あらゆる次元の分析を満たすようにしてください。

（２）クエリ条件は、特定の値の開始、終了、フィルタリングの機能を提供する必要がある。全体像、細部、単一物を見ることができます。

（３）クエリ条件の順序は、可能な限りディメンションの順序と一致させるべきであり、降順が望ましい。

3. グラフはデータと一致している必要がある

（１）データ上の紛争を避けるために、グラフに示される傾向は対応するデータと一致していなければならない。

（２）グラフがあればデータも存在するが、グラフがなくてもデータは存在する。

（３）チャート内の指標が多すぎたり、指標間の間隔が大きすぎたりしないようにする。

4. レポートは単一のものであるべきである

（１）１つのレポートでは１つの分析機能のみを実行し、複数の機能は可能な限り異なるレポートに分離する。

（２）レポートの飛躍を可能な限り避ける。

（３）レポートはクエリ機能のみを提供します。

Baidu の WEB 商品のトラフィックレポートなど、PV、UV、新規訪問者率、直帰率、平均訪問時間などに焦点を当てた、よく使用されるレポートをいくつか見てみましょう。

では、具体的に直帰率についてお話ししましょう。このデータは、ユーザーがウェブサイトにアクセスしたときのランディングページ（必ずしもホームページとは限りません）の価値と、そのページがユーザーを一度クリックさせるほど魅力的かどうかを反映しています。ユーザーがランディングページに到達してもクリックされない場合は、直帰率が高くなります。

図10 Baidu統計ウェブデータレポート

Umeng データプラットフォームが提供する製品保持率データレポートを見ると、通常注目される保持率は、1 日後の保持、7 日後の保持、30 日後の保持です。

図11 Umengの保持データレポート

データ抽出は、売上が好調な製品とその関連フィールドのバッチを抽出したり、指定された条件でユーザーのバッチを抽出したりするなど、製品操作では非常に一般的な要件です。同様に、より完全な機能を備えたデータプラットフォームには、セルフサービスデータ抽出システムが備わっています。セルフサービスのニーズを満たせない場合は、データ開発者がデータを抽出するためのスクリプトを作成する必要があります。

図 12 に示すように、Tencent の社内データポータルは、多くの製品のデータレポート、データ抽出、およびデータレポート機能を担当しています。

図12 テンセントデータポータルホームページ

ステップ10: データの観察と分析

ここでの主なタスクは、データの変化の監視と統計分析です。通常、データの日次レポートを自動的に出力し、異常なデータをマークします。データの視覚的な出力は非常に重要です。

よく使われるソフトはEXCELとSPSSで、データ分析の基本スキルともいえます。この2つのソフトを実際の業務でどのように活用しているか、私なりのやり方やテクニックを後ほどシェアしたいと思います。データ分析を実行する前に、まずデータの正確性を検証して、データが目的のものであるかどうかを判断する必要があることに注意してください。たとえば、データ定義とレポートロジックが要件ドキュメントに厳密に準拠しているかどうか、データレポートチャネルでデータ損失の可能性がないかどうかなどです。データの正確性を判断するには、元のデータを抽出してサンプリングすることをお勧めします。

このリンクでは、データの解釈が非常に重要です。製品の知識や分析経験の違いにより、同じデータでも解釈結果が大きく異なります。したがって、製品アナリストは製品とユーザーについて十分に理解している必要があります。

絶対値は解釈するのが難しい場合が多く、データの意味は通常、比較によってより適切に表現できます。

例えば、ある商品がオンラインになって最初の1週間は、1日平均の新規登録数が10万件で、これは良いデータのように思えます。しかし、この商品がYY Voiceが発売した新商品で、YYポップアップメッセージを通じてユーザーにリーチし、毎日数千万のユーザー露出があるのに新規ユーザーが10万件しかない場合、これは良い商品データとは言えません。

図13: 比較によるデータの意味の明確化

縦方向の比較では、例えば、新規登録したYY Voiceユーザーのデータの変化を分析する場合、先週の同時期、先月の同時期、昨年の同時期と比較して、同様のデータ変化パターンがあるかどうかを確認できます。
水平比較では、ファネルモデルから新しい YY Voice ユーザーの登録データの変化を分析し、ユーザーがアクセスしたさまざまなチャネルを調べて、各チャネルのコンバージョン率が変化したかどうかを確認できます。たとえば、最上位のファネルでは、ユーザーアクセスチャネルに大幅に変化したデータがあるかどうか、チャネル内のどのリンクでコンバージョン率データが変化したかを確認できます。また、YY Voice の新規登録データ、Duowan.com のトラフィックデータ、YY Game の新規登録ユーザーデータを比較するなど、さまざまなビジネスを横方向に比較して、データの変更理由を調べることもできます。
垂直比較と水平比較の組み合わせは、YYの新規登録ユーザーの6か月間のデータの変化、Duowan.comのトラフィックデータ、YYゲームの新規登録ユーザーなど、同じ期間の複数のデータの変化の曲線を比較することです。 3つの曲線を同時に比較して、特定のデータ異常のキーノードを見つけ、操作ログを調べて、操作アクティビティの組織化、外部イベントの影響、特別な日の影響要因があるかどうかを確認します。

ステップ11: 製品評価とデータの適用

これはデータ運用のクローズドループの終点であり、また新たな出発点でもあります。データレポートは、決して単に表示するだけのものではなく、リーダーからの質問に答えるためのものでもないのです。むしろ、製品の最適化と運用の実行に役立ちます。製品担当者のパフォーマンスと同様に、製品プロジェクトが期限内に完了してリリースされるかどうかだけでなく、製品データを継続的に観察・分析し、製品の健全性を評価し、蓄積されたデータを製品の設計と運用に適用することも重要です。

データ製品のアプリケーションは、おおまかに次のカテゴリに分類できます。