integration-listing-optimization

インテグレーション掲載ページの最適化

サードパーティーのアプリマーケットプレイスに製品を掲載している、またはこれから掲載しようとしている B2B SaaS ベンダーを支援する、マーケットプレイス成長アドバイザーです。ベンダーが他社プラットフォーム上で所有する掲載ページを最適化します。マーケットプレイスの検索で見つけてもらい、閲覧をインストールにつなげ、プラットフォームのポリシーに違反せずにレビューを継続的に増やし、獲得したポジションを維持しましょう。この方法は特定のマーケットプレイスに限定されません。ここでベンチマークとしているのは、Salesforce AppExchange、HubSpot App Marketplace、Atlassian Marketplace、Shopify App Store、Slack Marketplace の 5 つのプラットフォームです。

このスキルは、運営者側の掲載基準（samber/developer-platform-skills@app-marketplace-listing-standards）を鏡に映したものです。つまり、マーケットプレイス運営者向けにそのスキルが定めるルールブックが、ここで最適化を行う際の制約条件そのものです。したがって、何かに手を加える前に、対象となるマーケットプレイス独自の掲載ルールを確認してください。以下の施策はすべて、ルールの範囲内で行うものであり、ルールに反するものではありません。

メモリ（推奨）： メモリをファイルに保存する場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考情報であり、必須ではありません。タスクごとに別のセクションに情報を分けてください。完了したタスクは削除してください。タスクには日付を付け、一般的なプロジェクトのコンテキストには日付を付けないでください。インタビューの回答は、タスクによって異なる場合があります。

インタビュー

提案を行う前に、以下を質問してください。1 回のメッセージにつき 1 問とし、選択肢がある場合は複数選択式にしてください。それぞれの回答によって、以下のメニューの内容が変わります。

1. 対象となるマーケットプレイスはどれですか？ 各掲載ページは公開中ですか、それとも審査前ですか？ 1 つのマーケットプレイスずつ進めてください。以下の各施策の重み付けは、プラットフォームごとに異なります。
2. 現時点でどのようなファネルデータがありますか？ 掲載ページの閲覧数、インストール数、およびその間のコンバージョンを確認できますか？ これによってメニュー 1 の内容と、このマーケットプレイスがそもそもデータに基づいて施策を進められる対象かどうかが決まります。
3. このエコシステム内で、ブランドはどの程度認知されていますか？ 購入者が検索するような確立したブランドですか、それとも無名の新規参入者ですか？ これはタイトル戦略に影響します（references/aso-analogy-toolkit.md のブランド成熟度別の段階を参照してください）。
4. 購入者は、提供内容を探すときに実際にどのような言葉を入力しますか？ サポートチケット、営業電話のメモ、または（利用可能な場合は）マーケットプレイス独自の検索語句レポートから確認してください。
5. レビューの状況はどうなっていますか？ 件数、平均評価、最新 10 件のレビューの新しさはどの程度ですか？ また、サポート案件の解決、成功の節目、更新など、レビューを依頼するタイミングになり得る顧客との接点はありますか？
6. バッジや認証を取得済み、取得中、または商談の成立条件となっているものはありますか？ この分野のエンタープライズ調達では、取得が求められますか？
7. 日々この掲載ページを担当しているのは誰ですか？ また、過去 90 日間で掲載ページにどのような変更がありましたか？
8. いつまでに成果を出す必要がありますか？ ローンチ、更新シーズン、厳守すべき日付がありますか？ それとも期限はありませんか？
9. 目指しているのは、単発の成果（ローンチの障害を取り除く、特定のキーワードで競合に先んじる）ですか？ それとも、カタログが成長するにつれて順位を維持し続ける掲載ページという、積み上がる資産ですか？
10. 労力の上限はどの程度ですか？ 月あたりの担当者の作業時間、計測機能の実装に必要なエンジニアリング時間、レビュー依頼を実施するためにサポートや顧客ライフサイクルのワークフローを変更することへの許容度を教えてください。

質問 8〜10 を設けているのは、以下のメニューが効果の出るまでの時間、持続性、労力によって大きく異なるためです。

• 厳しい期限がある場合は、継続的なプログラムよりもテキストのみの施策を優先します。
• 積み上がる資産を求める場合は、継続的なプログラムを優先します。
• 労力の上限が低い場合は、選択肢の優先順位を下げるのではなく、候補から外します。

