จัดการ flatfile อัตโนมัติ: ดูแลรายการสินค้าในหลายมาร์เก็ตเพลซของ Amazon

ระบบ flatfile ของ Amazon เป็นช่องทางที่ครบถ้วนที่สุดสำหรับจัดการรายการสินค้าจำนวนมากในแคตตาล็อกขนาดใหญ่ และเป็นหนึ่งในระบบที่มีเอกสารสำหรับการใช้งานหลายมาร์เก็ตเพลซน้อยที่สุด แต่ละมาร์เก็ตเพลซใช้เทมเพลตคนละเวอร์ชัน กำหนดฟิลด์บังคับและกฎตรวจสอบต่างกัน แม้เป็นสินค้าเดียวกันในหมวดหมู่เดียวกัน การจัดการรายการสินค้าในสิบมาร์เก็ตเพลซจากแหล่งข้อมูลสินค้าชุดเดียวจึงต้องจัดการความต่างของเทมเพลต การแปลคุณลักษณะ และวงจรอัปโหลด ตรวจสอบ และแก้ไขอย่างเป็นระบบ

บทความนี้อธิบายเวิร์กโฟลว์ flatfile ที่เราใช้ดูแลแคตตาล็อกในหลายมาร์เก็ตเพลซ ทั้งความต่างของเทมเพลต จุดที่การทำงานอัตโนมัติช่วยได้มากที่สุด และจุดที่ยังหลีกเลี่ยงการดำเนินการโดยคนไม่ได้

flatfile คืออะไร

flatfile คือสเปรดชีตที่ใช้แท็บคั่นข้อมูล ซึ่ง Amazon ใช้สร้างและอัปเดตรายการสินค้าจำนวนมาก แต่ละแถวแทนสินค้า แต่ละคอลัมน์แทนคุณลักษณะ เทมเพลตที่ดาวน์โหลดจากส่วน Catalog > Add Products via Upload ใน Seller Central ระบุว่าคอลัมน์ใดบังคับ คอลัมน์ใดไม่บังคับ และค่าใดใช้ได้ในแต่ละช่อง

ระบบ flatfile มีมาก่อน SP-API Listings Items API และยังเป็นช่องทางหลักสำหรับการแก้ไขข้อมูลจำนวนมากใน Seller Central ในส่วนของ API นั้น Amazon ประกาศเลิกสนับสนุนฟีดรายการสินค้าแบบ flat file และ XML ในเดือนมีนาคม 2024 โดยกำหนดนำออกในวันที่ 30 มิถุนายน 2025 และให้เปลี่ยนไปใช้ Listings Items API ที่ใช้ JSON และ JSON_LISTINGS_FEED แทน การอัปโหลด flatfile ผ่าน Seller Central ไม่ได้รับผลกระทบ สำหรับผู้ขายที่มี SKU มากกว่าสองสามสิบรายการในหลายมาร์เก็ตเพลซ เวิร์กโฟลว์สำหรับจัดการข้อมูลจำนวนมากเป็นสิ่งจำเป็นในทางปฏิบัติ และในระบบของเรา flatfile เป็นช่องทางหลักในการจัดการแคตตาล็อก

แต่ในทางปฏิบัติ เอกสาร flatfile ของ Amazon กระจัดกระจายและมักล้าสมัย ข้อกำหนดที่เป็นปัจจุบันที่สุดของเทมเพลตใด ๆ คือตัวเทมเพลตที่เพิ่งดาวน์โหลดสำหรับมาร์เก็ตเพลซและหมวดหมู่ที่กำลังจัดการ การอาศัยเทมเพลตที่เก็บไว้หรือเอกสารเมื่อหกเดือนก่อนเป็นสาเหตุที่ทำให้เกิดข้อผิดพลาดในการอัปโหลดได้บ่อย

ความต่างของเทมเพลตระหว่างมาร์เก็ตเพลซ

