H7.14.2subscription price increase notice设计研究
订阅价格上调需要提前通知并给予用户应对窗口
别名: 订阅涨价 · 价格变更通知 · price increase notice
概念解释
已经在扣的订阅把下期价格抬高，必须在新价格生效前通知：旧价、新价、生效日，并留出取消、降级或锁价的窗口。它不是试用转正（那是从 0 到正价），也不是例行续费提醒（那是同价再扣一次）。这里改的是合同里的价格条款。
机制
人按开通时的价做预算。涨价若只出现在下期账单，就被体验成单方面改合同。法律常要求提前通知，但通知若不含新价或没有能完成的取消，窗口是假的。涨价还可能拆成「套餐改名 + 新 SKU」，看起来不像涨价，对账时才发现。窗口要长过人处理邮件与做决定的时间，并在产品内常驻，不依赖那一封还在不在收件箱。锁价、祖父条款如果存在，要作为可选项出现，而不是客服口头。
怎么研究
给活跃订阅改下期价，比较：账单日才变、邮件不含新价、邮件+应用内含旧/新/日期+取消。看取消、降级、争议。
自变量：提前量、是否并排旧新价、窗口内能否完成取消或降级、是否伪装成新套餐。 因变量：生效前主动管理、生效后拒付、人能否复述新价与日期。
不要把「涨价后收入上升」当通知成功。测的是知情与选择，不是短期 ARPU。
边界
税务或支付渠道费率转嫁若被当地法允许即时发生，仍应尽快告知，窗口可能短于商业涨价。企业合同按附加协议走，不走消费者邮件。降价通常不需要同等窗口，但已预付的周期不应克扣。多席位按席计价，要写清是单价涨还是总价涨。
怎么落地
- 生效前发送并在订阅页常驻：旧价、新价、日期、取消与可选降级。
- 禁止把涨价做成新 SKU 静默迁移；迁移必须等同涨价通知。
- 窗口内取消按本期权益处理，不要在通知后立刻停服。
- 验证：改一笔测试订阅的下期价，让人只凭通知说出哪天起扣多少、怎么取消。没有新价或取消要等生效后才能点，窗口失败。