秒杀系统需求PRD

第一次自由卡促销活动把核心交易系统打挂了。这件事之后，CTO拍板要做一套独立的秒杀系统。在写代码之前要先理清楚业务层面的问题：

• 这个系统为什么做
• 为什么是「现在」做
• 对谁有价值
• 覆盖哪些功能，优先级怎么排
• 上线后怎么验证效果。

文档概要

项目	内容
产品名称	秒杀系统
需求发起方	CTO发起，运营部、市场部、产品部联合推动
业务目标	建设独立于核心交易系统的秒杀能力，支撑高频大规模促销活动
目标用户	C端用户（核心）、运营团队、管理层
涉及渠道	微信小程序、支付宝小程序、APP、抖音小程序

需求背景

业务现状

公司是一家连锁店品牌，注册会员6000万，覆盖微信小程序、支付宝小程序、APP、抖音小程序四个用户端渠道。

自由卡是公司核心的营销工具。它是一种虚拟预付卡，用户先充值到卡里，之后用卡内余额购买饮品。配合大力度折扣（半价、买一赠一等），自由卡活动对用户的吸引力非常强。一张面值100元的自由卡半价50元卖，用户感知到的优惠力度远高于单次消费打折。

自由卡活动是运营团队手里最有效的拉新和促活手段。一次成功的活动，可以在几分钟内带来大量新注册用户和充值金额。

触发事件

第一次大规模自由卡促销活动，导致核心交易系统全面瘫痪。活动一开始，瞬间涌入的用户请求量远超系统承载上限，整个交易流程不可用。不光是参与活动的用户受影响，所有正常的下单、支付、查询订单也全部无法使用，持续了将近20分钟。

这次事故的直接后果：

• 大量用户投诉，客服电话被打爆
• 活动效果大打折扣，计划售出的自由卡只卖出了不到三分之一
• 运营团队此后不敢再做大规模促销活动
• 社交媒体出现吐槽帖，品牌口碑受到影响

为什么现在做

四个因素推动这个需求必须提上日程。

会员规模在持续增长。 会员数新增的非常快，每次活动的潜在参与人数在增加。不做改变，下次事故只是时间问题。

运营需求在加速。 运营团队计划把促销频率从一季度一次提升到每月至少两次。市场部、品牌部都有配合节日节点做活动的诉求（五一、端午、中秋、双十一、年货节等）。当前的状况是想做活动但不敢做活动。

竞对在做。 同赛道的几家品牌已经在做线上秒杀活动，而且频率越来越高。用户被培养出了参与限时抢购的习惯，我们不跟上就是丢客户。

促销流量不能再影响正常交易。 自由卡活动的流量是脉冲式的，活动开始那几秒的请求量可能是日常的几十倍。这种流量特征和正常交易完全不同，混在一个系统里处理，注定互相影响。

业务价值分析

做一个需求之前，要先回答清楚：做了之后能带来什么。这个需求的价值不只是「系统不崩了」这一条，它在多个维度上都有直接影响。

运营价值

维度	当前状况	期望状况
活动频率	1次/季度（不敢多做）	2到4次/月
活动准备周期	每次需要技术团队评估风险，提前一周以上准备	运营人员在管理后台自主配置，当天可上线
活动形式灵活度	只敢做小规模试水	可以放量做大规模促销
试错成本	高（一次失败影响核心交易）	低（秒杀系统独立运行，不影响正常交易）
渠道控制	所有渠道只能统一开关	按渠道独立控制，某个渠道异常时单独关闭

运营团队目前的处境是：每次想做活动，都要拉技术负责人和运维一起评估系统是否扛得住，评估完还不一定敢放量。独立的秒杀系统上线后，运营的活动排期可以从「技术允许什么时候做」变成「业务需要什么时候做」。

品牌价值

促销活动是品牌声量集中爆发的窗口。一次成功的秒杀活动能在社交媒体上产生大量自发传播：用户晒自己抢到了半价自由卡，朋友看到后去关注品牌小程序。

