用户行为分析埋点
用户行为分析系统是指由第三方提供的集合了数据采集SDK、数据分析模型、分布式算法与存储架构的用户属性与行为事件数据分析的系统。比如国外MixPanel、Heap等，用户行为数据分析的前提是在前期埋点时打好扎实的基础。
事件触发的条件、需要追踪的属性以及想要分析的维度，这些核心分析要素设置的好坏，将会直接影响到你在分析时的体验。错误的埋点触发条件，混乱的属性名设置，以及重要属性的遗漏，都会影响分析的效率与准确性。糟糕的埋点往往在完备性和易理解性两个方面存在不足。
完备性指的是事件与属性的设置能够完全实现数据分析的需求；易理解性指的是所有相关人员能够快速清晰地理解每个事件及属性的意义。
那么如何构建完备、易理解的数据埋点方案呢？以手游的数据埋点为例。
一、保障数据埋点的完备性
1、以规整清晰地格式记录的埋点方案
使用文档来记录埋点方案，是相当好的使用习惯，但如果在记录时结构不够系统，内容过于杂乱的话，那么文档的作用将会大打折扣。建议在构建文档时注意结构的规整以及内容的清晰，可以按照网舟科技建议的如下格式来构建埋点文档：
字段说明：
是否完成：如果项目十分庞大，且版本迭代频繁，那么有必要在文档中记录哪些事件是已经完成、哪些事件还在埋点中、哪些玩法尚未上线，这对于了解项目进度会很有帮助。
所属模块：建议按照游戏的系统与玩法模块来进行埋点。
事件名：埋点时使用的事件名。
事件中文名：事件的中文名，应和后台设置的映射名一致。
事件描述：对该事件的描述，补充解释事件的意义。
触发条件：埋点触发的条件，对于理解事件的意义很有帮助，也可以帮助使用者排查埋点是否正确。
重要程度：用来标识该事件的重要程度，对于庞大项目来说，优先级的标识会很有帮助。
属性描述：用以描述该事件的属性，可以按照需求加入或删除某些字段。
属性名：埋点时使用的属性名。
属性中文名：属性的中文名，应和后台设置的映射名一致。
属性类型：属性的类型，有需求可以添加。
属性描述：对属性的描述，可以写下诸如取值的枚举、易混淆属性的解释以及难理解属性的说明等。
以上的格式是推荐示例，可以根据实际情况进行修改。请注意，进行文档记录的核心目的是将有价值的信息规整地汇总起来，以便项目成员的理解、沟通和分析，在进行文档记录时要牢记这一点。
2、按照系统、玩法模块进行埋点
在上一小节中提到了根据模块来设置埋点的思路，这么做的好处在于两点：一是可以避免埋点的遗漏，对于玩法复杂、系统庞大的项目而言，能够帮助快速理清思路；二是对于同一模块的多个事件，一些属性实际上是通用的，因此在设计埋点的时候，应该将这些事件设置为同一个属性，根据模块设计埋点可以很好让你发掘哪些属性可以被多个事件共用。
3、将重要的属性设置为公共属性
当你需要分析多个事件时，可以根据这些事件共有的属性，也就是这些事件的属性交集，作为维度进行查看。一个常见的例子是，当你想要进行渠道分析，并且所有的事件都有“渠道”这一属性时，你可以便捷地选择“按渠道维度”进行查看。因此将重要的属性设置在每个事件中就显得相当重要了，如果你使用客户端接入，那么建议你将这些属性设置为公共属性。
如果你根据系统模块来设置埋点，那么应该优先关注那些与KPI相关的属性，诸如渠道、区服等等，像这样的属性，在设置的时候可以不去考虑具体的事件，而只需考虑哪些属性更重要，也就是说就算有些事件中该属性是冗余的、无意义的，也应该将其设置进去。同时如果有新的事件需要追踪，也需要将这些属性添加进去。
4、将所有的改动记录下来
你的游戏随着版本的更新迭代后，一些属性可能会失去作用，同时也会产生新的需要追踪的属性。由于后续的属性变动不会作用到老数据上，因此任何属性上的改动都会导致前后的属性不一致。为了避免增删属性对历史数据的分析造成影响，请将所有的改动都记录在文档中，当某个属性被弃用时，请不要将其从文档中删除，而是通过底色或者字体颜色等方式标注出该字段被弃用。这样能够保证在分析过往数据时，仍能查找到所有属性的意义。
二、确保数据埋点的易理解性
易理解性是一个容易被忽视的设计原则，因为在大多数情况下，对它的忽视并不会阻碍分析的进行。如果我们将不完备的埋点比作堵塞分析道路的巨岩，那么理解困难的埋点只相当于路上的小碎石，然而这种微小问题的累积却会对分析效率产生负面影响，尤其当项目变得越发庞大复杂，其造成的影响也将成倍扩大。使用者可能需要花费大量时间去询问事件及属性的意义，同时还要记下这些含义以防遗忘，这种糟糕体验对于分析的流畅性来说简直是毁灭性的破坏，因此设计埋点时需要考虑埋点的易理解性。
对于易理解性的理想要求是：任何用户可以只通过中文名理解该事件或属性的意义。这一要求可能相对难以达到，但至少要保证用户在少量说明的帮助下能够理解所有的事件及属性。为了达到这点，网舟科技提出如下的优化建议：
1、将所有的属性汇总起来
相较于理解事件的意义，使用者更可能在理解属性意义时犯难，因此埋点的设计者最好将所有的属性汇总起来，便于排查属性设置的问题。可以参考下述给出的建议格式构建你的属性汇总文档：
字段说明：
属性名：埋点时使用的属性名。
属性中文名：属性的中文名，应和后台设置的映射名一致。
属性类型：属性的类型。
属性说明：属性的说明，也可以加入取值的枚举等补充说明。
是否为公共属性：标识该属性是否是公共属性。
建议埋点设计者在项目伊始就进行属性汇总，并且每增加一个埋点，就立刻将所有属性更新到汇总文档中，这么做的好处是可以迅速排查出新埋点的设计是否合理，比如公共属性是否设置、是否有可以合并的属性、属性名是否有重复等等。
2、保持属性意义的独立
建议你将多个事件中具有相同意义的属性进行合并，但需要避免让一个属性在不同的事件中承载不同含义，比如说level在一系列事件中指代“用户等级”，在其它事件中又代表“难度”或“层数”，这样的属性设置使得中文名只能写上所有的含义，而使用者在进行分析时就必须去猜测这个属性到底指的是哪个含义，这就显得相当不便了。
实际上这个问题的本质是不同事件的属性重名，通过属性汇总文档，很容易就可以排查出这一问题，而解决方法也十分简单，只需更改其中一个事件中的属性名即可。
如果你的项目比较庞大，很容易频繁出现重名的情况，可以在这些属性名前加入模块或者事件的名称，比如misson_type，weapon_name，product_id等，即可有效避免属性重名。
3、属性的类型最好与实际操作相匹配
大多数情况下，属性的类型不会对理解产生太大的困扰，但仍有可能出现这样的情况：使用数值型来表示布尔值时，可以使用0与1、1与2或者-1与1等多种方式来指代“真”与“假”，对于使用者而言，需要花费时间确认项目中使用的是哪种方法，另外还有可能出现同时使用两种方法的情况，使用者的理解成本又会因此上升，所以最好直接设置成布尔型。另外，对于诸如“商品ID”“关卡ID”等以数字表示但无计算需求的属性，建议你将这些属性设置成字符串型。这是因为属性的类型决定了其在分析时可进行的操作，不同类型可进行不同的操作，这样设置既避免了无意义操作，比如计算“关卡ID”的总和，同时增加了有意义的操作，比如使用正则表达式查找“道具ID”。
综上所述，建议你根据属性的实际意义以及具体的操作来设置类型，布尔型优先使用布尔型，需要进行计算的使用数值型，不需要进行计算的设置为字符串型。
4、属性值能用中文尽量用中文
对于可以用中文来表示的属性，建议尽可能地直接使用中文，比如描述用户购买的商品，你可以使用数字为主的“商品ID”去指代，也可以使用中文的“商品名”去表示，这种情况下推荐使用中文的“商品名”表示。直接使用中文属性值，使用者在分析的时可以不需要查表，即可了解属性值的意义。请注意，中文请使用UTF-8进行编码。
在构建了完备、清晰的埋点方案与记录文档后，借助网舟科技用户行为分析系统，可以打通APP、小程序、网站等的用户行为数据，快速的进行用户分群、用户事件、留存、漏斗、行为序列等分析，从数据中挖掘能够推动用户快速增长的有效策略。