首页首句
定义过宽或频繁随活动变化。
分类层级
四类词不能都当主品类
层级
回答的问题
示例性质
主品类
回答的问题
品牌核心提供什么
示例性质
稳定、可覆盖主要业务
子品类
回答的问题
具体产品或服务属于哪里
示例性质
是主品类下位概念
能力
回答的问题
品牌可以完成什么
示例性质
不能冒充独立类别
场景
回答的问题
在何种任务中被使用
示例性质
带人群、条件与目的
分类树
一棵可审计分类树从业务对象向使用场景逐层展开
上层回答品牌究竟是什么，下层回答具体提供什么、具备什么能力、在什么条件下使用；任何节点都要能回到业务事实。
主品类
选择能覆盖核心收入对象、长期稳定且由业务 Owner 确认的上位类别。
子品类与产品
把具体产品线放到主品类下，标明地区、客群和在售状态。
能力
描述产品能完成的任务，但不把功能词抬升成品牌类别。
使用场景
补充谁在何种条件下解决什么问题，不反向覆盖主品类。
主品类
选择能覆盖核心收入对象、长期稳定且由业务 Owner 确认的上位类别。
子品类与产品
把具体产品线放到主品类下，标明地区、客群和在售状态。
能力
描述产品能完成的任务，但不把功能词抬升成品牌类别。
使用场景
补充谁在何种条件下解决什么问题，不反向覆盖主品类。
错误来源
六个位置最容易制造错归类
站点导航
产品、方案和行业混在同一层。
渠道类目
为了流量选择更宽泛或错误分类。
百科定义
沿用历史品类或缺少可靠更新来源。
Schema 类型
标记与正文和业务对象不一致。
竞品比较
一次价格并列被误读成长期同类。
命名交付物
交付一份「品牌分类树与证据底稿」
底稿把每个分类节点、适用对象、证据和排除项放在同一处，分类变更不再依靠一句定位口号。
节点定义
记录主品类、子品类、产品、能力、场景的上下位关系和互斥边界。
适用范围
标注集团、品牌、产品线、地区与生效时间，避免局部业务代表整个品牌。
证据索引
连接业务登记、现行官网、行业目录和真实使用材料，并写明 Owner。
排除清单
明确不属于哪些相邻类别，以及同名或历史类目为何不能继续沿用。
多品类品牌
可以有多项业务，但要说明层级与范围
健康多品类
不同产品线确实属于不同类别，并分别有对象、负责人、事实页和地区范围；集团层只做关系汇总。
混乱多品类
首页罗列所有热门术语，渠道各写一套主类目，产品和能力不分层，外部只能自行猜测。
四类核验
分类结论要同时经得起业务、官方、行业和使用事实核对
核验面
要回答的问题
冲突时的动作
业务事实
要回答的问题
实际交付对象与核心业务是否支持该类别
冲突时的动作
业务不成立时撤销分类，不用传播补强
官方表达
要回答的问题
官网、产品页、导航与 Schema 是否一致
冲突时的动作
先修现行责任页，再同步自有渠道
行业分类
要回答的问题
目录或报告采用的是何种粒度与时间版本
冲突时的动作
粒度不同则写映射，事实错误才申请修订
真实使用
要回答的问题
用户在什么任务中实际选择和比较品牌
冲突时的动作
把场景留在下层，不反推为主品类
复测题组
六类问题验证分类是否真正清楚
品牌是什么
观察第一品类定义。
属于哪类
观察主类与子类关系。
提供什么
观察产品与能力边界。
适合谁
观察场景是否冒充品类。
和谁可比
观察竞争集合是否合理。
不属于什么
观察同名和相邻类别消歧。
治理流程
六步修正品牌类别归属
步骤 01
确认主品类
由品牌与业务确认唯一主层级和定义。
01
步骤 02
建立分类树
把子品类、能力、产品和场景放到正确层。
02
步骤 03
扫描公开分类
核对官网、导航、渠道、目录、百科和 Schema。
03
步骤 04
区分错误与差异
判断是互斥分类、粒度差异还是合理多业务。
04
步骤 05
修正可控来源
先更新现行事实页，再同步其他自有页面。
05
步骤 06
按问题复测
观察介绍、类别、比较和排除问题。
06
正确分类不是让品牌出现在更多类别里，而是让主品类稳定、下位关系清楚、边界能够被公开核验。
品牌类别归属治理原则
预约品牌类别归属盘点
我们一起给你的品牌定一个稳定的主品类，把子品类、能力和使用场景放回正确层级，再扫官网、导航、渠道类目、百科和 Schema 找出错归类，最后用「品牌是什么 / 属于哪类 / 和谁可比」等问题在 AI 端复测，交付一份分类树和纠正清单。