運用データの埋め込み（データの埋め込みをどのように設計するか？）

データ埋め込みポイントをどのように設計するのでしょうか?

データ分析の目的は、特定のビジネス シナリオにおけるビジネス上の問題を解決することです。データポイントを埋め込むことでデータ分析の品質を向上させることができます。では、データ埋め込みポイントをどのように設計すればよいのでしょうか?この記事では、データ追跡の関連プロセスをまとめており、皆さんの参考になれば幸いです。

企業のビジネス目標をより効果的に達成するために、ユーザー エクスペリエンスはますます重要になっています。多くのインターネット企業はUED部門を設立し、UE設計仕様システムとUI設計仕様システムを構築するでしょう。しかし、実際に商品を宣伝してビジネス目標を達成する過程で、この 2 つのシステムだけでは不十分であることがわかります。これら 2 つの標準システムは、主に社内の開発コラボレーションの効率を向上させることを目的としているためです。これらは、製品ブランドの一貫性をある程度向上させるのに役立ちますが、それだけでは十分ではありません。

そこで、多くのグループ会社では、「UE設計仕様システム、UI設計仕様システム、データポイント仕様システム」の3つからなるクローズドループ仕様システムを構築します。

データ追跡仕様システムを構築することで、データ追跡の標準化を維持し、データ追跡開発の速度と品質を向上させ、データ分析能力の一貫性を維持し、データ分析の品質を向上させることができます。同時に、操作プロセスにおけるユーザーの妨害、注文プロセスにおけるユーザーの中断など、特定のビジネス シナリオにおけるビジネス上の問題をより適切に監視および解決し、反復のための有効な基盤を収集し、ビジネス目標とユーザー エクスペリエンスを改善するための方向性を示すことができます。

データ分析では、「エンドツービギン」ソリューションを採用する必要があります。データ分析の目的は、特定のビジネス シナリオにおけるビジネス上の問題を解決することです。ビジネス上の問題は、データの問題に変換され、それに基づいて分析フレームワークが構築される前に、「ビジネス目的」に基づいて複数のサブ問題にさらに細分化される必要があります。

(企業によってはデータ分析の専任職者がいるところもありますが、プロダクトマネージャー、ユーザーエクスペリエンスデザイナー、ビジネスデマンダーがこの役割を担っているところもあります。この記事では、一貫して「データアナリスト」と表記します)

データ収集ポイント分析は、データ収集の一般的な方法であり、データ収集が必要な「操作ノード」の機能プログラムコードにデータ収集プログラムコードを添付し、操作ノード上のユーザーの行動やイベントに関する関連技術とその実装プロセスをキャプチャ、処理、送信することを指します。データ収集は、プライベート展開でデータを収集するのに適した方法です。

データの埋め込みは、初級、中級、上級の3 つのタイプに分かれています。

主なポイント:製品やサービスのコンバージョンの重要なポイントに統計コードを埋め込み、独立したID（購入ボタンのクリック率など）に基づいてデータ収集が繰り返されないようにします。

中級:プラットフォームの各インターフェースにおけるユーザーの一連の行動を追跡するための複数のコードを埋め込み、イベントは互いに独立しています (製品の詳細ページを開く、製品モデルを選択する、ショッピングカートに追加する、注文する、購入を完了するなど)

上級:会社のエンジニアリングおよび ETL と連携して、すべてのユーザー行動を収集および分析し、ユーザー ポートレートを確立し、製品分析と最適化の基礎としてユーザー行動モデルを復元します。

データ トラッキングは、ユーザー データの製品およびオペレーティング システムの統計分析を容易にする、一般的に使用されるデータ収集方法です。商品購入やソフトウェア操作の過程でユーザー行動データを収集し、追跡ポイントを通じてレポートすることで、その後のユーザー行動の分析やユーザーの嗜好の把握に役立ちます。

データ追跡が適切に行われれば、ビジネス上の問題を分析して迅速に結論を導き出すことが容易になり、ビジネス目標を達成してクローズドループを形成するための意思決定をビジネス関係者が行うのを支援できます。

データの埋め込み方法は、その場所に応じてフロントエンド埋め込みとバックエンド埋め込みに分けられます。

フロントエンドのトラッキング ポイントは SDK を通じてデータを収集します。データ トラフィックを削減するために、収集されたデータは通常、圧縮され、一時的に保存され、レポート用にパッケージ化されます。リアルタイムで報告する必要のないイベントについては、通常、Wi-Fi 環境でのみ報告されるため、データの報告に遅延や欠落が生じます。

バックエンドトラッキングは、API（アプリケーションプログラミングインターフェース）を呼び出して情報を収集し、イントラネットを使用して情報を送信します。基本的にネットワーク上の理由によるデータ損失は発生しないため、バックエンドから送信されるデータはユーザーの行動を非常にリアルに反映できます。

