問題点
多くのマネージド WordPress ホスト (WP Engine、Kinsta、Flywheel など) は、パフォーマンス向上のために WordPress サイトの前段に CDN を配置しています。訪問者がページをリクエストすると、次のようになります。- キャッシュミス → リクエストが WordPress まで到達 → プラグインがリクエストを取得 → 正常に記録
- キャッシュヒット → CDN がキャッシュされたコンテンツを直接配信 → リクエストが WordPress に到達しない → プラグインでは記録されない
例
この例では、サイトは WPE アプリケーションキャッシュレイヤーが有効な WordPress Engine でホストされています。 この例では初めてページを取得するため、キャッシュミスとなります。この問題が発生する理由
プラグインは WordPress のアプリケーションレイヤーで動作します。記録できるのは、実際に WordPress サーバーに到達したリクエストのみです。CDN がキャッシュされたコンテンツを配信する場合、リクエストは CDN のエッジサーバーで終了し、WordPress のインストール環境には届きません。 完全な解決策は、CDN ネイティブのログドレインを使用することです。Agent Analytics はすでにこれを完全にサポートしています。CDN のログは、キャッシュヒット、キャッシュミス、ボットトラフィック、DDoS の試みなど、すべてを取得し、全体像を把握できます。プラットフォームの問題
残念ながら、WP Engine や Kinsta などのほとんどのマネージド WordPress ホストは、CDN のログドレインを設定するためのアクセス権を顧客に提供していません。 Profound はこれらのプロバイダーに顧客向けのアクセス権を要請しましたが、現時点では断られています。この機能を実現するため、これらのプロバイダーとのパートナーシップの機会を模索しています。アナリティクスへの影響
取得されるもの
取得されるもの
- 初回のページ訪問 (キャッシュミス)
- キャッシュをバイパスする動的/パーソナライズされたページ
- POST リクエストとフォーム送信
- 管理者によって生成された公開ページへのトラフィック
- クエリパラメーター付きのページ (多くの場合キャッシュされません)
- キャッシュのパージ/再構築期間中のリクエスト
取得されないもの
取得されないもの
- 同じページへの 2 回目以降の訪問 (キャッシュヒット)
- キャッシュヒット率の高い人気ページ (通常 90% 以上)
- CDN から配信される静的アセット (CSS、JS、画像)
- CDN エッジでフィルタリングまたは配信されるボットトラフィック
- CDN レイヤーでブロックされる攻撃/DDoS
一般的なキャッシュヒット率
一般的なキャッシュヒット率
- 最適化されたサイト: キャッシュヒット率 85〜95%
- 平均的なサイト: キャッシュヒット率 60〜80%
- 動的/パーソナライズされたサイト: キャッシュヒット率 20〜40%
回避策
トラフィックを完全に可視化する必要がある場合は、次の方法を検討してください。- CDN を制御できるホストに切り替える - 多くのホスト (AWS、Google Cloud など) では、独自の CDN を設定できます
- エンタープライズ向けの CDN アクセスをリクエストする - 一部のマネージドホストは、エンタープライズ顧客にログへのアクセスを提供しています
- 部分的なデータを受け入れる - ボット検出や不正利用のモニタリングでは、通常ボットはキャッシュの恩恵を受けないため、キャッシュミスのデータで十分な場合が多くあります
- サポート対象の CDN で Agent Analytics を直接使用する - Cloudflare、Fastly、またはその他のサポート対象の CDN を自分で設定できる場合は、代わりにネイティブ統合を使用してください
この制限は Agent Analytics に固有のものではありません。HTTP リクエストを記録しようとする WordPress プラグインはすべて同じ制約を受けます。つまり、WordPress に到達したものしか見ることができません。業界標準の解決策は CDN ネイティブのログ収集であり、CDN へのアクセス権を持つ顧客向けに完全にサポートしています。