Hataları aşağıdaki geniş kategorilere ayırdık:
- Kimlik doğrulama
- Yeniden deneyebilir
- Doğrulama
- Senkronizasyonla ilgili
Bu kategoriler olası tüm hataları kapsamasa da ve bazıları birden fazla kategoriye uysa da uygulamanızın hata işleme sürecini yapılandırmak için başlangıç noktası olarak kullanılabilir. Belirli hatalar hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:
- Yaygın Hatalar bölümünde belirli bir hata hakkında daha fazla bilgi verilmektedir.
- API tarafından kullanılan mantıksal hata modeli hakkında ayrıntılı bilgi için google.rpc.Status.
Kimlik doğrulama hataları
Kimlik doğrulama, uygulamanıza bir kullanıcı tarafından kendi adına Google Ads'e erişme izni verilip verilmediğini ifade eder. Kimlik doğrulama, OAuth2 akışı tarafından oluşturulan kimlik bilgileri aracılığıyla yönetilir.
Kimlik doğrulama hatasının, kontrolünüz dışındaki faktörlerden kaynaklanmasının en yaygın nedeni, kimliği doğrulanmış kullanıcının uygulamanıza kendisi adına işlem yapma iznini iptal etmesidir. Örneğin, uygulamanız bağımsız müşteriler için ayrı Google Ads hesapları yönetiyorsa ve her müşterinin hesabını yönetirken her müşteri olarak ayrı ayrı kimlik doğrulaması yapıyorsa müşteriler uygulamanızın erişimini diledikleri zaman iptal edebilir. Erişiminizin ne zaman iptal edildiğine bağlı olarak API doğrudan bir AuthenticationError.OAUTH_TOKEN_REVOKED hatası döndürebilir veya İstemci Kitaplıkları'ndaki yerleşik kimlik bilgisi nesneleri jeton iptal edildi istisnası oluşturabilir. Her iki durumda da, uygulamanızda müşterileriniz için bir kullanıcı arayüzü varsa uygulamanızın müşterileriniz adına işlem yapma iznini yeniden oluşturmak için OAuth2 akışını yeniden başlatmalarını isteyebilir.
Yeniden denemeye uygun hatalar
TRANSIENT_ERROR veya INTERNAL_ERROR gibi bazı hatalar, kısa bir duraksamadan sonra isteği yeniden deneyerek çözülebilecek geçici bir sorunu gösterebilir.
Kullanıcı tarafından başlatılan istekler için kullanıcı arayüzünüzde hatayı hemen belirtmek ve kullanıcıya yeniden deneme yapma seçeneği sunmak bir stratejidir. Alternatif olarak, uygulamanız isteği önce otomatik olarak yeniden deneyebilir ve hatayı yalnızca maksimum yeniden deneme sayısına veya toplam kullanıcı bekleme süresine ulaştıktan sonra kullanıcı arayüzünde gösterebilir.
Arka uçta başlatılan istekler için uygulamanız, isteği maksimum deneme sayısına kadar otomatik olarak yeniden denemelidir.
İstekleri yeniden denediğinizde üstel geri yükleme politikası kullanın. Örneğin, ilk denemeden 5 saniye önce duraklatırsanız ikinci denemeden 10 saniye sonra ve üçüncü denemeden 20 saniye sonra duraklatabilirsiniz. Eksponansiyel geri yükleme, API'yi çok agresif bir şekilde çağırmamanızı sağlar.
Doğrulamayla ilgili hatalar
Doğrulama hataları, bir işleme yapılan girişin kabul edilemediğini gösterir.
Örneğin, PolicyViolationError,
DateError,
DateRangeError,
StringLengthError ve
UrlFieldError.
Doğrulama hataları genellikle kullanıcı tarafından başlatılan ve kullanıcının geçersiz giriş yaptığı isteklerde görülür. Bu gibi durumlarda, aldığınız API hatasına göre kullanıcıya uygun bir hata mesajı göndermeniz gerekir. Ayrıca, API çağrısı yapmadan önce kullanıcı girişini yaygın hatalar açısından doğrulayabilirsiniz. Böylece uygulamanız daha duyarlı, API kullanımınız ise daha verimli olur. Arka uçtan gelen istekler için uygulamanız, gerçek bir operatör tarafından incelenmesi amacıyla başarısız işlemi bir sıraya ekleyebilir.
Senkronizasyonla ilgili hatalar
Birçok Google Ads uygulaması, Google Ads nesnelerini depolamak için yerel bir veritabanı kullanır. Bu yaklaşımın bir zorluğu, yerel veritabanının Google Ads'deki gerçek nesnelerle senkronizasyonunun bozulabilmesidir. Örneğin, bir kullanıcı doğrudan Google Ads'de bir reklam grubunu silebilir ancak uygulama ve yerel veritabanı bu değişiklikten haberdar olmaz ve reklam grubu varmış gibi API çağrıları yapmaya devam eder. Bu senkronizasyon sorunları DUPLICATE_CAMPAIGN_NAME,
DUPLICATE_ADGROUP_NAME,
AD_NOT_UNDER_ADGROUP,
CANNOT_OPERATE_ON_REMOVED_ADGROUPAD gibi çeşitli hatalarla kendini gösterebilir.
Kullanıcı tarafından başlatılan istekler için bir strateji, kullanıcıyı olası bir senkronizasyon sorunu konusunda uyarmak, ilgili Google Ads nesne sınıfını alan ve yerel veritabanını güncelleyen bir işi hemen başlatmak ve ardından kullanıcıdan kullanıcı arayüzünü yenilemesini istemektir.
Arka uç isteklerinde bazı hatalar, uygulamanızın yerel veritabanınızı otomatik ve artımlı olarak düzeltmesi için yeterli bilgi sağlar. Örneğin, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD, uygulamanızın yerel veritabanınızda bu reklamı kaldırıldı olarak işaretlemesine neden olur. Bu şekilde çözemediğiniz hatalar, uygulamanızın daha kapsamlı bir senkronizasyon çalışması başlatmasına veya gerçek bir operatör tarafından incelenmek üzere bir sıraya eklenmesine neden olabilir.