ข้อมูลโครงสร้าง ขนาดสินค้า: ฟิลด์ที่ไม่มีใครกรอก

ข้อมูลโครงสร้าง ขนาดสินค้า คือส่วนของหน้าสินค้าที่ไม่มีสายตามนุษย์คนไหนอ่าน — แต่ตอนนี้มันกลายเป็นส่วนที่ตัดสินว่าสินค้าของคุณจะโผล่ขึ้นมาในคำตอบหรือไม่ คุณใส่ 600 × 320 × 720 mm ไว้บนภาพสเปก ลูกค้าอ่านออก แต่ crawler, ฟีดสินค้า และผู้ช่วย AI ที่กำลังตอบคำถามว่า «ตู้แขวนผนังรุ่นไหนลึกไม่เกิน 350 mm» อ่านไม่ออกเลย เพราะตัวเลขนั้นมีอยู่ในรูปของพิกเซลเท่านั้น

ข้อมูลโครงสร้าง ขนาดสินค้า หมายถึงการประกาศขนาดทางกายภาพของสินค้าในรูปแบบที่เครื่องอ่านได้ นั่นคือฟิลด์ที่มีชื่อชัดเจน บรรจุค่าตัวเลขและระบุหน่วยไว้ตรง ๆ เผยแพร่ผ่าน JSON-LD บนหน้าสินค้า หรือเป็นคอลัมน์ในฟีดสำหรับร้านค้า ทุกวันนี้มีข้อกำหนดสามชุดที่นิยามฟิลด์เหล่านี้ ชื่อฟิลด์ของแต่ละชุดไม่ตรงกัน และแคตตาล็อกส่วนใหญ่ไม่ได้กรอกชุดไหนเลย

ด้านล่างคือบล็อกทั้งชุด ไล่ทีละฟิลด์ พร้อมเวอร์ชันคัดลอกไปใช้ได้ทันทีอยู่ท้ายบทความ

ข้อมูลโครงสร้าง ขนาดสินค้า: ข้อกำหนดสามชุดที่อ่านขนาดของคุณ

อ่านแถวล่างสุดสองรอบ เพราะในนั้นมีกับดักที่แคตตาล็อกแทบทุกเจ้าตกลงไป

ฟิลด์ขนาดของ Google อธิบายกล่องของคุณ ไม่ใช่ตัวสินค้า

shipping_length, shipping_width และ shipping_height เป็นฟิลด์ที่ไม่บังคับ รับได้ทั้งเซนติเมตรและนิ้ว และจำกัดช่วงไว้ที่ 1–400 cm หรือ 1–150 inches ตัว Google ระบุหน้าที่ของมันไว้ชัดเจนว่ามีไว้ช่วยคำนวณค่าขนส่งเมื่อคุณใช้วิธีคิดค่าส่งแบบ carrier-calculated ทั้งสามฟิลด์ต้องส่งมาพร้อมกันและใช้หน่วยเดียวกัน ไม่อย่างนั้นข้อมูลจะใช้ไม่ได้เลย

พูดง่าย ๆ คือฟิลด์กลุ่มนี้อธิบายกล่องบรรจุ ส่วน Merchant Center ไม่มี attribute ไว้สำหรับขนาดของตัวสินค้าที่ประกอบเสร็จแล้วเลย

ช่องว่างนี้คือเหตุผลที่ product_detail สำคัญกับคุณมากกว่าฟิลด์อื่นใดในหน้านี้ มันใช้บรรจุสเปกทางเทคนิคที่ attribute อื่นไม่ครอบคลุม โดยเขียนเป็นสามส่วน คั่นด้วยเครื่องหมายโคลอนสองตัวพอดี:

section_name : attribute_name : attribute_value

section_name ไม่บังคับแต่แนะนำให้ใส่ ส่วน attribute_name และ attribute_value จำเป็นต้องมี ตัวอย่างของ Google เองเขียนในรูป Display:Size:13 inch และ Battery:Capacity:12.5 hours แปลว่าที่อยู่ที่ถูกต้องของขนาดจริงของสินค้าในฟีด Google จะมีหน้าตาแบบนี้:

มีสองกฎที่ช่วยให้ข้อมูลส่วนนี้สะอาด หนึ่ง ใส่หน่วยไว้ข้างใน attribute_value ด้วย เพราะฟิลด์นี้เป็นข้อความอิสระ และเลข «600» เปล่า ๆ เอาไปใช้ต่อไม่ได้ สอง อย่าเขียนซ้ำสิ่งที่มี attribute ของตัวเองอยู่แล้ว Google บอกไว้ว่าห้ามใส่ข้อมูลที่ครอบคลุมอยู่ในที่อื่นซ้ำอีก และข้อมูลราคาหรือกำหนดเวลาจัดส่งก็ระบุชัดว่าห้ามใส่ไว้ที่นี่

