วิธีเตรียมฟีดสินค้าสำหรับ ChatGPT Shopping (กันยายน 2026)

ประเด็นสำคัญ

คำแนะนำ ChatGPT มาจากฟีดสินค้าเป็นหลัก ไม่ใช่การค้นเว็บ 9 ฟิลด์บังคับ กฎที่ปฏิเสธแถวแบบเงียบ ๆ และวิธีตรวจสอบไม่ว่าจะมีสิทธิ์เข้าถึงฟีดหรือไม่

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

เหมาะกับใคร

ผู้ทำ SEO อีคอมเมิร์ซ ผู้ดูแลฟีด และหัวหน้าฝ่ายปฏิบัติการ merchant ที่รับผิดชอบแคตตาล็อกราว 500 ถึง 100,000 SKU

สิ่งที่คุณจะได้

ไฟล์สินค้าที่ผ่านการตรวจสอบฟิลด์บังคับทั้งเก้าข้อ กับรายการข้อยกเว้นที่ระบุเจ้าภาพของทุก SKU ที่ถูกสกัดไว้

สิ่งที่ต้องมีก่อน

ส่งออกแคตตาล็อกเป็น CSV, TSV หรือ JSONL ได้ ไดเรกทอรี staging แก้ไข robots.txt เองได้หรือยื่นคำขอแก้ไขได้ สิทธิ์อ่านล็อกเซิร์ฟเวอร์หรือ CDN

เรื่องการเข้าถึง

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

ใช้เวลาราว

4 ถึง 6 ชั่วโมงสำหรับรอบแรกเมื่อแคตตาล็อกต่ำกว่า 5,000 SKU เวลาหมดไปกับการตรวจฟิลด์ ไม่ใช่การตั้งค่าเทคนิค

นิยามของคำว่าเสร็จ

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

อะไรเปลี่ยนไป และการตัดสินใจหนึ่งข้อที่มันบังคับ

OpenAI เปิดตัวโมเดล ChatGPT 5.6 เมื่อวันที่ 9 กรกฎาคม 2026 วันถัดมา สัดส่วนคำแนะนำการช้อปปิ้งใน ChatGPT ที่มาจากฟีดสินค้าของ merchant แทนการค้นเว็บเปิด ก็กระโดดจาก 8.26% ไปเป็น 61.54% ตัวเลขนี้มาจากงานวิจัยที่ Profound เผยแพร่ โดยติดตาม 1,757,723 ครั้งของการรันพรอมป์การช้อปปิ้งใน ChatGPT ตลอดเดือนกรกฎาคม 2026 ในวันเดียว การดึงข้อมูลจากฟีดจึงกลายจากแหล่งรองมาเป็นแหล่งหลัก

ตัวเลขนี้เป็นการสังเกตของบุคคลที่สาม ไม่ใช่การเปิดเผยของ OpenAI OpenAI ไม่ได้ยืนยันการเปลี่ยนแปลงเมื่อวันที่ 10 กรกฎาคม และไม่เคยเปิดเผยสัดส่วนการดึงข้อมูลใด ๆ ว่าอะไรมีข้อมูลรองรับและอะไรไม่มี ผมรวบไว้ในหัวข้อหนึ่งช่วงท้ายบทความ ด้านทิศทางให้จริงจัง ด้านความแม่นยำให้ผ่อน

ทิศทางนี้บังคับให้เกิดการเปลี่ยนกรอบคิดหนึ่งอย่าง ข้อมูลสินค้าตอนนี้ต้องถูกต้องในฐานะข้อมูล ไม่ใช่แค่ในฐานะเนื้อหา หน้าสินค้าที่เขียนสวยแต่ขาดเลขตรวจสอบ GTIN สำหรับเอนจินแนะนำที่อิงฟีดแล้วคือหนึ่งระเบียนที่ตรวจไม่ผ่าน

จากนี้ไปเป็นกระบวนการล้วน ๆ ไม่ว่าตัวเลขเมื่อวันที่ 10 กรกฎาคมจะทนต่อการตรวจสอบหรือไม่ ทุกขั้นตอนในนี้ก็ยังควรทำ แคตตาล็อกที่สะอาด ครบถ้วน และอ่านด้วยเครื่องได้ จะใช้ได้กับทุกพื้นผิวการค้าที่คุณยังต้องเจอต่อไป

ระบุว่าคุณอยู่เลนไหน

กระบวนการนี้แยกเป็นสองเลน เพราะคำว่า "เสร็จ" ให้ความหมายต่างกันในแต่ละเลน คุณจึงต้องรู้ก่อนเริ่มว่าเราอยู่ตรงไหน เลน A พิสูจน์การเข้าสู่ดัชนีได้ เลน B พิสูจน์ความพร้อมได้ ทั้งสองเลนผลิตไฟล์เดียวกัน

