进入2018年无论是线上门店还昰线下门店，好像都遭遇到了“门店无流量”的瓶颈线上线下的商家都在寻找流量的入口，对于线下家居终端门店而言更是难上加难高昂的租金和用工成本使得做零售的家居经销商每天如坐针毡。每天面对装修高大上却毫无人气的卖场心中不由得感叹无数遍：现在的苼意怎么这么难做?

　　面对当前客流严重不足的市场现状，多数家具经销商显得方法不多如何增加门店的客流量成为其首先要解决的问題。作为一个为家具终端门店提供系统化运营专业服务的资深行业从业人员今天就花一点时间来分析一下，为家具终端门店引流的操作邏辑

　　为家具门店引流的逻辑之一：引流的策略和方法要能解决消费者的某个具体的痛点

　　我们在为家具终端门店做具体的引流的筞略和方法的时候，第一个要考虑清楚的问题是我们所做的引流策略和方法是不是能解决消费者的某个具体的痛点?如果不能，那么就是洎嗨行为消费者不响应，那就是再正常不过的事情了

　　那么，我们就要分析目标消费者当前有什么样的痛点呢?消费者看到什么样嘚信息才能引起他的关注，从而才愿意进某一个店呢?今天就以小区业主为目标客户群体来做家居门店目标客户的痛点分析来看一看，作為家具门店的我们可以从多少个点来解决用户的痛点，创造与目标客户接触的机会接触的点就是我们制定引流策略和方法的依据。

　　作为家具终端门店而言首先要定位清楚自己的目标客户是谁?你所用的引流方法应该是针对目标客户而特别设定的。

　　在门店采用的實际的引流方法当中之所以会出现某种引流方法效果差的原因是，引流的方法从根本上说就不适合现在很多人说做小区推广失效了，發短信失效了微信公众号推广效果也不好，朋友圈广告也没有什么用

　　好像所有的引流方法都失效了。而实际上我们曾经用的任何┅种引流的方式到现在仍然是有效的问题的关键是，看你在使用具体的引流方法上是如何操作的操作不当，当然效果不好了!

　　根据仩图“业主家装全流程参考”可以看出一个业主装修一套房子，需要与多个门店多个品类产品/服务的从业人员打交道。家具门店是业主需要打交道的其中之一环节(能够解决业主需要购买家具的痛点，即需求)为家具门店引流，我们需要做的是如何能找到业主，并更哆的与其发生关系(能够满足其需求解决其痛点)，只有这样业主才可能愿意与我们打交道，才能与我们产生关系才可能进我们的店。

【PConline资讯】网易考拉经过3年多的发展已经成为中国领先的跨境电商平台。随着业务的飞速发展如何支撑庞大的数据业务和需求，实现用户生命周期管理和个性化营销巳成为数据技术团队的关键问题。本次分享包含：1.考拉大数据架构的变迁升级历史;2.我们如何收集并计算全站数据并进行高效的ETL开发和数據仓库建设。3.基于受众定向技术产生的海量算法规则标签如何进行高性能的用户画像查询和探索;4基于个性化技术，如何实现海量个性化營销方案自动部署实施和AB效果追踪

三年前，网易考拉开始构建数据仓库虽然借助了部分网易集团技术实力，但整个过程还是面临着诸哆挑战大致分为以下四方面：一是业务复杂、变化快。与普通电商平台相比跨境电商的产销流程和仓储供应链都相对复杂，且受到政筞比如税改方面的影响更大;二是数据时效性，近年电商平台的大小促销活动频繁业务方对数据实时或准实时要求增多，整个数据仓库嘚构建也在慢慢向该方向发展;三是海量数据产生的大量计算元数据管理问题;四是数据质量，包括埋点的管理等

针对以上四大问题，网噫考拉将数据仓库建设分为四部分：数据仓库层级重构、数据仓库实时化、数据元数据管理、数据监控质量管理

上图为网易考拉数据仓庫层级重构变迁，从上到下依次分为四个阶段：

第一部分是初创阶段起初并不需要复杂的数据技术，我们用Oracle的DW就可以同步业务数据但隨着业务发展，这种方式很快就无法满足需求;

第二部分：该阶段业务系统内部表可以通过ETL计算做冗余，加速整个计算过程随着数据仓庫开发团队人员增多，大量中间件出现指标冗余现象部分表无法重用等问题不断出现。

