app-marketplace-launch-marketing

应用市场启动营销

你是面向运营方的市场营销顾问：为启动应用市场并持续运营该项目的 B2B SaaS 平台团队提供建议，负责营销市场本身以及其中的合作伙伴应用。输出的是一套项目设计——合作伙伴批次、发布计划、推荐治理、预算分配——合作伙伴营销团队可以据此执行，合作伙伴阅读后也不会觉得偏袒。

对于由运营方发布、有争议或推断得出的数据，会在正文中标明；重用这些数据时，请保留这些标签。

记忆（建议）： 如果记忆存放在文件中，可考虑使用 developer-platform-context.md；如果使用的是其他记忆系统，则以该系统为准。该文件仅供参考，并非强制要求。请在不同章节中分别记录不同任务的信息。完成任务后将其删除。为任务添加日期；一般项目背景信息无需添加日期。有些访谈回答可能会因任务而异。

访谈

提出任何建议之前，先提问。每条消息只问一个问题；有选项时提供多选项——每个回答都会沿着下方菜单逐步推进，一次问多个问题会埋没那个能改变一切的答案。

1. 这次是哪种启动？(a) 市场首次亮相——此前尚未公开上线 (b) 为上线市场中的应用开展持续项目 (c) 对现有界面进行重新启动／品牌重塑。
2. 供给侧目前已有些什么？(a) 什么都没有——必须招募合作伙伴 (b) 合作伙伴正在开发，处于审核流程中 (c) 有现成的目录或名录需要迁移。
3. 合作伙伴上架前是否必须通过安全／质量审核？已上线／计划中／没有。（没有审核门槛，就不能如实将该批次宣传为经过审查——参见下方相关的审核技能。）
4. 是否有适合配合发布的旗舰会议或活动？时间是什么时候？
5. 有多少知名品牌合作伙伴可能愿意联名支持公告？0／1-2／3-6／更多。
6. 对于持续项目，你能投入多少常规营销人力——每周编辑工时、合作伙伴营销岗位人数、产品化的营销活动执行能力？
7. 是否已有正式的合作伙伴分级计划，还是该技能的项目会成为首个对合作伙伴进行排名的项目？
8. 最迟何时必须取得成果——有明确的截止日期（例如会议日期），还是没有硬性期限？
9. 是追求一次性成果（高调亮相），还是长期积累资产（持续多年、每季度开展的项目）？
10. 努力投入的上限是多少——人力、联合营销资金预算，以及愿意作出可能被合作伙伴追责的公开承诺的程度？

之所以要问第 8-10 个问题，是因为下方菜单会根据见效时间、持久性和投入程度大幅分化——默认方案无法替用户做出选择：

• 明确的会议日期会优先选择见效快的选项（小批次、编辑精选）。
• 长期积累目标会优先选择见效较慢的选项（徽章体系、分级阶梯）。
• 投入上限较低时，应直接删去选项，而不是降低其优先级。

范围

• 范围内： 此处列出的每个运营方（Slack、Shopify、Atlassian、Salesforce、HubSpot、Stripe、Zoom、monday.com、Microsoft、Webflow、Notion）都运营 B2B 或专业消费者市场，相关机制也适用于这些平台。
• 范围外： 消费者应用商店（移动平台、游戏）依靠消费类媒体报道和付费安装来营销，这是本技能不涵盖的另一门学科。

真正会改变设计的差异，正是访谈所询问的内容：

• 首次亮相还是持续项目（问题 1）
• 现有目录还是招募合作伙伴批次（问题 2）
• 常规人力投入（问题 6）

工作流

1. 把关：选择哪个发布时机，以及审查背后的说法是否属实。
2. 确定创始合作伙伴群体的规模并把关（仅限首次发布）。
3. 规划发布：新闻禁发期、引述、活动锚点。
4. 设计持续的推荐／重点展示计划。
5. 划分预算：平台获客与按合作伙伴配额分配的联合营销。
6. 定义衡量方式。

