はじめに
POSやECの取引を、そのままCRMに流し込めば終わり——というわけにはいきません。
「取引の何を、CRMのどのプロパティに入れるか」を決めるマッピング設計が、この同期のいちばんの肝なんです。
この記事では、1件の取引をDeal・Contact・LineItemという3つのオブジェクトへどう分解し、どんなプロパティを持たせるかを解説します。丁寧に設計しておくと、後の分析や施策がぐっと楽になります。
1件の取引を3つに分解する
なぜ分解するのか
POSの1レシート、ECの1受注には、実は複数の情報が詰まっています。「取引そのもの」「買った人」「買った商品の明細」です。これを一枚岩のまま持つと、後から「商品単位」で集計したいときに困ります。
取引を1レコードで持ち、商品名をテキストで羅列。商品単位の分析ができない
Deal・Contact・LineItemに分け、関連づける。商品・顧客・金額を自在に横断できる
CRMがもともと「取引に商品明細をぶら下げる」構造を持っているので、それに素直に合わせるのが結局いちばん扱いやすい形になります。
3オブジェクトの関係
分解した3つは、Contactを親として関連づけます。ContactにDealがぶら下がり、DealにLineItemがぶら下がる、という入れ子の構造です。
メール・顧客番号で名寄せした1人の顧客
1回の購入。金額・購入日・チャネルを持つ
購入した商品ごとの行。SKU・数量・単価
この構造にしておくと、顧客からもDealからも商品からも、それぞれの視点で購買を辿れるようになります。
Dealのプロパティとパイプライン設計
金額・購入日・チャネルを持たせる
Dealには、その取引を表す基本情報を持たせます。取引金額、購入日、そして「店舗かECか」を区別するチャネルの属性です。特にチャネルは、後でクロスチャネル分析をするときの軸になるので、必ず独立したプロパティとして持たせておきます。
外部取引IDを持たせておくのがポイントで、これが同じ取引を二重登録しないための冪等キーになります。
パイプラインとステージの考え方
CRMのDealは本来、商談の進捗（ステージ）を管理するものです。ですが今回のように「すでに確定した売上」を入れる場合は、進捗というより完了した取引の記録として扱います。
そのため、パイプラインは同期用に専用のものを用意し、基本は「購入完了」ステージに固定して投入します。営業的な商談パイプラインと混ざらないよう分けておくと、レポートも運用も見通しがよくなります。返品やキャンセルを扱いたい場合は、専用のステージを足して対応します。
LineItemと名寄せの設計
商品明細をどう作るか
LineItemは、取引の中の1商品行に対応します。商品名・SKU・数量・単価を持たせ、CRM側の商品マスタ（Product）と紐づけられるとより理想的です。
SKUを軸にする
商品名は表記ゆれが起きやすいため、LineItemの照合や商品マスタとの紐づけにはSKUを主キーにするのが安全です。商品名は表示用と割り切ると、後の集計がぶれません。
数量と単価を分けて持たせておくと、「この商品が累計何個売れたか」といった商品単位の分析にもそのまま使えます。
Contactへの名寄せキー
購入者は、メールアドレスを第一キー、会員番号（顧客番号）を補助キーとして既存Contactに名寄せします。どちらでも一致しなければ新規Contactを作成します。
このキー設計は同期の精度を大きく左右する部分です。片方だけに頼ると、メール変更や店舗・EC別登録で同一人物が分裂してしまいます。複数キーを併用し、優先順位を決めて照合していくのが実務上の落としどころでした。
まとめ
取引データのマッピング設計では、1件の取引をDeal・Contact・LineItemの3つに分解し、それぞれに適切なプロパティを持たせることが要点です。外部取引IDによる冪等性、SKU軸のLineItem、複数キーの名寄せ——この3点を丁寧に設計すると、後の運用が安定します。
続けて、店舗ごとの担当者割り当てを扱うOwnerマップ運用、そして安全に本番投入するDry Runの手順もあわせてご覧ください。全体像はハブ記事に戻ると掴みやすいはずです。