การตรวจสิทธิ์เข้าถึงสี่ข้อ

ตอบตามจริงทีละข้อ

คำถาม

อะไรนับเป็นหลักฐานว่า "ใช่"

อะไรไม่นับ

คุณลงทะเบียนกับ OpenAI แล้วและได้รับการยืนยันเป็นลายลักษณ์อักษรว่ามีสิทธิ์เข้าถึงฟีดหรือไม่?

การยืนยันที่ระบุชื่อฟีดของคุณ

"ผมส่งแบบฟอร์มแสดงความสนใจไปแล้ว"

แคตตาล็อกของคุณมุ่งตลาดสหรัฐฯ หรือไม่?

การยืนยันว่าขอบเขตการอัปโหลดมาตรฐานตอนนี้ครอบคุณ

การสันนิษฐานว่าตลาดของคุณรวมอยู่ด้วย

Integrations การชำระเงินเปิดใช้งานแยกแล้วหรือไม่?

การยืนยันชัดเจนระหว่างการออนบอร์ด

การที่คุณตั้งแฟล็กเอง

คุณส่งไฟล์ทดสอบหรือไฟล์เต็มไปแล้วและได้รับการตอบรับหรือไม่?

การตอบกลับที่อ้างถึงการส่งของคุณ

ส่งไปแล้วเงียบ

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

เลน A: ยืนยันสิทธิ์เข้าถึงฟีดแล้ว

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

เลน B: ยังไม่มีการเข้าถึง และอะไรที่ไม่เสียเปล่า

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

ถ้าคุณใช้ Shopify ข้อมูลสินค้าส่งไปยัง ChatGPT ผ่าน Shopify Catalog โดยไม่ต้องทำงานฝั่ง merchant เพิ่ม ส่วนฟีดตรงมีไว้เพื่อความสดใหม่และเพื่อฟิลด์ที่ไม่ได้ส่งมาโดยค่าเริ่มต้น มีข้อควรระวังหนึ่งข้อ แหล่งข้อมูลทุติยภูมิแห่งหนึ่งระบุว่า Integrations นี้เริ่มมีนาคม 2026 แต่ยังไม่ยืนยันได้ จึงควรถือเป็นประเด็นที่ต้องถาม ไม่ใช่เหตุผลตั้งแผน

เปิดประตูให้ครอว์เลอร์ที่อ่านสินค้าของคุณ

นี่คือขั้นแรกที่ให้ผลกับทั้งสองเลนทันที และเป็นชัยชนะที่ถูกที่สุด

เปิด robots.txt แล้วตรวจคำสั่งสำหรับเอเจนต์ของ OpenAI ตัวที่สำคัญต่อการมองเห็นสินค้าคือ OAI-SearchBot ถ้าถูกบล็อก เนื้อหาของคุณจะไม่ปรากฏในผลลัพธ์สินค้าของ ChatGPT ไม่ว่าฟีดจะสะอาดแค่ไหน มันไม่ได้ใช้ฝึกโมเดล การบล็อกจึงไม่ได้ปกป้องอะไร

มีชื่อเอเจนต์สี่ชื่อที่ต้องประเมินอย่างชัดเจน

เอเจนต์

หน้าที่

ผลต่อการมองเห็นสินค้า

OAI-SearchBot

จัดทำดัชนีเนื้อหาสำหรับพื้นผิวการค้นหา

การบล็อกซ่อนสินค้าโดยไม่เกี่ยวกับคุณภาพฟีด

ChatGPT-User

ดึงเพจเมื่อผู้ใช้ถามถึงเพจนั้นโดยตรง

การบล็อกทำให้อ่านเพจแบบเรียลไทม์พัง

GPTBot

ครอว์เลอร์สำหรับฝึกโมเดล

ไม่เกี่ยวกับการมองเห็นใน Shopping

OAI-Operator

การท่องเว็บแบบเอเจนต์

มีผลกับเส้นทางการชำระเงินผ่านเอเจนต์

