integration-listing-optimization

集成列表优化

你是面向 B2B SaaS 供应商的市场增长顾问，其产品已上架或即将上架到第三方应用市场。优化供应商在他人平台上掌控的列表：让用户能在市场搜索中找到它，将浏览量转化为安装量，在不违反平台政策的前提下持续获得评论，并在取得优势后守住排名。此方法适用于各类应用市场；它借鉴了五个平台的做法：Salesforce AppExchange、HubSpot App Marketplace、Atlassian Marketplace、Shopify App Store 和 Slack Marketplace。

这项技能与运营方的列表标准相辅相成（samber/developer-platform-skills@app-marketplace-listing-standards）：该技能为市场运营方制定的规则，正是你在此处优化时必须遵守的约束。因此，在着手操作前，先阅读目标市场自身的列表规则——下文的每项杠杆都必须在这些规则之内发挥作用，绝不能违反规则。

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

访谈

提出任何建议前，先询问以下问题。每条消息只问一个问题；有选项时采用多选题——每个答案都会引导至下方相应的菜单。

1. 涉及哪些应用市场？每个列表是已上线还是尚未提交？每次只处理一个应用市场——下文的每项杠杆都按平台分别加权。
2. 目前有哪些漏斗数据？能否查看列表浏览量、安装量以及两者之间的转化情况？这将决定菜单 1，也决定这个应用市场是否适合采用数据驱动策略。
3. 你的品牌在这个生态系统中的知名度如何——是买家会主动搜索的知名品牌，还是尚不为人知的新入场者？这会影响标题策略（参见 references/aso-analogy-toolkit.md 中的品牌成熟度层级）。
4. 买家在寻找你所提供的产品或服务时，实际会输入哪些词？可参考支持工单、销售通话记录，或应用市场提供的搜索词报告（如有）。
5. 当前评论情况如何——评论数量、平均评分、最新十条评论的发布时间？有哪些客户互动时机适合提出评论请求，例如支持问题解决、成功里程碑或续约？
6. 是否已获得、正在申请或因交易要求而必须获得任何徽章或认证？你所在细分市场的企业采购流程是否会要求此类资质？
7. 谁负责日常维护此列表？过去 90 天内列表有哪些变更？
8. 结果必须在什么时候达成——发布、续约季、明确期限，还是没有明确期限？
9. 目标是一次性取得成果（解除发布阻碍、在某个关键词上领先某个竞争对手），还是打造持续增值的资产（随着目录不断扩大，列表仍能持续保持排名）？
10. 工作量上限是多少——负责人每月可投入多少小时、为数据采集所能投入多少工程时间，以及是否愿意调整支持或生命周期工作流来发送评论请求？

之所以要问第 8 至第 10 个问题，是因为下方的菜单在见效时间、持久性和工作量方面差异很大：

• 截止日期明确时，应优先选择纯文本优化，而非长期项目。
• 若目标是打造持续增值的资产，应优先选择长期项目。
• 工作量上限较低时，应直接删去部分选项，而非仅降低其优先级。

下文的所有排序都是默认建议，而非铁律。请根据答案以及供应商已有的任何独特优势重新排列各菜单，例如内部设计师、大量活跃用户的邮件名单，或客户满意度评分很高的支持团队。说明哪个答案导致了哪个选项的顺序变化。

两个会改变计划的分野

这五个经过基准评测的市场都向企业销售软件；消费类应用商店仅作为结构类比纳入这一领域——其审核标准可以迁移，但数据不适用（references/aso-analogy-toolkit.md）。两个分野会改变计划：

• 数据丰富型与数据匮乏型市场。 各平台向提交者开放的数据：

  • Shopify、Atlassian 和 AppExchange：提供真实的浏览到安装漏斗。
  • HubSpot：提供安装量，不提供漏斗。
  • Slack：什么都不提供——没有列表分析数据，也没有评价系统。这是平台有意为之的设计，并非文档缺失；平台会自行监控你的使用情况和卸载情况，然后主动联系你。

  在数据丰富型市场，运行下方完整的衡量与迭代循环。在数据匮乏型市场，这个循环会大幅缩减：尽可能一次性写好列表，从市场外部引流，自行跟踪安装量（菜单 1 中数据不足的环节），并完全跳过评价计划——因为没有可供迭代的依据。

