用 Cloudflare Attribution Business Insights 看清爬虫流量的商业账

预计阅读时间：10 分钟

Cloudflare 推出的 Attribution Business Insights 仪表盘，把“爬虫来了多少、抓了什么、可能带来什么价值”从安全日志里的技术噪声，拉到了业务讨论桌上。对网站所有者来说，这不只是识别 bot，而是为内容被抓取、索引、训练或聚合时的成本与回报建立一套更清晰的对话基础。

爬虫问题正在从运维指标变成商业指标

过去看爬虫，很多团队只盯几个问题：是否恶意、是否打爆源站、是否绕过规则、是否影响真实用户。Attribution Business Insights 的重点不同，它把 crawler behavior、crawler appetite 和 potential value 放在一起看。

这几个词背后对应的是更业务化的问题：

哪些爬虫持续访问站点，而不是偶发扫一圈？
它们最想抓取哪些栏目、页面类型或内容资产？
抓取行为是否与搜索曝光、AI 摘要、内容分发、合作渠道或潜在授权价值有关？
这些流量带来的服务器、缓存、带宽和内容生产成本是否应该被量化？

这类问题很难只靠 Nginx access log 或 WAF 告警回答。安全团队能说“这个 UA 一天请求了 300 万次”，但业务团队更想知道“它抓的是新闻、文档、价格页还是评论区，以及这件事值不值得谈补偿”。

“Attribution” 的关键是把请求归因到可讨论的对象

爬虫流量最麻烦的一点，是它经常处于灰区。不是所有 bot 都该拦，也不是所有抓取都有明确回报。搜索引擎、AI crawler、内容聚合器、商业监测工具、合作伙伴集成都可能表现得像爬虫，但它们背后的商业意义不同。

Attribution Business Insights 这类仪表盘的价值，在于把原本散落在请求日志里的信号组织起来：谁在抓、抓得多频繁、偏好哪些内容、可能对应什么业务影响。这样网站所有者就能从“封不封”升级到“允许、限速、收费、协商、审计”的组合决策。

一个成熟的讨论通常不会只问：

这个爬虫合法吗？

而会问：

它消耗了多少资源？它抓走了哪些高价值内容？它给我们带来了什么可验证的回报？如果没有回报，是否应该要求商业补偿？

这正是 crawl compensation 话题需要的数据底座。

可以这样实践：先用日志做一个爬虫归因小报表

如果你已经在 Cloudflare 上有请求日志、Logpush、GraphQL Analytics 或其他边缘日志管道，可以先做一个轻量版分析。下面示例不声称是 Attribution Business Insights 的接口，而是一个可改造的本地分析脚本：读取 Cloudflare HTTP 请求日志 JSONL，按 User-Agent 和路径前缀统计爬虫 appetite。

准备一个 requests.jsonl，每行一条请求记录，字段名可按你的日志导出格式调整：

{"ClientRequestUserAgent":"Googlebot/2.1","ClientRequestPath":"/news/ai/cloudflare-dashboard","EdgeResponseStatus":200,"EdgeStartTimestamp":"2026-01-10T10:00:00Z"}
{"ClientRequestUserAgent":"ExampleAI-Crawler/1.0","ClientRequestPath":"/docs/api/rate-limits","EdgeResponseStatus":200,"EdgeStartTimestamp":"2026-01-10T10:00:01Z"}
{"ClientRequestUserAgent":"ExampleAI-Crawler/1.0","ClientRequestPath":"/pricing","EdgeResponseStatus":200,"EdgeStartTimestamp":"2026-01-10T10:00:02Z"}

保存下面脚本为 crawler_appetite.py：

#!/usr/bin/env python3
import json
import re
from collections import Counter, defaultdict
from pathlib import Path

LOG_FILE = Path("requests.jsonl")
BOT_PATTERNS = re.compile(
    r"bot|crawler|spider|slurp|preview|fetch|scrape|ai",
    re.IGNORECASE,
)


def section(path: str) -> str:
    parts = [p for p in path.split("/") if p]
    return "/" + parts[0] if parts else "/"


requests_by_agent = Counter()
sections_by_agent = defaultdict(Counter)
status_by_agent = defaultdict(Counter)