schema markup ขนาดสินค้า: สี่ฟิลด์หลัก บวกอีกหนึ่งที่ไม่มีใครใช้

บนหน้าเว็บของคุณเอง schema.org ให้ Product มีพรอปเพอร์ตีเรื่องขนาดโดยตรง แต่ละตัวรับค่าเป็น Distance หรือ QuantitativeValue ได้:

• width — «ความกว้างของสินค้า»
• height — «ความสูงของสินค้า»
• depth — «ความลึกของสินค้า»
• weight — รับค่าเป็น Mass หรือ QuantitativeValue

ถัดมาคือ size ซึ่งเป็นฟิลด์คนละประเภทและถูกใช้ผิดกันเป็นปกติ นิยามของมันรับได้ทั้งข้อความธรรมดาอย่าง XL หรือ 32Wx34L, QuantitativeValue ที่มี unitCode หรือ SizeSpecification แบบเต็ม — และตัวนิยามเองบอกตรง ๆ ว่าถ้ารูปแบบเหล่านั้นไม่เข้ากับสินค้า «พรอปเพอร์ตี width, height, depth และ weight น่าจะเหมาะสมกว่า» แปลเป็นภาษาคนสำหรับคนที่ขายอะไรที่ไม่ใช่เสื้อผ้า: ใช้ size กับระบบไซซ์เสื้อผ้า ใช้พรอปเพอร์ตีขนาดสี่ตัวกับสินค้าที่จับต้องได้ และอย่าเอา 600x320x720 ไปใส่ใน size เป็นข้อความ

ฟิลด์ที่ไม่มีใครใช้คือ hasMeasurement ซึ่งเป็น QuantitativeValue บน Product ที่ออกแบบมาเพื่อเก็บค่าการวัดต่าง ๆ ของสินค้า — ตัวอย่างของ schema.org เองคือความยาวขาในของกางเกง ขนาดล้อของจักรยาน และเบอร์เกลียวของสกรู ฟิลด์นี้รับค่าเป็นอาเรย์ จึงเป็นที่อยู่ของ ขนาดรอง ทุกตัว ไม่ว่าจะเป็นความกว้างชั้นวางด้านใน ความสูงที่นั่ง ระยะกึ่งกลางจุดยึด ขนาดช่องเปิด หรือระยะพิตช์เกลียว ตัวเลขกลุ่มนี้คือสิ่งที่ลูกค้าอีเมลมาถามคุณ และมันมีฟิลด์มาตรฐานรองรับอยู่แล้ว แต่ถูกปล่อยว่างไว้ในแคตตาล็อกแทบทุกเจ้า

เรื่องหน่วย unitCode รับรหัสกลาง 3 ตัวอักษรของ UN/CEFACT — MMT มิลลิเมตร, CMT เซนติเมตร, INH นิ้ว, KGM กิโลกรัม, LBR ปอนด์ ถ้าไม่มั่นใจว่ารหัสไหนถูก การใช้ unitText พร้อมข้อความธรรมดาก็ถูกต้องตามข้อกำหนด และดีกว่าใส่รหัสผิด

คัดลอกไปใช้ได้เลย: บล็อก JSON-LD สำหรับฟิลด์ขนาด

วางโค้ดชุดนี้ลงใน Product node ที่คุณมีอยู่แล้ว มันผ่านการตรวจความถูกต้อง ครบทุกฟิลด์ที่ควรมี และตั้งใจแยกขนาดสินค้าออกจากขนาดกล่องบรรจุอย่างชัดเจน

{
  "@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" }
  ]
}

ฟีด ChatGPT ต้องการตัวเลขชุดเดิม แต่เรียกด้วยชื่ออื่น

ข้อกำหนดฟีดสินค้าของ Agentic Commerce — ไฟล์ที่ร้านค้าส่งขึ้นไปให้พื้นที่ช้อปปิงของ ChatGPT ใช้ — รับข้อมูลขนาดได้สองรูปแบบ และกฎเรื่องฟิลด์ที่ต้องมาคู่กันก็เข้มงวด:

ข้อกำหนดระบุว่าคุณลักษณะทางกายภาพและการจัดหมวดหมู่ช่วยเรื่องการแบ่งประเภท การกรอง และความเกี่ยวข้องในการค้นหา — ซึ่งพูดตรง ๆ ก็คือสินค้าที่ไม่มีข้อมูลขนาดคือสินค้าที่ระบบกรองเข้าไปอยู่ในชุดผลลัพธ์ไม่ได้ ถ้าลูกค้าถามหาตู้ที่ลึกไม่เกิน 350 mm แล้วฟิลด์ depth ของคุณว่างเปล่า คุณไม่ได้อันดับต่ำ แต่คุณหายไปเลย

มีช่องว่างหนึ่งที่ต้องพูดกันตามตรง: ข้อกำหนดนี้ไม่ได้นิยามฟิลด์แยกสำหรับขนาดกล่องบรรจุ และไม่ได้บอกว่า dimensions หมายถึงตัวสินค้าหรือกล่อง ฉะนั้นให้ประกาศไว้ว่าคุณหมายถึงอันไหน ในที่ที่ทั้งคนและโมเดลอ่านได้ และทำให้เหมือนกันทั้งแคตตาล็อก

ทำไมฟิลด์เหล่านี้คุ้มที่จะกรอก ทั้งที่ Google ไม่เอาไปแสดง

ตรงนี้คือส่วนที่อ่านแล้วเหมือนขัดกันเอง เอกสาร Product structured data ของ Google เองซึ่งไล่รายการว่าอะไรทำให้ได้ rich result นั้น ไม่ได้ รวม width, height, depth, weight หรือ hasMeasurement เข้าไปด้วย รายการที่รองรับมีแค่ราคา สถานะสินค้าคงเหลือ คะแนนรีวิว การจัดส่ง นโยบายการคืนสินค้า ไซซ์เสื้อผ้า รหัสระบุสินค้า และข้อดีข้อเสีย

ดังนั้น markup เรื่องขนาดจะไม่ทำให้คุณได้ snippet ที่ใหญ่ขึ้น และมันก็ไม่เคยถูกออกแบบมาเพื่อสิ่งนั้น

สิ่งที่เปลี่ยนไปคือฝ่ายที่เอาข้อมูลไปใช้ Google บอกว่า product_detail ให้ข้อมูลโครงสร้างที่ช่วยให้ระบบเข้าใจและแสดงสินค้าในพื้นที่ต่าง ๆ รวมถึงฟีเจอร์ที่ขับเคลื่อนด้วย AI อย่าง AI Mode ในการค้นหา ส่วนฟีด Agentic Commerce มีอยู่เพื่อให้สินค้าถูกค้นเจอและถูกกรองได้ในหน้าต่างแชท ระบบเหล่านี้ไม่ต้องรอเทมเพลตหน้าตาอะไรมาทำงานให้ — มันต้องการ attribute ที่นำไปเทียบกับเงื่อนไขได้ ฟิลด์ขนาดจึงไม่ใช่ของประดับบนผลการค้นหาอีกต่อไป มันคือสิ่งที่ทำให้คุณมีคุณสมบัติถูกดึงขึ้นมาตอบ

นั่นเปลี่ยนลำดับความสำคัญไปเลย: กรอกฟิลด์เหล่านี้เพื่อเอนจินที่ตอบคำถาม ไม่ใช่เพื่อเอนจินที่วาดกรอบสวย ๆ

กฎข้อเดียวที่ทำให้ทุกอย่างพัง: ตัวเลขหนึ่งตัว อยู่สองที่

ความผิดพลาดทุกรูปแบบที่ผมเคยเห็นเกี่ยวกับ ข้อมูลโครงสร้าง ขนาดสินค้า มาจากรากเดียวกัน — ฟีดบอกอย่างหนึ่ง ภาพบอกอีกอย่างหนึ่ง

มันเกิดขึ้นแบบไม่มีใครตั้งใจ คนหนึ่งพิมพ์ขนาดกล่องลงใน shipping_width อีกคนวัดตัวสินค้าที่ประกอบเสร็จเพื่อทำภาพสเปก คนที่สามปัดค่า 564 mm เป็น 56 cm ใน product_detail ผลคือผู้ช่วย AI บอกลูกค้าอย่างมั่นใจว่าตู้กว้าง 640 mm ลูกค้าหันไปดูภาพของคุณที่เขียนว่า 600 แล้วคุณก็ได้ปัญหาความน่าเชื่อถือบวกกับการคืนสินค้ามาฟรี ๆ ที่แย่กว่านั้นคือตัวเลขที่เครื่องอ่านได้จะเป็นตัวที่ถูกยกไปอ้าง เพราะมันเป็นตัวเดียวที่อ่านออก

