送信ログを管理する
学習の目的
この単元を完了すると、次のことができるようになります。
- 送信ログデータエクステンションのクリーンアップとメンテナンスを行う。
- 送信ロギングが送信の単一障害点にならないようにする。
前の単元で、Michele が NTO のすべての送信を対象とする送信ロギングデータエクステンションを設定するところを見てきました。前述のとおり、ここで留意すべき重要な点は、送信ロギングデータエクステンションのそれぞれが、MID に関連する有効なすべての送信をキャプチャするということです。大量のメッセージです。では、過剰なデータが蓄積され、送信が遅延するといった問題を回避するにはどうすればよいのでしょうか?
ベストプラクティスに従うことです! ここで、送信ロギングを軌道に乗せるためのステップについて説明します。
一時保存用のデータエクステンションを使用して大量のレコードを処理する
第一に、送信ロギングデータエクステンションからデータを削除し、長期保存用のデータエクステンションに移動するのが常に最善策であることを念頭に置きます。前の単元で、データ抽出アクティビティを使用して実行する方法を解説しました。けれども、処理するレコードが何百万件にもなれば、この手法では追いつかなくなる可能性があります。大量のレコードを処理するために、もともと長期保存用だったデータエクステンションを一時保存用のデータエクステンションとして使用し、そこからリマーケティング用や販売用のデータエクステンションなど、別の場所に移すことを検討します。こうすれば、別々のデータエクステンションを使用してアクティビティを実行し、さらに負荷を軽減できます。
アクティビティの実行時間に基づいてスケジュールを調整する
どのような場合でも、1 つのデータエクステンションを使用するアクティビティの数を制限する必要があります。特に同時に実行する場合はこの点に注意します。前の単元で、Michele は 2 つのインポートを作成し、6 時間間隔で実行するように設定しました。アクティビティの処理時間が増大すれば、この間隔を変更しなければならないかもしれません。アクティビティの実行に要する時間に注意を払い、スケジュールを適宜調整します。
データ保持ポリシーを使用する
そしてもちろん、データ保持ポリシーを使用して、送信ロギングに使用するデータエクステンションのデータ量を管理します。データの保持を最大 10 日間に留めることをお勧めします。データエクステンションのデータ保持ポリシーは後で変更できますが、最初から確固たるポリシーを定めておくことが望まれます。
データエクステンションのフィールドを事前に計画する
既存のデータエクステンションにフィールドを追加するのは理想的とはいえないため、事前に計画を立て、開始する前に必要なカスタムフィールドが設定されていることを確認します。送信ロギングデータエクステンションには初めから標準テンプレートの 2 ～ 3 のフィールドが設定されていますが、AMPscript やガイドテンプレート言語のようなプログラム言語からデータをキャプチャするフィールドを追加できます。その場合も、データエクステンションの処理負荷を軽減するために、フィールド数を 10 以下に制限します。このデータエクステンションには大変な作業をしてもらうことになるため、そうした作業が極力有意義で生産的なものになるようにします。
そしてもちろん、送信ロギングの開始時点からベストプラクティスに従うことを強くお勧めします。後から修正することも可能ですが、余計な時間と手間がかかります。計画的に進め、送信ロギングによるアカウントへの負荷が軽減されるようにすれば、潜在的な問題の大半を回避できます。送信ロギングが稼働すれば、豊富な最新データを使用してマーケティング活動を強化できます。