このドキュメントでは、Adobe Campaignデータモデルを設計する際の主な推奨事項の概要を説明します。
キャンペーンの組み込みテーブルとそのやり取りについての詳細は、このセクションを参照してください。
キャンペーンスキーマを使い始めるには、このドキュメントを読んでください。 このドキュメントのAdobe Campaignデータベースの概念データモデルを拡張するための拡張スキーマの設定方法を説明します。
Adobe Campaignシステムは非常に柔軟性が高く、最初の実装以外にも拡張できます。 ただし、可能性は無限ですが、賢明な判断を下し、開始がデータモデルを設計するための強力な基盤を構築することは非常に重要です。
このドキュメントでは、Adobe Campaignツールを適切に設計する方法を学ぶための一般的な使用例とベストプラクティスを紹介します。
Adobe Campaign Standardは、オンラインとオフラインの戦略を調整して、パーソナライズされた顧客体験を作り出すのに役立つ強力なクロスチャネルキャンペーン管理システムです。
ほとんどの電子メールサービスプロバイダーはリスト中心アプローチを使用してお客様と通信していますが、Adobe Campaignは、お客様とその属性の幅広い表示を活用するために、リレーショナルデータベースに依存しています。
この顧客中心アプローチは、次の図のようになります。 灰色の受信者テーブルは、すべての作成が行われている主な顧客テーブルを表します。
各テーブルの説明にアクセスするには、管理者/設定/データスキーマに移動し、リストからリソースを選択して、「ドキュメント」タブをクリックします。
Adobe Campaignのデフォルトのデータモデルは、このドキュメントに表示されます。
Adobe Campaign Classicはカスタム顧客テーブルの作成を許可します。 ただし、ほとんどの場合は、標準の受信者テーブルを利用することをお勧めします。標準のテーブルには、既に追加のテーブルや機能が組み込まれています。
Adobe Campaignに送信するデータ マーケティングアクティビティに必要なデータを決定することが重要です。
Adobe Campaignは、データウェアハウスでもレポートツールでもありません。 したがって、可能な顧客とその関連情報をすべてAdobe Campaignにインポートしたり、レポートの作成にのみ使用されるデータをインポートしたりしないでください。
属性をAdobe Campaignに必要とするかどうかを判断するには、次のカテゴリのいずれかに該当するかどうか自問してください。
これらのいずれかに該当しない場合、Adobe Campaignでこの属性は必要ないと思われます。
システムのアーキテクチャとパフォーマンスを確実に保つには、次のベストプラクティスに従ってAdobe Campaignでデータを設定します。
ターゲット設定またはパーソナライゼーションの目的を持つフィールドは、テーブルに格納する必要があります。 つまり、パーソナライズされた電子メールの送信にフィールドを使用しない場合や、クエリの基準として使用する場合は、ディスク領域を使用しますが、使用できません。
ハイブリッドインスタンスおよびオンプレミスインスタンスの場合、FDA(Federated Data Access、外部データへのアクセスを可能にするオプション機能)は、キャンペーンプロセス中にフィールドをその場で追加する必要性をカバーします。 FDAがある場合は、すべてを読み込む必要はありません。 詳しくは、Federated Data Accessについてを参照してください。
ほとんどのテーブルでデフォルトで定義されているautopkに加えて、論理キーやビジネスキー(アカウント番号、クライアント番号など)を追加することを検討してください。 後でインポート/調整またはデータパッケージに使用できます。 詳しくは、識別子を参照してください。
パフォーマンスを高めるには、効率的なキーが不可欠です。 数値データ型は、テーブルのキーとして常に推奨されます。
SQLServerデータベースの場合、パフォーマンスが必要な場合は、「クラスター化インデックス」の使用を検討できます。 Adobeはこの処理を行わないので、SQLで作成する必要があります。
スキーマの表領域属性を使用すると、表の専用の表領域を指定できます。
インストールウィザードでは、種類(データ、一時、インデックス)別にオブジェクトを保存できます。
専用テーブルスペースは、パーティション化、セキュリティ・ルールに適しており、流動的で柔軟な管理、最適化、パフォーマンスを実現できます。
Adobe Campaignリソースには3つの識別子があり、別の識別子を追加できます。
次の表に、これらの識別子とその目的を示します。
識別子 | 説明 | ベストプラクティス |
---|---|---|
ID |
|
|
名前(または内部名) |
|
|
ラベル |
|
|
プライマリキーは、Adobe Campaignで作成されるすべてのテーブルに必要です。
ほとんどの組織は、外部システムからレコードを読み込んでいます。 受信者テーブルの物理キーは「id」属性ですが、カスタムキーを特定することもできます。
このカスタムキーは、外部システムフィードAdobe Campaignの実際のレコードの主キーです。
あらかじめ用意されているテーブルに、オートプックと内部キーの両方が付いている場合、その内部キーは物理データベーステーブル内の一意のインデックスとして設定されます。
カスタムテーブルを作成する場合は、次の2つのオプションがあります。
ワークフローでは、オートパックを参照として使用しないでください。
Adobe Campaignの主キーは、あらかじめ用意されているすべてのテーブルに対して自動生成されるIDで、カスタムテーブルに対しても同じIDを使用できます。 詳しくは、この節を参照してください。
この値は、シーケンスと呼ばれる、番号シーケンスの生成に使用されるデータベースオブジェクトから取得されます。
シーケンスには2種類あります。
シーケンスは32ビットの整数値で、使用可能な値の最大数は有限です。21億4000万 最大値に達した後、シーケンスは0に戻り、IDをリサイクルします。
古いデータが削除されない場合は、一意のキー違反が発生し、プラットフォームの正常性と使用状況の阻害要因となります。 Adobe Campaignは通信を送信できず(配信ログテーブルに影響が出た場合)、パフォーマンスに大きな影響を与えます。
したがって、顧客が年間60億通の電子メールを送信し、そのログの保存期間が180日の場合、4か月でIDが不足することになります。 このようなチャレンジを回避するには、ボリュームに応じてパージ設定を行う必要があります。 詳しくは、この節を参照してください。
主キーをautoPKとしてAdobe Campaignしてカスタムテーブルを作成する場合は、カスタム専用シーケンスをそのテーブルに系統的に関連付ける必要があります。
デフォルトでは、カスタムシーケンスの値は+1,000 ~ +2.1BBです。 技術的には、除外idを有効にすることで、4BBのフルレンジを取得できます。 この値は注意して使用し、負の数値から正の数値に渡すと1つのIDが失われます。通常、生成されたSQLクエリのAdobe Campaignではレコード0が無視されます。
関連トピック:
パフォーマンスにはインデックスが不可欠です。 スキーマでキーを宣言すると、Adobeは自動的にキーのフィールドにインデックスを作成します。 また、キーを使用しないクエリのインデックスをさらに宣言することもできます。
Adobeでは、パフォーマンスが向上する可能性があるので、追加のインデックスを定義することをお勧めします。
ただし、次の点に注意してください。
インデックスの管理は非常に複雑になる場合があるので、その動作を理解することが重要です。 この複雑さを説明するために、受信者を名と姓でフィルター処理して検索するなど、基本的な例を見てみましょう。 手順は次のとおりです。
データベース内のすべての受信者をリストするフォルダーに移動します。 詳しくは、プロファイルの管理を参照してください。
名フィールドを右クリックします。
「このフィールドに対するフィルター」を選択します。
姓フィールドに対してこの操作を繰り返します。
対応する2つのフィルターが画面の上部に追加されます。
様々なフィルター条件に従って、名フィールドと姓フィールドに対して検索フィルターを実行できるようになりました。
これらのフィルターの検索を高速化するために、インデックスを追加できます。 しかし、どのインデックスを使用すべきか。
この例は、PostgreSQLデータベースを使用するホスト顧客に適用されます。
次の表に、最初の列に表示されるアクセスパターンに従って、以下に示す3つのインデックスが使用される場合、または使用されない場合を示します。
検索条件 | インデックス1 (名+姓) | インデックス2 (名のみ) | インデックス3(姓のみ) | コメント |
---|---|---|---|---|
名は「ジョニー」に等しい | 使用済み | 使用済み | 未使用 | 名はインデックス1の最初の位置にあるので、いずれにせよ使用されます。姓に条件を追加する必要はありません。 |
名は「Johnny」、姓は「Smith」に等しい | 使用済み | 未使用 | 未使用 | 両方の属性が同じクエリで検索されるので、両方の属性を組み合わせたインデックスのみが使用されます。 |
姓が「Smith」と等しい | 未使用 | 未使用 | 使用済み | インデックス内の属性の順序が考慮されます。 この順序と一致しない場合、インデックスが使用されない可能性があります。 |
「Joh」を含む名の開始 | 使用済み | 使用済み | 未使用 | 「左検索」はインデックスを有効にします。 |
名が「nny」で終わる | 未使用 | 未使用 | 未使用 | 「右検索」はインデックスを無効にし、フルスキャンを実行します。 特定のインデックスタイプの中には、この使用例を扱うものもありますが、Adobe Campaignではデフォルトで使用できないものもあります。 |
名に「John」を含む | 未使用 | 未使用 | 未使用 | これは、「左」と「右」の検索の組み合わせです。 後者の場合はインデックスが無効になり、フルスキャンが実行されます。 |
名が「john」と等しい | 未使用 | 未使用 | 未使用 | インデックスでは大文字と小文字が区別されます。 大文字と小文字を区別しないようにするには、「upper(firstname)」のようなSQL関数を含む特定のインデックスを作成する必要があります。 「unaccent(firstname)」など、他のデータ変換にも同様の処理を行う必要があります。 |
大きなテーブルでは、「独自の」整合性に注意してください。 ワイドテーブルを持つレコードを「独自の」整合性で削除すると、インスタンスが停止する場合があります。 テーブルはロックされ、削除は1つずつ行われます。 したがって、大量の子テーブルには「中立」の整合性を使用することをお勧めします。
リンクを外部結合として宣言するのは、パフォーマンスには適していません。 ゼロIDレコードは外部結合機能をエミュレートします。 リンクでオートプックを使用する場合は、外部結合を宣言する必要はありません。
ワークフロー内の任意のテーブルを結合できますが、Adobeでは、リソース間の共通リンクをデータ構造の定義に直接定義することをお勧めします。
リンクは、テーブル内の実際のデータと整列して定義する必要があります。 誤った定義は、予期せぬレコードの複製など、リンクを介して取得したデータに影響を与える可能性があります。
リンクには、テーブル名と同じ名前を付けます。リンク名は、遠隔テーブルの内容を理解するのに役立ちます。
「id」をサフィックスとして含むリンクの名前を付けないでください。 例えば、「transactionId」ではなく「transaction」という名前を付けます。
デフォルトでは、Adobe Campaignは外部テーブルの主キーを使用してリンクを作成します。 より明確にするために、リンク定義で結合を明示的に定義することをお勧めします。
リンクで使用される属性にインデックスが追加されます。
Folio Builder created-byリンクとlast-modified-byリンクは、多くのテーブルに存在します。 この情報がビジネスで使用されていない場合は、リンクで属性noDbIndexを使用してインデックスを無効にできます。
リンクを設計する場合は、1-1関係が宣言されているときに、ターゲットレコードが一意であることを確認します。 そうしないと、1つしか期待できない場合に、結合が複数のレコードを返す可能性があります。 これにより、「クエリが予想以上の行を返した」場合に、配信の準備中にエラーが発生します。 リンク名をターゲットスキーマと同じ名前に設定します。
(1)側のスキーマにカーディナリティ(1 ~ N)のリンクを定義します。 例えば、関係受信者(1) - (N)トランザクションは、トランザクションスキーマ内で定義する必要があります。
デフォルトでは、リンクのカーディナリティが逆に(N)なので注意してください。 リンク定義にrevCardinality='single'という属性を追加することで、リンク(1 ~ 1)を定義できます。
リバースリンクがユーザに表示されない場合は、リンク定義revLink='NONE'を使用して非表示にできます。 例えば、受信者から最後に完了したトランザクションへのリンクを定義するのが適切な使用例です。 受信者から最後のトランザクションへのリンクのみが表示され、トランザクションテーブルに逆リンクを表示する必要はありません。
外部結合(1 ~ 0 ~ 1)を実行するリンクは、システムのパフォーマンスに影響を与えるので、注意して使用する必要があります。
Adobe Campaignは、データウェアハウスでもレポートツールでもありません。 したがって、Adobe Campaign・ソリューションのパフォーマンスを向上させるためには、データベースの増大を抑制する必要があります。 これを達成するには、以下のベストプラクティスに従うと役立ちます。
デフォルトでは、Adobe Campaign配信およびトラッキングログの保存期間は180日です。 クリーンアップ処理が実行され、それより古いログが削除されます。
データ保持に関する詳細は、キャンペーンのプライバシーとセキュリティのガイドラインを参照してください。
キャンペーンデータベースのクリーンアップワークフローについて詳しくは、このセクションを参照してください。
カスタムテーブルは、標準のクリーンアップ処理で削除されません。 この処理は1日目には必要ない場合がありますが、パフォーマンス上の問題を引き起こす可能性があるので、カスタム表のパージ処理を作成することを忘れないでください。
Adobe Campaign内のレコードの必要性を最小限に抑えるには、いくつかのソリューションがあります。
「deleteStatus」属性はスキーマで宣言できます。 レコードを削除済みとマークしてから、クリーンアップタスクで削除を延期する方が効率的です。
パフォーマンスを常に向上させるには、次のベストプラクティスに従ってください。
Adobe Campaignは、サードパーティのデータベースエンジンに依存しています。 プロバイダーによっては、大きいテーブルに対するパフォーマンスを最適化するために、特定のデザインが必要になる場合があります。
大きなテーブルと複雑な結合を使用してデータモデルを設計する際に従う必要がある、いくつかの一般的なベストプラクティスを以下に示します。
テーブルサイズは、レコード数とレコードあたりの列数の組み合わせです。 両方とも、クエリのパフォーマンスに影響を与える可能性があります。
PostgreSQLでは、TOASTメカニズムを避けるために行が8KBを超えないようにする必要があります。 したがって、システム(メモリとCPU)の最適なパフォーマンスを維持するために、列数と各行のサイズをできるだけ小さくしてください。
行数はパフォーマンスにも影響します。 Adobe Campaignデータベースは、ターゲット設定やパーソナライゼーションの目的で積極的に使用されない履歴データを格納するように設計されていません。これは、運用データベースです。
行数が多くなることに伴うパフォーマンス上の問題を防ぐには、必要なレコードのみをデータベースに保存します。 その他のレコードは、サードパーティのData Warehouseにエクスポートし、Adobe Campaignの運用データベースから削除する必要があります。
テーブルのサイズに関するベストプラクティスのいくつかを次に示します。
次に例を示します。
この例では、次のようになります。