理論的には、クライアントがサーバーにリクエストを送信する限り、サーバーの埋め込みポイントは対応するデータを収集できます。フロントエンドトラッキングと比較して、バックエンドトラッキングはリアルタイムでデータを収集でき、レポートの遅延がなく、データが非常に正確です。さらに、バックエンド トラッキングは、ユーザー ID 情報や行動属性情報との統合をサポートします。さらに、新しいトラッキング ポイントが起動または更新されるたびに、そのトラッキング ポイントはリリース後すぐに有効になります。

ウェブサイトやアプリは、デバイスのハードウェア情報、ソフトウェアの機能、データのアクセス許可、ユーザーの行動という4 種類の情報をユーザーについて収集できます。

1. デバイスのブランド、モデル、マザーボード、CPU、画面解像度などのデバイスのハードウェア情報。

2. ソフトウェア機能：Webページやアプリをクリックしたり、画面を水平または垂直に切り替えたり、スクリーンショットを撮ったり、シェイクしたりしなくても、データが記録されます。

3. データ許可: 新しいソフトウェアを登録するときに、写真アルバム、アドレス帳、GPS などの個人情報を許可するようユーザーに求めるページがポップアップ表示されます。ユーザーが許可に同意すると、Web ページまたはアプリはこの情報を収集できるようになります。

4. ユーザーの行動: ユーザーが Web ページまたはアプリ上で操作している限り、その行動は記録されます。

ウェブサイトやアプリはユーザーの許可を得てさまざまな種類のユーザーデータを収集できますが、データ追跡ドキュメントを作成する際に大規模かつ包括的なデータ追跡を追求する必要はありません。ビジネスニーズドキュメントに従って、対応する動作を記録するだけで十分です。

データ追跡は、データ ガバナンス プロセスの重要な部分です。複数の部門間の連携が必要な作業です。データアナリストはプロセス全体において重要な役割を果たします。データ アナリストは、データ ニーズ評価段階からデータ適用段階まで参加する必要があります。

データ追跡の作業では、現在のデータニーズに基づいて、データ指標計画を改良し、これらの指標に必要なデータが何であるかを考える必要があります。これらのデータは必要な追跡ポイントです。

もちろん、これらは単なる予備的な追跡ソリューションにすぎません。追跡をより「正確」かつ「完全」にしたい場合は、ユーザー パスなどの他の方法が必要になります。予備的な追跡ポイント計画が作成された後、時間トリガー メカニズムとレポート メカニズムを決定する必要があります。メカニズムが異なると、統計的な基準も異なるためです。

新規の取引先の場合、統計的基準の不一致による誤解を避けるために、統計指標は以前の基準と一致し、水平比較が容易になるようにする必要があります。

さらに、さまざまなプロジェクト間でフィールド名とテーブル構造を統一することも重要なタスクであり、このステップもデータ ガバナンス プロセスの重要な部分です。これらの手順を完了すると、予備的な追跡計画が完成します。

その後、ビジネス側とフロントエンドエンジニア、バックエンドエンジニアとの議論を重ねてトラッキングドキュメントを修正・改善し、フロントエンドエンジニア、バックエンドエンジニアに渡してトラッキングを実施します。この期間中、データ アナリストは、テスト環境のデータを通じて、現在の追跡に問題がないか確認する必要があります。問題があれば、この段階で修正することができます。問題がなければ、追跡イベントをオンラインで展開できます。

イベントとは、製品内の機能またはユーザーによる操作を指し、変数とは、イベントを説明する属性または主要な指標を指します。確認されたイベントと変数は、AARRR（獲得、活性化、維持、収益、紹介）モデルやUJM（ユーザージャーニーマップ）モデルを通じて段階的に分解され、ユーザーのライフサイクルと行動パスが明確になり、各ステップの重要な指標が抽象化されます。 （これら3つのモデルは新しい記事で個別に分析されます）

トリガーのタイミングが異なるとイベントの計算能力も異なるため、トリガーのタイミングはデータの精度に影響を与える重要な要素となります。両者は口径が異なり、データも必ず異なるため、イベントの発生条件を明確にすることが非常に重要です。

ユーザーの支払いを例にとると、トリガー条件はユーザーが支払いインターフェースをクリックすることでしょうか、それとも支払いが成功することでしょうか?ユーザーの支払いの例では、ユーザーの支払い動作を記録するために 2 つのフィールドを使用することをお勧めします。1 つのフィールドは支払いインターフェースをクリックする動作を記録し、もう 1 つのフィールドは支払いが成功したかどうかを記録します。

