「数字がズレる」問題に終止符を。マーケ×dbtでCV/商談化指標をコード管理し、信頼できるデータ基盤を構築

「マーケティング部門が報告するCV数と、営業部門が管理する商談数が一致しない」「BIツールの数字とSalesforceの管理画面が常に数%ズレている」。BtoBマーケティングの実務において、この「数字の不一致」は意思決定を鈍らせる最大のボトルネックです。

本ガイドでは、日本最高峰のデータ基盤構築の実務知見に基づき、dbt（data build tool）を活用してCVや商談化指標をコードで一元管理し、信頼できるデータ基盤を構築する具体的な手順を解説します。

1. 「数字のズレ」を根本から断つ、マーケティングデータ基盤の設計思想

1.1 なぜ従来の集計手法ではCV数や商談化率が乖離するのか

多くの場合、数字がズレる原因は「集計場所の分散」にあります。広告媒体、Google アナリティクス 4（GA4）、Salesforce、そしてスプレッドシート。それぞれのツールが独自のタイムゾーン、独自のコンバージョン定義（ラストクリック、ファーストクリック等）で計算を行うため、結果が一致することはありません。

1.2 Excel・BIツール内計算の限界

BIツール（TableauやLooker）の計算フィールドで指標を定義すると、そのツールを使える人にしかロジックが分かりません。これが「ロジックのブラックボックス化」です。指標定義をツールから切り離し、SQLコードとして共通管理する必要があります。

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

2. dbtを中核としたモダンデータスタックのツール選定と比較

信頼できるデータ基盤（モダンデータスタック）を構築するには、データの「運搬」「蓄積」「変換」を担う最適なツール選定が不可欠です。2026年現在の主要スペックを比較します。

3. 【実践】dbtによるCV/商談化指標のコード管理ステップ

dbtを用いて、生データを信頼できる指標へと変換する3つのレイヤー構造を構築します。

3.1 Staging層：生データのクレンジング

Salesforceの Opportunity テーブルやGA4のイベントデータをそのまま使うのではなく、まずはデータ型を整え、不要なカラムを削除します。

• タイムゾーンの統一: UTCをJST（+9時間）に変換。
• NULL値の処理: 欠損値がある場合のデフォルト値設定。

3.2 Intermediate層：名寄せと重複排除

「Webの問い合わせ（Email）」と「Salesforceのリード（Email）」を紐づける「名寄せ」を行います。ここで、1人のユーザーが複数回問い合わせた場合の「ユニークCV数」の定義を確定させます。

3.3 Mart層：ビジネス指標の定義とテスト

最終的なBIツールが参照するテーブルです。ここではじめて 商談化率 = 商談数 / 有効リード数 といった計算ロジックを記述します。dbtの generic test を使い、商談化率が100%を超えるといった異常値が発生した際に自動アラートを飛ばす設定を組み込みます。

関連記事：高額なCDPは不要？BigQuery・dbt・リバースETLで構築するモダンデータスタック

4. 現場の意思決定を加速させる「リバースETL」とBI連携

4.1 算出した「商談化スコア」をSalesforceに書き戻す

dbtで算出した「このリードの商談化確度」などの高度な指標を、Hightouch等を用いてSalesforceのカスタム項目に自動で書き戻します（リバースETL）。これにより、営業担当者はBIツールを開くことなく、いつものCRM画面で「優先すべきリード」を把握できます。

4.2 経営判断を支えるTableau/Lookerでの可視化

指標がコード管理されていれば、BIツール側で行うのは「表示」だけです。ツールの乗り換えや複数のBIツール（TableauとLooker Studioの併用など）を利用しても、数字がズレることはありません。

• Tableau事例: セールスフォース社による自社導入事例では、全社員が共通のデータダッシュボードを参照し、共通言語で議論を行っています。

  【公式】SalesforceによるTableau活用事例

5. 実務で直面するトラブルシューティングと運用回避策

5.1 「タイムゾーンの壁」への対処法

BigQuery等のDWHはデフォルトがUTCです。dbtのモデル内で DATETIME(created_at, 'Asia/Tokyo') を徹底するか、プロジェクト全体でタイムゾーン変換のマクロを定義することを推奨します。これを行わないと、深夜帯のCVが翌日分として集計され、日次レポートが毎日ズレ続けます。

5.2 API制限（Quota）の回避設計

Fivetran等でSaaSからデータを抜く際、SalesforceのAPIリクエスト制限（API Quota）に抵触することがあります。全件取得ではなく、dbtの is_incremental() マクロを使い、前回の実行以降に更新されたレコードのみを処理する「増分更新」を設計に組み込んでください。これにより、処理時間の短縮とコスト削減が同時に実現します。

5.3 データの鮮度（Freshness）の担保

dbtの source freshness 機能を使い、例えば「Salesforceからのデータ取り込みが12時間以上止まっている」場合にエラーを出すように設定します。数字がズレているのではなく「古い」だけという初歩的な混乱を防ぐことができます。

関連記事：広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

まとめ：信頼できるデータが組織を強くする

「数字がズレる」問題の解決は、単なる技術的な課題解決ではありません。部門間の不信感を拭い、全社員が同じ指標を信じてアクセルを踏める環境を作る「組織変革」そのものです。dbtを核としたデータ基盤構築により、貴社のマーケティング活動を「推測」から「確信」へと変えていきましょう。