每一个品牌监测工具都会生成一张随时间变化的提及量图表,而这张图表的可信度,取决于其背后的覆盖范围是否可靠。数量下降可能意味着人们不再谈论你。它同样可能意味着某个论坛开始对你的采集器进行限速,或者某个评测网站开始向你所在的采集地区提供不同的内容目录。
从仪表盘内部看,这两种情况完全一样。这正是提及量追踪的核心问题,而且在成为情感分析问题之前,它首先是一个覆盖范围问题。
各个平台的行为方式各不相同
把”互联网”当作单一来源来处理,正是大多数内部监测系统脆弱的原因。每个平台都有自己的访问机制、自己的结构和自己的失效方式。
社交平台。 只要有官方 API 存在且能满足你的需求,就使用它。它们稳定、被允许使用,也不会在你不知情的情况下悄悄改变你的覆盖范围。它们的限制通常在于历史深度、速率上限以及可暴露的字段。
论坛与社区。 Reddit 风格的聚合站、小众技术板块、行业专属社区。结构上简单,往往是价值最高的提及来源,同时也最为分散。这里没有统一的访问路径,因此逐一来源的工作量会在这里累积。
评测网站。 软件目录、零售评价、应用商店评价。高度区域化,这正是下文提到的陷阱所在。评测内容同时也是结构化的,因此它是最容易打分、也最容易被过度加权的平台。
新闻与博客。 已有的信息流和聚合器能很好地覆盖这类内容。通常不值得为此单独构建采集系统。
问答网站。 量小,但意图强烈,值得关注,因为关于你产品的一个提问,往往就在决策之前发生。
实际的建议是,按你的受众实际所在之处对各平台进行排序,而不是按每个平台采集的难易程度排序。一个把两个容易的平台覆盖得很好、却完全忽略重要平台的监测方案,是一种常见且代价高昂的结果。
地理位置改变了”提及”本身的定义
这正是让拥有国际客户的团队栽跟头的失效点。
应用商店按商店区域提供不同的目录和不同的评价集合。软件目录会对列表和评价都进行本地化。社交平台会按地区变更可见内容。一位身处德国的客户发布的提及,对一个美国的采集器而言可能完全不可见,而且结果中不会有任何迹象表明有内容缺失。
其结果是,单一视角的采集器产出的是一份区域性视图,却被贴上全球性视图的标签。如果你向拥有国际营收的管理层汇报”提及量上涨了 12%“,那么这个数字理应是从这些营收来源的市场中采集得到的。
具备国家和城市定向能力的住宅代理才能让区域性视图真正名副其实。使用 Shifter 网关时,视角和会话信息写在针对 p.shifter.io:443 的凭据中:
customer-USERNAME-country-de-sid-mentions-de-ttl-600:PASSWORD每个市场保持一个会话并以此发起查询,以确保分页的帖子或评价列表在内部保持一致,而不是在采集过程中途切换、把来自不同视角的页面拼接在一起。这一工作流程的产品化视图在品牌监测代理页面上。
有意识地构建查询集
覆盖范围取决于你搜索的内容,而大多数团队一开始搜索得太少,之后又搜索得太多。
从显而易见的内容开始:品牌名、产品名、域名。然后加入真实用户实际输入的内容:常见拼写错误、不带空格的名称、缩写、如果你曾经改过品牌名,那就加上旧名称。接着加入那些你被提及却没有被直接点名的语境:与竞品的对比、类别词加上一句抱怨、高管姓名。
反向的问题会在你的品牌名是常见词时出现。一个通用的名称会把真实的提及淹没在噪声之中,而解决办法不是更好的模型,而是更严格的查询:要求同时出现某个关联词、限制在相关社区内、或者匹配域名而非该词本身。这一点要在查询设计阶段就决定好,因为一个充满噪声的语料库会毒害后续的一切。
把查询集写成一个有版本记录的文件。当下个季度你的提及量出现跃升时,你需要知道究竟是外部世界发生了变化,还是你的查询发生了变化。
计数之前先去重
同一条陈述会通过多个渠道到达你这里。一篇新闻稿会在十几个媒体上转载。一条社交帖子会被引用、截图、再转发。一条评价会被聚合站镜像。一个论坛帖子会被跨版转发。
把这些全部当作独立的提及来计数,会以一种与传播机制而非与关注度相关的方式,虚增数量。更糟的是,这会让单一的一次大声量事件看起来像是广泛的舆情。
一个可行的规则是:以标准化的作者、标准化的文本和一个时间窗口组成复合键,并设定一个规范来源优先原则,让原始内容排在副本之前。比具体算法更重要的是,这套规则应固定且有文档记录,因为事后更改去重逻辑会重写你自己的历史数据。
把副本与规范记录关联保留,而不是直接丢弃。传播度是一个真实的信号,只是它和数量是不同的信号。
采集频率应服从风险,而非追求统一
每小时采集所有内容,成本高昂且大多是浪费。每周采集所有内容,则意味着在问题已经以糟糕的方式自行了结之后你才知道它发生过。
对各平台分级。那些抱怨会迅速升级的地方,通常是社交平台以及你所在品类中最活跃的社区,值得采用较短的采集间隔。评测网站和目录变化足够缓慢,按日采集即可。新闻聚合通常已经通过信息流实现了近乎实时。
再叠加一层事件驱动的机制:一次发布、一次故障、一次定价变动或一轮媒体报道周期,应该临时提高相关传播平台的采集频率。固定的日程安排做不到这一点,而它错过的那些时刻,恰恰正是这套监测方案存在的意义所在。
衡量你自己的覆盖率
真正能把一套可信赖的监测方案与一张不可信的图表区分开来的做法是:把采集情况与提及数据一并追踪。
记录每个来源的成功率、返回结果数与预期结果数的对比,以及已采集页面数与可采集页面总数的对比。当提及量下降时,首先要问的问题是:你自己的成功率是否也随之下降了。如果是,那就是一个采集层面的问题,而把它汇报为”对话量在减少”就是错误的。
在同一采集窗口内,对每个平台从同一地区的两个不同出口各运行两次一个小型对照查询。结果一致说明你的视图是稳定的;结果出现分歧说明该来源正在针对你的请求做出某种反应。建立这一基线的方法见于测试住宅代理速度、成功率和位置准确性,而请求节奏方面的内容见于速率限制与请求节流。
发现问题之后该怎么做
一套不产生任何处理决策的监测方案,不过是一份没人会读的报告。三个类别就足以起步。
立即处理。 来自可识别客户的具体投诉、关于你产品的事实性错误、安全性方面的指控。转交给专人处理,附上来源链接。
汇总统计。 情感倾向、数量、相对竞品的声量份额。以周为单位、以趋势形式呈现,并附上覆盖率指标,让这一趋势可信。
归档留存。 其余的一切。可检索,但不主动呈现。
关于这方面的品牌声誉防护,包括提及量追踪与假冒及滥用检测的交汇之处,内容见于利用代理保护你的品牌。应用商店相关的具体内容见于抓取 App Store 和 Google Play 数据。
常见问题
我应该使用 API 还是采集公开页面?
优先使用 API,只要它存在且能满足你的需求。公开页面采集用来填补空缺,而在实践中,这涵盖了大多数论坛、大多数评测网站以及大多数长尾社区。
历史数据的采集应该追溯多久?
追溯到足以建立一个可供比较的基线为止,这通常意味着一个季度。回填数年的数据成本高昂,而且很少会改变任何决策。
为什么什么都没发生,我的提及量却出现了跃升?
通常是单一内容的转载传播,或者是查询发生了变化。在对”关注度”做出任何结论之前,先检查去重结果和查询版本。
如果我已经在使用付费监测工具,还需要这些吗?
去问问这个工具在每个平台、每个地区的覆盖情况如何。大多数内部工作之所以存在,是因为某个具体的重要社区,或某个具体的市场,没有被该工具覆盖到。
总结
提及量追踪的失效往往悄无声息。覆盖缺口看起来像是沉寂,转载传播看起来像是共识,而一个本地视角看起来像是全球视图。
有意识地构建查询集,依据一套你能自圆其说的规则去重,按风险对采集频率分级,从你客户真正所在的市场进行采集,并把你自己的覆盖率与提及数据一并衡量。这才是让这张图表值得展示给任何人看的关键所在。套餐和价格详见定价页面。