数据驱动，是一个热门词汇。作为国际 SaaS 细分领域领跑者的 AfterShip，其数据驱动的落地也并非一朝一夕，背后蕴含了相关同学无数日夜的努力。

本文作者是 AfterShip 移动端技术团队 Corona 的一员，他将从业务视角出发，与我们分享 AfterShip 在数据驱动方面的落地和探索历程。

前言

2019 年底， Corona 团队支撑了移动端产品 AfterShip App（#1 Shipment Tracking）第一个版本落地。作为 To B 业务公司中的 To C 产品，APP 中的每一个动作都与用户体验、产品基础息息相关。

基于该项目，Corona 与后端、Data、QA 等团队一起，完成了数据驱动在业务团队“从零到一，从一到持续”的发展。

为什么我们会在意数据

“如果你无法量化它，就无法管理它 (If you can’t measure it, you can’t manage it.)” 这句话说出了我的心声。

数据，是技术团队验证功能是否完成的重要工具。

什么意思呢？ 我举个栗子。

假设我们开发一个给照片自动美瞳的功能。用户上传一张人像图片，loading 之后，人像的眼睛覆盖上了美化的效果。现在，研发同学完成了本地开发、自测，质量同学验收通过。Okay, 发布上线!

这个时刻技术同学(研发 + 质量)能说，「这个功能，我做完了」 吗？

我认为还不能。我们本地验收能覆盖的场景是有限的，线上环境会更加复杂。比如线上用户可能会遇到他的图片我们识别不到眼睛位置；用户网络比较差，美瞳这里要 Loading 半小时； 图片处理异常，出现花屏的结果；... ；毫无疑问，线上如果出现了这些问题，都意味着美瞳这个功能在我们的用户看来，没有实现。

那么，如何验证业务功能在线上的实现程度呢？很简单，两个步骤: 数据收集和数据分析。

技术工作的「完成」标准，不是编码完成、质量验收通过后发布上线，而是功能代码在线上复杂环境中的运行结果符合产品需求的描述，用户 100% 获得了预期的结果。在这个过程中，数据，是我们需要依赖和重视的工具。

延伸开来，也想简单提提技术成长的话题。很多技术同学都有这样的困惑:

• 这个 XXX 很简单，没有什么挑战；

• 技术不就是 Copy + Paste，它的难点在哪里？

• 我期望在技术深度上有成长，可是该怎么做？

• ...

这些困惑可能一个原因在于，没有很好地理解技术工作满分的标准。

我用一个大家熟悉的场景来类比。一张高考数学卷子，我们是怎么来区分普通学生，数学大神呢？我们不是通过卷子有没有写了字来判断，而是看它的分数，分数有没有到及格线？是不是满分？

同样的，对于技术工作来说，实现一个产品功能，在大部分场景下，都是简单的一件事，甚至有时候只需要 ctrl + c 、ctrl + v 就可以。但是，它仅仅相当于我们在高考卷子上填了字儿。

怎么样是及格？怎么样是满分？试着给代码添加数据埋点，然后把它扔到线上去看看有多少比例的操作获得了预期结果！那就是技术工作这张卷子的「分数」。你会在线上看到各种各样神奇的问题，或是系统底层、或是框架缺陷等等导致没有给用户输出预期的结果。有句话说「魔鬼藏在细节中」，那么对技术工作来说，技术人的魔鬼藏在线上。技术的一个成长就是不断地消灭线上一个又一个的魔鬼，把这张卷子的分数提高到 80 分，90 分，100 分。

数据指导产品迭代，同时也是辅助技术人才成长的重要工具。这也是我们不断推进数据驱动的一个重要原因。

下面我将从数据 1.0 到 3.0 阶段，以实例一一剖析。篇幅略长，还请各位看官坐稳了。

数据 1.0 - 从 0 到 1，先解决数据有无的问题

没有好的大前端数据收集实践，缺乏有效的数据反馈。这导致 APP 在头几次发版后，产品经理（以下简称“PO”）、技术同学无法明确感知线上版本的运行情况。

2020 年初，数据 1.0 建设工作正式启动。一出门就遇到了 3 只拦路虎：

1.如何设计且收集什么数据？

解决方案是：在 Google Sheets 创建埋点文档，由 PO 在功能需求设计的同时，给出对应的数据埋点设计。文档示例如下👇

这是一个「功能点」层面的设计方式，针对功能进行埋点设计，虽然零散，但能满足产生对应产品数据的需要。

2.数据上报到哪里？

APP 端选择了 Firebase。通过 Firebase SDK 上报数据，最后对接到 Google Analytics，实现上报、观看、分析一站式管理。同时，Firebase 做好了大部分 App 环境数据读取、上报，如 location、screen 等，减少了人力投入成本。

3.怎么观看、分析数据？

