この記事では、決済フローを最適化することによるコンバージョン率の改善を、Stripeが提供するノーコード機能を使って実現する方法を紹介します。
決済フローの最適化でコンバージョン率を改善する
ECサイトにおいて、決済フローの最適化は売上と収益を最大化するための重要な課題です。マーケティング施策やウェブサイトの改善などで構築したコンバージョンファネルの最終ステップで、どれだけ売上を逃さない・カゴ落ちを発生させないかが売上を高めるための鍵となります。
実際に2022年の調査によると、好みの決済方法が利用できない場合、84%の顧客が頻繁に購入を取りやめると回答しています。このように決済手段のサポートや決済フローの最適化を行うことが、ECサイトの売上を最大化することに貢献するといえます。
顧客層にあわせた決済手段を提供する
決済フローの最適化は、決済手段の数を増やすだけでは不十分です。購入する顧客の住む国や地域、そして年齢層によって、提示する決済手段をカスタマイズすることで、よりコンバージョン率を高めることが期待できます。例えば、十代から20代にかけての顧客が中心の場合、クレジットカードよりもApple PayやGoogle Payなどのデジタルウォレットや、コンビニ決済などの後払い決済（BNPL）の方が好まれるかもしれません。また、高額商品や高齢者向けの商品を取り扱う場合には、銀行振込による支払いが好まれる可能性も考えられます。
このように、顧客が利用したいと考える決済手段を、ビジネスモデルや商品・注文金額などに合わせてカスタマイズすることが、決済フローの最適化の鍵となります。
決済フロー最適化の実装コストを、Stripeで最小化する
決済フローを最適化し、顧客や注文商品に応じて最適な決済手段を提供するには、複雑な実装が必要に見えます。ここまで紹介した例だけでも、顧客のIPアドレスや発送先の住所、そして注文金額・通貨などの情報をもとに、提示する決済手段を変更する処理が必要です。
以下のサンプルコードは、3つの通貨と購入金額に応じて提示する決済方法を変更する実装です。
app.post("/create-payment-intent", async (req, res) => {
const { items } = req.body;
const orderAmount = calculateOrderAmount(items)
const orderCurrency = calculateOrderCurrency(items)
let paymentMethodTypes = ["card"];
// 通貨と金額に基づいて特定の決済方法を追加
switch(orderCurrency) {
case "eur":
paymentMethodTypes.push("giropay");
break;
case "gbp":
paymentMethodTypes.push("klarna");
if (orderAmount >= 100 && orderAmount <= 100000) {
paymentMethodTypes.push("afterpay_clearpay");
}
break;
case "usd":
paymentMethodTypes.push("paypal");
break;
default:
}
// payment_method_typesを指定してPaymentIntentを作成
const paymentIntent = await stripe.paymentIntents.create({
amount: orderAmount,
currency: orderCurrency,
payment_method_types: paymentMethodTypes,
});
res.send({
clientSecret: paymentIntent.client_secret,
});
});
しかしこのような複雑なコードをアプリケーションに組み込むことは、別の問題を引き起こします。1つ目は、保守すべきコード量が増加し、リリース前のテスト項目や保守対象が増えることです。2つ目は、条件の変更にデプロイが必要となり、コンバージョン率改善のための試行錯誤が迅速に行えなくなることです。
これらの問題は、Stripe Elementsとダッシュボードを使用することで解決できます。Payment Elementsを使用し、動的な支払い方法機能を有効にすることで、ダッシュボード上の設定を変更するだけで、国/地域や金額による制御が可能になります。
動的な支払い方法機能を使った場合、決済フォームを生成するためのコードは、金額と通貨だけ計算すればよくなります。
app.post("/create-payment-intent", async (req, res) => {
const { items } = req.body;
const orderAmount = calculateOrderAmount(items)
const orderCurrency = calculateOrderCurrency(items)
const paymentIntent = await stripe.paymentIntents.create({
amount: orderAmount,
currency: orderCurrency,
});
res.send({
clientSecret: paymentIntent.client_secret,
});
});
このようにStripe Elementsの機能を使用することで、コンバージョン率を向上させるための決済方法のカスタマイズがより簡単に行えるようになります。
決済フローの変更リスクを、A/Bテストで最小化する
決済フローの最適化に取り組む際、最も警戒されるリスクは、施策によって売り上げが減少してしまうことです。最適化のための仮説に現状との相違があった場合、顧客が好まない決済手段が優先表示され、それによってカゴ落ちが増加してしまう可能性が存在します。このようなリスクを減らすため、StripeではA/Bテストを利用した仮説の検証フェーズを設けることができます。
StripeのA/Bテスト機能を使用すると、複雑なコーディングやリスクの高い全面的な展開を行うことなく、さまざまな決済方法と設定を実験できます。決済フローの簡単なテストと最適化を可能にすることで、企業はコンバージョン率と全体的な顧客体験を改善できます。
ここではApple PayやGoogle Payをアプリケーションに実験的に追加する方法を見てみましょう。Stripeダッシュボードの決済設定ページの決済方法タブで、「実験を作成」ボタンを見つけて新しいA/Bテストを開始できます。これをクリックして、実験したい決済方法の表示ルールの設定を開始します。
実験作成画面では、各決済方法のオン/オフを切り替えたり、カスタムルールを設定したりできます。Apple PayやGoogle Payを実験的に導入したい場合は、トグルをクリックして有効にします。
同時に複数の決済方法を追加し、ルールをカスタマイズすることもできます。ただし、複数の条件を設定すると、実験の効果の測定と、因果関係の調査が難しくなる可能性もあります。コンバージョン率の改善は銀行振込のサポートによるものなのか、それとも同時にコンビニ決済もサポートしたからなのか？ A/Bテスト実験の目的は、事前に考えた仮説を検証することです。したがって、実験を開始する際は、実験結果から因果関係を判断しやすいように設定することが重要です。
実験したい決済方法を決定したら、最後のステップはテストするトラフィックの割合を設定することです。デフォルトでは、決済取引の50%が実験設定を使用して処理されます。より少ない割合で実験したい場合は、より低い割合（30%など）に設定します。実験内容を確認したら、実験を開始できます。「実験を開始」をクリックすると、設定した割合ですぐに実験が始まります。
これで、決済方法の提供方法をカスタマイズする効果を検証するために、小規模な実験を開始できます。
A/Bテストによる実験結果を確認する
A/Bテストによる実験結果についても、ダッシュボードで確認できます。実験グループごとに、どれくらいのセッションがあったかや平均売上がどれくらい変化したかなどが比較しやすい形で表示されます。
各数値が日ごとにどう変化したかなどの深掘りについても、レポート画面で行えます。
決済手段ごとの使用状況も確認できます。この画面を使うことで、導入を検討している新しい決済手段の利用具合の調査ができます。
最後にどちらの設定を採用するかを選びましょう。ここでの選択による変更も、アプリケーションコード側の変更なしに反映させることができます。
Workbenchを使用して個々の決済フローを調査する
開発者にとって、A/Bテストがどこで行われているかを調査およびデバッグすることは難しく感じるかもしれません。これは、チェックしたい動作がA/BテストのAなのかBなのかを判断し、意図的に再現する必要があるためです。決済フォームの実験に関しては、開発リソースなしで実験を設定できますが、決済プロセス中に顧客にどのようなUIと決済方法が表示されるかをテストおよび調査するよう求められる場合があります。
Stripeは、WorkbenchとDashboard機能を使用してこれらの調査をより簡単に行えるようにしています。まず、調査したい決済のPayment Intentを特定します。DashboardからそのPayment Intentの詳細ページにアクセスすると、WorkbenchのInspectorタブからリソースの詳細を確認できます。Inspectorタブには、Overviewタブを含むいくつかの機能があります。ここでは、リソースの生のJSONデータを表示できます。
例えば、その決済で顧客にどの決済方法が提示されたかを確認したい場合、OverviewタブのJSONデータからpayment_method_types属性をチェックします。Stripeが顧客に提示した決済方法がここに配列で格納されています。例えば、クレジットカード決済とLinkという2つの決済方法が提示されたことがわかるかもしれません。
また、Workbenchを使用して、このPayment Intentを作成したAPIリクエストを確認することもできます。Logsタブをクリックすると、現在表示しているリソースに関連するAPIリクエストの履歴を表示できます。リクエストのPOSTボディを見ることで、顧客に提示された決済方法のリストがアプリケーションコードで作成されたのか、それともStripeダッシュボードの設定によるものかを判断できます。場合によっては、リクエストにpayment_method_typesが含まれていないことがあります。これは、Stripeダッシュボードで設定された決済方法表示ルールに従ってPayment Intentが適用されたことを示します。
Stripeが統合されたアプリケーションにどのような情報を送信したかを調査したい場合は、Eventsタブを使用します。ここでは、調査しているリソースに関連するWebhookイベントの履歴をリストで確認できます。Eventsタブは、決済方法に基づいて顧客へのメールをカスタマイズしたり、外部の分析プラットフォームにデータを送信したりする場合に特に役立ちます。どのようなデータがいつ送信されるかを確認するのに使用できます。
このようにStripeのダッシュボードやツールを活用することで、開発者はビジネスチームからの要求により効率的に対応できます。このアプローチは、決済関連機能の開発に必要な時間を削減するだけでなく、アプリケーションコードを最小限に抑えることで運用と保守の負担も軽減します。さらに、Workbenchを使用することで、顧客からの問い合わせや社内からの質問に迅速に対応できます。
まとめ
オンライン決済において、顧客が好む決済方法を提供することで、コンバージョン率と売上の向上につながります。例えば、あるStripeユーザーは、若い顧客を惹きつけるためにKlarnaを通じてBNPL（後払い）決済を導入しました。この戦略により、平均注文額（AOV）が16%増加しました。Stripeを使用することで、4日以内に新しい決済方法を展開し、売上を伸ばす戦略を素早くテストし実装するシステムを構築しました。
決済方法を最適化するには、顧客の所在地や注文金額に合わせた多様な選択肢が必要です。しかし、これらのカスタマイズはコードを複雑にし、テストやトラブルシューティングをより困難にする可能性があります。
Stripe Elementsを使用すれば、追加のコーディングなしで、決済方法のローカライゼーションや並べ替えによる最適化が可能です。ダッシュボードで希望する決済方法を有効にし、必要に応じて金額制限や地理的な利用可能性を指定できます。リスクを最小限に抑えるため、ダッシュボードから直接A/Bテスト実験を実施することができます。これらの機能は、潜在的な売上の損失を回復するのに役立ちます。
実験期間中は、ワークベンチのインスペクター機能を使用して、決済を迅速に調査し、アプリケーションのテストとデバッグに必要な情報を収集できます。
注文フローの最終段階での売上損失を防ぐため、今すぐStripeで決済フォームの最適化を始めましょう。