埋点：又称为事件追踪（Event Tracking），指的是针对特定用户行为或事件进行捕获，处理和发送的相关技术及其实施过程。
功能方面：埋点是用来收集用户行为数据。比如想要了解一个用户在APP里面点击了哪些按钮，看了哪些页面，做了哪些事情等，就可以通过埋点来实现。
实现方式方面：埋点就是通过植入一段代码到某个页面或某个按钮，从而监听用户行为并进行收集上报。
第一步【埋点采集】：通过部署埋点，收集数据
第二步【数据传输】：将埋点收集到的数据，进行传输
- 实时传输：flume>kafka>db？
- 离线批量传输：jdbc>db
第三步【数据存储】：定义数据存储的库，如果数据量较小建议采用mysql，oracle等关系型数据库；数据量较大，建议采用hive，hbase等分布式数据库。
定义好数据存储的表结构，属性尽可能采集全面。
第四步【数据统计】：根据业务需求进行etl开发，输出业务所需的数据
第五步【数据应用】：业务人员验证和使用数据
1 埋点采集
1.1 埋点范围
根据业务人员的需求，选取可以衡量需求效果的数据指标，比如页面浏览量，页面转化率，访问人数，访问频次分布等等。明确需要收集哪些维度的数据，按需选择性埋点。
1.2 埋点事件
我们可以对一条业务流程中涉及到的各种操作进行事件埋点，用于了解该业务各操作流程的用户流失率，转化率等情况。通常包括但不限于以下事件：
- 页面事件：用户访问页面的信息，比如可以通过页面埋点统计页面浏览量（PV），或收集该页面上的接口；
- 点击事件：用户在页面的点击行为，比如想要收集用户点击搜索按钮时，填入了哪些关键字，就可以在搜索按钮上埋一个点击事件，通过字段keywords上报的值实现分析关键字的目的；
1.3 采集内容
埋点时需要尽可能全面的采集数据，主要包括以下信息：
- 用户基本信息：描述用户的基本属性信息，包括用户ID，性别，运营商，设备类型等
- 时间信息：事件发生的时间
- 行为信息：用户做了哪些行为，比如点击行为，浏览行为等
- 行为对象信息：用户的行为作用在哪些对象上，比如点击按钮A，浏览页面B，那么A，B就是用户行为作用对象
- 另外，也可以从4w1h（who,when,where,what,how）五个维度来划分埋点属性
2 数据存储
2.1 存储方式
根据埋点数据量和现有平台选择一种最合适的存储方式。
【Mysql】: 使用于数据量较小，优点读写方便
【ES】：现有埋点方案中，阿里日志系统，通过ES查询埋点结果
【Hbase】：适合数据量较大，可考虑使用现有hbase集群。
数据写入方式：中间件 or 直接写入？
2.2 存储频率
采用【定时】+【定量】的方式，保证数据时效性和数据平滑处理。
定时：周期触发，进行存储。避免当数据量较小时很长一段时间不存储。
定量：设置阈值，当数据量达到一定量（1k）即进行存储
程序退出：某用户退出登录时，需立马进行存储
3 注意事项
3.1 选择后端埋点还是前端埋点
比如像点击、浏览、曝光这些行为便可以用前端埋点，主要是发生在用户与界面的交互；如果是电商中要统计下单成功这个事件，客户端是没有办法知道订单是否成功的。如果统计的事件里有需要用到后端的数据，也是要进行后端埋点的。
3.2 埋点事件的格式
埋点数据是需要存储起来的，数据就会有它对应的字段。一般一条埋点数据需要记录：
事件ID、事件名（英文名、中文解释）、事件属性（属性英文名、中文解释、属性类型）、埋点形式（前端/后端）、事件触发时机（什么时候投递这个事件）
3.3 埋点报文
报文(message)是网络中交换与传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息，其长短很不一致，长度不限且可变。简单来说就是用户在App内有一个操作行为，就会上报一组带有数据的字段。这些字段组成一个报文。报文一般包含以下字段，简单举例，根据公司业务自行增删
{ "os": "js",
"os_vers": "端上的OS版本",
"dev_id": "设备id",
"model": "设备型号",
"manufacturer": "设备制造商",
"proj_id": "工程id",
"source": "渠道输入数字：1android_2ios_3H5_4小程序_5微信_6服务器后端_7QQ_100其它",
"proj_ver": "软件版本",
"up_time": "报文上传时间-毫秒时间戳",
"face_id": "事件全局唯一标识",
"accs_time": "事件发生时间,毫秒时间戳",
"serv_time": "服务器时间,毫秒时间戳",
"event_type": "view/click", "event_ver":"业务版本/事件版本
"ip": "290.39.55.75",
"longitude": "56°75.343",
"latitude": "143°07.230【非必填GPS关闭无法获取】",
"netwk_typ": "wifi/4G" },
"refer_id": "无埋点场景下所浏览页面的上一个页面的唯一标识",
"duration": "页面浏览毫秒数，关闭页面时统计",
"banner_id": "埋点自定义事件属性值",
"banner_name": "埋点自定义事件属性值",
"banner_type": "埋点自定义事件属性值",
"banner_city": "埋点自定义事件属性值" },
"usr_props": { "gid": "游客id", "uid": "登录账号", "province": ‘上海’】",
"city": "北京",
"city_code": "110",
"age": "22",
"sex": "1男_2女",
"phone": "13601197458",
解释一下这些报文的意思
1) trace_id为每个事件的全局唯唯一识别符，trace_id=md5(proj_id+source+accs_time+"salt盐")
- proj_id为工程id，accs_time为端上行为时间
- source为渠道来源：1android_2ios_3H5_4微信小程序_5微信环境_6服务器后端（只填数字）
2) 请求为post提交方式，header中需要添加：projId，source，upTime，uploadId 四个参数，uploadId=md5((projId+source+upTime+"salt盐")
- proj_id为设备id，upTime为上传时间
- source为渠道来源：1android_2ios_3H5_4微信小程序_5服务器后端（只填数字）
- 由于nginx中lua编程接收参数自身原因，header中的参数只能使用驼峰 projId，source，upTime,uploadId
- salt测试环境下为：test，salt正式环境下为：p1@PeFz4ZX
3）uid值在游客状态下为空，登录状态下有值；dev_id值在任何情况下都得传4）上面的报文为一次上报的报文格式，data中可以包括多次事件的信息5）基于客户端每次要使用客户流量才能获取$province，$city，ip，这三个字段保留，但是值为非必填。最终由后端根据请求ip和经纬度计算省市信息。6）报文中的json的所有的key可以不能遗漏，即使是value为空，如果是空值要用双引号""，不要用null。7) proj_id、sdk_ver、event_id，业务属性，必须按照产品需求保证对应关系，否则上报的数据会被丢弃。