การตรวจคุณภาพที่สำคัญที่สุดตรงนี้ไม่ใช่ `robots.txt` แต่คือครอว์เลอร์ที่ได้รับอนุญาตเข้าถึงได้จริงและอ่านอะไรได้บ้าง ขอ URL สินค้าตัวอย่างด้วย user agent ของครอว์เลอร์ แล้วดูเนื้อความที่ตอบกลับ ถ้าได้แค่เปลือกแอปที่ไม่มีชื่อสินค้า ราคา สถานะสินค้า และคำอธิบายที่เรนเดอร์จากเซิร์ฟเวอร์ การเข้าถึงก็สำเร็จแต่ไม่ได้อะไรกลับมา ร้านจำนวนมากเรนเดอร์ข้อมูลสินค้าฝั่งไคลเอนต์เท่านั้น และร้านแบบนั้นมองไม่เห็นในเส้นทางการค้นพบที่ไม่อาศัยฟีด ไม่ว่าไฟล์ robots จะเขียนว่าอะไร

ตรวจข้อนี้ได้ที่ OpenAI search crawler simulator ของ Auspia ซึ่งจะขอเพจสาธารณะในนามครอว์เลอร์ของ OpenAI แล้วแสดงว่าเปิดอ่านได้แค่ไหน

ถ้าแก้ไม่ได้ ถ้า robots.txt ถูกล็อกโดยแพลตฟอร์มหรือเอเจนซี ให้บันทึกคำขอแก้ไขพร้อมวันที่แล้วไปต่อ ขั้นนี้ไม่ใช่ตัวบล็อก มันกลายเป็นหลักฐานสำหรับบันทึกของเลน B

ทำให้หน้าสินค้าอ่านด้วยเครื่องได้

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

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

อย่างน้อยให้มี name, description, image, SKU, brand และบล็อก offers ที่มี price, price currency และ availability ค่าต้องตรงกับที่จะเข้าไปในฟีด ถ้าแคตตาล็อกมี GTIN, condition, material, color, size, dimensions ก็ใส่เพิ่มด้วย เพราะแอตทริบิวต์เหล่านี้คือสิ่งที่คำถามแบบบทสนทนาใช้จริง

การตรวจคุณภาพ หยิบ URL สินค้าหนึ่งตัวจากสามหมวดที่ต่างกันที่สุด แล้วตรวจด้วยเส้นทางการเรนเดอร์เดียวกับที่ครอว์เลอร์เห็น ไม่ใช่ด้วยเบราว์เซอร์ที่ล็อกอินอยู่

ถ้าแก้ไม่ได้ ถ้าแพลตฟอร์มไม่ให้ฝัง JSON-LD ในเทมเพลตสินค้า ให้ใส่ผ่าน tag manager แล้วบันทึกเป็นหนี้ทางเทคนิค วิธีนี้ใช้ได้แต่เปราะ และต้องมีคนรับผิดชอบปิดมัน

เขียนคำอธิบายใหม่ให้รับกับคำถามแบบบทสนทนา

ขั้นนี้คือจุดที่วินัย SEO แบบเดิมเริ่มทำร้ายคุณ

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

เขียนคำอธิบายสินค้าเป็นสเปกของข้อเท็จจริง นำด้วยประโยคมนุษย์สั้น ๆ หนึ่งประโยคบอกว่ามันคืออะไรและสำหรับใคร จากนั้นเป็นแอตทริบิวต์ที่ไม่มีคำโฆษณา "น้ำหนัก: 780 กรัม" ดีกว่า "ดีไซน์เบาเหลือเชื่อ" ถ้าจะกล่าวอ้างอะไร ให้กล่าวให้เจาะจงและตรวจสอบได้

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

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

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

ร่างสัญญาฟิลด์ก่อนจะแตะแถวแรก

ตรงนี้คือจุดที่ฟีดเริ่มต้น ก่อนจะส่งออกอะไรทั้งสิ้น นิยามคำว่า "ถูกต้อง" ไว้ครั้งเดียว สิ่งนี้เปลี่ยนการตรวจสอบจากการเถียงกันเป็นขั้นตอนที่ทำตามกลไกได้

ฟิลด์บังคับเก้าข้อ และจุดที่แต่ละตัวพัง

ทั้งเก้าข้อต้องมีในทุกแถว ตารางนี้คือสัญญา

ฟิลด์

รูปแบบที่รับได้

ข้อผิดพลาดที่พบบ่อยที่สุด

ผลที่ตามมา

item_id

สตริงคงที่และไม่ซ้ำสำหรับสินค้าหรือตัวเลือก

ใช้ซ้ำข้ามตัวเลือก หรือสร้างใหม่ทุกครั้งที่ส่งออก

แถวซ้ำและระเบียนกำพร้า

title

ข้อความล้วน ยาวประมาณไม่เกิน 150 ตัวอักษร

ตัดกลางคำ หรือใส่ราคาลงในชื่อ

แถวถูกปฏิเสธหรือจับคู่ผิด

description

