怎么实时监控推特关键词(不用整天刷搜索页)
怎么实时监控推特关键词(不用整天刷搜索页)
有人刚发了一条关于你公司的推文。或者竞品刚宣布了什么。又或者你在盯的某个代币开始有热度了。
你想现在就知道 —— 而不是明天早上碰巧打开时才发现。
X 给了你一个搜索框，但没给你告警。于是大多数人最后都留着一个标签页，习惯性地刷新，然后仍然错过了真正重要的那条 —— 因为它是凌晨三点发的。
这篇讲怎么搭一套会主动告诉你的监控。
两种做法，而且它们不等价
关键词监控的一切都归结到一个架构选择：
轮询 —— 你按固定间隔去问"有新的吗"。简单、到处都能用，而你的延迟就等于你的间隔。每五分钟查一次，平均而言你会晚两分半钟知道。
流式 —— 你保持一条连接开着，有匹配的内容就被推给你。搭起来麻烦些，但是秒级。
该选哪个，完全取决于你拿告警去做什么：
| 你的场景 | 够用的方案 |
|---|---|
| 每周出一份品牌提及报告 | 轮询，每小时 |
| 响应客户投诉 | 轮询，每几分钟 |
| 对突发新闻做反应 | 流式 |
| 任何"晚一步就没价值"的事 | 流式 |
⚠️ 要避免的错误： 因为想"快一点"就把轮询间隔设成 30 秒。那是两头不讨好 —— 你每天发 2,880 个请求，却仍然可能晚 30 秒。需要秒级就上流式；分钟级够用就把间隔放宽，把请求省下来。
两条路我们都提供 —— 轮询用搜索，流式用 WebSocket —— 所以这个选择是个设计决定，而不是被条件限死的。
先做这件事：把查询写对
在写任何代码之前，先花十分钟打磨查询语句。大多数监控最后被弃用，原因都出在查询上 —— 要么淹没你直到你把它静音，要么窄到从来不响。
X 的搜索操作符在 API 上同样有效，而它们就是信号和噪音的分界：
| 操作符 | 效果 | 什么时候用 |
|---|---|---|
"精确短语" |
匹配整个短语而非单词 | 多词组成的品牌名 |
from:username |
只看某个账号 | 盯特定的人 |
to:username |
只看给他的回复 | 投诉监控 |
-词 |
排除 | 干掉已知的误报 |
-filter:replies |
只要原创，不要回复 | 砍掉回复串 |
min_faves:100 |
只要点赞超过某个数的 | 等它传开了再看 |
lang:en |
限定语言 | 品牌名有歧义时 |
#话题标签 |
按标签而非纯文本 | 活动追踪 |
写这篇时我们逐个对着线上接口试过 —— 都如文档所述地生效。
举个实例。 假设你要监控一家叫 Nova 的公司。直接搜 nova，你会得到汽车、拉丁语作业，和一档 PBS 节目。
"nova" -car -chevy -pbs lang:en -filter:replies
这一行就能滤掉大部分噪音。再加个 min_faves:5，连没人看过的推文也一并去掉。
查询要一步步搭。 先当普通搜索跑一遍，看回来的是什么，把不对的加进排除项，再跑一遍。这十分钟能救下一个否则你迟早会屏蔽的告警频道。
轮询：大多数人需要的那个版本
下面是一个完整的监控。它会记住已经见过的内容，所以一条推文只提醒你一次，而不是每轮都提醒。
import time, requests
BASE = "https://api.socialapi.tech"
KEY = "your_api_key"
QUERY = '"nova" -car -chevy lang:en -filter:replies'
seen = set()
def check():
r = requests.get(
f"{BASE}/v1/search/advanced",
params={"query": QUERY, "limit": 50},
headers={"X-API-Key": KEY},
timeout=60,
)
r.raise_for_status()
fresh = []
for tweet in r.json()["data"]:
if tweet["id"] not in seen:
seen.add(tweet["id"])
fresh.append(tweet)
return fresh
# 第一次先跑一遍填缓存, 不对历史内容告警
check()
print("基准已建立, 开始监控...")
while True:
for tweet in check():
author = tweet["author"]["username"]
print(f"@{author}: {tweet['text'][:120]}")
# send_to_slack(tweet)
time.sleep(300) # 五分钟
三个比看上去重要的细节：
先跑一遍填缓存。 循环之前那次 check()，能防止你第一次运行就被上周的 50 条推文轰炸。
按 ID 去重，不要按文本。 人们会发几乎一模一样的内容。ID 是唯一的，文本不是。
给 seen 集合设上限。 放着不管它会无限增长。生产环境里要封顶 —— 只保留最近几千个 ID，或者用带过期时间的缓存。
监控本身就这些。剩下的是它底下的可靠性，那部分由我们来跑。
流式：当秒数真的重要时
轮询有个下限：你的间隔。如果你需要几秒内知道，就需要有东西主动推给你。
import json, websocket
WS = "wss://api.socialapi.tech/v1/stream/ws?api_key=your_api_key"
def on_message(ws, raw):
msg = json.loads(raw)
if msg.get("type") == "connected":
print("正在监控:", msg.get("subscribed"))
return
# 其它控制帧 —— 比如服务端在背压下丢消息时发的 "lagged" —— 没有
# user/content 字段。要在这里就返回, 否则流一忙就会半夜抛 KeyError。
if msg.get("type"):
return
text = msg.get("content", "")
if "nova" in text.lower():
print(f"@{msg['user']}: {text[:120]}")
websocket.WebSocketApp(WS, on_message=on_message).run_forever()
区别在于过滤发生在哪一侧。流推送的是你订阅的那些账号的内容，关键词过滤在你这边做 —— 适合紧盯一组明确的账号。搜索轮询则是在服务端对全站过滤 —— 适合捕捉来自任何人的提及。
真实场景里两者常常一起用： 用流盯最关心的那几个账号，用搜索轮询兜住其余的一切。
收到告警之后做什么
监控本身是简单的那一半。决定这套东西还有没有人用的，是另一半：
按重要性分流，不要按数量。 一个 20 万粉的账号提到你，和一个刚注册、三个粉丝的账号提到你，不是同一件事。看 author.followers_count，把它们发到不同的地方去。
低优先级的攒起来批量发。 一小时二十条 Slack 提醒，只会训练所有人把这个频道静音。每隔几小时一份摘要才读得下去。
告警里要带够能直接行动的上下文。 正文、作者、他的粉丝数，以及链接。少了这些你还是得打开 X，那就白搭了。
全都记下来，只对一部分告警。 所有匹配都存，只对够格的发通知。等有人问"这事从什么时候开始的"，你会需要完整历史。
几种常见的监控配置
品牌提及 —— 你的名字，加上常见错拼，减去已知的同名冲突。它最大的价值是能早点接住投诉。
盯竞品 —— 用 from:竞品账号 看他们的官宣，再加上他们的品牌名，看别人怎么议论。
加密与金融 —— $SOL 这类代币符号可以直接当搜索词。这块量很大，所以 min_faves: 几乎是必需的，除非你想要全部。
招聘与获客 —— "looking for a" 这类短语加上你的品类。触发不频繁，但一响就是高意图。
发布日的口碑 —— 提前搭好，不要临时搭。你需要发布之前的基准，否则无从判断变化。
大家会问的问题
怎么监控推特关键词？ 按计划跑搜索查询，对没见过的结果告警；或者保持一条流式连接接收推送。上面的代码两种都给了。
有人发了某个关键词，能收到通知吗？ X 本身不提供关键词告警。要么自己搭，要么用有这个功能的服务。
怎么追踪别人提到我的品牌？
搜你的品牌名，把无关含义排除掉。再单独加一条 to:你的账号 来接住直接回复。
最快多久能知道有新推文？ 流式最快。轮询快不过自己的间隔；流是推文一到就送达。
多久轮询一次合适？ 在你的场景能忍受的前提下越慢越好。每几分钟一次能覆盖大部分需求。低于一分钟的轮询请求量很大而收益很小 —— 真需要那个速度就该上流式。
能同时监控多个关键词吗？
可以。要么用 OR 合成一条查询，要么每个关键词跑一条独立查询(想分开路由告警时用后者)。
我监控别人的关键词，对方会收到通知吗？ 不会。搜索公开推文对任何人都不可见。
能只监控某个特定账号吗？
可以 —— 搜索里用 from:username，或者在流上订阅那个账号以获得更低延迟。
怎么避免重复告警？ 记住已经处理过的推文 ID。按 ID 去重而不是按文本，因为几乎相同的推文很常见。
为什么我的监控会漏推文？ 通常是查询写得太窄，或者轮询间隔长于那条推文可被检索到的窗口。上线前先手动测一遍查询。
能监控话题标签吗？
可以，#标签 直接当搜索词用。建议配一个最低互动量过滤 —— 话题标签会吸引大量低价值内容。
怎么过滤掉垃圾号和机器人？
把 min_faves: 和对 author.followers_count 的判断结合起来。单用任何一个都不够，一起用能滤掉大部分。
能搜某个时间段内的推文吗？
可以，查询里用 since: 和 until:。适合在开始实时监控之前先补一段历史。
监控和"社交聆听"有什么区别？ 规模和视角不同。监控是"这个短语出现时告诉我"；聆听通常指对大量提及做聚合分析。底下是同一批数据。
必须自己申请 X 开发者账号吗？ 如果用第三方 API 提供数据就不用。X 官方接口需要自己的账号和付费档。
能监控其它语言的推文吗？
能。lang: 限定单一语言，不写就是全都要。
不写代码能做监控吗？ 有些托管工具带界面能做。代价通常是查询的灵活度，以及告警能发到哪里。
能把告警发到 Slack 或 Discord 吗？
可以 —— 把循环里的 print 换成一个 webhook 调用即可，只需要改这一处。
能搜多久以前的历史？ 搜索偏向近期，不擅长回溯很久以前。如果你需要长期历史，应该从现在开始持续采集，而不是事后去重建。
社交聆听(social listening)是什么？ 长期观察人们怎么谈论某个对象。 ★机制就是一个保存好的查询按计划轮询★ —— 讲究的地方在于你拿结果做什么。
怎么监控一个推特账号？ 按间隔轮询他的时间线，再和你已有的做差集。★新帖子就是两次轮询之间的差。★
最好的免费监控工具是哪个？ 一个定时查询加上存储。 ★大多数付费工具就是这个，再加一个仪表盘★ —— 价值在于你积累起来的历史。
怎么统计我的品牌被提及了多少次？ 搜品牌词然后数返回的结果。 ⚠️ ★报告时要写"找到的提及数"，不是"存在的提及数"★ —— 搜索返回的是一个窗口，不是完整集合。
能实时监控吗？ 接近实时。 ★"实时"就是你的轮询间隔，或者一条流★ —— 实时信息流涉及什么。
该多久轮询一次？ 让间隔匹配对象变化的速度。 ★间隔恒定比间隔短更重要★，因为改动间隔会污染你自己的趋势线。
我该用告警还是监控？ 告警告诉你发生了什么；监控建立那份记录。 ★大多数人两个都要，而且它们是同一条管道★ —— 告警的具体做法。
如果你不想自己维护这些管道
上面那个监控大概三十行。真正花时间的是它周围的东西：能区分限流和瞬时失败的重试、重启后依然有效的去重，以及不会在每个窗口头一分钟就把额度烧光的节流。
这些正是我们的 API 在处理的 —— 完整操作符的搜索，加上一条低延迟的 WebSocket 流用于你想紧盯的账号。固定按次价格，没有属于你的限流要管。
有两种情况我们不收钱：请求还没发出去就被我们拒绝的(比如查询写错)，以及我方原因导致的错误。
延伸阅读：X 接口报限流错误时该怎么办 · 追踪粉丝与取关 · 移除你不想要的粉丝。