CRMとECカート連携のよくあるご質問50選
CRMとECカート連携のよくあるご質問50選
目次
- CRMとECカートの連携に関する5つの質問
- 受注データ連携に関する5つの質問
- 顧客データ連携に関する5つの質問
- 商品マスタ連携に関する5つの質問
- 会員データ連携に関する5つの質問
- API連携に関する5つの質問
- CSV連携に関する5つの質問
- リアルタイム連携に関する5つの質問
- 複数カート連携に関する5つの質問
- 連携エラー監視に関する5つの質問
1. CRMとECカートの連携に関する5つの質問
Q1. CRMとECカートのどちらを、顧客・注文データの正本にしますか？
A. 運営状況や解決したい課題によって、顧客属性、受注、同意など領域ごとに正本を決めます。その際は、双方向で自由に上書きせず、更新元・時刻・優先順位を項目単位で定義します。
Q2. カート連携の対象範囲は、最初から全項目にすべきですか？
A. 全項目にはしません。初回・休眠・再購入など先行施策に必要なID、注文、商品、同意から始め、利用されない列は連携対象外にします。
Q3. CRM施策に必要なデータは、どのタイミングで連携しますか？
A. 顧客、受注、商品データなどは深夜の時間帯に1回の更新。行動履歴系のデータは即時連携が望ましいです。
Q4. カートとCRMで顧客IDが異なる場合、どう紐付けますか？
A. 紐づかない理由は、カート以外のデータをCRMへ入れ込んでいる事が鯨飲であることがほとんどです。実施されたい施策や管理目的によって連携タイミングや統合方法は検討しましょう。
Q5. カートとの汎用的な連携は、良い事ですか？
A. はい。汎用的な連携が出来ている場合、特注での出費をすることなくCRMツールとカートを連携する事が出来るため、初期費用を押さえ導入スケジュールの短縮が想定できます。
2. 受注データ連携に関する5つの質問
Q6. 注文ステータスは更新される方が良いですか？
A. 更新される事が望ましいです。また商材によってはステータスによって施策の出し分けも行った方が良いです。
Q7. キャンセルや返品を、CRMの売上へどう反映しますか？
A. 元注文を消さず、取消額・返品額・発生日を反対取引として連携します。売上、粗利、購入回数を再計算し、対象者やランクにも反映します。
Q8. 税・送料・値引きを含む注文金額の定義は、どう揃えますか？
A. 商品小計、値引き、税、送料、ポイント、返金を別項目で受け、CRMの純売上を式で定義します。カート表示総額だけをLTVに使わないようにします。
Q9. ゲスト購入の注文を、後から会員へ紐付けてもよいですか？
A. 本人確認できた場合に限り紐付けます。
Q10. 受注データの到着が遅れた際の対応方法はありますか？
A. まず遅れてしまった理由はCRMの運用企業から通知や説明がある事がほとんどです。万が一、データの取り込み遅れが発生してしまった場合に、改善策を講じる企業を選ぶようにしましょう。
3. 顧客データ連携に関する5つの質問
Q11. 顧客データの連携キーに、メールアドレスも使えますか？
A. 会員IDだけでなく、メールアドレスでの紐づけも行えば、非会員とのデータ統合も可能になります。目的に合わせて活用しましょう。
Q12. 同じ人の顧客レコードが複数ある時、どれを残しますか？
A. 最新のデータで上書きをしていく事が一般的です。
Q13. 配送先住所を、そのまま顧客の現住所として保存してよいですか？
A. 基本的には保存しません。配送先は注文単位の届け先で、本人住所とは限りません。顧客属性へ反映する場合は本人が会員画面で登録した住所と区別します。
Q14. メールやLINEの同意・配信停止は、どのシステムを基準にしますか？
A. チャネル別同意を管理する一つの正本を決め（カート側にするのか、CRM側にするのか、など）停止は最優先で全配信先へ反映します。許可と不明を同じ状態にしない設計も必要です。
Q15. 顧客から削除依頼があった場合、連携先へどう反映しますか？
A. 依頼受付、本人確認、対象システム、処理結果を管理し、CRMだけでなくカート・配信・分析用複製にも伝播させます。保持義務のある取引記録は分けて判断します。
4. 商品マスタ連携に関する5つの質問
Q16. カートの商品コードとCRMのSKUが一致しない時、どう対応しますか？
A. データの統合ルールはツールによって違う為、連携仕様を利用中のCRMツール運用元に確認をし、SKUを一致する事も重要ですが、目的はCRM施策に影響のない判断で進めるようにしましょう。
Q17. 商品カテゴリを変更した後も、購入時の分類を残せますか？
A.データの統合ルールはツールによって違う為、連携仕様を利用中のCRMツール運用元に確認をしましょう。
Q18. セール価格と通常価格は、CRMへどのように連携しますか？
A. 注文時の単価を基本的に連携し、現在の商品マスタ価格で過去売上を再現しないようにします。セールでのみ購入する方と、通常価格で同回数購入される方のロイヤリティを把握する為です。
Q19. 終売商品をＣＲＭツールの商品マスタから削除してもよいですか？
A. ＣＲＭツール内で削除する必要は特にないです。ただ、削除してしまうと過去データへの影響などはＣＲＭツールによって違う為、運営元へ削除理由を伝えた上で削除しても問題がないか確認の上、処理をしましょう。
Q20. セット商品や定期商品の構成品を、どの粒度で持ちますか？
- セット商品で分析や施策を実施したい場合と、商品個数単位で分析や施策を行いたいかによって変わります。連携仕様はＣＲＭの運用元へ確認しましょう。
5. 会員データ連携に関する5つの質問
Q21. 会員情報の正本を、カートとCRMのどちらに置きますか？
A. 登録・認証を担うカートを基本の正本とし、CRMは施策用属性を付加する形が一般的です。例外項目は更新権限を一覧化して競合を防ぎます。
Q22. 顧客が会員情報を変更した時、どちらを優先しますか？
A. 登録・認証を担うカートを基本の正本とします
Q23. 会員ランクやポイント残高を、CRM側で計算してもよいですか？
A. 残高や利用可否は取引を処理するカート側の仕組みを企保的に正本にします。
Q24. ゲスト購入履歴を会員登録後に統合する条件は何ですか？
A. 本人が所有を確認したメールや名前、電話番号など、明確な照合条件を満たす履歴だけを候補にします。
Q25. 退会した会員のIDと購入履歴は、どう扱いますか？
A. ＣＲＭツールによって退会会員のデータ状況は変わる為、運用元への確認を行うようにしましょう。
6. API連携に関する5つの質問
Q26. 注文更新はWebhookと定期API取得のどちらが向いていますか？
A. 即時通知はWebhook、取りこぼし確認や過去再取得は定期APIが向きます。両方を併用し、Webhookを合図、API結果を確定データとする設計も有効です。
Q27. APIの認証情報は、誰がどのように管理しますか？
A. 秘密管理基盤へ保管し、最小権限・期限・更新・利用ログを管理します。資料やコードへ直書きせず、退職・委託終了時は失効させます。
Q28. APIの呼び出し上限に達しそうな時、何を優先しますか？
A. APIに開発元によってデータの優先をつけれる場合とつけれない場合もある為、APIの開発元の企業へまずは確認をするようにしましょう。
Q29. APIから同じ注文が再送された場合、二重登録をどう防ぎますか？
A. 一般的に注文IDの一致キーを使い、同じ更新番号は反映しても問題はない事が多いです。受信時刻の違いで新規注文になる事は基本的にありません。
Q30. カート側のAPI仕様変更へ、どう備えますか？
A. 多くの場合、APIの仕様変更は連携先のCRMツールの運用元へ通知が行くことがほとんどで、通知内容に沿って対応を進めます。その為、CRMツールの利用者が仕様変更の備えをする必要はない事が多いです。
7. CSV連携に関する5つの質問
Q31. CSV連携で文字化けや列ずれを防ぐには、何を固定しますか？
A. UTF-8、区切り、改行、引用符、日付形式、空欄表現、列順を仕様書で固定します。列名と版番号を持たせ、想定外の列は取込前に止めます。
Q32. CSVは全件ファイルと差分ファイルをどう使い分けますか？
A. 日常連携は更新日時や連番による差分、初期移行と定期照合は全件を使います。差分だけに依存せず、全件比較で漏れを発見できるようにします。
Q33. 顧客情報を含むCSVを、安全に受け渡す方法は？
A. 権限を限定した暗号化経路で転送し、保存期限と削除確認を決めます。メール添付や共有URLの使い回しを避け、取得・閲覧ログを残します。
Q34. CSV取込が途中で失敗した場合、どこから再開しますか？
A. ファイルIDと行キーごとの処理結果を残し、未処理行だけを再実行します。ファイル全体を再投入して注文や顧客を重複登録しない設計にします。
Q35. 担当者がCSVを手作業で修正する運用を続けてもよいですか？
A. ヒューマンエラー（人為的ミス）のリスクを極力低減した運用で続ける場合には問題ありません。
8. リアルタイム連携に関する5つの質問
Q36. どのデータをリアルタイム連携にするべきですか？
A. 行動履歴系のデータはリアルタイム連携が望ましいです。
Q37. 注文直後のサンクス配信は、注文確定前に送ってもよいですか？
A. 受付通知なら送れますが、決済済み・出荷確定と誤認させない文面にするようにしましょう。
Q38. リアルタイム連携で、画面ごとに値が違うことはありますか？
A. WEB接客などをサイト内に埋め込みレコメンド施策や、売上ランキングの表示など実施した場合、画面ごと（ログインした人によって）画面が変わる事はあります。
Q39. リアルタイム連携が止まった時、CRM施策をどう制御しますか？
A. 最終正常時刻を基に時間依存施策を自動停止し、静的な配信へ切り替えます。復旧後は滞留イベントを順序通り処理してから再開します。
Q40. リアルタイム化の費用に見合うか、どう判断しますか？
A. 実施したい施策によって変わりますが、一般的なＣＲＭツールはリアルタイムが望ましいデータはリアルタイムで取得する事が多いです。費用対効果は施策によっても変わる為、導入前の判断の場合はうサービスの提供元へ相談してみましょう。
9. 複数カート連携に関する5つの質問
Q41. 複数カートのデータ項目を、どのように共通化しますか？
A. 注文、顧客、商品ごとに共通モデルを作り、各カート固有項目は変換層で対応します。共通化のために重要な固有情報を捨てないよう拡張欄も設けます。
Q42. 同じ顧客が複数のカートを利用した時、IDを統合できますか？
A. 確定会員IDや本人確認済み情報で対応表を作れば可能です。カート横断の推定一致は信頼度を分け、誤統合時に元へ戻せる構造にします。
Q43. 複数カートに同じ注文番号がある場合、衝突をどう防ぎますか？
A. 一例として、カート識別子と注文番号の複合キーにする方法などがあります。
Q44. カートごとに異なる商品・キャンペーンを、CRMでどう識別しますか？
A. 元カートID、商品対応表、キャンペーン対応表を注文へ保持します。同名の商品・企画を統合せず、横断集計時だけ共通カテゴリへ変換します。
Q45. カートを切り替える際、旧カートの履歴をどう引き継ぎますか？
A. 旧IDと新IDの対応、注文・会員・同意・ポイントの移行基準を決めます。移行前後の件数と金額を照合し、旧データを即時削除しない方がよいでしょう。。
10. 連携エラー監視に関する5つの質問
Q46. 連携エラー監視では、成功・失敗以外に何を見ますか？
A. 件数、金額、遅延、欠損、重複、最終更新時刻、未処理滞留を監視します。処理が成功してもゼロ件が続く異常を検知できるようにします。
Q47. 失敗データを自動再送する時、無限リトライをどう防ぎますか？
A. エラー状況はアラートが出るように対応している企業が多いです。無限リトライに限らずアラートからの即時対応が重要な為、アラートと即時対応を実施しているかどうかを確認するようにしましょう。
Q48. 連携障害はどのように防ぎますか？
A. 主な連携障害は、予測がしきれない場合に発生する事が多いです。その為、発生をしてしまった場合の、アラート、利用者への通知、回収、同様の障害が起きないように事前対策を行う事が重要です。
Q49. エラーが出ていなくても、データ欠損を発見できますか？
A. カートとCRMの件数・金額・ID集合を定期照合すれば発見できます。前日比やゼロ件も監視し、正常終了ログだけを品質保証にしません。
Q50. 連携障害から復旧した後、何を確認して運用を再開しますか？
A. 滞留解消、重複・欠損、順序、同意、金額を照合し、影響した施策を再抽出します。再発防止策と監視確認後に段階的に配信を戻します。
まとめ
CRMとECカートの連携では、データを送ることより、正本・ID・更新順・同意・再処理を決めることが重要です。件数と金額の照合、遅延・欠損の監視、障害時の施策停止まで含めて運用してください。
関連情報
LTV-Labの機能：https://ltv-lab.jp/function/
料金：https://ltv-lab.jp/price/
無料デモ・お問い合わせ：https://ltv-lab.jp/contact/
LTVラボの記事一覧：https://ltv-lab.jp/ltvlab/