ข้อความล้วน ยาวไม่เกิน 5,000 ตัวอักษร

เศษ HTML หรือ markdown ติดมาจาก CMS

แถวถูกปฏิเสธ

url

URL ของหน้าสินค้า

มีพารามิเตอร์ติดตาม หรือ URL ที่ผ่านการเปลี่ยนเส้นทาง

แถวชี้ไปที่ไม่มีอะไร

brand

สตริงชื่อแบรนด์

ไม่มีเลยสำหรับ SKU ที่ไม่มีแบรนด์

แถวถูกปฏิเสธ

seller_name

สตริงชื่อ merchant

สะกดไม่เหมือนกันไปทั่วแคตตาล็อก

สัญญาณ merchant อ่อนลง

image_url

URL ตรงของรูปภาพ

รูป placeholder หรือ URL ที่ต้องมีเซสชัน

แถวไม่มีภาพ

availability

ต้องเป็น in_stock, out_of_stock, pre_order, backorder หรือ unknown เท่านั้น

ค่าที่ตั้งเองจากคำศัพท์ในคลัง

แถวถูกปฏิเสธ

price

"จำนวน สกุลเงิน" เช่น 79.99 USD

ตัวคั่นหลักพัน หรือตัวเลขที่ไม่มีสกุลเงิน

แถวถูกปฏิเสธ

สองฟิลด์สมควรเน้นเป็นพิเศษ เพราะมันพังแบบเงียบและลากทั้งกลุ่มสินค้าไปด้วย

availability รับได้เพียงห้าค่า การเว้นว่าง ค่าว่าง หรือค่าที่ไม่รู้จักทำให้แถวถูกปฏิเสธ ถ้าแพลตฟอร์มของคุณส่งออก IN STOCK, available หรือ 1 แถวเหล่านั้นจะตกทั้งหมด ให้จับคู่คำศัพท์ภายในกับห้าค่าที่อนุญาตอย่างชัดเจน และส่งสิ่งที่ไม่เข้าคู่เข้าคิวตรวจด้วยมือ แทนที่จะปล่อยเป็น unknown โดยอัตโนมัติ unknown เป็นค่าที่ถูกต้องตามกฎ แต่เป็นการเลือกอย่างมีสติ ไม่ใช่ถังขยะ

price คือ จำนวน ตามด้วยช่องว่าง แล้วด้วยรหัสสกุลเงินตัวพิมพ์ใหญ่ นั่นคือ 79.99 USD ไม่ใช่ $79.99 ไม่ใช่ 79,99 USD และไม่ใช่ 7.999e1 ไม่มีตัวคั่นหลักพันและไม่มีสัญกรณ์ยกกำลัง

กฎที่ปฏิเสธแถวแบบเงียบ ๆ

ยังมีข้อจำกัดอีกสี่ข้อที่ควรฝังลงในสคริปต์ตรวจ

GTIN ต้องเป็นตัวเลข 8, 12, 13 หรือ 14 หลักพอดี พร้อมเลขตรวจสอบที่ถูกต้อง ISBN-10 ใช้ไม่ได้ ให้เก็บศูนย์นำหน้าไว้ ซึ่งหมายความว่าต้องเก็บคอลัมน์นี้เป็นข้อความทุกที่ที่มันผ่าน นี่คือตัวทำลายแบบเงียบที่พบบ่อยที่สุดในสเปกทั้งหมด เพราะตารางและไฟล์ CSV ตัดศูนย์นำหน้าทิ้งโดยค่าเริ่มต้น

ราคาลด ต้องมากกว่าศูนย์และน้อยกว่าราคาปกติอย่างเคร่งครัดในสกุลเงินเดียวกัน แถวโปรโมชันที่ราคาลดเท่ากับราคาปกติ หรือที่ปล่อยราคาปกติว่างไว้ จะไม่ผ่าน

ความยาวชื่อ ประมาณไม่เกิน 150 ตัวอักษร เวลาตัดให้ตัดที่ขอบคำ

ฟิลด์วันที่ไม่ได้ตั้งเวลา สเปกระบุชัดว่าไม่มีการตั้งเวลาเปลี่ยนราคาหรือสถานะสินค้าในสัญญา ถ้าอยากให้โปรโมชันสลับตอนเที่ยงคืน ไปป์ไลน์ของคุณต้องส่งค่าใหม่

ตัดสินใจเรื่องแฟล็กสิทธิ์อย่างตั้งใจ

แฟล็กสามตัวกำหนดว่าจะเกิดอะไรกับแถวหลังผ่านการตรวจสอบแล้ว

แฟล็ก

