如何设置 Astrina 目标
在 Astrina 里设置目标，不等于开启完整监控。目标更小，它只对应某个工作流中的一个成功条件，比如表单已提交、结账步骤已确认，或者内部 QA 检查点。如果你一直在问 Astrina 目标 怎么设置，可以先把每个目标都当成一条单独、可衡量的终点线。
这种更聚焦的做法很重要，因为一个目标只应该回答一个问题：用户提交表单了吗？页面到达感谢页了吗？测试流程完成最后一步了吗？只选一个答案，不要选三个。把定义说清楚，后面会省很多时间，尤其是周五下午发布后，同事打开结果时。
1. 先决定在你的 Astrina 账户里，“目标”到底意味着什么
先从业务含义出发，不要先看按钮。目标可以代表转化、里程碑、已完成的动作，或者内部 QA 检查点。这四种情况在纸面上看起来很像，但实际表现并不一样。转化通常关系到收入；里程碑可能只是中间状态；QA 检查点可能只对产品团队有意义。
一次页面加载不是目标。一次成功的 API 响应也不一定是目标。关键是，这个动作是否能证明工作流已经到达你关心的状态。如果客服团队需要知道付款步骤是否完成，目标就应该直接写明这一点。如果 QA 团队需要知道登录后是否弹出了某个模态框，那就是另一个目标。
目标定义要尽量窄。像“用户完成 onboarding”这样的说法看起来很整洁，但它可能隐藏了三个不同状态：创建账户、邮箱验证和资料完善。如果其中任何一个失败都很重要，就把它们拆开。两个小目标通常比一个含糊的大目标更容易读懂。
2. 选一个具体的用户动作来作为目标
选一个动作，然后坚持只用它。表单提交就是一个好例子。最终的“确认”按钮点击、到达成功 URL、或在结账后看到页面上的可见状态变化，也都可以。这个动作应该是 Astrina 能够识别的，不需要猜测用户的意图。
不要把多个动作绑在一起。“用户注册并验证邮箱”听起来效率很高，但它混合了两个事件，只要其中一部分发生，就会产生混乱。目标应该要么清楚通过，要么清楚失败，中间不应该有模糊地带。如果工作流有五步，就选那一步来证明这个目标成功，其余步骤先放下。
举几个具体例子会更直观。结账目标可以是“支付页面显示订单已确认”。内容流程目标可以是“发布按钮变为线上状态”。支持流程目标可以是“工单表单显示感谢消息”。每一个都只有一个动作、一个结果、一个存在理由。
3. 把目标映射到 Astrina 能识别的精确触发条件
动作明确之后，再把它映射到 Astrina 能测量的信号。这个信号可以是 URL 条件、DOM 变化、文本匹配，或者产品支持的其他事件。Astrina 目标 触发条件要足够具体，只指向一个结果，而不是一类相似结果。如果你需要参考当前控制名称或可用字段，先查看 端点、身份验证和配额，并在发布目标前和线上产品界面做一下对照。
使用目标完成时实际发生变化的那个东西。感谢页通常有独特的 URL；结账成功状态可能会替换按钮文案，或者显示订单号；QA 检查点可能会出现某个特定的 DOM 元素。不要在有更精确方式时还依赖宽泛模式，因为宽泛模式比人们预想得更容易抓错结果。
这一步，命名纪律就开始发挥作用了。如果 Astrina 让你填选择器，就把它写得清晰易读。如果 UI 要你填事件名，就直接用真实动作命名，不要用 2022 年团队里的内部梗。一个清晰的触发条件，胜过四个花哨但不实用的。
4. 定义成功边界和失败边界
目标应该能识别真正的完成，并忽略那些差一点的情况。听起来简单，直到重试、重定向和部分加载都掺进来。一个表单可能提交两次；结账流程可能短暂显示成功消息，随后又报错；页面也可能在数据还没完全加载时就先显示了正确文本。你的目标必须忽略这些假阳性。
把成功边界设在完成的最终证明上。如果工作流结束于某个状态页，就要求出现只有完成后才会出现的页面状态。如果结束于 DOM 变化，就要求那个只会在最后一步出现的变化。如果结束于 URL，就要把条件写得非常精确。边界一旦太松，结果就会变差；结果一差，复查成本就会上升。
失败边界同样重要。目标不应该在部分进度、重试按钮或占位内容上触发。如果结账里有“稍后保存”和“立即购买”，只有一个应该计数。如果表单里有“下一步”和“提交”，也只有一个应该计数。边界越清晰，报告里的意外就越少。
5. 为目标设置命名、标签和归属
目标名称要让别人五秒钟内看懂。“结账成功页”比“目标 7”好得多。“支持表单提交 - 预发布”也比“联系表单”清楚得多。一个有六个目标的团队还能勉强靠模糊命名运转；有六十个目标就不行了。整个账户里最好保持统一的命名方式。
标签适合按发布、环境或部门来分组目标。一个标签可以标记预发布；另一个可以标记生产环境；第三个可以标记业务领域，比如计费或 onboarding。重点不是装饰，而是当有人需要为发布评审或交接筛选目标集时，能一眼看明白。
最后是归属。必须由一个人、一个团队，或者一个共享队列负责变更。如果没人负责，UI 变动把目标弄坏了也没人发现。如果归属不清，就写在目标旁边，或者写进团队 runbook 里。简单备注，少很多争论。
6. 用一个真实场景测试目标
先用一个已知正常的流程测试目标。用真实场景来测，别用人为构造的边缘情况。然后再测一个已知会失败的流程。这一对结果，比十几个猜测更有价值。如果两个都通过了，说明触发条件太宽；如果两个都失败了，说明触发条件太窄，或者指向了错误的信号。
比如，结账目标应该在订单真正完成时通过，在用户中途放弃购物车时失败。注册目标应该在确认步骤出现时通过，在用户输入邮箱后就停下时失败。测试要小，不需要为了验证一个目标，重新跑完整套监控设置流程。
如果结果看起来很奇怪，先检查目标是不是挂在了正确的动作或正确的环境上。一个在预发布环境里跑、却用了生产数据的目标，会制造非常让人困惑的证据。这种错误比团队愿意承认的更常见，但它其实可以避免。
7. 检查目标输出，并决定要调整什么
测试后，要像看客户报告一样认真检查记录结果。利益相关方能不能不求翻译就读懂？输出有没有展示正确的成功状态？它是写明了精确触发条件，还是只给了一个模糊的通过/失败？如果结果难以阅读，说明目标还没准备好。
如果目标太宽，就调整触发条件；如果部分进度漏了进来，就收紧边界；如果标签和实际完成的流程对不上，就重命名目标。有时候问题根本不在触发条件，而在措辞。一个叫“signup”的目标，也许其实应该写成“账户已创建”，因为那才是真正的终点。
这里有个很实用的习惯：找一个没参与构建的人一起复核目标。如果他能用一句话准确复述这个目标，说明它大概率没问题。如果复述不出来，通常就是目标藏了太多细节，或者用了只有创建者才懂的信号。
8. 随着产品变化持续维护目标
产品一变，没人检查，目标就会迅速过期。UI 更新可能会移动按钮；流程调整可能会重命名步骤；新的流程可能直接让旧流程失去意义。要在这些变化之后及时复查目标，不要拖到六个月后。最快失效的目标，通常是那个指向已经不存在页面的目标。
围绕发布建立一个简单的复查习惯。重设计之后，确认成功状态仍然存在；结账改动之后，确认确认页仍然带着同样的信号；新增 onboarding 流程之后，确认旧目标是否还相关，或者应该退役。小复查能避免大混乱。
如果你还需要帮助来解读这些检查周围的告警，可以参考 当 astrina 告警不再到达时该怎么办 这篇指南，它能帮助你区分是目标坏了，还是通知链路坏了。这个区分在发布窗口里很省时间。
会维护文档的团队还可以再进一步，把目标链接到一条简短的内部备注里。写上触发条件、负责人和最近一次复查日期。三个字段，足够了。如果目标换了负责人，接手的人不应该还得开会才能明白它为什么存在。
Astrina 好目标的实用示例
一个好的目标只有一个动作、一个信号、一个负责人。结账团队可能会把目标定义在付款后的“订单已确认”状态上；营销团队可能会把目标定义在已完成的潜客表单上；QA 团队可能会把目标定义在开启特性开关后才出现的模态框上。每个例子都只使用一个可衡量结果。
可以这样测试：如果你从定义里删掉一句话，目标就变得含糊了，那说明定义可能太薄。如果你再加上三个条件，目标变得更难读了，那说明定义可能太拥挤。合适的目标通常是那个仍然能抓住正确结果、但又最简单的版本。
| 目标类型 | 示例触发条件 | 应避免的内容 |
|---|---|---|
| 转化 | 付款后的成功 URL | 购物车页面、感谢草稿页、重试界面 |
| 里程碑 | 资料步骤完成 | 任何带“下一步”按钮的页面 |
| QA 检查点 | 登录后出现的元素 | 加载中的转圈、部分渲染 |
如果你还在决定目标如何嵌入更大的工作流，那么关于面向非技术网站主的 astrina 的文章，会提供一种思考简单归属和清晰检查的实用方式。当维护目标的人不是建页面的人时，这种视角尤其有用。
常见错误，尽量避免
第一个错误，是让一个目标同时干两件事。一个既追踪注册又追踪付款的目标，会因为与真正问题无关的原因而失败。第二个错误，是使用过早出现的触发条件。一个在最终动作完成前就加载出来的“成功”消息，是个陷阱。第三个错误，是把归属留空，然后指望团队自己记得。团队通常做不到。
另一个错误，是用模糊的业务概念来命名目标，而不是用可见结果来命名。“留存”不是目标。“续订页确认订阅”才是目标。这个差别看起来不大，但它决定了下一个读者是能理解测试，还是得在 Slack 里发消息问到底发生了什么。
最后，不要让一个旧目标在两次产品变更之后还原封不动地躺着。三月还匹配 UI 的目标，到六月可能就错了。如果工作流变了，目标也应该跟着变。别折腾太大，但一定要改。
把目标定义写得足够短，才能经得住变化
一个有用的目标定义，通常一条句子加一个负责人备注就够了。这个长度会逼着你把意思说清楚。它也能让同事在发布前检查账户时更快完成复核。目标应该说明什么叫成功、它出现在哪里，以及谁负责。除此之外的内容，通常更适合放到文档里，而不是目标本身。
如果你需要回头核对支撑目标的产品界面，可以把当前工作流和实时检查细节做个对照；必要时，也可以参考 如何检查网站 在移动端是否也按预期运行的产品文档。一个绑定到移动端专属状态的目标，如果没人注意到布局变化，也会失效。
这才是如何设置 Astrina 目标的真正工作：一个动作、一个信号、一个负责人，然后再做一次测试，证明这个目标仍然代表团队以为它代表的那个意思。
