2026年9月28日

最も誤解されがちなマーケティングデータ用語24選

マーケティングとデータエンジニアリングの架け橋（全6回中パート1）：キャンペーンのやり直しを減らし、オーディエンスの準備状況、データの最新性、所有権を明確にするために、マーケティングチームとデータチームで解釈が異なる24の用語を解説する実践ガイド

によってケイティ・ユアンによる投稿

「顧客」、「オーディエンス」、「リアルタイム」、「モデル」など、マーケティングとデータエンジニアリングで解釈が異なることが多い24の用語を理解します。
作業を開始する前に、データソース、顧客ID、オーディエンスの準備状況、データの最新性要件、所有権について合意形成を図ることで、キャンペーンのやり直しを減らします。
データとワークフロー全体で共有されたビジネスコンテキストを紐付けることで、合意された定義をマーケティングキャンペーン、アナリティクス、AI全体で再利用可能にします。

あなたが休眠顧客の呼び戻しキャンペーンを計画しているマーケターだと想像してみてください。データチームに「非アクティブな顧客」のリストを依頼します。あなたは「90日間何も購入していない人」を想定していますが、戻ってきたリストは「30日間アプリを開いていないユーザー」に基づいています。データ上では「非アクティブ」がそのように定義されているからです。

あるいは、注文したばかりの人に「あなたがいなくて寂しいです」といったメールを送るのを防ぐために、「リアルタイム」のオーディエンス更新を依頼したとします。あなたは15分ごとに更新されるリストを思い描いていますが、データチームは「数秒以内の更新」と受け取り、新しいインフラ、継続的なコスト、そしてより長いスケジュールについての質問を持ち帰ってきます。

こうした認識のズレは、何が構築されるか、コストがどれくらいかかるか、そしてマーケティングチームがいつそれを使用できるかに影響します。「顧客」が何を意味するのか、どのような状態になればオーディエンスの準備が整ったと言えるのか、そしてシグナルの鮮度がどれくらい必要なのかについて早期に合意しておくことで、誤解によるキャンペーンのやり直しを防ぐことができます。

このガイドでは、マーケティングとデータエンジニアリングで解釈が異なることが多い24の用語を、キャンペーン実行に関する5つの実践的な質問に沿って整理して解説します。これらの対比された定義を会話のきっかけとして活用してください。作業を開始する前に、前提条件を洗い出し、双方が何を必要としているかを明確にし、ビジネスに適した定義について合意を形成しましょう。

印刷可能なPDF版（全24用語）はこちらからダウンロードできます。

同じ言葉、異なる意味印刷用ガイドPDF

1. キャンペーンデータはどこから取得されるのか？

マーケティングツール内の情報は、複数のシステムや処理ステップに依存している場合があります。その経路を理解することで、必要なものを説明しやすくなり、どこに変更を加えるべきかを判断できるようになります。たとえば、「最終購入日」というフィールドを例に挙げてみましょう。これを使って休眠顧客を特定する前に、キャンセルされた注文が含まれるかどうか、およびどのシステムがその日付を提供するのかについて合意しておく必要があります。

用語	マーケティングが意図することが多い意味	データエンジニアリングが意図することが多い意味
イベント	ターゲティングの対象となる、顧客が行ったアクション。	タイムスタンプとスキーマを持ち、一度だけ書き込まれるレコード。スキーマは変更される可能性があり、それがインジェスト（取り込み）やそれ以降の下流プロセスすべてに影響します。
データソース	データが表示されるツールまたはアプリケーション。	データを生成したシステム。どのシステムか、どのように届いたか、およびどのバージョンを正とするか。
フィールド	セグメントビルダー内の入力欄や選択ボックス。	データ型（許可される値）、Null許容ルール（空にできるかどうか）、およびオーナーが定義された列。
生データ	フォーマットされていないエクスポートデータ。	下流プロセスを再構築できるように保存された、手を加えていないランディングレイヤー。
同期	データがツールに表示されること。	失敗モード、再試行、昨夜の失敗レコードなどを伴うジョブ。スケジュール実行、変更キャプチャ、またはイベント駆動型。
連携	2つのツールが接続されている状態。	認証、フィールドマッピング、スキーマ処理、レート制限、再試行、モニタリング、およびオーナーを伴うデータの移動経路。