反过来，一次系统故障的活动带来的负面传播也是成倍的。用户在社交媒体上吐槽「又崩了」「抢了半天白抢」，这种口碑损伤的修复成本远高于活动本身的投入。

活动体验的稳定性直接关系品牌可信度。 连续几次活动都顺畅，用户会形成「这个品牌的活动可以放心参加」的认知，后续活动的参与意愿会持续提升。

用户价值

当前痛点	改进后体验
活动开始后页面卡死，不知道有没有抢到	明确的排队反馈，实时告知等待进度
秒杀流量影响正常下单，想买杯饮品都下不了单	秒杀和正常交易完全隔离，互不影响
脚本用户抢走大量库存，普通用户基本没机会	防刷机制保证公平性
抢到了不知道去哪付款	清晰的支付引导流程
支付超时没有提示，名额就没了	超时前提醒，超时后名额释放给其他用户

拉新价值

秒杀活动天然具备社交传播属性。一张半价自由卡的信息在用户的朋友圈或微信群一传播，不是品牌会员的人看到后会为了参与抢购而注册成为新会员。

每次活动的新用户转化路径：

活动信息曝光 → 点击进入 → 注册/登录 → 参与抢购 → 支付 → 成为自由卡用户

运营团队可以针对这条路径设置数据追踪，衡量每次活动的新用户获取量和获客成本，和其他渠道（广告投放、线下地推等）做对比。

成交和增长价值

自由卡充值直接带来预付费收入。一张100元面值的自由卡卖50元，公司在单次交易上让利了50%，但获得的是：

• 锁定消费。 卡里有余额的用户，下次想喝饮品时大概率选择本品牌而非竞品
• 更高的到店频次。 自由卡用户的月均到店次数比普通用户高出40%以上
• 更高的客单价。 用卡支付时用户对价格敏感度降低，更容易选择加料、升杯

从用户生命周期价值来看，一个自由卡用户的长期回报远高于50元的让利成本。

活动数据沉淀下来后，运营团队可以分析：哪个时间段参与人数最多、哪个价位的自由卡最受欢迎、哪个渠道的转化率最高、新老用户的参与比例各是多少。这些数据反过来指导下一次活动的策划，形成持续优化的正循环。

量化预期

指标	当前值	目标值
大促活动频率	1次/季度	2到4次/月
活动期间正常交易影响	全部交易功能不可用	零影响
系统可用性（活动期间）	无保障	99.9%以上
单次活动可支撑的参与用户数	几千人（再多就崩）	几十万人
活动新增注册用户	无法准确追踪	可量化、可归因
活动投入产出比	无法计算	可准确衡量

目标用户

C端用户

用户群体	特征	核心诉求
品牌忠实用户	已有自由卡，月均消费4到6次	以优惠价续充自由卡
价格敏感型用户	有消费习惯，关注优惠信息	用最低价买到自由卡
新用户	通过朋友分享或社交媒体了解到活动	以优惠价体验品牌
黄牛/脚本用户	利用工具批量抢购	大量低价囤卡或转卖

第四类用户是需要防范的对象，不是目标服务用户。产品层面的要求是：防刷机制不能影响正常用户的体验。第一次自由卡活动时就出现过这个问题，活动开始不到几分钟，有人用脚本刷掉了三分之一的卡，真正想买的用户反而没抢到。

运营人员

角色	核心诉求
活动策划	快速创建和配置活动，灵活调整参数
活动执行	活动进行中实时监控数据，能快速干预异常情况
数据分析	活动结束后快速拿到完整的数据报表

管理层

角色	核心诉求
运营总监	活动投入产出比、获客成本、用户留存率
技术负责人	系统稳定性、风险可控
高管	销售增长、预付费收入、品牌影响力

核心业务流程

用户参与秒杀流程

整个流程分五个阶段。

活动前

用户在首页或活动入口看到即将开始的秒杀活动，可以查看活动详情（商品信息、秒杀价格、开始时间、活动规则）。如果感兴趣可以设置开始提醒，到时间后收到推送通知。

