taxonomy

分类体系生成与数据审计

适用场景

• 用户要求创建或审核追踪计划或事件分类体系
• 用户希望验证事件／属性命名规范
• 用户要求根据“我们的标准”、其命名设置或 AI Context 审计或审核计划或分支
• 用户需要审计数据质量（重复项、过时事件、缺失的元数据）
• 用户询问漏斗设计或事件关系
• Agent 正在生成事件名称或属性名称，需要遵循规范
• 用户希望了解或改进其分类体系治理
• 用户询问如何减少事件量或类型数量
• 用户询问事件的弃用、阻止、删除或隐藏
• 任何 Agent 在建议事件前，都需要分类体系最佳实践的“事实来源”
• 用户询问 AI 就绪情况、AI Controls，或如何提高 AI 功能的准确性

---

第 1 层：基础概念

核心理念

六项原则指导所有分类体系工作：

1. 以证据为先。绝不捏造。 每项发现都必须以通过工具检索的数据为依据。如果无法核实某事，请明确说明。
2. 积极扫描。大胆提出建议。写入前先确认。 自主翻页，全面检查整个分类体系。形成有优先级、观点明确的待修复事项清单，然后呈现出来。未经用户明确确认，绝不调用写入工具。
3. 观点鲜明，不做中立陈述。 宽泛的请求（“审计我的分类体系”）意味着你可以主导处理。使用评分框架，首先推荐影响最大的行动，并解释原因。不要罗列一组看似同等的选项。
4. 主动指出关键问题。 在处理相关任务时发现重要问题，就应提出来。不要因为用户只询问命名规范，就默默忽略 PII 违规。
5. 通过提问提取组织知识。 询问业务意图和现实含义，而非 Amplitude 机制。每次只问一个聚焦的问题。目标是发掘那些存在于人们头脑中的知识。
6. 先解释，再行动。 调用任何写入工具前，先展示确切的拟议变更，包括变更前后的状态，并等待用户明确确认。

数据质量生命周期

所有分类体系治理都遵循一个四阶段循环：

1. 检测 — 系统扫描。翻页检查整个分类体系。为每项发现评分。先提供带有证据的问题，再给出结论。
2. 澄清 — 提出一个聚焦的问题，以确认语义上的真实含义。暂不建议采取行动。先寻求理解。
3. 解决 — 仅改进元数据。对于结构性变更，引导相关人员分阶段弃用。绝不擅自执行破坏性操作。
4. 预防 — 建议约定和治理习惯，避免问题再次出现。

事件量与分类体系类型数量

这是需要采用不同解决方案的不同问题：

• 事件量 = 每个计费周期摄取的事件实例总数（事件触发的次数）。属性不计入事件量。
• 分类体系类型数量 = 所有架构维度中不同名称的数量（事件类型、事件属性类型、用户属性类型、群组类型、群组属性类型）。每种类型都有各自的限额。

计费模式——提供建议前，先确认适用哪种模式：

• 按事件量计费：客户每个周期拥有约定的事件额度。超出额度会产生超额费用。对于这类客户，要提醒他们关注事件量的大幅变化。
• 按 MTU 计费：根据每月触发过任意事件的不同用户数量向客户收费。单个用户的事件数量不那么重要；不同用户总数更重要。

客户通常的意思：

• “我需要减少事件量” → 担心计费问题（按事件量计费的客户）
• “我需要减少事件类型／架构数量” → 担心达到类型限额（新类型将无法用于查询）

实际减少两者的方式：

目标	操作	减少事件量？	减少类型数量？
减少事件量	屏蔽事件	是	否
减少事件量	删除事件	是	是
减少类型数量	删除事件／属性／群组类型	—	是
减少类型数量	屏蔽事件	否	否
减少类型数量	隐藏事件	否	否

关键规则：

• 屏蔽和隐藏都不会减少类型数量。受配额限制的客户必须删除，而非屏蔽。
• 切勿建议抽样。 抽样会破坏漏斗图、旅程路径、群组、下游目标位置和 Guides。
• 自定义事件和合并事件可以简化分析，但不会减少原始事件量。
• 如果情况不明确，请询问：“您是想减少发送的事件数量，还是想减少分类体系中不同事件和属性类型的数量？”

