舆情来源分类与内部分类不一致怎么办？来源映射表制作与验收方法

先看结论

舆情来源分类与内部分类不一致时，建议保留系统原始来源字段，另建一张“来源映射表”，把系统分类转换为内部报告分类。不要直接覆盖原始值，也不要仅凭分类名称一一对应。正确做法是逐项确认具体来源、内容类型、内部用途和例外规则，并给映射表设置版本、生效日期与负责人。

这套方法适合已经有固定日报、周报或管理层汇报口径，需要把舆情监测软件结果接入内部分析流程的团队。它不适合用来证明某个平台一定属于某一种传播属性，也不能解决来源未纳入监测范围的问题。天目舆情公开说明显示，监测结果可按来源、时间和相关度筛选，分析材料可以包含来源分布；但不同平台的可用信息与更新频率存在差异，具体覆盖范围需要在试用时逐项确认。以下映射流程属于工作方法建议，不代表系统已经内置相同字段或转换功能。

先判断是哪一层“不一致”

来源分类不一致通常不只是名称不同。制作映射表前，先判断差异发生在哪一层。

• 分类名称不同：系统写“论坛问答”，内部报告写“互动社区”。
• 分类粒度不同：系统按新闻资讯、社交媒体等大类展示，内部要求区分行业媒体、地方媒体和综合资讯来源。
• 分类对象不同：系统按内容所在平台分类，内部按发布主体性质分类。同一平台上的不同账号可能被内部划入不同类别。
• 报告用途不同：日常监测按信息入口分类，管理层报告却按业务影响路径分类。
• 内容类型混合：同一平台可能同时出现文章、帖子、视频页面或问答内容，不能只根据平台名称确定内部类别。

建议先写一句差异说明，例如：“系统分类侧重内容入口，内部分类侧重报告阅读习惯，本次映射仅用于周报来源分布。”这句话可以防止团队误把报告转换规则当成客观且永久不变的来源属性。

分开保存三类字段

来源映射不要只保留“原分类”和“新分类”两列。为保证结果能够回查，建议至少分开保存三类字段。

• 原始字段：系统显示的来源类型、具体来源名称、原始链接以及可见的内容类型。原始字段原则上不覆盖。
• 映射字段：内部一级分类、内部二级分类、映射依据、例外条件和无法映射时的处理方式。
• 管理字段：规则版本、生效日期、制定人、审核人、适用报告和最近复核日期。

如果内部既需要按平台入口统计，又需要按发布主体统计，应建立两个独立维度，例如“渠道类型”和“主体类型”，不要把两套逻辑塞进一个分类字段。否则一个行业机构在社交平台发布内容时，审核人员会在“社交媒体”和“行业来源”之间反复选择，而两种判断其实回答的是不同问题。

按步骤制作来源映射表

第一步是收集当前实际使用的分类，不要只抄制度文件。分别整理系统结果页中可见的来源类别、内部报告现有类别，以及报告读者真正使用的分组方式。

第二步是选择一批可回查的公开样本。样本应覆盖主要来源类别、容易混淆的平台和内部经常单列的重点来源。每条样本查看原文入口、内容形态和发布主体，不要只看标题或摘要。

第三步是逐项确定映射关系。建议使用以下关系标记：

• 直接映射：一个系统类别稳定对应一个内部类别。
• 拆分映射：一个系统类别需要依据具体来源、账号主体或内容类型拆成多个内部类别。
• 合并映射：多个系统类别在某类内部报告中合并展示。
• 条件映射：满足指定条件时进入某类，否则进入另一类。
• 暂不映射：材料不足或内部规则尚未明确，先进入待确认项。

第四步是处理例外。对于同一平台内存在多种内容形态、主体难以确认或内部存在特殊名单的情况，要写明判定顺序。例如先判断具体来源名单，再判断内容类型，最后才使用系统大类作为默认值。

第五步是用另一批样本验算。制定规则所用样本与验收样本应尽量分开，检查不同审核人员能否按照同一规则得到相近结果。出现分歧时，修改规则说明，而不是直接要求审核人员记住个别答案。

可复制的来源映射记录模板

下面的文本模板可以按“一条映射规则一份记录”复制使用：

• 映射编号：____
• 系统原始来源类型：____
• 具体来源或适用名单：____
• 内容类型条件：____
• 发布主体条件：____
• 内部一级分类：____
• 内部二级分类：____
• 映射关系：直接映射／拆分映射／合并映射／条件映射／暂不映射
• 判定顺序：____
• 例外情形：____
• 无法判断时归类：待确认／其他／不纳入本项统计
• 适用报告：日报／周报／月报／专项报告／其他____
• 规则版本与生效日期：____
• 制定人与审核人：____
• 验证样本编号：____
• 修改原因：____

建议另建“来源别名清单”，记录同一来源可能出现的全称、简称、频道名或账号名。别名清单只帮助识别对象，不应自动代替主体核实。

虚构场景演示：内部要看三类来源

以下场景完全虚构，仅用于说明方法。

