ECの商品データを点検する順番と、表記ゆれを直す前に決めること

商品点数が増えてきたので、検索や絞り込みを足したい。そうご相談をいただくと、たいてい先に出てくるのが商品データの話です。

まず商品データを整えましょう、と言われた経験はありませんか。ところが、いざCSVを開いても、どの列を足せばいいのかは決まりません。

かいなは、商品データの整備を検索機能の前工程だとは考えていません。選ばせ方が決まっていないと、属性は決まらないからです。

順番はデータからではなく、売り場の決め事から始まります。この記事では、その順番で自社のデータを点検する方法を整理します。

「商品データを整えてから」では、点検がいつまでも終わらない

相談の入口で一番多いのは、どの項目を属性にすべきかという質問です。答えは商材によって変わりますが、決め方の順番には共通のものがあります。

きれいなデータと、選ぶために使えるデータは別のもの

表記が統一され、空欄がなく、型番も揃っている。これはきれいなデータです。ただ、きれいであることと、お客様が選べることは別の話です。

整った商品説明文が並んでいても、絞り込みの軸として使える列が一つもない。この状態はよく起こります。

点検の出発点は、列が揃っているかではありません。その列で絞ったときに、お客様の候補が本当に減るかどうかで見ます。減らないなら、整えても売り場は変わりません。

属性は商品の説明ではなく、お客様が迷うときの言葉

属性項目は、社内で商品を管理するための言葉になりがちです。素材コード、シリーズ名、入数。どれも管理には要ります。

ただ、それが迷っている人の使う言葉とは限りません。問い合わせで実際に口にされる言葉を並べてみると、社内の項目名と重なる部分は案外少ないものです。

属性を決めるときは、商品を正しく説明できるかではなく、お客様の迷いを一つ減らせるかで採否を決めます。説明のための項目は、管理側に置いたままで構いません。

動作で束ねた品揃えから分かること

かいなは日用品のEC「SOREDAKE」を自分たちで運営しています。拭くだけ、流すだけ、入れるだけという動作で品揃えを束ねたECです。

カテゴリで分ければ洗剤や掃除道具になります。けれどお客様が探しているのは、面倒を一つ減らす方法のほうです。

同じ商品群でも、束ね方を変えると必要な属性は変わります。カテゴリのままなら用途タグは要りませんし、動作で束ねるならカテゴリは主役から外れます。

だからかいなは、属性の表を作る前に、売り場でどう束ねるかを先に決めます。

導入前に自社の商品データを点検する4つの場所

束ね方が決まったら、自社のデータがそれに耐えるかを見ます。見る場所は、粒度、表記ゆれ、欠損、正本の4つです。

粒度は商品単位か、バリエーション単位か

サイズや色で価格や在庫が変わる商材では、属性が商品側とバリエーション側に散らばりがちです。

絞り込みで「Mサイズ」を選んだとき、Mだけ在庫のない商品が一覧に残ると、お客様は商品ページまで進んでから空振りします。

判断はそれほど複雑ではありません。在庫や価格と連動して意味が変わる属性はバリエーション側に、変わらないものは商品側に置きます。

この整理をせずに絞り込みを足すと、機能の不具合に見える現象がデータ側の理由で起き続けます。

表記ゆれは、同じ意味がいくつの書き方で入っているか

ステンレスとSUS、無垢材と天然木、A4とエーヨン。同じものを指す書き方が混ざると、絞り込みの選択肢が二重に並びます。

選択肢が二重になると、どちらを押しても商品が半分しか出てきません。お客様には、品揃えが薄い店に見えます。

点検では、属性ごとに実際に入っている値を一覧で出してみます。想定より種類が多ければ、その属性はまだ選ばせる軸として使えません。

直す順番は、値の種類が少ないものからです。種類が多い属性ほど、そもそも軸として要るのかを疑います。

半分だけ埋まった属性は、絞り込みで害になる

新しい属性を足すと、既存商品が空欄のまま残ります。空欄の商品は、その軸で絞った瞬間に一覧から消えます。

売れ筋が消えると、お客様は在庫のない店だと受け取ります。これは機能の不具合ではなく、埋め方の設計漏れです。

新規属性を足すときは、全商品に値が入るまで表に出さないか、空欄を「指定なし」として必ず拾う設計にするか、どちらかを先に決めます。

どのシステムの値を正とするか