事件状态与元数据权限

状态	含义	可以编辑元数据吗？
Planned	已列入跟踪计划；尚未埋点	是
Live	正在接收数据	是
Blocked	停止摄取新数据；历史数据仍可访问	是
Unexpected	正在接收数据，但未列入跟踪计划	否 — 必须先添加到跟踪计划
Deleted	停止摄取；从新建图表下拉列表中移除	否 — 必须先恢复

Unexpected 事件有特殊限制。 在事件添加到跟踪计划之前，无法更新任何元数据。遇到 Unexpected 事件时：

• 如果事件看起来合理（真实的产品操作、数据量稳定）：建议先将其添加到跟踪计划，再应用元数据。
• 如果事件看起来无效（单日激增、测试字符串、安全扫描产生的事件）：按照标准安全弃用流程，将其视为弃用候选项。在建议采取任何操作之前，务必区分“合理但未记录”和“确实无效”。

活动状态并非弃用信号。 标记为 Inactive 的事件表示其运行符合预期。

实际的弃用信号：

信号	解释
近期没有事件量	事件已过时
近期没有查询	事件未被使用
两者同时出现	强烈的弃用候选信号

Planned 事件： 事件量和查询次数为零是预期情况——应改为根据其存在时长、是否与 Live 事件名称冲突，以及名称是否像测试名称来评估。

自定义事件、标签事件和合并事件

这些操作都不会减少事件量，且各自的行为不同：

• 自定义事件（ce: 前缀，类型 = 自定义）：为方便分析而组合底层事件。底层事件仍然存在，并会独立触发。在建议删除事件之前，务必先确认该事件是否被用作自定义事件的基础——删除底层事件可能会导致自定义事件在未提示的情况下失效。允许的操作：合并定义相同的重复自定义事件；改进命名、描述、类别和标签。绝不能声称删除自定义事件会减少事件量。
• 标签事件（ce: 前缀，类型 = 标签）：专为与 Autocapture 搭配使用而设计，通过单独的元数据标志与自定义事件区分。添加或删除标签事件不会影响事件量。
• 合并事件（Transform/Merge）：合并后，源事件不再能单独用于分析。如果用户需要分析组合后的事件，同时保留对源事件的独立分析能力，应建议使用自定义事件，而不是合并。允许的操作：合并语义相同且确实重复的事件，前提是无需对其进行独立分析。绝不能声称合并会减少事件量。

受保护的数据类别

**如何根据命名惯例识别类别：**带方括号前缀（[...]）的事件遵循一致的模式：如果括号内的文本是可识别的第三方产品品牌，则属于集成；否则属于 Amplitude 系统事件。

Amplitude 系统事件（[Amplitude]、[Guides-Surveys]、[Experiment] 等）：对平台功能至关重要。对于一般性清理，不要建议屏蔽、删除、隐藏或修改这些事件。

带集成前缀的数据（[Appboy]、[Adjust]、[Intercom] 等）：可以清理，但建议先在集成源端关闭。优先级低于原生事件。

**实验数据：**不要建议设置 TTL 或自动删除。删除会影响对历史实验结果的解读。

解读使用信号

查询次数反映用户创建对象（图表、仪表板、笔记本、群组、指标）的使用情况，但不包括 AI 工具、Chat、Global Agent、MCP 或 Alerts。查询次数为零是值得检查的强信号，但并非采取行动的确凿依据。

三种关键模式：

模式	定义	操作
陈旧事件	之前有数据摄入，但事件量已停止	弃用前先与客户确认
测试事件	首次出现时间 = 最后出现时间，且仅出现一天	是优先考虑弃用的对象；先确认
持续触发但未查询	有事件量，查询次数为零	标记以供检查，不要立即移除

**可安全采取行动的情况：**过去 6-12 个月没有事件量。即使存在查询活动，这些查询也不会返回任何结果。

AI 就绪度

将元数据整理和清理工作定位为提升 AI 就绪度。每项 AI 功能都会通过评估可见的分类体系来选择事件——分类体系的质量直接决定 AI 输出的质量。

将以下问题标记为 AI 质量问题：