得益于 Google Analytics 丰富的数据统计报表和简单的报表自定义功能，支持路径分析、数据表、趋势变化、漏斗分析等常用的图表类型，满足基本数据分析场景。

于是，在这个阶段我们的整体数据链路表现为如下形式:

数据 1.0 上线后，App 项目终于可以通过数据了解线上真实运行情况：

举个例子，“APP 卸载率高”是结果；通过 Google Analytics 路径分析，我们成功定位到了原因—— 用户抵触 “启动 App 后要求账号注册登录”功能。

基于此，PO 优化账号注册登录的时机设定；再次发版后，App 卸载率得到有效降低。

在数据 1.0 阶段，实现了一套简单的数据收集、分析方案，解决了数据从无到有的问题。但它有不可忽视的局限性：数据计算依赖 Google Analytics，无法实现较灵活有效的数据统计分析，这在技术侧数据分析表现尤为明显，很大程度上限制了数据驱动的开展。

数据 2.0 - 规范化，解决数据工作能不能走顺、走远的问题

2020 年下半年，团队扩充，群策群力的数据工作得到更多发展，进入了数据 2.0 阶段。这个阶段的关键词是：规范化。

1.数据设计规范化

数据 2.0 阶段，专业独立的数据同学接过了 PO 此前的工作，采用 PPM (Page position model) 进行数据埋点设计。文档示例如下:👇

同时，为了支撑详细数据的分析，对数据仓库做了规范化的设计。

2.项目流程规范化

为了提升数据协同效率和体验，我们在 App 项目流程中，明确加入“数据”角色及“时间点”规划。将数据工作固化到项目日常，日积月累，形成肌肉记忆。

3.数据收集规范化

随着数据设计的细化，技术团队在日常工作开展不免出现了一些困惑：

开发同学 A: 「为了收集这个事件，我的代码结构被破坏了！」 开发同学 B: 「收集这个事件，我花的时间比开发这个功能还多，有什么意义呢？」  

我们非常关注、同时也很理解这些困惑。数据工作的基础是数据收集。这一部分，非常倚重于技术同学支持。在不被理解和支持的情况下，数据工作必然是走不顺、走不远的。

那么，该如何提升效率和体验呢？

一方面，进行配套工具建设、代码架构改造，减少数据收集工作给质量、开发同学增加的负担；

另一方面，开展培训工作，让技术同学能真正看见数据、使用数据。

对于第一个方面，由于篇幅限制，我在这里挑代码架构的问题来具体聊一聊。

在数据埋点方面，我们会有这样的场景: 用户在模块 A 产生了一个数据 data_a, 而现在用户走到了模块 B，模块 B 这里的统计事件上，我们需要带上之前的 data_a.

那么在模块 B 这里，我们怎么取得 data_a 这个数据呢？简单的方式是让 data_a 跟其他的业务数据一起，由模块 A 传递给模块 B, 比如在 Android 上，我们通过 Intent Bundle 方式由界面 A 带给界面 B.

这个方式可以实现数据传递，但它也会带来问题: 如果 data_a 不是业务实现需要，仅仅是为了统计上报，会导致模块 A 带给模块 B 的数据越来越多，开发同学对数据的管理愈发吃力。更为不好的情况是，数据统计的视角略有别于业务视角，技术同学依据业务视角划分的领域，在引入数据统计之后，将被部分破坏。为了实现一个统计数据上报，技术同学不得不打破代码设计上的隔离，是一个比较常见的情况。

架构设计的一个重点在于对数据定义和流动的管控，而统计数据有别于业务数据，因此，我们在代码架构设计方面的改造，主要的考虑点在于明确划分业务数据和统计数据两条通道。

分离业务数据和统计数据通道的具体实现方式会有很多，也包括说可以在数据云端进行处理。这里仅以 Android app 为例，简单介绍我们的方式。

业务数据的传递，我们通常会有 Intent Bundle, Eventbus, manager 层缓存等等方式，这方面我们保持不变。而在统计数据这里，我们构建一个链表，每个页面的曝光动作都会在这个链上创建一个区块，用来记录本次页面曝光的相关统计用的数据。这个链表的顺序，与用户看到的页面的顺序保持一致。

我们举个例子来说明。用户打开了 App, 首次看到的页面是 Screen A. 这时候 App 在链表上创建第一个区块, 命名为 screen_A_1, 这里的 1 是 App 生成的曝光 id，它是随机数，用于标示本次页面曝光事件。当用户在 Screen A 产生了后续我们需要用到的统计数据 data_a，App 查找当前的区块 screen_A_1 并进行记录。

用户在 Screen A 点击按钮进入到 Screen B 产生了 Screen B 的曝光，这时候 App 与上面一样的逻辑，在链表上创建区块 screen_B_2.

