在前面《CRM系统设计与实施》这篇文章中，我们提到了流转规则，根据商机上的业务属性来判断，通过选定不同的属性组合作为特征，把某个特征的商机，分到某个目标的分配组

前序流程是用户在浏览广告页，登录页等页面留下线索时，会带上对应的业务属性参数，我们才能根据属性去分发

这个属性是如何标记的？这个是在自建线索收集能力时必然遇到的问题，解决这个问题就要用到埋点的方法

埋点上报

这里指的埋点，是做一些属性上的标记，在不同的场景下把关键的业务属性都传递到后台里，做统一管理

属性分类

如图所示，一条商机包含不限于一下的信息

流量来源：标记这个线索是从哪个外部的流量渠道过来的，比如百度，搜狗
访问页面：标记这个线索访问到自家网站后，访问过哪些页面，为了更好的标识，也会拆分成首次访问和末次访问两个属性
广告参数：即utm参数，流量来源那里对应了utm_source，其他广告计划，单元，关键词，媒介，根据业务需求标记，一般与主流投放渠道保持一致，对应了utm_compaign，utm_content，utm_term，utm_medium
其他业务自定义参数等等

如何上报

上报有如下流程
前端识别并归类（或者服务端识别）——传给CRM名片库存储——CRM元数据字典翻译和映射——页面展示

拿之前的业务环境举例，按照上报方式分，可将业务的属性分成三类：页面路径标记，页面埋码，服务端的标记。

页面路径标记、页面埋码针对的是网页端的场景
服务端针对的是app端或者第三方系统的回报场景，在实现上其实是两个并行的接口，页面端识别参数去标记数值，服务端如实记录需要的参数，互不影响。

如下表

又：针对各个分类的上报方式，实现的详细逻辑如下

页面路径标记类埋点：
主要为了识别线索从哪个流量来源来，比如上一跳在知乎，来到了百度搜索，然后进入了网站官网，这个时候，在逻辑上会归类到我们定义的“自然搜索-百度”类别下，当然平台不同还会做更细的处理，此处只讲解决方案的思路

页面路径标记逻辑如何实现？
前端页面有对应的js，可以识别路径上的utm参数，根据产品与研发约定的映射关系进行转码。
代码左侧的utm参数就是实际页面路径中包含的参数，右侧的数字，是产品从业务视角约定的，便于在crm内部字典做翻译

页面埋码参数类埋点：
除了url以外，业务上还需要其他更多的参数满足标记需求，比如页面名称，考试意向，浏览频道等等，可以通过页面埋码解决，可以直接定义“name= 1”这类键值对，然后前端也通过js识别的方式直传给后端，后端解析并存储

服务端标记类埋点
这个地方分两种情况讨论
第一种，主要用途是为了和某些商家的 合作，做了一个服务端的标记，标记流量来源参数数值，来确定用户的来源。这种数值是直传到线索属性上的，CRM端可以直接翻译。

第二种，是投放的时候，针对外部投放平台无法回传广告参数时，做的折中策略，会单独起一篇文章《CRM投放渠道管理与插码管理》

元数据字典翻译环节
一般的后台框架，如jeecg，jeesite，都会有字典管理模块，为的是把研发层面的码标记翻译展示成业务人员使用时看到的业务概念，提高可用性
此处比较简单，正常在系统中录入键值对即可，不过为了保险，需要单独维护一份字典映射表。

此处更理想的方案，其实是可以把所有的参数都整合到一块，由业务人员自行申请，生成一个统一的识别码，自行分发，这样能完全的把业务和数据层面给解耦开，但因参数更改频率较低，故投入产出比很低，所以就维持了现状。

关于埋点的实现方法，本文讲解的差不多了，如果大家有问题，可以评论区留言交流或者私信与我联系。
下一篇文章《CRM投放渠道管理与插码管理》，欢迎大家追更阅读，如有内容错误，欢迎斧正

我有一个建立社群的想法，我个人的一条价值观，利他就是利己，让我们互相帮助，互相成长。如果大家有兴趣，可以扫码我拉群