ECサイトの完成度は、公開日に決まりません。

むしろ、その後どれだけ観察し、判断し、手を入れられるかで決まります。

公開時点で見えているのは、あくまで「こう使われるだろう」という仮説です。お客様がどこで迷い、何を比較し、どの情報を見て購入を決めるのか。その答えは、運用が始まってから少しずつ見えてきます。
だから、公開後に改善点が見つかることは失敗ではありません。

問題なのは、改善点が見つかったのに、変えられないことです。

この記事でいう「育てるEC」とは、機能を増やし続けるECではありません。
お客様と事業の変化に合わせて、判断を更新し続けられるECのことです。

公開後に、設計の答え合わせが始まる

力を入れてつくったページが読まれないこともあります。目立たせた商品より、想定外の商品が検索されることもあります。
補足として置いた一文が、購入の迷いを解消する場合もあります。

公開前に設計できるのは、筋の通った仮説までです。

公開後に修正が発生するのは、つくり込みが足りなかったからではありません。修正を判断できる材料が、ようやく集まり始めたからです。

初回公開に、すべてを詰め込まない

ECサイトの構築が進むと、追加したい機能が増えていきます。

レコメンドも必要ではないか。
会員ランクも用意したい。
外部サービスとも連携したい。
AIを使った接客も検討したい。

どの要望にも、それなりの理由があります。
ただし、一つひとつに理由があることと、初回公開にすべて必要であることは別です。

機能を追加するほど、要件も画面も確認事項も増えます。公開時期が延び、予算が膨らみ、公開する頃には当初の前提が変わっている。
EC構築では普通に起こります。普通に起こるからこそ、なかなか笑えません。

初回公開で必要なのは、機能を可能な限りそろえることではありません。
お客様が商品を理解し、比較し、納得して購入できること。その基本的な購買体験が成立していることです。

そのうえで、公開後の行動を見ながら次に必要な機能を決める。

これは妥協ではありません。使われるかわからないものに先回りして投資するより、判断材料を得てからつくるための設計です。

「最初から何でもできるEC」と「あとから適切に変えられるEC」は、同じではありません。
前者を追いすぎることで、後者を失うこともあります。

改善案より、改善できる経路をつくる

ECサイトを育てると聞くと、新しい企画や大きな機能改修を想像するかもしれません。
実際には、もっと地味です。

商品説明の順番を変える。
送料の記載場所を見直す。
検索条件を整理する。
スマートフォンで押しにくいボタンを直す。
問い合わせで繰り返し聞かれる内容を追加する。

ただし、小さな変更だからといって、簡単にできるとは限りません。
たとえば、商品ページの送料表記がわかりにくく、同じ問い合わせが続いているとします。

変更する文言は決まっている。作業自体は数十分。
それでも、制作会社への見積もり、社内承認、発注、検証、本番反映と進み、気づけば数週間。

その間も、お客様は同じ場所で迷い続けます。
この場合、足りないのは改善案ではありません。
改善するための経路が詰まっています。

担当者の改善意識を高めても解決しません。改善しようとするたびに、複数の手続きと承認が必要な仕組みそのものが問題だからです。

必要なのは、良いアイデアを増やすことではありません。
見つけた課題を、必要な速度で変更につなげられることです。

データから「次に試すこと」を決める

アクセス解析やヒートマップを導入していても、改善に結びついていないECサイトは少なくありません。
レポートは毎月作成される。数字も共有される。しかし、次に何を変えるかは決まらない。
これでは、データを活用しているというより、データと定期的に顔を合わせているだけです。

数字は、それだけで原因を教えてくれません。

たとえば、商品詳細ページの閲覧数は多いのに、カート投入率が低いとします。

価格で迷っているのか。
送料や配送条件が見つけにくいのか。
サイズや仕様が足りないのか。
利用場面を想像できないのか。

同じ数字から、複数の仮説が考えられます。
そこで、商品説明や写真、送料の記載位置、FAQへの導線を変え、結果を確認します。効果がなければ戻し、別の仮説を試す。

大切なのは、変更することではありません。
変更によって、仮説を確かめることです。

アクセス数や購入件数が少ないECサイトでは、数字だけで傾向を判断しにくいこともあります。その場合は、問い合わせ内容、サイト内検索の言葉、レビュー、営業や接客の現場で聞いた声、ユーザーテストも組み合わせます。

数字で違和感を見つけ、現場の声で理由を考え、変更後の数字で確かめる。
改善とは、変更を積み重ねることではなく、判断の精度を上げていくことです。

育てやすさも、ECサイトの機能である

ECパッケージやプラットフォームを選ぶ際は、公開時に必要な機能が比較されます。
商品管理、会員管理、外部連携、決済方法。どれも重要です。

ただし、公開後にどこまで柔軟に変更できるかも、同じくらい確認しておく必要があります。
運営側で編集できる範囲はどこまでか。文言や画像の変更にも開発が必要なのか。小規模な改修をどの単位で依頼できるのか。
公開時には目立ちにくい項目ですが、運用が始まると、この違いが改善速度を左右します。

高機能であることと、育てやすいことは同じではありません。

機能が豊富でも、変更のたびに大きな費用と時間が必要なら、改善の頻度は落ちます。
反対に、小さな変更を安全に試せる仕組みであれば、公開後に得た学びをすぐに反映できます。

育てやすさは、運用上の都合ではありません。
ECサイトが変化に対応するための機能です。

公開時の正解を、今の正解へ更新する

ECサイトに完成がないからといって、何でも変え続ければよいわけではありません。

うまく機能している部分は、そのままで構いません。変えるべきなのは、公開時の正解と、今のお客様や事業との間にズレが生まれた部分です。

見る。考える。試す。確かめる。残すか戻すかを決める。
この判断を繰り返せるECサイトは、公開時点で完璧でなくても、今の正解へ更新されていきます。

反対に、公開時の完成度が高くても、その後に検証も変更もできなければ、少しずつ現実から離れていきます。

ECサイトに必要なのは、最初からすべてを正しくつくることではありません。
実際のお客様の行動を見て、仮説を確かめ、必要なら変えられることです。

まず決めておきたいのは、公開後に誰が数字とお客様の声を確認し、どの頻度で改善の優先順位を決めるのか。
公開日に確認するべきなのは、「完成したか」ではありません。

次に何を確かめるかです。

※関連リンク：「GMOクラウドEC」公式サイト