報告メカニズムもデータの正確性に影響を与える重要な要素の 1 つです。クライアントから報告されたデータは、ネットワーク接続の問題により失われる可能性があります。データ追跡作業を完了する際に、データアナリストは、データがリアルタイムで報告されるか非同期で報告されるかを判断して、データ追跡が妥当かどうかを判断し、データ追跡計画をタイムリーに調整する必要もあります。

統一されたデータ テーブル構造により、チーム内でのデータ管理とデータの再利用が容易になります。チーム内で統一されたデータ構造仕様のセットを形成することをお勧めします。たとえば、テーブルはさまざまなレベルに分かれています。最初のレベルには、ユーザー、地域、ニックネームなどのユーザーの基本情報が記録されます。 2 番目のレベルでは、ユーザーの行動情報が記録されます。

統一されたデータ テーブル構造仕様を持つだけでは不十分です。統一されたデータ命名仕様も、データ追跡作業の重要な部分です。条件が許せば、データ命名標準を統一するためにデータ辞書を確立することができます。たとえば、すべてのデータ テーブルで同じ変数に同じフィールド名が付けられていることを確認します。消費額フィールドの場合、データ アナリストは、消費額が表示されるたびにすべてのテーブルで Amount フィールド名が使用され、money や payment などの他のフィールド名が回避されることを望みます。

会社内やチーム内で命名基準を確立することは非常に重要です。物に名前を付けるには、動詞 + 名詞、または名詞 + 動詞のルールを使用できます。たとえば、「カートに追加」イベントには addTocart という名前を付けることができます。

データ追跡はデータアプリケーションへの道を開きます。データ ポイントを追跡した後、データ アナリストは指標システムとデータ レポート システムを構築するというタスクに直面する場合があります。レポートの優先度、追跡テクノロジ、実装コスト、限られたリソースに基づいて、データ追跡の優先度を決定できます。

実際の例を以下に示します。

以前は、某グループ会社にて、ECデータ埋め込みポイントの設計を担当しておりました。同社には多くのサブブランドとさまざまな事業ラインがあります。当時私たちが行っていた埋め込み設計は、主に商標取引業務を対象としていました。

（１）需要背景

商標データベースには 100 万件を超える商標が登録されています。しかし、従来の商標ソートアルゴリズムの不合理な仕組みにより、クリック行動がソートにおいて大きなウェイトを占め、長期間販売されていない商標が上位にランク付けされる結果となりました。手動操作が必要であり、時間と労力がかかります。この問題を解決するために、当時は時間減衰モデルが設計されました。同時に、この事業ラインでは、製品を各個人にインテリジェントに推奨できるようになることも期待していました。

（２）データ追跡設計プロセスの概要

（３）データ追跡プロセスの実践的な手順

①イベントと変数を確認する - UJMモデルを通じてユーザーの購入経路を分割する

ユーザーの購入経路は、登録、ログイン、商品の表示、商品のクリック、ページの詳細の閲覧、ショッピング カートに追加、注文の生成、注文の支払いなどのステップに分かれています。製品マネージャーが提案したデータ要件に基づいて、データ要件を満たすために各ステップに必要なフィールドを決定します。

②トリガー機構の確認

ボタンがクリックされたとき、またはユーザーがステップを完了したときにアクションを記録するかどうかを明確にします。

③確認・報告の仕組み

データ レポート メカニズムがリアルタイム レポートか非同期レポートかを指定します。異なるレポートメカニズムでは異なるフィールドが収集される場合があり、記録のためにフィールドを異なるテーブルに分割する必要がある場合があります。

④フィールド名の統一

ビジネス データ セット内の同じ変数は、すべてのデータ テーブルで同じフィールド名を使用します。たとえば、account_id はユーザー ID に使用され、region はユーザーの国に使用され、ip_region はユーザーの地域に使用されます。

⑤ テーブルレベルの統一構造

多層データテーブル構造が使用されます。第 1 層には一般情報、第 2 層には基本的なユーザー情報、第 3 層にはユーザー行動情報が格納されます。テーブルレベルの構造は、チーム内のデータアクセス仕様に応じて調整でき、統一された構造を採用できます。

⑥ 優先順位を明確にする

追跡ニーズの緊急性に応じて、各追跡タスクの優先順位をマークします。上記の 6 つのステップに従って、各ステップで記録する必要があるフィールドが標準形式のドキュメントにまとめられ、予備的な追跡ポイントの設計が完了します。その後は、プロダクトマネージャー、プランナー、フロントエンドエンジニア、バックエンドエンジニアと何度も議論を重ね、3者の合意が得られるまで継続的にドキュメントを修正・改善し、最終的にドキュメントを葬り去る必要があります。