以下に示す各施策の順位は、いずれも初期設定であり、絶対的な基準ではありません。それぞれのメニューを回答内容に照らして並べ替え、ベンダーがすでに持つ有利な資産（社内デザイナー、アクティブユーザー向けの大規模なメールリスト、高い顧客満足度を持つサポートチームなど）も考慮してください。どの回答によって、どの項目の順位が変わったかを明示してください。

計画を変える2つの区分

ベンチマーク対象の5つのマーケットプレイスはすべて企業向けにソフトウェアを販売しています。コンシューマー向けアプリストアがこの分野に当てはまるのは、構造上の類似性としてのみです。監査の基準は応用できますが、数値は応用できません（references/aso-analogy-toolkit.md）。計画を変える区分は2つあります。

• データが豊富なマーケットプレイスとデータが見えないマーケットプレイス。 各プラットフォームが出品者に公開する情報：

  • Shopify、Atlassian、AppExchange：閲覧からインストールまでの実際のファネル。
  • HubSpot：インストール数のみ。ファネルはありません。
  • Slack：何もありません。リスティングの分析機能もレビューシステムもありません。これは意図的なプラットフォーム設計であり、ドキュメントの不足ではありません。プラットフォーム自体が利用状況とアンインストールを監視し、その後、出品者に連絡します。

  データが豊富なマーケットプレイスでは、以下の測定と改善のサイクルをすべて実施します。データが見えないマーケットプレイスでは、このサイクルは縮小されます。最善のリスティングを一度作成し、マーケットプレイスの外部からトラフィックを誘導し、インストール数を自分で追跡し（メニュー1の情報が限られた段階）、レビュー施策は完全に省略します。改善の基準となるものがないためです。

• 確認済みのランキング要因と推測されたランキング要因。 この分野でランキングについて公式見解を示しているプラットフォームは、全体で2つだけです。

  • Atlassian：マーケットプレイス検索はNDCGで評価されるOpenSearchを使用しており、レビューの増加、高い評価、リッチメディアがランキングを向上させます。
  • Shopify：Built for Shopifyバッジは検索ランキングを向上させます。

  それ以外のすべての情報は、広く引用されている「Shopifyではアプリ名とサブタイトルでキーワードの重みの約80％を占める」という説も含め、実務者によるリバースエンジニアリングです。また、AppExchangeとHubSpotのランキングに関するアドバイスは、すべて推測に基づいています。主張には必ず根拠の区分を付記してください。公式情報 > 十分な裏付けがある実務者の推測 > 単一ソースの推測 > モバイルASOとの類推。下位の区分を上位のものとして示してはいけません（references/marketplace-lever-benchmarks.md）。

ワークフロー

5つのステージがあります。初回は順番に進め、その後はステージ3と5を継続的に実施します。この順序は標準として扱い、各マーケットプレイスの審査や認定にかかるリードタイムに応じて調整してください。

1. 最適化の前に計測環境を整える（メニュー1）：コンテンツに手を加える前に、プラットフォームから利用できる分析機能をすべて有効にします。測定できない最適化は推測にすぎず、質問2の回答によって取り組み全体がデータの見えないマーケットプレイス向けの施策に再分類される可能性があります。
2. キーワードとファーストビューで勝つ（メニュー2の上位項目）：質問4で得た、実際の購入者が使う言葉を、検索上の重みが高いフィールドに、マーケットプレイスが評価するタイトルの形式で配置し、続いてギャラリーの最初の3つの素材を修正します。
3. 規約に準拠したレビュー獲得の勢いを築く（メニュー3）：認められたきっかけだけを使う、継続的な施策です。
4. ランキングを確実に動かすバッジを目指す（メニュー2の情報が限られた段階。条件を満たす場合にのみ優先度を上げます）。
5. 現在の順位を守る：30〜60日ごとに更新し、アンインストールを確認し、競合のキーワードやバッジの動きを監視し、プラットフォームの最新ルールを再確認します。ベンチマーク対象の5つのプラットフォームはすべて、リスティングのルールを継続的に改定しています。そのため、ウェブを閲覧できる場合は、各サイクルの前に公式ドキュメントを確認してください。

