Shopify Metafields vs. Tags. 为什么报表需要结构

正是metafields让一份Shopify报表能真正处理你的数据––对它做计算、分组、筛选––而不仅仅是把恰好挂在产品、订单或客户上的一段文字显示出来。这才是任何值得构建的 自定义报表下面真正的地基：底层数据从一开始是否就被结构化，好让这类分析成为可能。

跟卖家一起做过很多进阶报表需求之后，当一份报表对不上时，我反复撞上的根源都是同一个：数据从来没有为分析而结构化过––它只是当时最快能写进去的文字。 报表因此前后不一，筛选很快就没得可选，最后每个月都有人把同一批数字用手重新算一遍。（关于Shopify原生分析工具单独能做什么、不能做什么的更宏观视角，请参阅我们的 Shopify Analytics完全指南。）

为什么metafields更适合分析

Metafields让你能把结构化的字段––不仅仅是自由文本––附加到产品、变体、客户、订单以及大多数其他Shopify资源上。以佣金比例为例：它不再是 20%这样的tag，而是一个被明确定义的字段：

• Namespace：commission
• Key：rate
• Value：20

现在「20」是系统可以直接使用的数字，而不是需要猜的文本。也正因如此，报表工具才可以根据实际销售额自动计算每位销售代表应得的佣金，而不用有人再去导出一份表格 用手算。同样的思路用于供应商名称：namespace vendor，key name，value Vendor_1 ––报表就能直接按供应商分组， 而不是去猜哪些tag碰巧代表供应商。

这正是一款专门的Shopify报表应用被设计来做的计算––只要底层字段是结构化的，它就能把一件人工表格活儿，变成一份会自己更新的报表。这也是Shopify数据之上那层 自定义报表的全部意义––报表能有多可靠，取决于它读取的字段有多可靠。（可附加metafields的资源完整清单， 可以在Shopify官方的 metafields文档中查看。）

Tags在哪里力不从心

Tags是Shopify里最灵活的功能之一：好创建、好更新，非常适合组织产品、客户和订单。它们只是从未被设计成同时充当报表用的结构化数据。

Tag本质上是文本。用来给东西贴个标签，够用。但一旦要以任何精度去计算、汇总或筛选，它就会立刻散架。

把同一个佣金比例，按许多卖家实际打tag的方式来标一遍：

• 10%
• 15%
• 20%

你的员工读这些值没问题。但你的报表系统读不了––至少读不可靠。它没有办法知道「20」是一个可以做加减乘除的数字，而不是一段看起来像数字的字符串。

同样的问题也出现在非数值型数据上。把产品直接打上供应商名的tag––Vendor_1、Vendor_2、Vendor_3–– 报表根本没办法知道这些tag代表的就是「供应商」，而不是你可能贴到产品上的其他任何东西。它可以把tag列出来，但它没法按供应商分组。

并排一比，同一份产品数据长这样：

非结构化数据的隐性成本

店铺刚上线时，优先级永远是速度。产品信息、客户属性、运营细节––团队会填在当下最顺手的地方。

但随着店铺成长，问题会越来越难：

• 哪些产品给销售代表带来最高的佣金？
• 在特定产品属性维度上，销售表现如何比较？
• 哪些客户细分带来最多的收入？
• 在自定义的业务指标下，业绩如何变化？

就是在这个节点上，你当初怎么存数据不再是一个技术细节，而是直接决定你能不能拿到一个可信的答案。如果信息只以自由文本或tag的形式存在， 从里头抠出一个能相信的数字，很快就变得很难––而且无论上层的报表工具多好，它都会一直难。

真正的代价不是一份错的报表––而是不断重返的人工返工

当一份建立在tag之上的报表看起来不对时，报表本身的逻辑通常没什么问题。真正的问题在数据结构上––它的表现形式不是一次性出错，而是持续不断的手工劳动。 一份被写成对照一份固定tag值列表的报表––具体的供应商名、具体的佣金档位––只认识写它的时候存在的那些值。新加一个供应商、新增一个档位，报表自己不会 把它拾起来；得有人注意到，然后回去用手更新公式。

Metafields没有这个问题。一份被写成读取vendor或commission rate字段的报表，会读它里面真正存的那个值––新供应商或新费率 会在下一次运行时直接出现，不需要更新任何东西。

如果一份报表看起来不对，别先质疑报表本身。先拿它的结果和同一时段的Shopify原生API数据对一下。这个对比会告诉你差异是活在报表层，还是活在最初存储底层信息的方式里。 数据的设计首先追求的是操作层面的便利（好录入、员工好一眼扫），其次––甚至可能根本轮不到––才是分析上的一致性。而人工更新公式，正是这个折中最后会来找你算账的地方。

给每一个新字段的一条实用规则

在创建一个tag或一个metafield之前，问自己一个问题：你会不会有一天需要按这条信息去筛选、分组、汇总或者计算？

如果会，那它属于metafield，不属于tag。规则就这一条。

结构化的数据能带给你：

• 一致的格式
• 可靠的筛选与细分
• 真正可以相信的计算
• 随着目录和订单量增长仍然能继续工作的报表

这些都不代表tag该退休。快速、轻量的组织仍然是它的地盘––把产品打上「clearance」，把客户标成「VIP」，不需要metafield。这条规则比「别再用tag了」窄很多： 如果一个值需要在报表里作为可量化的东西出现，就别让它留在tag里。

如果你正在把已有的tag数据往metafield迁移––佣金比例、忠诚度等级，或者你早期用tag标过的任何东西––给自己预留一段时间做一次性的清理。搬值本身是简单的部分。 提前想清楚namespaces和字段类型，才是让你不必再做第二次迁移的关键。

在你构建下一份报表之前

请先检查它背后的数据到底是怎么存的––而不是这份报表是怎么搭的。这个决定很少是那个最终去拉数字的人做的。它是几周甚至几个月之前，由某个当时根本没想过分析、 只是加了一个字段的人做的。

如果你想看看现有的metafields已经能支持什么，Mipler可以根据你店铺里已有的 metafields来生成Shopify报表，并附带100多个现成模板，免得你从一张白纸开始。

一旦字段结构化了，你可以对它们提的问题也会更有意思––想看一个具体例子，请参阅 哪些首单产品能把买家转化为回头客。

FAQ