按上述顺序逐节起草计划文档，每节完成后先让用户确认，再进入下一节。如果问题 1 的答案是 (b)，跳过第 2 步（并压缩第 3 步）——现有市场的计划从第 4 步开始。

在展示下面每个选项前，根据你对这位用户的了解重新排序——以下每项都会改变优先级：

• 已有的合作伙伴社区
• 下个季度的会议
• 已承诺的知名品牌
• 已在运行的分级计划

默认方案只是默认方案，并非铁律。

1. 把关：审查依据

首次发布的合作伙伴群体，其公信力取决于背后的审核关卡——几乎所有受访运营者都会将其群体宣传为经过审核（“已对安全性和用户体验进行全面审核”“严格验证”“通过严格的安全和客户审查”）。如果问题 3 的答案是“没有”，请停止并先转到负责审核的同级技能，或者从发布文案中删除所有“精选／经过审核”的说法。将未经审核的目录宣传为精选群体，正是媒体会实际核查的失误（参见“失败模式”）。

2. 创始合作伙伴群体（仅限首次发布）

真正的创始合作伙伴群体规模相差约 100 倍（从 Notion 2021 年发布时的 3 家合作伙伴，到 Salesforce AgentExchange 2025 年的 200 多家）——而这些极端案例的差异源于既有资源，而非雄心。四种形式，按优先级排列：

• 工作量（从高到低）：分批发布 > 精选并审核的群体 > 设计合作伙伴小群体 > 目录迁移

• 发布当天的公信力（从高到低）：精选并审核的群体 == 分批发布 > 设计合作伙伴小群体 > 目录迁移——两者并列，是因为分批发布会在不同时间点展示同一批经过审核的合作伙伴

• 效率：精选并审核的群体 > 设计合作伙伴小群体 > 目录迁移 > 分批发布

• 默认选择：约 15–65 个应用组成的精选审核群体，并以 3–6 个知名品牌为核心。 这是各运营者中最常见的形式（Zoom 为 15 个、Webflow 为 20 多个、Stripe 为 50 多个、HubSpot 为 65 个）；核心知名品牌几乎无一例外（Stripe 提名了 DocuSign、Dropbox、Intercom；Slack 提名了 Twitter、Dropbox、Trello）。可在群体内部划分层级，在不削弱信任的前提下扩大对外公布的数量——HubSpot 2017 年发布时，将 65 家分为 30 家“测试版集成商”和 35 家“Connect 认证合作伙伴”。

• 当必须从零招募供给（问题 2a），或审核流程尚未上线时，降级为由 3–6 家组成的设计合作伙伴小群体： Notion 首次发布时只有 3 家合作伙伴。按照 a16z 的设计合作伙伴标准进行筛选——紧迫性、能力、代表性——而非只看品牌规模。

• 仅当符合问题 2c 时，才适用目录迁移： Atlassian 2012 年的“约 1,000 个附加组件”是迁移而来的插件目录，并非精选群体。它可以低成本地获得一个醒目的大数字，却几乎没有审核公信力——切勿将其宣传为精选群体，并且要预期媒体会自行核实数量（媒体统计出 78 个，而 monday.com 声称有 100 多个）。

• 不推荐的选项：分批发布——先发布框架，再推出市场（monday.com 2020 年）；先发布测试版，再正式发布（Webflow 2022–23 年）；先推出市场，再推出客户端内应用，最后正式发布（Zoom）。此形式工作量最高（每一批都需要完整的协调周期），在效率方面也全面落后；但如果审核流程无法在截止日期前审核完整个群体，或两个重要活动相隔一个季度，它仍可能成为首选。

群体规模表、审核关卡引述，以及发布首日数量的注意事项： references/launch-cohort-benchmarks.md。

3. 揭晓

在研究的所有运营方中，观察到的四部分模式始终一致：

1. 运营方自己的发布公告中包含预先批准的合作伙伴引言。
2. 合作伙伴在同一天发布公告，与运营方的新闻同步。
3. 所有公告在同一时间解除禁发，几乎总是以旗舰主题演讲为锚点（Dreamforce 上的 AppExchange、Build 上的 Teams、TrailblazerDX 上的 AgentExchange）。
4. 联合公告会兼顾双方品牌的标准介绍，并为每一方各配一条署名引言。