ความต่างเชิงโครงสร้างระหว่างเทมเพลตมีมากกว่าที่ผู้ขายส่วนใหญ่คาดเมื่อเริ่มขายในหลายมาร์เก็ตเพลซ เทมเพลตเหล่านี้ไม่ได้เป็นเพียงคำแปลของฟิลด์ชุดเดียวกัน

เทมเพลต Clothing ของสหรัฐฯ สำหรับหมวดหมู่หนึ่งอาจมีคอลัมน์คุณลักษณะห้าสิบคอลัมน์ แต่เทมเพลตเยอรมนีที่เทียบกันอาจมีหกสิบ โดยเพิ่มฟิลด์ที่สหรัฐฯ ไม่มี เช่น คำรับรองการปฏิบัติตามข้อกำหนดสารเคมีของสหภาพยุโรป หรือข้อกำหนดฉลากพลังงานสำหรับสินค้าบางประเภท เทมเพลตญี่ปุ่นอาจจัดโครงสร้างรูปแบบย่อยของสินค้าแยกตามขนาดและสีต่างออกไป โดยใช้ชื่อธีมรูปแบบย่อยของสินค้าที่เวอร์ชันสหรัฐฯ ไม่รองรับ

ค่าที่ใช้ได้ในแต่ละฟิลด์มักต่างกันตามมาร์เก็ตเพลซ แม้ชื่อช่องจะเหมือนกัน ฟิลด์ item_type_keyword รับข้อความต่างกันใน .com กับ .co.uk ค่า color_name ต้องผ่านการตรวจเทียบรายการเฉพาะของแต่ละมาร์เก็ตเพลซ ชื่อสีที่ผ่านในสหรัฐฯ อาจถูกปฏิเสธในเยอรมนีหรือญี่ปุ่นเพราะไม่ตรงกับชุดค่าที่อนุมัติในตลาดนั้น รายงานข้อผิดพลาดไม่ได้อธิบายชัดเสมอไป โดยอาจแจ้งเพียงข้อผิดพลาดคุณลักษณะทั่วไป แทนที่จะบอกตรง ๆ ว่าค่าไม่อยู่ในรายการที่อนุมัติ

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

การแปลงระบบขนาด

สำหรับเสื้อผ้าและรองเท้า การแปลงระบบขนาดเป็นงานที่ใช้แรงมากที่สุดอย่างหนึ่งในการดูแลแคตตาล็อกหลายมาร์เก็ตเพลซ ระบบขนาด US, EU, UK และญี่ปุ่นเทียบกันตรง ๆ ไม่ได้ และตารางแปลงไม่เหมือนกันในสินค้าแต่ละประเภท

รองเท้าผู้หญิงขนาด US 8 โดยทั่วไปเท่ากับ UK 6 และ EU 39 ตามตารางแปลงขนาดที่ใช้กันทั่วไป (ตารางของแต่ละแบรนด์อาจต่างกันครึ่งไซส์) แต่เสื้อผู้หญิงขนาด US medium อาจเท่ากับ EU 38 หรือ 40 ตามเกณฑ์ขนาดของแบรนด์ ไม่มีตารางเทียบสากลที่ใช้ได้ทั้งหมด วิธีที่ถูกต้องคือดูแลตารางจับคู่ขนาดหลักแยกตามประเภทสินค้าและแบรนด์ โดยตรวจสอบกับคู่มือขนาดของผู้ผลิตรายนั้น

ต้องกรอกฟิลด์ size_name และ size_system ของ Amazon ให้สอดคล้องกันอย่างถูกต้อง เพื่อให้รายการสินค้าแสดงในตัวกรองขนาดของแต่ละมาร์เก็ตเพลซ หากอัปโหลดโดยใส่ขนาด US ในฟิลด์ size_name แต่ไม่ระบุ size_system ระบบอาจมองค่าเป็นข้อความที่ไม่มีรูปแบบ และจากประสบการณ์ของเรา รายการสินค้าอาจไม่แสดงในผลค้นหาที่กรองตามขนาด ปัญหานี้อาจไม่เห็นจากการยืนยันอัปโหลด เพราะสร้างรายการสินค้าได้สำเร็จ แต่ตัวกรองขนาดไม่ทำงาน

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