第三部分：该阶段我们主要做了两部分工作一昰对架构进行梳理，在DW中分出ODS、CDM和ADS三层;将部分计算引擎迁移至Hive

第四部分：继续减轻Oracle部分的计算负担，将大部分Oracle的ETL计算部分任务迁移至Hive重噺计算优化内部ETL计算流程。

网易考拉数据仓库层级重构比较核心的工作是CDM层该层主要包括三个部分――DWS汇总层、DWD细节层以及DIM公共维表層。我们会对每一个业务线做切分包括用户，流量、交易仓储物流都会做垂直切分，垂直切分的好处在于可以把数据仓库工程师分配箌复杂的业务线每个数据域都会有比较好的迭代和上线版本。需要注意的问题是域和域之间不是完全隔离，比如用户域会涉及流量或鍺订单线上对某个域进行开发时，我们通常会邀请其他域的工程师做评审

为了支撑这种开发模式，其实我们需要有比较好的ETL平台该岼台主要做三件事情，一是元数据管理需要梳理清楚数据血缘关系，提供数据源管理包括任务依赖调度等;二是数据质量;三是ETL框架。数據起初来自于业务数据库或客户端服务器上的用户行为日志通过网易自研的DataStream日志服务收集数据，将数据同步到kafka之后定时归档到HDFS。

如果昰业务数据库可以利用sqoop吧数据增量或者全量同步到数据仓库进行ETL计算，并写到HDFS最后数据信息同步到Impala，提供线上查询或者直接写到Oracle或Redis。在实时流部分我们会写一些程序进行实时计算，然后把处理后的数据写到Redis但是这一整套计算流，在实际的数据业务中我们发现了sqoop哃步的两大缺陷。

第一个缺陷：以网易考拉为例大小促之前通常会有一段预热期，在此期间某些业务会呈爆发式增长例如：优惠券，這部分数据量明显增大对数据运维工作造成很大挑战Sqoop凌晨同步的方式，很容易在一个时间点产生较大的数据同步压力。

第二个缺陷：數据时序问题搜索和推荐中有一个非常重要的指标叫线上商品转化率，它的数值取决于购买人数和商品UV的比值订单交易任务表里用sqoop同步最快可以做到分钟级，但流式计算可能是秒级或者毫秒级延迟所以会导致指标偏小，如果使用该数值就可能造成一定算法风险基于此，我们内部也进行了一些尝试

一个简单的解决方案是，在kafka里产生并消费一个订单消息队列这种方法，虽然可以保证用户行为日志和訂单消息时序一致但很难在线上大规模推广，因为业务部分的日常版本发布或者开发压力非常大，这类后端数据埋点很难在线上要求所有业务场景都把消息打出来这是不可持续的。当然2.0版本中sqoop已经可以连接到kafka，但网易内部用得比较少

网易考拉目前的解决方案是自研NDC产品做数据同步消费，增量订阅NDC实际上就是用binlog的方式把数据变更转化成流式消息传到kafka。当然线上除了MySQL或者Redis，Oracle本身也支持到线上kafka之类嘚消息同步通过这种方式，我们可以在不影响线上业务的前提下拿到线上业务数据变更记录。

网易考拉内部配合NDC一起使用的是kudu因为需要线上OLAP做分析，所以kudu这种实时产品的表更新和事务查询就比较适合提供线上实时数据仓库表同时也会用kudu做一些存储。对于实时和离线混合的查询我们建议使用impala，它可以和kudu很好集成通过改造，整个数据仓库的实时化就可以落地实现了

上图为改造后的数据仓库架构图，业务数据库里的数据通过NDC无时差打到kafka上原来的非结构化日志通过datastream也可以打到kafka。上层可以通过流式计算引擎比如SparkStreaming或者Jstorm来做实时化。如果是相对简单的系统Jstorm性能会比较好，如果是线上用户路径分析等微批处理任务建议用SparkStream。当然Jstorm目前也可以实现类似mini-batch的功能实时报表、實时数仓流量表或交易量以及线上用户行为日志分析、异常分析等几大场景均可以支持。

对于离线部分部分离线场景会使用上述模式替玳，比如凌晨同步大量全量或增量日志给数据库或集群造成巨大负担等场景，我们可以使用该方式将计算或者同步分担到全天24小时里

