Structured Data Dimensi Produk: Field yang Jarang Diisi

Structured data dimensi produk adalah bagian listing yang tidak pernah dibaca oleh apa pun yang punya mata — dan sekarang justru bagian itulah yang menentukan apakah produk Anda muncul di sebuah jawaban atau tidak. Anda menaruh 600 × 320 × 720 mm di gambar spesifikasi. Pembeli membacanya. Crawler, feed shopping, dan asisten yang menjawab "lemari dinding mana yang kedalamannya di bawah 350 mm?" tidak membaca apa pun, karena angka itu hanya ada sebagai piksel.

Structured data dimensi produk berarti deklarasi ukuran fisik produk yang bisa dibaca mesin: field bernama yang membawa nilai angka dan satuan eksplisit, dipublikasikan sebagai JSON-LD di halaman produk atau sebagai kolom di feed merchant. Sekarang ada tiga spesifikasi berbeda yang mendefinisikan field itu, nama-namanya tidak seragam, dan sebagian besar katalog tidak mengisi satu pun.

Berikut seluruh bloknya, field demi field, lengkap dengan versi siap tempel di bagian akhir.

Structured data dimensi produk: tiga spesifikasi yang membaca ukuran Anda

Baca baris terakhir dua kali, karena di situlah jebakan yang hampir semua katalog masuki.

Field dimensi Google mendeskripsikan kardus Anda, bukan produk Anda

shipping_length, shipping_width, dan shipping_height bersifat opsional, menerima sentimeter atau inci, dan dibatasi pada 1–400 cm atau 1–150 inches. Google menyatakan tugasnya dengan terang: field itu ada untuk membantu menentukan biaya pengiriman ketika Anda memakai metode yang dihitung kurir. Ketiganya harus diisi bersamaan dengan satuan yang sama, atau datanya tidak bisa dipakai sama sekali.

Jadi yang mereka deskripsikan adalah kardus. Tidak ada atribut Merchant Center untuk dimensi produk jadinya sendiri.

Celah itulah yang membuat product_detail lebih penting bagi Anda daripada field mana pun di halaman ini. Field ini membawa spesifikasi teknis yang tidak tercakup atribut lain, dalam format tiga bagian yang dipisahkan tepat dua tanda titik dua:

section_name : attribute_name : attribute_value

section_name opsional tapi disarankan; attribute_name dan attribute_value wajib. Contoh dari Google sendiri mengikuti pola Display:Size:13 inch dan Battery:Capacity:12.5 hours. Artinya, tempat yang benar untuk ukuran nyata sebuah produk di feed Google terlihat seperti ini:

Dua aturan supaya ini tetap bersih. Taruh satuannya di dalam attribute_value — field ini teks bebas dan angka "600" telanjang tidak bisa dipakai. Dan jangan pernah mengulang apa pun yang sudah punya atributnya sendiri: Google melarang Anda menduplikasi informasi yang sudah tercakup di tempat lain, dan data harga atau estimasi waktu pengiriman jelas-jelas tidak boleh masuk ke sini.

schema.org: empat field plus satu yang tidak dipakai siapa pun

Di halaman itu sendiri, schema.org memberi Product properti dimensi langsung, masing-masing menerima Distance atau QuantitativeValue:

• width — "Lebar item tersebut."
• height — "Tinggi item tersebut."
• depth — "Kedalaman item tersebut."
• weight — sebuah Mass atau QuantitativeValue.

Lalu ada size, field yang jenisnya berbeda dan rutin salah pakai. Definisinya mengizinkan string teks biasa seperti XL atau 32Wx34L, sebuah QuantitativeValue dengan unitCode, atau SizeSpecification utuh — dan disebut terang-terangan bahwa kalau semua itu tidak cocok, "properti width, height, depth, dan weight mungkin lebih tepat." Terjemahannya untuk siapa pun yang menjual barang selain pakaian: pakai size untuk sistem ukuran garmen, pakai empat properti dimensi untuk barang fisik, dan jangan menaruh 600x320x720 di size sebagai string.

Field yang tidak dipakai siapa pun adalah hasMeasurement, sebuah QuantitativeValue di Product yang ditujukan untuk pengukuran item — contoh dari schema.org sendiri adalah panjang dalam kaki celana, ukuran roda sepeda, dan ukuran diameter sekrup. Field ini menerima array, jadi di sinilah tempat setiap dimensi sekunder: lebar rak bagian dalam, tinggi dudukan, jarak titik pemasangan, bukaan, kisar ulir. Inilah angka-angka yang ditanyakan pembeli lewat email, dan field standarnya sudah tersedia — dibiarkan kosong di hampir semua katalog.

Untuk satuan, unitCode memakai common code 3 karakter UN/CEFACT — MMT milimeter, CMT sentimeter, INH inci, KGM kilogram, LBR pon. Kalau Anda tidak yakin kodenya, unitText dengan string biasa tetap valid dan lebih baik daripada kode yang salah.

Siap tempel: blok dimensi JSON-LD