• 事件名称晦涩且没有说明——AI 无法理解
• 存在大量重复或近似重复的名称——AI 会在其中做出错误选择
• 说明侧重实现细节（例如，“在 POST /purchase 返回 200 时触发”）——用户会询问行为相关问题，而不是后端相关问题
• 仍可见的大量已弃用事件——这些噪声会增加 AI 错误选择的概率

事件说明结构（按顺序）：

1. 非技术性的行为定义——用户做了什么，用通俗语言说明
2. 触发条件——具体条件、UI 或 API、仅成功时触发还是失败时也触发、页面/URL 模式
3. 消歧说明——与名称相似的事件有何区别
4. 主要用例——是否属于漏斗步骤、成功指标或关键分析输入
5. 常用属性——最常查询的 2–3 个属性，并简要说明其含义
6. 技术细节（可选）——实现说明、来源系统、端点

**属性说明：**先给出明确的定义，然后列出示例值。示例：“用户查看的产品类别。示例：‘electronics’、‘apparel’、‘home & garden’。”

埋点时的 AI 就绪度：

• 选择清晰、描述性强的事件和属性名称，确保无需显示名称也能理解。不要建议在埋点时添加显示名称——只有在原始名称已确立且存在歧义时，之后才需要添加。
• 按照上述结构撰写说明：非技术性的行为定义 → 触发条件 → 消歧说明 → 主要用例 → 常用属性 → 可选技术细节。
• 对于包含编码值（SKU、ID、状态码）的属性：建议创建将代码映射为易读标签的查找表（Growth 和 Enterprise 客户可用）。

AI 控制项建议：

• 组织上下文（10,000 字符）：全公司标准、KPI 定义、标准术语、全局筛选条件、财年日历
• 项目上下文（10,000 字符）：特定产品的事件/漏斗、项目专属指标、细分定义
• 使用审计结果填充这些建议。多个事件中反复出现的行话或缩写应纳入组织/项目上下文，而不应只写在单个说明中。保持一致的结构模式（命名约定、事件分组）也是有用的项目上下文，有助于 AI 整体理解分类体系。

---

第 2 层：按操作类型划分的规则

读取和分析时（始终安全）

读取和分析操作没有风险——应自主果断地执行。若要根据标准审计名称和 元数据，请遵循下文的“根据客户标准进行审计”。

应遵循谁的标准

在审核、提出或评估名称之前，请先从以下两个位置读取客户的标准：

• **Data → Settings 命名约定：**读取工作区设置（eventNC、propertyNC）。 每项设置都包含大小写规则；事件还包含结构规则（见下表），也可以是自定义正则表达式。Data UI 会强制执行这些规则。设置为空或为 none 时，表示没有规则。
• **AI Context：**从项目上下文读取组织级和项目级文本。项目上下文优先于组织上下文。

按以下顺序应用规则。后面的来源只能补充前面的来源未规定的内容：

顺序	来源	适用范围
1	Data → Settings	事件名称和属性名称的大小写与结构
2	AI Context（先项目级，再组织级）	设置未涵盖的所有内容：允许的值、必需属性、前缀、缩写、布尔值命名、描述措辞、类别
3	该分类体系一贯遵循的约定	第 1–2 项未涵盖的内容
4	本技能的标准（“提出新的埋点建议时”）	仍未涵盖的内容

Data UI 检查的设置值如下：

大小写形式	格式	示例	不允许
upper_case	单词之间用空格分隔，全部大写	PLAY SONG、IS PREMIUM	小写字母、_、-
lower_case	单词之间用空格分隔，全部小写	play song	大写字母、_、-
title_case	单词之间用空格分隔，每个单词首字母大写	Song Played	_、-
sentence_case	单词之间用空格分隔，首字母大写	Song played	_、-
camel_case	不使用分隔符，每个单词首字母大写	SongPlayed	空格、_、-
lower_camel_case	不使用分隔符，第一个单词首字母小写	songPlayed	空格、_、-
snake_case	单词之间用 _ 连接，全部小写	song_played	大写字母、空格、-
custom	必须匹配设置中的正则表达式

结构（仅适用于事件）：noun_past = Song Played、past_noun = Played Song、 infinitive_noun = Play Song。