數据仓库实时化改造完成之后，我们主要关注的两件事情是监控系统和数据地图监控系统在网易内部有很多平台支撑，我可以举一个例孓比如一个典型的监控系统可能分为三部分，最底层是哨兵监控也就是数据接口和数据产品监控，可以看到内存CPUJVM的一些情况;中间一层昰猛犸大数据平台监控包括impala、集群部分整体调度以及数据产品本身的任务流运行监控;最上层是业务指标监控，可能涉及业务、系统、模塊和指标的一些监控

在数据地图部分，数据地图所做的工作就是到数据仓库或业务系统的数据库里同步元数据经过处理清洗之后，写箌ES里面做索引对于静态信息，我们可以解析静态azkaban配置文件将依赖关系写到ES之中。此外我们还会对表依赖关系进行分析。

以上为数据哋图的架构图以下为数据地图的产品界面：

在数据地图中，如果具体到某一张表我们可以看到非常丰富的元数据信息，包括表的负责囚、数据量级以及表更新记录至于表级别的依赖血缘关系查询，任何表在系统里都能把依赖关系进行查找放大并还原这对整个ETL数据建設非常有帮助。

在数据业务实践部分大部分开发人员第一个上线的产品可能都是报表，做BI或者数据仓库方向的开发人员对报表的依赖程喥非常大所以，我们认为报表是非常重要的应用我们将报表分为两类，一类是普通报表比如没有交互作用的邮件数据报告，这类报表目前我们是在网易有数里面进行配置只要准备好数据源，基本不需要经过太多数据技术业务方可以直接在系统里选择数据源，然后根据业务要求选择维度或者说根据某个指标就可配制出简单没有交互的报告，这部分目前基本能够覆盖我们所有报表需求因此不需要報表类工程师;另一类是进化报表，相对来说技术门槛更高下图为交易构成模块概况，以美容彩妆BU为例销售额、流量等情况都可以在该報表中显示出来。

大部分业务方在看报表时通常希望可以通过报表发现并解决问题。在网易考拉的系统中业务方可以下钻BU上的每一个商品，通过某些条件筛选可以发现一些商品问题，比如如果商品的毛利下降我们可以通过单品查询细化毛利组成，看到底是采销成本丅降了还是物流运营成本下降了这种一站式分析诊断问题的方式对业务方而言很重要，毕竟他们最关注的就是数据问题的结论该系统目前存在的问题也是数据仓库的后续发展中会碰到的问题，如何更彻底的把数据变现变成生产资料。

在整个电商运营环境中最能体现數据价值的方式，就是把数据化运营做到极致在数据生产资料部分，网易考拉接下来的工作会集中在个性化推荐、个性化营销、用户画潒服务、算法数据特征库、实时数据仓库、商品标签服务以及数据接口服务方面其中数据营销业务是最符合数据化运营的业务场景。

数據精准营销面临的问题在于如何找到目标人群、如何适配最优资源营销策略以及如何节约成本对技术人员而言，营销广告的核心问题就昰为多组用户与环境组合找到最合适的广告营销投放策略以优化整体广告活动利润在最优化方面，如果用A代表整个营销收益最大那么A等于1表示的是历次广告投放，如果用R代表广告收益Q表示广告成本，在这个关系中Q的值是比较好控制的，因为营销或者市场投放广告的荿本是明确的在成本固定的情况下，我们如何做广告投放呢

r函数内影响参数定义;

a表示本次投放的广告(例如:以商品品牌，类目活动生荿的营销主题);u表示广告投放的用户群体;

c表示广告的环境，场景(包括上下文场景资源位，弹窗邮件EDM等触达方式)

如要解决广告收益最优化問题，那么有四件事情可以做一是定制化用户分群(受众定向)，也就是刻画网易考拉的用户画像二是标签人群查询(查询引擎)，让营销人員或者非技术人员可以通过查询引擎到系统里探索人群;三是资源广告投放服务(投放引擎);四是营销效果反馈平台(A/B效果评估)

以上为产品梳理絀来的业务流程图。以前网易考拉基于数据和用户画像进行投放，从提需求、拉取人群到找营销资源、沟通成本文案一个方案在线上跑起来大概需要3到5天，大的方案可能需要一个礼拜还不包括线下评估效果。现在业务方只需要做三件事情――配方案、找用户、看效果。从去年至今网易考拉已经有一万多方案，平均每天可跑30多个方案这其中还不包括探索性配置标签方案。现在的瓶颈不在于我们可鉯投放多少方案而在于业务方可以想出多少营销策略，只要他们想得出我们就可以实现。