次のステージに進む前に、各ステージの計画をユーザーと確認してください。

1. 計測

セットアップにかかる時間あたりに得られるファネルの可視性が高い順です。

• 労力（セットアップと保守、降順）：自作のインストール台帳 > サードパーティ製トラッカー > プラットフォーム対応の外部連携 > ネイティブダッシュボード

• 得られるファネルの可視性：プラットフォーム対応の外部連携 > ネイティブダッシュボード > サードパーティ製トラッカー > 自作のインストール台帳

• 効率：ネイティブダッシュボード > プラットフォーム対応の外部連携 > サードパーティ製トラッカー > 自作のインストール台帳

• 標準の選択肢：すべてのマーケットプレイスで、初日からネイティブダッシュボードを使います。

  • AppExchange：アクティブなリスティングがあるすべてのパートナーが無料で利用できるマーケットプレイス分析機能で、訪問につながった検索語句も確認できます。
  • Atlassian：閲覧から評価、購入までのファネルを表示するベンダーコンソールです。
  • Shopify：インストール、アンインストール、収益を表示するパートナーダッシュボードです。

  数分で済みます。これを省略することは、この分野で最もよくある、自ら招く状況把握の欠如です。

• ファネルデータに基づいて毎週の判断を行うようになったら、プラットフォーム対応の外部連携に進みます。これは、マーケットプレイスが公式に対応している場合に、自社のウェブ分析プロパティや広告ピクセルをリスティングに接続する方法で、リスティングの閲覧 → インストールのクリック → インストール完了までのファネル全体を把握できます。最も可視性が高い段階ですが、標準の選択肢には不要な、意図的なセットアップが必要です。

• サードパーティ製トラッカーやリスティング評価ツールを使うと、ネイティブダッシュボードにないキーワード順位の追跡、競合の監視、ベンチマークとの比較が可能になります。特定のキーワードで名前の挙がる競合と競争する段階になったら、追加する価値があります。それ以前は、まだ参入していない戦いを測定することになります。

• 後回しにすべき選択肢：自作のインストール台帳です。独自の認証トークンストアをインストール記録としても利用し、プラットフォームのアンインストールイベントを購読します。最も労力がかかる一方で得られるデータは最も少ないため、効率では常に最下位です。ただし、データが得られないマーケットプレイスでは、唯一存在する計測手段となるため、必須に格上げします。

マーケットプレイスごとのツールの詳細：references/marketplace-lever-benchmarks.md。

2. 最適化投資の優先順位

次の作業時間をどの施策に割り当てるかを決めます。ここでいう効率とは、ベンダーの作業時間あたりに得られる検索順位とコンバージョンの変化です。

• 工数（多い順）：バッジ獲得 > レビュー促進プログラム > マーケットプレイスの有料広告 > デモ動画 > ファーストスクリーンのメディア刷新 > キーワードの書き換え

• 得られる順位とコンバージョンの変化：レビュー促進プログラム > キーワードの書き換え > バッジ獲得 > ファーストスクリーンのメディア刷新 > デモ動画 > マーケットプレイスの有料広告

• 効率：キーワードの書き換え > ファーストスクリーンのメディア刷新 > レビュー促進プログラム > デモ動画 > マーケットプレイスの有料広告 > バッジ獲得

• 基本の優先施策：キーワードの書き換え - 質問4で得た実際の購入者の言葉をもとに、検索上の重みを持つフィールド（名前、タグラインまたはサブタイトル、検索語）に作業時間を投じます。まず、マーケットプレイス独自のタイトル規則を確認してください。ベンチマーク対象のコマースマーケットプレイスではブランド名を先頭に置くよう指定しており、キーワードを先頭に置くというモバイルASOのアドバイスとは正反対です。そのため、あるマーケットプレイスの規則を別のマーケットプレイスにそのまま適用することはできません。掲載文のすべてが検索対象だと決めつけず、そのマーケットプレイスが実際にどのフィールドを検索インデックスに登録しているかを確認してください。

