İstek durumunu ve teşhisleri kontrol etme

Etkinlik veya kitle üyesi gönderme istekleri eşzamansız olarak işlenir. Başarılı bir besleme yanıtı request_id döndürür ve isteğin tüm şartları karşıladığını ve işleme için kabul edildiğini gösterir. Ancak istekteki kayıtların başarıyla işlenip işlenmediğini göstermez.

Yüklemenizin durumunu kontrol etmek ve teşhisleri incelemek için döndürülen request_id değerini RetrieveRequestStatus ile kullanın.

İsteklerinizin durumunu kontrol etmek ve etkinlik ile kitle yüklemelerinizin durumunu doğrulamak için önerilen iş akışı aşağıda verilmiştir:

  1. Etkinlik göndermek veya kitle üyesi göndermek ya da kaldırmak için istek gönderin.

  2. Her besleme isteğinin genel durumunu kontrol edin. Başarılı bir istekte code, 0 değerine eşit (enum değeri OK, HTTP yanıtı 200 OK) olan bir Status bulunur ve IngestEventsResponse, IngestAudienceMembersResponse veya RemoveAudienceMembersResponse döndürülür.

    İstek başarısız olursa hatayı gidermek için isteği değiştirin ve tekrar gönderin.

    İstek başarılı olursa yanıtın request_id değerini yakalayın. Bu değeri, sonraki adımda işleme durumunu kontrol etmek için kullanabilirsiniz.

  3. 30 dakika bekleyin, ardından her başarılı request_id için bir RetrieveRequestStatus isteği gönderin.

    RetrieveRequestStatusRequest için tek bir request_id değeri gerekir. Başarılı bir besleme isteğinden aldığınız her istek kimliği için ayrı bir durum isteği gönderin.

    Her bir hedefin hedef durumu SUCCESS, PARTIAL_SUCCESS veya FAILED olana kadar her request_id için bu adımı düzenli olarak tekrarlayın. Her istek arasında beklemek için önerilen yoklama stratejisini uygulayın.

  4. Yüklemelerinizin düzgün çalıştığını doğrulamak ve verilerinizle ilgili sorunları belirlemek için her bir RetrieveRequestStatusResponse inceleyin.

  5. Veri sorunlarını düzeltme

  6. 1. adıma dönün ve yüklemelerinizle ilgili tüm sorunları giderene kadar bu adımları tekrarlayın.

Genel hedef durumunu kontrol etme

RetrieveRequestStatusResponse içindeki request_status_per_destination, ilgili besleme isteğindeki her hedef için ayrı bir giriş içerir.

Örneğin, IngestAudienceMembersRequest, verileri 3 farklı kitleye göndermek için destinations listesinde 3 giriş içeriyorsa durum yanıtı request_status_per_destination içinde 3 giriş (kitle başına bir giriş) içerir.

Data Manager API'nin ilgili hedef için verileri işlemeyi tamamlayıp tamamlamadığını belirlemek üzere her RequestStatusPerDestination için request_status alanını kontrol edin.

request_status için olası değerler şunlardır:

  • PROCESSING: Hedefle ilgili veriler hâlâ işleniyor. Bu aşamada hedef için uyarılar ve hatalar doldurulmaz. Durum, nihai duruma ulaşana kadar sorgulamaya devam edin.

  • SUCCESS: Hedef için istek işleme hatasız tamamlandı. İşleme sırasında işaretlenen uyarıları kontrol edin.

  • FAILED: Hatalar nedeniyle hedefle ilgili kayıtların tümü başarısız oldu. Tüm kayıtların neden başarısız olduğunu belirlemek için uyarıları ve hataları kontrol edin. İşleme sırasında işaretlenen uyarıları da kontrol edin.

  • PARTIAL_SUCCESS: Hedef için kayıtlardan bazıları başarılı oldu ancak diğerleri hatalar nedeniyle başarısız oldu. Bazı kayıtların neden başarısız olduğunu belirlemek için hataları kontrol edin. Ayrıca, işleme sırasında işaretlenen uyarıları da kontrol edin.