ขีดจำกัดคีย์เวิร์ดเบื้องหลัง

คีย์เวิร์ดเบื้องหลัง ซึ่งเป็นคำค้นที่ส่งในฟิลด์ generic_keyword มีขีดจำกัดจำนวนอักขระต่างกันตามมาร์เก็ตเพลซ และวิธีนับขีดจำกัดก็ต่างกันด้วย

Amazon.com จำกัดฟิลด์ generic_keyword รวมไว้ที่ 249 ไบต์ Amazon.de จำกัดเป็นไบต์เช่นกัน แต่ภาษาเยอรมันมีอักขระหลายไบต์มากกว่าภาษาอังกฤษ ข้อความคีย์เวิร์ดภาษาอังกฤษที่อยู่ในขีดจำกัดไบต์ของสหรัฐฯ จึงอาจเกินขีดจำกัดไบต์ของเยอรมนีเมื่อแปล ส่วนขีดจำกัดของ Amazon.co.jp เกี่ยวข้องกับการเข้ารหัสภาษาญี่ปุ่น คันจิหนึ่งตัวใช้สามไบต์ใน UTF-8 จึงใส่คีย์เวิร์ดภาษาญี่ปุ่นได้จริงน้อยกว่าที่ขีดจำกัดไบต์ชวนให้คาดเมื่อเทียบกับอักษรละติน

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

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

เวิร์กโฟลว์อัตโนมัติ

แนวคิดหลักของการทำ flatfile อัตโนมัติคือ ความต่างระหว่างมาร์เก็ตเพลซส่วนใหญ่เป็นโครงสร้าง ไม่ใช่ความหมาย สินค้ายังคงเดิม ทั้งมิติ วัสดุ การใช้งานที่ตั้งใจไว้ และคุณสมบัติหลักไม่เปลี่ยน สิ่งที่เปลี่ยนคือวิธีแสดงข้อมูลเหล่านั้นในรูปแบบเทมเพลตของแต่ละมาร์เก็ตเพลซ

เราเก็บข้อมูลสินค้าหลักในสเปรดชีต โดยใช้รูปแบบกลางสำหรับทุกคุณลักษณะ: มิติใช้หน่วยเมตริก ขนาดใช้ระบบดั้งเดิมของผู้ผลิต คีย์เวิร์ดใช้ภาษาต้นทาง และหมวดหมู่จับคู่กับระบบจัดหมวดหมู่ภายในที่เป็นกลาง จากนั้นสร้าง flatfile เฉพาะแต่ละมาร์เก็ตเพลซจากข้อมูลหลัก ผ่านชั้นแปลงข้อมูลที่จัดการความต่างเชิงโครงสร้างของตลาดเป้าหมายแต่ละแห่ง

ชั้นแปลงข้อมูลเป็นสคริปต์ ซึ่งในกรณีของเราเขียนด้วย Python โดยจับคู่คุณลักษณะหลักแต่ละอย่างกับคอลัมน์ flatfile ของแต่ละมาร์เก็ตเพลซ แปลงขนาด จับคู่หมวดหมู่กับโครงสร้าง browse node ของตลาด และตรวจสอบแต่ละฟิลด์ก่อนสร้างไฟล์ผลลัพธ์ ฟิลด์ที่ต้องให้คนตรวจ เช่น ข้อความแปล คำรับรองการปฏิบัติตามกฎระเบียบเฉพาะตลาด และคุณลักษณะตามข้อกำหนดของแต่ละประเทศ จะถูกทำเครื่องหมายในผลลัพธ์แทนการเติมอัตโนมัติ