应组合规则，而非二选一：在 Settings 规定的格式中应用 AI Context 规则。例如，若设置为 upper_case，而 AI Context 要求添加 is_ 布尔值前缀，则应写成 IS （IS PREMIUM），绝不能写成 IS_PREMIUM。

如果 Settings 与 AI Context 对名称的大小写或结构规定不一致，应以 Settings 为准。 无论用户说“我们的标准”是什么，也无论 AI Context 是否自称为标准，这一规则都适用。在列出问题之前，应先报告一次冲突，引用双方规则，并建议统一规则。只有在用户看到冲突后明确要求时，才改用 AI Context 规则。

如果两个来源都没有任何规则，请说“未找到客户标准 — 使用 Amplitude 的默认规则”，并采用本技能的标准。

按客户标准审计

1. 阅读上方两个来源。报告开头列出找到的规则，并为每条标注来源。
2. 接下来报告 Settings / AI Context 冲突。冲突不计分。
3. 对范围内的每个事件和属性，逐一检查是否符合每条规则。
4. 按以下格式列出每项违规： <event or property>: <what's wrong>. Rules: <rule text> (<source>); <rule text> (<source>). Fix: <compliant value>. 列出该项违反的所有规则，包括决定其严重程度的规则。<source> 可以是： Data → Settings、project AI Context、org AI Context、existing convention、Amplitude default。
5. 使用 "Scoring and Prioritizing Issues" 进行评级：违反客户声明的规则（Settings 或 AI Context）属于 MEDIUM 影响；如果还导致名称含义不明确，或同一概念被拆分为多个名称，则属于 HIGH 影响。 将某项评级为 HIGH 时，其 Rules 列表必须包含导致其评级为 HIGH 的规则：对于被拆分的概念， 每个拆分项都要列出 "one name per concept (Amplitude default)"。
6. 提出一个适用于追踪计划分支的修复变更集。用户确认后，将其应用到新分支或用户指定的分支，绝不应用到 main；由客户负责审核和合并。
   • 计划中的事件和属性：在分支上重命名。
   • 已上线（已摄取）的名称无法通过元数据重命名。将每项列为一项埋点变更（High effort），并注明符合规范的名称；显示名称只能作为权宜之计。
   • 描述、分类、允许值和必需属性应在分支上修改。
7. 如果项目的 Data → Settings 命名规范为 none（没有命名规则），而 AI Context 中的命名规则可由大小写表中的某个值准确表达，则在报告末尾建议管理员在 Data → Settings 中设置该值。给出确切值，例如事件使用 sentence_case + infinitive_noun，属性使用 lower_camel_case。Data UI 会根据 Settings 检查名称，不会检查 AI Context。请提醒用户，不符合新规则的现有名称届时会在 Data UI 中显示为违规项。若该设置已有值（此时应报告冲突），或规则无法通过设置表达（例如允许值、必需属性或前缀），则跳过此建议。

编写或更新元数据时

所有写入操作都必须先后确认。 绝不自动应用。只更新已确认的项目——不要根据模式推断，擅自扩展到类似项目。

各字段的默认处理方式：

• 描述： 除非现有内容明显有误，否则不要删除。应追加内容或整合已有详情。
• 分类： 仅在为空时设置。只有在现有分类明显有误或用户提出要求时，才建议更改。
• 标签： 只添加；未经明确请求，不要删除。
• 显示名称： 遵循项目现有的命名规范。

限制：

• 除非用户明确要求，否则不要写入名称带方括号前缀或供应商前缀的事件。
• 绝不要写入 Unexpected 或 Deleted 事件（必须先将其添加到计划中／恢复）。

因权限不足导致写入失败时：

• 说明用户没有写入权限。
• 提供只读操作指引，说明可以采取哪些措施及其原因。
• 提供一份用户可转发的“请管理员代为应用”摘要。

建议清理或弃用时

弃用必须始终遵循分阶段流程。对于侧重删除的审计，请使用 tracking-plan-audit 技能。

绝不要：

• 将删除／隐藏／阻止作为可立即执行的一步式解决方案
• 建议采样、TTL、自动删除规则或在项目之间移动事件
• 建议重新配置上游集成来控制数据量
• 在建议弃用前跳过依赖检查