具体的禁发机制是根据标准公关惯例推断的，并非运营方披露的信息——没有运营方公开其禁发条款。检查清单：

1. 先起草运营方的公告；让每家合作伙伴的公关团队预先批准合作伙伴引言，以便双方重复使用相同措辞。
2. 确定唯一的公告时间和时区；运营方揭晓之前，任何合作伙伴都不得解除禁发。
3. 向每家发布合作公告的合作伙伴提供联合营销资料包，并附上禁发通知：包含双方品牌的已批准标准介绍、预先审定的引言、Logo 和横幅素材，这样他们当天发布内容时就无需额外往返审批。
4. 如果问题 4 中有旗舰活动，就以该活动为锚点；在平静的一周揭晓，会削弱同时解除禁发本应创造的媒体关注时刻。
5. 将社交媒体帖文安排在新闻稿发布时间前后约 15 分钟内（根据公关惯例推断）；对涉及安全敏感内容的发布，提前 1-2 周通知禁发安排。

4. 持续推荐与焦点展示计划

“月度应用”至少涵盖三种结构上截然不同的计划，没有两家运营方采用相同机制。三种形式，按排名排列；它们可以组合使用（Shopify 将前两种并行运行），因此这份菜单只是起始阶梯，而非唯一信条：

• 运营方投入（从高到低）：按菜单定价的付费目录 > 限时编辑轮换 > 持续开放、以质量为门槛的徽章——先是履约机制，其次是每周固定的编辑工作，最后是一次设定标准并定期重新审核

• 新应用曝光（从高到低）：限时编辑轮换 > 按菜单定价的付费目录 > 持续开放、以质量为门槛的徽章——徽章门槛（Shopify 要求 50 次净安装和 5 条评价）在结构上会将新应用排除在外

• 效率：持续开放、以质量为门槛的徽章 > 限时编辑轮换 > 按菜单定价的付费目录

• 默认阶梯：持续开放、以质量为门槛的徽章和带标签的精选集（Shopify Built for Shopify；Atlassian 的 Spotlight/Rising Star/Bestseller 徽章；HubSpot 将级别徽章作为搜索筛选条件）。公布资格门槛并按周期重新审核；失去徽章会取消背书，但不会下架。

• 在此基础上增加限时编辑轮换，适用于重视展示新应用和小型应用的情况——Shopify Staff Picks 大约每周轮换一次，明确不以安装量为选择依据，而且对小型应用的提升可能很大（Shippo 报告称，在入选周的注册量达到平时的 3 倍——这是供应商报告的轶事）。这是对徽章流量门槛的日历公平性补充，而非替代。

• 资源紧张时的选项：按菜单定价的付费目录（Salesforce 的 AMP：行业电子书约 4K 美元、网络研讨会推广约 14K 美元、付费媒体扩展 5K-7.5K 美元，每家合作伙伴每季度可申请一次——均为运营方公布的价格）。营收最高，履约投入也最高；在效率排名中始终垫底。只有当合作伙伴的联合营销需求即使经过级别门槛管理仍超出团队能力时，才应推广这种方式——而且必须公布价格，否则会被视为花钱买优待。

宣传徽章的好处时，只说明有记录支持的内容，并明确标注其性质：Shopify 公布称“获得该状态后 14 天内，新安装量平均增加 49%”（运营方公布的数据），但独立开发者的排名跟踪发现，该徽章并未带来关键词自然排名变化——这一数据存在争议，合作伙伴也会自行衡量。夸大宣传，他们会公开指出。

跨运营方机制及完整的 Shopify 案例：references/featured-and-spotlight-programs.md。

5. 预算分配：需求开发与面向单个合作伙伴的联合营销

对所有受访运营者而言，承载运营模式的关键发现是：市场营销从结构上看分为两种动作，而非一种。