Tempel ini di dalam node Product yang sudah Anda punya. Lolos validasi, lengkap, dan sengaja memisahkan ukuran produk dari ukuran kardus.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wall cabinet, 2-door, 600 mm",
  "sku": "WC-600-2D",
  "material": "Birch plywood, white melamine",
  "width":  { "@type": "QuantitativeValue", "value": 600, "unitCode": "MMT" },
  "height": { "@type": "QuantitativeValue", "value": 720, "unitCode": "MMT" },
  "depth":  { "@type": "QuantitativeValue", "value": 320, "unitCode": "MMT" },
  "weight": { "@type": "QuantitativeValue", "value": 14.2, "unitCode": "KGM" },
  "hasMeasurement": [
    { "@type": "QuantitativeValue", "name": "Internal shelf width",
      "value": 564, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Wall fixing centres",
      "value": 512, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Carton, longest side",
      "value": 760, "unitCode": "MMT" }
  ]
}

Feed ChatGPT mau angka yang sama dengan nama field yang berbeda

Spesifikasi product feed Agentic Commerce — file yang dikirim merchant untuk permukaan shopping ChatGPT — menerima dimensi dengan dua cara, dan aturan dependensinya ketat:

Spesifikasinya menyatakan bahwa karakteristik fisik dan klasifikasi membantu kategorisasi, filtering, dan relevansi pencarian — dan itu artinya, secara gamblang, produk tanpa dimensi adalah produk yang tidak bisa difilter masuk ke kumpulan hasil. Kalau pembeli mencari lemari dengan kedalaman di bawah 350 mm dan field depth Anda kosong, Anda bukan berperingkat rendah. Anda tidak ada.

Satu celah yang perlu diakui: spesifikasinya tidak mendefinisikan field dimensi kemasan yang terpisah, dan tidak menyebutkan apakah dimensions berarti produknya atau kardusnya. Nyatakan mana yang Anda maksud di tempat yang bisa dibaca manusia sekaligus model, dan konsisten di seluruh katalog Anda.

Kenapa field ini layak diisi meski Google tidak menampilkannya

Ini bagian yang kedengarannya seperti kontradiksi. Dokumentasi Product structured data milik Google sendiri, yang mencantumkan apa saja yang bisa memberi Anda rich result, tidak memasukkan width, height, depth, weight, atau hasMeasurement. Daftar yang didukungnya berhenti di harga, ketersediaan, rating ulasan, pengiriman, kebijakan pengembalian, ukuran pakaian, identifier, serta kelebihan dan kekurangan.

Jadi markup dimensi tidak akan membuat snippet Anda jadi lebih besar. Dari awal memang bukan itu tugasnya.

Yang berubah adalah konsumennya. Google menyebut product_detail menyediakan structured data yang membantunya memahami dan menampilkan produk di berbagai permukaan, termasuk fitur berbasis AI seperti AI Mode di Search; feed Agentic Commerce ada supaya produk bisa ditemukan dan difilter di dalam sebuah chat. Sistem seperti itu tidak butuh template visual untuk aktif — mereka butuh atribut yang bisa dibandingkan dengan sebuah batasan. Field dimensi bukan lagi hiasan di hasil pencarian. Itulah yang membuat Anda memenuhi syarat untuk diambil mesin.

Ini membalik prioritasnya: isi field ini untuk mesin yang menjawab pertanyaan, bukan untuk mesin yang menggambar kotak.

Aturan yang merusak semuanya: satu angka, dua tempat

Setiap kegagalan yang pernah saya lihat pada structured data dimensi produk berakar dari hal yang sama — feed bilang satu hal, gambar bilang hal lain.

Terjadinya pun tanpa niat buruk. Ada yang mengetik ukuran kardus ke shipping_width, orang lain mengukur unit yang sudah dirakit untuk diagram spesifikasi, orang ketiga membulatkan 564 mm menjadi 56 cm di product_detail. Sekarang sebuah asisten dengan yakin memberi tahu pembeli bahwa lemarinya selebar 640 mm, pembeli melihat gambar Anda yang menulis 600, dan Anda baru saja memproduksi masalah kepercayaan plus satu pengembalian barang. Lebih buruk lagi, angka yang dikutip adalah angka yang dibaca mesin, karena itulah angka yang terbaca.

Perbaikannya ada di proses, bukan di markup: ukur sekali, lalu terbitkan hasil ukuran yang sama itu ke field dan ke gambar. Konkretnya —

1. Ukur barang jadinya, bukan gambar teknisnya dan bukan kardusnya, lalu catat angka mana merujuk ke yang mana.
2. Taruh setiap angka di gambar tepat pada fitur yang dijelaskannya — menempel ke tepi asli produk, bukan mengapung di dekatnya — dan ekspor sesuai ukuran diagram spesifikasi masing-masing platform. Software yang memang dibuat untuk anotasi dimensi melakukan ini secara deterministik, dan di situlah bedanya dengan editor foto umum tempat Anda menempatkan panah pakai tangan, atau dengan image generator yang dengan senang hati merender dimensi yang tidak pernah diukurnya, karena yang dioptimalkannya adalah tampak masuk akal.
3. Salin angka yang sama ke width/height/depth, product_detail, dan field dimensi di feed. Sumber sama, pembulatan sama, satuan sama.
4. Kalau sebuah angka berubah, ubah di kedua tempat dalam satu commit yang sama. Pasangan angka yang melenceng lebih buruk daripada angka yang tidak ada.