ค่าเริ่มต้นเมื่อเว้นว่างหรือปล่อยว่าง

บทบาท

is_eligible_search

true

false ถอดสินค้าออกจากสิทธิ์การค้นหาและปิดการชำระเงิน

is_eligible_checkout

ต้องมีการค้นหาที่มีสิทธิ์ก่อน

ถ้าจะเป็น true การค้นหาต้องเป็น true ด้วย ถ้าค้นหาเป็น false ค่าจะถูกเขียนทับ

is_ads_eligible

ปิด

ควบคุมเส้นทางการโฆษณาที่แยกออกไป

อาจพบในชื่อ enable_search, enable_checkout และ is_eligible_ads ด้วย สิ่งเหล่านี้คือชื่อพ้อง อย่าถือว่าเทมเพลตที่ใช้ชื่อเก่าเป็นฟิลด์คนละตัว

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

จัดลำดับกลุ่มฟิลด์เสริม

ฟิลด์เสริมมีราว 50 ตัว มาเรียงตามผลตอบแทนต่อชั่วโมงทำงาน ไม่ใช่ตามลำดับในสเปก

  1. ตัวเลือก (group_id, listing_has_variations, variant_dict, offer_id, gtin, mpn) ถ้าคุณขายเสื้อผ้า รองเท้า ของใช้ในบ้าน หรืออะไรที่มีไซซ์และสี นี่คือลำดับแรก
  2. ข้อมูลสินค้า (condition, product_category, material, color, size, gender, age_group รวมทั้งฟิลด์ขนาดและน้ำหนัก) พวกนี้คือสิ่งที่ทำให้การจับคู่แบบบทสนทนาทำงาน
  3. สื่อ (additional_image_urls)
  4. การคืนสินค้า (accepts_returns, return_deadline_in_days, return_policy)
  5. รีวิว (review_count, star_rating) บวก store_review_count และ store_star_rating ในระดับร้าน
  6. การจัดส่ง merchant และภูมิศาสตร์ (shipping_price, shipping, seller_url, target_countries, store_country)
  7. ฟิลด์ที่เปิดเฉพาะตอนออนบอร์ด marketplace_seller, size_system, accepts_exchanges, is_digital คู่ของโฆษณา (is_ads_eligible, ads_metadata) และคู่ของการชำระเงิน (is_eligible_checkout, seller_privacy_policy, seller_tos) ต้องมีการยืนยันตอนออนบอร์ด ไม่ใช่แบบบริการตนเอง เลื่อนไปรอบแรกก่อน

การตรวจคุณภาพ ฟิลด์บังคับทั้งเก้าต้องแมปกับคอลัมน์ในแคตตาล็อกที่มีข้อมูลจริงอย่างน้อย 95% ของ SKU ฟิลด์ที่ต่ำกว่าเกณฑ์นี้ไม่ใช่งานแมป แต่เป็นการตัดสินใจจัดหา

ถ้าแก้ไม่ได้ ถ้าฟิลด์บังคับไม่มีแหล่งข้อมูลเลย เช่น brand ในไลน์ที่ไม่มีแบรนด์ ให้หยุดแล้วไปคุยเรื่องการจัดหากับเจ้าของธุรกิจก่อนทำไฟล์ งานจัดรูปแบบไม่สามารถแก้ข้อมูลที่ไม่มีอยู่ได้

รูปแบบไฟล์ที่ส่งได้จริง

ใช้รูปแบบที่ OpenAI ยืนยันสำหรับฟีดที่คุณลงทะเบียนไว้ ระหว่างการออนบอร์ด นอกจากนั้นมีเส้นทางที่เข้ากันได้กับ Google ซึ่งรับ .txt หรือ .tsv ที่คั่นด้วยแท็บแบบ UTF-8 และ .csv ที่คั่นด้วยจุลภาค และรองรับ gzip เป็น .txt.gz, .txt.gzip, .tsv.gz และ .csv.gz

JSON สเปรดชีต XML RSS และ Atom ไม่ได้รับการสนับสนุนบนเส้นทางที่เข้ากันได้นี้ อย่าผสมรูปแบบข้ามแถว ให้ใช้รูปแบบเดียวทั้งการอัปโหลด

ทำให้สี่ฟิลด์ที่ทำแถวพังมากที่สุดเป็นมาตรฐาน

แช่แข็งการส่งออกหนึ่งครั้ง

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

การปรับมาตรฐานสี่ข้อ

ศูนย์นำหน้าใน GTIN ส่งออกคอลัมน์เป็นข้อความ ตรวจว่าความยาวเป็น 8, 12, 13 หรือ 14 และตรวจเลขตรวจสอบ ความล้มเหลวแบบเงียบส่วนใหญ่อยู่ตรงนี้