抢购阶段

活动到了开始时间，用户点击抢购按钮，系统接收请求后进入排队。页面展示排队状态和等待提示。排队结束后返回结果：抢到或没抢到。没抢到的用户看到明确的提示信息，引导关注下次活动。

支付阶段

抢到的用户需要在5分钟内完成支付。支持两种支付方式：微信支付和自由卡余额支付。临近超时前给用户推送提醒。超时未支付的订单自动取消，名额释放给其他等待中的用户。

完成阶段

支付成功后，自由卡自动充入用户账户，可以立即使用。用户在「我的订单」中可以查看秒杀订单详情。

异常处理

支付失败可以在超时时间内重试。如果支付渠道出现故障，用户可以切换支付方式（比如从微信支付切换到自由卡余额支付）。抢购未成功的用户看到的提示信息要友好且明确，避免「系统错误」这种含糊的说法。

运营活动生命周期

一个秒杀活动从创建到收尾，经历六个阶段。

创建活动

运营人员在管理后台创建活动：

• 设置活动名称和活动时间（开始时间和结束时间）
• 关联商品，设置秒杀价格和库存数量
• 配置限购规则（每人限购N份）
• 选择开放渠道（微信/支付宝/APP/抖音，可多选）
• 配置会员等级限制（可选，不配置则所有注册用户可参与）

审核上架

活动创建后进入待审核状态。审核通过后变为待上架。运营人员确认无误后点击上架，活动对用户可见，但未到开始时间不可抢购。上架前有一次确认弹窗，防止误操作。

活动进行中

到了开始时间，活动自动切换为进行中状态。值班人员通过管理后台实时监控数据：参与人数、成交笔数、库存消耗速度、各渠道的流量分布。如果出现异常，可以随时执行紧急操作：一键关停整个活动、关闭某个渠道的入口、调整限购数量。

活动结束

两个条件任一满足即结束：到达设定的结束时间，或库存全部售罄。活动结束后，系统等待所有待支付订单处理完毕（支付成功或超时取消）。

数据复盘

活动结束后系统自动生成数据报表。运营团队查看完整的活动数据：成交金额、参与人数、各商品的销售情况、各渠道的流量和转化率、新用户注册数。数据支持导出，供团队做活动复盘和下一次活动策划。

功能需求

整体分为三大块：C端用户功能、运营管理功能、数据统计功能。

C端功能清单

功能	描述	优先级
活动列表	展示当前和即将开始的秒杀活动	P0
活动详情页	商品信息、秒杀价、原价对比、倒计时、规则说明	P0
抢购	活动开始后点击抢购按钮，提交请求	P0
排队状态	提交后展示排队进度和等待提示	P0
结果反馈	抢购成功或失败的明确提示	P0
订单确认	展示订单信息，引导支付	P0
微信支付	支持微信支付完成付款	P0
自由卡余额支付	支持用已有自由卡余额购买	P0
秒杀订单查询	在「我的订单」中查看秒杀订单	P0
活动开始提醒	订阅提醒，开始前推送通知	P1
支付超时提醒	临近超时前提醒用户尽快完成支付	P1
活动分享	分享活动到微信好友或朋友圈	P1
活动日历	查看近期所有秒杀活动排期	P2

运营管理功能清单

功能	描述	优先级
活动创建	填写活动信息、关联商品、设置规则	P0
活动编辑	编辑未开始的活动信息	P0
活动上架/下架	控制活动是否对用户可见	P0
紧急关停	活动进行中一键关停，所有新请求立即被拦截	P0
渠道控制	按渠道独立开关（微信/支付宝/APP/抖音）	P0
商品管理	管理秒杀商品，设置秒杀价格和库存数量	P0
限购配置	设置每用户每商品的购买上限	P0
实时数据看板	活动进行中查看实时销售数据和库存消耗	P0
订单管理	查看和管理秒杀订单（查询、详情、取消）	P0
运行时参数调整	活动进行中调整限购数量、限流比例等关键参数	P0
会员等级限制	配置参与活动所需的最低会员等级	P1
活动复制	基于历史活动快速创建新活动	P1
批量操作	批量取消订单、批量退款	P1
防刷规则配置	配置防刷相关参数（限流阈值、黑名单规则等）	P1