Teşhisleri inceleyin

Bir hedefin request_status değeri SUCCESS, FAILED veya PARTIAL_SUCCESS değerine ulaştığında, sayıları doğrulamak ve sorunları gidermek için yanıttaki ayrıntılı teşhisleri inceleyin.

Her hedef için etkinlik veya kitle durumunu kontrol etme

Besleme isteği türüne karşılık gelen durum alanını inceleyin. Her RequestStatusPerDestination için aşağıdaki alanlardan yalnızca biri ayarlanır:

Etkinlik besleme durumu

İstek bir IngestEventsRequest ise events_ingestion_status alanı doldurulur.

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestEventStatus record_count kontrol edin. record_count hem başarılı hem de başarısız kayıtları içerir.

Kitle üyelerinin besleme durumu

İstek bir IngestAudienceMembersRequest ise audience_members_ingestion_status alanı doldurulur. Her kitle verisi türü için kontrol edilmesi gereken IngestAudienceMembersStatus alanı aşağıda verilmiştir. Bu alanlardan yalnızca biri ayarlanır.

composite_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestCompositeDataStatus'nin record_count bölümünü kontrol edin. record_count hem başarılı hem de başarısız kayıtları içerir.

Tanımlayıcı sayısının beklentilerinizi karşıladığını doğrulamak için data_type_counts sayfasını kontrol edin. Bu liste, DataType tarafından alınan tüm tanımlayıcıların (e-posta adresi, telefon numarası, fiziksel adres ve IP adresi gibi) dökümünü sağlar.

İstekte yeterli sayıda kayıt varsa upload_match_rate_range, istekteki kayıtların eşleşme oranı aralığını içerir.

google_user_id_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestGoogleUserIdDataStatus'nin record_count bölümünü kontrol edin. record_count hem başarılı hem de başarısız kayıtları içerir.

Alınan Google kullanıcı kimliklerinin sayısının beklentilerinizi karşıladığını doğrulamak için google_user_id_count kontrol edin.

mobile_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestMobileDataStatus'nin record_count bölümünü kontrol edin. record_count hem başarılı hem de başarısız kayıtları içerir.

Alınan Mobile ID sayısının beklentilerinizi karşıladığını doğrulamak için mobile_id_count sayfasını kontrol edin.

pair_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestPairDataStatus'nin record_count değerini kontrol edin. record_count, hem başarılı hem de başarısız kayıtları içerir.

Alınan PAIR kimliklerinin sayısının beklentilerinizi karşıladığını doğrulamak için pair_id_count kontrol edin.

partner_provided_id_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestPartnerProvidedIdDataStatus record_count bölümünü kontrol edin. record_count hem başarılı hem de başarısız kayıtları içerir.

Alınan iş ortağı tarafından sağlanan kimliklerin sayısının beklentilerinizle eşleştiğini onaylamak için partner_provided_id_count kontrol edin.

ppid_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestPpidDataStatus'nin record_count değerini kontrol edin. record_count, hem başarılı hem de başarısız kayıtları içerir.

Alınan PPID sayısının beklentilerinizi karşıladığını onaylamak için ppid_count kontrol edin.

user_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestUserDataStatus'nin record_count değerini kontrol edin. record_count, hem başarılı hem de başarısız kayıtları içerir.

Alınan kullanıcı kimliklerinin sayısının beklentilerinizi karşıladığını onaylamak için user_identifier_count kontrol edin.

İstekte yeterli sayıda kayıt varsa upload_match_rate_range, istekteki kayıtların eşleşme oranı aralığını içerir.

user_id_data_ingestion_status

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için IngestUserIdDataStatus'nin record_count değerini kontrol edin. record_count, hem başarılı hem de başarısız kayıtları içerir.

