Chrome Extension Kit

ARTICLE

Polar.shで商品とBenefitを設計する

Polar.shの商品と複数の開発者向けBenefitを表す図。

Polar.shで販売を始めるとき、最初に決めるべきなのは「何を売るか」ではなく「購入者にどの権利を渡すか」です。 この順番で考えると、ProductとBenefitの関係が整理しやすくなります。

Productは価格が付いた販売単位です。 一回払いのテンプレートアクセス、月額のProプラン、年額のTeamプランなどがProductになります。 Benefitは、そのProductを購入したユーザーに与える権利です。 たとえば、ライセンスキー、GitHubリポジトリアクセス、ファイルダウンロードなどがBenefitです。

有料Chrome拡張なら、まず無料機能と有料機能を分けます。 無料状態では設定画面や一部の機能だけを使えるようにし、有料状態では同期、エクスポート、自動化、チーム向け機能などを開放する、といった設計です。 この「有料状態」を拡張内で判断するために、Polar.shの購入情報やBenefit情報をサーバー側で検証します。

ライセンスキーBenefitを使う場合は、次の項目を決めます。

  • キーの表示形式やprefixをどうするか。
  • 有効期限を設けるか。
  • 何台まで有効化できるか。
  • 利用回数や使用量を制限するか。
  • 返金、解約、期限切れのときにどう扱うか。

GitHub Repository Access Benefitを使う場合は、購入者をどのリポジトリへ招待するかを決めます。 スターターキット、教材、サンプルコード、private docsのような商品では、このBenefitが実務的です。 購入後に手動で招待する運用もできますが、販売数が増えると招待漏れや削除漏れが起きやすくなります。 自動化できるBenefitは、できるだけ購入フローに組み込んだ方が運用が安定します。

ProductとBenefitは一対一で考える必要はありません。 同じBenefitを複数Productに紐づけたり、一つのProductに複数Benefitを付けたりできます。 たとえば、Lifetime ProductにはライセンスキーとGitHubアクセスを付け、Subscription Productにはライセンスキーだけを付ける、といった設計もできます。

Chrome Extension Kit で最初に扱いやすいのは、一回払いProductとライセンスキーBenefitの組み合わせです。 購入者はチェックアウトを完了し、ライセンスキーを受け取り、拡張のOptions pageでキーを入力します。 拡張はCloudflare Workerへ検証リクエストを送り、WorkerがPolar.shや自前DBの情報を見て有効状態を返します。

設計で迷ったら、管理画面の都合ではなくユーザーの購入後体験から逆算します。 購入直後に何が届くのか、どこで確認できるのか、端末を変えたときにどう復旧するのか、解約したらいつ使えなくなるのか。 この体験を言葉にできると、Polar.sh側のProductとBenefitも自然に決まります。

References