每位开发人员都应该了解的关于产品数据追踪的相关知识

产品数据记录了您的应用程序或网站内部实际发生的情况。它展示了用户的行为、系统的运行状态，以及业务的运营表现。

在本文中，您将了解什么是产品数据、哪些部分值得追踪、哪些部分可以忽略不计，同时也会明白：编写代码的开发者实际上承担着比他人认为的更大的责任。

目录

• 什么是产品数据？

• 为什么应该追踪产品数据？

• 还有谁会使用您所追踪的数据？

• 为什么应该尽早开始数据追踪？

• 为什么数据追踪永无止境？

• 在您的产品中应该追踪哪些内容？

• 有哪些内容是不应该被追踪的？

• 如何安全地处理用户数据？

• 总结

什么是产品数据？

产品数据指的是您的应用程序或网站内部实际发生的情况。它能够回答一些简单的问题：用户喜欢哪些功能？他们在使用过程中会遇到什么障碍？应用程序的加载速度是多少？哪些操作会导致用户完成购买或注册流程？

产品数据是经过验证的信息。调查和用户的反馈可以告诉您他们的想法，而产品数据则能展示他们实际做了什么。

这种差异的重要性远超表面看上去的那样。人们往往会错误地回忆自己的行为——他们会说结账过程没有问题，但实际上却放弃了继续操作。但您的数据不会出现这样的问题。

为了便于追踪和管理产品数据，您可以将它分为三类。

1. 用户行为数据

这类数据记录了用户在您的产品中实际进行了哪些操作，以及他们是如何使用该产品的。它能够帮助您了解使用模式、功能的使用情况、用户在使用过程中遇到的障碍，以及他们的整体使用体验。

这类数据能够回答以下问题：

• 用户多久点击一次“加入购物车”按钮？

• 有多少用户完成了新用户引导流程？

• 用户在结账过程中的哪个环节会放弃继续操作？

• 新访问者需要多长时间才能加入等候名单？

• 是哪次营销活动吸引了这位用户？

2. 系统与后端数据

这类数据记录了用户在与其交互时系统的运行情况。它提供了系统内部运作的详细信息，帮助您了解前端界面、服务器以及代码的运行状态。

这类数据能够回答以下问题：

• 一个页面需要多长时间才能加载完成？

• 哪些API接口会返回服务器错误信息？

• 该应用程序消耗了多少内存？

• 执行一次数据库查询需要多少时间？

• 在极端情况下，你们的业务逻辑是否依然能够正常运行？

3. 业务指标

这些高层次的数字能够帮助你判断产品从商业角度来看是否运作良好。它们将用户行为、系统性能与财务数据及发展趋势联系起来。

常见的业务指标包括：

• 每日和每月活跃用户数

• 月度重复收入及每用户收入

• 转化率与流失率

• 用户在特定天数后的留存情况

• 功能被采用的百分比

这三类指标是如何相互关联的

这三个类别从不同的角度描述了同一个产品。真正有价值的地方在于它们之间的结合之处。

假设某企业的某个支付接口开始出现错误，这就是系统数据；遇到这些错误的用户会放弃购物并离开购物车，这就是行为数据；而如果这一周的收入低于前一周，这就是业务指标。

单独来看其中任何一个指标，你几乎无法获得有用的信息。一个出错的接口可能并不会造成严重后果，被 abandon 的购物车也可能只是那些在浏览商品的用户，收入下降也可能是由于季节性因素造成的。

但只有将这三个指标结合起来分析，才能真正弄清楚问题所在：接口出了故障，因此购物车被放弃，进而导致收入下降。

为什么应该跟踪产品数据？

你应该跟踪产品数据，因为这些数据能用事实取代你的猜测。收集应用程序的数据可以帮助你规划发展路线，在问题出现之前就加以解决，并让你了解用户的真实行为，而不是你主观认为他们会如何行动。

如果不进行数据追踪，开发产品就如同在夜晚驾驶汽车而不打开前灯——你虽然在移动，但却无法看清前方的道路。

想象一下，在没有数据支持的情况下，人们是如何做出决策的。讨论往往只会停留在“我认为用户不会喜欢这个功能”这样的层面；但当你拥有数据时，就可以将这种观点转化为具体的问题，并找到答案。比如“为什么大多数打开了这个功能的用户再也没有回来使用它？”通过数据来支撑决策，这才是关键所在。

