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