Show Menu
トピック×

データモデルのベストプラクティス

このドキュメントでは、Adobe Campaignデータモデルをデザインする際の主要な推奨事項について説明します。
Adobe Campaignの事前定義データモデルを拡張するためのリソースを作成および変更するには、この節を参照し てください
標準搭載のリソースのデータモデル表現は、こちらで確認でき ます

概要

Adobe Campaignシステムは非常に柔軟性が高く、初期実装を超えて拡張できます。 ただし、可能性は無限ですが、賢明な判断を下し、データモデルを設計する開始の強力な基盤を築くことが重要です。
このドキュメントでは、Adobe Campaignツールを適切に設計する方法を学ぶための一般的な使用例とベストプラクティスを紹介します。

データモデルのアーキテクチャ

Adobe Campaign Standardは、オンラインおよびオフラインの戦略を調整して、パーソナライズされた顧客エクスペリエンスを作成するのに役立つ、強力なチャネル間キャンペーン管理システムです。

顧客中心アプローチ

ほとんどの電子メールサービスプロバイダーはリスト中心のアプローチを通じて顧客と通信しますが、Adobe Campaignは、顧客とその属性の幅広い表示を活用するためにリレーショナルデータベースに依存しています。
この顧客中心アプローチは、次の図のとおりです。 灰色の プロファイル ・リソースは、すべてが構築される主要な顧客テーブルを表します。
この節では、Adobe Campaignのデフォルトのデータモデルについて説明 します

Adobe Campaignのデータ

Adobe Campaignに送信するデータを教えてください。 マーケティングアクティビティに必要なデータを判断することが重要です。
Adobe CampaignはData Warehouseではありません。 したがって、可能な顧客とその関連情報をすべてAdobe Campaignにインポートしないでください。
属性がAdobe Campaignで必要かどうかを判断するには、次のいずれかのカテゴリに該当するかどうかを決定します。
  • セグメント化に使用する 属性
  • 属性を使用した データ管理 (集計計算など)
  • パーソナライゼーションに使用され る属性
  • 属性を使用して レポート (カスタムデータに基づいてレポートをプロファイル可能)
これらのいずれにも該当しない場合、Adobe Campaignでこの属性は必要ない可能性が高くなります。

データタイプ

システムのアーキテクチャとパフォーマンスを確実に保つには、次のベストプラクティスに従ってAdobe Campaignでデータを設定します。
  • 文字列フィールドの長さは、常に列で定義する必要があります。 デフォルトでは、Adobe Campaignの最大長は255文字ですが、サイズが短い長さを超えないことが既にわかっている場合は、フィールドを短くすることをお勧めします。
  • ソースシステムのサイズが過大評価され、サイズに達しないことが確実な場合は、Adobe Campaignのフィールドをソースシステムのフィールドよりも短くすることが許容されます。 これは、Adobe Campaignの文字列が短いか、整数が小さいことを意味します。

データ構造の設定

ここでは、リソースのデータ構造を設定す る際のベストプラクティスについて説明します

識別子

Adobe Campaignリソースには3つの識別子があり、識別子を追加できます。
次の表に、これらの識別子とその目的を示します。
表示名は、Adobe Campaignユーザーインターフェイスを介してユーザーに表示されるフィールドの名前です。 技術的な名前は、リソース定義の実際のフィールド名(およびテーブルの列名)です。
表示名
技術名
説明
ベストプラクティス
主キー
  • PKeyは、Adobe Campaignテーブルの物理的な主キーです。
  • この識別子は、通常、特定のAdobe Campaignインスタンスに対して一意です。
  • Adobe Campaign Standardでは、この値はエンドユーザーには表示されません(URLを除く)。
  • APIシステムを介して 、PKey値(物理キーではなく生成/ハッシュ値)を取得できます。
  • APIを使用してレコードを取得、更新、削除する以外の目的で使用することはお勧めしません。
ID
nameまたはinternalName
  • この情報は、テーブル内のレコードの一意の識別子です。 この値は手動で更新できます。
  • この識別子は、Adobe Campaignの別のインスタンスにデプロイする場合に値を保持します。 生成された値とは異なる名前を持ち、パッケージを介してエクスポートできる必要があります。
  • これは、テーブルの実際の主キーではありません。
  • スペース""、セミコロン":"、ハイフン"-"などの特殊文字は使用しないでください。
  • これらの文字はすべて、アンダースコア「_」(文字を使用できます)で置き換えられます。 例えば、「abc-def」と「abc:def」は「abc_def」として保存され、相互に上書きされます。