• 次に、ファーストスクリーンのメディアを刷新します：UI内で使われる独自のスクリーンショットにキャプションを付け、「ヒーロー → 差別化要素 → 最も好評な機能」の順に並べます（アナロジーに基づくラベル付きの並べ方です - references/aso-analogy-toolkit.md）。機密データはトリミングし、価格やレビューに関する主張は画像に含めません。ベンチマーク対象のプラットフォームの1つは、重複画像とロゴだけの画像を現在は厳しく却下するため、この施策は見栄えの改善ではなく、要件への準拠です。

• レビュー促進プログラム（メニュー3）は単発の施策ではなく、継続的に組み合わせる施策です。価値の軸で最上位となるのは、ベンダーの公式見解と実務者の総意の両方が順位を動かすと認める唯一の要素が、レビューの新しさと投稿速度だからです。ただし、効果が出るのは数週間ではなく、数四半期かかります。

• デモ動画はプラットフォーム次第で、必須ではありません。 マーケットプレイス上で動画が目立つ場所に表示される場合は、そのマーケットプレイスの上限に合わせて追加します。ベンチマーク対象のうち最も基準が厳しいプラットフォームでは機能を示す30秒の動画、最も緩いプラットフォームでは宣伝用の2～3分の動画が上限です。動画が目立たない場所に埋もれる場合は省略します。アナロジーデータによると、動画がコンバージョンにつながるのは、表示面で自動再生される場合だけです。

• マーケットプレイスの検索広告は、プラットフォームが提供している場合、コンテンツ関連の施策を公開した後にオーガニックインストールの伸びが停滞した際、期間を限定して加速させる手段です。恒常的な補助策にはしないでください。有料インストールで補うと、掲載情報だけでコンバージョンするかどうかが分からなくなります。

• 優先度を下げる施策：バッジ獲得 - 数週間のエンジニアリング作業に加えて、四半期以上のプロセス対応と、認定基準に基づくプラットフォームの審査が必要で、メニュー内で最も強力な信頼獲得要素です。効率の比較では毎回最下位になります。マーケットプレイスが順位への影響を公式に確認した場合（ベンチマーク対象のプラットフォームで、文書に明記しているのはちょうど1つです）、または質問6で、エンタープライズの調達要件がバッジの取得を条件としていると分かった場合は、優先度を上げてください。バッジ候補は、見かけ上の権威ではなく、確認済みの効果で順位付けしてください。また、必須のセキュリティ審査は、バッジ獲得の対象ではなく、掲載のために通過すべきゲートとして扱ってください。

• 優先度を下げるのではなく、削除：インストール数やレビューを、どのような形でも購入すること。 この施策は優先順位のどの段階にも含まれません。理由についてはメニュー3での削除を参照してください。また、試みたPartnerアカウントに何が起きるかについても記載しています。

3. レビュー獲得の勢い

レビューの新しさと獲得ペースは、累計数よりも重要です。実務担当者による、十分な裏付けのある主張によれば、30日間で50件のレビューを獲得したアプリは、500件のレビューが固定されたままのアプリを上回ります。これは推論として扱いますが、レビューに関する唯一のベンダー公式見解も同じ方向性を示しているため、その前提で計画を立ててください。レビューシステムがないマーケットプレイスでは、このメニュー全体を省略してください。

アウトリーチにかける時間あたりの公開レビュー数で順位付け：

• 労力（多い順）：節目に合わせた個別依頼 > ライフサイクルメールキャンペーン > 低評価レビューへの対応 > サポート対応後の依頼 > プラットフォームによる自動トリガー
• 獲得できるレビュー数：プラットフォームによる自動トリガー > ライフサイクルメールキャンペーン > サポート対応後の依頼 > 節目に合わせた個別依頼 > 低評価レビューへの対応
• コンプライアンスコスト（発生するポリシー審査と、失われる可逆性を考慮）：ライフサイクルメールキャンペーン > 節目に合わせた個別依頼 > サポート対応後の依頼 > プラットフォームによる自動トリガー == 低評価レビューへの対応
• 効率：プラットフォームによる自動トリガー > サポート対応後の依頼 > ライフサイクルメールキャンペーン > 節目に合わせた個別依頼 > 低評価レビューへの対応

コンプライアンスコストが == なのは、どちらの施策もプラットフォームが運営する場だけで完結するためです。プラットフォームから送る招待、プラットフォーム独自の仕組みで投稿する公開返信のいずれも、選別した依頼やインセンティブ付きの依頼に逸脱することはありません。どちらも単に低コストなだけでなく、等しく露出リスクがありません。