当 Screen B 需要上报 Screen A 的 data_a 数据时候，Screen B 先查找自己当前 screen_B_2，通过 pre_impr_id 往上查询最近一次 Screen A 曝光区块，从中读取 data_a .

在这过程中，我们避开了统计数据跟随业务数据进行跨页面传递的操作，从而解耦统计数据与业务数据逻辑。与此同时，链表也比较好地反映数据统计分析的视角，与技术视角区分开来。

这部分的代码设计修改以及相关配套工具的建设，都是为了改善技术同学的工作体验，解决的是技术同学能做、做得顺不顺的问题。而接下来第二个方面的措施，解决的是技术同学愿意做的问题。固然，有明确的任务安排，技术同学肯定是会进行的。但技术同学是人，人在愿意做和不愿意做两种心态下，产出是完全不一样的。

让开发同学认同、并且愿意做好数据工作，关键在于让技术同学查得到、用得上数据。

查得到：帮助业务技术团队整理 App 数据地图。包括当前规划数据，click 事件数分布等等；通过 App 数据地图，迅速定位每个数据的存储。

用得上：进行数据仓库 BigQuery、报表生成平台 Datastudio 的使用培训。掌握基本查询方法，完成基本的数据查询、统计。

知道在哪里，怎么查，数据驱动就足够了呢？还不够。

数据驱动，是深刻理解数据的存在，懂得用数据去观察业务，指导行动。信息决定决策。它是一种思维，一种做事方式，甚至是一种习惯。

数据 2.1 - 数据应用日常化，业务、技术齐开花

怎么用数据去观察业务、指导行动呢？

1.将「业务数据观察」纳入日常例行工作中

内部解读 App 涉及的业务数据报表，让开发同学看得懂业务数据指标，培养数据敏感性。尤其是每次发版后，通过业务数据的变化，感知业务功能产生的价值，形成对产品业务的立体理解。

2.对「技术数据」，让开发同学完成从数据设计和观察，到使用数据优化功能的全过程

举个栗子，App 核心功能之一是“消息推送”。物流状态更新时，服务端为用户推送消息提醒。这个功能，目前技术实现有没有什么问题？它的「分数」是多少？

对此，Corona 技术同学 W 主动梳理了“消息推送”功能的业务技术方案流程，对业务功能的结果和过程进行指标量化。以下是业务逻辑简图与各环节指标量化:

对“消息推送”来说，它的「分数」是“目标业务事件的消息推送达到率”指标，即: “最终到达用户设备的消息数 / 预期进行推送的消息数”。此外，也有 “Firebas token 获取成功率”等过程指标，用于辅助定位当前链路的瓶颈点。

指标量化后，经过了数据收集和分析工作，生成部分报表如下:

这些技术报表，展示了当前业务消息推送功能的最终结果指标，包含了各环节的过程指标及异常情况的分布。通过对异常数据进行分析和逻辑优化，可以不断提升“消息推送”这一功能的分数。

这个过程中，技术问题被不断挖掘出来：「消息推送的原理是什么」「为什么线上会有这个网络错误」「整个业务技术方案是怎么样」「为什么 XX 环节会产生瓶颈」...  

对技术同学来说，技术理解又走深了一层，数据让人直击本质。因为，最可怕的事情，往往不是不知道，而是不知道自己不知道。

NEXT: 数据 3.0 - 效能提升，解决数据工作能不能走得快的问题

走到现在，数据工作基本融入工作日常，提升了业务与个人成长的速度。接下来，我们关注的是：能否用更自动化的方式，为数据工作提效。

“数据工作效能提升”正是数据 3.0 的关键词。是否能自动化完成数据埋点？自动化完成数据统计验收？...

这是 App 项目团队当前所处的阶段，我们也正为此不断努力中。

阶段复盘: 做对了什么？做错了什么？

回顾这段旅程，这是我发自内心的 3 点思考：

1. 始终坚持数据驱动，是对的。

作为 To B 业务公司中的 To C 产品项目，通过数据分析评估每项改动对用户、对产品整体的影响情况，是一个好的方式。回到技术侧，无论是数据角度辅助技术同学理解业务，还是数据量化帮助挖掘技术深度，都取得了切实效果。

2. 始终团结各方角色，是对的。

数据工作由数据同学、产品同学、技术同学等多方角色共同完成，数据驱动的顺利落地、长远推进，离不开各方的一致共识和共同努力。

3. 忽视收敛数据指标，是错的。

日常工作中有非常多 A/B Testing 及数据指标建立，这不可避免地带来了一些问题；比如众多数据指标影响业务团队日常工作中的聚焦；不同的数据指标得出相反的分析结论，耗费业务团队的精力进行讨论……

结语

数据驱动有利于业务项目的发展，也有利于技术同学的成长。而数据驱动的落地，它横跨了太多个日夜，也包含了太多同事的身影。这个故事如今还在继续被谱写...