Hata türleri

Hataları aşağıdaki genel kategorilere ayırdık:

  • Kimlik doğrulama
  • Yeniden denenebilecek hatalar
  • Doğrulama
  • Senkronizasyonla ilgili

Bu kategoriler olası tüm hataları kapsamamasına ve bazıları birden fazla kategoriye uymasına rağmen, uygulamanızın hata işlemeyi 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:

  • Sık karşılaşılan hatalar, belirli bir hata hakkında daha fazla bilgi sağlar.
  • google.rpc.Status, API tarafından kullanılan mantıksal hata modeli hakkında ayrıntılı bilgi sağlar.
  • Standart hata kodları, Google Ads API bağlamında gRPC ve HTTP tarafından tanımlanan standart hata kodlarının listesini ve açıklamasını sağlar.

Kimlik doğrulama hataları

Kimlik doğrulama, uygulamanızın 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 kendi adına işlem yapması için verdiği izni iptal etmesidir. Örneğin, uygulamanız bağımsız müşteriler için ayrı Google Ads hesaplarını yönetiyorsa ve bu müşterinin hesabını yönetirken her müşteri olarak ayrı ayrı kimlik doğruluyorsa müşteriler, uygulamanızın erişimini istedikleri zaman iptal edebilir. Erişiminizin ne zaman iptal edildiğine bağlı olarak API doğrudan AuthenticationError.OAUTH_TOKEN_REVOKED hatası döndürebilir veya istemci kitaplıklarındaki yerleşik kimlik bilgisi nesneleri, jeton iptal edildi istisnası oluşturabilir. Her iki durumda da uygulamanızın müşterileriniz için bir kullanıcı arayüzü varsa müşterilerinizden, OAuth2 akışını yeniden başlatarak uygulamanızın kendi adlarına işlem yapma iznini yeniden oluşturmalarını isteyebilir.

Benzer şekilde, Google Cloud projenizde yalnızca Test access level varsa ve bir üretim (test dışı) hesabına istek göndermeye çalışılıyorsa API, enum değeri API sürümüne bağlı olan bir AuthorizationError döndürür:

Yeniden denenebilecek hatalar

TRANSIENT_ERROR veya INTERNAL_ERROR gibi bazı hatalar, kısa bir duraklamanın ardından istek yeniden denenerek çözülebilecek geçici bir soruna işaret edebilir.

Kullanıcı tarafından başlatılan isteklerde, kullanıcı arayüzünüzde hemen bir hata belirtip kullanıcıya yeniden deneme seçeneği sunabilirsiniz. Alternatif olarak, uygulamanız önce isteği otomatik olarak yeniden deneyebilir ve yalnızca maksimum yeniden deneme sayısına veya toplam kullanıcı bekleme süresine ulaşıldıktan sonra kullanıcı arayüzünde hatayı gösterebilir.

Arka uçta başlatılan istekler için uygulamanız, isteği otomatik olarak en fazla yeniden deneme sayısı kadar yeniden denemelidir.

İstekleri yeniden denerken rastgele titremeyle eksponansiyel geri yükleme politikası kullanın. Örneğin, ilk yeniden denemeden önce 5 saniye duraklatırsanız ikinci yeniden denemeden sonra 10 saniye, üçüncü yeniden denemeden sonra ise 20 saniye duraklatabilirsiniz. Ayrıca, senkronize yeniden deneme artışlarını önlemek için her aralığa küçük bir rastgele gecikme ekleyebilirsiniz. Eksponansiyel geri yükleme, API'yi çok agresif bir şekilde çağırmadığınızdan emin olmanıza yardımcı olur. Yeniden denemeler tükendikten sonra hata devam ederse sorun giderme için yanıttan request-id kaydedin.

Doğrulamayla ilgili hatalar

Doğrulama hataları, bir işleme yapılan girişin kabul edilemediğini gösterir. Örnekler: PolicyViolationError, DateError, DateRangeError, StringLengthError ve UrlFieldError.

Doğrulama hataları en sık, kullanıcının geçersiz giriş yaptığı kullanıcı tarafından başlatılan isteklerde görülür. Bu gibi durumlarda, aldığınız API hatasına göre kullanıcıya uygun bir hata mesajı sağlamanız gerekir. Ayrıca, API çağrısı yapmadan önce kullanıcı girişini yaygın hatalara karşı doğrulayarak uygulamanızın daha hızlı yanıt vermesini ve API kullanımınızın daha verimli olmasını sağlayabilirsiniz. Arka uçtan gelen istekler için uygulamanız, başarısız olan işlemi bir sıraya ekleyebilir. Bu sıra, bir operatör tarafından incelenir.

Birçok Google Ads uygulaması, Google Ads nesnelerini depolamak için yerel bir veritabanı kullanır. Bu yaklaşımla ilgili zorluklardan biri, yerel veritabanının Google Ads'deki gerçek nesnelerle senkronize olmamasıdır. Örneğin, bir kullanıcı reklam grubunu doğrudan Google Ads'de 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 hatalar şeklinde ortaya çıkabilir.

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, 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 olarak ve kademeli şekilde düzeltmesi için yeterli bilgiyi sağlar. Örneğin, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD uygulamanızın, yerel veritabanınızda bu reklamı kaldırılmış olarak işaretlemesine neden olmalıdır. Bu şekilde işlem yapamayacağınız hatalar, uygulamanızın daha kapsamlı bir senkronizasyon işi başlatmasına veya bir operatör tarafından incelenmek üzere sıraya eklenmesine neden olabilir.

Sonraki
API hatalarını anlama