ประเภทข้อผิดพลาด

เราได้จัดหมวดหมู่ข้อผิดพลาดไว้เป็นหมวดหมู่กว้างๆ ดังต่อไปนี้

  • การตรวจสอบสิทธิ์
  • ลองซ้ำได้
  • การตรวจสอบความถูกต้อง
  • เกี่ยวกับการซิงค์

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

ข้อผิดพลาดในการตรวจสอบสิทธิ์

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

สาเหตุที่พบบ่อยที่สุดของข้อผิดพลาดในการตรวจสอบสิทธิ์เกิดจากปัจจัยที่อยู่นอกเหนือการควบคุมของคุณคือผู้ใช้ที่ตรวจสอบสิทธิ์แล้วเพิกถอนสิทธิ์ที่ให้แอปของคุณดำเนินการในนามของตน ตัวอย่างเช่น หากแอปจัดการบัญชี Google Ads ที่แยกกันสำหรับลูกค้าอิสระ และตรวจสอบสิทธิ์แยกกันในฐานะลูกค้าแต่ละราย เมื่อคุณจัดการบัญชีของลูกค้า ลูกค้าอาจเพิกถอนการเข้าถึงแอปได้ทุกเมื่อ API อาจแสดงผลข้อผิดพลาด AuthenticationError.OAUTH_TOKEN_REVOKED โดยตรง หรือออบเจ็กต์ข้อมูลเข้าสู่ระบบในตัวในไลบรารีไคลเอ็นต์อาจส่งข้อยกเว้นโทเค็นที่ถูกเพิกถอน ทั้งนี้ขึ้นอยู่กับเวลาที่เพิกถอนการเข้าถึง ไม่ว่าจะเป็นกรณีใด หากแอปมี UI สำหรับไคลเอ็นต์ แอปอาจขอให้ลูกค้าเปิดขั้นตอน OAuth2 อีกครั้งเพื่อให้สิทธิ์แอปดำเนินการในนามของลูกค้าอีกครั้ง

ข้อผิดพลาดที่ลองใหม่ได้

ข้อผิดพลาดบางอย่าง เช่น TRANSIENT_ERROR หรือ INTERNAL_ERROR อาจบ่งบอกถึงปัญหาชั่วคราวที่อาจแก้ไขได้โดยการลองส่งคำขออีกครั้งหลังจากหยุดชั่วคราวไปสักครู่

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

สำหรับคำขอที่เริ่มต้นในส่วนแบ็กเอนด์ แอปของคุณควรลองส่งคำขออีกครั้งโดยอัตโนมัติจนครบจำนวนสูงสุดที่ทำได้

เมื่อส่งคำขออีกครั้ง ให้ใช้นโยบาย Exponential Backoff ตัวอย่างเช่น หากคุณหยุดชั่วคราว 5 วินาทีแรกก่อนที่จะลองใหม่ครั้งแรก คุณอาจหยุดชั่วคราว 10 วินาทีหลังจากครั้งที่ 2 และ 20 วินาทีหลังจากการลองใหม่ครั้งที่ 3 Backoff แบบทวีคูณช่วยให้คุณมั่นใจว่าไม่ได้เรียกใช้ API มากเกินไป

ข้อผิดพลาดจากการตรวจสอบ

ข้อผิดพลาดจากการตรวจสอบระบุว่าระบบไม่ยอมรับอินพุตของการดำเนินการ เช่น PolicyViolationError, DateError, DateRangeError, StringLengthError และ UrlFieldError

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

แอป Google Ads หลายแอปมีฐานข้อมูลในเครื่องเพื่อจัดเก็บออบเจ็กต์ Google Ads ปัญหาหนึ่งสำหรับวิธีนี้คือฐานข้อมูลในเครื่องอาจไม่ซิงค์กับออบเจ็กต์จริงใน Google Ads ตัวอย่างเช่น ผู้ใช้อาจลบกลุ่มโฆษณาใน Google Ads โดยตรง แต่แอปและฐานข้อมูลในเครื่องไม่ทราบถึงการเปลี่ยนแปลงนี้และยังคงเรียกใช้ API ต่อไปเสมือนว่ามีกลุ่มโฆษณานั้นอยู่ ปัญหาการซิงค์เหล่านี้อาจเกิดจากข้อผิดพลาดหลายอย่าง เช่น DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD และอื่นๆ

สำหรับคำขอที่เริ่มโดยผู้ใช้ กลยุทธ์หนึ่งคือการแจ้งเตือนผู้ใช้ถึงปัญหาการซิงค์ที่อาจเกิดขึ้น เปิดใช้งานงานที่เรียกออบเจ็กต์ Google Ads คลาสที่เกี่ยวข้องทันที และอัปเดตฐานข้อมูลในเครื่อง จากนั้นแจ้งให้ผู้ใช้รีเฟรช UI

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