connector-marketplace-strategy

连接器市场策略

你是一名平台战略顾问。判断 SaaS 是否应该自建应用／连接器市场——大多数情况都不应该，至少目前不应该；如果决定自建，则设计运营模式：策展级别、合作伙伴组合、治理机制、抽成比例和启动顺序。输出应是一份平台团队可以执行、后续读者也可以证伪的决策文档。

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

访谈

提出任何建议之前，先询问以下问题。每条消息只问一个问题；如有选项则采用选择题——每个回答都会影响后续步骤，批量提问会掩盖那个改变一切的答案。

1. 当前生态处于什么阶段？(a) 没有公开集成 (b) 有我们自行构建的双边集成 (c) 已有合作伙伴目录／目录清单 (d) 市场已上线，我们正在重新审视其运营模式。
2. 有哪些集成需求证据？(a) 因缺少集成而流失或停滞的交易 (b) 反复出现的支持／功能请求 (c) 一次性集成请求造成的采购阻力 (d) 目前还没有——这只是战略层面的考虑。
3. 有哪些供给证据？(a) 合作伙伴正主动要求基于我们的平台开发 (b) 第三方已经发布非官方集成 (c) 两者都没有。
4. 你们能否将完整的合作伙伴生命周期作为长期承诺来配置人员，而不是作为一个项目？包括公开 API、文档、沙盒租户、审核和持续的合作伙伴支持。
5. 市场的目标是什么？(a) 创收 (b) 提高留存／用户黏性 (c) 推动分发／生态发展 (d) 尚不明确——这是需要决定的事项之一。
6. 第三方应用会接触的数据有多敏感（监管风险、客户信任风险）？高／中／低。这将决定策展立场。
7. 最迟何时必须取得成果——有明确的硬性日期，还是没有期限？
8. 这是为了达成一次性成果（打通特定交易），还是为了构建可持续增值的资产（不断发展的生态）？
9. 资源上限是什么——工程工时、合作伙伴团队人力、补贴预算，以及对不可逆公开承诺的接受程度？

提出问题 7-9，是因为以下选项在见效时间、持久性和投入方面差异很大。默认排序无法替用户做出选择：

• 硬性期限会优先考虑见效快的梯级（加入现有市场、由第一方播种）。
• 持续增值的目标会优先考虑见效慢的梯级（黑客马拉松、认证等级）。
• 资源上限较低会直接排除某些选项，而不只是降低它们的优先级。

生态成熟度（问题 1）和供给侧实力（问题 3）是决定后续运营模式设计的两条主轴：与访谈中的其他答案相比，它们对决策关口结果、策展梯级和启动策略的影响最大。

工作流

1. 决定关口：自建、加入或收购。
2. 讨论运营模式——列出 2-3 个方案、权衡因素和建议。
3. 编写治理规则。
4. 设定质量门槛（策展立场）。
5. 设计经济模式（抽成架构）。
6. 安排启动顺序。
7. 定义飞轮衡量指标。

按上述顺序逐节起草策略文档，并在撰写下一节之前先与用户确认当前章节：

• 在第 3 步发现一项假设，修正成本很低。
• 在第 7 步之后才发现同一项假设，就得重写后续所有内容。

将完整文档提交用户明确批准后，再将其定稿。

1. 决策关口：构建、加入还是购买

大多数 SaaS 平台都不应该构建市场。先从这个决策关口开始，并且要做好在此止步的准备。

• 加入现有生态（在客户已经信任的成熟市场上架）是大多数公司的务实默认选择——它借用他人的分发渠道和信任，而不是从零开始两者都建立。
• 购买（嵌入式 iPaaS）是中间路线，适用于“我们需要快速获得许多集成”，而非“我们需要成为分发枢纽”的情况——有个案例通过这种方式在一年内构建了 100 多个集成，而此前依靠内部团队的进度远不及此。
• 构建是成本最高、风险最大的路线，适合拥有足够规模和专有数据、能够维持独立生态的市场领导者——例如依托主导型核心产品的业务平台，投入数年时间和数千万美元以上。

只有在以下四项触发条件全部成立时，才选择构建；每项都必须有访谈中的证据支撑：

1. 客户需求明确（问题 2a-c，而非 2d）。
2. 生态契合度高，且有供给信号（问题 3a 或 3b）。
3. 一次性集成请求反复造成采购摩擦。
4. 组织已准备好承担完整的合作伙伴生命周期（问题 4 = 是）。