ラベル
label
  • ラベルは、Adobe Campaignのオブジェクトまたはレコードのビジネス識別子です。
  • このオブジェクトでは、スペースと特殊文字を使用できます。
  • レコードの一意性を保証するものではありません。
  • オブジェクトのラベルの構造を決定することをお勧めします。
  • これは、Adobe Campaignユーザーのレコードやオブジェクトを識別するための、最も使いやすいソリューションです。
ACS ID
acsId
  • 追加の識別子を生成できます。acs ID
  • PKeyはAdobe Campaignユーザーインターフェイスで使用できないので、これはプロファイルレコードの挿入時に生成される一意の値を取得するためのソリューションです。
  • この値は、レコードがAdobe Campaignに挿入される前に、リソースでこのオプションが有効になっている場合にのみ、自動的に生成されます。
  • このUUIDは、紐付けキーとして使用できます。
  • 自動生成されたACS IDは、ワークフローまたはパッケージ定義の参照として使用できません。
  • この値は、Adobe Campaignインスタンスに固有の値です。

識別キー

Adobe Campaignで作成される各リソースには、一意のIDキーが1つ以上必要 です
カスタムリソースを作成する場合は、次の2つのオプションがあります。
  • 自動生成されたキーと内部カスタムキーの組み合わせ。 このオプションは、システムキーが複合キーであるか、整数でない場合に興味深いものです。 整数は、大きなテーブルで高いパフォーマンスを得るとともに、他のテーブルとの結合を行います。
  • プライマリ・キーを外部システムのプライマリ・キーとして使用する。 異なるシステム間で一貫したキーを使用して、データのインポートとエクスポートのアプローチを簡素化するので、このソリューションをお勧めします。
識別キーは、参照として使用しないでください(ワークフロー)。

インデックス

Adobe Campaignは、リソースで定義され ている 、すべての主キーと内部キーにインデックスを自動的に追加します。
  • パフォーマンスが向上する可能性があるので、追加のインデックスを定義することをお勧めします。
  • ただし、インデックスがデータベース上の領域を使用するので、追加するインデックスの数は多すぎないでください。 また、多数のインデックスがパフォーマンスに悪影響を与える場合もあります。
  • 定義するインデックスを慎重に選択します。

パフォーマンス

パフォーマンスをいつでも向上させるには、次のベストプラクティスに従ってください。

一般的な推奨事項

  • 「次を含む」などの操作は使用しないでください。クエリ 何を求め、フィルタリングを行うかがわかっている場合は、「EQUAL TO」などの特定のフィルタ演算子を使用して同じ条件を適用します。
  • データをインデックスで作成する際は、インデックスのないフィールドとの結合を避けてください。ワークフローで。
  • インポートやエクスポートのようなプロセスが業務時間外に発生することを確認します。
  • すべての日別アクティビティのスケジュールがあることを確認し、スケジュールに従います。
  • 日別のプロセスの1つまたは複数が失敗し、その同じ日に実行する必要がある場合は、手動プロセスが開始されたときに競合するプロセスが実行されていないことを確認します。システムのパフォーマンスに影響を与える可能性があります。
  • 読み込みプロセス中、または手動のキャンペーンが実行されている場合は、毎日のプロセスが実行されないことを確認します。
  • 各行のフィールドを複製する代わりに、1つまたは複数の参照テーブルを使用します。 キーと値のペアを使用する場合は、数値キーを選択することをお勧めします。
  • 短い文字列は引き続き使用できます。 参照テーブルが既に外部システムに配置されている場合、同じテーブルを再利用すると、Adobe Campaignとのデータ統合が容易になります。

1対多の関係

  • データデザインは、ユーザビリティと機能に影響を与えます。 多くの1対多の関係を使用してデータモデルを設計する場合、ユーザーがアプリケーションで意味のあるロジックを作成するのが難しくなります。 1対多のフィルターロジックは、技術的でないマーケターが正しく構築し、理解するのが困難な場合があります。
  • すべての重要なフィールドを1つのテーブルに含めると、ユーザーが必要なフィールドを簡単に作成できるので、便利です。クエリ また、結合を避けることができる場合に、一部のフィールドをテーブルに重複するのも、パフォーマンスが向上する場合があります。
  • 組み込み機能の中には、1対多の関係(オファーの重み付けの式や配信など)を参照できないものもあります。

大きいテーブル

大きなテーブルと複雑な結合を使用してデータモデルを設計する際に従うべきベストプラクティスを、以下に示します。
  • 特に未使用の列を識別して、列の数を減らします。
  • 複数の条件や複数の列での結合など、複雑な結合を避け、データモデルの関係を最適化します。
  • 結合キーの場合、文字列ではなく常に数値データを使用します。
  • ログの保存の深さをできる限り減らします。 より深い履歴が必要な場合は、集計の計算やカスタムログテーブルの処理を行って、より大きな履歴を保存できます。