รูปแบบราคา ตัดตัวคั่นหลักพันออก เก็บจุดทศนิยม ตัดสัญกรณ์ยกกำลังออก แล้วต่อรหัสสกุลเงินเป็นโทเคนแยก จากนั้นตรวจด้วยนิพจน์ปรกติที่รับเฉพาะ ^\d+\.\d{2} [A-Z]{3}$ ที่เหลือส่งเข้าคิว

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

ทำความสะอาดชื่อและคำอธิบาย ชื่อตัดที่ขอบคำที่ 150 ตัวอักษร คำอธิบายลอกมาร์กอัปออกแล้วตัดที่ 5,000 ตัวอักษรของข้อความล้วน

การตรวจคุณภาพ นำไฟล์ที่ปรับมาตรฐานแล้วเข้าตารางใหม่ แล้วยืนยันว่าคอลัมน์ GTIN ยังแสดงศูนย์นำหน้าอยู่ นี่คือวิธีจับกับดักการส่งออกแบบตัวเลขที่ผ่านการตรวจอื่นมาทั้งหมด

ถ้าแก้ไม่ได้ ถ้าการปรับมาตรฐานเกิดในแพลตฟอร์มฟีดหรือ PIM อย่าเชื่อข้อความแจ้งความสำเร็จ ให้ตรวจผลลัพธ์ของมันด้วยการทดสอบชุดเดียวกัน

ตรวจทุกแถวและดูแลรายการข้อยกเว้น

ตรงนี้คือการรันการตรวจทั้งไฟล์ ขั้นนี้เปลี่ยนแคตตาล็อกให้เป็นแผนงาน

การตรวจเชิงกลไกเก้าข้อที่ทำได้โดยไม่ต้องมีวาลิเดเตอร์

ต่อแถว ฟิลด์บังคับทั้งเก้ามีอยู่และไม่ว่าง availability อยู่ในรายการห้าค่า ความยาวและเลขตรวจสอบของ gtin ถูกต้อง price ตรงรูปแบบจำนวนกับสกุลเงิน sale_price น้อยกว่า price อย่างเคร่งครัด มากกว่าศูนย์ และสกุลเงินเดียวกัน title ไม่เกิน 150 ตัวอักษร description เป็นข้อความล้วนไม่เกิน 5,000 ตัวอักษร url ตอบกลับ 200 และเรนเดอร์ข้อมูลสินค้าจากเซิร์ฟเวอร์ image_url ชี้ไปที่รูปจริง ไม่ใช่ placeholder

แผนภาพ: แถวสินค้าแถวเดียวผ่านด่านตรวจแปดด่านตามลำดับ — ฟิลด์บังคับครบ, availability อยู่ในรายการ, เลขตรวจสอบ GTIN, รูปแบบราคา, ราคาลดต่ำกว่าราคาปกติ, ชื่อสั้นกว่า 150 ตัวอักษร, คำอธิบายเป็นข้อความล้วน, URL และรูปแก้ได้ แถวที่ผ่านเข้าชุดที่มีสิทธิ์ แถวที่ตกไปอยู่ในไฟล์ข้อยกเว้นพร้อมชื่อเจ้าภาพ

แถวจะผ่านด่านทั้งหมดหรือตกลงไฟล์ข้อยกเว้นพร้อมชื่อด่านที่ปฏิเสธมัน ด่าน availability ปฏิเสธแถวมากที่สุด เพราะคำศัพท์คลังที่ตั้งเองเป็นสาเหตุที่พบบ่อยที่สุดของการตกทั้งแคตตาล็อก

ทำไฟล์ข้อยกเว้น ไม่ใช่แคตตาล็อกที่สมบูรณ์แบบ

สองคอลัมน์และเจ้าภาพหนึ่งคน item_id, ตัวที่กั้น และคนที่จะแก้

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

ถ้าแก้ไม่ได้ ถ้าฟิลด์บังคับหายไปทั้งหมวดสินค้า ไม่ใช่แค่บาง SKU ให้ถือเป็นเรื่องการจัดหาที่ต้องคุยกับเจ้าของธุรกิจ อย่าเปลี่ยนแถวพวกนั้นเป็น unknown เพื่อให้ผ่านการตรวจ unknown เป็นค่าที่ถูกต้องตามกฎและมีความหมายเฉพาะ การใช้มันเพื่อผ่านด่านคือการทำข้อมูลตัวเองให้สกปรก

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

ตรวจไฟล์แบบเดียวกับที่แพลตฟอร์มจะทำ

