前面说了那麽多理论，最後几天来写一下开发实务吧！今天要介绍的是怎麽收集 App 使用者行为资料。

Initiate

追踪事件是需要成本的，这些成本包括开发、蒐集、除错、分析等。因此一开始思考的点是「哪些事件对於商业来说是最重要的」。

由於当时的 App 的商业模式是以广告为主，最重要的就是说服我们的 App 能帮广告主带来流量，因此最重要的资料应用就是每日活跃使用者数报表，用这个报表向广告主说明每天会有多少人看过他们的广告，并以此来收费。从一开始就很明确要追踪的资料以及应用上的目的。

Design

最一开始的设计当然是以简单为主，幸好市面上有很多工具可以协助我们做到这件事。其中最有名也最普遍的就是 GA 了（Google Analytics）只要在网站或是 App 里埋上对应的追踪码，GA 就能蒐集很多使用者的行为资料。如果要纪录比较复杂的行为，可以使用自定义的事件，在应对的使用者行为发生时送给 GA。

Implement

GA 的开发真滴简单，只要在网站里埋对应的追踪码就可以了。

Deployment

同上，埋好之後就可以在 GA 的後台确认有没有部署成功，成功的话就能看到流量进来了。

Evaluation

虽然大家对於 GA 的数字还是有争议，但毕竟是 Google 的产品，所以也算是一般业界很常用来参考的数值。初期需要评估的大概就是两个点：

1. 数值是否稳定。
2. 是否能满足商务需求。

小迭代

小的迭代像是增加追踪事件，或是调整 GA 报表之类。

大迭代

用 GA 就是如此的方便，但之後就越来越难了。当满足基本商务需求後，接着就会有更复杂的商务需求，像是：「想知道不同年龄、性别的使用者会看什麽影片来更了解使用者以及找到合适的广告主」、「想知道哪部片最受欢迎来做排名推荐」、「想知道使用者留存率来优化使用者体验」等等。因为 GA 仅提供统计资料、没有办法知道特定的使用者行为，当 GA 无法满足这些需求时，就只好开始刻自己的事件追踪器了。

Design

为了追踪个别使用者行为，在自制事件追踪便纳入了使用者辨识码。以 App 来说，对於登入的使用者就会用登入帐号（Email 或个人 ID 之类），对於未登入的使用者之前可以用 Device ID 来做使用者识别。
第一个自制的事件追踪，我们先用了一个很简单的 JSON 来定义与传送资料。

{
    "device_id": "u123141",
    "email": "[email protected]",
    "user_id": "u123123",
    "timestamp": "2021-09-29 00:00:00",
    "event": "login",
    "content1": "email",
    "content2": "",
    "content3": "",
    "content4": ""
}

除了资料定义之外，也要考虑到後续怎麽收集。
我们初步选择 AWS Kineis 来做资料的收集以及 Lambda 来做後续的处理，并将处理完的资料放到 S3

App -> Kinesis -> Firehose -> SQS-> Lambda -> S3

在选择资料收集方法上的时候，要考量到价钱、可扩张性、易维护性以及稳定性。真的是幸好现在有 AWS 这样的云端服务才让这件事情变得容易许多（但 Kinesis 上次也是死了...）。

Implement

由於这次是自制事件追踪，在设计上就牵扯到很多单位。

• 前端
  前端需要实作追踪事件，在特定的行为发生後将事件传送出来。

• 後端
  由於刚开始没有人力开发後端，所以就采用上述的方式，将资料直接从前端抛到 Kinesis 上。

• Data
  Data Team 初期会负责检核资料以及做资料的前处理。

Deployment

由於自己开发的元件和牵扯到的团队变多，部署时也开始复杂起来。前端、後端、Data 都有各自的部署周期，在团队间沟通上特别需要沟通好，以免就是前端上线、但是後端还没准备好的情况。这种时候上线建议先从 Data 开始上线，确保处理资料程序上线後，前端再让资料上线，以避免宝贵资料丢失的状况。

Evaluation

评估的时候除了前面提到的商务需求外，也需要评估自己开发的部分有没有问题，包括系统稳定度、负载量等等。因为 GA 的程序还没拔掉，所以也可以交叉比对一下自己收下来的资料与 GA 的差异（通常都会有差异）是否稳定。

小迭代

上线之後除了修 bug 之外，当然也会依照实际需求来调整追踪的事件，前後端和资料团队都需要频繁的沟通和调整。

大迭代

随着 App 逐渐复杂，使用者事件也会开始变得复杂。这时候原本的事件系统也变得越来越难维护，所以我们又痛定思痛做了一次大改版 QQ...

Design

由於每个事件都有对应的资料要传，所以这次乾脆就独立一个栏位将事件内容放在里面方便整理。

{
    "device_id": "u123141",
    "user_id": "u123123",
    "timestamp": "2021-09-29 00:00:00",
    "event": "login",
    "data":  {
        "method": "email",
        "email": "[email protected]"
    }
}

{
    "device_id": "u123141",
    "user_id": "u123123",
    "timestamp": "2021-09-29 00:00:00",
    "event": "itemview",
    "data":  {
        "item_type": "recommendation"
        "item_id": [1, 2, 3, 4],
        "item_url": ["www.qq.com/1", "www.qq.com/2", "www.qq.com/3", "www.qq.com/4"]
    }
}

这样设计的用意是想让纪录事件的内容文件看起来清楚一点，但事实证明当事件一多之後还是很恐怖...抱歉了我的前同事们...

Implement

在新事件上，我们因为一些原因屏除了直接打到 Kinesis 的方法，改用 RESTFul API 来接事件，这样以可以让後端做初步的资料格式检查。但沟通上就更复杂，需要前端＋後端＋资料三个团队一起涉入开发，开发复杂度也直接上天。当初最难的做的应该是实作自己的 session(https://support.google.com/analytics/answer/6086069?hl=zh-Hant&ref_topic=6083659) 机制吧...抱歉了我的前同事，但是我们真的需要这个酷东西。

整体开发来说，事件定义是最难的。除了 Session 以外，当初还想知道使用者实际上有看到哪些版位，IOS、Android、Web 对相同定义的实作方式都完全不同。

Deployment & Evaluation

除了复杂度增加外，跟之前的差不多就跳过。

後续的小迭代

当事件越来越多，有几件事变得特别复杂

• 如何保持 living document，
• 管理文件、事件、App 版本以及之间的关系
• 如何让新上的事件不会影响旧的事件
• 旧的事件什麽时候可以退休
• App 改版时如何确保事件传送无误
• 等等...

每个都有一段血泪史这边我就先不挖了。

小结

好的事件是分析的第一步，千万不能觉得这些事件都是前端的事情，实作上前端真的有很多问题需要一起克服解决，才能维持事件的品质。