数据统计功能清单

功能	描述	优先级
活动概览	单场活动的参与人数、成交笔数、成交金额、支付转化率	P0
单品维度统计	每个商品的售出数量、剩余库存、支付转化率	P0
数据导出	活动数据导出为Excel	P0
渠道维度统计	各渠道的流量、参与人数、转化率对比	P1
新用户统计	通过活动新注册的用户数量和转化路径	P1
历史活动对比	多场活动的数据趋势对比	P2
用户画像分析	参与活动用户的特征分析（地域、会员等级、消费频次等）	P2

页面原型

以下原型图展示的是各核心页面的功能布局和信息结构，不代表最终的视觉设计。实际上线的界面会由设计团队根据品牌视觉规范重新设计，但页面包含的功能模块和交互逻辑以此为准。

管理后台

运营人员日常使用管理后台完成活动的创建、管理和监控。核心页面有两个：活动列表页和创建活动页。

活动列表页

活动列表是运营人员进入后台后的主工作台。页面核心元素：

元素	说明
活动列表	以表格形式展示所有活动，包含活动名称、活动时间、关联商品数量、当前状态
状态标签	用不同颜色区分活动状态：待审核、待上架、进行中、已暂停、已结束
操作按钮	根据活动状态动态展示可用操作。待上架状态可编辑和上架，进行中状态可监控和关停
创建入口	页面右上角的创建活动按钮，点击进入创建活动页

创建活动页

创建活动页分为两个区域：基础信息和秒杀商品。

基础信息区域的表单字段：

字段	类型	说明
活动名称	文本输入	必填，活动的展示名称
活动时间	时间范围选择	必填，设置开始时间和结束时间
生效时段	单选 + 时间范围	可选全天生效或指定每天的生效时段（比如每天10:00到12:00）
限购数量	数字输入	每人每商品的购买上限，默认为1
会员等级	下拉选择	可选不限制、银卡及以上、金卡及以上、黑卡
备注	文本输入	选填，运营内部备注信息

秒杀商品区域是一个可编辑的商品表格，运营人员通过「添加商品」按钮选择商品并配置秒杀参数：

字段	说明
商品名称	从商品库中选择
商品图片	跟随商品库，可单独替换
原价	商品原始价格，不可编辑
折扣方式	固定价格或折扣比例二选一
秒杀价/折扣比例	固定价格模式直接填秒杀价，折扣比例模式填百分比后自动计算秒杀价
活动库存	本次活动该商品的可售数量
排序	商品在活动页的展示顺序

表单填写完成后，运营人员点击「提交审核」进入审核流程，也可以点击「暂存草稿」稍后继续编辑。

C端小程序

C端用户通过小程序参与秒杀活动。核心页面包括活动详情页和秒杀订单列表。

活动详情页

活动详情页是用户参与秒杀的主页面，从上到下包含以下区域：

区域	说明
活动头图	展示活动主题和视觉banner
倒计时	活动未开始时显示距开始倒计时，进行中显示距结束倒计时
商品列表	展示参与秒杀的商品卡片，每张卡片包含商品图片、名称、原价（划线）、秒杀价（高亮）、限购提示
活动规则	折叠展示活动规则说明（限购规则、支付时限、退款规则等）
抢购按钮	页面底部固定的操作按钮。未开始时显示「即将开始」不可点击，进行中显示「立即抢购」，已结束或售罄显示对应状态

用户点击抢购后，页面切换为排队等待状态，展示排队进度。抢购成功后跳转到订单确认页，引导用户在5分钟内完成支付。

秒杀订单列表

