背景#
組内で担当している製品ページの主なトラフィック経路は、グループ内の各アプリからのものであり、その中で重要な指標の 1 つは到達率です。
到達率の計算方法：リソースのクリックからページの表示までの回数 / リソースのクリック回数
- リソースのクリックはネイティブ側のトラッキングであり、BI はマテリアルの名前に基づいて対応するビジネスを判断します。
- ページの表示は Web H5 側のトラッキングであり、通常は
mountedライフサイクル内に設定されます。
最近、到達率の低下に関するフィードバックを多く受け取っており、いくつかのケース分析を行った結果、原因は主に以下のいくつかの要素にあることがわかりました：
- ユーザーの意図 / 疲労度の問題
- BI の統計の問題、分子 / 分母の計算ミス
- ページの読み込みが遅い
今後同様の問題に直面した場合に、既存の統計データを使用してユーザーの離脱ポイントを直感的に確認し、問題の分析と特定をより効果的に行うために、既存のユーザーパスを分析する必要がありました。そのため、調査を行い、以下に記録します。
調査#
既存のユーザーパスの表示方法は、内部のモニタリング統計プラットフォームの個人診断パスで行われます：
- まず、異なるエンドを選択すると、異なるトラッキングデータテーブル（ネイティブと H5 を区別）を参照します。
- 次に、ユーザー ID + 時間を入力し、対応するページを選択し、イベントをフィルタリングして結果を簡素化することができます。
- 最後に、報告された時間に基づいて、そのユーザーの対応する時間内のすべての関連する操作トラッキングを直接表示します。
個人診断パスの核心ロジックは、時間を基準とした全操作トラッキングを検索するための個別のユーザー識別子に基づいています
一方、行動パスの統計表示には、論理的な順序で漏斗データを計算するための固定された操作トラッキングが必要です。つまり、明確な順序があり、適切な統計次元を持つ重要なトラッキングが必要です。そのため、個人診断パスツールでは統計のニーズを満たすことができません。
ユーザーがリソースをクリックしてからページが表示されるまでの行動パスは、端内での Web ビューのオープンと H5 の読み込みから表示までです。
この行動パスに基づいて、関連するトラッキング SDK のメンバーに相談した結果、以下の結論に達しました：
- ネイティブ SDK と H5 SDK のパスは、明確な順序がない（コンポーネントのライフサイクルとページのライフサイクルに類似）ため、片方のデータを基にモニタリングするしかありません。
- ネイティブ SDK
- 標準のトラッキングには、H5 ページを開く - H5 ページの読み込みを開始する - H5 ページの読み込みが完了する、というものがありますが、現時点ではサポートされていません（今後のリリースに依存）
- 既存のトラッキングには、特定のページに入る - 特定のページから退出する、というものがありますが、トリガータイミングが広範囲です（アプリの開閉、アプリ内のページ切り替え、バックグラウンドとフォアグラウンドの切り替えなどが含まれます）、適切な統計次元がありません
- 左上の戻るボタンなどの重要なトラッキング：直接的なトラッキングはありません。SDK の自動収集レポートの統一トラッキング：コントロールのタイプ名 + コントローラの名前 + トリガーメソッド名を条件として選択する必要がありますが、クエリのコストが高く、安定しておらず、適切な統計次元もありません
- まとめ：ネイティブの既存のパスには適切なモニタリングポイントがありません
- H5 SDK
- 標準のトラッキングには、H5 ページの初期化 - H5 ページの表示（onLoad 後）があります。具体的なビジネス関連情報には、アクセスページの完全なリンクとページのルーティングがあります。inrouter やチャネル番号などの情報を使用して、あいまいなマッチングを行うことができます。
- 既存のファネル分析機能を利用して到達率を簡単に計算できます。
- まとめ：H5 の既存のパスにはモニタリングポイントがありますが、効果は限定的です
結論#
短期的な解決策：H5 の初期化 - 表示のファネル変換率は技術的にモニタリングできるため、補助的な観察を行います。
長期的な解決策：ネイティブのリリース後にネイティブ側のパスモニタリングを行い、同時に戻るボタンのクリックなど、よりビジネス上の意義のある指標である離脱率などのトラッキングを推進します。