框架提供的是思考结构，具体指标仍需针对产品定制
别名: 框架非指标清单 · 产品定制指标 · HEART customization
概念解释
HEART 一类框架给出的是提问和推导的结构，不是可粘贴的指标库。Task success 在支付里可能是“款项到达且用户确认无误”，在笔记里可能是“一条笔记被再次打开并继续写”；把“完成率”或“NPS”整段搬进每个类别，是把结构误当成清单。定制的意思是：结构保持，计数规则按这个产品的对象、任务和失败代价重写。
机制
框架要跨产品传播，只能停留在类别和层，不能停留在字段。一旦某篇介绍文章为 Engagement 举例“每周活跃天数”，该例会从插图变成默认实现，因为它可采、可画、可对标。默认实现忽略了对象差异：医疗排班的“活跃”可能有害，创作工具的“活跃”可能就是价值。定制从信号层开始：这个产品上目标达成时看见的现象是什么，再为现象选计数。结构提供的是完整性检查——有没有问过愉悦、有没有经过信号——不是提供行业平均数。把别人的指标当自己的指标，等于把别人的现象当自己的现象，而现象并不随框架迁移。
怎么研究
收集若干套“按教程填写”的 HEART 表，统计有多少指标定义可以直接在另一产品上原样使用；可原样使用的比例越高，定制越失败。对照同一类别在不同产品上的信号句，信号句若雷同，多半是从指标倒推的。也可以做迁移实验：把产品甲的指标定义接到产品乙的数据上，看它还能否区分乙的成功与失败用户；若不能，该指标是甲的定制结果，不是框架的通用件。
边界
完全不借鉴常见指标会提高发明成本，定制可以从候选集里挑，而不是从零发明计数。监管要求的字段（实名完成、告知勾选）不是 HEART 的通用件，是法定计数，可以出现在任务成功里，但仍要写明自己的信号。对标和行业基准需要共享定义，那是另一项用途，不能倒过来要求产品内部的成功标准与对标定义合一。定制过度、每个小组一套无法对话的定义，会毁掉跨团队对齐；结构层应保持共享，字段层才定制。
怎么落地
- 每个 HEART 类别的指标定义必须出现产品对象和任务名，禁止只写“完成率”“活跃度”。
- 先写本产品的信号句，再从常见指标里挑选或改写，顺序不得反。
- 引入任何外产品的指标定义时，用本产品的成功/失败用户做一次区分检验，分不开则不用。
- 共享一份框架表头，允许各产品填写不同的指标单元格，并在评审时只挑战单元格是否匹配信号。