Alınan kullanıcı kimliklerinin sayısının beklentilerinizi karşıladığını doğrulamak için user_id_count kontrol edin.

Kitle üyelerini kaldırma durumu

İstek bir RemoveAudienceMembersRequest ise audience_members_removal_status alanı doldurulur. Her kitle verisi türü için kontrol edilmesi gereken RemoveAudienceMembersStatus alanı aşağıda verilmiştir. Bu alanlardan yalnızca biri ayarlanır.

composite_data_removal_status
Bileşik veriler için kaldırma durumu
google_user_id_data_removal_status
Google kullanıcı kimliği verileri için kaldırma durumu
mobile_data_removal_status
Mobil veriler için kaldırma durumu.
pair_data_removal_status
PAIR verileri için kaldırma durumu.
partner_provided_id_data_removal_status
İş ortağı tarafından sağlanan kimlik verileri için kaldırma durumu
ppid_data_removal_status
PPID verileri için kaldırma durumu.
user_data_removal_status
Kullanıcı verilerinin kaldırılma durumu.
user_id_data_removal_status
Kullanıcı kimliği verileri için kaldırma durumu

Alınan toplam kayıt sayısının beklentilerinizi karşıladığını doğrulamak için record_count kontrol edin. record_count hem başarılı hem de başarısız kayıtları içerir.

Ayrıca, alınan tanımlayıcıların toplam sayısını onaylamak için user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count veya partner_provided_id_count değerini kontrol edin.

Bileşik veriler için data_type_counts sütununu kontrol ederek tanımlayıcı sayısının beklentilerinizi karşıladığını doğrulayın. Bu liste, DataType tarafından alınan tüm tanımlayıcıların (ör. e-posta adresi, telefon numarası, fiziksel adres ve IP adresi) dökümünü sağlar.

Uyarıları ve hataları kontrol etme

Hedef ve istek türü için durum alanlarına ek olarak RetrieveRequestStatusResponse, istekle ilgili uyarıların ve hataların dökümünü içerir.

  • Hata, API'nin kaydı tamamen reddettiğini gösterir.

  • Uyarı, API'nin kaydı reddetmediğini ancak kaydın verilerinin bir kısmını yok saymak zorunda kaldığını gösterir.

Örneğin, bir Event şifrelenmiş UserIdentifier verileri ve gclid gibi AdIdentifiers içeriyorsa ve UserIdentifier verilerinin şifresi çözülemiyorsa Data Manager API'si, kaydı AdIdentifiers kullanarak işlemeye devam eder ancak PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR uyarısını döndürür.

Ancak Event, AdIdentifiers içermiyorsa ve UserIdentifier verilerinin şifresi çözülemiyorsa Data Manager API kaydın tamamını reddeder ve PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR hatasını bildirir. Bunun nedeni, geçerli bir Event'nin ad_identifiers veya user_data değerlerinden en az birini içermesi gerektiğidir.

Uyarı ve hata bilgilerini içeren yanıt alanları şunlardır: Bu alanlar, genel hedef durumu SUCCESS, PARTIAL_SUCCESS veya FAILED olduğunda doldurulur.

warning_info

WarningInfo nesnesi. warning_counts alanı, WarningCount nesnelerinin bir listesini içerir. Her WarningCount şunları içerir:

  • reason: Uyarının türü.

  • record_count: Bu tür uyarı içeren kayıtların sayısı.

  • record_indices: Orijinal istekte bu tür bir uyarı içeren kayıtların dizinleri. Etkilenen kayıtları kontrol etme bölümüne bakın.

Genel hedef durumu SUCCESS olsa bile warning_info kontrol edin.

error_info