合意すべき点： 値がどこから取得されるか、何が含まれるか、および誰がそれをメンテナンスするか。

2. 顧客レコードは誰を表しているのか？

顧客のアイデンティティ（識別情報）によって、誰が含まれ、誰が除外され、あるいは最悪の場合、二重にカウントされるかが決まります。まずは、1つのレコードが何を表しているのか、および2つのレコードが同一人物のものであるとチームがどのように判断するのかを確立することから始めましょう。

顧客関係に関するマーケティングチームの知見は、エンジニアリングチームがアイデンティティについてより適切な意思決定を行うのに役立ちます。先ほどの呼び戻しキャンペーンの例では、「個人」と「世帯」はどちらも顧客データを整理する上で有用な方法です。キャンペーンでは、これらどちらを採用するかを明確に選択する必要があります。世帯単位のビューは、1世帯につき1回限りの特典に適しているかもしれません。個人単位のビューは、個人のロイヤルティ特典に適しているでしょう。

用語	マーケティングが意図することが多い意味	データエンジニアリングが意図することが多い意味
顧客	個人。	特定の粒度におけるエンティティ。個人、アカウント、世帯、デバイスなど、およびそれを表す識別子。
プロファイル	ある人物について判明しているすべての情報を1つの画面にまとめたもの。	共通のキーで結合（Join）された複数のテーブル。特定の時点で計算されたものであり、すでにわずかに古くなっている可能性があります。
重複排除	重複しているものを削除すること。	アイデンティティ解決（ID統合）。しきい値を持つポリシー。判定が緩すぎると2人の別人を統合してしまい、厳しすぎると1人の人物を分割してしまいます。
ゴールデンレコード	唯一の真実。	人が作成したルール（変更可能）の出力結果。

共有されたデータ基盤があれば、チームはこれらの目的に応じて明確に命名されたビューを維持し、適切なビューを再利用できます。それぞれについて、文書化された定義、レコードの紐付けに使用する識別子、およびマッチングルールのオーナーが必要です。

合意すべき点： キャンペーンのターゲットが個人、アカウント、世帯、デバイスのいずれであるか、および関連するレコードがどのようにマッチングされるか。

3. どのような状態になればオーディエンスをアクティベートできるのか？

オーディエンスはいくつかの状態（定義するルール、条件を満たすレコード、送信先で使用できるレコード）を経て遷移します。それぞれの状態は、キャンペーンの準備状況に関する異なる疑問に答えるものです。

たとえば、50,000人がセグメントに一致したものの、メールプラットフォームがそのうち47,000件のレコードしか受け入れなかったとします。この例における差分は、送信先識別子の欠落、拒否されたレコード、または配信時に適用された除外ルールを反映している可能性があります。チームは、オーディエンスの準備が整ったと判断する前に、この差分の原因を説明できるようにする必要があります。

用語	マーケティングが意図することが多い意味	データエンジニアリングが意図することが多い意味
セグメント	メッセージを送信する対象となる人々のグループ。	「定義」を指しているのか、それとも「結果」を指しているのかを把握する必要があります。これらはコストが異なります。
オーディエンス	セグメントと同じ意味。	多くの場合、セグメントのエクスポートされたコピー（その背後にあるロジックではなく、送信先にプッシュされたバージョン）を指します。
モデル	解約傾向などの予測。	データモデル。テーブルとそれらの関係性。このページで最も誤解を招きやすい用語。
計算された特性	顧客生涯価値（LTV）など、個人に関する有用な数値。	スケジュールに従って、コストをかけて、すべての人を対象に永続的に再計算されるもの。
類似	シードオーディエンスから構築された、拡張されたリーチ。	調査、説明、デバッグができない下流プロセスのブラックボックス。これに依存することに対して、エンジニアが難色を示すことを想定しておく必要があります。
アクティベーション	キャンペーンを開始すること、またはオーディエンスを活用すること。	適切な識別子、権限、鮮度、フォーマットを備えた対象レコードを送信先に配信すること。

