คุณสามารถอัปโหลดข้อมูลสินค้าไปยัง Merchant Center โดยใช้ฟีดตามไฟล์, Merchant API หรือทั้ง 2 อย่างรวมกันได้ ดังนี้
- ฟีดสินค้าที่อิงตามไฟล์: อัปโหลดไฟล์ CSV, TSV หรือ XML โดยใช้ SFTP, Google Cloud Storage, Google ชีต หรือการเรียกข้อมูลตามกำหนดการ
- Merchant API: ส่งคำขอแบบเป็นโปรแกรมจากแบ็กเอนด์โดยตรงเพื่ออัปเดตข้อมูลที่เพิ่มขึ้นเมื่อข้อมูลสินค้ามีการเปลี่ยนแปลง ควบคู่ไปกับการซิงค์แคตตาล็อกทั้งหมดเป็นระยะๆ
คู่มือนี้จะเปรียบเทียบทั้ง 2 วิธี อธิบายว่าควรใช้วิธีใดเมื่อใด (หรือใช้ทั้ง 2 วิธีร่วมกัน) และมีคู่มือการย้ายข้อมูลทีละขั้นตอนหากคุณตัดสินใจย้ายผลิตภัณฑ์บางรายการหรือทั้งหมดจากฟีดไฟล์ไปยัง API
เลือกแนวทางแหล่งข้อมูล
ประเมินความผันผวนของแคตตาล็อก สถาปัตยกรรมแบ็กเอนด์ และเวิร์กโฟลว์การดำเนินงานเพื่อตัดสินใจว่าจะใช้ Merchant API, ฟีดไฟล์ หรือการตั้งค่าแบบผสม
กรณีที่ควรใช้ Merchant API
ใช้แหล่งข้อมูลหลักของ API ในกรณีต่อไปนี้
- การผสานรวมแบบเป็นโปรแกรมโดยตรง: คุณต้องการเรียกใช้ API โดยตรงจากแบ็กเอนด์แทนการสร้างไฟล์และจัดการไปป์ไลน์การโอนไฟล์ (เช่น SFTP หรือ Google Cloud Storage)
- ราคาและสินค้าคงคลังมีความผันผวนสูง: ราคาผลิตภัณฑ์หรือระดับสินค้าคงคลังมีการเปลี่ยนแปลงบ่อยครั้งตลอดทั้งวัน
- อัปเดตทันทีเมื่อข้อมูลมีการเปลี่ยนแปลง: คุณต้องการส่งการเปลี่ยนแปลงผลิตภัณฑ์ไปยัง Google ทันทีที่เกิดขึ้นในแบ็กเอนด์ แทนที่จะรอการสร้างและอัปโหลดไฟล์ตามกำหนดการครั้งถัดไป
- การอัปเดตแคตตาล็อกแบบเพิ่มขึ้น: คุณต้องการแทรก อัปเดต หรือลบผลิตภัณฑ์แต่ละรายการเมื่อมีการเปลี่ยนแปลง โดยไม่ต้องอัปโหลดแคตตาล็อกทั้งหมดซ้ำทุกครั้ง
- การอัปเดตแอตทริบิวต์บางส่วน: คุณต้องการอัปเดตช่องที่เฉพาะเจาะจงของผลิตภัณฑ์ (เช่น
priceหรือavailabilityโดยใช้productInputs.patch) โดยไม่ต้องส่งเพย์โหลดผลิตภัณฑ์ทั้งหมดอีกครั้ง
กรณีที่ควรใช้ฟีดไฟล์
ใช้แหล่งข้อมูลหลักแบบไฟล์ในกรณีต่อไปนี้
- แคตตาล็อกแบบคงที่: ข้อมูลผลิตภัณฑ์มีการเปลี่ยนแปลงไม่บ่อยนัก (เช่น วันละครั้งหรือน้อยกว่านั้น)
- แบ็กเอนด์แบบสแนปชอตเท่านั้นที่ไม่มีการติดตามเดลต้า: แบ็กเอนด์จะส่งออกเฉพาะสแนปชอตแคตตาล็อกแบบเต็ม และไม่สามารถติดตามการเปลี่ยนแปลงระดับสินค้าหรือการลบผลิตภัณฑ์อย่างชัดแจ้ง
- เวิร์กโฟลว์ที่อิงตามสเปรดชีต: ทีมที่ไม่ใช่วิศวกรจะดูแลจัดการหรือลบล้างข้อมูลผลิตภัณฑ์ใน Google ชีตหรือไฟล์ CSV โดยตรง
- การดำเนินการที่ใช้การบำรุงรักษาต่ำ: คุณต้องการการส่งออกไฟล์ตามกำหนดเวลาที่ Merchant Center จะจัดการการดึงข้อมูลและการประมวลผลภาพรวม แทนที่จะดำเนินการผสานรวม API กับการกำหนดอัตราคำขอ การจัดการการลองใหม่ และการซิงค์แคตตาล็อกทั้งหมดเป็นระยะๆ
กรณีที่ควรใช้ทั้ง 2 อย่าง
คุณสามารถรวมฟีดไฟล์และ Merchant API ไว้ในบัญชี Merchant Center เดียวกันได้ในสถานการณ์ต่อไปนี้
- แคตตาล็อกสินค้าที่แบ่งพาร์ติชัน: คุณใช้ Merchant API สำหรับสินค้าที่มีการเปลี่ยนแปลงอย่างรวดเร็ว (เช่น แฟลชเซลหรือสินค้าคงคลังที่มีการหมุนเวียนสูง) และฟีดไฟล์สำหรับกลุ่มแคตตาล็อกแบบคงที่หรือสายผลิตภัณฑ์ที่แยกต่างหาก ตรวจสอบว่าผลิตภัณฑ์แต่ละรายการได้รับการอัปโหลดโดยแหล่งข้อมูลหลักเพียงแหล่งเดียว (ดูการใช้งานพร้อมกันและการเป็นเจ้าของแหล่งข้อมูลหลัก)
- ข้อมูลหลักของ API ที่มีฟีดเสริมแบบอิงตามไฟล์: คุณจัดการข้อมูลสินค้าหลักผ่านแหล่งข้อมูลหลักของ API ขณะที่ทีมที่ไม่ใช่วิศวกรหรือพาร์ทเนอร์บุคคลที่สามจะระบุแอตทริบิวต์เพิ่มเติมผ่านฟีดเสริมแบบอิงตามไฟล์ (เช่น Google ชีตหรือไฟล์ CSV) ที่เชื่อมโยงกับกฎแอตทริบิวต์ หรือในทางกลับกัน
- การย้ายข้อมูลบางส่วนหรือแบบแบ่งระยะ: คุณเปลี่ยนตลาด หมวดหมู่ หรือบัญชีย่อยที่เฉพาะเจาะจงไปใช้ API ขณะที่ยังคงเก็บแคตตาล็อกที่เหลือไว้ในฟีดไฟล์
หากตัดสินใจย้ายสินค้าบางรายการหรือทั้งหมดจากฟีดไฟล์ไปยัง Merchant API ให้ทำตามคู่มือการย้ายข้อมูลทีละขั้นตอน
ความแตกต่างที่สำคัญด้านสถาปัตยกรรม
ฟีดไฟล์และ Merchant API แบบพุชแตกต่างกันในวิธีที่ Google ประมวลผลและจัดการข้อมูลสินค้า ดังนี้
| แนวคิด | ฟีดไฟล์ | Merchant API |
|---|---|---|
| รูปแบบการผสานรวม | การดัมพ์ไฟล์ออฟไลน์: คุณส่งออกแคตตาล็อกไปยังไฟล์และโอนไฟล์โดยใช้ SFTP, Google Cloud Storage, Google ชีต หรือการเรียกข้อมูลตามกำหนดการ | การผสานรวมแบบเป็นโปรแกรมโดยตรง: แบ็กเอนด์จะส่งคำขอไปยังปลายทาง API โดยตรง |
| รายละเอียดการกลายพันธุ์ | การประมวลผลแบบเป็นกลุ่ม: โดยปกติแล้ว การแก้ไขรายการเดียวจะต้องประมวลผลทั้งไฟล์อีกครั้ง | ธุรกรรมแบบละเอียด: คุณสามารถแทรก แพตช์ หรือลบเฉพาะผลิตภัณฑ์ที่มีการเปลี่ยนแปลงได้ |
| เวลาในการซิงค์ข้อมูล | การซิงค์แบบกลุ่ม: การเปลี่ยนแปลงจะรออยู่ในแบ็กเอนด์จนกว่าจะถึงรอบการส่งออกและโอนไฟล์ตามกำหนดการครั้งถัดไป | การเรียกใช้ทันทีหรือตามกำหนดเวลา: คุณสามารถส่งการเปลี่ยนแปลงที่เพิ่มขึ้นได้ทันทีที่เกิดขึ้น ควบคู่ไปกับการซิงค์แบบเต็มเป็นระยะๆ |
| ลักษณะการลบ | โดยนัย (สแนปชอต): แต่ละไฟล์เป็นสแนปชอตที่สมบูรณ์ การนำแถวออกจากไฟล์หลักจะเป็นการลบสินค้า | Explicit: ไม่มีแนวคิดสแนปชอต ให้เรียกใช้ productInputs.delete เพื่อนำผลิตภัณฑ์ที่เลิกผลิตแล้วออก |
| การแสดงทรัพยากร | สถานะเดียว: แถวของไฟล์แสดงถึงอินพุตดิบ | แยกข้อมูลดิบและข้อมูลที่ประมวลผลแล้ว: API จะแยกข้อมูลออกเป็น ProductInput (อินพุตดิบ) และ Product (สถานะที่ประมวลผลแล้วขั้นสุดท้าย) |
| กฎแอตทริบิวต์ (ฟีด) | ใช้กับคอลัมน์ไฟล์ดิบใน UI ของ Merchant Center | รองรับใน UI ของ Merchant Center ต้องระบุเมื่อผสานข้อมูล API กับไฟล์เสริมของบุคคลที่สาม ไม่บังคับสำหรับการเปลี่ยนรูปแบบแหล่งที่มาเดียวหากจัดการในแบ็กเอนด์ |
การใช้งานพร้อมกันและการเป็นเจ้าของแหล่งข้อมูลหลัก ("การอัปเดตล่าสุดจะชนะ")
แม้ว่าคุณจะใช้ทั้งฟีดไฟล์และ API ในบัญชี Merchant Center เดียวกันได้ แต่เราขอแนะนำอย่างยิ่งให้ใช้วิธีเดียวในการแทรกสินค้าที่ระบุ
Merchant Center ทำงานตามรูปแบบ "การอัปเดตล่าสุดจะแทนที่ข้อมูลเดิม" แหล่งข้อมูลหลัก (API หรือฟีดไฟล์) ที่พุชการแทรกสินค้าล่าสุดจะได้รับสิทธิ์การเป็นเจ้าของหลักของข้อมูลสินค้าดังกล่าว ดังนี้
- เมื่อแหล่งข้อมูลไฟล์เป็นเจ้าของสินค้า: การละเว้นสินค้าจากการอัปโหลดไฟล์ครั้งถัดไปจะทริกเกอร์การลบโดยนัย ซึ่งจะนำสินค้าออกจาก Merchant Center
- เมื่อแหล่งข้อมูล API เป็นเจ้าของผลิตภัณฑ์: การละเว้นผลิตภัณฑ์จากการอัปโหลดไฟล์จะไม่มีผลใดๆ เนื่องจากฟีดไฟล์ไม่ได้เป็นเจ้าของผลิตภัณฑ์อีกต่อไป
คุณต้องโทรหา
accounts.productInputs.deleteเพื่อนำออก - ความเสี่ยงในการเป็นเจ้าของซ้ำโดยไม่ตั้งใจ: หากฟีดไฟล์ที่อัปเดตทำงานหลังจากพุช API และมีสินค้า แหล่งข้อมูลไฟล์จะกลับมาเป็นเจ้าของอีกครั้ง การละเว้นผลิตภัณฑ์ในไฟล์ในภายหลังจะลบผลิตภัณฑ์โดยไม่คาดคิด
เพื่อหลีกเลี่ยงการลบหรือการสูญเสียการอัปเดต API โดยไม่คาดคิด อย่าทำการอัปเดตพร้อมกันในผลิตภัณฑ์เดียวกันโดยใช้ทั้ง API และแหล่งข้อมูลหลักของไฟล์
ข้อควรพิจารณาที่สำคัญเกี่ยวกับ API
ทำความเข้าใจลักษณะการทำงานที่สำคัญของ Merchant API ต่อไปนี้ก่อนเริ่มการติดตั้งใช้งาน
แหล่งข้อมูลยืดหยุ่น (ไม่มีภาษาหรือป้ายกำกับ)
Merchant API ช่วยให้คุณสร้างแหล่งข้อมูลหลักได้โดยไม่ต้องระบุ feedLabel หรือ contentLanguage ซึ่งแตกต่างจากฟีดไฟล์ที่กำหนดให้คุณต้องระบุป้ายกำกับฟีดเป้าหมายและภาษาที่เฉพาะเจาะจงล่วงหน้า
- การอัปโหลดที่ยืดหยุ่น: วิธีนี้ช่วยให้คุณอัปโหลดสินค้าที่มีภาษาหรือป้ายกำกับฟีดแบบใดก็ได้ไปยังแหล่งข้อมูลเดียว
- การจัดการที่ง่ายขึ้น: คุณไม่จำเป็นต้องสร้างและจัดการแหล่งข้อมูลแยกต่างหากสำหรับตลาดเป้าหมายทุกแห่ง หมายเหตุ: ดูรายละเอียดเพิ่มเติมเกี่ยวกับการเลือกกลยุทธ์แหล่งข้อมูลได้ที่หัวข้อเลือกกลยุทธ์แหล่งข้อมูล
กลยุทธ์และโควต้าการซิงค์ข้อมูล
ออกแบบการผสานรวม Merchant API ให้รองรับทั้งการอัปเดตแบบเพิ่มทีละส่วนและการซิงค์แบบเต็มที่กำหนดเวลาไว้ ซึ่งต่างจากฟีดไฟล์ที่คุณอัปโหลดแคตตาล็อกทั้งหมดในกลุ่มเดียว
- รวมการอัปเดตที่เพิ่มขึ้นกับการซิงค์แบบเต็มเป็นระยะ: ส่งคำขอ
productInputs.insertหรือproductInputs.patchเมื่อคุณสมบัติของสินค้าเปลี่ยนแปลงในแบ็กเอนด์ เนื่องจากการอาศัยการอัปเดตแบบเพิ่มขึ้นเพียงอย่างเดียวอาจทำให้ข้อมูลไม่ซิงค์กันเมื่อเวลาผ่านไป คุณจึงควรเรียกใช้การซิงค์แบบเต็มเป็นระยะๆ เพื่อปรับยอดแคตตาล็อกให้ตรงกับแหล่งข้อมูลที่ถูกต้อง (ซึ่งจะรีเฟรชวันหมดอายุของสินค้า 30 วันด้วย) ความถี่ในการซิงค์แบบเต็มจะขึ้นอยู่กับขนาดแคตตาล็อกและโควต้า API ที่มีอยู่ - กำหนดอัตราคำขอให้สอดคล้องกับโควต้า API: อย่าเรียกใช้ API สำหรับผลิตภัณฑ์ทั้งหมดพร้อมกัน แม้ว่าจะส่งการเปลี่ยนแปลงที่เพิ่มขึ้นได้เมื่อเกิดขึ้น แต่ให้กระจายคำขอการซิงค์แบบเต็มอย่างสม่ำเสมอตลอดทั้งวันเพื่อให้อยู่ภายในโควต้าการเรียกใช้เมธอดต่อนาทีและรายวัน ดูรายละเอียดได้ที่หัวข้อโควต้าและขีดจำกัด และอัปเดตผลิตภัณฑ์เป็นประจำ
การทดสอบการผสานรวม
ตรวจสอบตรรกะการผสานรวมในสภาพแวดล้อมที่ปลอดภัยก่อนที่จะย้ายไปยังเวอร์ชันที่ใช้งานจริง
ใช้บัญชีทดสอบ
ก่อนทำการเปลี่ยนแปลงในเวอร์ชันที่ใช้งานจริง เราขอแนะนำให้ทำตามขั้นตอนเบื้องต้นของการย้ายข้อมูลในบัญชีทดสอบที่ใช้แซนด์บ็อกซ์ ดังนี้
- สร้างบัญชีทดสอบ: สร้างบัญชีทดสอบแยกต่างหากเพื่อทำการทดสอบอย่างปลอดภัยโดยไม่ส่งผลกระทบต่อโฆษณาที่แสดงอยู่หรือข้อมูลที่แสดงฟรี
- สร้างแหล่งข้อมูล API: ฝึกสร้างแหล่งข้อมูลหลักของ API
- ทดสอบกฎแอตทริบิวต์: ตรวจสอบการเปลี่ยนรูปแบบข้อมูลและการรวมฟีดเสริม
- ตรวจสอบเพย์โหลดและคีย์ผลิตภัณฑ์: พุชผลิตภัณฑ์ตัวอย่างเพื่อยืนยันตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ของ SKU, การเข้ารหัส และการจัดการข้อผิดพลาด
โปรดดูรายละเอียดที่หัวข้อขั้นตอนที่ 1: สร้างบัญชีทดสอบและคู่มือบัญชีทดสอบ
ตรวจสอบความสอดคล้องของคีย์ผลิตภัณฑ์
ตรวจสอบว่าคีย์ผลิตภัณฑ์เพย์โหลดแบบเป็นโปรแกรมตรงกับ SKU ของฟีดไฟล์ทุกประการ Google ระบุผลิตภัณฑ์โดยการรวมข้อมูลต่อไปนี้เข้าด้วยกัน
offerId(เรียกว่าidในฟีดไฟล์ โดยคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่)contentLanguage(เช่นen)feedLabel(เช่นUS)
สัญลักษณ์พิเศษและการเข้ารหัส
หากตัวระบุสินค้ามีอักขระ เช่น /, % หรือ ~ ให้ใช้รูปแบบที่เข้ารหัส (การเข้ารหัส base64url ที่ไม่มีการเติม) ในการเรียก API ดูข้อมูลเพิ่มเติมได้ที่ ProductInput.name
ควบคุมการเกิดขึ้นพร้อมกัน
ในการผสานรวมแบบเรียลไทม์ การอัปเดตอาจไม่เป็นไปตามลำดับเนื่องจากเวลาในการตอบสนองของเครือข่าย หากต้องการป้องกันไม่ให้การอัปเดตที่เก่ากว่าเขียนทับข้อมูลที่ใหม่กว่า ให้ใช้ช่อง versionNumber ในทรัพยากร ProductInput
Playbook การย้ายข้อมูลทีละขั้นตอน
หากตัดสินใจย้ายสินค้าบางรายการหรือทั้งหมดจากฟีดไฟล์ไปยัง Merchant API ให้ทำตาม Playbook นี้เพื่อเปลี่ยนสินค้าโดยไม่สูญเสียการแสดงผลหรือประวัติการแสดงผล
1. ซ้อมการย้ายข้อมูลในบัญชีทดสอบ
ก่อนทำการเปลี่ยนแปลงในเวอร์ชันที่ใช้งานจริง ให้สร้างบัญชีทดสอบที่ใช้แซนด์บ็อกซ์โดยใช้เมธอด accounts.createTestAccount (ดูคำแนะนำเกี่ยวกับบัญชีทดสอบ) บัญชีทดสอบเป็นสภาพแวดล้อมแบบแยกต่างหากที่ข้อเสนอจะได้รับอนุมัติโดยค่าเริ่มต้น ไม่จำเป็นต้องมีการยืนยันโดเมน และระบบจะไม่แสดงข้อมูลต่อสาธารณะ
ใช้บัญชีทดสอบเพื่อจำลองการตั้งค่าเวอร์ชันที่ใช้งานจริงและซ้อมการย้ายข้อมูลตั้งแต่ต้นจนจบ โดยทำดังนี้
- จำลองการตั้งค่าฟีดไฟล์: สร้างแหล่งข้อมูลหลักของไฟล์ (และแหล่งข้อมูลเสริม) ในบัญชีทดสอบ แล้วอัปโหลดตัวอย่างไฟล์ฟีดเวอร์ชันที่ใช้งานจริง
- สร้างแหล่งข้อมูล API ทดสอบและกฎ: สร้างแหล่งข้อมูลหลักของ API และกำหนดค่ากฎแอตทริบิวต์ที่จำเป็นหรือการรวมฟีดเสริม
- ทดสอบการรับช่วงการเป็นเจ้าของและการจัดข้อกำหนดคีย์: ส่งคำขอ
productInputs.insertสำหรับสินค้าตัวอย่าง และยืนยันว่าแหล่งข้อมูล API รับช่วงการเป็นเจ้าของสินค้าที่มีอยู่โดยไม่สร้างสินค้าซ้ำ - ยืนยันการอัปเดตและการลบ: ทดสอบการอัปเดตบางส่วนด้วย
productInputs.patchและการนำออกด้วยproductInputs.deleteและตรวจสอบทรัพยากรที่ได้ด้วยproducts.get
2. สร้างแหล่งข้อมูล Products API เวอร์ชันที่ใช้งานจริง
ก่อนพุชข้อมูล ให้สร้างแหล่งข้อมูลหลักประเภท API ในบัญชี
สร้างแหล่งข้อมูลหลักของ API
หากต้องการสร้างแหล่งข้อมูลที่ยอมรับพุช API ให้ส่งคำขอ POST ไปยังปลายทาง dataSources ดูรายละเอียดเพิ่มเติมได้ที่หัวข้อสร้างแหล่งข้อมูลสินค้าหลัก
3. เปลี่ยนกฎแอตทริบิวต์ที่กำหนดเอง
กฎแอตทริบิวต์ที่กำหนดเองจะเชื่อมโยงกับแหล่งข้อมูลที่เฉพาะเจาะจง และจะไม่โอนจากแหล่งข้อมูลไฟล์ไปยังแหล่งข้อมูล API ใหม่โดยอัตโนมัติ
วิธีเปลี่ยนกฎแอตทริบิวต์จะขึ้นอยู่กับวัตถุประสงค์ของกฎ ดังนี้
- การผสานข้ามแหล่งที่มาและฟีดเสริมของบุคคลที่สาม: หากคุณรวมข้อมูล API หลักเข้ากับแหล่งข้อมูลเสริมภายนอก (เช่น ไฟล์ซัพพลายเออร์ของบุคคลที่สาม สเปรดชีตสินค้าคงคลัง หรือฟีดโปรโมชัน) คุณต้องสร้างกฎแอตทริบิวต์อีกครั้งใน UI ของ Merchant Center และแนบกฎเหล่านั้นกับแหล่งข้อมูล API ใหม่ การประมวลผลล่วงหน้าฝั่งไคลเอ็นต์ไม่สามารถแทนที่กฎที่รวมข้อมูลจากแหล่งข้อมูลอิสระหลายแหล่งได้
- การเปลี่ยนรูปแบบข้อมูลแหล่งเดียว: สำหรับการล้างข้อมูลแหล่งเดียว ค่าเริ่มต้น หรือการจัดรูปแบบสตริงในข้อมูลแคตตาล็อกหลัก ให้เลือกระหว่างตัวเลือกต่อไปนี้
- การเปลี่ยนรูปแบบแบ็กเอนด์ (แนะนำ): ใช้การเปลี่ยนรูปแบบในระบบของคุณเองก่อนเรียกใช้ API ซึ่งจะช่วยให้คุณควบคุมแบบเป็นโปรแกรมได้มากขึ้น ทดสอบได้ง่ายขึ้น และแก้ไขข้อบกพร่องได้ง่ายขึ้น
- กฎแอตทริบิวต์ของ Merchant Center: สร้างกฎการเปลี่ยนรูปแบบสำหรับแหล่งข้อมูล API ใหม่ใน UI ของ Merchant Center อีกครั้งหากต้องการให้ Merchant Center จัดการกฎเหล่านั้นโดยอัตโนมัติต่อไป
4. เปิดใช้การผสานรวม API
เปิดการผสานรวม API เวอร์ชันที่ใช้งานจริงเพื่อเริ่มแทรก อัปเดต และลบผลิตภัณฑ์ในแหล่งข้อมูลหลักของ API ใหม่ โดยทำดังนี้
แทรกและอัปเดตผลิตภัณฑ์ (การเป็นเจ้าของ): ส่งคำขอ
productInputs.insertและproductInputs.patchจากการผสานรวม เมื่อคุณแทรกผลิตภัณฑ์โดยใช้ API ที่มีคีย์เดียวกัน (offerId,contentLanguage,feedLabel) กับผลิตภัณฑ์ในฟีดไฟล์ที่มีอยู่ แหล่งข้อมูล API จะเป็นเจ้าของผลิตภัณฑ์นั้นและเก็บรักษาประวัติการแสดงผลไว้ ดูคำแนะนำเพิ่มเติมได้ที่แทรกผลิตภัณฑ์และเพิ่มและจัดการผลิตภัณฑ์ลบผลิตภัณฑ์ที่เลิกขาย: กำหนดค่าการผสานรวมให้เรียกใช้
productInputs.deleteอย่างชัดเจนเมื่อใดก็ตามที่มีการนำผลิตภัณฑ์ออกจากแคตตาล็อกทยอยติดตั้งใช้งาน: สำหรับแคตตาล็อกขนาดใหญ่ ให้เปิดใช้การผสานรวมทีละบัญชีย่อยของ Merchant Center หรือทีละแหล่งข้อมูล
กำหนดค่าการเกิดขึ้นพร้อมกัน: หากส่งคำขอจำนวนมาก ให้กำหนดค่าไคลเอ็นต์เพื่อจัดการคำขอหลายรายการพร้อมกันและจัดการการเชื่อมต่อหลายรายการ ดูคู่มือเปลี่ยนโครงสร้างโค้ดสำหรับคำขอหลายรายการพร้อมกัน
5. หยุดการอัปเดตแหล่งข้อมูลไฟล์ชั่วคราว
เมื่อการผสานรวม API ทำงานแล้ว ให้หยุดการอัปเดตไฟล์ก่อนการเรียกใช้ไฟล์ตามกำหนดการครั้งถัดไป เพื่อไม่ให้แหล่งข้อมูลไฟล์เขียนทับการอัปเดต API โดยทำดังนี้
- หยุดอัปโหลดไฟล์ใหม่ไปยังตำแหน่ง SFTP/FTP, Google Cloud Storage หรือ Google ชีต
- ใน UI ของ Merchant Center ให้ไปที่แหล่งข้อมูลไฟล์และหยุดการเรียกข้อมูลตามกำหนดการไว้ชั่วคราว
- ผลิตภัณฑ์ที่มีอยู่ซึ่งเป็นของแหล่งข้อมูลไฟล์จะยังคงแสดงอยู่เป็นเวลาสูงสุด 30 วันจนกว่าการผสานรวม API จะแทรกผลิตภัณฑ์ดังกล่าว
6. รอให้การย้ายข้อมูลเสร็จสมบูรณ์และยืนยัน
รอจนกว่าผลิตภัณฑ์ที่ใช้งานอยู่ทั้งหมดจะย้ายข้อมูลจากแหล่งข้อมูลไฟล์ไปยังแหล่งข้อมูล API แม้ว่าการอัปเดตแบบเพิ่มทีละส่วนจะย้ายข้อมูลสินค้าเมื่อมีการเปลี่ยนแปลง แต่การซิงค์แคตตาล็อกแบบสมบูรณ์ตามกำหนดเวลาผ่านการผสานรวมปกติจะช่วยเร่งการย้ายข้อมูลแคตตาล็อกทั้งหมด (ดูกลยุทธ์และโควต้าการซิงค์ข้อมูล)
ในระยะนี้
- ตรวจสอบจำนวนสินค้าใน UI ของ Merchant Center รอจนกว่าจำนวนแหล่งข้อมูลไฟล์จะลดลงเหลือ
0และจำนวนแหล่งข้อมูล API ตรงกับแคตตาล็อกที่ใช้งานอยู่ - ใช้
products.getเพื่อยืนยันว่าแอตทริบิวต์และกฎแอตทริบิวต์ที่กำหนดเองผสานรวมกันตามที่คาดไว้ - ตรวจสอบเครื่องมือการวินิจฉัย API ใน UI ของ Merchant Center เพื่อติดตามอัตราข้อผิดพลาดและประสิทธิภาพของ API
7. เลิกใช้แหล่งข้อมูลไฟล์
หลังจากเปลี่ยนผ่านเสร็จสมบูรณ์และจำนวนรายการฟีดไฟล์เป็น 0 แล้ว ให้ทำดังนี้
- ยืนยันว่าการอัปเดตแสดงแบบเรียลไทม์
- ลบแหล่งข้อมูลไฟล์เดิมใน UI ของ Merchant Center เพื่อป้องกันไม่ให้การอัปเดตตามไฟล์โดยไม่ตั้งใจเขียนทับข้อมูล API