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

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

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

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

  • ข้อผิดพลาดที่พบบ่อยจะให้รายละเอียดเพิ่มเติมเกี่ยวกับข้อผิดพลาดที่เฉพาะเจาะจง
  • google.rpc.Status ให้รายละเอียดเกี่ยวกับโมเดลข้อผิดพลาดเชิงตรรกะ ที่ API ใช้
  • รหัสข้อผิดพลาด Canonical แสดงรายการและคำอธิบาย รหัสข้อผิดพลาด Canonical ที่กำหนดโดย gRPC และ HTTP ในบริบทของ Google Ads API

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

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

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

ในทำนองเดียวกัน หากโปรเจ็กต์ที่อยู่ในระบบคลาวด์ Google มีเพียงระดับการเข้าถึงการทดสอบและพยายามส่งคำขอไปยังบัญชีเวอร์ชันที่ใช้งานจริง (ไม่ใช่บัญชีทดสอบ) API จะแสดงAuthorizationError ซึ่งค่า Enum จะขึ้นอยู่กับเวอร์ชัน API

ข้อผิดพลาดที่ลองอีกครั้งได้

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

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

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

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

ข้อผิดพลาดเกี่ยวกับการตรวจสอบความถูกต้อง

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