機能するカートでビートをネットで売る方法
何年もの間、僕の店のビートはどれもボタンが一つだった。買う。押すとライセンスの選択が開き、一つ選ぶと、BeatStarsがそのビートだけを載せた決済画面に連れていく。動いていたし、静かに売上を落としていた。プロデューサーが2本欲しいなら、2回払うしかなかった。ボタンごとに新しい購入が始まるからだ。そんな人はいない。1本買って、もう1本はまた来ると言って、来ない。
だから10月22日、サイトに本物のカートを入れた。プラグインではない。店はAstroで作った静的サイトで、データベースも自前の管理画面もない。店を始めてから最大の変更だ。仕組みを書いていく。
買うボタンの問題
ビートストアはカートを押す店ではない。各商品に六つのライセンス段があり、価格は数量ではなく段で変わるカタログだ。だからほとんどのプロデューサーはカートを作らなかった。プラットフォームがビートごとにリンクをくれるので、買い手をそこへ送ればいい。
その代償は見えないが実在する。決済が一回増えるたびに、買い手が気を変える機会が一回増える。支払いフォームを二度通り、同じ情報を二度入れ、二つのファイルのために別々のメールを二通受け取る。あるビートのベーシックと、別のビートのステムスを比べたいなら、二つの購入は完全に独立していた。
BeatStarsが使わせてくれるもの
BeatStarsはカートのAPIを公開していない。だが店のフロントエンドはそれを使っていて、到達できる。呼び出しは三つで足りる。
- カートを作る。新しいuuidで。決済ごとに新しくするので、買い手が前回の商品を引き継ぐことはない。
- 行を足す。トラックIDと、選んだライセンスのコントラクトIDで。段と価格を決めるのはコントラクトで、トラックだけではない。
- 共有リンクを求める。そのURLを買い手が開くと、カートがその人のブラウザにコピーされ、すべて載った状態でBeatStarsの決済に着地する。
大事なのはここだ。支払いと配信はBeatStarsに残る。サイトはカードに触れず、買い手を保存せず、店にもならない。カートを組んで渡すだけで、だから全部が静的なページに置ける。
静的サイトを静的なままに保つ
カートはブラウザに住む。行ごとに二つだけ覚える。どのビートか、どのライセンスか。それだけだ。名前、価格、コントラクトIDはページが読み込まれるたびにサイトの設定から読むので、価格を変えても、先週始めたカートに古い数字が残らない。
ヘッダーのカウンター、追加と削除のボタン、合計はすべて素のJavaScriptだ。セッションもログインも、間に入る僕のサーバーもない。サイトが誰かと話すのは、買い手が決済を押して共有リンクが組まれる瞬間だけだ。
テストで差が出た細かい点が二つある。1ビートにつき1ライセンス。カートは同じビートを二度持つのを拒む。プラットフォームがそう動くからで、試した買い手は奉仕されるのではなく混乱する。そして決済へ離れて払わずに戻ってきたとき、カートはまだそこにある。離れる直前に保存したコピーから戻す。アカウントの仕組みなしで作れる、放棄カート回収に一番近いものだ。
割引は誰も正しくやらない部分
僕のライセンスには店独自の特典がある。ベーシックを1本買えば2本無料、スタンダードを3本買えば2本無料。BeatStarsはこれをカートごとに一度、決済時に、一番安い行に適用する。サイトが合計$65.90と出して決済が$32.95と言ったら、買い手は得した気分にならず、騙された気分になる。
だからカートはそのルールを再現し、誰かが離れる前に同じ計算を見せる。何が無料か、次の無料行まであと何が必要か、合計がいくらになるか。階段はカートを埋めている間に見え、最後に驚きとして現れない。買い手に真実を伝えることにもなる。それが決済ページと出会って生き残る唯一の割引の形だ。
おそらく自分では作らない理由
小さな機能に見えて、そうではない。サイトには管理画面もCMSもプラグインもない。すべてのページが事前に生成され、素のHTMLとしてアップロードされる。ブラウザにしか存在しないカートは、仲裁するサーバーなしで合計とライセンスと決済を一致させ続けなければならない。
店側はもっと悪い。BeatStarsはカートAPIを文書化していないので、裏の三つの呼び出しはフロントエンドで見つけ、一つずつ試した。各行にはトラックIDと、ライセンスのコントラクトIDの両方が要る。価格はコントラクトにあり、ビートにはないからだ。あるトラックで店が無効にしたライセンスがあると決済全体が失敗するので、エラーは空白の画面ではなく、壊したビートの名前とともに返らなければならない。
それから誰も見ない部分がある。買い手が離れる前に割引の階段を再現すること。ここでの合計と決済での合計が同じ数になるように。BeatStarsは無料の行をカートごとに一度、一番安いものに適用する。これを間違えると、カートは機能ではなく苦情になる。
だから多くのプロデューサーは自分で作らず、プラットフォームを借りる。そしてこのサイトが倒れないホスティングで動いている理由でもある。他のすべては静的なファイルで、動く部分はお金を受け取るプラットフォームだけだ。
その下のサイト
こういうものは、プラグイン15個のWordPressでは生き残らない。店は静的サイトで、430ページを事前に生成している。スタイルシート一枚と、プレイヤーとカートのための少しのJavaScript。訪問者が来ても、データベースに何も問い合わせない。
音声も同じ考え方だ。320 kbpsのMP3ではなく56 kbpsのHE-AAC。インデックスをファイルの先頭に置くので、ビートをダウンロードし終える前に再生が始まる。一年間訪問者の端末に残すキャッシュヘッダーも付ける。
そのあとホストがやることは少ないが、うまくやる必要がある。ファイルを速く返し、バイト範囲とキャッシュヘッダーを尊重し、SSLとHTTP/2を備える。このサイトが動いているのはそれだ。自分の店にも同じ土台が欲しいなら、実際に借りる必要があるのはその部分だけだ。
別のプラットフォームで売っているなら
この仕掛けはBeatStars向けだ。僕のライセンスと買い手がそこにいるから。理屈は移せる。カートのエンドポイントを持つ店なら、静的サイトから同じように動かせる。移せないのは近道のほうだ。カートはカートに入れると書いたボタンではない。合う価格、合うライセンス、買い手が選んだものがそのまま開く決済だ。
まだ決済ごとに1本ずつ売っているなら、カタログとライセンスから始めて、そのあとにカートを作るといい。ビートのカタログ全部はここにあり、この店がどんなビートを土台にしているか聴きたいならこのboom bapのインストから。
よくある質問
ビートストアにカートを足すのに開発者が要りますか
静的サイトなら、はい、多少のコードが要る。呼び出しは店のカートエンドポイントへの三つの変更で、残りはブラウザの状態だ。だが誰かが書いて、すべてのライセンス段を決済の合計と突き合わせて試す必要がある。
買い手がライセンスを変えたくなったらカートは動きますか
動く。各行が自分のライセンスを持ち、カート自体から切り替えられる。同じビートを二度は持てないので、ライセンスの変更は行を足すのではなく置き換える。
支払いはどこで起きますか
いつもBeatStarsで。サイトはカートを組んで、それを載せた決済を開くだけだ。カード、請求書、配信、ライセンスのPDFはプラットフォームの中に残る。
サイトで直接売らないのはなぜですか
そうするとサイトに決済代行、税の処理、請求書、顧客データベースが要る。カートがプラットフォームに渡す静的なカタログなら、速い部分は速いままで、お金の部分は合法的にやっている人に任せられる。