แยกวิเคราะห์ไบต์ที่จะส่งจริง ด้วยรูปแบบที่จะใช้จริง แล้วนับว่าเข้าไปกี่แถวออกมากี่แถว

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

การตรวจคุณภาพ จำนวนแถวเข้าเท่ากับแถวออก และการตรวจอัตโนมัติตรงกับการตรวจด้วยมือ ถ้าไม่ตรง แปลว่าฝ่ายใดฝ่ายหนึ่งผิด และมักเป็นฝ่ายมือ

ถ้าแก้ไม่ได้ ปัญหารหัสอักขระแก้ได้เกือบทุกครั้งด้วยการส่งออกเป็น UTF-8 ใหม่ ปัญหาเรื่องอัญประกาศเกือบทุกครั้งคือตัวคั่นที่ไม่ได้ escape หรือขึ้นบรรทัดใหม่เกินมาในคำอธิบาย

ถ้าทีมมีเอเจนต์เขียนโค้ดได้ นี่คือจุดเดียวที่สคริปต์สั้น ๆ คุ้มค่า มันเปลี่ยนการตรวจสอบจากโปรเจกต์รายไตรมาสเป็นการรันซ้ำ

ตรวจว่ามันได้ผลจริง

สิ่งที่คุณพิสูจน์ได้ขึ้นกับเลน ตรงนี้ควรแม่นและไม่ทำให้ความต่างพร่า

แผนภาพ: สองเส้นทางขนานใช้ไฟล์สินค้าที่ตรวจแล้วไฟล์เดียวกัน เส้นบน มีสิทธิ์เข้าถึงฟีดที่ยืนยันแล้ว จบด้วยการเข้าสู่ดัชนีที่พิสูจน์ได้ เส้นล่าง ไม่มีสิทธิ์ จบด้วยความพร้อมที่พิสูจน์ได้แต่การเข้าสู่ดัชนียังไม่ยืนยัน ทั้งสองบรรจบที่ไฟล์ที่ผ่านการตรวจไฟล์เดียวกัน

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

ถ้ามีสิทธิ์เข้าถึง (เลน A)

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

ถ้ายังไม่มีสิทธิ์ (เลน B)

สี่ข้อ คำขอ robots.txt คืน URL สินค้าให้ OAI-SearchBot การเรนเดอร์ฝั่งเซิร์ฟเวอร์ของ URL นั้นมีชื่อสินค้า ราคา สถานะสินค้า และคำอธิบาย การตรวจเก้าข้อผ่าน และไฟล์ส่งออกที่แช่แข็งกับการรันตรวจถูกเก็บไว้ที่ที่คนถัดไปทำซ้ำได้

ความพร้อมเป็นผลลัพธ์จริงและหักล้างได้ แต่มันไม่เหมือนกับการเข้าสู่ดัชนี และไม่ควรรายงานราวกับว่าเป็นสิ่งเดียวกัน

ตัวเลขสุดท้ายที่สำคัญ

ลิงก์ออกจาก ChatGPT ได้ utm_source=chatgpt.com ต่อท้ายโดยอัตโนมัติ นั่นหมายความว่าหลักฐานฝ่ายเดียวที่ยืนยันได้ว่ามีคลิกอยู่ในการวิเคราะห์ของคุณเอง ตั้งฟิลเตอร์ไว้ล่วงหน้าตั้งแต่ยังไม่ต้องใช้

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

สิ่งที่กระบวนการนี้ควบคุมไม่ได้

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

ตัวเลขวันที่ 10 กรกฎาคมเป็นการสังเกต จากผู้ให้บริการรายเดียว มันบรรยายแผงพรอมป์ที่ Profound ติดตาม ไม่ใช่เซสชันผู้ซื้อจริงหรือเส้นทางการซื้อ OpenAI ไม่ได้ยืนยันการเปลี่ยนแปลงนี้และไม่ได้เปิดเผยสัดส่วนการดึงใด ๆ การเปิดตัว GPT-6 Astra เริ่มวันที่ 3 กันยายน 2026 และทับซ้อนกับหน้าต่างการวัดช่วงหลังของงานวิจัยนั้น มันเป็นตัวแปรกวนจริง

ตัวเลขการกระจุกตัวมีข้อจำกัดเดียวกัน การเพิ่มขึ้นของการอ้างอิงร้านในสิบอันดับจาก 22.5% เป็น 41.8% และจำนวน merchant ที่ไม่ซ้ำลดจาก 13,524 เป็น 10,607 มาจากแผงเดียวกัน และข้อสรุปว่าการเปลี่ยนแหล่งดึงอธิบาย 83% ของความแปรปรวนการมองเห็นใน 517 รายที่เปลี่ยน คือสัดส่วนการอธิบายภายในแผง ไม่ใช่ค่าสัมประสิทธิ์เชิงเหตุที่เอาไปตั้งแผนได้

