データモデルの設計
学習の目的
この単元を完了すると、次のことができるようになります。
- データソースを特定する。
- Marketing Cloud Engagement に保存するデータを指定する。
- Contact Builder で使用するデータモデルを設計する。
始める前に
このモジュールを受講する前に、「Marketing Cloud Engagement 連絡先管理」を完了しておく必要があります。ここでの作業は、そのバッジでの概念や作業に基づいて行います。
データ活用の準備
開発者の皆さんは、会社のデータを Marketing Cloud Engagement に組み込むことにワクワクしていることでしょう。ただし、どこから始めればよいかわからないという人もいるでしょう。それなら、これはあなたにぴったりのモジュールです。Marketing Cloud Engagement にデータを移動することは、新しい家に引っ越すことに似ています。引っ越しの前には、いくつかの作業が必要です。
- 何を残しておくかを決める。
- ラベルを付けて、箱に詰める。
- 新しい場所で、物をどこに置くかを決める。
これは、データの場合にも当てはまります。さっそく、移動の準備を始めましょう。
データの特定
ご存知のとおり、データは、Web フォーム、Web 分析サービス、設定センター、POS システム、ソーシャルメディアなど、多くのソースから発生します。そのため、ブレインストーミングを行って現在のデータソースと潜在的なデータソースをすべて特定することが重要です。通常、このステップにはチームワークを要するため、まだ行っていない場合は、ホワイトボードを用意し、同僚を集めて、意見を出し合いましょう。ご心配なく。ここで待っていますので実行してみてください。
レコードのデータベースの選択
潜在的なデータソースを特定したら、次はレコードのデータベース (DBOR) を選択します。DBOR は、購読者のオプトインステータスと購読者についての一般情報の情報源です。ここで、顧客についてのほとんどの最新情報を見つけることができます。また、この決定は、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 が一意な識別子になり、そのため、プライマリキーとして使用できます。
まだキーを決定していない場合は、モデルに一貫性のある連絡先キーを指定することが重要です。ベストプラクティスを再確認しましょう。
連絡先キーのベストプラクティス |
---|
|
データモデルの設計
データが集まったところで、これらはすべてどこに行くのでしょうか? 「Marketing Cloud Engagement 連絡先管理」モジュールで学習したデータデザイナーインターフェースを覚えていますか? 次は、そこに向かいます。
データデザイナーには、次のものが含まれます。
- データソース: ここで、すべてのデータソース (同期されたソースとカスタムソースを含む) を指定し、整理します。
- データエクステンション: ここで、データのプレースホルダーを作成します。データエクステンションは Email Studio でも作成できます。
- 属性グループ: これは、データモデルを整理する方法です。属性グループ内には、属性セットまたはデータエクステンションがあり、属性はデータエクステンション内のフィールドです。
- 母集団: これらは、独自の属性または識別子を持つ人の集団やデータモデルを区別するために使用されます。母集団は、顧客と従業員に対してコミュニケーションのモデルや構造が異なる会社にとって有用です。
これらは、データモデルの設計に使用する基本ツールです。これらは互いにどのように関連しているのでしょうか? 属性グループはデータエクステンションのコレクションであり、共有する共通のデータに基づいてそれらを関連付けるリンクがあります。見込み客の属性グループの例を見てみましょう。
データソース | 関連するデータエクステンション | データのつながり |
---|---|---|
外部設定センター | マスター顧客 | マスター顧客データエクステンションでは、CustomerID をプライマリキー属性として識別します。 |
Web サイト閲覧アクティビティ | Web アクティビティ | Web アクティビティデータエクステンションは、外部キー属性 CustomerID によってマスター購読者データエクステンションとリンクされています。 |
小売購入データ (POS) | 顧客購入 | 顧客購入データエクステンションは、外部キー属性 CustomerID によってマスター購読者データエクステンションとリンクされています。 |
製品カタログ CSV | 製品カタログ | 製品カタログは、外部キー属性 ProductID によって顧客購入とリンクされています。 |
おわかりのように、データエクステンション構造を決定することは重要です。次の質問について考慮します。
- すべての外部データソースに対してデータエクステンションが必要か?
- 購読者情報を保存するマスターデータエクステンションを作成するか?
- 個別のキャンペーンを送信するために、オーディエンスをどのようにセグメント化するか?
- フィルター済みデータエクステンションを使用するか?
- コンテンツは、送信のために使用できるか、それとも送信不可能なコンテンツか?
- データエクステンションのデータはどの程度の頻度で更新されるか?
あらゆるビジネスには独自のニーズがあるため、Marketing Cloud Engagement でデータモデルを設計する正しい方法や間違った方法というものはありません。データモデルとデータエクステンションを最終決定する前に、同僚と相談しましょう。
お疲れ様でした。多くのことを学習したので、データモデルを設計し、Contact Builder での作成の準備を行うための手順の概要をチェックリストにまとめました。
- すべての潜在的なソースからのすべてのデータをリストする。
- DBOR を選択し、Marketing Cloud Engagement で送受信する必要のあるデータを決定する。
- キャンペーンのセグメンテーションとパーソナライズに必要なデータを決定する。
- データの種別にラベルを設定し、データソース間で共通するフィールドを特定する。
- Marketing Cloud Engagement にインポートする必要があるデータソースとデータフィールドを最終決定する。
- データを保存するために作成する必要があるデータエクステンションを特定する。
次は、データモデルの作成を開始します。