Cloud Service コンテンツリクエストについて
はじめに introduction
コンテンツリクエストには、AEM Sites に送信されるリクエストが含まれます。これらのリクエストは、Edge Delivery Services またはコンテンツ配信ネットワーク(CDN)などの顧客提供のキャッシュシステムを通じてルーティングされる場合があります。これらのリクエストは、構造化データを HTML 形式または JSON 形式で配信し、ページビュー(ページやエクスペリエンスフラグメントなど)または JSON 戻り値をヘッドレス方式で API を通じてサポートします。
ユーザーが HTML または JSON を使用してページを表示すると、コンテンツリクエストがカウントされます。最初のキャッシュシステムがリクエストを受信した時点でこのリクエストを測定します。コンテンツリクエストをカウントする目的で、特定の HTTP リクエストが含められたり除外されたりします。HTTP の含まれるコンテンツリクエストと除外されるコンテンツリクエストの完全なリストを参照してください。
Cloud Service コンテンツリクエストについて understanding-cloud-service-content-requests
ページリクエストとは、メインページエクスペリエンスをレンダリングするのに必要なコア構造化コンテンツ(HTML や JSON など)を取得する HTTP リクエストを指します。画像やスクリプトなどのアセットのリクエストは含まれません。
標準の CDN を使用しているお客様の場合、AEM as a Cloud Service では、サーバーサイドレベルで測定されたコンテンツリクエストがカウントされます。この測定は自動的に行われ、クライアントサイドの分析トラッキングに依存しません。
AEM(Adobe Experience Manager)as a Cloud Service は、AEM インスタンスによって生成され、CDN で受信された応答タイプに基づいてコンテンツリクエストを識別します。特に、HTML(text/html)または JSON(application/json)を返すリクエストがカウントされます。これらの形式は通常、従来のサイトレンダリングまたはヘッドレス配信のいずれかでプライマリページコンテンツを配信します。
JavaScript ファイル、CSS スタイルシート、画像などの静的アセットのリクエストは、コンテンツリクエストとしてカウントされません。
コンテンツリクエストは、応答が CDN キャッシュから提供されたか、元の AEM 環境に転送されたかに関係なく測定されます。
Cloud Service コンテンツリクエストの相違 content-requests-variances
コンテンツリクエストは、次の表にまとめられているように、組織の分析レポートツール内で差異が生じる場合があります。一般に、サイトのコンテンツリクエスト数のレポートにクライアントサイドのインストルメンテーションに依存する分析ツールを使用しないでください。これらのツールは、アクティブ化するユーザーの同意に依存しているため、多くの場合、トラフィックの大部分が見逃されることがあります。AEM as a Cloud Service の上に独自の CDN を追加するお客様向けに、ログファイルのサーバーサイドでデータを収集する Analytics ツール、または CDN レポートを使用すると、精度が向上します。
ライセンス制限に対するコンテンツリクエストの使用状況の表示とトラッキングについて詳しくは、ライセンスダッシュボードを参照してください。
サーバーサイドのコレクションルール serverside-collection
AEM as a Cloud Serviceでは、コンテンツリクエストのカウントにサーバーサイドのコレクションルールを適用します。 これらのルールでは、AIやLLMのweb クローラーが認識されるなどの既知のボット(検索エンジンweb クローラーなど)や、サイトに定期的にpingを送信する一連のモニタリングサービスは除外されます。 この除外リストに含まれていないその他の合成、自動、または監視タイプのトラフィックは、請求可能なコンテンツリクエストとしてカウントされます。
次の表に、含まれるコンテンツリクエストと除外されるコンテンツリクエストのタイプと、それぞれの簡単な説明を示します。
含まれるコンテンツリクエストのタイプ included-content-requests
HTTP コード 206:これらのリクエストでは、完全なコンテンツの一部のみが配信されます。部分的なリクエストは、ページコンテンツのレンダリングに使用されるHTMLまたはJSON レスポンスの一部を配信する場合に含まれます。
・ Amazon CloudFront
・ Apache Http Client
・非同期HTTP Client
・ Axios
・ Azureus
・ Curl
・ GitHub Node Fetch
・ Guzzle
・ Go-http-client
・ ヘッドレス Chrome
・ Java™ Client
・ Jersey
・ Node Oembed
・ okhttp
・ Python Requests
・・
Netty} Wget
・ WinHTTP
・ Fast HTTP
・ GitHub Node Fetch
・ Reactor Netty
トラフィックが既知のボットとして分類されていない場合は、カスタムエージェントまたはAI駆動型の自動化を含めることもできます。
除外されたコンテンツリクエストのタイプを参照してください。
例には、次のようなものがあります。
•
Amazon-Route53-Health-Check-Service• EyeMonIT_bot_version_0.1_(https://eyemonit.com/)
• Investis-Site24x7
• Mozilla/5.0 以降(互換;UptimeRobot/2.0;https://uptimerobot.com/)
• ThousandEyes-Dragonfly-x1
• OmtrBot/1.0
• WebMon/2.0.0
<link rel="prefetch"> リクエスト<link rel="prefetch"> を使用)、これらのサーバーサイドリクエストがカウントされます。このアプローチでは、プリフェッチされるページの数に応じて、トラフィックが増加する場合があります。ライセンスダッシュボードも参照してください。
除外されたコンテンツリクエストのタイプ excluded-content-request
/libs/* に移動するリクエスト/system/probes/health例:
・AddSearchBot
・AhrefsBot
・Applebot
・Ask Jeeves Corporate Spider
・Bingbot
・BingPreview
・BLEXBot
・BuiltWith
・Bytespider
・CrawlerKengo
・Facebookexternalhit
・Google AdsBot
・Google AdsBot Mobile
・Googlebot
・Googlebot Mobile
・lmspider
・LucidWorks
•
MJ12bot・SemrushBot
・SiteImprove
・StashBot
・StatusCake
・YandexBot
・ContentKing
・Claudebot
User-Agentまたは他のボット分類シグナル) これらのリクエストには課金されません。このような除外されたボットの例としては、ChatGPT、Gmail Image Proxy、Baidu Spider、Outbrain、Yahoo! メールプロキシ、aiHitBot、Mail.Ru Bot、DomainStatsBot、Rainmeter、MetaInspector、Yahoo Gemini。
AI エージェントが既知のボットとして識別されない場合(例えば、汎用ブラウザー
User-Agentを使用している場合)、そのリクエストは請求可能なコンテンツ リクエストとしてカウントされる可能性があります。/api/graphql で始まります)。これらは Cloud Service の請求対象ではありません。favicon.ico を除外/content/experience-fragments/...など)に対して行われたリクエスト。例:同じドメインのバナーまたはカードの XF を取り込む
aem.customer.com 上のホームページ。・ URLが/content/experience-fragments/…
・ リファラードメインが
request_x_forwarded_hostに一致します注意: エクスペリエンスフラグメントのパスがカスタマイズされている場合(例:
/XFrags/...または/content/experience-fragments/以外の任意のパスを使用)、リクエストは除外されず、同じドメインであってもカウントされる可能性があります。 Adobeでは、除外ロジックが正しく適用されるように、Adobeの標準XF パス構造を使用することをお勧めします。コンテンツリクエストの管理 managing-content-requests
上記のセクション Cloud Service コンテンツリクエストの分散で説明したように、コンテンツリクエストは、多くの理由により予想よりも高くなる可能性があります。一般的なスレッドはCDNにトラフィックが達している可能性があります。 AEMのお客様にとって、ライセンスの予算内に収まるようにコンテンツリクエストを監視および管理することは有益です。 コンテンツ要求の管理は、通常、実装技術と トラフィックフィルタールール を組み合わせて行います。
コンテンツリクエストを管理するための実装手法 implementation-techniques-to-manage-crs
- ページが見つからない応答がHTTP ステータス 404で配信されていることを確認します。 ステータスが200で返された場合、コンテンツリクエストにカウントされます。
- ヘルスチェックまたはモニタリングツールを/system/probes/health URLにルーティングするか、GETの代わりにHEAD メソッドを使用して、コンテンツリクエストが発生しないようにします。
- コンテンツの鮮度に対するニーズと、サイトに統合したカスタム検索web クローラーのAEMライセンスコストとのバランスを取ります。 過度に攻撃的なweb クローラーでは、多くのコンテンツリクエストを利用する可能性があります。
- 任意のリダイレクトを、クライアントサイド(JavaScript リダイレクトを使用したステータス 200)ではなく、サーバーサイド(ステータス 301または302)として処理することで、2つの別々のコンテンツリクエストを回避します。
- ページをレンダリングするために読み込まれるAEMからのJSON応答であるAPI呼び出しを組み合わせるか減らします。
- ブラウザーのユーザーエージェントがAEMに正しく渡されていることを確認します。 これにより、上記の「既知の検索エンジン」コンテンツリクエスト除外ルールが活用されます。 特定のヘッドレス実装またはCDN設定で、発信元のユーザーエージェントが失われることがあります。 そのような場合は、除外を防ぎ、ユーザーエージェントが通過した場合よりも高いコンテンツリクエストにつながる可能性があります。
コンテンツリクエストを管理するためのトラフィックフィルタールール traffic-filter-rules-to-manage-crs
- 一般的なボットパターンは、空のユーザーエージェントを使用することです。 実装とトラフィックパターンを確認して、空のユーザーエージェントが有用かどうかを確認します。 このトラフィックをブロックする場合は、推奨される構文は次のとおりです。
trafficFilters:
rules:
- name: block-missing-user-agent
when:
anyOf:
- { reqHeader: user-agent, exists: false }
- { reqHeader: user-agent, equals: '' }
action: block
- ある日そのサイトを非常に激しく攻撃し、その翌日には消えてしまうボットもあります。 このような機能は、特定のIP アドレスやユーザーエージェントをブロックしようとする試みを妨げる可能性があります。 一般的なアプローチの1つは、 レート制限ルール を導入することです。 例を確認し、リクエストの速度が速い場合に許容値と一致するルールを作成します。 汎用的なレート制限を許可する可能性がある例外については、条件構造構文を確認してください。