Shopify Metafields vs. Tags. Чому звітам потрібна структура

Саме метаполя (metafields) дають Shopify-звіту змогу реально працювати з вашими даними – обчислювати їх, групувати, фільтрувати – а не просто відображати випадковий текст, прикріплений до товару, замовлення чи клієнта. Це справжній фундамент будь-якого кастомного звіту, який варто будувати: чи були базові дані від початку структуровані так, щоб з ними можна було працювати.

Працюючи з мерчантами над складними запитами до звітності, я постійно наштовхуюсь на одну й ту саму першопричину, коли звіт не сходиться: дані ніколи не були структуровані для аналізу – це просто текст, який заносили туди, де було найшвидше. Звіти виходять непослідовними, фільтрація швидко впирається в стелю, і хтось знову перебудовує ті самі числа вручну щомісяця. (Ширшу картину того, що вбудована Shopify-аналітика може, а що – ні, дивіться в нашому повному гайді по Shopify Analytics.)

Чому метаполя краще підходять для аналітики

Метаполя дозволяють прикріплювати структуровані поля – не просто вільний текст – до товарів, варіантів, клієнтів, замовлень і більшості інших ресурсів Shopify. Візьмімо комісійну ставку: замість тегу на кшталт 20% вона стає визначеним полем:

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

Тепер «20» – це число, з яким система вміє працювати, а не текст, який треба вгадувати. Саме це дозволяє звітному інструменту автоматично обчислювати комісію для кожного менеджера з продажів на основі реальних продажів – замість того щоб хтось експортував таблицю та рахував руками. Той самий підхід працює й для назв постачальників: namespace vendor, key name, value Vendor_1 – і звіт уже може групувати дані за постачальником напряму, замість того щоб вгадувати, які саме теги позначають постачальника.

Саме такі обчислення й покликаний виконувати спеціалізований застосунок для звітності Shopify, щойно базове поле стає структурованим: перетворюючи ручну роботу з таблицями на звіт, що оновлюється сам. У цьому й полягає весь сенс шару кастомних звітів над даними Shopify – він настільки надійний, наскільки надійні поля, з яких він читає. (Повний перелік ресурсів, до яких можна прикріпляти метаполя, є у власній документації Shopify з метаполів.)

У чому теги недотягують

Теги – одна з найгнучкіших можливостей Shopify: їх легко створювати, легко оновлювати, вони зручні для організації товарів, клієнтів і замовлень. Просто вони не задумувалися як структуровані дані для звітності.

Тег – це текстове значення. Це нормально, коли треба просто наліпити ярлик. Але воно розсипається в ту ж секунду, коли треба щось порахувати, агрегувати чи точно відфільтрувати.

Візьмімо ту саму комісійну ставку, але в тегах – так, як багато мерчантів її позначають:

• 10%
• 15%
• 20%

Ваші співробітники прочитають ці значення без проблем. Ваша звітна система – ні, принаймні не надійно. Вона не має способу зрозуміти, що «20» – це число, з яким можна робити математику, а не просто рядок, який на нього схожий.

Та сама проблема виринає й з нечисловими даними. Позначте товари прямо іменами постачальників – Vendor_1, Vendor_2, Vendor_3 – і звіт не має жодного способу зрозуміти, що ці теги означають саме «постачальник», а не щось інше, чим ви могли б позначити товар. Він може перелічити теги. Але не може згрупувати за постачальником.

Поруч ті самі дані про товар виглядають так:

Прихована ціна неструктурованих даних

Коли магазин щойно стартує, у пріоритеті швидкість. Інформацію про товар, атрибути клієнтів, операційні деталі – команди додають туди, де в моменті зручніше.

Але з розвитком магазину питання стають складнішими:

• Які товари приносять найвищі комісійні для менеджерів з продажу?
• Як виглядають продажі в розрізі конкретних атрибутів товару?
• Які сегменти клієнтів генерують найбільшу виручку?
• Як показники змінюються в розрізі кастомних бізнес-метрик?

Це той момент, коли спосіб зберігання даних перестає бути технічним нюансом і починає визначати, чи отримаєте ви взагалі надійну відповідь. Якщо інформація існує лише як вільний текст або теги, витягнути з неї число, якому можна довіряти, стає складно – і залишиться складно, наскільки б хорошим не був інструмент звітності поверх.

Справжня ціна – не помилковий звіт, а ручні переробки

Коли звіт, побудований на тегах, виглядає неправильно, з логікою звіту зазвичай усе гаразд. Проблема – у структурі даних. І проявляється це не як одноразова помилка, а як постійна ручна робота. Звіт, побудований під фіксований список тегових значень – конкретні імена постачальників, конкретні рівні комісії, – знає лише про ті значення, що існували на момент його створення. З'являється новий постачальник чи новий рівень – і звіт сам його не підхопить: хтось має помітити й піти вручну оновлювати формулу.

З метаполями такої проблеми немає. Звіт, налаштований читати поле vendor чи commission rate, читає те значення, яке насправді там збережене – новий постачальник чи нова ставка з'являться в наступному запуску звіту, і оновлювати нічого не треба.

Якщо звіт виглядає неправильно, не починайте з сумнівів у самому звіті. Почніть із порівняння його результатів з даними Shopify API за той самий період. Це порівняння показує, чи розбіжність живе у шарі звітності, чи у способі зберігання базової інформації від самого початку. Дані проєктують спочатку під операційну зручність (швидко ввести, легко переглянути очима), а вже потім – під аналітичну послідовність, якщо взагалі. І саме ручні оновлення формул – це те місце, де такий компроміс наздоганяє вас.

Практичне правило для будь-якого нового поля

Перш ніж створити тег чи метаполе, поставте одне питання: чи знадобиться вам колись фільтрувати, групувати, підсумовувати чи обчислювати цю інформацію?

Якщо так – це метаполе, а не тег. Ось і все правило.

Структуровані дані дають вам:

• Узгоджене форматування
• Надійну фільтрацію та сегментацію
• Обчислення, яким справді можна довіряти
• Звіти, які продовжують працювати, коли ростуть каталог та обсяг замовлень

Це не означає, що теги списують у тираж. Вони й далі – правильний інструмент для швидкої, «легковагої» організації: позначити товар як «clearance» чи клієнта як «VIP» не потребує метаполя. Правило вужче за «перестати користуватися тегами»: якщо значення має з'явитися у звіті як щось вимірне, не лишайте його в тезі.

Якщо ви мігруєте існуючі дані з тегів – комісійні ставки, рівні лояльності, будь-що, що позначали тегами на старті, – закладіть час на разову зачистку. Перенести самі значення – це проста частина. А от продумати namespaces та типи полів наперед – це те, що врятує вас від повторної міграції другим заходом.

Перш ніж будувати наступний звіт

Перевірте, як насправді зберігаються дані під ним – а не те, як побудований сам звіт. Це рішення рідко ухвалює той, хто наприкінці витягує числа. Його приймають за тижні чи місяці до цього – той, хто додав поле і взагалі не думав про аналітику.

Якщо хочете побачити, що вже підтримують ваші наявні метаполя – Mipler будує Shopify-звіти з метаполів, які у вас уже є, з понад 100 готовими шаблонами, якщо не хочете починати з чистого аркуша.

Коли поля структуровані, питання, які можна ставити, стають цікавішими – як один робочий приклад дивіться які товари з першого замовлення перетворюють покупців на постійних клієнтів.

FAQ