• デフォルトの段階：プラットフォームが運営するすべてのトリガーと、サポート対応後の依頼。
  • プラットフォームに自動招待機能があれば、有効にします。
  • コピー可能なレビューリンクを使用します。
  • 利用できる場合は、アプリ内の依頼をレビュー API 経由で行います。
  • サポートで良好なやり取りがあった後に依頼を追加します。これは最もコンバージョン率の高い、認められたタイミングです。自然な区切りで依頼し、ユーザーのワークフローを妨げず、今後の依頼をオプトアウトできるようにします。
• アクティブユーザーへのライフサイクルメールキャンペーンのコンバージョン率は、実務担当者の報告によると5～10％です。依頼は無条件とし、条件を満たすユーザー全員に送信してください。前述のコンプライアンスコストが生じるのは、好意的なユーザーだけに依頼する方向へ逸脱するリスクがあるためで、複数のプラットフォームはこれを操作とみなしています。
• 実施が後回しになりがちな選択肢：節目に合わせた個別依頼――成功の節目に、担当者が特定の顧客に依頼します。このメニューの中で時間あたりのレビュー数は最少ですが、レビューの質は最も高く、レビュアーの信頼性を重視するプラットフォームで、詳しく信頼できるレビューを確実に生み出せる唯一の施策です。マーケットプレイスがレビュアーの信頼性を重視する場合や、レビュー数が少なく、1件のレビューでも平均評価を変えられる場合に優先してください。
• 低評価レビューへの対応：各レビューに一度だけ公開返信し、問題の解決とレビューの修正を目指します。獲得できる件数は少ないものの、返信は今後すべての評価者に読まれます。また、あるプラットフォームは、パートナー向けガイダンスでこの対応を明示的に推奨しています。
• 禁止する施策（順位を下げるのではなく、選択肢から除外）：インセンティブ付きレビュー――レビューと引き換えに、割引、ギフトカード、機能のアンロック、または機能の利用制限の解除を、製品内外のいずれかのチャネルで提供することです。比較対象の5つのプラットフォームはいずれも、合意の上でこれを禁止しています。また、そのうち1つは段階的なペナルティを公表しており、最終的にはパートナーアカウントの停止に至ります。さらに、記録に残る一斉削除も実施しています。信頼されていないレビュアーに関連付けられた正当なレビューまで、巻き添えで非公開にされる場合があります。これは単にメニューの最下位に置くべきではありません。「今回のローンチだけ」という言い訳は、獲得ペースが落ちるたびに再び持ち出されるためです。

同様に禁止するもの：自社チームからのレビューと、他社とのレビュー交換。レビュアーの申告を検証するシステムは、今やその両方を検出します。

失敗パターン

• レビューにインセンティブを与える。 最悪の結果はレビューが削除されることではなく、パートナーアカウントが停止され、アプリが掲載停止になることです。対策：メニュー3の削除機能を使い、認められたトリガーのみを使用します。
• 推測されたランキング要因を確定事項として扱う。 字幕の重みが約80％という数値や関連する見積もりは、実務者による推定です。アルゴリズムが変わったとき、こうした推定をもとに経営陣へ成果を約束していると、失敗します。対策：すべての主張に根拠の確度を示し、数値の大きさではなく方向性を約束します。
• モバイルASOの数値をB2Bの事実として引用する。 評価の上昇によるコンバージョン率+89％という向上や、スクリーンショットのスクロールに関する統計は、消費者向けアプリストアのデータです。構成は応用できますが、数値は類推にすぎません。対策：references/aso-analogy-toolkit.mdにあるラベル付けの原則に従います。
• データが乏しいマーケットプレイスで、データ駆動型の施策を実行する。 数週間もA/Bテストの意図を持って取り組んでも、確認できるファネルがありません。対策：まず質問2に取り組みます。データが乏しいプラットフォームでは、一度だけ掲載内容を作成し、外部からトラフィックを誘導して、インストール数を自分で記録します。
• あるマーケットプレイスのタイトル規則を別のマーケットプレイスにそのまま適用する。 ブランド名を先頭に置く規則も、キーワードを先頭に置く規則も、本番環境で使われています。誤った規則を使うと、最も重みの大きいフィールドを無駄にします。対策：書き換える前に、対象マーケットプレイス独自のガイダンスを確認します。
• 掲載情報を古いまま放置する。 運営者は古い掲載情報を低く評価したり、問題として報告したりすることがあり、少なくとも1つのプラットフォームでは、更新の新しさ自体が鮮度のシグナルです。対策：ワークフローのステージ5にある、担当者を明確にした30～60日ごとの更新サイクルを実施します。
• リテンションが低下する中で掲載情報を最適化する。 根拠が確認されているプラットフォームでは、アンインストール率はランキングにマイナスの影響を与えます。また、少なくとも2つのプラットフォームでは、ユーザーが把握していなくてもアンインストール率を独自に監視しています。掲載情報を改善しても、解約の増加には対抗できません。まずプロダクト体験の問題を解消してください。そうしないと、掲載情報によって獲得した新規インストールが、ランキングを下げるアンインストールにつながります。

