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