Skip to content

methodology.md

Latest commit

 

History

History
123 lines (83 loc) · 5.73 KB

methodology.md

File metadata and controls

123 lines (83 loc) · 5.73 KB
Raw

値付けの考え方

price-dial が何を計算し、何を計算しないかの区分。

なぜ3層に分けるか

「料金シミュレータ」を1つの計算機として作ると壊れる。入力の確度が層ごとに 根本的に違うのに、出力が同じ見た目で出てくるから。

層 問い 入力の性質
1. 手取り この価格で、いくら手元に残るか **決定論。**ルールは全部公開されている
2. 採算 1件獲得にいくらまで払えるか 商品による。継続課金は実測が要る
3. 値付け そもそもいくらにするか 計算ではない

層1の出力は「¥1,250 の本は ¥787 になる」で、これは検算できる。 層2の出力は「SaaS の許容CACは ¥102,000」で、これは継続12ヶ月という仮定に 乗っている。顧客ゼロなら仮定を検証する手段がない。

同じ画面に並べると、片方が確定でもう片方が願望であることが見えなくなる。

層1 — 手取り

構造は全チャネルで同じ。 表示価格から控除が連鎖して手取りになる。

チャネル 控除 出典
KDP JP (Select 70%) 消費税 10/110 → 配信コスト ¥1/MB → ×70% KDP ヘルプ
KDP JP (35%) 消費税 10/110 → ×35%（配信コストは非控除） 同上
Stripe (JP国内 self-handle) 3.6% 要確認
Stripe Managed Payments base 3.5% + JP 3.6% + クロスボーダー 1.5% + 為替 1-2% 自社試算 2026-06-30・要再確認
GitHub Sponsors (個人) GitHub 手数料 0% + 通貨換算 未確認（community discussion 由来）

出典が「要確認」の行を計算に使うときは evidence を落とす。 数字を持っている ことと、その数字が正しいことは別。

日本の消費税が一番の罠

KDP は税込の希望小売価格を受け取り、税抜に直してからロイヤリティ率を掛ける。

1,250 × 0.70          = 875   ← 間違い。どのタイトルでも到達しない
1,250 × (100/110) × 0.70 − 配信 = 787

海外製の KDP 計算機はほぼ全部 USD 前提で、この 10/110 を持っていない。 日本の KDP ロイヤリティ計算は空き地になっている。

ルールには穴がある

日本では 10MB 以上の電子書籍は配信コストが引かれない。7.71MB なら ¥8 引かれ、 10.1MB なら ¥0。ファイルを重くすると手取りが増える帯がある。

こういう非直感的な境界を見つけて出すのが層1の実用価値で、 「だいたい7掛け」で済ませていると永久に気づかない。

層2 — 採算

粗利から LTV を出し、LTV / 3 を許容CACの目安にする。問題は LTV の出し方が 商品によって違うこと。

商品 LTV 確度
本 粗利（1回売り） 確定
買い切りアプリ 粗利 −（返金率 + サポートコスト） ほぼ確定
SaaS 月次粗利 × 継続月数 継続月数の実測が要る
GitHub Sponsors — 枠組みが当てはまらない

継続月数の実測がない状態の LTV は、予測というより願望に近い。 その数字で広告費を決めると、検証できない赤字を作る。

したがって層2は、継続月数が実測されるまで層1の上に載せない。

層3 — いくらにするか

計算の仕事ではない。 何が価格を決めているかが商品ごとに違うため。

商品 価格を決めているもの
Kindle本 **Amazon の制度。**税込 ¥250-1,250 の外に出ると 70% を選べない
SaaS 競合と、顧客が得る価値
買い切りアプリ ストアの価格帯慣習と、競合の無料版
GitHub Sponsors 相場と関係性。最適化の対象ではない

本の価格を決めているのは制度で、中身の価値はそこに入ってこない。 ¥1,250 と ¥1,300 の間にある差は ¥50 に見えて、実際には 70% と 35% の差になる。

根拠の質を運ぶ

3層を1つのツールに載せる以上、どの層の数字なのかが出力に出ていなければならない。

  • ✅ MEASURED — レポートの数字を割って出した値だけ
  • ⚠️ PARTIAL — 計算式は裏が取れているが実観測がない
  • 🔴 ASSUMED — 仮値

演算のたびに弱いほうへ落ちる。上がることはない。 実測の粗利に仮の継続月数を掛けたら、出てくる LTV は仮値。

これを人間の注意力に任せると失敗する。実際に失敗した例が price-dial を作る きっかけになっている（README）。

何を実測と呼ぶか

レポートの数字を割って出した値だけ。

定価に率を掛けた値は、どれだけ自明に見えても計算値どまりで、観測を1件も含まない。 この区別が消えた瞬間に、検算されない数字が「実測」の顔で台帳に載る。

実測の作り方（KDP の例）

KDP のレポートは価格を返さない。が、割れば1冊あたりが出る。

1冊あたりロイヤリティ = royalty ÷ net_orders

条件が2つある。

  1. KENP = 0 の本だけ使う — KU の読了収益が混ざると価格由来でない額が乗る
  2. 単一マーケットプレイスの本だけ使う — 国が混ざると通貨も税率も混ざる

これで出した5点が、4つの観測窓すべてで税抜35%と小数まで一致した。 tests/test_kdp_jp.py はその5点をそのまま固定している。