1. 从业务问题到数仓指标为什么“敏感度”值得单独建模电商这个行当做了几年之后你会发现一个非常扎心的规律同样的商品有的靠打折就能卖爆有的把价格砍到骨折也没人看有的商品评论区随便一条差评就断崖式下跌有的满屏骂声销量却纹丝不动。这背后其实就是两件事——促销敏感度和评论敏感度。先说促销敏感度。它描述的是销量对价格调整或促销力度的反应程度。敏感度高的商品你给一张满减券、做个秒杀订单量立刻往上蹿敏感度低的商品促销活动做下去利润没了库存没动销量还是一潭死水。评论敏感度同理它描述的是用户评价尤其是负面评价对转化率的影响程度。有的品类用户下单前必刷评论差评直接劝退有的品类用户看都不看评论区闭眼买。这两个指标听起来像是业务分析团队该做的事但真正落地的时候你会发现没有数仓层面的统一建模这玩意儿根本没法规模化计算。业务团队今天用Excel拉数明天用BI工具临时写逻辑口径五花八门分析出来的结论互相打架。你问运营A“这个商品促销敏感度高不高”他说高你问运营B同一个问题他说不高。为什么因为两个人看的数据窗口不一样一个看的是大促期间一个看的是日常活动。所以我当时接到这个需求的时候第一时间就跟业务对齐了一个认知敏感度不是一个临时取数需求它是需要沉淀到数仓里的一个标准化标签体系。只有把它做成统一的模型、统一的口径、统一的计算逻辑业务才能拿到一份“所有人说同一句话”的数据。这个思路说起来简单做起来其实有不少坑。比如促销敏感度的计算到底是看“促销期销量 vs 非促销期销量”的倍数关系还是看“价格弹性系数”评论敏感度到底是用“好评率提升对转化率的影响”来衡量还是用“差评出现后销量下跌的幅度”来衡量如果不在建模前把这些口径定死后面做出来的表就是一堆废数据。2. 建模前的关键决策口径、维度和计算逻辑2.1 先定口径什么样的数据才配叫“敏感度”在动手建表之前我最先做的一件事是跟业务方一起把口径掰扯清楚。这是整个项目里最重要的一步没有之一。促销敏感度的口径我们最终定为商品在促销期与非促销期的日均销量比值再经过价格变动幅度归一化处理。说白了就是“促销力度每变化1%销量变化百分之几”。这个口径比单纯的“促销期卖了多少”要科学得多。举个例子一件商品促销期日均卖100件非促销期日均卖50件看起来是2倍敏感度。但如果这个促销是把价格从100砍到50那这2倍的销量变化其实是用5折换来的和只打9折就翻倍的商品完全不是一个敏感度级别。评论敏感度的口径我们定为商品好评率变化一个单位1个百分点时转化率的变化幅度。这里有个隐含逻辑——评论对销量的影响不是直接的而是先影响转化率再传导到销量。所以建模的时候不能只看“评论好卖得好”这种相关性要做的是剥离其他因素之后只看评论这个变量对转化的边际贡献。这两个口径的确定前后开了三次会每次都跟业务吵得不可开交。但吵归吵这个步骤省不了。因为一旦口径定了后面所有的计算逻辑、数据粒度和应用场景都是水到渠成的事。2.2 选择维度商品维度的敏感度才有业务价值维度怎么选直接决定这张表的复用性。我们最终落到了SKU粒度同时冗余了类目、品牌、价格带这几个常用分析维度。为什么选SKU而不是类目因为同一个类目下的不同SKU敏感度可能差出好几倍。举个例子同一个美妆品牌下一支口红和一个洁面乳促销敏感度和评论敏感度可能完全不同。口红是冲动消费品价格激励非常有效洁面乳是刚需品促销效果相对有限。但只做SKU粒度也不行因为业务看数据的时候经常需要从类目、品牌、价格带这些维度去切片。如果每张表只做单一粒度下游使用的时候join来join去性能烂不说口径还容易漂移。所以我的做法是在DWS层做主模型的时候保留SKU粒度同时在模型里冗余类目、品牌、价格带等维度字段这样下游要什么粒度都能直接聚合不需要回到底层明细表重新计算。冗余维度字段在数仓建模里是个很常见的操作有人觉得违反范式但在实际业务里这种适度冗余带来的查询性能提升和口径一致性远远大于那点存储成本。2.3 梳理基础数据三类上游数据缺一不可口径定了维度定了接下来就要盘点数据。这个项目的上游数据主要分三块第一块是订单事实数据。这是最核心的订单ID、SKU、销售数量、实际成交金额、下单时间、订单类型普通订单还是促销订单这些字段都得有。这里有个容易被忽略的细节订单数据里最好要能区分出“促销订单”和“非促销订单”否则敏感度计算根本无从下手。第二块是促销活动数据。促销活动ID、活动名称、活动类型满减、直降、秒杀、活动开始时间、活动结束时间、促销力度折扣率/优惠金额。这块数据看着简单实际很脏。同一个SKU在同一时间可能参加多个活动有的活动的“促销价”和“到手价”之间还有优惠券叠加处理起来非常头疼。第三块是商品评价数据。评价ID、SKU、评分1-5星、评价内容、评价时间、是否有晒图、是否有追评。严格来说评论敏感度的建模还需要曝光数据和转化数据不然你光知道评论好坏不知道它对转化率的影响算不出真正的“敏感度”。但曝光数据在不少公司是缺失的尤其是早期阶段所以我们的处理方式是先用好评率和销量做相关性分析等曝光数据补齐了再往真正的转化率模型上靠。2.4 计算逻辑细化从“拍脑袋”到标准化这块是整个模型最需要抠细节的地方我单独拉出来写。先说促销敏感度的标准计算公式促销敏感度 (促销期日均销量 - 非促销期日均销量) / 非促销期日均销量 / 促销折扣率翻译成人话就是销量变化百分比除以价格变化百分比。这个指标也叫“促销弹性”它衡量的是每1%的价格优惠能换来百分之多少的销量增长。如果促销敏感度为2说明每降价1%销量增长2%这个商品做促销非常划算如果只有0.3说明降价对销量的拉动很弱做促销就是在赔本赚吆喝。这里有几个细节必须处理到位。第一非促销期的选取要排除节假日、大促前后等异常周期否则基线本身就歪了。我当时的做法是取促销开始前30天的日均销量同时剔除预售期和S级大促期间的数据。第二促销折扣率的计算要考虑真实支付金额不能只看商品吊牌价。用户用券、满减叠加之后的实际支付金额才是真实的“促销价”。否则计算出来的敏感度会虚高。然后是评论敏感度的计算。这块没有统一的标准公式因为不同行业、不同平台的数据基础不一样。我们最终用的方案是分段回归的思路对每个SKU按周聚合好评率或差评率和转化率或销量然后做线性拟合取回归系数作为敏感度。如果在曝光数据缺失的情况下就用销量替代转化率作为因变量但要在指标说明里备注清楚这是近似口径。这个方案我用Python验证过拟合效果整体还是可以的。但对于好评率本身就很高比如98%以上的商品好评率的方差太小回归系数的置信区间会很宽敏感度算出来不稳定。这个问题的处理办法是提高聚合粒度从按周聚合改成按自然月聚合增加样本量代价是时效性变差。后面我会在“常见问题”里专门展开讲这个坑。3. 数据模型设计与核心表结构3.1 分层设计明细层、汇总层、标签层各司其职拿下口径之后就到了数仓建模的核心环节——分层设计。我遵循的还是经典的数仓分层思路ODS操作数据存储、DWD明细数据层、DWS汇总数据层、ADS应用数据层。这个项目里ODS其实就是直接把上游的订单表、活动表、评价表原样同步过来不做任何加工只是加上分区、去重、类型转换这类基础清洗动作。DWD层要做的事情稍微多一点主要是把订单明细里的促销标识识别出来把评价数据里的评分归一化把活动数据里的时间区间拆分成可Join的结构。DWS层就是前面说的SKU粒度汇总表把促销期日均销量、非促销期日均销量、好评率、评价数、转化率等指标计算好以主键SKU 统计周期聚合成一张大宽表。ADS层则是在DWS的基础上直接产出敏感度分档标签包括促销敏感度等级、评论敏感度等级以及给下游推荐系统用的敏感度评分。很多刚入行的同学会问DWS和ADS不是重叠了吗为什么不能只做一张表我的回答是DWS是给“数据查询”用的ADS是给“业务决策”用的。DWS里是纯粹的指标数值比如促销敏感度是1.86还是0.42ADS里是分档标签比如“高敏感”“中敏感”“低敏感”。业务方不需要关心1.86还是0.42意味着什么他们只需要知道该对这个商品采用什么样的运营策略。这个“指标到标签”的转换过程沉淀到ADS层之后可以统一复用到多个下游比让每个业务方自己解读指标要靠谱得多。3.2 核心DWS表字段设计实战DWS层的表结构是整个项目的中枢我直接分享一下当时的字段设计思路。主键是统计日期和SKU_ID然后是一大票度量字段大致如下基础指标sku_id、category_id、brand_id、price_band、stat_date、sale_qty_30d_avg、sale_qty_promo_avg。其中sale_qty_promo_avg是最近N次促销活动的日均销量N要预先定义好我们当时取的是最近5次活动太少的商品就取实际次数但要在备注里写明样本量。促销指标promo_discount_rate促销折扣率1表示无折扣、promo_sensitivity最终算出来的促销敏感度、promo_sensitivity_level高/中/低分档。分档逻辑先用四分位数法后续根据业务反馈再做人工调整。评论指标review_good_rate好评率、review_cnt_30d近30天评价数、comment_sensitivity评论敏感度、comment_sensitivity_level。评论敏感度还有几个衍生指标比如差评转化影响系数、评论情感得分均值。这张表跑起来后数据量其实不大因为粒度是SKU天一个中大型电商平台也就几十万SKU存一年的数据可能也就几亿行。比起订单明细动不动几百亿行的体量这张表的查询性能完全不用担心。3.3 敏感度分档规则用数据分布代替拍脑袋指标算完之后如果直接丢给业务他们看到一堆小数还是会懵。所以我的方案是再做一层分档让业务可以直接用“标签”做决策。分档规则我建议用百分位数来切而不是自己拍脑袋定阈值。比如促销敏感度按商品的促销敏感度值从高到低排序前25%定义为高敏感25%-60%定义为中敏感后40%定义为低敏感。为什么不按三等分因为实际数据分布通常不是均匀的大多数商品其实是低敏感或中等敏感真正高敏感的商品是少数。如果三等分高敏感区间里会混入一些“没那么敏感”的商品分档的指导意义就弱了。评论敏感度的分档逻辑类似但因为它还受好评率基数的影响我额外做了个限制只有好评率低于97%的商品才参与分档好评率在97%以上的商品直接归为“低评论敏感”或“不敏感”。为什么因为一个商品好评率已经99%了再往上提升的空间非常有限就算评论敏感度算出来很高实际运营可操作的空间也很小。用大白话说你没法把已经接近满分的试卷再提高多少分。这个限制规则是我在项目上线后根据业务反馈加的因为最开始的时候有个好评率99.5%的商品被算成了“高评论敏感”运营同学拿着这个结果去开会差点被挑战到怀疑人生。后来加了这道防线整个标签体系的合理性就高了很多。4. 实操过程与核心环节实现4.1 第一步订单数据的清洗与促销标识识别实操的第一步是对订单数据进行清洗和促销标识识别。这步看着基础其实坑最多。订单数据里的促销标识理论上应该由上游的订单系统直接提供。但实际操作中订单系统里经常只有订单类型字段没有标注“这个订单是否命中促销”、以及“命中哪个促销活动”。我的做法是通过订单的支付金额与商品正常售价对比来反推如果一个订单的实付金额明显低于商品日常售价就把它标记为促销订单再通过订单上的活动ID或者优惠信息字段去关联具体的促销活动。这个方案的准确率大概在95%左右够用了。清洗过程中还要处理退款订单。如果一个订单发货后30天内发生了退款这个销量要不要计入敏感度计算我的建议是不计。因为退款代表用户最终没有保留商品它对“促销是否有效”这个问题的回答会产生干扰。比如一件商品促销期卖出1万单但退了8000单这种情况下算出来的促销敏感度会严重失真。所以我当时在DWD层就直接过滤掉了退款状态为“已退款”的订单。这块的SQL实现逻辑其实很直接就是在DWD层做订单明细的加工-- DWD层促销订单识别与清洗示例 CREATE TABLE dwd_trade_promo_order_di ( order_id STRING COMMENT 订单ID, sku_id STRING COMMENT SKU ID, category_id STRING COMMENT 类目ID, brand_id STRING COMMENT 品牌ID, sale_quantity INT COMMENT 销售数量, pay_amount DECIMAL(10,2) COMMENT 实付金额, origin_price DECIMAL(10,2) COMMENT 日常售价, order_date STRING COMMENT 下单日期, is_promo_order TINYINT COMMENT 是否促销订单 1是0否, promo_id STRING COMMENT 关联促销活动ID, discount_rate DECIMAL(10,4) COMMENT 实际折扣率, etl_time TIMESTAMP COMMENT ETL处理时间 ) PARTITIONED BY (dt STRING COMMENT 数据分区日期); INSERT OVERWRITE TABLE dwd_trade_promo_order_di PARTITION(dt ${bizdate}) SELECT order_id, sku_id, category_id, brand_id, sale_quantity, pay_amount, origin_price, order_date, CASE WHEN pay_amount origin_price * 0.95 THEN 1 ELSE 0 END AS is_promo_order, COALESCE(promo_id, ) AS promo_id, CASE WHEN origin_price 0 THEN ROUND(pay_amount / origin_price, 4) ELSE NULL END AS discount_rate, CURRENT_TIMESTAMP() AS etl_time FROM ods_trade_order_di WHERE dt ${bizdate} AND order_status cancelled AND refund_status NOT IN (refunded, partially_refunded);这段SQL的逻辑是筛选出未取消、未退款的订单通过实付金额与日常售价的比值判断是否促销订单并顺手算出了折扣率。实际生产环境里处理的数据量可能是每天上亿条所以要在ODS层就做好分区裁剪不然跑一次任务耗时感人。4.2 第二步促销期与非促销期销量基线计算订单数据处理完接下来要计算每个SKU的促销期日均销量和非促销期日均销量。这块的核心逻辑是针对每个SKU的每次促销活动划定促销期窗口然后往前推30天作为非促销期窗口。需要注意的点是非促销期窗口并不是简单“往前推30天”就完事。如果往前推的30天里正好赶上另一个大促那这个“非促销期”就不“非”了。我的处理办法是往前推45天然后过滤掉其中包含促销活动的时间段再取最多30天的非促销日作为基线窗口。这里有个细节有的SKU活动频率特别高一年到头都在打折几乎找不到连续的非促销期。对于这类商品单一商品的基线本身就不稳。我当时给出的处理方案是下沉一级用同品牌、同价格带、同品类的其他商品均值作为参考基线但会在表里用标志字段注明“基线来源品类替代”。这个方案虽然不够严谨但至少比没有基线强。-- DWS层SKU粒度促销敏感度核心指标汇总 INSERT OVERWRITE TABLE dws_sku_sensitivity_di PARTITION(dt ${bizdate}) SELECT t.sku_id, t.category_id, t.brand_id, AVG(CASE WHEN t.is_promo_period 1 THEN t.daily_sale_qty END) AS promo_avg_daily_qty, AVG(CASE WHEN t.is_promo_period 0 THEN t.daily_sale_qty END) AS non_promo_avg_daily_qty, AVG(CASE WHEN t.is_promo_period 1 THEN t.discount_rate END) AS avg_discount_rate, -- 促销弹性系数 (促销期日均 - 非促销期日均) / 非促销期日均 / 折扣率 ROUND( (AVG(CASE WHEN t.is_promo_period 1 THEN t.daily_sale_qty END) - AVG(CASE WHEN t.is_promo_period 0 THEN t.daily_sale_qty END)) / NULLIF(AVG(CASE WHEN t.is_promo_period 0 THEN t.daily_sale_qty END), 0) / NULLIF(AVG(CASE WHEN t.is_promo_period 1 THEN t.discount_rate END), 0), 4 ) AS promo_sensitivity FROM ( SELECT sku_id, category_id, brand_id, d.dt AS sale_date, SUM(sale_quantity) AS daily_sale_qty, MAX(CASE WHEN p.promo_id IS NOT NULL THEN 1 ELSE 0 END) AS is_promo_period, MAX(CASE WHEN p.promo_id IS NOT NULL THEN p.discount_rate ELSE NULL END) AS discount_rate FROM dwd_trade_promo_order_di o LEFT JOIN dim_promo_info p ON o.promo_id p.promo_id AND o.order_date BETWEEN p.start_date AND p.end_date WHERE o.dt DATE_SUB(${bizdate}, 45) GROUP BY sku_id, category_id, brand_id, d.dt ) t WHERE t.sale_date DATE_SUB(${bizdate}, 30) OR t.is_promo_period 1 GROUP BY t.sku_id, t.category_id, t.brand_id;4.3 第三步评论数据的加工与回归建模评论敏感度的计算我用的是Python离线跑回归因为要在Spark SQL里做线性回归比较绕虽然Hive里也有回归函数但我更熟悉Python的操作路径。大致流程是从DWS层拉取每个SKU最近90天的周粒度好评率和周粒度销量数据然后剔除促销影响把促销周的销量按促销敏感度平滑回非促销水平再用线性回归拟合好评率对销量的边际影响。这里有个关键细节做评论敏感度的时候一定要剔除促销因素的干扰。你想啊一个商品如果同时遇到差评风波和大促评论敏感度会被大促的巨大销量完全淹没。我当时的做法是先用上一节算好的促销敏感度把促销周的销量折算成“等效非促销销量”再用这个修正后的量去跟好评率做回归。这个“剥离混淆变量”的思路在统计分析里是标准的但在工程实现里很少有人真的做。回归拟合的核心代码大概长这样import pandas as pd import numpy as np from scipy import stats def calc_comment_sensitivity(sku_df): 计算单个SKU的评论敏感度 sku_df: 包含week_date, good_rate, adjusted_sale_qty的DataFrame # 剔除异常点 df sku_df[(sku_df[adjusted_sale_qty] 0) (sku_df[good_rate].notna())] if len(df) 4: # 至少4个周样本才能拟合 return None, None # 好评率与销量做线性回归 x df[good_rate].values y np.log1p(df[adjusted_sale_qty].values) slope, intercept, r_value, p_value, std_err stats.linregress(x, y) # p_value 0.05说明关系不显著敏感度记为0 if p_value 0.05: return 0.0, r_value ** 2 return round(slope, 4), round(r_value ** 2, 4)实际跑完回归之后还需要对结果做一次人工抽检。比如随机抽20个SKU人工看一下评论区和销量趋势确认回归方向是否正确好评率上升时销量是否确实上升。这个抽检步骤看起来“不技术”但特别管用。因为算法模型的错误往往不是逻辑错误而是数据输入的错误。评论数据里可能有水军刷出来的假好评有大量带图返现的诱导好评这些数据会让回归结果与现实严重不符。抽检环节能帮你提前发现这类问题。5. 应用场景与业务落地效果5.1 促销敏感度的应用分层定价与活动设计促销敏感度模型做出来之后第一个业务应用是促销活动的分层设计。在我们没有这套模型之前运营同学做活动基本靠“一刀切”——全站所有商品一个折扣力度。结果就是敏感度高的商品根本不需要那么大折扣就能爆量白白牺牲利润敏感度低的商品给再多折扣也不动费用打了水漂。有了促销敏感度标签之后运营就能按敏感度分档去做差异化的促销策略高促销敏感商品主攻拉新和冲量适合做秒杀、前N件优惠、限量抢购这类强刺激活动。因为用户对价格敏感稍微让利就能撬动大量订单毛利率损失可以靠销量规模来弥补。中促销敏感商品适合做满减、加购优惠这类“带节奏”的活动目的是提升客单价和连带率。这类商品你给它直降用户不一定买账但凑单满减往往能激发额外消费。低促销敏感商品促销资源尽量少投放日常保住正常毛利即可。如果要做活动建议跟高敏感商品捆绑销售而不是单独做折扣否则就是纯粹的利润损失。这套策略从上线到落地促销费用整体下降了大约15%但促销期间的GMV没有明显下滑。这个效果本质上是把每一分促销预算花在了正确的地方。5.2 评论敏感度的应用舆情监控与质量提升优先级评论敏感度模型在产品侧的应用就更有意思了。比如高评论敏感的商品意味着用户非常看重评价。这类商品只要有几条差评销量就会明显下滑。针对这类商品我们建议的运营动作是第一优先安排高质量的买家秀和问答内容把好评区的丰富度做起来第二对差评进行快速响应和二次跟进能挽回的尽量挽回不能挽回的要及时在追问区给出官方解释第三产品质量问题的反馈要第一时间同步到供应链防止问题扩大化。而低评论敏感的商品用户不太看评价即使偶尔出现几条差评也不影响转化。这类商品的运营资源就不需要往评论维护上倾斜而是应该重点优化主图、标题、价格这些更影响点击和转化的因素。这套逻辑落地之后客服团队处理差评的优先级终于有了数据支撑不再是谁叫得大声就先处理谁。5.3 数据产品化建设统一敏感度看板模型上线稳定之后我们做了一个统一的可视化看板把这个项目交付给了业务团队。看板主要包含三个模块全局概览各品类促销敏感度、评论敏感度的分布情况哪些品类促销敏感度高哪些品类评论敏感度高一目了然。SKU明细搜索任意SKU看到它的促销敏感度、评论敏感度数值、分档标签、历史趋势以及同品类对比的排名。运营策略推荐根据敏感度组合自动输出推荐策略。比如“高促销敏感高评论敏感”的商品建议策略是“大促冲量重点关注差评”“低促销敏感低评论敏感”的商品建议策略是“维护常规价格不做额外投入”。这个看板上线后的两周日均PV达到了3000多说明业务方是真的在用而不是把它当成一个摆设。这也是我认为一个数仓项目有没有做成功的重要标准——有没有业务方真的天天在用你的数据做决策。6. 常见问题与排查技巧实录6.1 促销敏感度异常偏高或偏低怎么排查整个模型上线之后被问到最多的问题就是“某某商品的促销敏感度怎么突然从1.5变成6.8了是不是算错了”遇到这种问题我的第一步不是去查代码而是先查这个SKU最近的促销活动记录。促销敏感度飙升最常见的原因是折扣力度异常。如果这个商品过去促销都是95折这次突然搞了个5折那敏感度计算出虚高是正常的。这是一种数据正确但业务解读容易误导的情况处理方式是给敏感度模型加一个折扣区间过滤条件只有折扣率在0.7到0.95之间的促销记录才参与计算。过猛和过弱的促销都不参与避免极端值扭曲结果。还有一种情况是SKU本身出现了结构性变化比如商品改版升级、换了主图、改了标题这些动作都会导致销量出现非促销因素的变化。我把这类因素称为“噪音事件”。对于这类事件一个成熟的方案是维护一张“SKU异常事件登记表”当运营确认某个SKU发生了改版、换图、活动报备等特殊情况时手动标注剔除区间模型自动跳过这些天。6.2 样本量不足导致评论敏感度算不出来评论敏感度回归是需要样本量的最少也要4个周级别的数据点也就是一个月的评论和销量数据。但很多新上架的商品评论数量非常少每周可能就几条好评率波动特别大——这个月100%好评下个月一条差评就是90%回归出来的系数完全没有统计意义。对于这类商品我们最终的方案是不做SKU级别的评论敏感度而是默认继承所属类目的评论敏感度均值。等SKU积累了足够样本之后再自动切换到SKU级敏感度。这个“继承父类目”的思路在推荐系统里很常见叫冷启动问题数仓标签建模同样会遇到解决思路也是通用的。6.3 双11大促数据对基线造成的永久性污染这个坑是我要特别强调的。每年双11的销量是日常的几十倍如果你用包含双11的窗口去计算非促销期基线那结果基本就废了。但这个问题还不是最烦的最烦的是双11前的预售期、双11后的返场期这些时间段算不算促销期定义不清晰的话每年10月到12月的敏感度模型都会错乱。我的做法是维护一套“事件日历表”把大促期、预售期、返场期、日常活动期全部打上标记敏感度计算时直接过滤掉大促和返场时段。这套日历表要每年更新而且要在每年大促前提前确认不能等数据跑完之后再补否则历史数据回溯的工作量非常恐怖。6.4 评论情感分析要不要做最后聊一个挺多同学会问的问题评论敏感度到底要不要做细粒度的情感分析毕竟用户写“东西不错”和写“东西不错就是物流太慢”是两个完全不同的评价强度光看好评率4星5星占比会丢失很多信息。我的建议是在有NLP资源的情况下可以做但不要一上来就做。第一版先用好评率、差评率、评价数这些基础指标顶住把整套模型流程跑通让业务先看到价值。等基础版本稳定了、业务方也习惯了看这套指标之后再逐步加入情感分析、话题聚类、属性级情感比如“质量好但味道差”这些高阶维度。我自己在项目里踩过这个坑。第一版就想做情感分析结果标注数据不够、模型效果不稳定、业务看不懂标签含义项目差点夭折。后来返璞归真回到好评率打底先把流程跑通了再迭代加NLP能力反而顺利很多。数仓项目跟做菜一个道理得先保证端上桌的菜是熟的再琢磨怎么摆盘。7. 这个项目后续还能怎么扩展敏感度模型把自己跑成标准表之后能做的事情其实比想象中多。我这里说两个我亲测有效或正在推进的方向给准备做类似项目的同学一个参考。第一个方向是跟价格弹性模型打通。促销敏感度本质上是一种简化的价格弹性但它只考虑了促销折扣这一个变量。如果能把竞品价格、季节因素、库存深度这些变量加进来做一个更完整的销量预测模型那就能用来做定价优化。比如确定一个SKU在什么价格区间内利润最大化而不是只看“促销能不能拉动销量”。这个方向的价值天花板比敏感度本身高得多。第二个方向是做用户维度的敏感度分析。现在的敏感度商品是主体但同样的促销新用户和老用户的反应完全不一样。新用户对折扣的敏感度远高于老用户因为老用户的购买是习惯驱动新用户的购买是价格驱动。如果把商品敏感度和用户敏感度做一个交叉矩阵就能做千人千面的促销券发放策略。这个在大厂叫用户增长在小厂叫精细化运营本质上都是基于同样的数据思维。每次回看这个项目我最深的感受是数仓建模的目标不是把数据算对而是把业务问题翻译成数据问题再把数据结果翻译回业务语言。促销敏感度和评论敏感度这两个词的业务含义运营同学其实早就知道但他们缺的是一个准确、稳定、可执行的数据口径。数仓工程师的价值恰恰就体现在这个“翻译”的过程中。