
9 月 3 日,亚马逊把旧的 Seller Central 邀请授权流程关掉了——而 93% 的旺季需求都在这个日期后面
亚马逊用新的授权流程替换掉旧的 invite 邀请制,重新授权时只会带上服务商在 Solution Provider Portal 上「已获批」的角色。我们用 Helium 10 量了一下:9 月 3 日之后的窗口,礼品类词吃掉全年 92.7% 的需求,常青类只有 33.5%。
作者:WAYAMZ Team
本文另有 英文版。
亚马逊要把旧的 Seller Central 邀请授权流程关掉了。2026 年 8 月 10 日之后,卖家改用新的授权方式给服务商开权限——在服务商的 SPN listing 上点「Authorise Now」,或者用服务商直接发来的授权链接。服务商这边,必须在 2026 年 9 月 3 日 之前,把自己在 Solution Provider Portal 上的角色覆盖核对并补齐。
如果你把它当成一条服务商侧的合规通知来读,这事儿挺无聊的。但站在卖家角度,里面有一句话的分量远超其他:
卖家重新授权时,新授权只会包含你的服务在 SPP 上当前已获批的那些 Seller Central 角色。
你的服务商今天在用、但没有正式获批的角色,不会跟着过来。不提示、不协商、也不进审核队列——就是在新授权里直接不存在。
而这个日期,卡在日历上一个很特别的位置。所以我们把这个位置值多少钱,量了一遍。
方法
我们用 Helium 10 拉了三条美国站关键词的周搜索量历史。选词的标准是覆盖 Q4 的行为区间,而不是为了凑结论:christmas gifts(纯礼品需求)、winter coat(有季节性但不靠送礼)、air fryer(常青类目,Q4 有个小鼓包)。
Helium 10 返回的每个周数据点,都是「近 30 天」的搜索量——所以一个标注 10 月 4 日的点,描述的其实是大约 9 月 4 日到 10 月 4 日之间的需求。我们把每个点归到它自己那个 30 天窗口的中点,再把中点落在 9 月 3 日到 12 月 31 日之间的点加总,除以近 52 周的总量。
这个窗口是 52 周里的 17 周,也就是全年的 32.7%。如果一个类目的需求是全年均匀分布的,那它在这个窗口里就该是 32.7%。超出的部分,才叫集中度。
结果
| 关键词 | 9/3–12/31 窗口内的需求占比 | 集中度指数 | 全年峰值(窗口中点) |
|---|---|---|---|
| christmas gifts | 92.7% | 2.83 | 2025-12-05,是 8 月中基线的 9.9 倍 |
| winter coat | 63.1% | 1.93 | 2025-11-21,是 8 月中基线的 12.2 倍 |
| air fryer | 33.5% | 1.02 | 2026-06-12,是 Prime Day,不是 Q4 |
同一个日期,三种完全不同的风险画像。
对礼品类目来说,全年 92.7% 的需求都在 9 月 3 日的另一边。相当于把「平均年份」下近三倍的每周需求密度,全部压进了截止日一过就开启的那个窗口里。9 月中旬断档两周——就是那种「某个角色悄悄没续上、过了十天才反应过来、再重新申请」的典型剧本——它不是一个「两周」的问题,它是一个发生在曲线起跳点上的两周,而那条曲线后面要涨十倍。
常青类目那边,指数是 1.02。9 月 3 日就是个普通的周四。而且值得注意:air fryer 的全年峰值压根不在 Q4——是 6 月底 Prime Day 那个 243 万的尖峰。常青卖家的权限风险日历,确实和礼品卖家不一样;硬把两者说成一回事,就是常青卖家白白买了一份自己不需要的 Q4 焦虑。
winter coat 夹在中间,63.1%,但它相对自身基线的峰值是三者里最陡的——12.2 倍。天气驱动的类目,一年里大部分时间量都很小,然后在八周里爆炸式拉升。它的绝对暴露度比礼品类低,但留给你的反应时间更短。
为什么这个坑特别安静
亚马逊大部分的截止日期都会自己吆喝一声。费用变了,你在结算报告上能看见;listing 被压制了,ASIN 直接黑掉。这一个没有任何信号。
有截止日期的是服务商,承担后果的是卖家。而且后果浮出水面的样子,长得像一个普通故障:批量改竞价的表传上去报错、货件死活创建不了、调价软件不写数了。这些看起来都像工具的 bug。第一反应是重试,然后是发工单,再然后——好几天之后——才想起来去看权限。
还有一个结构性原因,让你应该预期「会有缺口」而不是「希望没有」:服务商的权限是这些年一点点自然堆起来的。2023 年请来做 PPC 的代运营,2024 年顺手接了 listing 编辑,2025 年又因为方便接了库存——中间没有任何人正式回头重新界定过范围。SPP 上的已批准角色集,反映的是服务商当初注册申请了什么;实际使用情况,反映的是这段合作后来长成了什么样。重新授权这个动作,会在一个不是你定的日期上,静悄悄地按「注册表」而不是按「实际」来裁决这两者的差额。
具体要做什么
自查本身很小。每个服务商一条消息,这周就得发出去。
对每一个有账号权限的第三方,列出它替你干的事,然后直接问:这些事对应的角色,是不是都在你们 SPP 的已批准覆盖范围里?缺的有没有提交申请?答案要么是「确认了,都在」,要么就是一个你现在还有八天可以修、而不是等到十月才发现的问题。
有两类典型翻车值得点名。第一类是被遗忘的工具——那个几年前接进来的调价软件或 feed 工具,没人把它当成「服务商」,但它手里握着实时的写权限。第二类是那种没查就拍胸脯说「没问题」的服务商,这也正是为什么最后那步复验必须是一个跑通的动作,而不是一个状态页面。
然后按暴露度排序。如果你的头部词长得像表格第一行,你没有任何余量,确认必须在 9 月 3 日之前拿到手;如果像第三行,同样的自查照做,但可以从容一点做。
运营者小结
截止日期是服务商的,断档是你的。
真正该决定你紧张程度的,不是那个日期,而是你全年有多大比例压在它后面。92.7% 的话,9 月中旬一次静默的权限缺口,是这个季度一个礼品类卖家能犯的最贵的非受迫失误之一——而防住它的成本,是给每个服务商发一封邮件。33.5% 的话,它就是一项日常维护。
在你决定自己属于哪一种之前,先把自己的百分比算出来。大部分卖家默认自己是第三行,结果一算是第一行。
运营者简报
每周一封,只给要点。
每周把最值得行动的亚马逊信号打包给你:政策变化、费用数学、数据解读。不发垃圾,随时退订。