Contoh nyata untuk sisi gambar dari pasangan itu ada di studi kasus label ukuran produk, dan soal satuan yang menjegal separuh eksportir dibahas di dimensi produk pakai cm atau inci.

Checklist sebelum publikasi

• width, height, depth ada di node Product, masing-masing sebagai QuantitativeValue dengan unitCode atau unitText
• weight ada dan pakai satuan
• Setiap dimensi sekunder yang benar-benar ditanyakan pembeli ada di hasMeasurement dengan name yang deskriptif
• size hanya dipakai untuk sistem ukuran pakaian — tidak ada string 600x320x720
• Feed: shipping_length / shipping_width / shipping_height ketiganya ada, satuan sama, dan mendeskripsikan kardus
• Feed: dimensi produk setelah dirakit ada di product_detail, satuan di dalam nilainya, tepat dua tanda titik dua per entri
• Feed: tidak ada duplikasi data yang sudah punya atribut sendiri; tidak ada harga atau estimasi waktu pengiriman di dalam product_detail
• Feed agentic: pakai dimensions beserta satuannya, atau length+width+height plus dimensions_unit
• Feed agentic: weight jangan pernah dikirim tanpa item_weight_unit
• Dimensi produk dan dimensi kardus diberi label yang jelas berbeda di semua tempat kemunculannya
• Setiap angka di markup cocok dengan angka yang tercetak di gambar spesifikasi, sampai milimeter
• Ada satu orang yang ditunjuk sebagai penanggung jawab kecocokan itu, supaya tidak ada yang mengedit satu sisi saja

FAQ

Bagaimana cara menambahkan dimensi produk ke structured data?

Taruh width, height, depth, dan weight di node Product Anda dalam JSON-LD, masing-masing sebagai QuantitativeValue dengan value berupa angka dan sebuah unitCode. Tambahkan setiap fitur terukur lainnya sebagai entri di hasMeasurement dengan name yang deskriptif. Di feed Google, ukuran setelah dirakit tempatnya di product_detail, bukan di field shipping_*.

Apakah Google memakai width, height, dan depth dari Product schema?

Tidak untuk rich result. Properti produk yang didukung Google mencakup harga, ketersediaan, ulasan, pengiriman, kebijakan pengembalian, ukuran pakaian, identifier, serta kelebihan dan kekurangan — dimensi fisik tidak ada di daftar itu. Tapi dimensi tetap penting untuk pengambilan data dan perbandingan di permukaan berbasis AI, dan itu tugas yang berbeda serta sekarang lebih besar.

Apa bedanya shipping_length dengan ukuran asli produk?

shipping_length, shipping_width, dan shipping_height mendeskripsikan kemasan pengiriman, dan ada supaya tarif yang dihitung kurir bisa dikalkulasi. Field itu bukan dimensi produk jadinya dan jangan diisi dengan itu. Merchant Center tidak punya atribut khusus untuk ukuran setelah dirakit, dan karena itulah product_detail adalah tempat yang benar untuknya.

Kode satuan mana yang harus dipakai untuk dimensi di JSON-LD?

unitCode memakai common code 3 karakter UN/CEFACT — MMT untuk milimeter, CMT sentimeter, INH inci, KGM kilogram, LBR pon. Kalau Anda tidak yakin kode untuk sebuah satuan, pakai unitText dengan string biasa saja; unitText yang terbaca lebih baik daripada unitCode yang salah.

Kalau dimensi sudah ada di feed, apakah masih perlu ditulis di gambar produk?

Perlu, dan alasannya simetris. Mesin membaca field dan tidak bisa membaca gambar Anda; pembeli membaca gambar dan tidak akan pernah membuka feed Anda. Diagram dimensi Anda adalah gambar, sementara setiap sistem yang memutuskan apakah produk Anda muncul di sebuah jawaban membaca teks — jadi kirim keduanya, dan bikin keduanya cocok sampai milimeter. Cara merumuskan sisi gambarnya supaya pembeli benar-benar bertindak dibahas di cara menyampaikan dimensi produk ke pembeli; kalau Anda mau tahu ongkos salahnya dalam bentuk uang, kalkulator biaya pengembalian yang menghitungnya.

Sumber dan Referensi

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode, dan unitText
• Google Merchant Center — atribut dimensi pengiriman dan batasannya
• Google Merchant Center — atribut product detail [product_detail]
• Google Search Central — Product structured data dan properti yang didukung
• Agentic Commerce — spesifikasi product feed