数据还能帮助你了解用户的真实使用体验。这不是你设计出来的使用流程，而是用户们实际的操作方式。你可以从中发现他们在哪里停留、哪些步骤被跳过了，以及他们究竟有没有找到应用程序的某些功能。

跟踪数据还有助于你发现用户获取和留存方面存在的问题。如果你无法看到问题所在，就无法解决它们。更糟糕的是，整个行业的留存率数据都相当不乐观。

根据Adjust在2024年发布的基准数据，移动应用程序在一天后能保留26%的用户，在一周后保留13%，而在30天后仅保留7%。在网页领域，这一情况更为严峻。Contentsquare基于超过6,500个网站上的990亿次访问量所进行的2026年数字体验基准研究显示，只有13%的访客会在30天内再次返回这些网站。

通过数据追踪，我们能够及时发现那些会悄悄导致你损失资金的故障。Baymard研究所通过对50项独立研究的数据进行汇总分析，得出了购物车放弃率的平均值，这一数字为70.22%。当他们询问人们放弃购买的原因时，有17%的人表示网站出现了故障或崩溃，另外17%的人则认为结账流程耗时过长。这两种情况都属于技术故障，但它们并不会出现在错误日志中，而是会直接影响你的收入。因此，只有通过数据追踪，才能避免这类问题的发生。

如果不能全面了解自己的市场状况，也会带来巨大的损失。当人们对市场动态一无所知时，企业甚至可能会因此倒闭。例如，CB Insights追踪了自2023年以来关闭的431家初创企业，发现其中43%的企业之所以倒闭，是因为产品与市场的匹配度不佳。而这类问题本可以通过数据分析提前发现，从而避免做出错误的商业决策。

总体来说，大多数团队都已经认识到了数据的重要性，并且认同我们需要基于数据来做出决策。根据Salesforce在2025年3月进行的一项调查，76%的商业领导者感到自己有压力，必须用数据来支持自己的观点。此外，大多数人也都认为，他们的职业成功与否取决于他们是否具备“数据素养”以及是否能够以数据为依据来开展工作。

那么，让我们再从另一个角度来看看数据的重要性——看看还有哪些团队成员会在工作中使用这些数据吧。

还有谁会使用你追踪的数据呢？

几乎整个团队都会使用这些数据。事实上，这些数据的传播范围比大多数开发人员想象的要广泛得多。

首先，你会自己查看这些数据，用来判断昨晚发布的版本是否引发了某些问题，某个功能是否值得投入维护成本，以及性能瓶颈究竟出在什么地方。之后，这些数据还会被其他团队成员继续使用。

你的产品经理会用这些数据来决定接下来应该开发哪些功能；设计师会通过这些数据找出用户在使用产品时遇到的困难；分析师会利用这些数据来分析收入变化的原因；技术支持人员会借助这些数据来理解为什么投诉量会突然增加；市场部门会用这些数据来判断哪些营销活动真正吸引了用户并使他们持续使用你的产品；而公司的创始人，在每次讨论产品发展路线图时，也会先查看这些数据。

• 你能够看到错误发生的具体情况，并追踪到导致问题的具体环节。

• 你的产品经理会根据这些数据来判断因此损失了多少转化机会，从而决定是否需要优先处理这个问题。

• 你的分析师会从这些数据中提前发现用户流失的迹象，并将其纳入分析模型中。

• 你的技术支持负责人最终会明白为什么在周二投诉量会突然增加。

• 你的市场人员会发现，有些付费用户最终无法完成结账流程。

而你的创始人则会看到那些本应到手的收入并没有真正进入公司的账户，从而在接下来的会议上提出更有针对性的问题。

一个事件、六个人以及六个问题，而所有这些都可以通过你在某个下午编写的三行代码来得到解答。

请注意，那六个人实际上都在做同一件事：他们正在做出决策。

这才是数据追踪的核心意义。数据本身并没有价值，只有当有人因为这些数据改变了想法、发布了不同的产品，或者停止了那些无效的做法时，数据才真正具有价值。