用户在「我的订单」中可以查看所有秒杀订单。页面顶部有状态筛选标签：全部、待支付、已支付、已取消、已完成。

每张订单卡片包含以下信息：

元素	说明
订单状态	用颜色标签区分：待支付（橙色）、已支付（蓝色）、已完成（绿色）、已取消（灰色）
商品信息	商品名称、数量、支付金额
时间信息	待支付订单显示剩余支付倒计时，已完成订单显示支付时间
操作按钮	待支付订单有「去支付」按钮，已完成订单有「查看详情」按钮

待支付订单的倒计时归零后，系统自动取消订单并释放库存名额。

业务规则

规则类别	具体规则	补充说明
活动时间	活动有明确的开始和结束时间，时间窗口外不可抢购	开始时间精确到秒
活动状态流转	待审核 → 待上架 → 已上架 → 进行中 → 已结束	主路径之外还有已驳回、已暂停等分支状态，完整定义见「状态流转」章节
限购	每个用户、每个活动、每个商品限购N份	N由运营配置，默认值为1
支付时限	抢到名额后5分钟内完成支付	超时自动取消订单，名额释放给其他用户
渠道控制	微信、支付宝、APP、抖音四个渠道独立开关	可随时开关某个渠道的入口
会员等级	可配置参与活动所需的最低会员等级	不配置则所有注册用户可参与
库存占用	抢到名额即占用库存，未支付的在超时后释放	未支付的名额不计入已售数量
活动结束条件	到达结束时间或库存全部售罄	任一条件满足即结束
退款规则	已支付的自由卡订单不支持退款	自由卡充值后即可使用
防刷	系统自动检测异常行为并限制参与	不能影响正常用户体验

状态流转

业务规则表里列了活动和订单的状态流转方向，这里用状态机的方式把完整的流转路径画清楚，包括每次流转的触发条件。

活动状态机

当前状态	触发条件	目标状态
待审核	审核通过	待上架
待审核	审核驳回	已驳回（可修改后重新提交）
待上架	运营点击上架	已上架（用户可见，不可抢购）
已上架	到达活动开始时间	进行中
进行中	到达结束时间或库存全部售罄	已结束
进行中	运营点击暂停	已暂停（新请求被拦截，已提交的订单继续处理）
已暂停	运营点击恢复	进行中
进行中	运营点击紧急关停	已结束（所有新请求立即被拦截）

几个需要注意的状态：

已上架和进行中的区别。 已上架状态下，用户能在小程序里看到活动信息和倒计时，但抢购按钮不可点击。到了开始时间系统自动切换到进行中，抢购按钮才可用。这个设计是为了让用户提前了解活动信息，活动开始时不用再花时间找入口。

暂停和关停的区别。 暂停是临时中断，可以恢复。比如发现某个渠道流量异常，暂停后排查处理完再恢复。关停是直接终结活动，不可恢复，用于出现严重问题（比如价格配置错误）时的紧急止损。

订单状态机

当前状态	触发条件	目标状态
待支付	用户完成支付	已支付
待支付	超过5分钟未支付	已取消（库存自动释放）
待支付	用户主动取消	已取消（库存自动释放）
已支付	自由卡充值完成	已完成
已支付	系统异常导致充值失败	已关闭（触发退款流程）

订单状态的关键约束：已取消状态下库存必须立即释放，保证其他等待中的用户有机会抢到。已支付到已完成之间是自由卡充值环节，正常情况下是秒级完成的自动操作，用户几乎感知不到这个中间过程。

需求优先级

需求按业务价值和紧急程度分为三个批次。

P0：第一期必须上线

P0是秒杀活动能正常运行的最小集合，缺少任何一项活动都无法正常进行。

模块	P0功能项
C端	活动列表、详情页、抢购、排队状态、结果反馈、订单确认、微信支付、自由卡余额支付、订单查询
运营端	活动管理全流程（创建/编辑/上架/下架）、商品管理、限购配置、紧急关停、渠道控制、实时看板、订单管理、运行时参数调整
数据端	活动概览、单品维度统计、数据导出
安全	防刷机制