一般的に、需要はビジネス側から開始され、製品マネージャーまたは運用部門が独自のビジネスシナリオに基づいてコア指標と分析要件を明確にします。製品データ指標システムを構築する際には、「コア」シナリオに特に注意し、コア指標を優先する必要があります。ニーズを明確に分析した上で追跡ソリューションを設計します。

データチームが主導し、要件を提起したビジネス関係者と開発チームが参加するよう求められます。ソリューション設計がビジネス要件を満たしているかどうかを需要側に確認するとともに、開発チームがビジネスコンテキストを十分に理解し、需要開発の実現可能性を確認していることを確認する必要があります。需要レビューは複数回開催する必要がある場合がありますが、開発フェーズに入る前に、ビジネス側 (マーケティング、オペレーション、製品マネージャーなど)、データ プランナー (データ製品、データ アナリストなど)、開発者の間で合意に達する必要があります。

（専任のデータ分析担当者がいない場合は、ユーザー エクスペリエンス デザイナー、プロダクト マネージャー、または需要側がこの役割を担うことができます）

プログラム実行フェーズでは、データ チームと開発チームが協力する必要があります。データ チームは、分析プラットフォームのデータ管理モジュールで対応する構成を行う必要があります。たとえば、データ管理モジュールでは、追跡イベントと関連変数を構成します。開発チームは、追跡ポイント計画に基づいて追跡ポイントの実現可能性とスケジュールを確認し、対応するコード展開を実行し、追跡ポイントの開発、テスト、起動を担当します。

開発チームが開発とテストを完了した後、データ チームは正式な展開の前にデータを検証する必要があります。データを検証するときは、データ トリガーのタイミングが正しいことと、エントリが完全にカバーされていることを確認することに重点を置きます。

追跡ポイントが起動されると、ビジネス側とデータチームはデータ分析プラットフォームを使用して、報告された追跡ポイントデータを監視および分析できます。

3 つの当事者はプロセス全体を通じて相互に協力する必要があります。明確なコラボレーション プロセスが欠如していると、追跡サイクルが長くなったり、追跡結果が見逃されたり、間違った結果になったりする可能性があります。追跡ポイントの品質と効率を向上させるには、チームワークが不可欠です。コラボレーション プロセスを明確にし、プロセスにおけるすべての関係者の責任を標準化することをお勧めします。

1. 製品の目標と主な課題を明確にし、深いレベルと具体的なニーズから整理します。

2. 同一階層ページに対する操作や同一ページ上の複数のソースは 1 つのイベントとなり、異なる操作内容やページソースはイベントの属性として収集されます。

3. 分析の初期段階で重要なユーザー行動を少量収集し、結果を迅速に取得します。

4. コアプロセスでは、ユーザー行動の各ステップのデータを取得する必要があります。

5. データの統計的品質を明確に決定し、開発チームと良好なコミュニケーションを維持して、データポイントの具体的な収集タイミングを開発チームに伝える必要があります。

6. 追跡が完了したら、追跡から返されたデータがあるかどうかだけでなく、データの存在と正確性を検証する必要があります。

7. 一度に全方向の追跡を実行しないでください。これは膨大な作業負荷となり、大量のデータが干渉や混乱を引き起こすことになります。段階的およびバージョン的に追跡を実行することをお勧めします。

データ分析の結果については、データについての結論を出すだけで十分か、それとも分析レポートを作成する必要があるのか​​を検討する必要がありますか?データレポートを提供するだけで十分ですか、それとも BI オンラインレポートにする必要がありますか?作業が深くなるほど、より多くのエネルギーとコストがかかり、より価値の高いサポートが必要になります。データ分析結果を出力する際に​​は、需要配信目標を制御し、それを値と一致させることが重要です。

（１）過度な努力を避ける：企業は指標をざっと見るだけで、完全な分析レポートを受け取ることができました。

（２）期待を下回ることを避ける：ビジネス部門はアナリストの結論と提案から機能の反復の方向性を見つけることを期待しているが、結果データを提示するレポートしか受け取らない。

あらゆる形態の製品は、最終的には市場とユーザー (顧客) のテストに耐えることができなければなりません。データ分析は、製品の商業的価値を実現するのに役立つ重要なツールの 1 つです。ツールが効果的か使いやすいかは、ツール自体ではなく、主にそれを使用する人によって決まります。私たち全員がこのツールを活用して、当社の製品がビジネス目標をより効果的に達成できるよう願っています。

コラムニスト

Xin Yun 氏は、「Everyone is a Product Manager」のコラムニストです。 BサイドやSaaSプロダクトを中心に、ユーザーエクスペリエンスデザイン、インタラクションデザイン、ユーザーリサーチ、データ分析、プロジェクトマネジメントなどのスキルを得意とする。

この記事はもともと「Everyone is a Product Manager」に掲載されました。無断転載は禁止です。

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

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。