Skip to content

コネクテッドコンテンツレスポンスのキャッシュ

コネクテッドコンテンツのレスポンスは、送信速度を最適化するために、異なるキャンペーンやメッセージ間（同じワークスペース内）でキャッシュできます。

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

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

コネクテッドコンテンツのレンダリングとデータ処理（上級）

このセクションでは、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 は、:cache_max_age やその他のキャッシュルールの使用に応じて、5分から4時間の TTL を持つマルチティアキャッシュをコネクテッドコンテンツのレスポンスに使用します。

  • インプロセスメモリキャッシュ: ワーカープロセス内の一時的なキャッシュです。データはジョブの期間中のみ存在できます（ワーカーのタイムアウトに基づき最大約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 に対するものであれば、キャンペーンやキャンバス間でキャッシュを共有できます。
  • キャッシュはユニークな URL に基づいており、ユーザー ID やキャンペーンには基づいていません。つまり、URL が同じであれば、コネクテッドコンテンツ呼び出しのキャッシュされたバージョンが、ワークスペース内の複数のユーザーやキャンペーンで使用される場合があります。
New Stuff!