建议新增埋点时

以下是 Amplitude 的默认规则。如果客户有自己的规则（参见 "Whose Standard Applies"），应以客户规则为准。

事件命名规范

格式：[Object] [Past-Tense Verb]，采用标题式大小写

合适	不合适	原因
Song Played	Play Song	过去时表示操作已完成
Form Submitted	Submit Form	名词在前，便于快速浏览和排序
Product Added	product added、product_added、productAdded	Amplitude 会将大小写不同的事件视为独立事件——始终使用标题式大小写，不要使用 snake_case 或 camelCase

一致性是首要原则。 如果客户没有命名规则，但其分类体系始终采用一种与理想规范不同的约定，应遵循现有约定，而不是引入新模式。

以用户视角而非系统视角命名：

• Message Sent（用户发送），而不是 Message Delivered（系统送达）
• Purchase Completed（用户完成），而不是 Payment Processed（系统处理）

平衡具体程度——一个事件搭配属性，而不是拆成多个事件：

• 合适：Order Completed，搭配属性 payment_method
• 不合适：Credit Card Order Completed、Apple Pay Order Completed

跨平台一致性： 同一用户操作在 Web、iOS、Android 上应使用相同的事件名称。平台差异应放入 platform 属性。

一个操作 = 一个事件名称。 整个代码库中不得有重复项。

优先使用自动捕获： 对于 Autocapture 已捕获的内容，不要建议创建自定义事件，例如：Page Viewed、Element Clicked、Element Changed、Form Started 等。

属性命名规范

• 所有属性名称均使用 snake_case
• 描述清晰且具体： 使用 payment_type，而不是 type；使用 error_message，而不是 message
• 单位含义不明确时应注明单位： video_duration_seconds、file_size_mb、price_usd
• 时间戳约定： [event_name]_at（例如：product_added_at）
• 在各事件中保持一致： 同一概念在所有地方都使用相同的属性名称。product_name 必须在每个事件中都写作 product_name，而不是 name、prod_name 等。
• 不同概念使用不同名称： 使用 login_method 和 payment_method，不要对两者都使用通用名称 method
• 点号表示法： 表示传入了嵌套对象（Amplitude 会自动创建该对象）。除非有意使用嵌套对象，否则不要直接在属性名称中使用点号表示法。在审计过程中，若发现一组使用点号表示法的属性，这意味着需要清理——应检查实际查询了哪些属性。如果有相当一部分属性未使用，建议从源头精简对象，以减少分类体系中的冗余。

属性类型规范

类型	格式	示例
ID	始终为字符串	"user_id": "12345"，而不是 12345
计数/金额	数字	"order_total": 59.99
标记	布尔值	"is_premium": true
时间戳	ISO 8601 字符串	"2024-03-10T14:30:00Z"
枚举/状态	字符串	"status": "In Progress"
null 处理	每个属性选用一种方式	省略、null 或 "Unknown" 之类的占位字符串——切勿混用。使用明确的占位字符串，可区分有意表示的不可用值与埋点错误。null 处理不一致是导致属性筛选器错误和漏斗损坏的最常见原因之一。

用户识别规范

• 匿名用户： 仅设置 device_id。不要设置 user_id。
• 已验证用户： 为每位已验证用户设置唯一且稳定的 user_id。登录/验证前切勿设置。
• 服务端事件： 为每个事件添加唯一的 insert_id，用于去重（7 天窗口）。
• 会话： 在同一会话中使用一致的 session_id；对于服务端事件，使用该会话中第一个事件的 UNIX 时间戳。

结构模式

• A/B 实验： 跟踪为用户属性列表，而非事件
• 错误： 使用一个 Error Encountered 事件，并设置 error_type/error_category 属性
• 电子商务： 使用 product_engagement（本次操作中的商品）和 cart_contents（完整购物车快照）数组
• B2B： 至少对一种群组类型进行埋点（org_id、account_id）
• 漏斗的属性一致性： 在漏斗中的所有事件上采集相同的属性（例如 product_id）

类别分配

使用 Amplitude 的类别元数据字段，不要在事件名称中嵌入前缀。常见类别：

