Shopify Metafields vs. Tags. なぜレポートには構造が必要なのか

Shopifyのレポートが、商品・注文・顧客にたまたま付いているテキストを表示するだけでなく、実際にデータを扱える――計算し、グループ化し、フィルタリングできる――のは、 metafieldsがあるからです。それこそが、作る価値のあるすべての カスタムレポートの本当の土台です。つまり、そもそも基礎データがそうした処理を支えられるだけ構造化されていたかどうか、という土台です。

マーチャントの高度なレポートニーズに向き合ってきた経験から言うと、レポートが合わないときに繰り返し行き着く根本原因は決まっています――データが分析のために構造化されたことがなく、 その場で一番早い場所に入力された「ただのテキスト」であるということです。レポートは一貫性を欠き、フィルタリングはすぐに選択肢が尽き、 誰かが毎月同じ数字を手作業でやり直すはめになります。（Shopifyの内蔵アナリティクスが単独でできること・できないことの全体像は、 Shopify Analyticsの完全ガイドをご覧ください。）

なぜmetafieldsは分析に向いているのか

Metafieldsを使うと、商品、バリアント、顧客、注文、そしてその他ほとんどのShopifyリソースに、フリーテキストではなく 構造化されたフィールドを紐づけられます。たとえば手数料率を考えてみます。20%のようなタグの代わりに、定義されたフィールドになります。

• Namespace: commission
• Key: rate
• Value: 20

これで「20」はシステムが扱える数値になり、意味を推測しなければならないテキストではなくなります。おかげでレポートツールは、実際の売上に基づいて 各営業担当者への手数料を自動計算できます。誰かがスプレッドシートをエクスポートして手で計算する必要はありません。同じアプローチはベンダー名にも使えます。 namespace vendor、key name、value Vendor_1――これでレポートは、どのタグがたまたまベンダー名なのかを推測することなく、 ベンダー単位でそのままグループ化できるようになります。

これはまさに、基礎フィールドが構造化されたときに、専用のShopifyレポートアプリが担うべき計算です。手作業のスプレッドシート作業を、自動で更新されるレポートに変えるのです。 それこそが、Shopifyデータの上に載せるカスタムレポート層の意味そのものです―― レポートは、その下にあるフィールドと同じだけしか信頼できません。（metafieldsを紐づけられるリソースの一覧は、Shopify自身の metafieldsドキュメントにすべて載っています。）

タグが力不足になる場面

タグはShopifyの最も柔軟な機能の一つです。作成も更新も簡単で、商品、顧客、注文の整理に役立ちます。ただし、レポート用の構造化データも同時にこなすようには 設計されていません。

タグはテキスト値です。何かに「ラベルを貼る」だけなら十分です。しかし、少しでも精度を持って計算・集計・フィルタリングしようとした瞬間に破綻します。

同じ手数料率を、多くのマーチャントが実際にタグで表現しているとおりに置き換えてみます。

• 10%
• 15%
• 20%

スタッフはこの値を問題なく読めます。しかしレポートシステムは違います――少なくとも安定して読むことはできません。「20」が計算に使える数値なのか、 単に数値のように見える文字列なのかを判断する術がないからです。

同じ問題は、数値ですらないデータにも起こります。商品にベンダー名を直接タグ付けしたとします―― Vendor_1、Vendor_2、Vendor_3――しかしレポートには、これらのタグが「ベンダー」を表しているのか、 それとも他のあらゆる要素を表しているのかを知る手立てがありません。タグを列挙することはできても、ベンダー単位でグループ化することはできません。

並べて見ると、同じ商品データはこう見えます。

構造化されていないデータの隠れたコスト

ストアを立ち上げた直後は、スピードが最優先です。商品情報、顧客属性、業務上の細かなデータ――チームはその場で一番便利なところに入力します。

ストアが成長するにつれ、問いは難しくなっていきます。

