データ消費
セッションリプレイは、他のbrowserバイトと同じ消費価格設定に従います。 生成されるバイトの量は、セッションの数、長さ、ユーザー アクティビティ レベル、およびサイトの DOM の複雑さによって異なります。
リプレイあたりのコストを予測する最も正確な方法は、短いテスト期間で機能を有効にして、実際の消費量を測定することです。 あるいは、リプレイ 1 回あたりの平均 5.3 MB を大まかな概算として使用することもできますが、実際のコストは大幅に異なる可能性があることに留意してください。 おおよそのコストを予測する簡単な式は次のとおりです: sessions x sampling_rate x gb_per_replay x cost_per_gb 。
次の例を見てみましょう。
100 万 (セッション) x 5% (サンプリング レート) x 0.0053 (再生あたりの GB) x 0.35 ドル (GB あたりのコスト) = 50,000 回の再生で 92.75 ドル
消費量を制御するには、 サンプリング レートを調整します。
ユーザーのプライバシーとセキュリティに関する懸念
当社はデータのプライバシーを最優先し、強力なデフォルト設定でセッションリプレイを構築して、機密性の高い顧客情報の漏洩の可能性を最小限に抑えます。 特定のニーズに合わせてプライバシー設定をさらにカスタマイズできます。
セッションリプレイではスクリーンショットやビデオはキャプチャされません。 代わりに、ユーザー インタラクションを再構築するために必要な重要なDOM状態の変更のみを記録します。 これにより、保存されるデータの量が大幅に削減されます。
データプライバシー法の遵守
New Relic GDPRの下ではデータ プロセッサとして、CCPA の下ではサービス プロバイダーとして機能します。 つまり、お客様の指示に従ってデータを処理することになります。 最終的に、これらの法律に準拠できるかどうかは、アプリケーション内でセッションリプレイをどのように実装するかによって決まります。
デフォルトでは、個人データを含むすべてのテキストとユーザー入力は録画内でマスクされます。 必要に応じて特定の要素を選択的にマスク解除できますが、デフォルトでは個人を特定できる情報がすぐに表示されないようになっています。 このアプローチは、データ プライバシーの強力な基盤を提供し、同時に特定のニーズに柔軟に対応します。
セッションリプレイとアプリのパフォーマンス
セッションリプレイは、次のようにしてアプリケーションのパフォーマンスへの影響を最小限に抑えます。
初期影響を最小限に抑える: セッションリプレイはページ全体の読み込み後に非同期で読み込まれるため、初期のページ読み込みパフォーマンス メトリクスに干渉しません。
DOM 変更追跡: ロードされると、セッションリプレイ モニター DOM の変更が圧縮ペイロードとして報告されます。 これらのペイロードのサイズは、DOM ツリーの複雑さと相関します。
パフォーマンスの最適化手法: DOM が大きい場合、ペイロード サイズも増加する可能性があります。 ただし、セッションリプレイはペイロード サイズを削減するために次のようなさまざまな手法を使用します。
GZIP圧縮
重複の削減
戦略的なペイロード収集: 大きな (圧縮された) ペイロードは、完全な DOM がキャプチャされた場合にのみ送信されます。これは通常、再生機能が最初にインポートされたときに発生します。 その後、ユーザーのアクションに関連する小さなペイロードのみが送信されます。 ブラウザエージェントは、次の条件の最初の発生に基づいてデータを収集します。
- ペイロードは圧縮すると 64 KB を超えます。
- 60秒が経過します。
- ページの可視性が変更されます (例: タブの変更、フォーカス、ナビゲーション)。
- セッションが終了します。
主な変更点:
- 明確さ:読みやすさを向上させるために文の構造を改善しました。
- 簡潔さ:冗長な単語やフレーズを削除しました。
- 一貫性:統一性を保つために、リストに並列構造を使用しました。