本文为读者系统讲解了数据采集的核心原理、埋点技术、工具、组织建设等方面知识。文章探究了采集的整个过程，包括后端交互采集方式、用户行为采集方式（即埋点技术），以及数据采集中的工具、团队组织建设等多方面内容，通过阅读本篇文章，希望你对数据采集有更清晰的认知和了解。
数据采集是数据体系建设的最上游，是非常重要的一个环节，除了专业的数据人员，人们普遍对数据采集的认知度不高。
如果你提起埋点，应该很多人都熟悉它。它应该也是绝大部分人对数据采集的认知了。数据上报其实是一个系统性工程，它涉及了工具、团队、团队协同、标准、流程等多方面的内容，其中任何一个部分出现问题都有可能让上报过程变得复杂，下游数据出现问题的概率增高。
本文系统的讲解了数据采集的核心原理是什么，以及工具、组织改如何建设，希望能让你对数据采集有一个清晰的认知和了解。
一、数据采集的整个过程
我最早接触的数据采集是从业务的数据库中COPY各种表到数据仓库中，就是从一个库中的一些表以各种形式拷贝到另一个库中再以各种形式存储下来的过程。这是一个后端交互的采集方式。
后来逐步了解到，原来还可以去采集用户的行为，名词叫埋点。采集用户的行为主要目的是为了以数据的视角观察用户是怎么在你的产品里“活动”的，为了帮助设计者了解设计的缺陷，优化交互设计，提高产品的体验。
数据采集中埋点的概念绝大多人都有听说，但基本上是停留在听说阶段。知道要埋点，反正埋点了就能有数据，然后就可以分析了。这么理解没问题，对于使用者本身，就足够了。
直到真正开始做数据采集这个工作时，慢慢了解到数据采集是个比较复杂的事情，它涉及众多角色，涉及繁长的流程，和建设指标一样，是个既简单而又复杂的的工程。
二、从行为到指标，数据是怎么来的
1. 用户行为动作的抽象过程
应用程序的出现是为了满足用户的各种需要。例如网上购物、看视频、玩游戏、社交等场景，所有的场景活动都会有用户在应用上的各种行为操作。
下图是京东移动端的首页，京东的核心场景是购物，用户在应用上浏览商品，挑选，购买。用户在京东上的所有的操作行为都可以归类为“动作”。
用户和应用程序的交互，不像现实生活中的“动作”那么丰富，例如走路、开门、跑、跳，这些实际的物理动作在应用程序范围内是不会发生的。人在应用程序的动作会受限于使用载体本身（手机、电脑、电视..）的人机交互，如早期的手机用按键，控制电视需要用遥控器，psxbox等游戏机用手柄等。
人机交互动作更多是像登录、浏览、点击等动作，用户在应用程序的操作，就是这些实际的物理操作，不会囊括太多现实中的其他物理动作。
例如“扔手机”这个动作，没有和手机发生实际的交互，只是在现实中进行了物理的动作，该动作就不会让手机本身“知道”并记录下来。
2. 从动作到日志的交互过程
既然动作被限定在人机交互这个范围内，记录用户行为就有规律可循。识别用户的动作，并把它记录下来是数据采集的核心目标。现在以京东商城购物为例，看看从动作发生到数据记录的过程是什么。
下图是京东商城手机端的首页，我们现在准备记录我的两个2个动作：
- 我浏览了该页面。
- 我点击了家电家具的按钮。
我的两个动作是浏览和点击，但动作的实际发生是要作用于具体的实体对象的，也就是“我对谁做了什么”：我点击了哪个实体，我浏览了哪个实体。
通常来说，用户在应用上的动作（谁对什么做了哪些动作），统一归纳理解为“事件”，可以理解为，发生了一件什么事。
事件的基本要素可以用这四点来描述：一个用户在某个时间点、某个地方，对谁做了什么什么动作。
总结归纳一个事件需要包括的四个要素：谁、什么时间、对谁、做了什么动作。
定义了“事件”，应用程序就需要在动作实际发生时，把这个事件以数据形式记录下来。
在技术上，通常以记录日志的形式表现出来。也就是说，当我“点击”了京东家电家居的按钮时，应用会把我这个动作存储成一条数据：
$user_id:用户：勍爷（谁） $event_time:时间：5:30:30（在什么时间） $event_postion:”位置：jd_home_detail（对谁，页面） $event_content内容：eid_jd_home_app（对谁，按钮元素） $event_action:动作：click（做了点击动作）
日志一般用JOSN的格式来表示：
{ "user_id": "勍爷”,
"event_time": "5:30:30”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_home_app”，
"event_action": "click”,
}
如果我继续在京东首页上分别点击“京东电器”、“京东到家”、“京东超市”三个按钮，则会产生三条日志记录：
京东电器：
{ "user_id": "勍爷”,
"event_time": "5:30:31”,
"event_postion": "jd_home_detail”,
"event_content": "eid_jd_app”,
"event_action": "click", }
京东到家：
{ "user_id": "勍爷”,
"event_time": "5:30:32”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_tohome”,
"event_action": "click", }
京东超市：
{ "user_id": "勍爷”,
"event_time": "5:30:33”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_market”,
"event_action": "click", }
上面三条记录中变化的只有envet_content（对谁做），同一个动作（点击），记录了4条不同的记录。
3. 更多的描述——参数的引入
事件的基本要素描述了事件的主体，他们构成了一个完整的事件。但是仅仅只记录事件的基本四要素信息，如上面日志记录里的内容，是不够我们用于业务分析的。
例如用户勍爷，是注册用户，他用的什么设备登录？IP地址是什么？在什么地理位置？用的什么网络？点击的按钮？跳转地址是什么？
再如，首页中的搜索框，“搜索”事件，用户输入了什么关键词、搜索类型？是否触发联想词、输入词为空的搜索？
分析需求多种多样，需要记录的数据内容就会变的更多。要想记录更多的数据，可以对事件的四要素进行扩展。
如下图：
我们可以增加对该事件基本要素更多的属性描述，例如对用户进行描述扩展，对动作、实体对象进行更丰富的描述，这些描述统一为扩展参数。扩展参数的记录，应该根据实际的需求来进行合理的设计，从指标和维度的实际使用情况来倒推所需要的参数是什么。
例如，根据上面的例子，如果想了解在北京用IOS端点击“首页家电家居”按钮的用户数是多少，我们需要在事件中加入参数：
$event_ip：IP地址 $event_client：客户端
然后再加入一些用户的属性，性别、年龄、身高、体重4个参数，则日志会变成这样：
{
"user_id": "勍爷”,
"gender":“男”，
"height":“184”,
"weight":“165”,
"age":“18”,
event_ip“：“114.206.233.55”,
"event_client":“IOS”,
"event_time": "5:30:31”,
"event_postion": "jd_home_detail”,
"event_content": "eid_jd_app"，
"event_action": "click",
}
对于参数，可以基于事件的四要素做归纳：
【用户类】【页面元素类】【动作类】，每个类别都可以做扩展。
4. 公有参数、私有参数、日志长度
1）公有参数
随着加入参数的增多，日志也需要一定的统一性。
例如想用户的基本属性，设备号、用户名、注册时间、会员属性、性别、年龄等，对于任何事件来说，都是需要包含对应的用户参数的。几乎绝大多数统计，都需要用户的基本属性。如今天有多少会员登录、有多少新用户、有多少年龄18岁的女性用户等等。它具有普遍性，几乎每条日志都会带有这些参数。
这类参数视会被视为公共参数，他是在一定范围内，不论你定义什么事件、不论你分析什么，都会进行采集的。
2）私有参数
私有参数的范围更小，依赖业务自身的特定需求。例如直播这个业务辅助电商进行销售，那直播会有自己的私有业务属性；例如弹幕、打赏等动作，从事件本身就单独独立于电商整个体系，它有自己的私有业务规则，所以在直播这个领域内，它会有自己特定的参数。
这时候，采集的日志表现，只会在直播这个业务范围内，才会存在这些参数。
3）日志长度
如果从日志的视角来看，把每一条日志都格式化后，每一个参数对一定一个字段，它们的长度是不一样的。
我们假设有两个事件：
【直播进房事件】、【商品详情播放事件】来看一看他们的格式化后的长度：
两个事件所产生的日志长度是不同的，因为采集的参数（字段）不相同。这两条日志结构中，都有三个类型，其中关于用户属性的参数，是完全一致的，我们认定它们是公共参数。
房间、SKU、主播ID、商品视频这些具有独特的业务含义，并不会再其他领域内出现，故描述它们的属性就属于私有参数。
用一张图来描述Event模型：
5. 日志的格式设计：定常、扩展与嵌套
因为日志长度不同，在使用以及后续的处理上就会带来不便，想想看，你的EXCEL中有1万条不同长度的数据是个多么恐怖的事情。
但是最重要的是，对于传输和解析（把日志结构化）就变的异常困难了。每条日志都不一样长，每个日志都具有独特的私有参数，批量解析需要规则，对某一字段是保留还是解析成结构化需要设定一个统一个规则。
从成本的角度来讲，如果每一条日志都需要合理的解析成结构化的数据，那么消耗的计算资源也会大很多。从传输、解析、理解、扩展和后期维护的角度来看，日志的格式需要有特定的规则，而不是杂乱无章的。
所以，根据上述的内容，日志的格式设计需要满足以下几点：
- 日志的字段长度要一样，便于维护。
- 为了满足需求的灵活性，日志需要有扩展性。
- 扩展性字段需要统一定义，方便下游用户解析。
- 运用嵌套满足扩展性所以日志保持定长、并有共识的几个字段，通过嵌套来满足业务的灵活多变添加更多的参数。
定长设计多少个字段、不是拍脑袋决定的，需要根据业务长期以来的分析需求通过抽象来判断的。
例如设备号、IP地址、通信波段等最常用的，然后留有一定的扩展位，扩展位留几个，取决于设计者的技术方案与成本、运维、解析便利性以及容错性来综合判断。
如上图，假设统一定长的日志是10个字段，其中7个字段是最常用，这7个字段是全局公参，是所有需求都需要的字段。
剩下留有3个扩展位，每个扩展字段下的内容还可以再扩展，留有足够的扩展空间。在这些扩展位中，可以写入业务的私有参数，也有可能是局部的业务、用户的公有参数。但它不是全局性的（公司级）如何扩展、把哪类扩展内容固定在具体的扩展字段上，需要与多方达成协定，便于后续的解析工作。后续解析成结构化，由使用方自行决定。
格式的设计没有对错之说，核心目标是要保障稳定利于传输、具有扩展性、可读性好、容错率高、传播协定便于解析的特性。至于是20个定长字段，还是10个，外层有一个扩展字段还是多个，需根据公司的实际发展需要来决定。
6. 一个完整行为的记录
看一个实际的例子，如上图，我的行为路径分成了6步：
- 启动京东商城应用。
- 进入首页，再点击家电家居按钮。
- 进入家电家居页面，再点击家电馆按钮。
- 进入家电馆页面，点击美的空调广告页。
- 进入美的空调详情页。
- 点击商品视频，播放视频。
用户的动作可以分成这几步，我们对动作进行同类合并，这几步中，一共有4类动作：登录、浏览、点击、播放。
然后是实体位置，一共有多少的页面和按钮参与了这些动作，用表格来描述：
浏览的动作理解起来比较特殊，页面暴露在手机上，就等同于这个页面让用户看到了。所以一般都把浏览动作定义为曝光动作。
曝光是一个用户被动触发的动作，它是高频出现的。只要页面或者页面上的各种内容出现在（在手机上暴露）用户面前，都会触发曝光动作。如果用户只是上下浏览滑动，没有点击具体按钮，那么用户的动作就只有曝光。
通过表格的统计，一共包括了4个页面，4个按钮，4个动作。其中每一行都可以理解为一个独立的事件，每个事件在触发后，都会生成一条日志，这一套动作下来，一共产生了14条日志。
此时如果我退出了应用，系统在记录一条我退出的动作，我这个自然人在应用上留痕的记录就是15条。
假设该应用有1万个用户都做了上面的动作，则将会产生15万条日志记录。这些日志都会以定长的方式发送到接收服务器中，最后加工成表。
千万的用户会产生千万的行为轨迹，我们把应用的页面、元素与动作组合成一个个事件，每个用户的轨迹就上述的表格一样一条一条被记录下来。
7. 捕捉、传输、SDK与管道
前面讲述了从动作到日志的过程，但实际上它是如何具体实现的呢？
它总的逻辑类似于石油的开采过程：
1）客户端上的采集
手机、pc、tv等终端上的各类应用，都会设有固定的采集器，如果想采集每一个用户的行为数据，那必须在每一个用户的应用上，安装采集器。采集器的核心作用有两个：采集和上报。
- 采集行为日志，把用户的动作记录成日志。
- 把日志传送给管道，把日志传输到提前设定好的服务器中。
采集器需要具备小巧精干的特性。一般采集器都是主程序的附属功能，它不能占用程序的太多资源、不能因为采集消耗用户大量的电量、流量资源，同时还不能干扰主程序的正常运行，不能为此带来风险。
2）管道
用户日志产生了，日志怎么样传输给服务器？
需要假设传输管道。类似于手机上插一根usb线，另一端插在电脑上。采集器和管道之间存在一个协议，采集的日志以什么样的格式传输，一次传输多少，传输到哪里去，都需要管道来承担。如同这个usb是几代，线有多粗一样。
一般管道的设计需要考虑几点：
- 传输容量（带宽）。
- 传输开关（类似于水管开关）。
- 分流器（主管道分流到分支管道）。
- 解析器（改变数据格式）。
- 容灾机制（确保管道畅通无阻，抗宕机数据丢失风险）。
其中开关、分流、容灾的设计是非常重要的。开关类似于水管水龙头，能够确保随时关上水龙头，因为池子可能有满的时候。
分流的意思是不希望水都从一个管道过来，这里要考虑的问题有：如果水被污染了怎么办？另一个是场景是有的业务不想用水了，可以自行关闭，而不是一直开着让水溢出。所以需要提供独立自主的控制能力。
解析能力在数据采集中是必要的一步。因为数据上报上来的格式不便于直接使用和理解。需要将其解析成格式化数据。
例如JSON格式：
{
"name": "John",
"age": “30”,
"city": "New York",
"pets":
[
{"name": "Fluffy",
"type": "cat"},
{"name": "Rover",
"type": "dog"}
]
}
这样的数据不易被理解，不易被SQL直接使用。由于SQL语言具备群众基础，或者说所有数据工作者都会SQL，最理想的方式还是进入到数据库中用SQL语言来处理。
所以把不同结构的数据解析成结构化（表的形式）的能力是数据进入到数据库中的必要工作。大多数时候，用户根据自己的实际需要进行解析，解析的工作主要由数据仓库工程师来完成。
解析能力放在管道中是一个争议较多的话题，通常管道不涉及解析能力。如果有，也是单独的模块，它与管道解耦。类似于在水龙头出口加装一个净水器的作用。
之所以不建议设计解析能力的原因是管道是一个传送单位，它不对传送的内容做过多的干预，只是确保传送的内容能够传送到制定的地方。如果增加解析能力，则会对管道本身增加一个数据质量保障的责任，如果没有足够的服务能力，就不能保障服务是可靠的。
三、全埋点与代码埋点
全埋点与代码埋点是个技术的开发方式，但这个开发方式影响着很多人对埋点、数据采集的认知。除了在数据专业领域的人，很多人对埋点的认知是非全面的，非系统性的。这也无可厚非，毕竟不同角色只会专精自己的领域，对于非本职工作，能够协同完成即可，不会过多的探究内在原理。
所以经常有人会提问，做全埋点、无埋点、自动化埋点不是更好吗？希望能够减少数据采集的工作中的工作量。
1. 识别、抽象、统一设定
首先，上面讲述的事件，日志，这些都不会凭空出现。采集日志的过程一定是程序来实现的，它运转在电脑、手机上。
所以你要记录的用户的行为一定是有开发代码的过程的，例如一个简单的按钮点击事件代码（ChatGPT帮我写的）：
document.getElementById("button-id").addEventListener("click", function() {
//记录按钮点击事件
trackEvent("button-clicked", {
buttonId: "button-id",
buttonLabel: "按钮标签",
userId: "用户ID",
timestamp: new Date().getTime()
});
});
其中，trackEvent是一个自定义的函数，用于记录事件和数据。button-id是需要跟踪的按钮的ID，buttonLabel是按钮的标签或文本，userId是用户的ID，timestamp是事件发生的时间戳。
要记录用户在某一个元素上的点击、曝光等事件，该前端工程师需要按照已经设计好的埋点方案写一定量的代码程序，才能够完成这个功能的开发。
但往往开发者发现，大部分的需求都是同质化的，例如是80%的需求都是曝光、点击这类事件，导致工程师开发过程中增加的只是重复劳动的工作量。
故有很多人想对此抽象合并：能不能不用写开发代码，写一次，或者安装个什么插件，统一埋点，以增加效率减少维护成本；或者是可视化的方式，在产品上点点功能，就把开发工作完成了呢？
如果想采集用户的行为信息，还无需开发，新的产品迭代，也不用理会，新功能都可以自动埋点。这种诉求如果通过技术方式来实现的一个前提就是要足够的抽象。必须清晰的定义一个让机器理解的边界，然后统一按照一个模式来完成工作。
类似于工厂生产一个产品，有多少道工序，定义好流程。所有操作需按照这个工序来，只需要在工序的第一步添加原材料，最后一步收获产品就可以了。
从埋点的角度来看，基于event模型，定义事件的要素来看，【谁】、【什么时间】、【对谁】、【做了什么动作】其中【谁】、【什么时间】、【动作】是需要由用户触发的。【对谁（页面、元素等）】是产品端上固定设计好的。
根据我们定义event过程来看，我们会预先定义用户的【动作】，例如浏览（曝光）、点击这些动作。如果所有的要素都变的已知，自动埋点就可以实现。
基于此，我们假设全埋点可能需要做到这么几件事：
- 需要识别出位置和实体（页面、元素），且能够做到更新识别（产品端的更新，增加页面、元素能够识别的到）。
- 对实体能够定义统一的evnet（事件）。
- 采集能力与上报能力。
其中，1 2 两点，是做到自动埋点的关键动作。这样，“用户行为采集”这件事，真的就可以交给机器自动来完成了。
2. 应对复杂与变化略显无力
全埋点从效率上来看非常好，但它不能解决所有问题。绝大多数业务是多变与复杂的。随着业务发展的深入和产品对体验、增长的需求增加，研究用户行为的特定诉求变得更多，变得更多样化。
例如，看基本的访问量、点击量只是初始需求，还需要看访问时长、用户轨迹等。当然如果某一类分析变得固定下来，不论业务如何发展，该类分析诉求都必要需要的话，同样是可以加入到统一定义event的动作中去的。
但是需要数据采集的用户群体往往不单单是业务、产品、还可能包括技术、财务、行政等业务的诉求，例如以下几种：
- 业务想了解哪些用户点击了XX元素之后直接下单的。
- 技术想知道哪个页面加载的速度大于800ms，哪些页面加载后闪退了。
- 同一个大业务下，运营和产品两个部门对于直播进房事件的定义不同。
- 分析师想了解视频自动播放对于DAU的影响是什么。
前后端关联、不同业务部门的不同诉求、分析师的原因探究、实验、技术对性能的追求，这些都是复杂、特定、多变的场景，与自动化处理采集的过程，天生和抽象、统一就是对头。
所以，全埋点是个理想的方案，但它不适用于复杂的业务形态。
另外，从成本的角度看，如果产品内所有的页面元素都规划了evnet，那上报的数据量会非常恐怖。例如有1亿DAU的应用，收集的日志量会有几百亿条/天（保守估算），但这些数据还仅仅只能看最基本的PVUV，那我们的报表成本未免也太贵了。
但是，全埋点非常适用于用户量级小（10万级），业务、产品交互逻辑不复杂的产品。例如公司的内部网站、论坛、行政、报销、分析、ERP系统，或者一些TOB的系统。并且对于数据的分析诉求不是那么的深，就是想了解DAU,或者DAU是自己的核心OKR等团队。
同时这类产品团队也不会投入太多的精力去做数据采集的事情，也不会把采集的数据合理入仓。他们只是想看一看基本的数据，至少在产品0-1，以及1-100的相当长的一段时间内，都不会有太复杂的变化。
B端的用户群体少，尤其是服务公司内部的，性能、稳定性、产品交互，都不会像C端一样要求甚高，出现问题，至少可以司内线下沟通解决，容错率和宽容度是有的。所以对于技术、体验、交互方面的复杂采集需求是非常少的。
另外，内部工具基本以提高效率为核心目的，大多数没有业绩、收入等增长的诉求，也不会想方设法的去找如何提高业绩、增长的方法。
代码埋点和全埋点对比：
四、工具要怎么做
工具的建设范围包括SDK+管道+采集的管理能力，其中SDK、管道的能力被管理门户所管理。SDK、管道是采集的必备能力，它相当于采集石油的磕头机和运输管道。
管理门户的作用主要是控制SDK、管道的能力。所以，理论上来讲，没有管理门户，石油也是能够被采集上来的。
关于采集的工具设计，需要结合上面说到的核心原理与采集方式。首先是全埋点的方式，识别、统一定义、这些能力集成在全埋点的SDK中。SDK要具备采集和上报的能力，采集和上报可根据规则进行调整，用于适配各种不同的管道。
如果管道和SDK联合设计，就可以结合组织、技术、业务体量来设计格式、协议等，这里更多是技术方案的对接，就不过多赘述。
我想重点阐述一下，在核心能力之外的衍生能力建设，这部分能力更多集中在管理能力上。
1. 使用场景与工具的演进
采集的工具建设不是一下子变出来的，它也是结合实际的需求在不同阶段有不同的产物。我们可以结合业务的逐步发展，来推演工具到底如何建设。
我们的演进路线图如下：
2. 一个人的采集
业务发展初期，几乎很少在一开始就考虑如何采集数据的。一是没有团队上没有专业领域的人来设计，二是团队更聚焦业务与市场，精力不够，三是不会投入太多的成本在采集数据上。
初期的业务产品需要快速试错，敏捷迭代，所以全套的采集方案和快速迭代的产品节奏是对不齐的。绝大多数情况都是在产品快要上线的两到三周前才会思考要看什么数据来监测产品的情况。
并且数据分析诉求也非常简单，几乎一个dau就囊括了所有需要。所以团队不会在数据采集投入太多的资源，更无需专业人员来做。这个时期，几乎所有的采集任务都由研发来包办了。
产品、业务、运营的全部精力投入在自身职责范围内的工作，几乎很少提出相对专业性的分析体系和思路。研发绝大多数情况按照自己的理解进行采集，同时还需要对接数据管道、数据处理、看板报表等工作。
假设公司没有健全的数据工具体系。这个时候的研发要承接采集上报+管道+数据落地处理加工的角色，研发可能受制于工作进度紧等压力，部分数据统计诉求直接读取业务数据库，基本上怎么简单怎么来。
因为即便是找到一些集成的sdk工具，也需要搭建管道，后续的etl处理等数据专业工作。对于业务研发来讲，已经跨越职能领域了。有的时候会直接去买第三方工具，简单的部署环境后，就可以完成需求，简单迅速还有服务保障。
3. 协同与质量
随着业务的发展进入成熟期，业务对数据的诉求越来越多，越来越深入，数据采集的工作变得复杂和沉重。这个时期用青黄不接来形容最合适不过。
数据量上来了，需求多了，采集任务更复杂了；客户端的研发在采集上消耗的精力越来越多，并且不单单是做新增任务，维护和问题排查也会占用精力，甚至很多时候已经超过了正常的业务功能开发。
这个时期，出现了采集协同。开始对需求进行把控，需求的规范性和合理性开始被重视起来，开始从需求源头控制，减少不合理需求、重复需求、增加需求流程。
另一个主要现象就是数据质量问题开始频繁出现，如数据不准，不及时，或者某些问题导致采集失效等。
问题频发核心问题主要有：
- 采集方案的不合理导致的数据问题。
- 缺少相应的质量保证流程机制、缺少测试环节。
- 组织上缺少专业的人员来负责整体的采集工作。
- 缺少采集标准与规范。
这个时期的采集需求场景通常是，需求者提交一份excel需求单，描述了自己的需求，研发基于需求单进行开发，上线后不出问题就算结束。工具在这个时期开始体现重要性了，它需要具备流程、机制、规则的约束性、并具有采集管理能力。
与很多产品不同，采集工具并不能帮我们主动写代码，自行采集（全埋点方式例外）。采集代码还是需要依靠研发来完成，所以工具的能力更注重采集的管理和质量能力，他们对工具的诉求主要是：
- 我都采集了哪些内容？
- 需要有对采集内容的增删改查能力
- 每天数据采集的成本是多少？
- 我采集的数据是否按照我的要求采集？是否有采集？
- 如果出现问题时，是不是可以提前告诉我？
- 如果已经出现下游应用问题，能不能快速排查到问题点？
- 能否在上线前有联调测试能力？
下图描述了采集工具需要满足的上述能力建设领域：
工具的建设不是一成不变的，随着需要的增加和变化逐步调整目标和适配性。数据采集的工具主旋律以质量为主，效率在采集的层面上是其次需求，它并非是个主要或必要的需求。
大多数采集是跟随客户端发版的迭代速率更新的，在效率层面上的核心用户群体是客户端研发和测试。研发效率的提升不在于对新增采集需求写代码的效率，而是出现问题如何快速定位的能力。
所以从效率的角度上来讲，质量工具体系建设的越好，对研发的效率提升越明显。
测试场景是质量的一个前置环节，能否测试充分、提供较为全面的测试能力非常重要。在业务成熟阶段，很多部门配有测试，测试业务功能的同时连带着测试数据埋点。测试过程是工具提效能力的一个重要场景。写测试用例、测试过程相对耗时。
经常出现的情况是，测试功能的时间都很紧迫，埋点测试的时间就会被挤占，甚至是不测。这样就会对后面的质量埋下隐患。
所以，工具的建设核心是：
- 尽可能的提高数据采集质量的把控能力，包括上线前的测试、合规性检查，上线后的监控、诊断能力，在提高质量的同时，能够间接帮助研发、下游提效。
- 提效不是重心，可以重点帮助测试高效的测试充分分担测试压力。
- 成本控制最好在采集之初提前设计，提供全套能力。
- 具备管道的开关能力，保证数据流的控制，防火防灾。
- 能够方便查询采集内容的元数据查询能力。
- evnet的增删改能力。
五、组织与流程
组织与流程是数据采集中最容易出现问题也最容易影响效果的环节。业务是不断发展变化的，产品工具也是不断迭代的，组织也是如此。
组织最好能够和工具有比较好的配合，或者说工具能够更好的契合组织的运转达到1+1>2的效果。前面说过，一个研发就可以完成数据采集的工作，所以什么样的组织都可以运转，就看组织是否高效、专业，能够发挥出组织的设定优势。
如果依旧拿业务的发展视角去看组织的变化与发展，先去看在这个过程中，有哪些角色参与到实际的采集工作中。
依旧用这张图来看：
随着业务的发展，数据采集工作必然会从研发独立一个角色负责到专业团队负责的转变。
但这个变化不是提前设计好的，它是结合需要来变的，需要主要来自于：
- 解决因为需求来自不同部门或同一部门的不同角色导致的需求重叠、不合理需求的问题。
- 解决测试不充分，验收把关的问题。
- 解决释放研发精力的问题（排查问题等占用的额外精力）。
- 解决数据采集统筹到数仓的问题。
- 解决成本控制问题。
- 增加采集质量把控的能力。
在很长一段时间内，公司的埋点方式都是由产品提出需求，研发来完成埋点，在工具上进行管理的方式。
这么做的好处是，产品迭代的过程中，就可以把采集埋点完成。但主要问题是缺少统筹，对需求的合理性没有判断。需求较为零散，不成整体性。
因为往往迭代周期内，没有太多的时间去思考清楚数据分析的需求，但又必须赶在迭代上线前，要完成一些数据的采集。
所以，采集的合理性和有效性往往偏低，更取决于提出需求人的思考与设计的能力，使得需求的质量必然变的参差不齐。
也许很多数据采集从采集那一刻起就从来没有用过。所以对业务产品+研发+工具的形式，必然会造成需求冗余、研发精力被过多占用、测试不充分、数据采集有效性和利用率不高的情况发生。
现在有很多公司会把埋点工作统一到一个部门，通过bp的方式来做，这样做减轻了业务部门的负担，但对业务需求提出的标准提高了不少。另外还有专职的测试人员加入进来保障测试质量。
集中管理的好处是：
- 对需求的统筹管理，减少不合理、冗余需求。
- 标准较方便统一落地执行。
- 可以做专业度较高的事情，例如治理、运维等工作。
- 不断提高工具的能力。
- 集中做数据治理、统一行动的项目变的可行。
但这种组织形式也有一些问题，比如团队的成长性价值、投入回报、与业务的合作关系挑战（例如强势的业务提出冗余需求无法拒绝）流程过长等。
以上是两种主流的组织形态：
- PM+研发自提需求自行消化，借助工具进行管理。
- 专职人员负责采集，借助工具进行管理。
我认为，随着工具与技术的进步，未来的形态可能是这样的：由业务输入需求，系统半自动化完成部分工作，由少量的专业人员进行监督的模式。
拉齐需求水平，降低研发成本，提高采集的数据利用率，减少基础物理成本，提高数据采集服务是未来的组织建设方向。
六、写在最后
数据采集是每个公司都必然会做的事情。不同的发展时期有不同的投入和组织建设，往往公司不会在一开始就会对此做顶层设计，包括工具、技术、组织，都是随着业务的发展，对数据的诉求变大或变复杂逐步调整的。所以每个阶段的演变都会留下些许历史痕迹。
在流程中参与的角色，叫疼的人会改变工具和组织的形态，流程和组织都在逐步的变化。但变化都是往成熟、高效的方向去变，变化的过程中也会冒出很多创新或者失败。
数据采集是数据体系建设的最源头，它的干净与否决定着数据的信赖程度。很多时候我们轻视它，是因为它简单；很多时候它很复杂很头疼，是因为它参与的角色太多，下游链条太长，增加了沟通协作成本；有一种现象是，我检查了没有问题，但它就是有问题。
随着ChatGPT的出现，输入需求进行AI埋点、自动化测试、采集数据将变得可能。半自动化监督的方式可能是未来采集的方向。
人工智能减少角色的参与，人来把控需求，效率和质量交给AI。把采集这个看起来简单的事情，变得真正简单。
作者：勍爷小箴，微信公众账号：数据产品设计 datadesign
本文由 @勍爷小箴 原创发布于知识吧。未经许可，禁止转载。