ทางแก้อยู่ที่กระบวนการ ไม่ใช่ที่ markup: วัดครั้งเดียว แล้วเอาค่าที่วัดได้ตัวเดียวกันนั้นไปลงทั้งในฟิลด์และในภาพ ลงรายละเอียดคือ —

1. วัดสินค้าที่ประกอบเสร็จจริง ไม่ใช่วัดจากแบบเขียน และไม่ใช่วัดกล่อง แล้วบันทึกไว้ว่าตัวเลขแต่ละค่าหมายถึงอันไหน
2. วางตัวเลขแต่ละค่าบนภาพให้ตรงกับส่วนที่มันอธิบาย — ยึดติดกับขอบจริงของสินค้า ไม่ใช่ลอยอยู่ใกล้ ๆ — แล้วส่งออกตามขนาดภาพสเปกของแต่ละแพลตฟอร์ม ซอฟต์แวร์ที่สร้างมาเพื่อการกำกับขนาดบนภาพ (dimension annotation) ทำงานนี้ได้ผลเหมือนกันทุกครั้ง ซึ่งคือความต่างทั้งหมดจากโปรแกรมแต่งภาพทั่วไปที่คุณต้องลากลูกศรวางเองทีละอัน หรือจากเครื่องมือสร้างภาพด้วย AI ที่จะวาดขนาดซึ่งมันไม่เคยวัดออกมาให้อย่างหน้าตาเฉย เพราะสิ่งที่มันปรับให้ดีที่สุดคือความดูน่าเชื่อ
3. คัดลอกตัวเลขชุดเดียวกันนั้นลงใน width/height/depth, product_detail และฟิลด์ขนาดของฟีด แหล่งเดียวกัน ปัดเศษเหมือนกัน หน่วยเดียวกัน
4. เมื่อค่าไหนเปลี่ยน ให้แก้ทั้งสองที่ใน commit เดียวกัน ตัวเลขคู่ที่เพี้ยนจากกันแย่กว่าตัวเลขที่หายไปทั้งค่า

ตัวอย่างจริงของฝั่งภาพในคู่นี้ดูได้ที่ กรณีศึกษาการทำป้ายบอกขนาดสินค้า และคำถามเรื่องหน่วยที่ทำให้ผู้ส่งออกครึ่งหนึ่งสะดุด อธิบายไว้ใน ขนาดสินค้าควรใช้ cm หรือ inches

เช็กลิสต์ก่อนเผยแพร่

• มี width, height, depth อยู่บน Product node ครบ แต่ละตัวเป็น QuantitativeValue พร้อม unitCode หรือ unitText
• มี weight พร้อมระบุหน่วย
• ขนาดรองทุกค่าที่ลูกค้าถามจริง อยู่ใน hasMeasurement พร้อม name ที่บอกได้ว่าเป็นค่าอะไร
• ใช้ size กับระบบไซซ์เสื้อผ้าเท่านั้น ไม่มีข้อความแบบ 600x320x720 อยู่ในนั้น
• ฟีด: shipping_length / shipping_width / shipping_height มีครบทั้งสามค่า หน่วยเดียวกัน และอธิบายกล่องบรรจุ
• ฟีด: ขนาดสินค้าที่ประกอบเสร็จอยู่ใน product_detail ใส่หน่วยไว้ข้างในค่า และมีโคลอนสองตัวพอดีต่อหนึ่งรายการ
• ฟีด: ไม่มีข้อมูลซ้ำกับสิ่งที่มี attribute ของตัวเองอยู่แล้ว ไม่มีราคาหรือกำหนดเวลาจัดส่งอยู่ใน product_detail
• ฟีด agentic: ใช้ dimensions พร้อมหน่วย หรือใช้ length+width+height บวก dimensions_unit
• ฟีด agentic: ไม่ส่ง weight ออกไปโดยไม่มี item_weight_unit เด็ดขาด
• ขนาดสินค้าและขนาดกล่องบรรจุถูกกำกับแยกกันชัดเจนทุกที่ที่ปรากฏ
• ตัวเลขทุกตัวใน markup ตรงกับตัวเลขที่พิมพ์อยู่บนภาพสเปก ตรงกันถึงระดับมิลลิเมตร
• ระบุชื่อผู้รับผิดชอบความตรงกันนี้ไว้หนึ่งคน เพื่อไม่ให้ใครแก้ข้างเดียว