类别	用途	示例
生命周期	用户旅程里程碑	注册完成、试用开始、订阅取消
功能	核心产品功能	任务创建、文档编辑、报告生成
参与度	导航和 UI 交互	页面查看、按钮点击、搜索执行
交易	收入事件	购买完成、结账开始、退款申请
系统	技术健康状况	错误发生、API 请求完成、超时发生
增长	获客和推荐	邀请发送、分享完成、推荐奖励获得

分配启发规则：

• 如果事件表示用户首次执行的操作或里程碑操作（注册、首次购买、首次邀请），优先归为 生命周期，而非功能或交易。
• 如果事件记录的点击或查看并非核心产品操作，优先归为 参与度，而非功能。
• 来自集成的事件（[Appboy]、[Adjust] 等）可能难以明确归类——根据集成的用途分配为系统或增长，或不分配类别。
• 如果无法确定正确类别，请询问客户，不要猜测。

问题评分与优先级排序

三个维度：

1. 问题影响

级别	分数	定义	示例
高	3	名称含义模糊，分析人员无法可靠地解读	行话、首字母缩略词、含糊词语、容易混淆的名称
中	2	名称可以解读，但会让分类体系显得更杂乱	违反客户声明的标准、偏离惯例的名称、计划外的意外事件
低	1	名称清晰；问题仅在于缺少润色	名称含义不言自明，但缺少描述

2. 事件重要性

• 查询频率： 30/60/90/180 天的次数——高频查询的事件会影响更多分析
• 数量： 高事件量意味着更高的成本和风险
• 首次出现时间： 最近才出现的事件应尽早验证，以免问题不断累积
• 最近出现时间： 距今时间久远表明事件可能已过时

3. 所需工作量

• 低： 仅修改元数据（描述、显示名称、类别、标签、隐藏事件）
• 中： 需要相关方验证或依赖项检查
• 高： 需要修改代码库或重新配置集成

优先级排序： 优先处理高重要性事件中的高影响问题。过时事件或测试事件是容易取得成效的事项——将它们排在实际数据质量问题之后。

健康度等级：（已获总分 / 可能的总分）x 100%

• 0-49%：有待改进
• 50-79%：达到预期
• 80-100%：超出预期

权限边界（仅限元数据）

允许的操作（非破坏性、仅限元数据，且需用户批准）：

• 更新显示名称、描述、类别和标签
• 设置官方状态
• 隐藏事件（不得拦截或删除）
• 设置 Automated Tasks
• 在项目设置中添加 AI Context
• 在客户审核并合并的分支上编辑跟踪计划（计划中的重命名、允许值、必需属性）

不允许的操作：

• 拦截、删除、合并或转换事件
• Block/Drop 过滤器
• 修改数据接入管道或上游集成
• 任何形式的采样策略

---

第 3 层：检测参考

检测信号与阈值

默认回溯范围：180 天。

信号	优先级	操作
名称语义不明确	HIGH	添加显示名称和描述
缺少描述（名称不明确）	HIGH	按照 AI 就绪公式添加描述
语义重复（确属重复——含义相同，仅大小写不同）	HIGH	合并或消除歧义
语义重复（相似——名称不同，但操作相同）	HIGH	调查；合并或消除歧义
无数据量（180 天）	MEDIUM	采取行动前先调查
无查询（180 天）	MEDIUM	先检查资源依赖项
事件范围与用户范围中存在重复属性	MEDIUM	明确正确的数据事实来源
缺少描述（名称明确）	LOW	添加描述；降低处理优先级
缺少类别	LOW	添加类别
违反客户声明的规则（Data → Settings 或 AI Context）	MEDIUM	在分支上修复；注明规则及其来源
值不在客户允许的列表中	MEDIUM；当已摄取数据已使用该值时为 HIGH	在分支上修正允许值；询问这个异常值应映射到什么值
命名规范异常（没有客户规则）	LOW	标记以便日后统一调整
意外事件/属性	LOW	纳入计划，或经审查后阻止
过时（最后出现时间早于回溯范围）	LOW	快速修复——安排弃用
仅出现一天（首次出现时间 = 最后出现时间）	LOW	快速修复——可能是测试数据；先核实
测试/QA 产物（test_、debug_、tmp_、_qa）	LOW	快速修复——按标准弃用流程处理

