Skip to content

コネクテッドコンテンツの応答のキャッシュ

コネクテッドコンテンツの応答は、異なるキャンペーンやメッセージにわたって(同じワークスペース内で)キャッシュして、送信速度を最適化できます。

Brazeは、コネクテッドコンテンツのレスポンス本文を恒久的に記録または保存しません。メッセージのレンダリング中、応答は一時的に保持されることがあります(例えばメモリ内やキャッシュ内)。これにより、BrazeはLiquidをレンダリングし、メッセージを送信できます。

キャッシュを防止するには、:no_cache を指定できます。これにより、ネットワークトラフィックが増加する可能性があります。システムのトラブルシューティングと健全性監視を支援するため、Brazeはコネクテッドコンテンツのリクエストメタデータ(完全にレンダリングされたリクエストURLやレスポンスのステータスコードなど)を、成功した呼び出しと失敗した呼び出しの両方について記録します。これらのログは最大30日間保持されます。

Connected Content rendering and data handling (advanced)

このセクションでは、BrazeがLiquidおよびコネクテッドコンテンツをどのようにレンダリングするか、またメッセージ送信前にデータが一時的に存在する可能性のある場所について、より詳細なエンドツーエンドの視点を提供します。これはプライバシーとデータ処理の審査に役立つかもしれません。

保存されるものと保存されないもの

  • コネクテッドコンテンツのレスポンス本文: Brazeによって恒久的に保存されません。一時的にメモリに保持され、キャッシュが有効な場合は、有効期限(TTL)付きでキャッシュに保存されます。
  • コネクテッドコンテンツのリクエストメタデータ: リクエストのメタデータ(完全にレンダリングされたURL、HTTPステータスコード、応答時間など)は、トラブルシューティングと監視のために記録されます。これらのログは最大30日間保持されます。
  • 最終レンダリングされたメッセージ: レンダリング中にメモリ内に存在します。設定やチャネルによっては、別の場所に保存される場合もあります(例:メッセージアーカイブやコンテンツカード)。

レンダリングの流れ(概要)

以下のフローは、Brazeがメール、SMS、プッシュ通知などのプロバイダーベースのチャネル向けにメッセージをレンダリングし送信する方法を説明します。SDK経由で配信されるコンテンツカードのようなチャネルは、基盤となるLiquidとコネクテッドコンテンツのレンダリングを同じように利用しますが、コンテンツが生成されるタイミングと配信方法が異なります。

  1. バックグラウンドワーカーは、メッセージの配信準備が整った際に、そのメッセージのLiquidテンプレートをレンダリングします。
  2. コネクテッドコンテンツタグは、Liquidレンダリング中に評価されます。
  3. 各コネクテッドコンテンツタグについて、Brazeは多層キャッシュをチェックします。キャッシュされた値が存在しない場合(またはキャッシュが無効化されている場合)、Brazeはエンドポイントを呼び出し、応答を受け取ります。
  4. 応答はLiquidテンプレートに挿入され、メッセージが完全にレンダリングされます。
  5. プロバイダーベースのチャネルでは、レンダリングされたメッセージはチャネルプロバイダーに送信され、その後ユーザーに配信されます。コンテンツカードなどのSDK経由で配信されるチャネルでは、レンダリングされたコンテンツはBraze SDKと同期されます。このコンテンツは初回インプレッション時または表示時に生成され、その時点でユーザーに表示されます。

コネクテッドコンテンツの応答が一時的に存在できる場所

Brazeは、コネクテッドコンテンツの応答に対して多層キャッシュを使用します。TTLは5分から4時間の間で、:cache_max_age の使用状況やその他のキャッシュルールによって異なります。

  • プロセス内メモリキャッシュ: ワーカープロセス内の一時的なキャッシュです。データはジョブの実行期間中のみ存続します(ワーカーのタイムアウトに基づき最大約11分間)。
  • ローカルマシンキャッシュ: ワーカーごとのキャッシュです。例えばローカルのMemcachedインスタンスなどです。
  • クラスタ全体のキャッシュ: ワーカー間で共有される分散キャッシュです。例えばMemcachedクラスターなどです。

これらのキャッシュ層は揮発性であり、設定されたTTLよりも早くデータが削除されることがあります。

:no_cache を使用すると何が変わるか