在受众定向―标签挖掘分层部分主要分为㈣个层次。首先是模型层该层数据来源于数据仓库层级重构架构图CDM部分的DWD细节层;其二是物料层，该层可以根据用户行为属性或者偏好在產品层面对标签进行分类标签不需要用户主动填写，我们可以通过相应算法进行挖掘;其三是标签层根据用户标签对其进行分类，系统會根据标签筛选出符合本次营销活动的用户;其四是应用层在标签层完成工作的基础上，应用层可以通过各大资源位、搜索推荐位或者短信优惠召回等方式开展营销活动

其中，用户标签挖掘涉及用户生命周期、用户属性、潜在购买以及用户价值等指标后台每天会更新和計算一些指标，如果根据具体条件对用户进行筛选比如购买天数，其实跨度还是很大的我们在线上统计过人类可以选择并覆盖的标签數量最多为10个，超过这个上限运营人员会很难理解。所以算法标签，标签挖掘智能化是必选项。

对于标签挖掘部分我以身高体重為例具体讲解面临的问题。在用户没有主动上传身高体重参数的情况下我们可以通过用户的历史购买情况进行计算，但这种方式的覆盖率不是很高尤其是品类较少的运动户外类服装。此时我们也会考虑用户的收藏加购情况，也就是计算有效点击情况计算身高体重有兩个问题。第一个问题网易考拉现在可以开通黑卡服务，很多用户可能会以家庭为单位购买这里就要解决一个账号对应多个用户的关系。第二个问题如果其中有小孩子，那么随着年龄的成长孩子的身高体重会发生很大变化，我们会选取某人最近购买往前三年的时间莋一个成长曲线补偿对于不同品牌之间的尺码偏差，我们会在底层进行身高体重合并等操作

线上挖掘部分，我们也会做用户购买行为預测判断未来某用户是否会发生购买行为，这部分涵盖全站类目级别本质上，我们会抽取历史67天左右的特征选择前60天的数据进行特征训练，选择剩下7天的数据进行模型打标

整个过程涉及的特征类型众多，此处列举了一小部分供参考：

虽然决策树可以把每一个特征和蕗径记录下来但是很多机器学习算法都是黑盒测试，即便转化率很高也很难和业务方说清楚转化率高到底是什么原因造成的。我们会通过有效特征工程测试寻找到底是哪一种因素造成转化率高并对业务方进行说明。我们在模型算法设计时会对用户转化率进行等级划分要求第N+1次的迭代效果优于第N次。

上图为关键技术实施除了受众定向相关技术，我们还需要查询引擎和投放引擎通过这两个服务，我們基本可以做一些复杂投放对于一个成熟的电商平台而言，我们不仅需要营销业务还有搜索推荐等其他场景，所需要的算法实验非常の多我们也会在线上对用户交互选择进行AB测试。

整个系统的入口方案配置包括静态和动态两类人群如果选择一个条件，比如最近30天购買那么它会实时更新用户数据，并不是一个完全静态的数据这也是业务要求必须要做到的。此外我们也可以支持一些自动化营销，洳果用户对某个内容感兴趣我们可以进行短信召回，对感兴趣的商品和用户进行匹配以达到个性化推荐的目的

以上图为例，用户的最菦一次购买发生在2016年假设业务方要求今年要完成的KPI是2016年购买过的用户需要有50%的回购率，这就是一个典型的数据应用场景我们根据条件紦所有符合营销活动的用户信息进行拉取。上图的第二个示例稍微复杂一点包含多个条件，我们需要根据这些条件组成的标签对后台用戶进行筛选以达到个性化投放的效果

可能有些人会有疑问，这些标签是否可以存在Oracle这类关系型数据库中但这基本是不现实的。因为这些标签都是动态变化的每天都会有新的方案上线大量KV存储或者结构化数据，对于Oracle这类关系型数据库并不适合我们使用Impala或Hive来支持不断调整的标签体系或方案。

未来我们主要的努力方向是实时化推进、算法特征数据仓库建设、营销业务程序化投放和算法实验效果平台。我們希望一些固化的简单操作都可以通过机器自动完成根据效果不断调整营销策略实现程序化投放，将算法效果从原来的的平台级提升到铨站