定義、評価されたメンバーシップ、および配信結果を識別可能な状態に維持することで、このプロセスが容易になります。マーケティングチームはルールが意図したオーディエンスを表しているかどうかを確認でき、エンジニアリングチームは正しいレコードが送信先に届いたかどうかを確認できます。これにより、双方が「想定内の除外」と「修正が必要な問題」を区別できるようになります。

同様の正確さは予測においても役立ちます。キャンペーンで傾向スコアが必要な場合は、その予測の名前と、それが何を推定するためのものであるかを明確に指定してください。これにより、チームは単に「モデル」と呼ぶよりも、構築および検証すべき具体的な対象を得ることができます。

合意すべき点： オーディエンスの選択ルール、必要な予測または特性、および配信がどのように検証されるか。

4. データの鮮度はいつ十分と言えるのか？

鮮度は、下そうとしている顧客に関する意思決定によって異なります。単一のキャンペーンであっても、データが1つのプラットフォームから取得されている場合でも、複数のタイミング要件が存在することがあります。

毎晩計算され、15分ごとにエンゲージメントツールに送信される解約スコアを例に考えてみましょう。配信頻度を高くしても、予測データが15分前のものになるわけではありません。それは依然として夜間の計算に基づいています。

ここで、今朝購入した顧客を追加してみましょう。キャンペーンでは、次回の配信前にその顧客をウィンバックオーディエンスから除外する必要があるかもしれませんが、解約スコアは次回のスケジュールされた計算まで待つことができます。これらは別々の要件であり、顧客への影響も異なります。

用語	マーケティング部門が意図しがちなこと	データエンジニアリング部門が意図しがちなこと
リアルタイム	違和感がない程度に十分に早いこと。	1秒未満のストリーミング、常時稼働のアーキテクチャ、そして発生し続けるコスト。
リフレッシュ	数値が変化すること。	依存関係、スケジュール、およびオンコール担当者を伴うパイプラインの実行。
レイテンシ	何かが表示されるまでの遅延。	指定していない箇所で測定された、複数の遅延の累積。
ライブ（本番稼働）	現在動作していること。	テスト環境ではなく、本番環境にあること。

鮮度を有意義なものにするには、遅延の開始と終了を特定します。たとえば、購入が発生してからデータプラットフォームで利用可能になるまで、その利用可能状態からメンバーシップの変更まで、あるいはメンバーシップの変更から配信先がそれに基づいてアクションを実行できるようになるまで、といった具合です。

これらの違いを明確にすることで、チームは体験を変化させる「スピード」に投資できるようになります。また、マーケティング部門にとっても、キャンペーン全体を「リアルタイム」にする必要があると言う代わりに、問題をより適切に説明できるようになります。

合意すべき事項： どの顧客イベントから計測を開始するか、更新されたデータはどこで使用可能であるべきか、そして許容できる遅延はどのくらいか。

5. データが使用される際、誰が責任を負うのか？

顧客データへのアクセス権を得ることで、その意味、許可された用途、および継続的な所有権に関する疑問が生じます。これらの責任は、オーディエンスがデータプラットフォームから離れた後も継続します。