正是这种需求催生了各种与数据相关的职业。随着企业规模不断扩大，已经没有人能够完全记住整个产品的所有细节，因此决策过程不再依赖直觉，而是需要证据的支持。

首先出现的是商业智能分析师，随后是数据科学家、数据工程师、产品分析师以及分析工程师——这些职位的出现都是因为数据量不断增加，而需要更多的人来处理这些数据并帮助做出决策。每一个这样的职位存在的根本原因，都是因为有人需要做出决策，但却无法预见所有可能的情况。

在一个小型团队中，或者在一个你从零开始开发的产品项目中，所有这些工作都可以由你独自完成。在刚开始的时候，这些工作的规模通常会比较小，你并不需要进行复杂的分析。正如我在这里所建议的那样，简单的数据追踪就已经足够了。

为什么应该尽早开始数据追踪？

你无法回顾过去，也无法重新模拟用户在产品上线第一个月的行为模式，更无法弄清楚是哪个功能吸引了首批用户注册。同样，你也无法解释三个月前用户数量突然下降的原因。你的数据从你开始收集的那一刻起才开始产生意义，而在那之前的所有信息都会永远消失。

尽早开始数据追踪还能帮助你在产品规模扩大后应对各种挑战。到了某个阶段，你可能需要聘请分析师或数据科学家来协助工作；但如果你从一开始就一直在收集数据，那么你就为他们提供了一笔宝贵的资源。而如果之前没有进行任何数据收集，他们可能要花费整整一个季度的时间来等待足够多的数据才能开始进行分析。

如果你已经开始了数据追踪工作，那说明你做得很好，请继续坚持下去；如果没有开始，现在就行动吧。即使你这周还在搭建代码基础架构，也请在这一周内加入数据追踪功能。如果你的产品已经上线两年了，那么最好的时机是在产品发布之前就开始设置数据追踪系统；而其次好的时机就是现在。

从工程角度来看，尽早开始数据追踪也是很有必要的。当你从一开始就建立数据追踪机制时，你的数据架构会随着产品的不断发展而逐渐完善。因为你是在开发产品的过程中为这些数据命名的，所以命名也会更加规范和一致。如果等到两年后才开始进行数据追踪，当代码量已经变得非常庞大时，再进行修改就会变得非常困难。因此，请尽早开始吧。

尽早开始数据追踪并不意味着要追踪所有的事情，而是意味着从一开始就追踪一些关键的信息，并在此基础上逐步完善体系。在刚开始的时候，你并不需要一个完美的数据架构，只需要记录一些重要的事件，并养成持续添加更多数据的习惯即可。

为什么数据追踪永无止境？

设置好数据追踪系统只是一步而已，要确保这些系统随着产品的发展而不断更新并保持其相关性，则是另一回事——很多团队却忽视了这一点。

你的产品不会一成不变。功能名称会发生变化，流程设计也会被重新调整，某些界面可能会被删除。所有这些变化都可能导致某些事件无法正常触发，某些参数失去意义，或者让你去收集一些已经不再具有原有含义的数据。

因此，应该将跟踪机制视为工作的一部分，而不仅仅是一次性设置好的东西。这个过程就像产品本身一样，是一个持续进行的过程。

当你发布一个新的功能时，应该在同一个拉取请求中添加与之相关的事件信息；当你修改某个流程时，需要检查该流程之前是否触发过哪些事件；当你淘汰某个界面时，也必须同时取消与该界面相关的事件的记录，并通知所有曾经查询这些数据的人。在部署新版本后，一定要验证这些事件是否真的能够按照预期被触发，就像你要检查新功能本身是否能正常工作一样。

进行验证是非常重要的。如果跟踪机制出现了问题，这些问题往往是不会被立即发现的。Monte Carlo的一项调查发现，74%的数据专业人士认为，是企业的相关人员最先发现数据问题的，而且这种情况几乎总是如此。由于很少有人为数据分析功能编写测试用例，因此某个事件被停止记录后，往往要几周之后才会在别人的仪表板上显现出来。

偶尔对整个数据跟踪架构进行审查也是很有必要的。每年一到两次，仔细检查所有的事件信息，针对每一条事件问自己三个问题：这条事件现在还会被触发吗？还有没有人会查看它吗？它的名称现在还能准确反映它的功能吗？

