Salesforce Data Cloud イベント来場者・EC購入者・LINE友だちの統合顧客ビュー（概念と設計）

デジタルマーケティングの現場において、顧客は複数のチャネルを縦横無尽に行き来します。展示会（イベント）で製品を知り、LINE公式アカウントを友だち登録し、最終的にECサイトで購入に至る。この一連のプロセスにおいて、多くの企業は「イベント名簿」「LINE友だちリスト」「EC購買履歴」がバラバラのシステムに存在し、一人の人間として認識できないという課題を抱えています。

Salesforce Data Cloudは、これら「分断されたデータ」をリアルタイムに近い速度で統合し、真のシングルソース（信頼できる唯一の情報源）を構築するためのプラットフォームです。本記事では、実務者が直面するデータマッピングや名寄せ（アイデンティティ解消）の具体的な設計手法について解説します。

Salesforce Data Cloudによる顧客統合の全体像

Data Cloudの役割は、単なるデータのストレージではありません。異なるフォーマット、異なる更新タイミングで流れてくるデータを、Salesforceが定義する標準データモデル（CIM: Cloud Information Model）に適合させ、高度な計算と推論を用いて「誰と誰が同一人物か」を特定することにあります。

なぜイベント・EC・LINEの統合が必要なのか

例えば、ECでの購入頻度が高い顧客がイベントに来場した際、現場のスタッフがその事実を即座に把握できれば、接客の質は劇的に向上します。また、LINEで特定のキーワードに反応した顧客に対して、ECでの閲覧履歴に基づいたパーソナライズメッセージを送信できれば、CVR（成約率）は大幅に高まります。これらを実現するには、バックグラウンドで「匿名データ」と「記名データ」がシームレスに結合されている必要があります。

Data Cloudが担う「真のシングルソース」としての役割

Data Cloudは、Salesforce内のデータ（Sales Cloud, Service Cloudなど）はもちろん、Amazon S3やGoogle Cloud Storage、さらにはSnowflakeやBigQueryといった外部データウェアハウスとも直接接続（ゼロETL）が可能です。これにより、データを複製することなく、最新の顧客情報を統合ビューとして可視化できます。

データソース別の取り込み（Ingestion）設計

統合の第一歩は、データの「接続」です。それぞれのソースの特性に応じたコネクタを選択します。

イベント来場データ（Salesforce / 外部API）

イベントの来場管理をSales Cloudの「キャンペーン」で行っている場合は、標準コネクタで容易に取り込めます。iPad等の外部アプリで管理している場合は、Amazon S3経由での一括インポート、もしくはIngestion APIを使用したリアルタイム連携を検討します。

EC購入履歴データ（Shopify / MuleSoft）

ECプラットフォームがShopifyの場合、Data Cloudとの直接連携コネクタが有効です。自社構築のECサイトやレガシーな基幹システムの場合は、MuleSoftを介してデータ変換を行いながらData Cloudへ流し込むのが実務的です。ここでは「いつ」「誰が」「何を」「いくらで」買ったかというトランザクションデータを、データレイクオブジェクト（DLO）として定義します。

ECと会計の連携については、以下の記事で解説しているアーキテクチャが、Data Cloudへデータを流す前の「整流化」において非常に参考になります。

【完全版】Shopifyの売上をfreeeに直接連携してはいけない。決済手数料の分解と「月末在庫」を正しく処理する2つのコマースアーキテクチャ

LINE友だち・行動データ

LINEのデータ統合は最も難易度が高い部分です。LINE公式アカウントのWebhook経由で取得できる「LINEユーザーID」と、自社で保有する「メールアドレス」や「電話番号」を紐づける必要があります。多くの場合、LIFF（LINE Front-end Framework）を用いたログイン連携や、アンケートフォームによるID連携（IDシンク）が必要です。

LINE連携の具体的なデータ基盤設計については、こちらの記事が詳細を網羅しています。

LIFF・LINEミニアプリ活用の本質。Web行動とLINE IDをシームレスに統合する次世代データ基盤

【実務】データモデル（DMO）へのマッピングと設計指針