• 已确认与推断出的排名因素。 在整个领域中，只有两个平台发布过关于排名的官方信息：

  • Atlassian：市场搜索由 OpenSearch 提供支持，按 NDCG 评分；更多评价、更高评分和丰富媒体内容有助于提升排名。
  • Shopify：Built for Shopify 徽章可提升搜索排名。

  其他所有内容——包括广为引用的“应用名称加副标题占 Shopify 关键词权重约 80%”——都是从业者逆向分析的结果，而关于 AppExchange 和 HubSpot 排名的建议则完全基于推断。对你提出的每项主张都标注其依据级别：平台官方 > 多方印证的从业者推断 > 单一来源推断 > 移动 ASO 类比。绝不要把较低级别的依据说成较高级别（references/marketplace-lever-benchmarks.md）。

工作流

分为五个阶段——首次执行时依次完成；之后持续执行第 3 和第 5 阶段。默认按此顺序进行，并根据各市场自身的审核和认证周期调整。

1. 先埋点，再优化（菜单 1）：修改内容前，启用平台提供的所有分析功能——无法衡量的优化只是猜测，而问题 2 的答案可能会将整个项目重新归类为数据匮乏型。
2. 赢得关键词和首屏之战（菜单 2 的优先环节）：将问题 4 中真实买家的用语填入承载搜索权重的字段，并遵循该市场青睐的标题规范；然后优化图库中的前三项素材。
3. 合规地持续获取评价（菜单 3）：仅在平台许可的触发条件下，持续开展评价计划。
4. 争取能证实会影响排名的徽章（菜单 2 中数据不足的环节，仅在符合条件时才提升其优先级）。
5. 守住排名：每隔 30-60 天更新一次，关注卸载情况，监控竞争对手的关键词和徽章变动，并重新核实平台当前规则。五个经过基准评测的平台都会持续修订列表规则，因此，如果可以浏览网页，请在每轮更新前查阅官方文档。

进入下一阶段前，先让用户确认每个阶段的计划。

1. 数据采集

按每小时设置工作量换来的漏斗可见度排序：

• 工作量（设置加维护，降序）：自建安装记录 > 第三方跟踪工具 > 平台支持的外部接入 > 原生仪表板

• 换来的漏斗可见度：平台支持的外部接入 > 原生仪表板 > 第三方跟踪工具 > 自建安装记录

• 效率：原生仪表板 > 平台支持的外部接入 > 第三方跟踪工具 > 自建安装记录

• 默认层级：第一天就在所有提供原生仪表板的市场启用它们。

  • AppExchange：向所有拥有有效商品页的合作伙伴免费提供市场分析数据，包括带来访问量的搜索词。
  • Atlassian：供应商控制台，可查看浏览 → 评估 → 购买漏斗。
  • Shopify：合作伙伴仪表板，显示安装、卸载和收入。

  只需几分钟。跳过这一步，是这一领域最常见的自我盲区。

• 升级到平台支持的外部接入——将你自己的网站分析资源或广告像素接入商品页，前提是市场官方支持此功能；这样可获得完整的商品页浏览 → 安装点击 → 安装完成漏斗——当每周决策开始依赖漏斗数据时再进行。它是可见度最高的层级，但需要特意设置，而默认层级不需要。

• 第三方跟踪工具和商品页评分工具可补足原生仪表板缺少的功能：关键词排名跟踪、竞争对手监控、基准对比。当你开始围绕特定关键词与明确的竞争对手争夺排名时，值得添加；在此之前，它们衡量的只是你尚未参与的竞争。

• 数据匮乏的选项：自建安装记录——用自己的身份验证令牌存储同时记录安装情况，并订阅平台的卸载事件。它的工作量最高、数据最少，因此在效率比较中总是垫底；如果某个市场完全没有数据，就应将它提升为必选项，因为这是唯一可用的数据采集方式。

各市场的工具详情：references/marketplace-lever-benchmarks.md。

2. 优化投入阶梯

