Servis hesabı anahtarı yerine neden impersonation öneriliyor?

Anahtar dosyası uzun ömürlü bir sır ve sızdığında iptal edilene kadar geçerli kalıyor; Google'ın kendi rehberi de dikkatli yönetilmediğinde güvenlik riskine dönüştüğünü belirtiyor. Impersonation yönteminde, yani kendi kimliğinle o servis hesabı adına çağrı yapma modelinde, kimlik doğrulama sırasında kısa ömürlü token üretiliyor, servis hesabına Service Usage Consumer rolü, kendi hesabına ise o servis hesabı üzerinde Service Account Token Creator rolü veriliyor. Sonuçta diskte tutulan bir anahtar dosyası kalmıyor.

Tek istekte kaç kayıt gönderilebiliyor?

Audience tarafında en fazla 10.000 üye, event tarafında en fazla 2.000 event. Her iki istekte de en fazla 10 destination tanımlanabiliyor ve tek bir audience üyesi ya da event en fazla 10 kimlik taşıyabiliyor. Aşıldığında istek TOO_MANY_AUDIENCE_MEMBERS, TOO_MANY_EVENTS, TOO_MANY_DESTINATIONS ya da TOO_MANY_USER_IDENTIFIERS ile düşüyor. Bu asimetri yükleyici tarafında iki ayrı batch boyutu tanımlamayı gerektiriyor.

Hangi alanlar hash ediliyor, hangileri düz kalıyor?

E-posta, telefon numarası, ad ve soyad normalizasyondan sonra SHA256 ile hash ediliyor. Ülke kodu ve posta kodu hash edilmiyor, düz gönderiliyor. Normalizasyon kuralları da alan tipine göre değişiyor: boşluk temizliği ve küçük harfe çevirme her alanda, telefon numarasında E.164 biçimi, gmail.com ve googlemail.com adreslerinde alan adından önceki noktaların silinmesi. Şifreleme kullanılıyorsa şifrelenen şey hash'in kendisi oluyor, hash edilmemiş değer değil.

Yüklemenin işe yarayıp yaramadığı nereden anlaşılıyor?

Senkron yanıttan değil. Başarılı bir istek yalnızca request_id döndürüyor; kaç kaydın işlendiği, kaçının hata aldığı ve eşleşme oranı aralığı RetrieveRequestStatus çağrısıyla okunuyor. İşleme otuz dakikada bitebiliyor ama yirmi dört saate kadar sürebiliyor, o yüzden durum sorgusu tek seferlik değil backoff ile tekrarlanan bir döngü olmak zorunda.

Eşleşme oranı tam sayı olarak veriliyor mu?

Hayır, kova olarak veriliyor. Kovalar şöyle: yirminin altı, yirmi ile otuz arası, otuz bir ile kırk arası diye devam edip doksan bir ile yüz arasında bitiyor; ayrıca bilinmiyor ve uygun değil karşılıkları var. Yeterli kayıt yoksa alan hiç dolmuyor. Yani API üzerinden yüzde kesinliğinde bir eşleşme oranı takip edilemiyor; trend izlemek için kova geçişlerini kaydetmek gerekiyor.

Data Manager API ile Yükleme: Kimlik Doğrulamadan Diagnostics'e Kurulum Sırası

Panel connector'ının yetmediği yerde API başlıyor. Servis hesabı taklidi, batch sınırlarının asimetrisi, hash edilmeyen alanlar, kuru çalıştırmanın gizli bedeli ve yüklemenin sonucunu okumanın tek yolu.

TL;DR

Data Manager API'de kurulumun zor kısmı istek gövdesi değil, onu çevreleyen dört karar: kimlik doğrulamanın anahtar dosyası yerine _impersonation_ üzerinden kurulması, batch boyutlarının audience ve event tarafında farklı olması, hangi alanın hash edileceği, ve sonucun ayrı bir çağrıyla okunması. Senkron yanıt yalnızca isteğin kabul edildiğini söylüyor; kaç kaydın işlendiğini yirmi dört saate kadar sürebilen ayrı bir durum çağrısı veriyor.

Ücretsiz Üye Ol Giriş Yap