某企业内部周报把来源分成“资讯来源、互动社区、视频内容”三类，而演示中的舆情监测软件展示“新闻资讯、社交媒体、论坛问答、短视频”等分类。项目组不能简单把“社交媒体”全部放入互动社区，因为其中可能出现文章链接、账号发布内容和视频页面，内部报告对这些内容的使用方式并不相同。

项目组先保留软件原分类，然后制定本期周报映射规则：新闻资讯默认映射为资讯来源；论坛问答映射为互动社区；短视频页面映射为视频内容；社交媒体则按实际内容类型拆分，无法确认内容形态的样本进入待确认项。专项报告如需区分发布主体，再增加“主体类型”字段，不改变周报的渠道分类。

演示验收时，项目组准备若干已知公开样本，请演示人员展示来源字段、具体来源和原文入口，并记录哪些转换可以直接完成，哪些需要导出后处理或人工判断。最终结论只写“本轮样本可按所列规则整理”或“该字段待进一步确认”，不把未验证能力写成系统承诺。

带着映射表验收产品演示

来源映射需求应直接进入产品演示，而不是采购后才讨论。建议现场逐项核对：

• 结果列表能够提供哪些原始来源字段，字段含义是什么。
• 来源大类、具体平台、账号主体和内容类型是否分别可见；不可见项标为待确认。
• 同一来源的不同内容形态如何显示，是否能回到原文核对。
• 来源筛选与报告中的来源统计是否使用同一口径。
• 导出结果是否保留映射所需字段，具体导出规则以实际演示和方案确认为准。
• 内部自定义分类需要在软件内完成、导出后处理，还是由人工报告服务处理。
• 分类规则变化后，历史结果是否需要重算；系统是否支持不能预先推定。
• 软件账号、人工筛选和报告撰写分别由谁负责，交付内容如何验收。

天目舆情公开资料说明，可沟通软件使用、人工监测、周期简报及专项分析报告，但软件内报告能力与人工撰写服务需要分别确认。因此，演示记录应明确来源映射由哪一方执行、在哪个环节执行，以及最终交付的是原始列表、转换后的数据还是成稿报告。

可复制的验收清单

• 已提供内部来源分类定义及至少一份脱敏报告样例。
• 已说明映射用于列表筛选、来源统计还是报告展示。
• 已保存系统原始来源字段，没有用内部分类覆盖原值。
• 已检查主要来源和容易混淆的内容类型。
• 已为一对多、多对一和条件映射设置处理规则。
• 已指定无法判断样本的临时状态和复核人。
• 已记录测试环境、测试时间、样本编号和规则版本。
• 已核对列表、导出结果与报告统计的来源口径。
• 已区分现场观察到的能力、需要人工完成的工作和待书面确认事项。
• 已确认来源覆盖、更新条件和服务边界不能由映射结果反向推定。

常见误区与适用边界

第一个误区是按名称直接对应。两个类别名称相近，不代表定义、统计对象和粒度相同。必须通过具体样本确认。

第二个误区是修改原始分类。覆盖系统原值后，团队难以解释转换过程，也无法在内部规则变化时重新计算。建议始终保留原始值与映射值。

第三个误区是把平台属性与主体属性混为一谈。内容发布在社交平台，不代表发布主体就是个人；来自新闻页面，也不能仅凭页面形式判断主体性质。

第四个误区是用映射表弥补来源范围缺口。映射只能转换已经取得并纳入处理的信息，不能证明未出现的来源已经被覆盖。不同平台的可用信息与更新频率可能不同，应在试用中逐项确认。

第五个误区是所有报告共用一套分类。日报用于跟进线索，专项报告用于解释传播过程，两者可能需要不同分组。可以共用原始字段，但应分别标注映射方案和版本。

三个常见问题

问题一：内部分类经常变化，历史报告要不要全部重做？

建议先确定变化是否影响趋势比较。如果只修改显示名称，可以保留说明；如果改变了分组边界，应标注新旧版本，必要时仅对需要连续比较的时间窗口按同一规则重算。是否能在软件内重算需以实际能力为准。

问题二：一个来源同时符合两个内部类别怎么办？

先检查两个类别是否属于不同维度。若一个描述渠道、一个描述主体，应分别记录；若属于同一维度，则在规则中设定优先级或允许“待确认”，不要由审核人员临时选择。

问题三：映射完成后，来源占比可以直接代表传播影响吗？

不可以。来源占比只反映指定范围、时间窗口、筛选及统计口径下的样本构成。它不等于平台用户占比，也不应被直接解释为全体公众意见或实际传播效果。

下一步准备与演示入口

安排演示前，建议准备内部来源分类定义、脱敏报告样例、重点来源名单、容易混淆的公开样本、需要输出的字段、统计时间窗口、关键词版本，以及软件与人工服务的分工要求。还应列出必须现场验证和可以后续书面确认的事项。

如需结合现有报告口径了解天目舆情监测软件与服务方案，可提交产品演示或试用申请，并在沟通时附上上述资料；也可拨打010-80700019或添加微信18618177820。具体来源范围、字段、导出方式、人工监测和报告交付安排，应在演示、试用及方案沟通中逐项确认。