埋点问题

• 埋点代码倾入性太强。
  • 像寄生虫一样挂靠在业务流程的各个环节。
  • 需要捕获用户的各种行为，比如点击、浏览、分享、元素曝光、热点图、页面路径...
  • 埋点可能干预原有的业务行为。比如为了记录来源的信息，需要在分享时手动注入这些埋点需要的信息。典型的例子是，惟客云的 _ref_useId、_ref_wxOpenId、_ref_bzId。
• 精细化运营驱动着埋点的精细化。
  • 埋点需求千变万化。根据不同的业态、平台、不同的公司对埋点的需求都不一样。
  • 不同公司可能使用不同的埋点提供商。不同供应商提供的能力、要求上报的格式可能不一致。不可能因为供应商的变动，整套应用都需要重新翻一遍加上新的埋点代码。
• 埋点和业务变更的节奏是不同步的。
  • 业务变更节奏比较快，埋点很容易过时、或者被破坏。
  • 埋点规则、埋点文档不清晰。

埋点功能抽象

目前大部分埋点采集都是采用事件模型(Event Model)，事件的 5 个基本要素：

• 时间(when)。 事件发生的时间、会话时间等等。
• 地点(where)。发生的地理位置。例如 IP、坐标位置。
• **人物(who)。**当前用户是谁，用户 id、微信openid 等等。
• **行为(what)。**事件的内容。
  • 业务行为，下单事件，以及下单事件附带的各种参数，例如商品、商品类型、价格等等，取决于业务和采集目的。
  • 交互行为。比如点击按钮、进入哪些页面。这些行为通常也要关联业务信息。
• 方式(how)。设备、进入的场景、渠道、页面、来源信息(来源门店、分享来源)。