Data 360 小売とは、POS、Web サイト、Zalo のデータを1つの顧客プロファイルに統合し、店舗で買った人が Web サイトを見ていた人と同一人物かどうかを把握できるようにする取り組みです。先週店舗で買ったばかりなのに、今日も同じ商品の広告が届く。それは2つのシステムがお互いを知らないからです。
この記事は想定シナリオであり、実在のお客様ではありません。アプローチは4つのステップです。3つのデータソースを Data 360 に取り込み、電話番号とメールで同一の顧客を識別し、リピート購入者やカゴ落ち顧客などの segment を作り、その segment を Marketing Cloud に送ります。最大の教訓は、主要な収集ポイントで電話番号の表記をそろえることが、どんなツールよりも重要だという点です。
ご注意: これは想定シナリオです。記事内の15店舗のチェーン、顧客プロファイル、対応方法はすべて仮想のもので、Sonix のお客様ではなく、結果の数値も示していません。機能は edition や license によって異なり、メニュー名もバージョンで変わる場合があります。Zalo は標準で用意されたソースではないため、個別の連携が必要です。個人データや費用に関する内容は一般的な参考情報であり、法務・財務上の助言ではありません。
想定シナリオ:3つのデータソースが同一の顧客として識別され、Marketing Cloud に送られます。背景:15店舗のチェーンと分断された3つのデータソース
想定シナリオ:ある小売チェーンは15店舗、Web ストア、顧客対応用の Zalo OA を持っています。それぞれが別々にデータを持っており、経営層が答えられない問いは「店舗で買った人は、Web サイトを見ていた人と同じか」です。
| ソース | 主なデータ | 顧客の識別方法 |
|---|---|---|
| 店舗の POS | レジでの購入履歴 | 会員登録時の電話番号が一般的 |
| Web サイト | アカウント、閲覧した商品、カゴ落ち | メール、入力があれば電話番号 |
| Zalo OA | メッセージの反応、OA のフォロー | Zalo 独自の ID。電話番号がない場合もある |
3つのソースがお互いを知らないため、買ったばかりの人に広告を送る、カゴ落ちした人に声をかけられない、複数のチャネルを行き来する顧客の全体像がない、といったよくある問題が起きます。
Data 360 小売:4つのステップ
次の4ステップは、プラットフォームの一般的な流れに沿っています。識別と統合の部分は顧客データの統合とモデリングに関する Trailhead モジュール(英語)で実習できます。まず基本を押さえたい方は、Data 360: 4 steps to unify customer data(英語)をお読みください。
3つのソースを Data 360 に取り込む
- POS と Web サイトは、利用中のシステムに応じて connector や API で接続します
- Zalo は標準のソースではないため、個別の連携が必要です。技術的な方法の1つが、技術チームが行うIngestion API(英語)経由でのデータ投入です
同一の顧客を識別する
- match rule を設定します。同じメール、または正規化した同じ電話番号なら同一人物とみなします
- reconciliation rule を設定します。ソース間で値が異なるとき、どのソースを優先するかを決めます
segment を作る
- 例:リピート購入者、カゴ落ち顧客、閲覧のみで未購入の顧客
- 統合プロファイルに基づく segment は、3つのチャネルすべての行動を反映します
segment を Marketing Cloud に送る
- segment を activate し、マーケティングチームが適切な相手にオファーを送れるようにします
- 買ったばかりの人は、同じ商品の広告の対象から外します
例:1人の顧客、3つの痕跡
仮想の例:1人の顧客が3か所に次のように現れます。以下の名前や情報はすべてサンプルデータです。
| ソース | 名前 | 電話 | メール | 行動 |
|---|---|---|---|---|
| POS | Lan さん | 0901 234 567 | (空) | 店舗で保温ボトルを購入 |
| Web サイト | Lan Tran | 0901234567 | lan.tran@example.com | 別の商品を閲覧し、カゴ落ち |
| Zalo OA | Lan Tran | (空) | (空) | OA をフォローし、オファーのメッセージを開封 |
正規化した電話番号の match rule で、POS と Web のプロファイルが結び付きます。0901 234 567 と 0901234567 は、空白を除けば同じ番号だからです。これで、店舗で買った人が Web サイトを見ていた人だと分かります。
Zalo のプロファイルは難しくなります。電話番号もメールもないため、顧客が電話番号を提供するか、アカウントを連携した場合にしか結び付けられません。これはどのツールでも起きる現実的な限界ですので、すべての Zalo プロファイルが一致するとは期待しないでください。
統合後は、買ったばかりの商品の広告を止める、カゴに残した商品を控えめにリマインドする、という2つのシンプルで有用なことができます。想定シナリオのため、結果の数値は示していません。
小売業の方は、Sonix の小売向けソリューション(英語)もご覧ください。
教訓:電話番号の表記をそろえる
例を振り返ると、Data 360 小売の成否を分けるのはツールではなく入力データです。電話番号の表記が場所ごとに違えば、同じ人の2つのプロファイルは決して出会いません。
| 収集ポイント | よくある状況 | そろえるべきこと |
|---|---|---|
| 店舗のレジ | 0901 234 567、0901.234.567、+84901234567 | 表記を1つに。例:0で始まる10桁、スペースなし |
| Web フォーム | 自由入力 | 入力時に形式をチェック |
| Zalo OA | 顧客が番号を残さない | 適したオファーがあるときに電話番号を依頼 |
| メール | 大文字小文字が混在 | 小文字に統一して保存 |
何かを設定する前に、主要な収集ポイントでこのルールをそろえましょう。プラットフォームにデータが流れ込んだ後で修正するよりも、はるかに安く済みます。
始める前に検討しておきたいこと
顧客の同意と個人データ。オファー送付のためにデータを統合することは、個人データを処理することを意味します。顧客の同意を記録し、現行の個人データ保護に関する規則を確認してください。これは一般的な参考情報であり、法的助言ではありません。
費用。Data 360 と Marketing Cloud にはそれぞれ license があり、Data 360 は通常、利用量に応じた課金です。公式の料金ページを確認し、実際のニーズに基づく見積もりを取りましょう。これは一般的な参考情報であり、財務上の助言ではありません。
人的リソース。Zalo 連携、データの標準化、match rule の設定には経験者が必要です。社内チームで行うか、導入パートナーに任せるかを検討しましょう。
小さく始める。手を広げず、買ったばかりの商品の広告を止めるなど、具体的な1つの用途から始めましょう。Salesforce ソリューション全般はSonix の Salesforce ページ(ベトナム語)もご覧ください。
Data 360 小売:データ統合の前に確認するチェックリスト
多くの店舗とオンラインチャネルをお持ちなら、次のリストを確認しましょう。
☐ 顧客データのソース(POS、Web、Zalo、その他のチャネル)を洗い出した
☐ 突合に使う共通項目(電話番号とメールなど)を決めた
☐ すべての収集ポイントで電話番号とメールの表記をそろえた
☐ Zalo の連携方法と担当者を決めた
☐ リピート購入者やカゴ落ちなど、具体的な用途を1〜2件に絞った
☐ 顧客の同意を記録する方法を用意した
☐ 有効化の前に license と課金方法を確認した
御社には、店舗とオンラインチャネルがいくつありますか? コメントに数をお書きください。Sonix チームが、最初の一歩をご提案します。
Salesforce
Data 360
Salesforce Marketing Cloud
顧客体験
ビジネス
Sonix との無料相談で、顧客データのソースを整理し、データ基盤に投資する前に最適な最初の一歩を見極めましょう。
Sonix: Your success is our happiness.

コメントを残す