Bir ErrorInfo nesnesi. error_counts alanı, ErrorCount nesnelerinin bir listesini içerir. Her ErrorCount şunları içerir:

  • reason: Hatanın türü.

  • record_count: Bu tür bir hata nedeniyle başarısız olan kayıtların sayısı.

  • record_indices: Orijinal istekte bu tür bir hata nedeniyle başarısız olan kayıtların dizinleri. Etkilenen kayıtları kontrol etme bölümüne bakın.

Etkilenen kayıtları kontrol etme

İçerik alma isteğinizde uyarı veya hata içeren kayıtları tam olarak belirlemek için her bir WarningCount ve ErrorCount öğesinin record_indices değerini kullanın.

record_indices içindeki her değer, orijinal istekteki bir kaydın 0 tabanlı konumudur:

Örneğin, 0 değerine sahip bir record_indices, istekteki ilk etkinliği veya kitle üyesini ifade eder.

record_indices analizini yaparken aşağıdakileri göz önünde bulundurun:

  • Dizinler her hedef için ayrı ayrı raporlanır. İsteğinizde birden fazla hedef varsa her RequestStatusPerDestination, ilgili hedef için uyarı veya hata içeren kayıtların dizinlerini bildirir. Aynı kayıt birden fazla RequestStatusPerDestination içinde görünebilir.

  • Bir kayıt birden fazla nedenden dolayı görünebilir. Örneğin, bir kayıtta hem hata hem de uyarı veya birden fazla uyarı türü olabilir. Belirli bir kayıttaki tüm sorunları bulmak için hedefteki her WarningCount ve ErrorCount öğesini kontrol edin.

Beş etkinlik ve bir hedef içeren IngestEventsRequest için örnek bir RetrieveRequestStatusResponse aşağıda verilmiştir. İşlem kimliği zaten yüklendiği için ilk etkinlik (dizin 0) ve dördüncü etkinlik (dizin 3) başarısız oldu. Üçüncü etkinlik (dizin 2) ise işlendi ancak önceden tanımlanmamış bir özelleştirilebilen değişken değerine sahipti.

{
  "requestStatusPerDestination": [
    {
      "destination": {
        "operatingAccount": {
          "accountType": "GOOGLE_ADS",
          "accountId": "1234567890"
        },
        "productDestinationId": "123456789"
      },
      "requestStatus": "PARTIAL_SUCCESS",
      "eventsIngestionStatus": {
        "recordCount": "5"
      },
      "errorInfo": {
        "errorCounts": [
          {
            "recordCount": "2",
            "reason": "PROCESSING_ERROR_REASON_DUPLICATE_TRANSACTION_ID",
            "recordIndices": [0, 3]
          }
        ]
      },
      "warningInfo": {
        "warningCounts": [
          {
            "recordCount": "1",
            "reason": "PROCESSING_WARNING_REASON_CUSTOM_VARIABLE_NOT_PREDEFINED",
            "recordIndices": [2]
          }
        ]
      }
    }
  ]
}

Kayıtları düzeltmek için:

  1. Her ErrorCount ve WarningCount için record_indices kullanarak orijinal isteğinizdeki ilgili kayıtları bulun.

  2. Her bir kaydı nasıl düzelteceğinizi belirlemek için reason kullanın. Her bir nedenin açıklaması için ProcessingErrorReason ve ProcessingWarningReason sayfalarına bakın.

  3. Yalnızca düzeltilmiş kayıtları içeren yeni bir veri alma isteği gönderin. Başarılı olan kayıtları yeniden göndermeyin. Aksi takdirde, yinelenen veriler veya ek hatalar oluşabilir.

Anket stratejisi

Orijinal istekteki her hedef için request_status, SUCCESS, FAILED veya PARTIAL_SUCCESS değerine ulaşana kadar eksponansiyel geri yükleme algoritması kullanarak RetrieveRequestStatusRequest öğesini düzenli olarak gönderin. Bu işlem 24 saati bulabilir ancak Data Manager API, bazı istekleri 30 dakika gibi kısa bir sürede işleyebilir.

