【第562回】 Marketing Cloud Next ： 参照コンテンツブロック キャッシュ問題
Marketing Cloud Engagement でよく知られている問題の一つに、参照コンテンツブロックの「キャッシュ問題」があります。
Marketing Cloud Next でも、メール送信時のコンテンツ処理には、同様にキャッシュの仕組みが利用されているようです。
では、そもそもなぜコンテンツをキャッシュする必要があるのでしょうか。
Marketing Cloud Next では、大量のメッセージをレンダリングする際に、毎回 Content API から同じコンテンツを取得していては非常に非効率です。
例えば、10 万人に同じメールを送信するとします。
そのメールで同じコンテンツブロックを使用しているにもかかわらず、10 万人分それぞれについて Content API から同じコンテンツを取得していたら、かなり無駄が多いですよね。
そのため、一度取得したコンテンツを一定の範囲で再利用できるように、キャッシュを利用して処理を効率化していると考えられます。
Marketing Cloud Engagement では、JobID が変更されない限り、参照コンテンツブロックのキャッシュが残ることがあります。この挙動については、Salesforce の ヘルプドキュメント にも記載されています。
私も以前、この問題について記事を書き、回避策などを紹介しました。
それでは、Marketing Cloud Next ではどうなのでしょうか。
今回は実際に検証してみます。
コンテンツの準備
今回は「フッター」をコンテンツブロックとして作成し、それをメールから参照します。
その際、次の 2 パターンを同じメール内に配置して比較します。
ContentBlockBy() の AMPscript を配置する（上）
Content Block コンポーネントから直接呼び出して配置する（下）
ちなみに、この状態でコードビューを確認すると、それぞれ次のようになっています。
動的参照
{{getContentBlock key='MCHG5X7KJXSNCD3EKV3MA2MJOLFY'}}直接配置
<!--FRAGMENT:@cms/MCHG5X7KJXSNCD3EKV3MA2MJOLFY-->
Want to update your email preferences? GO HERE.
Questions? Check out the Help Center.
© Nobuyuki WatanabeAMPscript を配置した側は、コードビューでは getContentBlock に変換されており、コンテンツブロックを動的に参照する形になっています。
一方、Content Block コンポーネントから直接コンテンツを選択した場合は、FRAGMENT:@cms/... という CMS コンテンツを示す情報は残っているものの、その下には Content Block の実際の内容が HTML として展開されています。
このように設定方法により、違いが生まれているのがポイントです。
実際にメールを送信する
今回は、セグメントフローを 1 時間の間隔で定期実行してメールを送信するフローを用意しました。
そこで最初に受信したメールでは、当然ながら上下とも同じフッターが表示されます。
コンテンツブロックの更新と再公開
続いて、コンテンツブロックを開き、「背景色」を変更して、保存・公開します。
保存しただけでは送信内容に変更が反映されないことは確認済みです。
この状態でとりあえずメールコンテンツを開くと、Content Block コンポーネントから直接配置した側の背景色も変更されていることが分かります。
※プレビューとテストで確認すると、ContentBlockBy() の AMPscript を配置した側にも変更が反映されているのが確認できます。また、プレビューとテストで送信した場合は、最新のコンテンツブロックの状態で送信されます。
この状況を見るに、どちらも最新のコンテンツブロックを参照しているように見えます。ところが、実際にメールを送信すると違いが出ます。
実際のメールを確認する
実際に送信されたメールを確認してみます。
すると、Content Block コンポーネントから直接配置した「下」のコンテンツは、背景色が変更されていません。
事前にプレビューで確認したときは、両方とも「黒」の背景色でしたね。
この結果から、今回の検証結果を整理すると、次のようになります。
AMPscript で ContentBlockBy() を配置
送信時に最新の公開済みコンテンツブロックを取得する
Content Block コンポーネントから直接配置
メールが公開された時点のコンテンツブロックの内容が使用される
つまり、コンテンツブロックだけを更新・公開した場合に違いが発生します。
Marketing Cloud Engagement では、AMPscript を利用していても、常に最新の公開済みコンテンツブロックを取得するわけではありませんでした。
そのため、Marketing Cloud Engagement 経験者にとっては、ここは押さえておきたい大きな違いだと思います。
Marketing Cloud Engagement の Journey Builder のように、メールアクティビティを開いて「Publish」を押し直す、といった操作はもはや必要ありません。その意味では非常にシンプルです。
ただし、Content Block コンポーネントから直接配置した場合には、コンテンツブロック側の変更だけでは送信内容が更新されないという癖が残っています。この点は運用上、考慮する必要がありそうです。
API による一括公開も考えてみた
では、Content Block コンポーネントから直接配置したコンテンツを、どうすれば更新できるのでしょうか。
メールを何らかの形で編集して保存すると、メールは Revised 状態になります。
その後、再度公開することで、最終的には新しいコンテンツブロックの内容が送信に反映されます。この辺りは Marketing Cloud Engagement に少し似た挙動ですね。
ただし、これを API でまとめて処理できないか試してみたところ、なかなか簡単ではありませんでした。
① 公開 → そのまま再公開
まず、現在公開されているコンテンツをそのまま再公開してみます。
POST /services/data/v67.0/connect/cms/contents/publish
"errorCode": "INVALID_API_INPUT",
"message": "Your content wasn’t published. Try again."現在公開されているものを、そのまま再公開することはできませんでした。
これができれば一番簡単だったのですが、残念ながらうまくいきません。
② 公開 → 非公開（→ 後に再公開）
次に、一度非公開にする方法も試しました。
POST /services/data/v67.0/connect/cms/contents/unpublish
"errorCode": "INVALID_API_INPUT",
"message": "We can’t unpublish the record because one or more records depend on it. The dependent record is either not included in this unpublish request, or the record can’t be unpublished at this time"こちらは依存関係のエラーが発生します。
コンテンツブロックが他のコンテンツから参照されているため、単純に非公開にすることもできません。
③ 公開 → 改訂済み（→ 後に再公開）
最後に、API から何らかの更新を行い、メールを Revised 状態にする方法も考えました。
PUT /services/data/v67.0/connect/cms/contents/variants/{managedContentVariantId}ただし、この方法では更新するコンテンツの内容をリクエストボディに含める必要があります。
つまり、単純に「Revised にするためだけの更新」では済まず、既存コンテンツの内容を取得・保持したうえで更新処理を行う必要があります。
これは少しリスクと手間がありますよね。
そのため、今回はここまでは試していません。
現時点では、確実に対応しようとすると、
メールを一つずつ開く → 何らかの変更を加える → 保存する → 公開する
という作業が必要になりそうです。これはなかなか大変ですね。
ちなみに、Marketing Cloud Engagement では、ジャーニーの新しいバージョンを作成することで JobID が変更され、それによって参照コンテンツブロックのキャッシュを更新できるケースがありました。
一方、Marketing Cloud Next では、新しいバージョンのフローを作成してアクティブ化しても、今回のコンテンツブロックの挙動には影響しないようです。このこともしっかり覚えておきましょう。
今回の検証結果
いかがでしたでしょうか。
今回の検証結果をまとめると、コンテンツブロックの配置方法によって、更新後の挙動が異なることが分かりました。
特に重要なのは、次の違いです。
ContentBlockBy() を利用した場合
コンテンツブロックを公開すると、その最新の公開済み内容が以降のメール送信に反映される
Content Block コンポーネントから直接配置した場合
コンテンツブロックを公開しただけでは、すでに公開済みのメールの送信内容には反映されない
メール側を Revised にして再公開する必要がある
もちろん、この挙動が Salesforce の意図した最終的な仕様なのかどうかまでは確認できていません。
既知の問題であり、今後変更される可能性もあります。
ただし、現時点での検証結果を見る限り、コンテンツブロックを更新した際、その最新の公開済み状態を既存のメールにも反映させたいのであれば、ContentBlockBy() を利用する方法が適していると考えられます。
Marketing Cloud Engagement 経験者からすると、この ContentBlockBy() の挙動はかなり分かりやすいですよね。
コンテンツブロックを再公開すれば、それ以降の送信では新しい内容が使用される。
それまでは既存のコンテンツが再利用されるため、効率性も維持できます。
Marketing Cloud Engagement の参照コンテンツブロックで苦労した経験がある方にとっては、この違いはぜひ押さえておきたいポイントです。
最後に、今回使用した ContentBlockBy 関数についておさらいしておきましょう。
ContentBlockBy 関数
Marketing Cloud Next では、以下の ContentBlockBy 関数が利用できます。
ContentBlockById()：コンテンツブロックを コンテンツキー で指定
ContentBlockByKey()：コンテンツブロックを コンテンツキー で指定
ContentBlockByName()：コンテンツブロックを API 参照名で指定
コンテンツキー は、以下で取得できます。
ContentBlockById() で使用
ContentBlockByKey() で使用
API 参照名 は、以下で取得できます。
ContentBlockByName() で使用
これらを AMPscript をビジュアルエディターに配置すると、実はコードビューでは自動的に、以下の Handlebars 形式へ変換されています。
ContentBlockById() ⇒ {{getContentBlock key=""}}
ContentBlockByKey() ⇒ {{getContentBlock key=""}}
ContentBlockByName() ⇒ {{getContentBlock apiname=""}}
注意：現在、Handlebars で利用できるコンテンツ関数は getContentBlock key のみです。getContentBlock apiname は内部エラーとなるのでまだ利用しないようにしてください。
↓ ↓ ↓ ↓ ↓ 利用開始の目安は以下の注意文言が外れた時です。
今回は以上です。