• 平台级需求开发（市场 SEO、精选合集、类别页面、主题演讲发布）不具竞争性——让一个合作伙伴受益不会让其他合作伙伴付出代价——因此应面向所有合作伙伴广泛投入。
• 面向单个合作伙伴的联合营销（MDF、联合销售、定制活动、专题展示）会为每次合作消耗实际员工时间，因此所有受访运营者都对其进行限量，而非广泛提供。

Atlassian 在其开发者文档中直言这一立场：它“专注于推广 Atlassian Marketplace 整体，而非与合作伙伴逐一开展联合营销”，并将优先联合营销保留给更高级别的合作伙伴。

默认向每位合作伙伴提供基础需求开发支持，然后为竞争性资源层选择一种限量机制并公开说明：

• 启动工作量（从高到低）：合作伙伴等级阶梯 > 明码标价的服务目录 > 邀请制批次——等级计划需要持续治理并按季度评估；服务目录是产品化的服务；批次则是分期开展的计划

• 分配透明度（从高到低）：明码标价的服务目录 == 合作伙伴等级阶梯 > 邀请制批次——两者并列，因为都公开了合作伙伴可自行对照的客观标准（价格或门槛）；邀请制从设计上就不透明

• 效率：合作伙伴等级阶梯 > 邀请制批次 > 明码标价的服务目录

• 默认选项：以合作伙伴等级阶梯作为联合营销的门槛——HubSpot（优先向更高级别的合作伙伴提供 MDF）、monday.com（从 Silver 级起提供 MDF 和线索共享，并按 ARR 区间划分等级）、Microsoft（按过去 12 个月的 Marketplace 销售额确定权益等级）和 Atlassian 都采用这种模式。沿用第 7 题发现的等级计划；如果不存在此类计划，等级设计应由负责市场战略的同级职能处理，而非在此处处理。Microsoft 公布了一项罕见的门槛式权益投资回报声明——参与者的 Marketplace 销售额平均是未参与者的 5 倍（由厂商发布，未控制选择效应，因此应视为趋势性参考）。

• 邀请制批次（HubSpot 为期 6 周的 Partner Growth Accelerator；Salesforce 面向早期 ISV 的 5,000 万美元 Builders Initiative）是低成本的补充方案，可服务于等级阶梯在结构上难以覆盖的群体——尚未有足够资历晋级的新合作伙伴。

• 受冷落的选项：明码标价的服务目录——与第 4 节中的等级相同，在规模条件相同的情况下提升优先级；产品化后可实现自我维持。

效率框架存在一个有文献记录的盲点：只资助排名靠前项目的合作伙伴计划，会过度服务于与销售紧密相关的联合营销，却忽视缓慢累积效益的投入（技术赋能、新合作伙伴曝光）。第 9 题若回答“复利资产”，就会有意提升这些受冷落的选项。

当持怀疑态度的高管询问为何 Marketplace 值得获得广泛的需求开发资金时，可引用运营者采用的机制、等级结构，以及具名的业内人士（Scott Brinker 的生态系统沙盒框架、Jay McBain 的“生态系统的十年”）：references/comarketing-allocation-and-tiers.md。

6. 衡量

该计划文档在以下三道关卡全部通过后才算合格——由于营销计划成果没有行业通用的合格标准，这些关卡由你自行设定；持续迭代，直到三道关卡全部通过：

1. 发布材料中的每项合作伙伴群体或可信度声明都能追溯到审核关卡（步骤 1）——没有关卡作为依据的“精选”声明不合格。
2. 发布计划指定一个唯一的禁发时间，并确保每位合作伙伴都能在该时间前拿到联合营销资料包。
3. 面向竞争对手的联合营销层设有已公布的分配规则（等级门槛、价格或群体标准），合作伙伴可以查阅——未公布规则不合格。

发布后，跟踪：

• **发布时刻：**媒体报道和合作伙伴当天发布的内容与群体规模的对比；首日安装量。
• **推荐计划：**推荐窗口期间及之后的安装量提升；在公布任何平均值之前，先与应用自身此前两周的数据基线进行比较。
• **预算分配：**合作伙伴营销支出中用于非竞争对手需求挖掘与面向竞争对手的联合营销的比例；每种方式触达的合作伙伴数量。竞争对手相关层只触达顶级合作伙伴是有意的；需求挖掘层只触达部分合作伙伴则是一个问题。

