编辑导读：数据埋点作为数据分析、数据仓储等的基础，在设计数据埋点的时候我们不光要依据前端特性去设计前端的数据埋点，还需要了解后端特性结合业务进行埋点设计。本文作者对此五个维度的分析，希望对你有帮助。
一般只要说到数据埋点通常情况下都是指前端的数据埋点，而并非后端数据埋点。所以往往会忽视后端埋点在整个数据埋点的作用。数据埋点作为数据分析、数据仓储等的基础，在设计数据埋点的时候我们不光要依据前端特性去设计前端的数据埋点，还需要了解后端特性结合业务进行埋点设计。
可能对于我们来说，只有前端内容是我们最直观感受，从而花费大量功夫去处理前端的埋点设计，而对于看不见的后端埋点我们往往忽视。这样使我们产品设计师（产品经理）对于数据埋点的设计理解局限在了前端交互上，把同样重要的后端埋点设计直接交给研发leader或是架构师自主设计不管不顾，这是不对的。至此本次我们聊一下后端埋点，以便配合研发leader和架构师开展工作。
一、后端埋点
数据埋点的最终归宿地都会是数据库，不管它是前端埋点还是后端埋点他们都会存入MySql或MongoDB的数据库中（数据库类型）。
相比较前端埋点在可视化页面上交互和触发，后端埋点更多是在对业务数据的请求和记录上。前后端进行比较，后端埋点在存储用户操作数据上会比前端晚一步，但在业务流程上又会比前端快一步。是因为当用户进入页面操作时，都是在页面上先进行操作，所有前端埋点的触发永远会比后端埋点快一步。但是在业务流程上（例如登录，订购等），后端埋点会比前端埋点更快一步，因为业务需要后端会和数据库进行实时“互动”，在互动结束后才会将结果反馈给前端，再由前端和用户进行交互。
后端数据埋点不像前端那么多花样，要去思考用户路径和用户交互，后端埋点更加注重业务沉淀和业务逻辑。后端埋点和前端埋点一样，也分全量、模块化和代码埋点三种。除此之外，后端埋点还有个特殊方式就是日志。全量和模块化埋点我就不在过多阐述，因为他俩对于产品设计师（产品经理）来说没有太多的要求，直接沟通研发将对应的SDK或API装载即可，我们重点说代码和日志两种方式。
代码埋点：我们请了一个施工队，这个施工队听你的指挥，并根据你在高速路上指定的位置建造收费站，这种都是一砖一瓦的施工。
优点：可控性高，满足所有的需求。缺点：研发成本、设计成本高。可视化（模块化）埋点：我们将需要建造的收费站进行模具化，只需要到指定位置放置模具，对模具直接浇灌水泥，收费站就直接成型。
优点：操作方面，布置快捷缺点：适应性差，纬度匹配度因“路”而异全量埋点：直接组装卫星发射到天上，实时监控高速路上的用户行为。
优点：用户的一举一动我们都知晓缺点：数据传输量大，数据需要二次清洗，占用大量实时资源进行数据传输。
二、后端埋点之代码埋点
和前端埋点相似，代码方式的埋点可控性高，成本也高。在理解后端埋点设计上，我们可以从前端埋点设计需要考虑的4大生命周期（页面的创建、加载、更新、销毁）进行过度理解。
因为后端的操作都在于代码的请求和运算（请求中），那么我们假设将整个后端埋点按照前端埋点设计的逻辑进行拆分，分别是请求前、请求中、请求后三个部分。
请求前：可以了解请求数据的初始状态情况，是哪位用户的，他准备买什么商品，在哪里进购买的（坑位：首页、推荐等）。请求中：依据请求的初始数据去获取用户的状态（是否是会员、是否封禁），商品的状态（库存量，价格，详细信息等）。请求后：知道明确的请求结果，知道支付是否成功，失败的原因是什么，是库存不够，余额不足或是用户自己取消支付等。
1.带入到场景中
用户点击支付商品，用户触发前段埋点，这时前端向后端请求支付（请求前），后端根据前端请求过来的数据包内容「支付信息、商品信息、用户信息等」去验证这些正确性（请求中），随后将验证结果打包处理给到前端（请求后），让前端给用户继续交互（流程图经过缩减主要用于认知，只显示主要环节所以不必太过于较真）。
2.细节
一般的验证可分为两部分，一种是数据的验证，后端对传输过来的加密参数进行头部验证，验证数据的安全性。以保证这个数据不是非法请求。另一个验证是业务验证，验证传输过来数据的准确性。用户信息对不对，库存对不对，支付密码对不对等。
文中的请求是以”前端”的视角在说。因为我们最有感知的请求中也就是我们常说的加载中。
单单