データモデルの設計

学習の目的

この単元を完了すると、次のことができるようになります。

データソースを特定する。
Marketing Cloud Engagement に保存するデータを指定する。
Contact Builder で使用するデータモデルを設計する。

始める前に

このモジュールを受講する前に、「Marketing Cloud Engagement 連絡先管理」を完了しておく必要があります。ここでの作業は、そのバッジでの概念や作業に基づいて行います。

データ活用の準備

開発者の皆さんは、会社のデータを Marketing Cloud Engagement に組み込むことにワクワクしていることでしょう。ただし、どこから始めればよいかわからないという人もいるでしょう。それなら、これはあなたにぴったりのモジュールです。Marketing Cloud Engagement にデータを移動することは、新しい家に引っ越すことに似ています。引っ越しの前には、いくつかの作業が必要です。

何を残しておくかを決める。
ラベルを付けて、箱に詰める。
新しい場所で、物をどこに置くかを決める。

これは、データの場合にも当てはまります。さっそく、移動の準備を始めましょう。

データの特定

ご存知のとおり、データは、Web フォーム、Web 分析サービス、設定センター、POS システム、ソーシャルメディアなど、多くのソースから発生します。そのため、ブレインストーミングを行って現在のデータソースと潜在的なデータソースをすべて特定することが重要です。通常、このステップにはチームワークを要するため、まだ行っていない場合は、ホワイトボードを用意し、同僚を集めて、意見を出し合いましょう。ご心配なく。ここで待っていますので実行してみてください。

レコードのデータベースの選択

潜在的なデータソースを特定したら、次はレコードのデータベース (DBOR) を選択します。DBOR は、購読者のオプトインステータスと購読者についての一般情報の情報源です。ここで、顧客についてのほとんどの最新情報を見つけることができます。また、この決定は、Marketing Cloud Engagement がどのデータをどの程度の頻度で送受信する必要があるかの決定にも役立ちます。

外部 Web サイト、コマース、分析、POS、プロファイルセンター、CSV などが含まれている Marketing Cloud Engagement データソース。 どのデータを移動するか

データを明確に把握できたら、次は Marketing Cloud Engagement に何を移動するかを決定します。キャンペーンのセグメンテーションとパーソナライズに使用するデータのみを選択します。たとえば、POS システムには購入の日付や説明などの有用なデータが含まれていますが、SKU や卸売価格など、顧客に共有することがない情報も含まれています。Marketing Cloud Engagement にあらゆる種類のデータをインポートできるからといって、そうするべきだということはありません。さらに、機密データや個人を特定できるデータ (誕生日など) は、セグメンテーションや Transactional メッセージに不可欠な場合のみ保存します。

ラベルの設定

必要なデータを把握したら、ラベルの設定を開始できます。まず、Marketing Cloud Engagement のフィールド種別 (数値、テキスト、日付、ブール値、小数、メール、電話番号、ロケール) に基づいてデータのラベルを設定します。次に、キーにラベルを設定して指定します。どのキーのことでしょうか? よくぞ聞いてくれました。3 つのキーがあります。

外部キー: Marketing Cloud Engagement では、リレーショナルデータベースを使用してデータが整理されています。この種類の構造では、外部キーは 2 つの一意のテーブルまたはソース間のデータを関連付けるために使用されます。たとえば、顧客データエクステンションに CustomerID があり、POS データソースに PurchaserID があるとします。名前は異なりますが、これらのフィールドは同じ顧客です。そのため、これらのフィールドは、これらの 2 つのデータを関連付ける外部キーとなります。
連絡先キー: 連絡先キーは、Marketing Cloud Engagement アカウント内で連絡先を識別するために割り当てる一意の値です。(Email Studio の購読者キーとしてご存知かもしれません。)
プライマリキー: Marketing Cloud Engagement のプライマリキーは、特定の一意のデータポイントを識別するデータエクステンション上の一意のフィールドです。これは、連絡先キーであることが多いですが、そのデータに対して一意であれば他の値も使用できます。たとえば、製品カタログデータエクステンションでは、SKU が一意な識別子になり、そのため、プライマリキーとして使用できます。

まだキーを決定していない場合は、モデルに一貫性のある連絡先キーを指定することが重要です。ベストプラクティスを再確認しましょう。

連絡先キーのベストプラクティス

一貫性を維持するには、Email Studio の購読者キー値を Contact Builder の一意の連絡先キー値として使用します。
特定のチャネルに関連しない一意の値を使用します。
顧客の行動に基づいて変更されることがない連絡先キー値を使用します。
Marketing Cloud Connect を使用する場合、ベストプラクティスとしてリード ID または連絡先 ID を連絡先キーとして使用します。この ID を使用すると、Sales Cloud データと Service Cloud データが自動的に同期されるため、すべてのクラウドで一貫した識別子を使用できます。