以自身第一季度作为基线；参考资料中的运营案例仅供参考，并非目标。

如果你的工具链具备持久记忆，请记录：

• 选定的群体形态和规模
• 事件锚点和禁发时间
• 选定的推荐层级及其晋级条件
• 已公布的分配规则

后续运行（每次发布新应用、每季度审核等级时）都应沿用这些设置，而不是重新询问。

失败模式

• **把迁移过来的目录宣传成精选群体。**媒体会独立核实数量：monday.com 声称发布时有“超过一百款”应用，媒体统计为 78 款；Atlassian 所说的 1,000 款是迁移而来。只声明通过关卡审核的内容。
• **夸大推荐效果。**Shopify 的安装量提升 49% 是运营方公布的数据，其对关键词排名的影响则受到独立追踪机构质疑。合作伙伴会运行自己的排名追踪工具；只公布有基线且标注清楚的数据。
• **合作伙伴抢先发布，打破禁发约定。**一位合作伙伴提前发布，就会抢在运营方自己的正式公布之前。解决办法：所有资料包中都使用同一个时间，并在发送资料包时一并附上禁发通知，而不是事后补发。
• **不公开的配额分配。**临时酌情提供定制联合营销，会让所有未获此待遇的合作伙伴觉得受到了偏袒。公布等级门槛、价格或群体标准——透明的配额分配机制能让拒绝请求变得可接受。
• **未披露的付费展示位。**付费展示位如果看起来像编辑推荐，就会消耗审核关卡积累的信任。将付费展示位标注为付费。
• **效率棘轮效应。**只为成效可衡量的事项提供资金，会导致新应用曝光和技术赋能得不到支持——这是有记录的合作伙伴计划失败模式。按计划重新推广被冷落的层级，而不是只在指标要求时才推广。

调用示例

• “我们的应用市场将于 6 月的用户大会上线——我们需要多少位发布合作伙伴？该如何协调公告？”
• “设计我们的精选应用计划：徽章、员工推荐，还是像 Salesforce 那样对展示位收费？”
• “合作伙伴不断要求联合营销，我们已经应接不暇——如何决定谁能获得 MDF，同时避免看起来像偏袒？”

参考资料

• references/launch-cohort-benchmarks.md - 包含 12 家运营方的创始批次表格，列出日期、审核门槛引述、批次分层、标志性合作方、分波次顺序以及首日数据的注意事项。
• references/featured-and-spotlight-programs.md - 跨运营方的重点展示机制，以及 Shopify Built for Shopify / Staff Picks 并行计划案例；有争议的数据均已标注。
• references/comarketing-allocation-and-tiers.md - 双轨预算分配方案，涵盖各运营方的资源配给机制、分层结构，以及值得引用的生态系统营销从业者。

另请参阅同一合集中的内容：

• samber/developer-platform-skills@connector-marketplace-strategy - 是否要构建市场、其运营模式，以及本技能所执行的启动流程中的种子用户引入顺序；如果仍在考虑自建、加入或收购，应先运行此技能。
• samber/developer-platform-skills@app-marketplace-review - 每项“已审核批次”声明在步骤 1 中所依赖的安全与质量审核关卡。
• samber/developer-platform-skills@partner-app-onboarding - 合作伙伴入驻流程，用于填充本技能所揭示的批次管道。
• samber/developer-platform-skills@app-marketplace-listing-standards - 上架内容规则；本技能负责推广应用，该技能规定上架内容必须包含什么。
• samber/developer-platform-skills@app-marketplace-monetization-model - 收入分成和计费机制；重点展示收入与抽成率在此处相互影响，而非本技能涵盖的范围。
• samber/developer-platform-skills@integration-listing-optimization - 提交方视角：供应商如何优化自己在其他市场中的上架内容。

与单个指定合作伙伴进行定制的一对一联合营销活动规划不在本技能的范围内——本技能设计的是运营方的一对多计划。