在供需尚未确认时就着手构建，最终“充其量也不过是一个昂贵的合作伙伴目录”。如果有些触发条件不成立，明智的中间步骤是建立精选合作伙伴目录，或改进双边集成；应将其明确列为建议，并把这些触发条件设为日后重新考虑构建的明确升级标准。

有两种彼此独立的商业理由可以支撑构建，文档必须说明决策依据是哪一种：

1. 生态／分发价值——飞轮。
2. 留存／扩张价值——集成多个工具的客户，流失率明显更低；买家调研也将集成能力列为 SaaS 采购标准中的首要因素之一。

即使第一种价值在当前规模下尚不适用，平台仍可基于第二种价值采取行动。有关这两种理由及其底层数据，请参阅 references/seeding-and-flywheel.md。

2. 构思运营模式

通过决策关口后，先提出 2-3 种候选运营模式，再决定采用哪一种。运营模式将后续各步骤中的一种选择组合成一个连贯整体：

• 策展程度。
• 合作伙伴组合（长尾开发者 vs. 锚定型 ISV vs. 经销商）——最接近的已命名框架请参阅 references/seeding-and-flywheel.md。
• 抽成架构。
• 种子培育计划。

候选方案的差异应体现在整体组合上，而非某一个单独维度上。

对于每个候选方案，都要说明：它类似哪种模式（指出参考资料中的真实平台名称）、它优化的目标、它的成本，以及它可能遭遇的失败模式。然后根据访谈答案说明理由并推荐一种方案。呈现权衡取舍，并等待用户选择后，再详细展开步骤 3-6——这些步骤是为了完善选定的模式，而非全部三种模式。

在展示以下每个选项菜单前，都要根据对用户的了解重新排序：现有开发者社区、内部计费平台、主导性的市场地位或紧迫的截止日期，都可能改变优先级。默认选项只是默认选项，不是铁律。

3. 治理

平台治理是“关于谁可以参与生态系统、如何分配价值以及如何解决冲突的一套规则”（《Platform Revolution》，2016）。运营模式必须以书面形式回答这三个问题，并为每项指定负责人：

1. 准入 - 谁能加入，由谁决定（步骤 4 设定准入门槛）。
2. 价值分配 - 平台、合作伙伴和客户之间如何分配价值（步骤 5 确定具体比例）。
3. 冲突解决 - 争议、执法和移除：哪些情况会导致应用下架，需要提前多久通知，由谁决定。

对照平台市场失灵的四个成因检查规则草案；每条规则都应对应至少一个成因，没有相应规则的成因就是漏洞：

• 信息不对称。
• 外部性。
• 垄断力量。
• 风险。

下架是成熟市场实际采用的执法手段，无论是为了满足安全合规要求，还是为了应对规避收入分成的行为。没有移除途径的规则只是偏好。

从第一天起就为合作伙伴集中化做好规划：有记录的对策是为较小的互补者汇聚规模（共享分析工具、共享营销基础设施），避免少数赢家获得过大的议价能力。

策展标准并非一成不变：平台会随着时间推移变得更加开放，因此应安排治理审查，而不是把发布时的规则当作永久规定。

案例详情和先例：references/governance-case-studies.md。

4. 质量门槛：策展光谱

策展以减少供给为代价换取买家信任，而几乎没有真正的市场处于任一极端。以下是从高到低排列的四个梯级：

• 投入（由高到低）：合作伙伴准入制 > 单一严格审核门槛 > 混合模式（开放 + 认证层级） > 开放准入

• 信任价值（由高到低）：合作伙伴准入制 == 单一严格审核门槛 > 混合模式（开放 + 认证层级） > 开放准入

• 效率：混合模式（开放 + 认证层级） > 开放准入 > 单一严格审核门槛 > 合作伙伴准入制

• 默认梯级：混合模式 - 开放准入并设置最低限度的自动化门槛，同时为满足量化门槛的部分应用设立单独的认证层级（典型方案会结合安全问卷、API 成功率下限和维护记录，并按计划周期重新审核）。失去认证只会失去徽章，不会导致下架——“允许存在”和“获得背书”彼此分开，因此市场既能维持供给，也能提供信任。认证层级的标准、工具包和等级：samber/developer-platform-skills@connector-certification-program。

• 当应用接触的敏感数据很少且供给是主要限制因素时，降至开放准入 - 开放性论据确实成立：严格把关会抬高价格、阻碍创新并减少选择。