P1：第一期增强

P1在P0稳定运行后尽快补齐，提升用户体验和运营效率。

模块	P1功能项
C端	活动开始提醒、支付超时提醒、活动分享
运营端	会员等级限制、活动复制、批量操作、防刷参数配置
数据端	渠道维度统计、新用户统计

P2：后续迭代

P2功能根据前几次活动的运营反馈和数据分析结果决定做不做、什么时候做。

模块	P2功能项
C端	活动日历
数据端	历史活动对比、用户画像分析

验收标准

系统稳定性

指标	标准	验证方式
秒杀系统可用性	活动期间 ≥ 99.9%	监控数据
正常交易影响	活动期间零影响	正常交易的响应时间和错误率无变化
抢购结果反馈时间	用户提交后5秒内获得结果	数据埋点
支付成功率	≥ 95%（排除用户主动放弃）	支付数据

业务转化

指标	标准	验证方式
库存售罄率	首场活动 ≥ 80%	活动结束后统计
抢到→支付转化率	≥ 70%	漏斗数据
用户投诉率	较上次活动下降50%以上	客服工单数据
活动新增注册用户	可追踪、可归因	埋点数据

运营效率

指标	标准	验证方式
活动创建到上线	运营人员独立完成，不依赖技术团队	实际操作验证
紧急关停响应时间	点击关停后10秒内所有新请求被拦截	演练验证
活动数据报表	活动结束后1小时内可查看完整报表	实际操作验证

如何验证需求价值

这个需求的价值不能等全部做完才验证，分三个阶段逐步确认。

内部验证

正式对外活动前，先做一次内部模拟活动。参与者是公司内部员工，规模控制在几百人。验证三件事：核心购买流程是否跑通、运营配置流程是否顺畅、数据统计是否准确。内部验证的目的不是测试系统承载能力，而是确认业务流程没有遗漏。

小规模验证

首次对外活动选择一个小规模的商品，库存控制在几千份，只开放一个渠道（微信小程序）。重点观察以下指标：

观察指标	关注点
系统稳定性	秒杀系统是否正常运行，正常交易是否受影响
库存售罄速度	判断商品和价格的吸引力是否符合预期
支付转化率	支付流程是否顺畅，用户放弃支付的比例有多高
用户反馈	客服工单量、社交媒体评价、用户主动反馈
新用户注册	这场活动带来了多少新注册用户

小规模验证的结果决定后续是继续放量还是先修改优化。

规模化验证

小规模活动验证通过后，逐步放量：增加库存、开放更多渠道、提高活动频率。每次活动后做数据复盘，和上一次活动做纵向对比，和其他营销手段（广告投放、优惠券发放等）的投入产出比做横向对比。

需要持续追踪的长期指标：

• 自由卡用户的复购率（对比非自由卡用户）
• 自由卡用户的月均到店频次
• 每场活动的获客成本（活动投入 ÷ 新增用户数）
• 自由卡用户的12个月生命周期价值

这几个长期指标是判断秒杀系统业务价值的根本依据。单场活动的成交金额只是短期收益，自由卡用户的长期留存和消费才是这件事值不值得持续投入的答案。

风险评估

风险项	影响程度	发生概率	应对措施
黄牛/脚本批量抢购	高	高	防刷机制：用户行为检测、单用户限流、异常行为自动标记
活动期间系统故障	高	中	紧急关停能力、应急预案、值班机制
库存超卖	高	低	库存扣减准确性保证、定时对账
支付渠道故障	中	低	支付超时处理、名额自动释放、支付方式切换引导
活动规则配置错误	中	中	审核流程、上架前二次确认弹窗
数据不一致（订单和库存对不上）	高	中	定时对账机制、异常监控和告警
负面舆情	中	低	活动规则透明展示、用户反馈渠道畅通、客服话术提前准备

术语表

PRD里反复出现一些业务术语，为了避免不同角色理解不一致，在这里统一定义。

