先做一件事:让两个账号各自把同一个页面查一遍,把页面地址、查询时间、账号角色、看到的总词数和前几条词全部截图或抄下来。然后不要争论谁对,而是把两份记录并排放,逐项核对“查询对象是否同一份、可见范围差在哪、差异能不能用权限解释”。如果差异集中在某些目录、某些子域名或某些词类上,通常说明两个账号能看到的站点范围不同;如果连同一个页面都出现完全不同的总量,才需要继续查查询对象是否一致。
多人对同一事实理解不同,往往是因为各自看到的“事实”其实不是同一个对象。把分歧转成表格,至少四列:查询对象、查询时间、账号角色、结果摘要。查询对象要写到具体页面或具体域名,不能只写“我们的站”。查询时间要写到日期,因为词数会随页面收录和索引状态变化。账号角色写清楚是主账号、子账号、只读账号还是临时协作账号。结果摘要记录总词数和前几条代表性词。
假设一个团队里,A 用主账号查首页,看到 1200 个词;B 用只读账号查同一首页,看到 300 个词。此时不要急着判断谁的数据错,而是先确认两人输入的页面地址是否完全一致,是否一个带 www 一个不带,是否一个查的是首页一个查的是整站。把这四列填完,很多分歧会当场消失。
账号权限不同,最常影响的是可见范围,而不是同一范围里的数字算法。可见范围可能体现在:能否看到子目录、能否看到子域名、能否看到历史数据、能否看到竞品对比、能否导出完整列表。核对时,先问一句:两个账号查的是同一个“范围定义”吗?
如果差异正好落在上述某一项上,那么“账号权限不同导致结果不同”就是合理解释。此时下一步不是继续比对总数,而是让有权限的一方导出完整范围,再让另一方在授权范围内核对子集。动作的结果会直接影响下一步:如果子集能对上,说明差异只是范围问题;如果子集也对不上,才需要查查询对象或时间点。
假设某站点有主域和 blog 子域。主账号查主域,看到 800 个词;协作账号查主域,看到 500 个词。两人都以为自己在查“同一个站”。核对后发现,主账号的默认范围包含 blog 子域,协作账号的授权范围只含主域。此时把 blog 子域的词单独查一遍,假设得到 300 个词,500 加 300 接近 800,差异就有了可验证的解释。
这个例子的关键不是数字本身,而是核对方法:先确定范围边界,再用子范围相加去逼近总量。如果相加后仍差很多,说明还有别的范围没被识别,比如 m 站、历史页面或已下线栏目。把这个动作做完,下一步就能决定是调整账号权限,还是统一查询口径。
核对完成后,通常只有三种处理结果。第一种,差异由权限范围造成,那就统一查询口径:指定一个基准账号、一个基准范围、一个基准时间,其他人按这个口径复核。第二种,差异由查询对象造成,比如页面地址不一致,那就重新约定输入规范,要求带协议、带子域、带路径。第三种,差异无法用范围解释,那就保留两份原始记录,换一个时间点再查一次,看差异是否稳定。
无论哪种结果,都要把核对过程留成可复查的记录。记录里写清楚:谁在什么时间、用什么角色、查了什么对象、看到什么结果、下一步由谁处理。这样下次再出现“账号权限不同导致结果不同”,团队不必重新争论,直接按记录核对范围即可。
第一,权限变更可能有延迟。刚调整完角色,不一定立刻反映到查询结果里,所以核对要留出缓冲时间,并以变更后的新查询为准。第二,总量相同不代表范围相同。两个账号可能总数接近,但覆盖的目录不同,这时要比对前几条词或导出列表,而不是只看总数。
把这两个条件写进核对清单,能减少反复。最终判断标准不是谁的数字更大,而是差异能否被范围、对象和时间三个因素解释清楚。能解释清楚,就按统一口径继续;解释不清楚,就保留记录并缩小查询对象,直到找到可核对的最小范围。