サーバーvsクライアント整合性チェック
お客様が Zenovay の数値を GA4、Stripe の領収書、または自社バックエンドのログと比較し、数値が一致しないことに気づくケースは少なくありません。Zenovay の方が多いこともあれば、少ないこともあります。正直なところ、Zenovay を含む すべての アナリティクスツールは、ブラウザに届いたもの、サーバーに届いたもの、Webhook で確認されたものに基づく推定値を返しています。
整合性チェックは、その差を「ないことにする」のではなく、信頼度ラベル付きで定量化する Zenovay の仕組みです。
何を比較するか
整合性チェックは、ウェブサイト・メトリック種別・日ごとに 3 つの真実の層を比較する日次ジョブとして動作します:
| 層 | 何を測定するか | どこに格納されているか |
|---|---|---|
| クライアント | ブラウザトラッカーが発火したイベント | page_views, user_events(source = 'browser') |
| サーバー | POST /api/v1/events 経由で取り込んだイベント | 同じテーブル(source = 'server') |
| Webhook | Stripe / LemonSqueezy / Polar の Webhook 確認 | payment_events(status = 'succeeded') |
各 (ウェブサイト, 日, メトリック) の三つ組について、各層が見たイベント数、一致した件数、推定損失率、固定リストから選ばれた主要なミスマッチ理由を記録します。
V1 の 3 つのメトリック種別
V1 では、明確な真実の層を持つ 3 つのメトリックを対象とします:
- ページビュー — クライアント(ブラウザ)vs サーバー(
POST /api/v1/events) - 目標完了 — クライアント側目標イベント vs サーバー側目標イベント
- 収益イベント — クライアント側購入イベント vs Stripe Webhook 真実(
payment_events)
カスタムイベント、identify 呼び出しなど他の種別は V1 の対象外です — 比較できる真実の層が存在しないためです。
損失の推定方法
ページビューと目標では真実の層は server_count です。収益では webhook_count が真実の層となります(決済プロバイダの Webhook が真実の出どころ — 実際に顧客に課金したのは Webhook 側の事実です)。
推定損失 = (真実 - クライアント) / 真実 × 100
負の値も許容されます: サーバーがブラウザトラッカーよりも 多く のイベントを捕捉した場合、それも情報です — トラッカーが取り逃したイベントをサーバー側取り込みが拾ったということで、両方を運用する目的そのものです。
信頼度ラベル
各整合性レコードには 3 つのラベルのいずれかが付与されます:
| ラベル | 適用条件 |
|---|---|
| 高信頼度 | 両層がそれぞれ 100 件以上のイベントを持ち、推定損失が 30 % 未満。 |
| 中信頼度 | いずれかの層が 50–100 件の範囲、または損失が 30–60 % の範囲。 |
| データ限定的 | いずれかの層が 50 件未満、損失が 60 % 超、または片方の層しか存在しない。 |
「データ限定的」は修正すべき問題ではなく、サンプルが小さすぎる、または片寄っているために確信を持って結論を出せないことを示します。信頼度ラベルは Trust ビューを「分かっていることだけを言う」誠実な状態に保ちます。
ミスマッチ理由
整合性チェックが意味のあるギャップを検出すると、検出優先度順に並べた 7 つの理由から 1 つを選びます:
| 理由 | 検出ルール | 対処可能? |
|---|---|---|
webhook_delay | クライアント > Webhook が ≥20 % かつ当日の Webhook 件数が直近 6 日間平均より ≥2σ 低い | ✓ |
client_blocked | サーバー > クライアントが ≥10 % | ✓ |
route_mapping | 上位 1–2 ルートがギャップの ≥50 % を占める | ✓ |
duplicate_suppression | 取り込みパイプラインが当日中にブラウザイベントを重複排除した | 情報のみ |
id_stitching | 訪問者セグメント間で未マッチのクライアントイベント数の分散が大きい | 情報のみ |
no_server_layer | server_count = 0 かつ client_count > 0 | 情報のみ |
unknown | どの閾値にも到達しなかった | 情報のみ |
3 つの理由は 対処可能 です — 対処はお客様側で行います(CSP の修正、SDK のリトライ設定、Stripe Webhook 配信状況の確認)。残りの 4 つは診断コンテキストです。
どこで見るか
app.zenovay.com の任意のドメインダッシュボードを開き、Trust タブを選択してください。以下が表示されます:
- 直近 7 日間の推定トラッキング損失と信頼度ラベル
- メトリック別(ページビュー、目標、収益)の内訳: クライアント / サーバー / マッチした件数と、ギャップを完成度バーの斜線部分として可視化
- イベント影響度順の主要ミスマッチ理由と、対処可能なものへの推奨アクション
- (Pro 以上)ルート別ドリルダウンテーブルで、ギャップに最も寄与しているルートを表示
これは何ではないか
- 正しさの保証ではありません。計測の品質を計測したものです。
- ギャップを修正する試みではありません。修正(CSP の設定、Webhook の設定、ルート正規化)はお客様側の作業です。
- お客様が使っていない第三者サービスやベンダーには言及しません。ミスマッチ理由は汎用的に保ち、どのスタックでも推奨アクションが意味を持つようにしています。
- 新しいデータ収集を作りません。整合性チェックは既存の
page_views,user_events,payment_events行を読むだけ — 新しい Cookie もなく、新しい識別子もなく、Cookieless トラッキングの保証は変わりません。
プラン別の利用可否
Trust タブ自体はすべてのプランで利用可能です。ルート別ドリルダウンと対処可能な理由のアクション手順は Pro 以上で利用可能です。 Free では集計値と理由名のみが表示され、ルートレベルの詳細は表示されません。
関連概念
- 直帰率 — 整合性チェックのコンテキストで意味が増える品質シグナル
- サーバーサイドイベント取り込み — 整合性チェックのサーバー層を支える
POST /api/v1/eventsエンドポイント - Cookieless トラッキング — インメモリトラッカーが古い識別子で整合性チェックを汚染しない理由