ความสดใหม่ของฟีดและจังหวะการเก็บข้อมูล
การถูกปฏิเสธเรื่องราคาและสถานะสินค้าคงคลังแทบทุกกรณีคือปัญหาเรื่องจังหวะเวลาที่แฝงตัวมา ฟีดและเว็บไซต์คือสองระบบที่บอกข้อมูลสินค้าชิ้นเดียวกันให้ Google และการถูกปฏิเสธก็เกิดขึ้นในช่องว่างระหว่างทั้งสอง
สามช่องทางที่ข้อมูลส่งถึง Google
| วิธี | ความหน่วง | เหมาะกับ |
|---|---|---|
| การดึงฟีดตามกำหนดเวลา | ระดับชั่วโมง | แคตตาล็อกทั้งชุด วันละครั้งหรือมากกว่า |
| Content API | เกือบเรียลไทม์ | การเปลี่ยนแปลงราคาและสต็อกทันทีที่เกิดขึ้น |
| การอัปเดตสินค้าอัตโนมัติ | Google เป็นผู้ดำเนินการ | ตัวช่วยกันพลาด ไม่ใช่กลยุทธ์หลัก |
การอัปเดตสินค้าอัตโนมัติเปิดให้ Google แก้ไขราคาและสถานะสินค้าคงคลังจากข้อมูลที่มีโครงสร้างบนหน้าสินค้าของคุณ เมื่อข้อมูลไม่ตรงกับฟีด คุ้มค่าที่จะเปิดใช้งานไว้เป็นแนวป้องกันสุดท้าย แต่นี่คือการที่บุคคลที่สามเข้ามาแก้ข้อมูลของคุณ ไม่ใช่สิ่งที่ใช้แทนการส่งข้อมูลที่ถูกต้องตั้งแต่ต้น
ควรดึงฟีดบ่อยแค่ไหน
วันละครั้งคือขั้นต่ำสำหรับแคตตาล็อกที่ใช้งานจริง หากสต็อกเปลี่ยนแปลงบ่อย ควรดึงหลายครั้งต่อวัน สำหรับสินค้าที่หมุนเวียนเร็วจริง ๆ เช่น มาร์เก็ตเพลส แฟลชเซล และสินค้าที่มีชิ้นเดียว การดึงฟีดตามกำหนดเวลาคือเครื่องมือที่ผิด และ Content API คือคำตอบที่ถูกต้อง
การเก็บข้อมูลที่คุณกำหนดเวลาไม่ได้คือการที่ Google เข้ามาเก็บข้อมูลหน้าสินค้าของคุณ ซึ่งเกิดขึ้นตามตารางเวลาของ Google และนี่คือเหตุผลที่ฟีดต้องถูกต้องก่อนที่หน้าเว็บจะเปลี่ยน ไม่ใช่หลังจากนั้น
ลำดับการเปลี่ยนแปลงที่ช่วยไม่ให้สินค้าถูกปฏิเสธ
- เมื่อขึ้นราคา: อัปเดตฟีดก่อน แล้วค่อยอัปเดตเว็บไซต์
- เมื่อลดราคา: อัปเดตฟีดก่อน แล้วค่อยอัปเดตเว็บไซต์ ให้ฟีดมาก่อนเสมอ
- เมื่อสินค้าหมด: อัปเดตฟีดก่อน และควรทำผ่าน API
- เมื่อสินค้ากลับมามีสต็อก: อัปเดตเว็บไซต์ก่อนก็ไม่เสียหาย แต่อัปเดตฟีดก่อนจะทำให้สินค้าปรากฏได้เร็วกว่า
ข้อมูลที่มีโครงสร้างบนหน้าสินค้า
การใส่ product schema markup บนหน้า Landing Page ช่วยให้ Google อ่านราคาและสถานะสินค้าได้อย่างชัดเจน แทนที่จะต้องแกะข้อมูลจากหน้าเว็บที่แสดงผล วิธีนี้ช่วยลดการถูกปฏิเสธจากข้อมูลไม่ตรงกันได้อย่างมีนัยสำคัญ เป็นข้อมูลที่ระบบอัปเดตสินค้าอัตโนมัติใช้อ่าน และเป็น markup ชุดเดียวกับที่แพลตฟอร์มช้อปปิ้งแบบ AI ใช้ นี่คือการปรับด้านเทคนิคที่ให้ผลตอบแทนสูงที่สุดในรายการนี้