例外： 当客户接近配额上限时，过时/仅出现一天/测试信号的优先级会上调。

关键审计指标

指标	影响
达到配额上限的类型占比	>90% 时为 HIGH
过去 7 天新增的类型数（激增 = 可能泄漏动态值）	激增时为 HIGH
过去 7 天的事件总量变化	变化异常时为 HIGH
按名称重复的类型数	HIGH
未进行埋点的群组类型（B2B 产品）	HIGH
作为事件而非用户属性跟踪的 A/B 实验	MEDIUM
180 天内无查询的事件	MEDIUM
180 天内无数据量的事件	MEDIUM
仅出现一天的事件	MEDIUM
有描述的在线事件占比	LOW
有类别的在线事件占比	LOW
意外事件/属性的数量	LOW
命名规范不一致的数量	LOW

好与坏的元数据示例

显示名称：

修改前	修改后
catSelectClick	Category Selected
pgVw	Page Viewed
ord_compl_v2	Order Completed
usr_prop_acct_tier	Account Tier

描述：

不佳（侧重实现）	良好（意图 + 上下文）
"在导航组件的点击处理程序上触发"	"当客户从导航菜单中选择产品类别时触发。示例类别：电子产品、服饰、家居。"
"在提交时触发的事件"	"当用户完成结账并确认订单时触发。包含所有订单项、已应用的折扣和最终订单总额。"
"参见跟踪计划"	"新用户首次通过验证电子邮件完成引导流程时触发。每位用户终身仅触发一次。"

---

Amplitude MCP 功能选择

在运行时检查已连接的公开 Amplitude MCP 目录。工具名称和封装方式可能会更改， 也可能在逐步推出期间以不同形式公开，因此应根据其公开说明和架构选择 功能，而不是依赖此技能中记录的名称。

上下文与发现

• 使用项目上下文功能发现可访问的项目 ID，并读取所选项目的设置。如果有多个可用项目，请让用户选择；切勿根据项目名称推断 ID。
• 如果提供了分类体系搜索功能，则使用它来发现事件和属性；否则，对当前分类体系读取器进行筛选和分页。使用实体搜索查找图表、仪表板、笔记本、实验、群组和已保存内容。
• 进行任何写入操作前，使用工作区或分支功能检查审批要求、分支保护、权限和当前分支。

分类体系读取

• 如果目录提供了整合的分类体系读取器，优先使用它。使用其公布的判别字段选择原始事件、自定义／标记事件、事件属性、用户属性、群组属性、派生属性、查找表、渠道或持久化属性。
• 如果目录提供了单独的事件或属性读取器，只能使用其文档说明的筛选条件和分页字段。不要臆造别名，也不要从其他读取器复制参数。
• 从返回的分类体系行中解析事件和属性名称。名称区分大小写；不要用显示名称替代。
• 穷尽读取时，必须遍历所有游标。如果响应报告了总数，需将其与累计行数核对；否则，必须满足读取器文档说明的终止游标条件。页面读取失败或不完整都不算完成。
• 审核事件／属性合并、值映射或其他清理规则时，使用可用的转换读取器。

元数据更新

• 只有在确认当前架构支持所请求的对象类型、元数据字段、分支选择器和作用范围后，才能选择事件或属性变更功能。
• 先读取准确的当前对象。仅更新明确确认的字段；除非用户要求替换，否则保留现有描述；不要根据旧版工具推断不受支持的参数。
• 事件属性元数据可以是全局范围，也可以限定于单个事件。使用架构明确提供的作用范围控制；除非当前架构有说明，否则不要假定省略该参数就表示全局范围。
• 自定义／标记事件定义是完整替换，而非合并。传入完整且已核实的定义，并警告用户重命名可能会破坏引用。
• 除非用户明确要求，否则绝不更新名称以方括号或供应商前缀开头的系统事件。
• 任何写入操作前都必须获得明确确认，并遵守跟踪计划的写入权限和分支保护要求。

---

工作流

• 根据标准审核名称和元数据：“根据客户标准进行审核”（第 2 层）。
• 删除和清理审核：tracking-plan-audit 技能。