BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

商品在庫絞り込み機能のリリース振り返りと、New Relicを活用した観測について

NewRelic

初めまして。フロントエンドエンジニアの近藤 @kon_engineerと申します。 本記事では、2022年1月24日（月）にリリースされた、商品在庫絞り込み機能の振り返りと、サービス全体の状況を可視化できるNew Relicというプラットフォームを活用したAPIの観測について紹介します。

今回の事例では、New Relicで観測可能なAPIのレスポンス速度や各クエリパラメータのリクエスト状況などを分析して、効果測定や今後の施策に活かす取り組みを行いました。New Relicの詳しい説明や、BASEがNew Relicを導入した経緯はこちらの記事をご参照頂けたらと思います。

商品在庫絞り込み機能とは

商品管理画面で商品の在庫数を指定して検索できる機能です。BASEでは商品管理画面の一覧から、在庫切れの商品や在庫が少なくなっている商品を簡単に見つけることができないという課題がありました。特に商品数が50を超える場合は、在庫状況をページングして確認する必要がありました。そこで、在庫数で商品を絞り込めるように改修して、商品管理の利便性の向上を図りました。

Twitter上の告知は以下です。

New Relicによる監視

New Relicによる監視はBASE全体として推進しているものの、本PJのメンバーは本格的な導入経験はありませんでした。今回はプロジェクトとしてトライしてみようということで、メンバーそれぞれが仕組みを学びながら運用していきました。

開発前

検索利用状況

商品在庫検索機能は、既存の商品検索APIにクエリパラメータを追加することで実装しました。実装前に既存の商品検索APIのレスポンス速度や、使用されている頻度を把握することで既存の問題や、追加で行った方が良い改善がないか、開発前に観測することにしました。 利用状況

まずは検索API全体の呼び出された回数を測定して、次に各パラメータが指定された回数を測定することで、どのパラメータが使われて、どのパラメータが使われていないか分かるようにしました。

得られた結果として、全体の検索回数に対して、キーワードを指定して検索された回数が約87%あることが測定できたため、キーワードで主に検索されていることが分かりました。また、商品タイプ別の検索は、他の検索条件よりも極端に使用されていないことが呼びされている回数から分かったため、何らかの対応を検討する価値があると把握できました。

さらに、キーワード検索以外は、絞り込みボタンを押して検索モーダルを開かなければ検索できないUIのため、キーワード以外の各検索回数の結果から、検索モーダル経由で一定数の検索リクエストが呼ばれていることが分かりました。今回は検索モーダルに在庫数の検索機能を追加するため、そもそも検索モーダルがほとんど開かれていない、という状況ではないことを把握することは重要でした。

負荷状況

レスポンス速度に改善の余地はないか、また今回の改修によってレスポンスが悪くならないか把握するために、現状の応答速度を事前に把握しました。特に大きな問題は見つからなかったため、この速度を維持することを目標としました。 応答時間

リリース前後

規模別

事前にショップを規模別に分類して、規模別でどのような効果があったのか観測できるように準備しました。今回の機能は、商品数が増えて在庫管理が大変な大規模ショップにより使ってもらいたいという思いがあったので、規模別に観測することで効果を細かく把握する狙いがありました。 規模別

リリース後の検索回数

また、在庫数を検索された回数がどれくらいなのか、リクエストURLを監視してリリース後すぐに分かるようにしました。機能が順調に使われていることが観測できて、PJメンバーで喜ぶ場面もありました。 在庫数

どのような値で検索されているか把握する

当初は観測していなかったのですが、リリース後に在庫数0で検索されているケースがとても多いことが判明しました。在庫が少ない商品を検索するために使われることは予想していたのですが、それにしても0で検索されることが多い、という印象でした。そのため、どのような数値で検索されているのか、後からNew Relicのダッシュボードに追加して観測しました。結果として8割以上が在庫数0で検索されていたことが分かり、数字から事実として在庫切れ商品を把握したいニーズを把握することができました。これにより、在庫切れ商品を素早く通知するような、在庫切れにアプローチした施策が今後も有効だろうということが分かりました。 指定されている数字

負荷状況

事前に十分に検証はしたものの、リリース後もレスポンスが遅くなっていないか、エラーコードが出ていないかなどの検証をしました。特にエラーも発生しておらず、レスポンスも悪化していないことを観測することができました。

終わりに

PJが始まった時、今まで効果測定を適切に行えていないというチームメンバーの課題感がありました。そのため、ただリリースして終わるのではなく、機能を使ってもらっているのか、どのような使われ方をしているのかを把握して、反省と次の施策に繋げる取り組みを行いました。

今回の施策は、規模として大きな改修ではありませんでしたが、改修したAPIをNew Relicで観測することで、しっかりと機能が使われていることを把握できて、施策として一定の効果があったことが分かりました。また、当初チームが持っていた仮説として、ショップオーナーの方々は、在庫切れの商品を少ない時間で簡単に把握したい、というものがありました。仮説が間違っていなかったことが改修したAPIの利用状況からも分かり、今後も在庫切れの商品がすぐに分かるような施策が有効であると、自信を深めることができました。

何より、作ったものがしっかりと使われていることを観測できることで、チーム全体の士気も上がったと思います。今後も継続的にこのような取り組みを行うことで、施策の有効性や妥当性を意識して開発していきたいと考えています。