導入事例・男女のマッチングサービス
サブスク課金型マッチングサービスの開発
システム開発をリリースで終わらせず、課金率や顧客価値を改善し続ける事業基盤にできます。
- 対象
- 課金制の男女マッチングサービス
- 費用
- 600万円（税別）
- 公開日・更新日
- /
結果
- 決済 事業者を変えても作り直さない
- 集客時 流入が増えても取りこぼさない
- マッチング AIでお相手を薦める
- データ活用 課金データの数理分析で優良顧客を特定
- 売上 売上アップに貢献
課題
ユーザー同士をつなぐ課金制のマッチングサービスを、継続課金・自動マッチング・リアルタイムチャットまで含めて本番運用できる形で構築する必要がありました。広告やキャンペーンによる流入増に耐えることに加え、公開後も数字を見ながら課金率を上げ続けることが求められました。
- クレジットカードの継続課金を安全に扱う決済連携
- 相性に基づく自動マッチングとリアルタイムなチャット・通知
- 流入増に耐える基盤と、課金導線での快適な表示性能
- 公開後にデータで課金率とUXを改善し続ける体制
作ったもの
決済・マッチング・チャットを別々の機能として並べず、どこが課金率を左右するかで要件を切り分けてから設計しました。外部決済は差し替え可能なドライバとして抽象化し、課金導線は表示速度が離脱に直結するためサーバーコンポーネント中心に構成。流入増に追従するインフラはコードで管理しています。公開後の改善に向けては、まずBigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築しました。統合にあたって、アプリDBとGA4にある同じ人のデータを1人分にまとめました。重複と表記のゆれを直し、欠けた値や誤った値も整えています。約11名体制で、決済からインフラ、データ基盤・分析まで一貫して担当しています。
- LaravelとGraphQL（Lighthouse）でバックエンドを構築し、Next.jsで利用者向けの画面を実装
- 独自の決済部分をTypeScript・DynamoDBで実装。外部決済ゲートウェイを差し替え可能なドライバに抽象化し、トークン化・継続課金・エラー処理まで対応
- ルールで候補を絞り込み、AIでお相手を薦めるレコメンド機能を実装
- 流入増に備えたECSオートスケール構成をIaC化し、サーバーコンポーネント中心の構成で課金導線の表示性能を確保
- BigQueryで購買データを分析し、最終的な顧客データ基盤（CDP）はDatabricks on AWS上に構築してアプリDB・GA4などを統合
- アプリDBとGA4にある同じ人のデータを1人分にまとめ、重複・表記のゆれ・欠けた値・誤った値を前処理で整理
- 課金データを数理分析して優良顧客層を特定し、LP・UGC・課金導線の改善に反映
結果
継続課金・自動マッチング・チャットを備えたサービスが本番で動いています。決済は事業者を差し替えられる形にしてあるので、手数料の見直しや乗り換えは決済部分の差し替えだけで済みます。広告で人が一気に流れ込む場面でも処理能力が自動で増えるため、いちばん申し込みが集まる瞬間に画面が重くなって取りこぼすことがありません。公開後は、BigQueryでの購買データ分析を経て、Databricks上にデータ基盤を整えました。Databricks上の課金データを数理分析して優良顧客層を特定し、LPと課金導線を改善して売上アップに貢献しました。作って終わりではなく、次に何を直せば課金率が動くかを数字で決められる状態です。決済、マッチング、インフラ、データ基盤を別々の会社に分けると要件の境目で話が止まりますが、一体の体制で要件定義から運用改善までを持っているため、その議論がそのまま実装につながります。
Beekleだからできたこと
技術要件ではなく、売上とKPIから「何を作るか」を決める
システム開発をリリースで終わらせず、課金率や顧客価値を改善し続ける事業基盤にできます。
課金率を左右する箇所から要件を切り分け、決済・マッチング・インフラを設計。公開後はBigQueryで購買データを分析し、Databricks上に構築したCDPで課金データを数理分析して優良顧客層を特定し、LP・UGC・課金導線の改善までつなげました。
Beekle自身が課金型プロダクトを運営し、決済、広告流入、インフラ、BigQueryとDatabricksでの顧客分析、LP・課金導線の改善まで当事者として回しています。そのため受託でも、仕様通りに機能を作るだけでなく、課金率や離脱に影響する箇所から要件を切り、リリース後の分析・改善まで含めて設計できます。
発注判断の裏側
このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。
- 比べたもの
- 機能を作るだけの開発会社
- 不安だったこと
- 公開後に課金率が上がらないことが不安でした。
- 決め手
- 決済・広告流入・顧客分析まで自分たちで回した経験があり、課金率に効くところから要件を切れることが決め手になりました。
よくある質問
- Q. サブスク課金型マッチングサービスの開発では、何が課題でしたか？
- A. ユーザー同士をつなぐ課金制のマッチングサービスを、継続課金・自動マッチング・リアルタイムチャットまで含めて本番運用できる形で構築する必要がありました。広告やキャンペーンによる流入増に耐えることに加え、公開後も数字を見ながら課金率を上げ続けることが求められました。
- Q. サブスク課金型マッチングサービスの開発の費用はいくらでしたか？
- A. 600万円（税別）です。
- Q. サブスク課金型マッチングサービスの開発で、何が変わりましたか？
- A. 継続課金・自動マッチング・チャットを備えたサービスが本番で動いています。決済は事業者を差し替えられる形にしてあるので、手数料の見直しや乗り換えは決済部分の差し替えだけで済みます。広告で人が一気に流れ込む場面でも処理能力が自動で増えるため、いちばん申し込みが集まる瞬間に画面が重くなって取りこぼすことがありません。公開後は、BigQueryでの購買データ分析を経て、Databricks上にデータ基盤を整えました。Databricks上の課金データを数理分析して優良顧客層を特定し、LPと課金導線を改善して売上アップに貢献しました。作って終わりではなく、次に何を直せば課金率が動くかを数字で決められる状態です。決済、マッチング、インフラ、データ基盤を別々の会社に分けると要件の境目で話が止まりますが、一体の体制で要件定義から運用改善までを持っているため、その議論がそのまま実装につながります。
- Q. ほかにどんな方法と比べましたか？
- A. 機能を作るだけの開発会社と比べました。
- Q. なぜBeekleに依頼したのですか？
- A. 決済・広告流入・顧客分析まで自分たちで回した経験があり、課金率に効くところから要件を切れることが決め手になりました。