ข้อกล่าวอ้างบางข้อที่วนอยู่ในบล็อกผู้ให้บริการไม่มีในสเปก ให้ระวังทุกข้อ

ข้อกล่าวอ้าง

แหล่งที่มา

สถานะ

ฟีดรีเฟรชทุก 15 นาที เร็วกว่ารายวัน 96 เท่า

บล็อกผู้ให้บริการ

ไม่มีในสเปก OpenAI ซึ่งไม่ระบุความถี่

ฟีดเป็นสำเนาเต็ม ไม่ใช่การอัปเดตเฉพาะส่วน

ผู้ให้บริการรายหนึ่งที่ไม่อ้างเอกสาร OpenAI

ยังไม่ยุติ ถามตอนออนบอร์ด

ต้องมีตัวอย่างราว 100 สินค้า

บล็อกผู้ให้บริการ

เอกสารช่วยเหลือ OpenAI พูดถึงการส่งฟีดตัวอย่างหรือเต็ม โดยไม่ระบุจำนวน

ส่งผ่าน SFTP

แหล่งหนึ่งบอก SFTP อีกแหล่งบอกส่ง HTTPS แบบเข้ารหัส

แหล่งขัดกันเอง กลไกถูกกำหนดตอนออนบอร์ด

popularity_score, return_rate, เมทาดาทาราคาต่อหน่วย สื่อวิดีโอและ 3D ทำงานเป็นปัจจัยจัดอันดับ

แหล่งรวบรวมแหล่งเดียว

ไม่มีในรายการฟิลด์ของสเปก ฟิลด์รีวิวในสเปกคือ review_count, star_rating, store_review_count, store_star_rating

ฟีดที่มีโครงสร้างแปลงได้ดีกว่าข้อมูลที่เก็บด้วยการดึงราวสองเท่า

คำกล่าวอ้างของผู้ให้บริการที่ไม่อ้างแหล่ง

อย่ารับเป็นข้อเท็จจริง

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

คำถามที่พบบ่อย

วันนี้ส่งฟีดสินค้าให้ ChatGPT ได้ไหม

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

ควรรีเฟรชฟีดบ่อยแค่ไหน

สเปกไม่ได้ระบุความถี่ บล็อกผู้ให้บริการสองแห่งอ้างว่าทุก 15 นาที แต่ตัวเลขนั้นไม่มีในเอกสาร OpenAI คำตอบที่ใช้ได้จริงคืออัปเดตจากสองเหตุการณ์ที่สเปกกำหนดให้ต้องสดใหม่ คือราคาและสถานะสินค้า

ส่งทั้งไฟล์หรือเฉพาะแถวที่เปลี่ยน

ยังไม่ยุติ ผู้ให้บริการรายหนึ่งอ้างว่าเป็นสำเนาเต็มและไม่อ้างเอกสาร OpenAI ถามตอนออนบอร์ดก่อนสร้างไปป์ไลน์ที่ผูกกับคำตอบใดคำตอบหนึ่ง

ข้อกำหนดตัวอย่าง 100 สินค้าเป็นเรื่องจริงไหม

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

ฟีดที่ดีจะดันอันดับสินค้าของฉันในผลการช้อปปิ้งของ ChatGPT ไหม

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

ฉันขายบน Shopify ต้องทำกระบวนการนี้ไหม

สำหรับการเชื่อมต่อพื้นฐาน ไม่ต้อง ข้อมูลสินค้าส่งไปยัง ChatGPT ผ่าน Shopify Catalog โดยไม่ต้องทำงานฝั่ง merchant เพิ่ม ส่วนฟีดตรงมีไว้เพื่อความสดใหม่และเพื่อฟิลด์ที่ไม่ได้ส่งมาโดยค่าเริ่มต้น

ผู้เขียน: Eva Laurent นักกลยุทธ์ด้านการค้นหาอีคอมเมิร์ซที่ Auspia ทำงานกับหน้าสินค้ามากกว่า 10,000 หน้า เขียนเรื่องการค้นหาอีคอมเมิร์ซ การค้นพบสินค้า และว่าข้อมูลสินค้าไปถึงพื้นผิวการค้าที่ขับเคลื่อนด้วย AI ได้อย่างไร

สำรวจหัวข้อนี้

อ่านต่อในเส้นทางการเติบโตเดียวกัน