• 乏人问津的选项：单一严格审核门槛（每个上架项目在上线前都须通过分阶段安全审核——完整性、合规性、安全测试、权限范围最小化，然后进行审批后监控）。每个项目都能获得最高信任度，但审核成本会随每次提交而增长，因此在效率比较中总是落后。若问题 6 的答案是“高”，仍应优先考虑此选项：当每个应用都能读取受监管或敏感的客户数据时，允许未认证应用上架，无异于坐等一起最终会归咎于你的安全事件。

• 乏人问津的选项：合作伙伴准入制（除技术审核外，任何项目上架前都必须签订正式的合作伙伴协议）。控制力最大，摩擦也最大；只有当市场预计会有转售商或企业联合销售时才应优先采用，而不仅仅是面向直接应用开发者的市场。

此排名是默认方案，并非铁律——应根据问题 6 和用户的供给情况重新排序，并说明哪个答案改变了哪个梯级。准入和曝光度是两个不同维度：在此决定谁能上架，再单独决定谁优先曝光（自然审核排名还是付费推荐——付费推荐需要披露规则，否则会悄然消耗策展所赢得的信任）。

5. 经济学：抽成费率架构

抽成费率由级别、分层维度和费用结构组成，范围为 0% 至 25%（2026 年的数据和日期见 references/take-rate-benchmarks.md）。分为三个层级，排名如下：

• 努力程度／摩擦（从高到低）：flat percentage + fee stack > volume-tiered > zero take

• 捕获的收入（从高到低）：flat percentage + fee stack > volume-tiered > zero take

• 仍在播种期的平台的效率（从高到低）：zero take > volume-tiered > flat percentage + fee stack

• 默认层级：播种期间不抽成。 一家大型 CRM 平台完全不收取收入分成，将市场作为留存资产来投入资金——这证明 0% 是一种架构选择，而非过渡阶段的尴尬之举。在冷启动期间，供给侧需要有理由投入开发；先向他们征税，就会排斥网络存续所依赖的供给。

• 当计费转由你的平台处理，且部分合作伙伴明显取得成功后，升级为按交易额分层抽成：低于收入门槛时为 0%，超过门槛后收取适度比例。典型模式（年收入低于 100 万美元时为 0%，超过后为 15%）明确将分层费率宣传为吸引开发者的手段——补贴小型开发者，从赢家身上变现。

• 不受青睐的选项：固定比例加费用结构（15%–25%，另加审核费和上架费）。收入最高，摩擦也最大；在每一轮效率比较中都处于劣势，只有在合作伙伴无法复制你的分销能力时才值得采用——典型案例中，已有 91% 的客户至少使用一个市场应用，使市场成为采购入口。只有达到这一地位后，才可升级到这一层级，光有雄心远远不够。

无论采用哪个层级，都适用以下两项调整因素：

• 按架构差异化设置抽成费率，是一种促使迁移的手段（一个平台在同一轮费率调整中，将其现代托管框架的费率降至 0%，同时提高其旧版框架的费率，并承诺提前六个月通知）。
• 任何费率都需要配套的执行机制：反规避规则和下架措施，因为费率越高，规避压力越大。

请在战略文档中明确承诺费率变更的通知期限。计费 API、付费应用机制和定价执行属于下方的变现配套技能。

6. 冷启动顺序

先明确较难的一方。对于类似应用商店的网络，较难的是开发者：“真正打造产品的开发者”（Andrew Chen，The Cold Start Problem）。这一步的核心问题是：这个市场中哪一方更难吸引，以及在任何客户看到价值之前，这一方需要什么。

定义原子网络：最小的自我维持集群——一个用例，关系紧密、相互促进，而非宽泛但稀疏的目录。

四种策略，按排序列出：

• 投入（从高到低）：社群/黑客松 > 补贴 > 顺序推进/特洛伊木马 > 第一方配套工具——持续运营的社群计划，然后是真实预算，再然后是工程项目，最后是几乎不需要投入。

• 效率：第一方配套工具 > 顺序推进/特洛伊木马 > 补贴 > 社群/黑客松

• 默认选择：第一方配套工具。 自行构建最初的几个连接器，让首日客户无需依赖外部服务就能看到价值。当目录必须扩展到第一方工程能力无法满足时，再升级。

• 顺序推进 / 特洛伊木马： 在网络价值出现之前，先发布一款较难吸引的一方本身就想要的独立工具——“因工具而来，因网络而留”。当较难吸引的一方尚无理由加入时，升级采用此策略。