Data Cloudに取り込まれた生のデータ（DLO）は、そのままでは使えません。これらをData Cloud標準の「データモデルオブジェクト（DMO）」にマッピングする作業が必要です。

Customer 360 データモデルの基本構造

基本となるのは「Individual（個人）」DMOです。これに対し、以下のDMOを関連付けます。

• Contact Point Email: メールアドレス（EC、イベント登録用）
• Contact Point Phone: 電話番号
• Contact Point App: LINEユーザーID（LINE連携用）
• Sales Order: EC購入履歴
• Engagement: イベント来場、LINEメッセージ開封、Web閲覧履歴

イベント・EC・LINEを紐づける共通キーの設計

マッピングの際、最も重要なのが「ソースキー（Source Key）」の設計です。各ソースシステムが持つ固有のIDを保持しつつ、それをData Cloud内でどのように「共通の個人」に紐づけるかを定義します。例えば、ECサイトの顧客IDが EC_12345 で、LINEのIDが U1a2b3c... であっても、両者が同じメールアドレス user@example.com を持っていれば、Data Cloudはこれらを同一人物とみなす準備が整います。

アイデンティティ解消（名寄せ）の具体的な設定手順

アイデンティティ解消（Identity Resolution）は、Data Cloudの心臓部です。複数のデータソースから「同一人物」を特定するルールを設定します。

名寄せの精度を高めるためには、Webサイト上でのトラッキングとID連携の設計が欠かせません。詳細は以下のガイドを併せて参照してください。

WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ

1. マッチルールの定義

どの項目が一致したら「同一人物」とみなすかのルールを作成します。
例：

• ルール1（完全一致）: メールアドレスが一致
• ルール2（完全一致）: 電話番号 ＋ 氏名（カナ/英字）が一致
• ルール3（あいまい一致）: 氏名 ＋ 住所が近似

一般的には、確実性の高い「メールアドレス」や「電話番号」を優先します。

2. リコンシリエーションルールの定義

同一人物と特定された際、複数のソース（EC、イベント、LINE）で住所や電話番号が異なっていた場合、どのシステムの情報を「正」とするかを決定します。「最後に更新されたデータ（Last Updated）」を採用するか、あるいは「ECシステムのデータを優先（Source Priority）」するかをビジネス要件に合わせて設定します。

【比較】自社構築（BigQuery/CDP） vs Salesforce Data Cloud

顧客統合基盤を検討する際、自社でデータウェアハウス（DWH）を構築するか、Data Cloudのようなパッケージを利用するかは大きな分岐点です。

※料金の詳細は、Salesforce公式サイトの価格ページをご確認ください。利用するデータボリュームや処理頻度によって変動します。

運用上の注意点とよくあるエラーへの対処法

データボリュームとクレジット消費の最適化

Data Cloudは強力ですが、すべてのデータを無差別に同期するとクレジットを激しく消費します。例えば、ECサイトの「カート投入ログ」をすべてストリーミングで取り込む必要があるのか、あるいは「購入確定」だけで良いのか、目的（セグメンテーションやトリガー配信）に基づいたフィルタリングが重要です。

よくあるエラー：アイデンティティの過剰統合

「家族で同じメールアドレスを使っている」「店舗の共有端末でログインされた」といったケースで、意図しない名寄せ（過剰統合）が発生することがあります。これを防ぐためには、マッチルールの厳格化や、匿名CookieとログインIDの紐づけ解除条件（ログアウト時の処理）を正しく設計する必要があります。

まとめ：統合顧客ビューがもたらすビジネス成果

Salesforce Data Cloudによるイベント・EC・LINEの統合は、単なるデータ集約ではありません。それは、顧客が「今、何を求めているのか」を文脈（コンテキスト）に沿って理解するための基盤です。

イベントでの名刺交換から、LINEでの継続的なコミュニケーション、そしてECでの購買。このストーリーを一本の線でつなぐことで、企業は初めて、LTV（顧客生涯価値）を最大化するための施策を実行に移すことができます。設計の難易度は決して低くありませんが、本記事で紹介したDMOマッピングと名寄せの指針を参考に、一歩ずつデータ統合を進めてみてください。