• 営業担当者に最も高い手数料をもたらす商品はどれか？
• 特定の商品属性で見ると、売上はどう比較できるか？
• どの顧客セグメントが最も売上を生んでいるか？
• 独自のビジネス指標で見たとき、パフォーマンスはどのように変わるか？

ここで、データをどう保存したかは、もはや技術的な細部ではなくなり、信頼できる答えが得られるかどうかそのものを左右し始めます。 情報がフリーテキストやタグの形でしか存在していなければ、そこから信頼できる数字を引き出すのはあっという間に難しくなります―― そして上に載せるレポートツールがどれほど優秀でも、その難しさは変わりません。

本当のコストは間違ったレポートではなく――手作業のやり直し

タグに基づいて作られたレポートが間違って見えるとき、レポート側のロジックはたいてい問題ありません。本当の問題はデータ構造にあります―― そしてそれは一度きりのミスとしてよりも、継続する手作業として現れます。決まったタグ値のリスト――特定のベンダー名、特定の手数料階層――に 照らし合わせるように作られたレポートは、誰かがそれを作った時点で存在していた値しか知りません。新しいベンダーや新しい階層が加わっても、 レポートは自力ではそれを拾いません。誰かがそれに気づき、手動で数式を更新しに戻る必要があります。

Metafieldsにはその問題がありません。vendorやcommission rateフィールドを読むように作られたレポートは、 そこに実際に保存されている値を読みます――新しいベンダーや新しいレートは、次のレポート実行時にそのまま現れ、更新する必要はありません。

レポートが間違って見えたら、まずレポートを疑うのはやめましょう。同じ期間について、Shopify自身のAPIデータと結果を比較することから始めてください。 その比較が、ズレがレポート層にあるのか、そもそもの基礎情報の保存の仕方にあるのかを教えてくれます。データはまず業務上の使いやすさ （入力が速く、スタッフが目で追いやすい）を優先して設計され、その次にようやく――設計されるとしても――分析上の一貫性が来ます。 そして手作業による数式のメンテナンスこそ、そのトレードオフのツケが必ずまわってくる場所です。

新しいフィールドを追加するときの実用ルール

タグでもmetafieldでも、作る前に一つだけ質問してください。この情報を、いつかフィルタリング、グループ化、集計、あるいは計算する必要が あるでしょうか？

もし「はい」なら、その情報の居場所はタグではなくmetafieldです。ルールはそれだけです。

構造化されたデータは、次のものをもたらします。

• 一貫したフォーマット
• 信頼できるフィルタリングとセグメンテーション
• 本当に信頼できる計算
• カタログや注文量が増えても動き続けるレポート

これでタグが引退するわけではありません。素早く、軽い整理には引き続きタグが正解です――商品を「clearance」、顧客を「VIP」と印付けるのに metafieldは要りません。ルールは「タグを使うのをやめよう」よりずっと限定的です。値がレポートに「測れるもの」として現れる必要があるなら、 それをタグに置きっぱなしにしないでください。

既存のタグデータを移行する場合――手数料率、ロイヤルティランク、初期の頃にタグで表現していたものは何でも――一度きりのクリーンアップに時間を 見込んでください。値そのものを移すのは簡単な方です。事前にnamespaces（名前空間）とフィールド型を決めておくことこそが、移行を2度やる羽目に ならないための鍵です。

次のレポートを作る前に

レポートの作り方ではなく、その裏でデータが実際にどう保存されているかを確認してください。この意思決定は、最終的に数字を取り出す人が下すことは ほとんどありません。数週間、あるいは数ヶ月前に、フィールドを追加した人が――アナリティクスのことなど一切考えずに――下しているのです。

既存のmetafieldsがすでに何をサポートしているかを確認したい場合、Miplerは metafieldsから作るShopifyレポートを、 すでにストアが持っているデータを使って構築します。白紙から始めたくない場合に備えて、100以上のテンプレートも用意しています。

フィールドが構造化されたら、そこから引き出せる問いはさらに面白くなります――具体例としては、 どの初回注文商品が購入者をリピーターに変えるのかもご覧ください。

FAQ