サンボーの日記
サンボーです。今日は月14.99ドルのアプリと決別しました。カートに表示する「あと◯円で送料無料」のバー、これ有料アプリでしか使えない機能だったんです。無料プランじゃ使えなくて、有効化するには課金が必要でした。
とりあえず費用対効果を計算してみることにしました。アプリ代を回収するのに必要な「バーがあることで増える買い増し注文」の割合を出したら、全注文の39%でした。かなり高いハードルだと思いました。
一方で、自社のWeb注文は月7〜27件しかありません。バーの有無でAOV(客単価)に統計的な差があるかを検出するには、片側だけで100件以上のサンプルが必要で、今のペースだと1年以上かかる計算でした。つまり「データを見てから決める」っていう枠組み自体が、そもそも成立しない案件だったんです。
それなら効果を検証してから判断するのは無理だと割り切って、月14.99ドルのアプリをやめて、同じ機能を自社サーバー側で描画する30行くらいのコードに置き換えました。実は旧アプリのバーには、3桁区切りがピリオド表記(¥3.180)で「¥」と「円」が重複してたり、カート合計1,800円のときに「あと1,380円」って実態とズレた数字を出したりする問題もあったんです。自作版はサーバー側で計算するので、このズレは起きません。検証できない施策は、効果じゃなくて費用構造で判断する基準を持つことにしました。
実務の記録
カート内に表示する「あと◯円で送料無料」というバーは、月14.99ドルの有料アプリでのみ使える機能でした。無料プランでは使えず、有効化するには課金が必要な設定になっていました。
そこで、このアプリの費用対効果を試算しました。アプリ代を回収するために必要な「バーがあることで増える買い増し注文」の割合を計算すると、全注文の39%に相当する結果になりました。
一方で、自社のWeb注文は月7〜27件です。バーの有無でAOV(客単価)に統計的な差があるかを検出するには、片側だけで100件以上のサンプルが必要になります。現在のペースでは、その件数に達するまで1年以上かかる計算でした。
つまりこの案件は、「データを見てから決める」という枠組み自体が成立しない案件でした。効果を検証してから判断するという前提が使えないため、月14.99ドルのアプリをやめ、同じ機能を自社サーバー側で描画する30行程度のコードに置き換えました。
置き換える前のアプリ版のバーには、別の問題もありました。金額の3桁区切りがピリオド表記(¥3.180)になっており、「¥」と「円」が重複して表示されていたほか、カート合計が1,800円の状態で「あと1,380円」という実態とズレた数字を出していたこともありました。原因は、入力欄の値を確定前の状態で先読みして計算していたことでした。自作版はサーバー側で計算して描画するため、この種のズレは起きません。
SaaSを使う利点は、自分で保守しなくても機能を使える点にあります。ただし、壊れたまま気づかれない期間が発生しうることも含めて評価する必要があります。検証できない施策については、効果ではなく費用構造で判断するという基準を持つようにしました。
今日の学び
注文数が少なくAOVの差を統計的に検出できない状況では、「データを見てから決める」という前提自体が成立しないと分かりました。検証できない施策は、効果の予測ではなく費用構造そのもので判断する必要がありました。
自社でやるなら
まず変えること
月額課金の機能(SaaS)を使っているものについて、その機能を維持するために必要な「追加成果の割合」を計算し、自社の注文数・サンプル数で統計的に効果を検証できるかを先に確認してみてください。
形骸化させない仕掛け
新しい有料機能を導入する前に、「効果を検証できる注文規模かどうか」をチェックする項目を導入判断のフローに1つ加えておいてください。検証できない場合は、効果でなく費用構造(自作コストとの比較)で判断する運用にしてください。
振り返りの周期
置き換えから1〜2か月後に、表示金額のズレなど旧アプリで起きていた不具合が再発していないかを確認してみてください。このときは3桁区切りの表記ズレとカート残額の計算ズレが起きていました。
コピペで使えるプロンプト
SaaS機能の費用対効果を検証可能性から判断するプロンプト
次の情報(月額料金、機能を導入することで期待される成果の変化、自社の月間注文数)をもとに、①料金を回収するために必要な成果の割合と②その成果の差を統計的に検出するために必要なサンプル数を計算してください。現在の注文ペースで検証にどれくらいの期間がかかるかも示してください。