Journey Builder のパフォーマンスを最適化する方法

同時ジャーニーの影響の軽減

ジャーニーは処理リソースを共有します。同時に実行されるジャーニーがパフォーマンスにどのように影響する可能性があるかを考慮することが重要です。

HTS の有効化

すべてのジャーニーで HTS を使用します。メール活動を使用するすべてのジャーニーで HTS を使用すると、ジャーニーをより迅速かつ効率的に実行できます。HTS 送信フレームワークでは、スループットの向上と遅延の低減に加えて、同時処理のサポートも向上しています。

システム最適化ダッシュボードとシステム優先度の使用

各ジャーニーの開始時刻をずらすことで、需要を減らし、個々のジャーニーの処理速度を向上させます。System Optimization ダッシュボードを使用して、全体的なスループットを向上させる可能性がある最適化を特定し、優先順位を付けます。

専用データベースの検討

専用データベースへのシングルテナントリリースでは、共有データベースへのマルチテナントリリースよりも高速で予測可能な処理速度が得られます。これらのおすすめをマルチテナント取引先に実装した後に処理速度を向上させるには、シングルテナントと専用データベースのリリースについて取引先責任者にお問い合わせください。

ジャーニーを作成する前のデータのグルーミング

データの保存方法と準備方法は、Journey Builder でレコードを処理する速度に影響します。処理を最大化する方法を次に示します。

• 複数のジャーニーで同じデータエクステンションを使用するのではなく、ジャーニーごとに事前絞り込まれた送信可能なデータエクステンションのコピーを作成します。このステップにより、ジャーニーがインポート、送信ログ、レポート、抽出などの他のデータベースアクティビティと競合することもなくなります。
• 大規模なセグメンテーションには、エントリソース内の取引先責任者を絞り込むのではなく、Journey Builder で取引先責任者を許可する前に Automation Studio などの ETL ツールを使用します。
• 合計 500,000 件を超える取引先責任者がある場合、エントリソースで検索条件を使用して 50% を超える取引先責任者を絞り込むことはできません。これを行うと、重要なコンピューティングリソースが浪費され、リソースの過剰な使用が原因でジャーニーが停止してしまう可能性があります。代わりに、Journey Builder でデータを使用する前に Automation Studio などの ETL ツールを使用してデータをセグメント化します。
• 可能な限り、1 対 1 のデータエクステンションリレーションを使用します。1 対多または多対多のリレーションを使用する必要がある場合は、各取引先責任者の一致行数を減らすようにデータが慎重にグルーミングされていることを確認してください。これは、多くの取引先責任者が判断分岐、検索条件、またはこれらのデータエクステンションのクエリに依存するその他の活動を実行している場合に特に重要です。データエクステンションが 1 対多または多対多リレーションでリンクされている場合、一致する属性値がジャーニーエントリソース検索条件、待機活動、または決定分岐に複数回表示される場合があります。
• 決定分岐に使用するすべてのデータをエントリソースデータエクステンションに含めます。可能な場合は、取引先責任者データではなくジャーニーデータを判断分岐に使用します。

効率的な絞り込みロジックの使用

ジャーニーは処理用のリソースを共有します。ジャーニーにエントリ検索条件が含まれている場合、取引先責任者がジャーニーに受け入れられる速度は低くなります。1 時間あたりの処理を最大化するには、次のガイドラインに従います。

• 検索条件で取引先責任者データを使用する場合、データモデルを使用して、取引先責任者属性を取引先責任者にリンクするために必要な AttributeSets を決定します。パスのいずれかの AttributeSet に一対多リレーションが含まれている場合、取引先責任者に関連付けられているデータ量に比例して処理速度が低下します。たとえば、LastOrderDate に基づく決定分割の場合、取引先責任者に関連付けられた注文数がパフォーマンスに影響します。何千もの注文がある取引先責任者は、1 つの注文がある取引先責任者よりもパフォーマンスが低下します。
• エントリ検索条件を使用する場合、最高の検索条件パフォーマンスを得るには、演算子で終わる演算子と演算子を含めることは避けてください。データ処理では、これらの演算子は [次の文字列と一致する] 演算子を使用するよりもコストがかかります。
• 複雑なエントリソース検索条件または決定分岐検索条件では、取引先責任者を絞り込むためにテーブル結合が多くなり、パフォーマンスが低下します。

賢いジャーニー活動の使用

Journey Builder は、ジャーニーセグメントの取引先責任者を処理します。区分は、ジャーニーの開始から最初の待機、2 つの待機の間、待機から終了までの活動のチェーンです。セグメント内の各活動の最小処理速度によって、セグメントを介した取引先責任者の処理速度が決まります。活動種別ごとに処理する取引先責任者のレートが異なります。Journey Builder では、複数のジャーニーおよびセグメントの取引先責任者を同時に処理します。ジャーニーの特定の設定と選択した活動は、各セグメントとジャーニー全体のパフォーマンスに影響する可能性があります。

活動数の制限

追加できるジャーニー活動の数に制限はありませんが、読み込み時間が遅くならないように、ジャーニー内の活動数を 150 ～ 200 に制限します。

メッセージング活動

ほとんどのジャーニー活動はメッセージ活動よりも処理時間が短く、通常、セグメント内のメッセージング活動は妨げられません。メールの HTS を有効にすると、一般的にメール活動のスループットが向上し、セグメント全体のスループットが向上します。

待機活動

• 待機活動は慎重に使用してください。待機活動をジャーニーの最初のステップとして追加せず、最後の待機活動でない限り 15 分未満の待機活動は使用しないでください。
• デフォルトでは、[待機期間] 活動は 1 日に設定されています。ジャーニーの終了直前の待機を使用する場合に不要なシステム負荷を軽減し、ジャーニーのパフォーマンスを向上させるには、使用事例に必要な最小限の時間まで期間を短くします。
• ジャーニーの途中の待機活動が 3 分以内の場合、ジャーニーに終了条件または終了条件が設定された目標活動が含まれていない限り無視されます。

決定分割

• 決定分割を使用してジャーニーを開始することは避けてください。検索条件がジャーニーの最初のステップである場合は、ジャーニーの前にその検索条件の絞り込みまたはセグメント化を検討します。
• 使用事例でジャーニーの開始時に決定分割が必要な場合は、ジャーニーの開始時に 3 つ以上の決定分割活動を使用しないようにします。
• Journey Builder では取引先責任者がバッチで処理されるため、一連の決定分割活動を使用するとバッチサイズが小さくなります。最初に最大数の取引先責任者が従うと予想される決定分岐パスを作成します。
• 連続する決定分岐を回避します。

コンテンツのパーソナライズの影響を考慮する

Journey Builder では、AMPscript の機能を使用してメッセージをパーソナライズできます。Marketing Cloud Engagement は、メッセージ送信の最後にすべての AMPscript コールを処理します。これは、1 時間あたりに送信されるメッセージの数に影響します。

HTS を有効にすると、コンテンツのパーソナライズに伴うパフォーマンスへの影響を軽減できます。

従来のコンテンツについては、専用のデータベースで管理された環境で実行された内部ベンチマークで、これらの影響が確認されました。

高度にパーソナライズされた複雑なメッセージコンテンツでは、送信スループットが最大 25% 低下する可能性があります。パーソナライズは、利用者と対象を絞ったコミュニケーションを実現するための強力なツールですが、ジャーニーの送信スループットにどのように影響するかをメモしておきます。

メモ 表示される相対的なパフォーマンスの差は、コンテンツのパーソナライズの影響を評価するための指針にすぎません。同じコンテンツでも、実際のパフォーマンスの違いは環境によって異なる可能性があります。