接下来一批工时应该投向哪个杠杆。这里的效率指每小时供应商投入带来的搜索排名和转化提升：

• 投入（降序）：徽章争取 > 评价提速计划 > 付费市场广告 > 演示视频 > 首屏媒体全面改版 > 关键词改写

• 带来的排名和转化提升：评价提速计划 > 关键词改写 > 徽章争取 > 首屏媒体全面改版 > 演示视频 > 付费市场广告

• 效率：关键词改写 > 首屏媒体全面改版 > 评价提速计划 > 演示视频 > 付费市场广告 > 徽章争取

• 默认阶梯：关键词改写——将工时投入到具有搜索权重的字段（名称、标语或副标题、搜索词），并以问题 4 中真实买家的用语为依据。首先查看市场平台自己的标题规范：经过基准测试的电商市场平台要求标题采用品牌优先的格式，这与移动 ASO 建议的关键词优先格式恰恰相反，因此不同市场平台之间不能照搬规范。应先确认市场平台实际会将哪些字段编入搜索索引，而不要假设列表中的所有文本都计入。

• 接下来是首屏媒体全面改版：采用独特、位于 UI 内并带有说明文字的截图，按主图 → 差异化亮点 → 最受欢迎的功能排序（这是标注为类比的排序方式，见 references/aso-analogy-toolkit.md），裁掉敏感数据，且不要在图片中嵌入价格或评价相关声明。一个经过基准测试的平台现在会直接拒绝重复图片和只有徽标的图片，因此在该平台上，这一步是合规要求，而非润色。

• 评价提速计划（菜单 3）是持续配套工作，而不是一次性的阶梯项目。它位于价值轴顶端，因为评价的新近度和速度是供应商官方声明与从业者共识都认可的排名影响因素，但其回报以季度计，而非以周计。

• 演示视频受平台限制，并非普遍适用。 如果市场平台醒目展示视频，就按照该平台的时长上限添加视频：在经过基准测试且限制最严格的平台上，展示 30 秒的功能证明；在限制最宽松的平台上，则展示两到三分钟的宣传视频。如果视频在平台上的位置不显眼，就跳过——类比数据表明，只有当展示位会自动播放视频时，视频才能提高转化率。

• 付费市场搜索广告：如果平台提供此类广告，可在发布完内容相关阶梯项目后、有机安装量增长停滞时，作为限时加速手段；绝不能将其作为长期补贴——付费安装会掩盖列表本身的转化效果。

• 受限选项：徽章争取——这需要数周工程投入、一个季度或更长的流程工作，以及平台根据认证标准进行审核，同时它也是菜单中最有力的信任资产。但在每轮效率比较中，它都排在末位；只有在市场平台官方确认徽章会影响排名（经过基准测试的平台中，只有一个平台以书面形式确认），或者问题 6 表明企业采购以获得徽章为门槛时，才应提高其优先级。徽章候选项应按已确认的效果排序，而非按感知到的声望排序；并且应将强制性安全审查视为必须通过的列表准入门槛，而非需要争取的徽章。

• 删除，而非降级：以任何形式购买安装量或评价。 它不属于这套阶梯中的任何一级——删除它的原因，以及试图这样做的 Partner 账户会有什么后果，请参见菜单 3。

3. 评价增长速度

近期评价和增长速度比累计总数更重要：有一条经过充分佐证的从业者说法指出，某应用在 30 天内获得 50 条评价，会胜过一款已有 500 条静态评价的应用。请将其标为推断，但仍应按这一趋势为准，因为唯一一条来自供应商官方的评价声明也与之相符。没有评价系统的市场平台，完全跳过这一部分。

按每小时外联投入带来的已发布评价数量排序：

• 投入（降序）：里程碑时机的个性化邀约 > 生命周期电子邮件活动 > 负面评价互动 > 支持服务后的提示 > 平台自动触发
• 获得的评价数量：平台自动触发 > 生命周期电子邮件活动 > 支持服务后的提示 > 里程碑时机的个性化邀约 > 负面评价互动
• 合规成本，按触发的政策审查及所需承担的可逆性计算：生命周期电子邮件活动 > 里程碑时机的个性化邀约 > 支持服务后的提示 > 平台自动触发 == 负面评价互动
• 效率：平台自动触发 > 支持服务后的提示 > 生命周期电子邮件活动 > 里程碑时机的个性化邀约 > 负面评价互动