你的产品中应该跟踪哪些内容呢？

每个产品都是不同的，因此并没有一个适用于所有产品的通用列表。一般来说，你应该跟踪那些会对你的业务产生实际影响的数据，而忽略那些没有意义的信息。

具体来说，前面提到的三个类别可以对应到一些具体的数据跟踪对象。以下是它们各自的详细分类：

用户行为会转化为事件和用户属性；系统及后端运行情况则会表现为崩溃信息、性能数据以及后端错误；而业务指标则有所不同，理解这种差异是非常重要的。

你不能直接为业务指标编写跟踪代码。不存在像`track_mrr`这样的函数。你需要从另外两个类别中计算出这些业务指标的值。这就是为什么事件的质量会直接影响你的业务报告的质量的原因。

事件

事件是你需要跟踪的最重要的信息。任何在产品中具有实际意义的操作都可以被视为一个事件。点击按钮、完成购买、提交表格、分享内容，或者跳过引导流程，这些都属于事件的例子。

并不是所有的点击操作都会被记录为事件。你应该重点关注那些能够体现用户意图、展示进度或产生实际价值的操作。

事件的命名应该采用`动词+名词`的形式，并且使用小写字母连写。谷歌自己推荐的跟踪事件名称就是按照这种规则来命名的，例如`add_to_cart`、`sign_up`、`begin_checkout`和`join_group`等。选择一种统一的命名规范并严格遵守它。如果一个数据schema中既有`checkout_failed`又有`failed_checkout`，那么其他人就很难准确地查询这些数据了。

为事件添加参数以提供上下文信息：

• failed_checkout，其中包含reason: "payment_declined"

• view_product，其中包含product_id: "123"和category: "shoes"

• use_feature，其中包含feature_name: "export_pdf"

有三种类型的事件值得重点关注。诸如sign_up、complete_purchase和start_trial这样的转化操作，是衡量应用效果的重要指标。而open_dashboard和share_report这类功能使用情况，能帮助你了解应用的哪些部分真正发挥了作用。至于abandon_checkout和exit_onboarding这样的用户退出环节，则能告诉你用户是在哪里放弃使用的——这一信息与了解他们在哪些地方取得了成功同样重要。

用户属性

事件记录了用户的具体行为，而用户属性则描述了用户的基本信息。

用户属性是一种会在不同会话之间持续存在的状态，例如套餐等级、注册月份、偏好语言，或者是否已完成入门引导流程。一旦设置好这些属性，它们的值就会一直保持不变，直到发生变化为止。

通过用户属性，你可以对各种事件进行分类分析。“有多少用户完成了结账操作”只是一个数字；而“有多少使用免费套餐的用户在首周内完成了结账”则能为你提供更有意义的信息。

有两条需要注意的事项：首先，不要将具有大量不同值的属性设置为用户属性，因为这类属性无法用于数据分组分析；其次，也千万不要在这些属性中存储个人信息。关于这一点，后面还会进一步详细说明。

应用崩溃

当应用程序在运行过程中出现故障时，就会发生崩溃。崩溃通常是由一些不可预见的严重错误导致的，这种错误会严重影响用户体验。每份崩溃报告都应该包含设备信息、操作系统版本、应用程序版本，以及事故发生时的具体堆栈跟踪信息。

性能数据

性能数据用于反映你的产品在实际用户使用环境中的运行速度，而不仅仅是在测试机器上的表现。运行缓慢的应用程序会流失客户，进而导致收入下降。

需要记录应用程序的启动时间、屏幕渲染所需时间、网络请求的耗时长度，以及用户需要等待完成的任何操作所花费的时间。这些数据应以分布形式进行记录，而不是平均值。这样，在采取行动时，你就能获得更全面的信息。

后端日志与错误信息

日志能帮助你了解代码的具体运行情况，而错误信息则能指出代码出现故障的位置。总的来说，这些信息来自你的服务器，是前端无法直接获取的。

需要针对每个接口、状态码、失败的后台任务、超时情况，以及你所依赖的第三方服务中的故障现象进行日志记录。在记录日志时，要确保提供足够的上下文信息，以便能够完整地追踪每一条出现故障的请求流程。