FAQ

จะเพิ่มขนาดสินค้าเข้าไปใน structured data อย่างไร

ใส่ width, height, depth และ weight ไว้บน Product node ใน JSON-LD แต่ละตัวเป็น QuantitativeValue ที่มี value เป็นตัวเลขและมี unitCode ส่วนคุณลักษณะอื่นที่วัดได้ทั้งหมด ให้เพิ่มเป็นรายการใน hasMeasurement พร้อม name ที่อธิบายได้ว่าเป็นค่าอะไร สำหรับฟีดของ Google ขนาดของสินค้าที่ประกอบเสร็จต้องอยู่ใน product_detail ไม่ใช่ในฟิลด์กลุ่ม shipping_*

Google ใช้ค่า width, height, depth จาก Product schema หรือเปล่า

ไม่ใช้สำหรับ rich result พรอปเพอร์ตีของสินค้าที่ Google รองรับครอบคลุมราคา สถานะสินค้าคงเหลือ รีวิว การจัดส่ง นโยบายการคืนสินค้า ไซซ์เสื้อผ้า รหัสระบุสินค้า และข้อดีข้อเสีย — ขนาดทางกายภาพไม่อยู่ในรายการนั้น แต่มันยังสำคัญต่อการถูกดึงขึ้นมาตอบและการเปรียบเทียบในพื้นที่ที่ขับเคลื่อนด้วย AI ซึ่งเป็นงานคนละแบบ และตอนนี้ใหญ่กว่าเดิม

shipping_length ต่างจากขนาดจริงของสินค้าอย่างไร

shipping_length, shipping_width และ shipping_height อธิบายกล่องพัสดุที่ใช้ส่ง และมีไว้เพื่อให้คำนวณค่าส่งแบบ carrier-calculated ได้ ทั้งสามค่าไม่ใช่ขนาดของสินค้าที่ประกอบเสร็จ และไม่ควรเอาขนาดสินค้ามากรอกลงไป Merchant Center ไม่มี attribute เฉพาะสำหรับขนาดของสินค้าที่ประกอบเสร็จ นี่จึงเป็นเหตุผลที่ product_detail เป็นที่ที่ถูกต้องสำหรับข้อมูลนั้น

ใน JSON-LD ควรใช้รหัสหน่วยตัวไหนกับข้อมูลขนาด

unitCode รับรหัสกลาง 3 ตัวอักษรของ UN/CEFACT — MMT คือมิลลิเมตร, CMT เซนติเมตร, INH นิ้ว, KGM กิโลกรัม, LBR ปอนด์ ถ้าไม่แน่ใจว่าหน่วยนั้นใช้รหัสอะไร ให้ใช้ unitText พร้อมข้อความธรรมดาแทน เพราะ unitText ที่อ่านรู้เรื่องดีกว่า unitCode ที่ผิด

ถ้าใส่ขนาดในฟีดแล้ว ยังต้องใส่ขนาดบนภาพสินค้าอีกไหม

ยังต้องใส่ และเหตุผลสมมาตรกันพอดี เครื่องอ่านฟิลด์ได้แต่อ่านภาพของคุณไม่ได้ ส่วนลูกค้าอ่านภาพและไม่เคยเปิดฟีดของคุณเลย ภาพไดอะแกรมขนาดของคุณคือรูปภาพ และทุกระบบที่ตัดสินว่าสินค้าของคุณจะปรากฏในคำตอบหรือไม่นั้นอ่านข้อความ — ฉะนั้นทำทั้งสองอย่าง และทำให้ตรงกันถึงระดับมิลลิเมตร วิธีเรียบเรียงฝั่งภาพให้ลูกค้าตัดสินใจได้ อธิบายไว้ใน วิธีสื่อสารขนาดสินค้าให้ผู้ซื้อเข้าใจ และถ้าอยากรู้ว่าพลาดเรื่องนี้แล้วเสียเงินไปเท่าไร เครื่องคำนวณต้นทุนการคืนสินค้า คิดเลขให้ได้

แหล่งข้อมูลอ้างอิง

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode และ unitText
• Google Merchant Center — attribute ขนาดพัสดุและขอบเขตค่าที่รับได้
• Google Merchant Center — attribute รายละเอียดสินค้า [product_detail]
• Google Search Central — Product structured data และพรอปเพอร์ตีที่รองรับ
• Agentic Commerce — ข้อกำหนดฟีดสินค้า