合规成本的 == 成立，是因为这两种策略完全在平台自身运营的界面中进行：由平台发送的邀约，以及通过平台自身机制发布的公开回复。两者都不会偏向特定对象或附带激励——它们同样不会增加曝光风险，而不只是成本都低。

• 默认阶梯：启用平台自身运营的所有触发方式，以及支持服务后的邀约。

  • 启用平台提供的自动邀约功能。
  • 使用平台提供的可复制评价链接。
  • 如果平台提供评价 API，则通过该 API 引导产品内提示。
  • 在积极的支持互动后发出邀约，这是转化率最高且获准的时机：在自然停顿时提示，绝不阻碍用户工作流，并提供退出后续邀约的选项。

• 面向活跃用户的生命周期电子邮件活动，从业者报告的转化率为 5–10%。邀约应无条件发给所有符合条件的用户——其合规成本正是只向满意用户邀约的风险，有多个平台将此视为操纵。

• 受冷落的选项：里程碑时机的个性化邀约——由指定人员在用户取得成功的里程碑时，向特定客户发出邀约。每小时获得的评价最少，但评价质量最高；也是唯一一种能够稳定获得详细、可信评价的策略，而对评价者可信度加权的平台会优先展示这类评价。当市场平台重视评价者可信度，或评价基数较小、每条评价仍能影响平均分时，应优先采用此策略。

• 负面评价互动：对每条评价公开回复一次，力求解决问题并促使用户修改评价。能获得的评价数量不多——但每位未来的评估者都会看到回复，而且有一家平台的官方合作伙伴指南明确对此进行了指导。

• 已删除，而非降级：激励评价——通过产品或任何外部渠道，以折扣、礼品卡、解锁功能或限制功能为条件换取评价。经过评估的五个平台一致禁止此类行为；其中一家公布了逐级加重的处罚措施，最终将终止合作伙伴账户，并会记录在案地批量下架评价；与不可信评价者相关的真实评价也可能连带被取消发布。不能将其放在选项列表的末尾，因为“这次发布才这么做”每逢增长停滞时都会再次出现。

  同样应删除：来自自家团队的评价，以及与其他供应商互换评价——评价者声明系统现在能识别这两种行为。

失败模式

• 激励用户评价。 最严重的后果不是评价被移除，而是 Partner 账户被终止、应用被下架。解决方法：删除菜单 3 中的相关内容；只使用获准的触发方式。
• 把推断出的排名因素当成已确认事实。 副标题权重约为 80% 的说法及类似结论都只是从业者估计；如果据此向管理层作出承诺，算法一变就会失败。解决方法：为每项说法标注其来源等级，并承诺方向而非幅度。
• 把移动应用商店优化（ASO）的数据当作 B2B 事实。 评分上升带来转化率提升 89% 的数据，以及截图滚动统计数据，都来自消费类应用商店。可借鉴其结构，数据仅作类比。解决方法：遵循 references/aso-analogy-toolkit.md 中的标注规范。
• 把数据匮乏型市场当成数据驱动型市场来运营。 花数周时间计划 A/B 测试，却没有可供分析的漏斗。解决方法：先回答问题 2；在数据匮乏的平台上，一次性完成内容撰写，引导外部流量，并自行追踪安装量。
• 照搬某个市场的标题惯例到另一个市场。 生产环境中既有品牌优先，也有关键词优先的惯例；选错会浪费权重最高的字段。解决方法：改写前，先查看目标市场自身的指南。
• 任由商品信息页过时。 运营人员会降低过时商品信息页的排名或对其进行标记；至少有一个平台会将更新时间的新近程度本身作为新鲜度信号。解决方法：按照工作流阶段 5 的要求，每 30-60 天刷新一次，并指定负责人。
• 优化商品信息页，却任由留存率下滑。 在有佐证的平台上，卸载率会对排名产生负面影响；至少有两个平台会独立监控卸载率。更好的商品信息页无法抵消用户流失——先解决产品体验上的差距，否则商品信息页带来的新安装用户最终会变成拖累排名的卸载用户。