Canlılık ve kota kullanımı arasında denge kuran makul bir ilk bekleme süresi ve yeniden deneme yapılandırması örneğini aşağıda bulabilirsiniz:

Ayar Değer
İlk teşhis isteğinden önceki bekleme süresi (dakika) 30
Geri çekilme çarpanı 1.3
Maksimum geri çekilme (dakika) 60 (1 saat)
Maksimum toplam süre (dakika) 1440 (24 saat)

Bu yapılandırmayla ilgili isteklerin sırası ve geçen süre şu şekildedir:

Grafik

Anket Stratejisi

Veriler

Deneme Besleme İsteğinden Bu Yana Geçen Süre (ss:dd) Denemeden Önceki Gecikme Notlar
1 00:30 30,0 dk. Öncelikle durumun kullanılabilir olup olmadığını kontrol edin
2 01:09 39,0 dk.
3 01:59 50,7 dk.
4 02:59 60,0 dk. Gecikme süresi artık 1 saatle sınırlıdır
5 03:59 60,0 dk.
6 04:59 60,0 dk.
7 05:59 60,0 dk.
8 06:59 60,0 dk.
9 07:59 60,0 dk.
10 08:59 60,0 dk.
11 09:59 60,0 dk.
12 10:59 60,0 dk.
13 11:59 60,0 dk. 12 saatlik sınır
14 12:59 60,0 dk.
15 13:59 60,0 dk.
16 14:59 60,0 dk.
17 15:59 60,0 dk.
18 16:59 60,0 dk.
19 17:59 60,0 dk.
20 18:59 60,0 dk.
21 19:59 60,0 dk.
22 20:59 60,0 dk.
23 21:59 60,0 dk.
24 22:59 60,0 dk.
25 23:59 60,0 dk. Maksimum toplam süre olan 24 saatten önceki son istek

Birçok istemcinin aynı anda yeniden deneme yapmasıyla ortaya çıkan "gürleyen sürü" sorununu önlemek için bekleme gecikmelerine küçük ve rastgele bir miktar titreşim ekleyin.

Yetkilendirme koşulları

RetrieveRequestStatusRequest, hedef hesapları veya istek başlıklarını kabul etmez. Bunun yerine Data Manager API, request_id ile ilişkili orijinal veri alma isteğindeki hedefleri tanımlar ve her Destination için arayanın operating_account erişimine sahip olduğunu doğrular.

Bir isteğin durumunu kontrol etmek için RetrieveRequestStatusRequest içinde kullanılan kimlik bilgilerinin, orijinal besleme isteğindeki her hedefin operating_account için aşağıdaki koşulları karşılaması gerekir:

  • Aynı erişim yolu: Kimlik bilgileri, orijinal besleme isteğinde belirtilen erişim yolunun aynısını kullanarak her bir operating_account öğesine erişebilmelidir.

    Örneğin, bir Google Ads operating_account için besleme isteğinde login_account olarak bir üst yönetici hesabı belirtildiyse kimlik bilgilerinin aynı yönetici hesabı üzerinden operating_account erişimi de olmalıdır. Kimlik bilgileriyle ilişkili Google Hesabı'nın alt operating_account hesabına doğrudan erişimi olsa bile, bu hesabın içe aktarma sırasında belirtilen login_account yönetici hesabı üzerinden erişimi yoksa istek PERMISSION_DENIED hatasıyla başarısız olur.

  • Yeterli erişim düzeyi: Kimlik bilgileriyle ilişkili Google Hesabı'nın, operating_account ürününe veri alma izni olan bir erişim düzeyi veya rolü olmalıdır.

    Örneğin, Google Ads'de Google Hesabı'nın Yönetici veya Standart erişim düzeyine sahip olması gerekir. Salt okuma erişim düzeyine sahip bir hesabın kimlik bilgilerini içeren istek, PERMISSION_DENIED hatasıyla başarısız olur.