在当今数据驱动的商业环境下，构建一个有效的数据分析系统是企业发展的关键，但对于业务线复杂的闲鱼来说却是极具挑战的。既要整合纳米镜功能和算法，又要满足各业务线的接入需求。这其中存在许多需要权衡的要点，也有不少创新的解决方式。
闲鱼业务线的复杂现状
闲鱼的业务线繁多且复杂这是不争的事实。不同的业务线有着不同的数据需求。例如，可能一个业务线关注的是某类二手商品的销售数据，另一个可能侧重用户的交互行为。在这样复杂的业务结构下，要构建一个让每条业务线都能便捷接入的数据分析系统难度很大。从时间维度上看，随着业务的不断发展，新的业务线也会不断产生，如果没有一个良好的数据分析系统构建方案，后期的维护和新业务接入成本会越来越高。而且面对众多的数据使用者，数据的准确性和有效性也难以保证。
在地域方面，闲鱼在全国甚至全球范围内拥有用户，不同地区的用户行为也存在差异，增加了系统构建的复杂性。对于构建数据分析系统，要的不仅仅是对当下数据的分析，更是要考虑长远的可扩展性。
纳米镜的功能与局限
纳米镜有其特定的分析算法，有着固定的输入输出，要求特定的标准数据集。这一标准数据集虽然规范，但在实际的闲鱼业务场景中却有些格格不入。各个业务线关注的人群切面和数据指标都有所不同。比如说有的业务线关心的是用户对高端商品的浏览数据，有的则关心低价商品的交易数据。对于纳米镜的标准数据集使用上，存在着要进行改造的必然。仅仅让业务将数据按照标准数据集规范插入中间表，实施起来困难重重。一方面业务产出数据集开发成本大，另一方面，使用方如果操作不规范会造成数据污染。
这在实际的运营中就可能导致基于错误数据的决策。从曾经的案例看，就曾因为数据不规范导致对某类商品市场需求预估错误，使商品库存积压。这种数据错误带来的经济损失是不可忽视的。
业务开发流程中的数据源问题
在日常的业务开发流程中，生成ODPS数据源的工作流程有着多种步骤。而与纳米镜结合时就产生了诸多问题。如传统的数据开发流程牵扯到埋点开发、跨专业领域编写SQL，操作繁杂且耗时。但如果采用数据自动生成的方式，就能省略这些步骤，活动数据能够在页面上线时就自动存储到纳米镜标准数据源。然而这种方式在多业务线的闲鱼中却很难达成一个适用于所有业务（包括闲鱼、手淘、天猫等）的用户行为采集方案，因为各个业务工程实现方案差异太大。但幸运的是闲鱼的工程基建已基本成熟稳定，具有业务语义的用户行为的API输入输出已固化，这为闲鱼独家的用户行为自动采集方案提供了可能性。
在成本上，这无疑可以节省大量的人力和时间，原本开发需要花费人力日，采用合适的方式可以直接减少开发成本。从过往的经验来看，每一次的节省成本都意味着能够有更多的资源投入到业务的拓展和改进上。
用户行为采集的配置策略
闲鱼有一套成熟的用户行为采集通用配置，这能满足业务方数据分析时的多种数据指标诉求。在人员上，通过这样的通用配置，不同的业务人员能够更方便地获取所需数据。例如市场部门能够通过这些数据来做市场推广策略调整。它还支持定向扩展，可以针对具体的页面spmId定制个性化的用户行为指标。这些配置参数有着明确的含义，能够给予使用者明确的操作指引。假设某个新的业务线加入闲鱼，借助通用配置和定向扩展，就能够快速地开展数据采集工作。
这种配置不仅仅是理论上的合理，在实际的试点项目中，也证明了其提升数据采集准确性和效率的实用价值。无论是对于新开展的业务还是已有的业务线更新需求，都提供了很大的便利性。
navigator['push'] = newProxy(navigator['push'], {
get(target, propKey) {
return target[propKey];
},
set(target, propKey, value) {
target[propKey] = value;
return target[propKey];
},
apply(target, thisArg, args) {
// 先执行原逻辑
const result = target.apply(this, args);
// 是否指定忽略纳米镜分析
const ignoreNanoAnaly = args && args[0] && args[0].api && args[0].ignoreNanoAnaly;
if(ignoreNanoAnaly) {
return result;
}
if(result instanceofPromise&& result.then) {
result.then(d => {
// 这里写入监听逻辑
// ...
returnPromise.resolve(d);
}).catch(e => {
// 这里写入监听逻辑
// ...
returnPromise.reject(e);
});
}
return result;
}
})
行为聚合与上报的优化
在行为聚合与上报方面，闲鱼有着独特的策略。为了减轻带宽和服务器计算压力，不会对每次采集到的用户行为立即上报，而是对整个页面实例生命周期的行为进行聚合，并选择在页面被销毁或者应用从前台切到后台15秒后做统一上报。这种方式就像一个数据分拣站，先把杂乱无章的数据整理好再发送。从开发成本来看，原本需要花费大量人力日的开发量，现在只要活动上线就能使用纳米镜查看活动智能分析结论。这极大地提高了纳米镜的使用效率。
从业务方的反馈来看，这种高效的报告方式让他们能够更迅速地对业务活动做出反应。如果没有这样的优化策略，可能因为报告的延迟导致错过最佳的业务调整时机。
{
"spms": [{
"spm": "common", // 用户行为通用配置 会对所有页面产生的用户行为进行匹配
"tasks": [{
"indexType": 0, // 0代表指标 1代表bucket_id 2代表infos 3代表扩展信息 默认0这里主要是需要与纳米镜的标准数据源建立映射关系
"index": "index__ipv", // 指标名称 IPV
"behavior": [
{
"type": 0, // 用户行为类型 0代表navigator 1代表mtop 2代表location.href
"condition": "fleamarket://item", // 正则匹配是否目标行为 type=navigator匹配下跳url；type=mtop匹配接口返回值 不校验填true
"valueType": "1"// 指标数值类型 0代表boolean 1代表count 字符串属性链代表对应取对应值
}
]
}]
}, {
"spm": "spma.spmb",
"match_uv": true, // 是否采集页面uv 默认指标名称是 index__visit
"tasks": [{
"indexType": 0,
"index": "index__gold_copper", // 金宝箱是否打开
"behavior": [{
"type": 1, // mtop接口请求的行为类型
"api": "mtop.api.lottery.draw", // 抽奖接口api名称
"condition": "d.data.status===5", // mtop返回值符合该正则匹配 则认为符合采集记录条件 status==5代表用户成功打开了金宝箱
"valueType": "0"// 是否领取成功 0/1
}]
}]
}]
}
纳米镜业务接入模式的成效
目前纳米镜设计的业务接入模式效果显著。对于业务能够实现0成本接入，若有定制化的数据指标诉求，也只需要低成本地动态配置。以某个业务线为例子，以前接入数据分析系统需要投入大量的人力、物力进行系统对接等操作，现在几乎可以一键接入。在业务规模不断扩大的当下，这一模式有助于新业务线的快速整合，使各个业务线都能够便捷地享受到数据分析带来的优势，为业务决策提供科学依据。
关于构建可扩展数据分析系统这个问题，大家的企业是否有类似的情况？希望大家点赞、分享并在评论区分享经验。
{
"page": "spma.spmb",
"indexes": "index__visit=1,index__ipv=10,index__gold_copper=1"
}