衡量

先设定计划门槛——由自己设定并明确标注，而非外部认证标准。持续迭代，直到以下五项全部达标：

1. 已启用平台提供的所有原生分析界面；或者已明确将该市场归类为数据匮乏型，并建立自行维护的安装记录表。
2. 每个已编入索引的字段都包含问题 4 中的买家用语，并遵循目标市场自身文档说明的标题惯例。
3. 画廊中的前三项素材各不相同，展示应用内界面并配有说明文字；计划中的每项评价请求都对应一种获准的触发方式。
4. 计划中的每项排名相关说法都带有来源标签（供应商官方信息、有佐证的推断、单一来源推断、类比）。
5. 已制定每 30-60 天一次的刷新周期，并指定负责人。

上线后的运营 KPI：

• 各市场的商品信息页浏览量及浏览到安装的转化率。
• 关键词覆盖度（已编入索引的字段中包含的词），与关键词表现（商品信息页实际获得排名的词）分开追踪——有覆盖度却没有排名，说明需要重新审视改写内容。
• 过去 90 天的评价增长速度及平均评分。
• 卸载率或流失率。
• 相对于认证标准的徽章进度。

对于类似 A/B 测试的前后对比，references/aso-analogy-toolkit.md 中源自类比的显著性阈值可作为合理的通用规则：将低于 2% 的提升视为噪声。

如果你的测试框架支持持久化记忆，请按市场分别记录，以便下一轮优化继承这些信息，而无需重新询问：

• 数据丰富型/数据匮乏型的分类。
• 选定的阶梯级别及促成选择的因素。
• 目标关键词集合及每个词当前的排名。
• 正在使用的获准评价触发方式。
• 刷新周期的负责人和日期。

调用示例

• “我们的 Salesforce AppExchange 列表页流量还不错，但几乎没有安装量——审查一下，告诉我应该先改什么。”
• “我们将在六周后登陆 Atlassian Marketplace。制定列表页计划：关键词、截图、视频，以及如何在不违反规则的前提下获得最初的 20 条评价。”
• “我们已在 Shopify App Store 上架一年，排名正在下滑。制定一套持续开展的计划，守住我们的排名。”

参考资料

• references/marketplace-lever-benchmarks.md - 五大市场的对比：按已确认与推断分类的排名因素、原生分析工具、评价征集机制及其执行力度、提交者优化时受限的列表字段、徽章计划及其已确认效果，以及从业者生态图谱。
• references/aso-analogy-toolkit.md - 经隔离并标注的移动 ASO 借鉴经验：趋同的审核维度、品牌成熟度分级、图库排序框架、转化基准和 A/B 测试显著性阈值——可迁移的是结构，不能迁移的是数字。

另请参阅同一合集中的：

• samber/developer-platform-skills@app-marketplace-listing-standards - 视角相反的姊妹技能：由运营者编写列表规则手册。该技能设计的评分标准，就是本技能需要在其中优化的约束条件；请先阅读目标市场发布的规则版本。
• samber/developer-platform-skills@app-marketplace-launch-marketing - 运营者如何设计精选推荐、重点展示和付费推广计划；了解这些计划的设计方式，才能争取精选推荐，而不是坐等机会。
• samber/developer-platform-skills@integration-partnership-strategy - 哪些生态系统值得投入资源上架；如果市场组合本身尚未确定，请先运行此技能。
• samber/developer-platform-skills@etl-connector-strategy - 面向 ETL/ELT 平台的同类提交者视角，认证和连接器维护在此类平台的列表工作中占主导地位。
• samber/developer-platform-skills@zapier-integration-playbook - Zapier 专属攻略：在该平台上的触发器设计、评价检查、测试版、模板、嵌入和版本管理。
• samber/developer-platform-skills@salesforce-appexchange-playbook - AppExchange 专属攻略：本技能优化的列表页背后的列表类型、托管式打包、安全审查、PADA 和付款路径。
• samber/developer-platform-skills@slack-app-directory-playbook - Slack 专属攻略：本技能优化的列表页背后的安装门槛、权限范围说明、审核阶段和下架规则。