当无法从用户那里获取相关信息时，这些日志就显得尤为重要了。它们还能帮助你将应用程序端的行为与系统运行状态进行对照分析。

此外，后端日志会记录下有人试图滥用系统、向你的服务器发送大量请求的行为。在这种情况下，你可以提高速率限制，并采取相应措施来防止这类安全问题的发生。

不应该追踪哪些信息？

对于那些你无法据此采取任何行动的信息，就不要进行追踪。在添加某个数据记录之前，先问自己这样一个问题：如果这个数值发生了变化，我会做出什么不同的反应？如果你找不到答案，那么说明这个数值就不应该被记录下来。

千万不要追踪那些你不希望被泄露的信息。任何你收集到的数据，都意味着你需要负责保护这些信息。只收集你真正需要的数据，才是保障安全的最佳做法。

对于那些无法被准确命名的信息，也请不要进行追踪。一个清晰的名称意味着这个信息的含义已经得到了明确的界定。user_action和button_click这类名称其实只是占位符，并不能真正代表具体的事件类型。首先需要弄清楚这个事件的真实含义，然后再给它起一个合适的名字。

同一件事情不要被记录两次。每个独立的事件只需要记录一次即可。如果同一个操作会触发两次不同的事件记录，那么就会产生“哪个记录更可靠”的问题，而这种选择带来的麻烦根本不值得。

如何安全地处理用户数据？

关键在于只收集完成工作所必需的数据，并且要谨慎地处理这些数据。

不要在分析报告中包含个人身份信息。

个人身份信息，通常简称为PII，是指那些能够单独识别某个人的资料，或者当与其他你掌握的信息结合在一起时也能用来识别该人的数据。姓名、电子邮件地址、电话号码、物理地址、支付详情以及政府颁发的身份证号码等都属于此类信息。

分析工具本来就不是为存储个人身份信息而设计的，而且大多数供应商也在他们的服务条款中明确禁止这样做。因此，请使用匿名或假名的用户标识进行数据收集；只有在确实需要识别用户身份的情况下，才将数据存入你的自有数据库中。

注意那些通过参数泄露出来的信息。

个人身份信息往往就是通过这些参数被泄露出去的。例如，一个用于记录查询字符串的事件记录可能会包含某人的姓名；而一个携带电子邮件地址的URL参数也可能会直接进入事件日志系统。因此，在数据离开设备之前，必须对参数值进行必要的处理，以确保其安全性。

在法律要求的情况下，必须征得用户的同意，并尊重他们的选择。

根据欧盟的《通用数据保护条例》以及其他类似的规定，那些并非绝对必要的分析活动通常都需要获得用户的同意才能进行。

为数据设定保留期限，然后让这些数据自动过期。

大多数分析工具都会默认将数据保存一段时间，而你也能够缩短这个期限。数据保留时间越短，安全性就越高。三年前的事件细节其实很少会有用处，因此使用汇总后的数据反而会更合适。

记录下你收集的所有数据。

文档的作用非常重要。一份详细列出所有事件、所有参数以及这些参数存在原因的文档，在隐私审查、审计过程中，或者在有新工程师询问“`evt_flow_2b`是用来做什么的”时，都会为你提供很大的帮助。

总结

产品数据能够真实反映实际发生的情况，而不是用户所说的情况或你的个人观点。

需要从多个方面收集数据：用户行为数据能告诉你用户具体做了什么；系统数据能显示你的产品运行状况如何；而业务指标则是由前两者综合分析得出的。单独某一类数据可能无法提供足够准确的信息。

无论你目前处于哪个发展阶段，都应该立即开始进行数据记录。因为上个月的数据已经无法再被恢复了——这个机会窗口每天都在关闭。

为那些需要查询这些数据的人，给这些事件起合适的名称。使用“动词+名词”的格式来命名，保持一致性；同时要明确说明各个参数的含义，并在修改相关内容时及时通知团队。

随着产品的发展变化，要及时更新数据结构。在添加新功能时，也要一并更新相关的数据记录；每年至少进行一两次审计，删除那些没人会使用的冗余数据。

长期来看，认真记录产品中的各种数据所带来的好处是显而易见的。

干杯！