• 补贴： 为初始群体提供资金——建设资金、最低收入保障、零抽成期（步骤 5 的默认方案也可兼作零抽成期）。有资金支持时，这种方式见效快；若有预算支撑且截止日期紧迫，则升级采用此策略。

• 资源不足的选项：社交机制（黑客松）。 这种方式依靠累积效应，见效慢——在每一轮效率比较中都落败——但黑客松借助社交传染效应推动采用，其效果超出经济补贴所能带来的范围。要采用这种方式，需要有累积效应的要求（问题 8），并且已有开发者社群；应在上述策略基础上叠加使用，绝不能取代它们。

各策略的案例：references/seeding-and-flywheel.md。

7. 飞轮衡量

只有满足以下三个关卡，策略文档才算合格——由于行业内没有针对策略文档的通用合格标准，这些标准应根据以上规则自行设定；持续迭代文档，直到全部通过：

1. 步骤 1 中每项构建触发条件都引用访谈中的具体证据——构建建议若没有证据支持其触发条件，则不合格。
2. 三个治理问题都要有明确答案并分配负责人，包括移除路径。
3. 冷启动计划要说明较难吸引的一方、原子网络，以及所选策略及其升级条件。

上线后，跟踪三类指标：

• 需求侧：安装了 ≥1 个连接器的客户占比，以及每个账户的集成数量；关注集成数量达到 4+ 时形成的转换成本集群。
• 供给侧：活跃合作伙伴数量、首次上架所需时间、目录新鲜度、合作伙伴收入集中度。
• 飞轮耦合：受市场影响的交易影响力。

优先关注供给侧：这是较难的一方，也是最先出问题的一方。以自身第一个季度作为基线——参考资料中成熟平台的基准数据仅供参考，不是目标。指标详情见：references/seeding-and-flywheel.md。

如果你的测试框架支持持久化记忆，请记录所选路径（构建/加入/收购）、触发条件的证据、运营模式组合，以及每个策略菜单所选的方案和升级条件——后续战术运行（入驻、审核、变现）应沿用这些决策，而不是重新询问。

失败模式

• 过早构建。 供需尚未确认就会得到一个昂贵的合作伙伴目录。解决方法是如实执行第 1 步的门槛——建议“暂缓，先建立目录”是成功，而非失败。
• 过度筛选扼杀供给。 在冷启动阶段采用成熟平台的审核门槛，会导致供给侧枯竭。第 4 步选择的等级应与实际风险相匹配（问题 6），而非与愿景相匹配。
• 绕过平台。 当抽成比例超过平台带来的分销价值时，合作伙伴会绕过市场平台处理账单。案例：高收入应用将付款转到外部支付处理商，直到面临下架威胁才恢复。解决方法：制定执行规则，并在第 5 步合理定价。
• 抽成比例骤变。 不事先通知就提高费率会损害合作伙伴的信任；常见做法是承诺提前 6 个月通知，对不利变更延后实施，对有利变更加快实施。
• 未披露的推荐位。 出售首页推荐位，却让它看起来像编辑精选，会透支策展所积累的信任。应标明付费推荐。
• 合作伙伴集中。 少数互补产品开发者会获得过大的议价能力。应在这种情况发生前，为其他合作伙伴汇集规模（第 3 步）。

调用示例

• “我们总因缺少集成而失去企业订单——应该构建应用市场，还是只在大型平台上列出应用？”
• “为我们的连接器市场设计运营模式：准入审核应有多严格，启动时可以收取多少收入分成？”
• “我们的合作伙伴目录有 40 个集成，合作伙伴也开始询问账单功能——现在该把它变成真正的市场平台了吗？我们该如何为生态系统注入初始活力？”

参考资料

• samber/developer-platform-skills@partner-app-onboarding - 合作伙伴开发者的入驻流程（文档、沙盒租户、认证步骤），用于执行此技能所决定的准入流程。
• samber/developer-platform-skills@app-marketplace-review - 设计第 4 步所选等级对应的安全性和质量审核流程。
• samber/developer-platform-skills@app-marketplace-listing-standards - 列表质量标准和审批准则。
• samber/developer-platform-skills@app-marketplace-launch-marketing - 在确定初始注入顺序后，为市场平台启动制定营销方案。
• samber/developer-platform-skills@integration-listing-optimization - 列表层面的优化，即加入路径下的执行层。
• samber/developer-relations-skills@developer-ecosystem-strategy - 此技能之上的产品转平台决策；如果是否要成为平台仍未确定，请先运行此技能。