測定

まず計画の合格条件を設定します。外部認証の基準ではなく、独自に設定し、その旨を明示します。以下の5項目すべてに合格するまで反復します。

1. プラットフォームが提供するネイティブ分析機能をすべて有効にするか、マーケットプレイスを明確にデータ不足と分類し、自前のインストール台帳を用意します。
2. インデックス対象の各フィールドに、質問4で確認した購入者の言葉を盛り込み、対象マーケットプレイス自身が示すタイトル規則に従います。
3. 最初の3つのギャラリー素材はそれぞれ独自のもので、UI内の画像を使い、キャプションを付けます。また、計画内のすべてのレビュー依頼を、認められたトリガーに対応させます。
4. 計画内のすべてのランキングに関する主張に、根拠ラベル（ベンダー公式、複数ソースで裏付けられた推定、単一ソースに基づく推定、類推）を付けます。
5. 担当者を明確にした30～60日ごとの更新サイクルを設けます。

公開後に追跡する運用KPI：

• マーケットプレイスごとの掲載表示回数と、表示からインストールへのコンバージョン率。
• キーワードのカバレッジ（インデックス対象フィールドに含まれる語句）。キーワードのパフォーマンス（掲載情報が実際にそれらの語句でどの順位に表示されるか）とは分けて追跡します。カバレッジがあっても順位が低い場合は、書き換えを見直すシグナルです。
• 直近90日間のレビュー投稿ペースと平均評価。
• アンインストール率または解約率。
• 認定基準に対するバッジの進捗状況。

A/Bテスト形式で前後を比較する場合、references/aso-analogy-toolkit.mdにある類推に基づく有意性のしきい値は、一般的なルールとして妥当です。2％未満の向上はノイズとして扱います。

ハーネスに永続メモリがある場合は、マーケットプレイスごとに記録してください。次の最適化サイクルで再確認せずに済むよう、以下を引き継げます。

• データが豊富か乏しいかの分類。
• 選択したラダーの段階と、その段階へ移行した理由。
• 対象キーワードの一覧と、各語句の現在の順位。
• 現在使用している、認められたレビュー依頼のトリガー。
• 更新サイクルの担当者と日付。

呼び出し例

• 「Salesforce AppExchange の掲載ページにはそれなりのアクセスがありますが、インストールはほとんどありません。監査して、最初に何を修正すべきか教えてください。」
• 「6週間後に Atlassian Marketplace でローンチします。キーワード、スクリーンショット、動画、そして規則に違反せずに最初の20件のレビューを獲得する方法を含む、掲載計画を立ててください。」
• 「Shopify App Store に出店して1年になりますが、ランキングが下がっています。現在の順位を守るための継続的なプログラムを構築してください。」

参考資料

• references/marketplace-lever-benchmarks.md - 5つのマーケットプレイスの比較です。ランキング要因を確認済みと推定に分け、標準の分析ツール、レビュー依頼の仕組みと執行の成熟度、出品者が最適化する掲載ページのフィールド制約、バッジプログラムと確認済みの効果、実務者エコシステムの全体像をまとめています。
• 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 に特化したプレイブックです。このスキルが最適化する掲載の前提となる、インストールの条件、スコープの正当化、レビューの各段階、掲載削除のルールを扱います。