with LOG_FILE.open("r", encoding="utf-8") as f:
    for line in f:
        row = json.loads(line)
        ua = row.get("ClientRequestUserAgent", "-")
        if not BOT_PATTERNS.search(ua):
            continue

        path = row.get("ClientRequestPath", "/")
        status = str(row.get("EdgeResponseStatus", "unknown"))

        requests_by_agent[ua] += 1
        sections_by_agent[ua][section(path)] += 1
        status_by_agent[ua][status] += 1

print("crawler,requests,top_sections,statuses")
for ua, total in requests_by_agent.most_common(20):
    top_sections = ";".join(
        f"{name}:{count}" for name, count in sections_by_agent[ua].most_common(5)
    )
    statuses = ";".join(
        f"{code}:{count}" for code, count in status_by_agent[ua].most_common()
    )
    print(f"{ua!r},{total},{top_sections},{statuses}")

运行：

python3 crawler_appetite.py

你可以把输出贴进 BI 工具、电子表格或数据仓库，继续补三类字段：

内容成本：例如 /news、/research、/docs 的生产成本和商业价值不同。
技术成本：请求数、缓存命中率、源站回源、带宽和错误率。
回报信号：搜索转化、推荐流量、合作收入、授权收入或品牌曝光。

有了这些列，爬虫讨论会从“这个 UA 很烦”变成“某类爬虫每月抓取 800 万次，高度集中在高成本内容，回报信号弱，应该进入限速或商业沟通”。

策略不是只剩封禁：允许、限速、谈判可以并存

Attribution Business Insights 的意义之一，是帮助团队避免把所有爬虫都塞进同一个桶。不同类型的 crawler 可以对应不同处理方式：

对明确带来搜索发现价值的爬虫，保持开放，但监控抓取范围和频率。
对消耗大、回报弱的 AI 或聚合类爬虫，设置速率限制、路径限制或授权要求。
对伪装、异常高频或绕过规则的访问，交给安全策略处理。
对潜在合作方，用数据开启 crawl compensation 讨论，而不是靠主观感受谈判。

如果要把策略落到 Cloudflare 配置层，可以这样实践一个“先观察、再收紧”的思路。下面是一个示意规则片段，表达的是对特定 AI crawler 的 /research 路径限速；实际字段和语法需要按你的 Cloudflare 产品、Terraform provider 版本或 Ruleset API 调整。

# 示例：按你的 zone_id、规则阶段和 provider 版本调整后再使用
resource "cloudflare_ruleset" "crawler_rate_limit" {
  zone_id = var.cloudflare_zone_id
  name    = "crawler-rate-limit"
  kind    = "zone"
  phase   = "http_ratelimit"

  rules {
    action = "block"
    expression = "(http.user_agent contains \"ExampleAI-Crawler\" and starts_with(http.request.uri.path, \"/research\"))"
    description = "Limit high-cost research crawling after business review"

    ratelimit {
      characteristics = ["ip.src", "http.user_agent"]
      period          = 60
      requests_per_period = 120
      mitigation_timeout  = 600
    }
  }
}

这类规则不应该拍脑袋上线。更稳的做法是先用仪表盘或日志看 7 到 30 天，确认 crawler 身份、抓取路径、缓存影响和业务回报，再决定是放行、挑战、限速、阻断，还是交给商务团队沟通。

采用建议：把爬虫治理做成跨团队流程

这个仪表盘最适合放在安全、平台、内容、增长和商务之间共同使用。安全团队识别异常，平台团队计算成本，内容团队判断资产价值，增长团队评估回流，商务团队决定是否谈授权或补偿。

落地时可以从一个小清单开始：

每周查看 top crawlers、top paths 和异常增长。
给高价值内容路径打标签，例如研究报告、新闻、文档、价格页。
把 crawler 流量和源站成本、缓存命中率、转化或推荐来源放在同一张表里。
对不同爬虫建立策略：允许、监控、限速、阻断、商业沟通。
定期复查规则，避免误伤搜索引擎、合作伙伴或真实用户。

边界也要讲清楚：归因数据能帮助谈判，但不能自动证明某个爬虫带来了确定收入；User-Agent 也可能伪造，关键 crawler 应结合 IP、ASN、行为模式和官方验证方式判断。真正有价值的是把技术事实稳定地端到业务桌面上，让“爬虫是否该付费”不再只是一场情绪化争论。