前言
朋友分享了个数仓的PPT，就聊聊对埋点和数仓的一些认识和体验。
埋点
先谈谈埋点吧——用户行为分析的数据来源。 （通俗些就是格式化，以表格形式展示的目标日志数据）
战士上战场，莫得子弹 就是一个死。 分析者是战士，数据就是子弹，埋点就像制造子弹的机床。
就我所知，目前大部分企业获取用户行为大数据最好的方式就是在各终端设置埋点。目前使用的是全埋点的策略——也就是终端框架内，所有可交互的元素在触发时都会被采集。
（好像5W一下子都有了?）
How：
采集元素目前主要分为四大类：页面采集（Page）[弹窗的弹出也可以归类为页面元素上报]、按钮采集（Button）、输入框采集（Input）、列表曝光采集（Expose） 所有希望数据入库的事业部，必须严格按照上报入库流程与格式，传入数据，并给出相应注释。
这是目前整个大数据侧埋点入库的基本框架，他对所有事业部都一视同仁，保证了行为数据入库的规则性（觉得此处用规范力度欠缺）。规则性这个定义，在我的职业（还有学习，生活）生涯中真的很重要，很重要，很重要。特别是对数仓这样一个承载各方海量数据，且经常出现跨系统关联的载体来说，严格遵循入库规则是重中之重，否则就是一场灾难。
好了，再细说一下埋点采集与数据上报：
1、页面采集（Page）：用户每打开新页面都会上报一次页面访问记录（重新打开同一页面也会再次上报）。该条记录上报的内容是前端预先设定（有上报需求来源于业务侧），通常由页面上报名称和其它通用上报字段组成。通用上报字段因为是共有字段，我们最后一起说。来看看页面上报名称的设计，我的心得是：千万！不要！让前端自己决定！ 如果你希望你的数据来源一团浆糊 Whatever
页面ID上报结构：A_B_C_D：用这种层级下划线连接的方式，定义上报ID，就很清晰。如：page_id = BUSA_acp_home
定义：A业务线下，页面上报类，首页 的页面上报。
2、按钮采集（Button）：用户每点击一个按钮都会上报一个按钮点击记录。该条记录上报的内容是前端预先设定（有上报需求来源于业务侧），通常由页面上报名称和其它通用上报字段组成。
按钮ID上报结构：btn_id = BUSB_acb_{prod/other/outer}_Alist#1_Productid 我仍然在用的一种按钮上报方式，体验不错。
定义：B业务线下，按钮上报类，{商品类，功能类，对外导流类 三种按钮类型 选其一}，按钮嵌在A列表的第二个位置（智能推荐，千人千面，此处仅代表单个用户的情形），按钮的产品号。
3、输入框采集（Input）：记录用户在文本框输入的任何信息和动作。包括你与意中人交流时时，反复斟酌句读，辞藻，踌躇犹豫的矛盾心理，在此处都能记录的明明白白。
输入框上报结构：1:我稀饭你很久噜，做我女朋友中不 / 2：我稀饭你很久噜 / 3：一起吃个饭吧 / 4：你在做什么？你到家了嘛 ——直男聊天案例 定义：首先输入了1，删除部分输入后到2，增加输入到3，4等等。
连带你的初始输入，删除，撤回。。。曲折的心路历程还有总输入时间，都会被记录且细化到毫秒级。所以不要再质疑企业能获取你的生日，身份证号，密码等信息，数据安全真的全靠自觉。（以及草票）
4、列表曝光采集（Expose）：简单讲就是给用户看到了哪些元素。因为智能匹配或着死规则匹配的普及。每个分类的客户都会被给到企业认为合适的行为路径（哪一类的用户被推荐哪一类的产品，跳转哪一个页面早已被商家安排的明明白白 ）
列表曝光上报结构：按钮id，所在列表，所在页面以及其它通用上报字段。
定义：页面下曝光了哪些列表，这些列表中又展示了哪些按钮元素，分别在第n个位置。
5、能采集到的东西肯定不限于此（Other）终端位置，APP版本，终端内其它APP。。。只有你想不到~
#附上通用字段：1、上报/采集时间 2、来源业务线 3、来源终端 APP/微信/官网 4、来源渠道 5、经纬度 等等。这个业务侧可以根据业务需求增加多个，个性化很强的上报，放在同一个json格式的字段即可
Why：
tips：上面说的一些东西应该是对大数据自研比较看重的公司，才会考虑到的事情，使用三方BI服务或者对数据监控，分析要求一般的企业may不用care这个。夹个How much：因为成本贼高，真正开始为业务赋能和变现，需要一定时间（与人才、投入等因素相关）的迭代才能走上正轨。
好了谈谈为啥需要数仓：
1、数仓大 目前的发展态势是业务方对数据的需要量越来越大，品类越来越多，追溯的时间越来越长。如果你要求后端同学把每天上千万条（勿杠）的用户记录存在MYSQL库中，且需要保存三年以上，不仅你的线上会土崩瓦解，开发同学也会砍死你。恰巧数仓放得下。它能相对精准，尽可能长的存贮所有数据（有价值，无价值，还未被意识到有价值）成为企业的数据资源，为业务赋能，数据分析、挖掘提供数据基础。
2、精准化，格式化的存贮并展现海量数据，并明确数据与数据之间，表与表之间的关联血缘。同一个商品的进出货，成本，利润，物流，评价，购买者，购买者的年龄，爱好，收入以及他的前世今生，如果设计有度，理论上都是能够实现的。
3、查询效率高，不管是SQL还是成熟的 数据产品，都可以高效率高指向性的获取所需要数据，取数或者做报表（数据可视化应该也算报表，虽然不太想承认）
谈谈为啥需要设计埋点规则和上报规范：
1、打通跨部门，业务线的数据通道，避免数据孤岛的形成。——多部门结合用户上下游数据，进行数据分析或流量分发，共享时需要用户完整的行为路径、标签等数据。如果从一开始就有相同的或相近的上报规则，后面的方案实施水到渠成。
2、统一上报规范，避免重复造轮子，以及混乱数据造成的资源紧张。——一个上报大类只需要设计一个表结构，明确且只需用户付出一次认知成本，维护成本也很有限。如果n个业务部有n个页面上报，如果大数据侧有一个需求迭代，就需要改五次。
3、尽可能保证上报数据的纯净，易识别，边界明确易获取。——不管是使用SQL还是代码获取数据，本质上都是挑选符合规则（呵 规则又出现了）的数据，结构化输出。
稀烂的埋点上报会出现两个结果：
a）大量的特殊处理 取一个简单的列表按钮点击你需要 case X when 条件A then a when 条件B then b ........end。
b）你再怎么写单独处理的规则，都取不出相对纯净的数据。核心转化计算错误，误导业务侧做出错误的决策。
战士上战场，数据源都是错的，还分析个锤子。
4、统一指标口径，避免同一指标多个统计结果。
直接举个栗子：运营侧统计的日活和产品侧统计的日活，最后结果相差颇大。细查发现是查了两张不同的表，数据差异其实是合理的，但按理说：两者差异最起码应该小于3%。细细查发现，指标口径定义会有些许差异，一方定义了已注册用户的独立用户号User_id，一方统计了独立设备号Device_id，因为部分业务并非强登录，所以结果相差颇大。
所以同一个指标名称，同一个指标定义，同一个取数逻辑这样就不会被发现出了纰漏了。
综上：
1、规则及早的制定和实施，并绝对不轻易更改。——迭代意味着数据缺失或是老数据难以复用，当然你可以喊研发一次性按新规则刷个几年的数据，如果算法得当，还能保证80%数据真实，可用。
2、各部门严格按照规则实施，不管是老数据或是新需求。——这一点很重要，也是坑最多的地方。各部门有各部门的角度、理解，数据上报也不是业务核心行为。牢骚fa也不赘述了。规则，统一 事前一分力，事中省十分（好诗 好诗）
今天好像全在写埋点？？？
最后：
仅个人观感，如有谬误，敬请指正。
公众号：半仙范世巴