用語	マーケティング部門が意図しがちなこと	データエンジニアリング部門が意図しがちなこと
信頼できる唯一の情報源	信頼しているダッシュボード。	指定されたシステム、ガバナンスが効いたデータセット、またはセマンティック定義。テーマごとに異なるものが存在することは正当です。
同意	顧客がチェックボックスにチェックを入れたこと。	下流に伝達され、クエリ実行時に適用可能でなければならない、目的ごとの許可。
コピー	データをどこかにダウンロードまたはエクスポートすること。	追加で永続化されたすべてのバージョン。レプリケーション、マテリアライズドテーブル、キャッシュ、抽出データ、配信先側のストレージなど。
ガバナンス	物事に時間がかかる理由。	企業がデータ漏洩を公表せずに済んでいる理由。

実際には、ガバナンスはデータの品質、所有権、適切な使用もカバーします。実用的な出発点として、各意思決定に指定された情報源を特定することが挙げられます。顧客のアイデンティティを確立するシステムは、チャネルの好みを記録するシステムや収益を計算するシステムとは異なる場合があります。

次に、データが配信先に届くまでの流れを追跡します。エクスポート時に条件を満たしていたオーディエンスであっても、その後の配信前に最新の除外リストの適用が必要になる場合があります。保存されたコピーは、それを作成したキャンペーンよりも長く残ることがあります。チームは、変更がどのように配信先に届くのか、そして届かない場合に誰がその対応を担当するのかを把握しておく必要があります。

Databricks CustomerLake（Agentic CDP）は、カスタマーデータプラットフォームの機能をDatabricksとそのガバナンス基盤にネイティブに統合します。この共有基盤を活用することで、マーケティングチームとデータチームは、信頼できる顧客コンテキストを共有する場所を確保できます。

合意すべき事項： 各意思決定における信頼できる情報源、許可された用途、および配信先での更新の担当者。

アクションアイテム：1つの合意を単一のキャンペーンを超えて役立てる

Databricks上で構築を行うチームにとって、次のステップは、これらの重要な合意を再利用可能にすることです。チームはビジネス定義をUnity Catalogに文書化し、Genieでの分析、CustomerLakeでのオーディエンス構築、またはMLモデル開発で検出可能にすることができます。新しいキャンペーンごとに、マーケティング部門とデータエンジニアリング部門がすでに合意し、実践している定義を活用できます。

最近のキャンペーンで混乱を招いた用語を1つ選択してください。データチームと一緒に1つの顧客例を検証し、次にデータを使用する人が見つけられる場所にその決定を記録します。

「顧客」であれば、レコードが何を表しているのか、そしてその背景にある識別子を命名することを意味します。「最終購入日」であれば、どの取引をカウントするかを文書化することを意味します。「オーディエンスの準備完了」であれば、ローンチ前に何を確認すべきかについて合意することを意味します。

合意された意味を、それを実装するデータセットまたはワークフローに関連付け、変更時に誰が関与すべきかを特定します。ドキュメントと実装は共に進化していく必要があります。

これは、マーケターが自然言語ツールやAIエージェントに顧客データの処理を依頼する際に、特に役立ちます。「最も価値のある休眠顧客を見つける」という指示には、価値、休眠状態、アイデンティティ、許可に関する曖昧さが依然として残ります。明示的な指示がない場合、AIは独自の判断を下しますが、その判断は毎回異なるものになります。AIツールに明示的なビジネス定義とコンテキストを提供することで、より優れた、一貫性のある結果が得られます。

有効なテスト方法として、次のキャンペーンに参加する人が、最初の会議に出席した人を探し出すことなく、その決定を理解できるかどうかを確認することが挙げられます。理解できるのであれば、チームは再利用可能な成果物を作成できたことになります。

本シリーズについて

「マーケターのためのデータエンジニアリング対話ガイド」は、Matthew Niederberger氏のMartechTherapyとのパートナーシップにより開発された、全6回のシリーズです。この記事における24の定義は、Databricksが後援し、同氏が独自に作成したガイドから転載されたものです。

Matthew氏のオリジナルの記事、Same word, different meaning（同じ言葉、異なる意味）を読んで、同氏の視点や、次回の会議に持参できる印刷用リファレンスを確認してください。

シリーズ次回予告：アクションにつながるデータリクエストの書き方。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事