商品情報は、カート、基幹システム、卸向けのExcel、撮影用の資料と、複数の場所に分かれて存在しています。

点検で確かめるのは、値が食い違ったときにどれを信じるかです。ここが決まっていないと、整えたそばから元に戻ります。

正本を決めたら、更新の入口も一つにします。入口が二つある限り、表記ゆれは何度でも再発します。

属性設計より先に、手を止めたほうがいいとき

かいなは、データ整備や絞り込みの追加をおすすめしない場面があります。売り込みにならないよう、先に書いておきます。

商品点数が少なく、一覧で足りているECにはすすめません

取扱商品が数十点で、スクロールすれば全体を見渡せるEC。ここに多軸の絞り込みを足しても、押される回数はほとんど増えません。

この規模で伸び悩む理由は、探しにくさよりも商品ページの説得力にあることが多いです。

かいなはこの状態でERABの導入をおすすめしません。属性を設計する前に、写真と説明文の作り直しを提案します。

商品ページの情報が足りていないのに属性だけ増やすとき

絞り込みは、候補を減らすところまでしかできません。減らしたあとに決め手がなければ、お客様は結局戻ります。

比較表に並べたい項目が商品ページに載っていないなら、先に埋めるのは商品ページのほうです。

属性設計は、商品ページにある情報を並べ替える作業です。どこにもない情報は、属性にもできません。

全商品を一度に整えようとすると、公開まで届かない

数千点を一度に直す計画は、担当者の通常業務と必ずぶつかります。途中で止まった整備は、中途半端なデータだけを残します。

かいなは、売上の大半を占める商品群から先に整えることを提案しています。残りは絞り込みの対象から外したまま公開し、順に追加していきます。

全部が揃うまで待つ必要はありません。使われる軸から埋めたほうが、直す優先順位も見えてきます。

属性設計で判断が分かれるところ

ここからは、明日自分で判断できる基準に落とします。条件によって答えが変わるところだけを書きます。

属性の数は、迷いが「条件」か「用途」かで変わる

サイズや規格が合わなければ買えない商材では、属性は多いほど役に立ちます。型番から探す人は、軸が細かいほど早くたどり着きます。

一方、用途で迷う商材では、軸を増やすほど手が止まります。贈り先や予算のように、答えやすい問いを二つか三つ置くほうが進みます。

自社がどちらかを見分ける目安は、問い合わせの中身です。「この仕様はありますか」が多ければ条件型、「どれがいいですか」が多ければ用途型として設計します。

画像が揃っていないと、比較は成立しない

比較表を作ると、写真の背景や角度の違いが目立ちます。同じ条件で撮られていない商品は、並べた瞬間に見劣りします。

かいなは名古屋と東京に自社の撮影スタジオを持っていて、新商品や季節ごとに自分たちで撮り続けています。

そのぶん、トーンを揃えたまま積み上げたときの効き目も、崩れたときの見え方も実感しています。

比較を売り場の主役にするなら、属性表を作るのと同じタイミングで、撮影の基準も決めておきます。

カート側を直すか、外側に足すか

属性設計が固まったら、次はどこに実装するかです。カート本体に手を入れる方法と、外側のレイヤーに置く方法があります。

カート本体を触ると、決済や在庫にも影響が及びます。属性を試しながら決めたい段階では、動かしにくい構造になります。

かいなのERABは、読み取り専用のAPIやCSVだけで既存ECとつなぎ、カートを改修せずに選ぶ体験だけを足す構成にしています。

属性がまだ固まらない、やってみないと決まらない。その段階なら、外側に置いて試すほうが判断は早くなります。逆に軸が確定していて変える予定がないなら、カート側に持たせたほうが管理は素直です。

商品データの点検と属性設計、お気軽にご相談ください

商品データの整備は、直し始めると終わりが見えなくなる作業です。終わりを決めるのは、データの完成度ではなく、売り場での束ね方です。

かいなは自社でECを運営しながら、支援先の商品データも扱っています。どの属性を捨てるかという相談ができるのは、自分たちも同じ判断を繰り返しているからです。

ERABは既存ECに手を入れずに、選ぶ体験だけを足せる構成です。費用は体験の型と商品データの状態で変わるため、無料相談の場で概算をお伝えしています。

どこから点検すればいいか分からない段階でも構いません。ERABやECリニューアル・カート移行のページもあわせてご覧のうえ、30分の無料相談でお気軽にご相談ください。