术语	定义
自由卡	公司发行的虚拟预付卡，用户充值后可用卡内余额购买饮品。是秒杀活动的核心商品类型
秒杀活动	在限定时间窗口内，以低于日常售价的价格限量销售商品的促销活动
库存	单次活动中某个商品的可售数量，售完即止
限购	同一用户在同一活动中对同一商品的购买数量上限
名额	用户抢购成功后获得的购买资格，占用一个库存。在支付时限内完成支付即正式成交，超时未支付则名额释放
渠道	用户访问系统的入口，包括微信小程序、支付宝小程序、APP、抖音小程序
紧急关停	活动进行中遇到异常情况时，运营人员一键终止活动的操作，执行后所有新请求立即被拦截
会员等级	用户在会员体系中的级别，从低到高为普通会员、银卡会员、金卡会员、黑卡会员
支付时限	用户抢到名额后必须完成支付的时间窗口，默认为5分钟
防刷	系统自动识别和拦截异常抢购行为（脚本、批量请求等）的安全机制

数据埋点需求

秒杀系统上线后，需要通过数据埋点来衡量系统表现和业务效果。以下是核心埋点事件的定义，供技术团队在开发阶段同步实现。

C端用户行为埋点

事件名称	触发时机	关键参数
活动页曝光	用户进入活动详情页	活动编号、渠道、用户ID、会员等级
抢购按钮点击	用户点击「立即抢购」按钮	活动编号、商品编号、渠道、用户ID
抢购结果	系统返回抢购结果	活动编号、商品编号、用户ID、结果（成功/失败）、排队耗时
支付发起	用户发起支付请求	订单编号、支付方式、金额
支付完成	支付回调成功	订单编号、支付方式、金额、从抢到到支付的耗时
支付超时	订单因超时被取消	订单编号、用户ID、超时时长
活动分享	用户分享活动	活动编号、分享渠道（微信好友/朋友圈）、用户ID

运营侧关键指标

指标	计算方式	用途
活动参与率	点击抢购的用户数 ÷ 活动页曝光用户数	衡量活动吸引力
抢购成功率	抢购成功用户数 ÷ 点击抢购用户数	衡量库存和流量的匹配度
支付转化率	支付成功订单数 ÷ 抢购成功订单数	衡量支付流程顺畅度
渠道转化漏斗	各渠道的曝光→点击→成功→支付各环节转化率	识别各渠道的表现差异
新用户占比	活动期间新注册用户数 ÷ 活动参与总用户数	衡量活动的拉新效果
人均抢购耗时	从点击抢购到收到结果的平均时长	衡量系统响应性能的业务感知

这些埋点数据最终汇总到数据统计模块的各个报表中，供运营团队做活动复盘和策略优化。

本专栏在知乎里，且我也开了星球，有兴趣的可以订阅和加入，一起交流。

• 知乎账号:SamDeepThinking
• 星球:老码头的技术浮生录

小结

做了这些年开发，参与过不少需求评审。一个常见的情况是技术同学拿到需求后直接翻功能列表，把背景和价值分析跳过了。这样做的结果是遇到方案取舍时缺少判断依据。

比如产品要求「秒杀活动不能影响正常交易」，看过这份PRD里的事故背景和业务价值分析，就知道这不是一个可商量的选项，而是一条不可退让的红线。技术方案里关于流量隔离的设计、关于紧急关停的响应时间要求，都从这条红线推导而来。

再比如需求优先级为什么这样排。P0里的每一项都是活动能正常运行的最小集合，缺了任何一项活动就做不了。P1和P2的排序依据是对业务的贡献程度和实现成本的权衡。理解了排序逻辑，技术方案的分期规划就有了明确的依据。

需求文档不只是给产品经理看的。开发理解了业务意图，做出来的系统才经得住真实业务的检验。

下一篇进入技术方案设计，基于这份PRD里的每一个功能点和业务规则，拆解系统架构和技术选型。