银行APP营销活动埋点既遵循互联网现有的埋点方式和方法，结合自身业务场景的特殊性，灵活运用各类埋点方式和事件定义，完成相应埋点需求设计。
一、埋点的需求来源和业务目的
埋点需求通常在形成了基本的业务逻辑、通畅的业务流程基础上，对全链路用户行为和交易数据进行采集和归档，可以帮助更好地统计业务数据和营销活动效果，方便运营、测试、研发、产品等各岗位进行数据分析、提高工作效率。
二、常见埋点事件采集方式
2.1 代码埋点
顾名思义，埋点研发人员将埋点代码直接结合到业务代码中，实现用户在业务流程中行为数据的采集。包括前端埋点、后端埋点等。此种方式的优点是代码集成度高，与业务结合紧密，可以完成较为复杂的用户行为数据采集，采集的数据颗粒度也更为精细；缺点也显而易见，开发成本较高、实施过程中沟通难度大、测试量高。
2.2 无痕埋点
也称全域埋点、自动埋点、无埋点，使用该种埋点方式的理想状态是通过嵌入完整的SDK产品，实现自动化埋点，将客户端的行为进行全方位多方面采集，从而快速、高效地完成埋点工作。此种方式的优点是SDK产品可以短时间快速完成基本埋点；弊端也很明显，不如代码埋点数据颗粒度更精确，无法进行精度更高的数据统计，而且全埋点的数据采集量大，后期业务场景复杂时，采集的数据需要进行二度加工和分析，会造成二次开发工作量。
2.3 可视化埋点
实施此种埋点方式时，产品和运营可以快速在界面上进行埋点自主操作、实时生效，可进行及时测试和调整。此种方式可帮助提高运营效率，减少沟通和开发成本，但仅能对可视化部分进行埋点，对于后台数据类的上报和统计就无法进行埋点的数据统计了。
三、埋点事件定义
3.1 事件选择
根据前述《如何做好银行APP的营销活动埋点需求？》文章中，案例初探部分，对招商银行信用卡APP“掌上生活”的营销活动“9号玩家日”的业务分析，需要进行统计数据集中在：多少用户参与了这个活动，五个子活动哪个活动参与人数更多，用户为了参与活动消耗了多少积分，又获得了多少奖品。
3.2 属性定义
根据“4W1H”原则可对单个事件进行定义，包含who，what，when，where，how等方面。
1. who-用户基础情况
包含用户id、设备id、uuid、cookie、手机号、账号、昵称、账户信息、开户信息等。
2. when-埋点事件时间戳
包含埋点事件发生时间、埋点事件上报时间、埋点事件系统反馈时间、埋点事件入库时间等。此处需要注意时间戳的定义、记录格式和采集标准，以及各种异常情况的处理，如多个子系统之间时间差导致的对同一埋点事件的对应错误。
3. where-用户使用环境
包含绝对物理环境（GPS、IP）、相对物理环境（自主填写类，如收货地址信息等）、用户地区属性（如银行特有的开户信息中的地址等）。
4. how-埋点事件操作过程
包含用户进行埋点事件操作时的操作路径、软件环境（操作系统、设备版本、设备型号）、网络环境（4G、WiFi、运营商网络等）。
5. what-埋点事件本身的描述
包含埋点事件关键节点，各节点构成对一个区别于其他独立事件的描述。如，用户打开“9号玩家日”主页面，参与了第四个子活动（砸金蛋），成功中奖并兑换了奖品（获得了积分，多少积分）。
3.3 事件上报
在完成事件定义和事件属性的构建时，我们需要对埋点事件数据上报方式、上报节点、上报时间进行分门别类，进行数据管理和埋点数据用于分析高效化。此时我们需要进一步明确事件上报内容，如上报参数内容、参数类别、参数值类型等，下面以营销活动页面进入事件为例，对事件上报具体内容进行示例：
蓝色部分为每个事件均需要统计的公共属性部分，缺少公共属性部分，无法描述该埋点事件描述的基础信息，黄色部分为埋点事件识别属性部分，这部分数据可精确区分该事件时如何发生的、造成了怎样的结果，用户经历了怎样的操作过程等。
四、小结
综上，银行APP营销活动通常为服务于终极业务目的而设立，同时需要统计的数据也集中于涉及成本费用核算、用户参与度、积分等价值分的获得消耗流水上。基于此，多种埋点方式可灵活采用，如涉及到购买、中奖等实际价值消耗的事件埋点可采用代码埋点方式，与业务代码一同上线下线；如涉及到页面打开等可视化部分，可采购现有可视化埋点解决方案，进行相关埋点数据的采集。