Brazeインフラ内でホストされていないエンドポイントに対しては、:no_cache を使用することで、コネクテッドコンテンツのレスポンス本文がMemcachedに保存されるのを防ぎます。この場合、レスポンスはレンダリングジョブの実行期間中(最大約11分間)のみワーカープロセスのメモリ内に存在します。Braze内部のホストに解決されるエンドポイントについては、キャッシュバスティングで説明されているように、応答が引き続きキャッシュされる可能性があります。

最終的にレンダリングされた出力が存在する場所

  • メッセージアーカイブ: メッセージアーカイブが有効な場合、Brazeは最終的にレンダリングされたメッセージを、設定済みのクラウドストレージバケットに書き込むことがあります。コネクテッドコンテンツの応答がレンダリングされたメッセージに含まれている場合、それはアーカイブされたコピーにも含まれます。
  • ユーザーデバイス: 配信後、完全にレンダリングされたメッセージコンテンツは、ユーザーデバイス上で不明な期間保持されることがあります。
  • コンテンツカード: コンテンツカードのレンダリング済みコンテンツは、カードが期限切れになるまでBrazeデータベースに保存されます。

デフォルトのキャッシュ設定

キャッシュ存続期間は最大5分(300秒)です。コネクテッドコンテンツの呼び出しに :cache_max_age パラメーターを追加することで、この値を更新できます。例は次のとおりです。

1
{{ {% connected_content [https://example.com/webservice.json] :cache_max_age 900 %}}}

GETリクエストはキャッシュされます。この動作は、コネクテッドコンテンツ呼び出しに :no_cache パラメーターを追加することで変更できます。

POSTリクエストはデフォルトではキャッシュされませんが、コネクテッドコンテンツ呼び出しに :cache_max_age パラメーターを追加することでキャッシュできます。最小キャッシュ時間は5分、最大キャッシュ時間は4時間です。

キャッシュサイズの制限

コネクテッドコンテンツの応答本文の最大サイズは1 MBです。応答本文が1 MBを超える場合、キャッシュされません。

キャッシュ時間

コネクテッドコンテンツは、GETエンドポイントから返される値を最低5分間キャッシュします。キャッシュ時間が指定されていない場合、デフォルトのキャッシュ時間は5分です。

コネクテッドコンテンツのキャッシュ時間は、次の例に示すように :cache_max_age を使用して長く設定できます。最小キャッシュ時間は5分、最大キャッシュ時間は4時間です。コネクテッドコンテンツデータは、Memcachedなどの揮発性キャッシュシステムを使用してインメモリでキャッシュされます。

その結果、指定されたキャッシュ時間に関係なく、コネクテッドコンテンツデータは指定された時間よりも早くBrazeのインメモリキャッシュから削除される可能性があります。これは、キャッシュ期間があくまで目安であり、Brazeによってデータがキャッシュされる期間を保証するものではないことを意味します。また、指定されたキャッシュ期間で予想されるよりも多くのコネクテッドコンテンツリクエストが発生する可能性があります。

指定秒数のキャッシュ

この例では900秒(15分)間キャッシュされます。

1
{% connected_content https://example.com/webservice.json :cache_max_age 900 %}

キャッシュバスティング

コネクテッドコンテンツがGETリクエストから返される値をキャッシュするのを防ぐには、:no_cache 設定を使用します。ただし、Braze内部のホストからの応答は引き続きキャッシュされます。

1
{% connected_content https://example.com/webservice.json :no_cache %}

POSTでは、キャッシュバスティングを行う必要はありません。POSTリクエストはデフォルトではキャッシュされないためです。POSTレスポンスをキャッシュするには :cache_max_age を追加し、キャッシュを避けるには :cache_max_age を省略してください。

知っておくべきこと

  • キャッシュは、コネクテッドコンテンツの重複呼び出しを削減するのに役立ちます。ただし、ユーザーあたりのコネクテッドコンテンツ呼び出しが必ず1回になることは保証されません。
  • コネクテッドコンテンツのキャッシュは、URLとワークスペースに基づいて行われます。コネクテッドコンテンツの呼び出し先が同一のURLであれば、キャンペーンやキャンバス間でキャッシュを共有できます。
  • キャッシュはユーザー IDやキャンペーンではなく、ユニークなURLに基づいて行われます。つまり、URLが同じであれば、キャッシュされたコネクテッドコンテンツの呼び出し結果がワークスペース内の複数のユーザーやキャンペーンで使用される可能性があります。
New Stuff!