做速卖通的卖家应该都经历过这种时刻看着后台订单量连续几天往下掉犹豫要不要降价降完又发现利润被压得喘不过气。要么就是凌晨盯着竞品的价格一咬牙跟着改结果第二天醒来发现人家是按计划赚钱自己纯属陪着亏。手动调价最大的问题不是“手慢”而是没有一套可依赖的决策依据。早期我也全靠感觉后来真正把自动化、动态定价和价格历史数据组合起来用才慢慢摆脱了这种被动局面。这套策略本质上只回答三个问题现在该卖多少钱、什么时候改价、改了之后怎么复盘。价格历史数据告诉我们市场曾经发生过什么自动化负责把“应该发生”的动作落下去。这套打法适合单量不大但想做精细化运营的速卖通卖家也适合有几十上百个SKU、靠人工实在盯不过来的团队。下文我会从思路、数据源、定价模型、系统设计到实际脚本逐步展开尽量给出一套可以直接参考的落地方案。1. 动态定价的本质不是“低价”而是“科学分配定价资源”1.1 手动调价的三大痛点先说说我为什么坚决要甩掉手动调价。第一是信息滞后。人工盯价格只能看到“当下这一刻”的页面快照但竞品到底是一个小时前改的价还是三天前就改了、今天系统才抓取到你完全不知道。等你在后台手忙脚乱改完价市场可能已经又变了一轮。第二是决策没有依据。手动调价往往跟着感觉走今天心情不好就降五毛明天看到竞品涨价又赶紧跟着涨价格完全不是围绕成本、销量、库存这些客观指标走的长期下来利润曲线非常不稳定。第三是执行不闭环。调完价之后很少有人会认真记录“我为什么调价、调了多少、对转化和利润产生了什么影响”导致每次调价都是孤立的动作无法沉淀成经验。这三个痛点凑在一起最直接的后果就是你永远在追赶市场而不是在经营一个商品。动态定价要做的事就是把这套流程从“人盯”变成“系统盯”从“拍脑袋”变成“按规则走”。1.2 为什么价格历史数据是动态定价的核心底盘有人可能会问动态定价听起来很复杂是不是得上一堆算法其实起步阶段并不需要。真正值钱的不是算法而是干净、连续、可对比的价格历史数据。历史数据能帮你回答很多关键问题这个商品过去三个月在哪个价格区间销量最好竞品每次降价之后我的单量分别掉了多少平台大促前后价格弹性是不是明显变大这些问题的答案都藏在历史记录里而不是当下的某个价格截图上。有了历史数据你才可能做最简单的“价格-销量”对照分析比如把过去60天的售价和每天订单量拉出来你会发现某个价格区间转化率明显更好或者某个价位离成本太近、完全不适合长期卖。这一步做完再谈自动化才有意义因为自动化只是把“已经验证过有效的规则”重复执行它不会魔法般地帮你找到最优价。我个人的建议是在开始写任何自动化脚本之前先攒至少两周的完整数据。数据字段最好是日期、SKU、售价、促销价、订单量、库存、竞品参考价。哪怕前期用Excel手工整理都行关键是先让数据“跑起来”后面接入脚本才有料可用。2. 价格历史数据从哪里收集、怎么管2.1 官方数据源优先后台报表和订单记录做价格历史数据第一优先级永远是官方数据源。速卖通商家后台提供的订单导出、流量分析、商品分析等报表能拿到自己商品的售价、成交价、销量、转化率等最可靠的数据。这些数据不会被反爬机制干扰也不会因为页面渲染问题而漏抓是后续定价模型最稳定的“内环数据”。建议养成固定节奏每天或每周导出一份商品维度的数据报表命名规则统一例如“sales_20250601.csv”放在固定目录下。长期积累之后这些文件本身就是价值很高的历史资产。这里有个容易忽略的细节导出时要区分“商品原价”和“实际成交价”。大促、优惠券、联盟佣金都会让成交价低于页面原价如果不区分后面做利润核算时会出现很大的偏差。另外速卖通后台也能看到部分流量和搜索关键词数据这类数据如果和应用价格历史数据配合可以帮你判断调价到底影响了曝光还是影响了转化。如果价格降了但曝光没变、单量还是没起来那问题大概率不在价格上可能在主图或评价上。2.2 竞品价格监控合规采集与工具选择想要做动态定价只看自己的数据是不够的。竞品价格是定价模型里的重要输入尤其是标品和同质化明显的类目。竞品价格怎么拿最安全合规的方式是优先看平台是否开放了相关的API或第三方数据服务。如果条件允许先从合规渠道取数。如果实在需要页面级监控我建议克制一点只监控自己核心竞对的少量SKU而不要做全平台海量爬取。技术选型上可以用Requests配合解析库做轻量采集也可以用Playwright这类浏览器自动化工具处理页面动态渲染的场景。这里必须说一句不要试图绕过平台的反爬机制不要用高频访问去打探别人数据账号安全远比所谓“完整数据”重要。我自己的习惯是每个SKU每小时最多抓一次且尽量错峰执行不给服务器造成压力也降低被封风险。用Playwright做价格采集时有几个经验值得分享。第一一定要设置超时和重试页面偶尔加载不全是非常正常的第二保存原始HTML或截图方便后续排查是页面结构变了还是真要改价了第三把采集结果统一落到同一个数据表里不要今天存CSV明天存JSON越乱越难建模。2.3 数据清洗与存储设计这里必须提醒原始数据不能直接用。常见脏数据包括价格字段带了货币符号、时间格式不统一、同一SKU在不同文件中命名不一致、促销价和一口价混在一起等。清洗的底线是保证“每天每个SKU只有一条有效记录”这是所有后续计算的基础。推荐的数据字段结构大概是这样的字段说明示例record_date数据日期2025-06-01sku_id商品SKU编码sku-1001price展示价/原价17.99promo_price实际成交参考价15.49cost采购成本可后续关联9.8sales_qty当日订单量37stock库存320competitor_price核心竞品参考价16.20currency币种USD存储阶段起步用CSV完全够用等数据量大了再迁到SQLite或MySQL。我建议不要一上来就上重型数据库先用能满足“每日增量写入”的工具撑住重点关注的是数据连续性。如果某一天没采集到数据第二天要第一时间补上缺失的数据段会影响后面所有的趋势判断。3. 动态定价的核心策略模型3.1 基于销量阈值触发的规则模型最实用的入门策略是基于规则触发逻辑很简单设定销量阈值低于阈值就降价高于阈值就提价把调价规则写死。比如某商品近7天日均销量低于5件且库存大于200件系统自动降价3%如果近7天日均销量高于20件且库存开始吃紧系统自动提价5%。这种模型的好处是透明、可控、容易排查。问题在于阈值需要人工反复调整。刚开始可能设得太激进一天降好几次最后把自己利润做没也可能设得太保守价格根本不动。我的建议是先用历史数据回放拿过去两周的真实销量和库存数据模拟跑一遍看看按规则调价的结果比人工调价是赚了还是亏了。回放通过之后再放到线上小额测试。3.2 基于竞品价格中位数锚定模型竞品价格中位数锚定是比较经典的做法。思路是每天收集核心竞品的价格计算其中位数或分位数然后把自己的价格锚定在某个位置。比如你定位是性价比路线可以把自己的日常售价设为竞品中位价的95%到98%如果你店铺评价更好、品牌力更强可以锚定在100%到105%。举个例子某商品采集到5个竞品价格15.2、15.9、16.5、17.0、18.0中位数是16.5。如果你要走性价比路线按97%锚定目标价就是16.0。这个数字再叠加上成本约束如果16.0已经低于你的利润底线那就自动取底线价而不是硬跟着竞品走。这个模型最大的优点是用数据代替情绪但也要注意别被单一竞品带偏。竞品可能会为了清库存而临时亏本甩卖如果完全跟随你会被拖进一场无底线的价格战。所以一定要给模型加“下限保护”不能只看竞品还要看自己的成本和利润目标。3.3 成本与利润约束模型动态定价的所有策略最终都要被成本和利润约束兜底。这里说的成本不是单纯的采购成本而是“总成本”。总成本 采购成本 头程物流分摊 平台佣金 支付手续费 预期损耗。平台佣金通常按订单金额的固定比例收取不同类目不一样比例要以你店铺后台实际扣费为准。用一个最简化的公式最低售价 总成本 / (1 - 目标毛利率)。假设某商品总成本是12.5美元目标毛利率是15%那么最低售价 12.5 / (1 - 0.15) ≈ 14.7美元。也就是说无论竞品价格多低无论销量多差自动调价系统都不能把价格压到14.7以下。这道红线的优先级必须高于一切策略模型否则一次失误的改价就可能把一个月的利润全部吃掉。我在实践里会把成本数据单独维护一张表跟商品表做关联。脚本每次计算目标价时都会先读这张成本表确保任何情况下下限价都实时可查。这样即使供应商涨价、物流费用调整系统也能第一时间算出新的底线。3.4 生命周期与大促模型同一个商品在不同阶段是不应该用同一套定价逻辑的。新品刚上架时目标是快速破零、积累销量和评价这时候可以采用“低价渗透”策略甚至可以主动设置一个比竞品低5%到10%的诱饵价把初始销量顶上去。成长期和成熟期则回归到利润优先价格可以跟随竞品中位数波动。到了清仓阶段库存压力大于利润压力触发降价的条件要适当放宽目的是尽快回笼资金。大促时还要多一层临时策略。大促期间流量爆发转化率本身会提升这时反而不要盲目降价太多因为曝光足够大价格稍微有优势就能带动大量订单。同时要注意平台官方活动的优惠叠加逻辑避免出现大促价叠加优惠券之后击穿成本底线。我吃过大亏规则设了“大促前降价5%”结果平台又额外包了满减券最后变成双重优惠一单亏近两美元。4. 自动化系统搭建设计4.1 整体架构五个层各司其职自动化动态定价系统不需要太花哨通常拆成五层就够了。采集层负责定时拉取自己的销量、库存和竞品价格存储层负责把数据落库计算层读取历史数据和规则算出建议价执行层负责把建议价同步到速卖通通知层负责把每天的调价结果发到钉钉、企业微信或邮箱方便你复盘。这个结构最大的好处是每一层都可以独立替换。比如初期采集层用Playwright后面如果拿到了官方API权限可以平滑替换计算层和执行层的代码完全不用动。我见过很多卖家一上来就想搞一个“一键全自动”的巨无霸系统结果每天光排查数据异常就花两小时反而比手动调价更累。架构轻一点反而能跑得久。4.2 技术选型为什么是Python技术选型上Python依然是我最推荐的语言。原因很实在pandas处理表格数据方便requests和Playwright做采集成熟schedule或APScheduler做定时任务很稳定pytest还能给定价规则做自动化验证。这些库都有非常成熟的生态遇到问题搜索解决方案也容易。如果完全不会编程也可以考虑使用RPA工具比如影刀这类国产自动化工具通过模拟鼠标键盘的流程来自动改价。RPA的优势是上手快、不依赖开发缺点是维护起来比较脆页面结构一改就要调整流程而且执行速度远不如API。我的建议是有一定技术能力的卖家优先用Python写脚本不会代码就先用RPA跑MVP等流程验证有效后再逐步往代码方案迁移。4.3 改价执行API对接与RPA兜底改价这一步是最需要谨慎的。速卖通开放平台提供了商品管理相关的接口能力如果账号有对应权限优先走API对接。用API改价的好处是稳定、快速、可追溯每一次修改都有清晰的请求记录和返回值方便后续排查问题。价格同步接口的核心参数一般包括商品ID、SKU ID、价格、币种等具体要以官方文档为准。如果因为类目资质、店铺权限等暂时无法申请到API权限可以先用RPA或浏览器自动化兜底。Playwright可以模拟登录商家后台在商品编辑页把新的价格填入再保存。这个方案能跑通但要特别小心操作频率不要太快每次操作之间加延时避免触发平台的风险控制。我认识一个卖家图省事把间隔设成1秒结果店铺被临时限权整整两天没法改价损失惨重。4.4 定时任务与运行监控系统跑起来的另一半靠定时任务。Linux服务器可以用crontabWindows老服务器可以用计划任务程序。调度频率建议每天1到2次就够除非你处在价格竞争极其激烈的细分品类否则每小时动价不仅风险高还容易让消费者对价格产生不信任。监控告警也很重要。我的习惯是每天改价结束后把当天所有SKU的“原价、新价、底价、竞品中位数价、触发规则”都汇总成一份日志推到钉钉群里。这样即使系统明天出错我也能很快根据日志定位是哪一步出了问题。另外建议加一个最简单的“价格异常自检”如果计算出来的目标价低于成本红线脚本必须跳过执行并报错而不是默默改价。5. 从零搭建一个动态定价脚本5.1 需求确认先拿一个SKU试跑建议不要一开始就全店铺开先选一个数据比较完善的SKU做试点。我这个示例假设某个SKU过去7天日均销量只有4件库存还有200件总成本是12.5美元目标毛利率15%竞品价格列表为[15.2, 15.9, 16.5, 17.0, 18.0]。逻辑是参考竞品中位数按97%锚定同时不能低于成本红线如果销量低且库存高再额外打一个95折。这个需求很简单但足够把整个链路跑通。后续要扩展策略时都可以在这个骨架上往下加模型。5.2 核心定价引擎代码下面是一段简化可读的Python代码。这里使用了模拟的函数表示数据读取和API调用实际接入时替换为真实的数据源和正式接口即可。# pricing_engine.py from datetime import date # 成本表实际可从数据库或CSV读取 COST_TABLE { sku-1001: 12.5, # 总成本美元 } MIN_PROFIT_RATE 0.15 # 目标毛利率15% def get_cost(sku): 获取商品总成本 return COST_TABLE[sku] def get_sales_last_7d(sku): 模拟读取近7天总销量实际可从订单表聚合查询 # 示例数据总销量28日均4 return 28 def get_stock(sku): 模拟读取库存 return 200 def get_competitor_prices(sku): 模拟读取竞品价格列表实际采集后落库再读取 return [15.2, 15.9, 16.5, 17.0, 18.0] def median_price(prices): 计算中位数 sorted_prices sorted(prices) n len(sorted_prices) mid n // 2 if n % 2 0: return (sorted_prices[mid - 1] sorted_prices[mid]) / 2 return sorted_prices[mid] def calculate_target_price(sku): cost get_cost(sku) # 成本红线最低售价不能低于 cost / (1 - min_profit_rate) floor_price round(cost / (1 - MIN_PROFIT_RATE), 2) # 竞品锚定中位数价格的97% comp_median median_price(get_competitor_prices(sku)) base_price round(comp_median * 0.97, 2) # 如果锚定价格低于成本红线强制抬到红线 price max(base_price, floor_price) # 低销量高库存时在保证毛利的前提下小幅降价 sales_last_7d get_sales_last_7d(sku) stock get_stock(sku) if sales_last_7d / 7 5 and stock 100: price max(floor_price, round(price * 0.95, 2)) return { sku: sku, target_price: price, floor_price: floor_price, comp_median: comp_median, rule_fired: low_sales_high_stock if sales_last_7d / 7 5 and stock 100 else none, }这段代码里最关键的是“floor_price”的计算逻辑。它把成本、平台佣金、目标毛利统一压进一个数字任何策略计算出来的价格最终都要跟这个红线做一次比较。很多人写动态定价时会忽略这一步结果就是策略模型跑得很欢月底一算账发现不少订单是在亏本边缘成交的。下面写一个简单的调度入口模拟每天执行并输出结果# run_daily_pricing.py from pricing_engine import calculate_target_price def update_price_to_aliexpress(sku, price): 调用速卖通开放API更新价格。 这里替换为你实际对接的API请求需带上签名和鉴权信息。 # resp requests.post(https://api.aliexpress.com/update_price, json{...}) # 模拟请求成功 print(f[API] sku{sku} 价格已更新为 ${price}) def main(): skus [sku-1001] for sku in skus: result calculate_target_price(sku) print(f[定价] sku{sku} 目标价${result[target_price]} f竞品中位数${result[comp_median]} 触发规则{result[rule_fired]}) # 目标价低于成本红线时不执行改价 if result[target_price] result[floor_price]: print([告警] 目标价低于成本红线跳过改价) continue # 实际执行阶段再调用API update_price_to_aliexpress(sku, result[target_price]) if __name__ __main__: main()注意真实对接API时肯定会涉及签名、Access Token、类目参数等这段代码只是示意流程。真正接入前一定要把官方接口文档里关于价格同步的字段全部核对一遍特别是币种和SKU唯一标识这两个地方错一个可能导致改错商品。5.3 用pytest给定价规则加一层防护网第二个值得养成的习惯是给定价规则写自动化测试。动态定价脚本一旦跑起来最怕的就是哪天改了一个小逻辑结果某类SKU的价格全算错了。用pytest写几个核心用例能在每次改动后立刻发现问题。# test_pricing_engine.py from pricing_engine import calculate_target_price def test_price_not_below_floor(): 任何情况下目标价都不能低于成本红线 result calculate_target_price(sku-1001) assert result[target_price] result[floor_price] def test_low_sales_triggers_discount(): 低销量高库存时目标价应比常规锚定价格更低但仍高于红线 result calculate_target_price(sku-1001) assert result[rule_fired] low_sales_high_stock测试用例不一定要多但要把最容易出问题的那几条守住。比如“目标价不能低于底线”“低销量时会触发降价”“竞品中位数变化时价格会相应变化”。这些用例跑绿了才有底气半夜让脚本自动改价。5.4 定时运行与日志留痕脚本写好后用服务器crontab每天固定时间执行0 9 * * * cd /path/to/project /usr/bin/python3 run_daily_pricing.py logs/pricing.log 21Windows下可以用任务计划程序触发器设为每天9点操作指向python.exe和脚本路径即可。日志一定要保留而且建议按天切割。遇到问题先看日志大多数异常都能从这里找到线索。6. 常见问题与排查速查表6.1 高频问题速查问题现象可能原因解决思路脚本运行了但价格没变API请求失败、SKU编码错误、权限不足查看API返回码核对商品ID和SKU ID价格被改到异常低位成本表缺数据导致底线为0为缺失成本的SKU设置“禁止改价”标记每天都能抓到竞品价但竞品价异常抓到了别人大促前的临时促销价或虚假价格对竞品价做分位数裁剪去掉极端值调价后利润反而下降只盯价格忽略了运费模板和优惠券叠加把总成本和到手价纳入计算销量低、降价后依然没有效果问题可能不在价格而在曝光、主图、评价先看流量是否变化再判断是否继续降价前一天改完价第二天平台又变回来了平台活动价覆盖、关联促销未同步检查商品是否在参加官方活动6.2 如何避免陷入竞品价格战价格战是动态定价最大的隐性风险。某竞品为了清库存把价格压到成本线以下如果你的规则是“只要竞品降价我就跟着降”你会在极短时间内把自己的利润空间完全打没。我现在的做法是给每个SKU设置两个价格上限保护一个是成本底线一个是全店最低毛利。任何策略计算出的价格如果触碰这两条红线之一系统直接拒绝执行并且自动通知人工复核。另外动态定价的频率也不宜过高。频繁小幅度调价会给消费者一种“这店价格不稳”的感觉反而影响转化。建议每次调价幅度控制在3%到8%之间单日调价不超过一次。周末、深夜这类流量低峰期尽量不执行明显降价避免被竞品监控盯上后快速跟进。6.3 价格调整后没有效果的排查思路如果调低了价格但销量依然没有起色不要马上继续降价。先看流量曲线如果曝光量本身就没变化说明价格调整还没被市场感知到问题可能出在关键词排名和广告上如果曝光明显增长了但转化率没变化则需要看评价、主图、问大家这些影响下单决策的因素。价格只是影响转化的变量之一不是唯一的杠杆。还有一个容易被忽略的细节是价格带感知。同一个商品从16.0降到15.9消费者几乎无感但如果你从17.0降到14.9跨过了一个整数心理价位带效果会明显很多。所以动态定价时别只看百分比还得看价格落点是否接近消费者的心理阈值。我一般会把目标价进一步“适配”到常见的价格尾数上比如14.99、16.49、15.9让价格看起来更自然。最后分享一点个人体会我把动态定价跑起来之后最大的收获并不是每天省了多少改价的时间而是终于有了可以复盘的数据。以前调价全凭感觉事后也说不清到底哪一步对了现在每次改价都带着触发规则、竞品中位数、成本底线和执行结果月底拉出来看能很清楚地知道哪些策略是赚钱的哪些策略该删掉。如果你是第一次做这个系统我强烈建议先拿一个SKU试跑两周人工和系统并行观察。哪怕脚本只做“计算建议价人工确认后再改价”的半自动模式也比一上来就完全放权更稳妥。等模型验证能稳定产出利润再逐步放开自动执行毕竟价格是直接关系到现金流的东西再小心都不为过。
=-4πδ：狄拉克δ函数与点电荷的数学本质)