วงจรดาวน์โหลด แก้ไข และอัปโหลดเป็นแบบกึ่งอัตโนมัติ เราใช้สคริปต์ดาวน์โหลดผ่าน SP-API Reports API ซึ่งเปิดให้ใช้รายงาน GET_FLAT_FILE_OPEN_LISTINGS_DATA และประเภทที่เกี่ยวข้อง การประมวลผลไฟล์ดาวน์โหลด เปรียบเทียบกับข้อมูลหลัก และสร้างไฟล์อัปโหลดทำอัตโนมัติ ส่วนการอัปโหลดและตรวจรายงานผลประมวลผลยังให้คนดำเนินการ เพราะความเสียหายจากข้อผิดพลาดในการอัปโหลดจำนวนมากสูงพอที่จะต้องตรวจทานก่อนส่งไฟล์ให้ Amazon ไม่ใช่เพราะทำอัตโนมัติไม่ได้

รูปแบบความล้มเหลวที่พบบ่อย

ข้อผิดพลาดในการอัปโหลดแบ่งเป็นสามประเภท: การตรวจข้อมูลไม่ผ่าน การประมวลผลล้มเหลว และความล้มเหลวที่ไม่แจ้งเตือน

การตรวจข้อมูลไม่ผ่านเป็นกรณีที่ตรงไปตรงมาที่สุด รายงานอัปโหลดแจ้งข้อผิดพลาดชัดเจนพร้อมระบุแถวและฟิลด์ที่ไม่ผ่าน สาเหตุที่พบบ่อยที่สุดคือค่าไม่ถูกต้องในฟิลด์ที่ต้องเลือกจากชุดค่าที่กำหนด (size_name, color_name, item_type_keyword) ขาดฟิลด์บังคับของเทมเพลตเวอร์ชันนั้น หรือคีย์เวิร์ดและคำอธิบายเกินขีดจำกัดไบต์

การประมวลผลล้มเหลวเกิดเมื่ออัปโหลดผ่านการตรวจข้อมูล แต่รายการสินค้าไม่อัปเดตตามคาด สาเหตุที่พบบ่อยคือความสัมพันธ์ของรูปแบบย่อยของสินค้าผิด เช่น ส่ง ASIN ลูกโดยไม่มีรายการแม่ที่ตรงกัน หรือส่งรายการแม่ด้วยธีมรูปแบบย่อยของสินค้าที่ไม่ตรงกับคุณลักษณะของรายการลูก อีกกรณีคือ browse node ขัดแย้งกับหมวดหมู่เดิมของ ASIN ที่มีอยู่แล้ว

ความล้มเหลวที่ไม่แจ้งเตือนตรวจพบยากที่สุด การอัปโหลดสำเร็จและรายงานประมวลผลไม่มีข้อผิดพลาด แต่รายการสินค้าทำงานไม่ถูกต้อง เช่น ขนาดไม่ปรากฏในตัวกรอง คำค้นไม่ถูกจัดทำดัชนี หรือความสัมพันธ์ของรูปแบบย่อยของสินค้าปรากฏในระบบเบื้องหลังแต่แสดงบนหน้าร้านไม่ถูกต้อง ต้องตรวจคุณลักษณะรายการสินค้าที่ใช้งานจริงเทียบกับค่าที่ส่งผ่าน Catalog Items API แทนการดูหน้าร้านด้วยตา

วิธีป้องกันความล้มเหลวที่ไม่แจ้งเตือนคือเพิ่มขั้นตรวจหลังอัปโหลด: ดึงข้อมูลรายการสินค้าที่ใช้งานจริงผ่าน API สำหรับทุก ASIN ที่ได้รับผลกระทบภายในยี่สิบสี่ชั่วโมงหลังอัปโหลด เปรียบเทียบกับค่าที่ส่ง และทำเครื่องหมายความต่าง ขั้นตอนนี้ไม่ซับซ้อน แต่เป็นสิ่งที่แยกกระบวนการดูแลแคตตาล็อกที่เชื่อถือได้ออกจากกระบวนการที่ต้องตรวจด้วยมือตลอดเวลา เพื่อจับการเปลี่ยนแปลงรายการสินค้าที่อธิบายไม่ได้และไม่เคยมีรายงานข้อผิดพลาดแจ้ง