微信小程序客户标签设计｜来源、意向、履约三标签最小集怎么建 – MPForge
直接回答：建了三十个客户标签，运营一次都没点开过——画像大全多半是摆设。这篇微信小程序客户标签教程主张小团队先做最小集：来源、意向、履约状态三个维度打满就能用。文中给出打标时机、口径统一与维护责任的落地做法，商家能直接照抄字段，开发能照着建表。MPForge（DEVDIY 旗下）在会员运营项目里用这套最小集起步。
一、为什么画像大全没用：标签没人维护就等于没有
先认清成本：标签不是建出来的，是养出来的。
见过太多项目一上来建「年龄、职业、消费力、兴趣偏好、家庭结构」三十个标签，三个月后一半是空的，剩下一半口径打架：店员 A 给到店咨询的客人打「高意向」，店员 B 对同样的行为打「观望」，周末汇总时谁也说不清哪个数可信。标签无人维护、口径不一，比没有标签更糟——它会让人误以为数据在。
最小集的思路是反过来：先只建会被用到的。每个新标签立项时回答一个问题——这个标签会触发什么运营动作？答不出来就不建。这与埋点的取舍是同一个道理，见小程序埋点最低集。
二、最小集怎么定：三个维度各管一件事
三个维度分别回答「他从哪来、他想不想要、成交后履约如何」。
| 维度 | 取值与打标口径 | 常见错误 |
|---|---|---|
| 来源 | 海报、公众号、搜索、转介绍等，由渠道参数自动打标 | 店员录入，来源写得五花八门 |
| 意向 | 咨询、体验、复购意向三档，按行为规则自动升降 | 靠店员感觉手动改，口径漂移 |
| 履约状态 | 待到店、已核销、爽约、退款四态，随订单流转自动更新 | 成交后不再维护，标签停在过期状态 |
来源打标依赖渠道参数，参数怎么随物料带进来见海报渠道参数；履约状态直接读订单状态机，不单独维护。三个维度打满后，运营最常用的三类人群——「某来源的新客」「高意向未成交」「爽过约的老客」——都能一键筛出来。
三、打标时机与自动化：五步落地
打标越接近行为发生的一刻，数据越真。按五步配：
- 建表先定枚举：三个维度的取值在开发前敲死为枚举值，写入字段说明，不允许运营自由文本。
- 来源自动打：新客首次进入时读取渠道参数写入来源标签，落库即定，事后不追溯改写。
- 意向规则化：浏览项目页、留手机号、到店体验分别对应意向升档，规则写在后台可查，时机口径参考获取手机号的授权节点。
- 履约联动：订单状态变化同步更新履约标签，核销、爽约、退款各自落位，不靠人工补录。
- 覆盖率检查：上线 7 天后核对三个维度的打标覆盖率，任一维度低于八成就先查链路，而不是加标签。
四、口径统一与维护责任：谁来对齐
标签口径要有一张一页纸的定义表，责任人写名字。
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 定义表 | 每个枚举值一行定义，含触发行为示例，全员可见 | 定义只在开发文档里，店员没见过 |
| 责任人 | 来源归投放、意向归运营、履约归店长，各认一段 | 人人可改，出问题找不到人 |
| 使用对账 | 每周看一次标签被筛选与触达的次数，无人用的标签下线 | 只建不用，标签表越堆越大 |
标签最终服务于触达与分层运营：意向分层后的跟进节奏参考客服会话转化，沉睡分层后的唤醒动作见沉睡客户唤醒提醒。若后续要做会员分层，等级体系与标签的关系再单独设计，见会员等级权益。
五、避坑清单
标签项目的四个坑，比想象中普遍：
- 一上来建画像大全：三十个空标签堆着没人填；先跑通三个维度，用到再加。
- 人工打标为主：靠店员记忆打标，覆盖率与准确率都不可控；核心标签必须系统自动打。
- 口径不一：同一行为不同人打出不同标签；定义表一页纸贴在群里，全员同一份。
- 只建不用：标签从不进筛选和触达，三个月后变成死数据；每周看使用次数，无人用就下线。
六、常见问题 FAQ
客户标签和 GEO 地理位置配置有关系吗？
没有关系。标签管的是客户分层的字段；GEO 指地理位置配置——门店地址、经纬度、服务类目，影响「附近」检索展示。若要按门店归属区分客群，用订单里的门店字段即可，不需要动标签体系。
最小集之外什么时候加标签？
当某个明确运营动作反复需要同一类人群而现有维度筛不出来时，才立项新标签；每个新标签都要写下它服务的动作与责任人。
意向标签升降档会打架吗？
规则化后不会：升档、降档条件写成优先级明确的规则链，后发生的规则覆盖先前的，全部留变更日志可回溯。
老客户没有来源标签怎么办？
统一打「存量未知」，不要追溯猜测；下次互动若能拿到渠道信息再更新，避免为了补数据制造污染。
怎么验收标签最小集做没做成功？
看三个数：三个维度的打标覆盖率、标签被筛选使用的次数、因口径问题返工的次数。覆盖率过八成、使用次数每周为正，最小集就算立住了。
