Aynı Dönüşümü Dört Ayrı API'ye Yazmak: Data Manager'ın Hedef Haritası

Backend’de tek bir sipariş kaydı var ve o kayıt bugün üç ya da dört yere birden gitmek zorunda: Google Ads’te dönüşüm eylemini besleyecek, GA4 tarafında tag’in kaçırdığı satın almayı tamamlayacak, Campaign Manager 360 kullanan bir hesapta Floodlight tarafına yazılacak, kimlik verisi varsa Customer Match listesini tazeleyecek. Her biri ayrı bir entegrasyon: ayrı kimlik doğrulama, ayrı alan adları, ayrı hata davranışı, ayrı bakım yükü.

Data Manager bu dağınıklığa tek veri modeli ve tek uç nokta öneriyor. Tanım kendi dokümantasyonunda açık: veri iş ortakları, ajanslar ve reklam verenler için birinci taraf veriyi birden fazla Google reklam ürününe göndermeye yarayan birleşik bir ingestion API’si.¹ Buradaki kritik ayrıntı şu: tek API, her hedefe aynı koşullarla girildiği anlamına gelmiyor. Hedeflerin her biri kendi hesap tipi, kendi yetki kuralı ve kimi durumda kendi erişim onayıyla geliyor. Yazı boyunca bunlara kapı diyorum: kod tarafı hazır olsa bile önceden açılmadığında isteğin reddedildiği ön koşullar.

Ağustos boyunca yazdığım ölçüm serisinde önce iki panelin sayılarını ortak zemine indirmeyi, sonra satır seviyesinde birleştirmeyi ve Shopify siparişini reklam tıklamasına bağlayacak join anahtarını ele aldım. Bu yazı serinin bir sonraki adımı: eşleştirilmiş kayıt hazır olduğunda onun hangi kapıdan, hangi kimlikle geri yazılacağı.

Hedef Bir Ürün Adı Değil, Hesap Tipi

Entegrasyon planlarken ilk düzeltilmesi gereken varsayım, hedefin “Google Ads” ya da “GA4” gibi bir ürün adı olduğu. Dokümantasyon hedefi hesap tipiyle tanımlıyor ve her istekte iki ayrı hesap bilgisi yer alıyor: verinin yazılacağı operating hesabı ve isteği yapan login hesabı.²

Hesap tipi	Operating hesabı	Ön koşul
GOOGLE_ADS	Customer ID	Login hesabı hiyerarşide manager olabilir
DISPLAY_VIDEO_ADVERTISER	Advertiser ID	Login hesabı advertiser ya da partner olabilir
DISPLAY_VIDEO_PARTNER	Partner ID	Login hesabı partner
GOOGLE_ANALYTICS_PROPERTY	Property ID	Login hesabı operating hesabıyla aynı olmak zorunda
FLOODLIGHT_CONFIG	Advertiser ID	Login hesabı operating hesabıyla aynı olmak zorunda
GOOGLE_AD_MANAGER_AUDIENCE_LINK	Audience Link ID	Partner bağlantısı üzerinden erişim
DATA_PARTNER	Yalnızca login	Onaylanmış data partner hesabı ve partner bağlantısı

Hesap kimliğinin yanına bir de ürün kimliği giriyor: audience kimliği, conversion action kimliği, GA4 tarafında measurement kimliği ya da Floodlight activity kimliği. Yani “hesabı bağladım” cümlesi bu API’de yetmiyor, hedef her istekte tek tek belirtiliyor.

GA4 ve Floodlight’ta Login Hesabı Serbest Değil

Google Ads tarafında manager hesabın alt hesap adına istek yapması alışılmış bir durum. GA4 ve Floodlight hedeflerinde bu alışkanlık çalışmıyor: login hesabı operating hesabıyla eşleşmezse istek OPERATING_ACCOUNT_LOGIN_ACCOUNT_MISMATCH hatasıyla düşüyor.² Bu hata kodu API’nin hata listesine 2025-11-05 sürümüyle girdi.³

Pratikte anlamı şu: ajans tarafında tek bir servis hesabıyla tüm müşterilerin GA4 mülklerine yazmayı planlayan bir kurgu, yetki modelini mülk bazında kurmak zorunda. Bunu şöyle okuyorum: kısıt dokümante ama entegrasyondan sonra fark edildiğinde düzeltmesi pahalı, çünkü servis hesabı erişimleri müşteri tarafında tek tek açılıyor.

Ad Manager tarafı ayrı bir yerde duruyor. Buradaki hedef doğrudan bir ağ kimliği değil, bir audience link kimliği ve erişim data partner bağlantısı üzerinden kuruluyor.² Data partner hesabı ise başvuru ve onay süreci gerektiriyor, kendi kendine açılan bir hesap tipi değil.⁴

İki İstek, İki Farklı Akış

API iki ayrı ingestion yolu sunuyor ve ikisi farklı veri tipleriyle çalışıyor. Audience tarafında kullanıcı listeleri yönetiliyor, event tarafında dönüşüm ve etkinlik kayıtları gönderiliyor.

Ne gönderiliyor	Hangi istek	Hedef	Kapı
Customer Match (iletişim bilgisi, user ID)	Audience	Google Ads	Standart
Customer Match (iletişim bilgisi)	Audience	Display & Video 360	Standart
Mobil cihaz kimliği listesi	Audience	Google Ads, Display & Video 360	Standart
PAIR verisi	Audience	Ad Manager tarafı dahil	Partner bağlantısı
Offline dönüşüm, enhanced conversions for leads	Event	Google Ads	Hesap tarafında şart kabulü
Multi-source dönüşüm	Event	Google Ads	2026-02-10’dan beri genel
Store sales dönüşümü	Event	Google Ads	Allowlist ve uygunluk şartı
Recommended ve custom event	Event	Google Analytics	Reserved event adları yasak
Transaction ID’li multi-source event	Event	Google Analytics	Mülk bazında allowlist
Floodlight offline dönüşüm	Event	Campaign Manager 360, Search Ads 360, DV360	Standart

Audience tarafında bir ayrıntı gözden kaçıyor: Customer Match verisi bu API üzerinden gönderildiğinde eşleştirme confidential matching ile yapılıyor ve bu davranış varsayılan.⁵ Panel tarafında da doğrudan bağlantı kullanan Customer Match akışları için aynı şey geçerli, ek ücreti yok ve reklam verenin ayrıca bir şey yapması gerekmiyor.⁶ Şifreleme ise ayrı bir katman ve zorunlu değil.

Bir başka ayrıntı hedefleme eşiği. API üzerinden yüklenen listeler ilk sürümde en az 1.000 üye şartına tabiydi, 2025-10-06’daki v1.3 ile eşik 100 üyeye indi.³ Küçük segmentlerle çalışan hesaplarda bu, daha önce hedeflemeye hiç girmeyen listelerin kullanılabilir hale gelmesi demek.

Kapılar: Allowlist, Onay ve Beyan

Dokümantasyonun ön koşul olarak saydığı maddelere bakınca çıkan sonuç şu: bu API’de gecikmenin bir kısmı kodda değil, erişim tarafında doğuyor. Üç kapı ayrı ayrı işliyor.

Birincisi allowlist. Store sales dönüşümleri yalnızca uygunluk şartlarını karşılayan Google Ads hesaplarında çalışıyor. GA4 tarafında transaction ID taşıyan multi-source event’leri de mülk bazında allowlist arkasında ve Google bunun için ayrı bir başvuru formu yayımlıyor.⁷

İkincisi data partner statüsü. Başka reklam verenlerin hesaplarına partner bağlantısı üzerinden yazmak isteyen taraflar onay sürecinden geçiyor; ilgi formu doldurulmadan bu hesap tipi açılmıyor.⁴ Ajans modelinde çalışan bir yapı için bu, teknik entegrasyondan önce planlanması gereken bir kalem.

Üçüncüsü beyan. 2026-04-01’den itibaren AB politik reklam düzenlemesi kapsamında beyanı bulunmayan hesaplarda kullanıcı listesi oluşturma, güncelleme, silme ve audience ingestion çağrıları EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED hatasıyla kısıtlanabiliyor.³ Türkiye’den yönetilen ama AB’de reklam yayınlayan hesaplarda bu kapı, entegrasyon hazır olduktan sonra fark edilen türden bir engel.

Enhanced conversions for leads tarafında da hesap düzeyinde şart kabulü ve veri politikası kontrolleri var; bunlar karşılanmadığında istek hedefe ulaşmıyor ve hata mesajı doğrudan eksik olan şartı söylüyor.³

Devraldığı Yollar ve Geçişin Somut Farkı

Data Manager’ı ayrı bir ürün gibi değil, dağınık yüklemeleri toplayan bir katman olarak okumak daha doğru. Google, mevcut entegrasyonlar için ayrı geçiş rehberleri yayımlıyor: Google Ads store sales, Google Ads ve Display & Video 360 tarafındaki Customer Match, Campaign Manager 360 offline dönüşümleri ve GA4 tarafında Measurement Protocol.³

Measurement Protocol geçişinin somut farkları rehberde sıralanıyor: ürünler arasında ortak veri modeli, hassas veri için şifreleme desteği, tek istekte birden fazla hedef, api_secret ihtiyacının kalkması ve fail-fast hata modeli.⁸ Son iki madde pratikte en çok hissedilen kısım. Measurement Protocol tarafında yanlış biçimli bir istek doğrulama sunucusu kullanılmadığında hata döndürmüyor, sonuç ancak raporda eksik veri olarak görülüyordu; Google’ın fail-fast’i geçişin farkı olarak sayması da bunu doğruluyor.

IAB Tech Lab’in Event and Conversion API standardını takip eden bir tarafta çalışılıyorsa ayrıca bir eşleme dokümanı var, yani ECAPI alanlarının Data Manager isteklerine nasıl karşılık geldiği tanımlı.⁹ Birden fazla platforma aynı event sözleşmesiyle yazan yapılar için bu, kendi eşleme tablosunu yazma yükünü kaldırıyor.

Panel Connector’ı mı, API mı?

Aynı işin iki yolu var ve seçim çoğunlukla veri hacmiyle değil ritimle ilgili.

Ölçüt	Panel connector’ı	API
Import sıklığı	En fazla günlük	Çağıran tarafın belirlediği sıklık
Satır sınırı	Tek importta 100 milyon satır	Belirtilen böyle bir sınır yok
Alan eşleme ve hash	Panelde tanımlı dönüşümlerle	Çağıran tarafın sorumluluğunda
Veri tazeliği	Kaynak, çalıştırmadan önce tazelenmiş olmalı	İstek anındaki veri
Kaynak çeşitliliği	BigQuery, S3, Snowflake, HubSpot dahil liste	Kaynaktan bağımsız

Panel tarafında import sıklığının günlük sınırı ve veri kaynağının çalıştırmadan önce tazelenmiş olma şartı açıkça yazılı.¹⁰ Tek importun 100 milyon satırı geçmemesi gerektiği de kaynak hazırlama rehberinde geçiyor; daha büyük kaynaklar bölünüyor ya da filtreleniyor.¹¹ Buna karşılık panel, alan eşleme ve hash tarafını üstleniyor: PII alanları için SHA256 hash ve normalizasyon panelde otomatik uygulanıyor.

Karar cümlesi şöyle kuruluyor: veri zaten bir ambarda duruyor ve günlük sıklık uygunsa panel connector’ı daha az bakım istiyor. Sipariş anında ya da saatlik yükleme gerekiyorsa, ya da veri hiçbir desteklenen kaynakta durmuyorsa API tarafına geçmek gerekiyor.

Kuruluma Başlamadan Yanıtlanacak Dört Soru

1. Hedef hangi hesap tipine düşüyor? GA4 ya da Floodlight ise yetki modeli mülk veya advertiser bazında kurulacak, tek servis hesabıyla merkezi kurgu çalışmayacak.
2. Kimlik yüzeyi ne? Multi-source dönüşümlerde transaction ID ve dönüşüm zamanı zorunlu, üstüne en az bir ilişkilendirme kimliği gerekiyor: hash’lenmiş kullanıcı verisi ya da GCLID, GBRAID, WBRAID gibi bir tıklama kimliği.¹²
3. Consent hangi kaynaktan geliyor? Satır düzeyinde consent alanı gönderilmiyorsa hesap düzeyindeki varsayılan devreye giriyor ve bu varsayılanın ne olduğu panelde ayrı bir ayar.¹³
4. Kapılardan hangisi açık değil? Store sales, GA4 multi-source ve data partner tarafında erişim onayı entegrasyondan önce başlatılmalı.

Bu dört soru yanıtlandığında geriye kalan iş, veriyi doğru biçimde hazırlamak ve yüklemenin sonucunu okumak. İkisi de kendi başına ayrı birer konu.

Bunlardan ilki, tag’e ek veri kaynağı bağlanan senaryoda karşılaşılan davranışlar. Yüklenen dönüşüm değerinin tag’in yazdığı değeri kalıcı olarak değiştirmesi, transaction ID eşleşme oranının düşük kalması, değerin kuruş ya da lira cinsinden gönderilmesinden doğan yüz kat fark ve yeni bir dönüşüm eylemi açıldığında ortaya çıkan çift sayım riski. Bunları ve on dört günlük teklife girmeyen deneme penceresini ek veri kaynağı yazısında ele aldım.

İkincisi uygulama tarafı: kimlik doğrulama kurulumu, hash ve normalizasyon kuralları, opsiyonel şifreleme ve yükleme sonrası diagnostics okuma. Bunu API uygulama yazısında anlattım.

Footnotes

1. Data Manager API (Google for Developers). Tanım birebir: “A unified ingestion API for data partners, agencies and advertisers to send first-party data to multiple Google advertising products.” Aynı sayfa audience ve conversion event olmak üzere iki ana kullanım ailesini sıralıyor. ↩
2. Destinations (Data Manager API). Hesap tipleri, operating ve login hesap ilişkisi ile hedef ürün kimlikleri bu sayfada tanımlı. Data partner erişimi için koşul da burada: linked account yalnızca login hesabının account_type değeri DATA_PARTNER ise ve operating hesabının bir üstü data partner hesabına bağlıysa belirtilir. ↩ ↩² ↩³
3. Release notes (Data Manager API). OPERATING_ACCOUNT_LOGIN_ACCOUNT_MISMATCH hata nedeni 2025-11-05 v1.4 ile eklendi. Hedefleme eşiğinin 1.000’den 100 üyeye inmesi 2025-10-06 v1.3 kaydında; EU PAR beyanı ve EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED 2026-03-26 kaydında, 2026-04-01 tarihi belirtilerek. Enhanced conversions for leads tarafındaki şart ve politika hataları 2025-08-06 v1.2 kaydında. Multi-source dönüşümlerin tüm Google Ads hesaplarına açılması 2026-02-10 kaydında. Upgrade rehberleri ilgili sürüm notlarında ürün ürün bağlanıyor. ↩ ↩² ↩³ ↩⁴ ↩⁵
4. Set up API access (Data Manager API). Sayfa data partner hesaplarının yalnızca onay sürecinden sonra verildiğini belirtiyor ve ilgi formuna yönlendiriyor. Ön koşullar bölümünde Google Cloud projesi, serviceusage.services.enable yetkisi ve gcloud kurulumu sıralanıyor; kimlik doğrulamada API anahtarı dışındaki yöntemlerin kullanıldığı ve Data Manager kapsamının hassas kapsam sayıldığı da aynı sayfada. ↩ ↩²
5. Audiences overview (Data Manager API). Google Ads tarafında iletişim bilgisi ya da user ID ile Customer Match ve mobil cihaz kimliği kitleleri, Display & Video 360 tarafında iletişim bilgisiyle Customer Match ve mobil cihaz kimliği kitleleri destekleniyor. Sayfa Customer Match verisinin confidential matching ile işlendiğini ve şifreleme desteğini de belirtiyor. ↩
6. Confidential matching (Google Ads Data Manager Yardım). Özellik varsayılan olarak açık ve ek ücreti yok: doğrudan bağlantı ile Customer Match kullanan veriler otomatik olarak confidential matching ile işleniyor. Şifreleme opsiyonel, işleme kodu ise herkese açık bir depoda yayımlanıyor. ↩
7. Events overview (Data Manager API). Store sales dönüşümleri yalnızca allowlist’teki Google Ads hesaplarında; transaction ID taşıyan multi-source event’ler yalnızca allowlist’teki Google Analytics mülklerinde kullanılabiliyor ve sayfa başvuru formunu veriyor. Floodlight offline dönüşümleri Campaign Manager 360, Search Ads 360 ve Display & Video 360 için sıralanıyor. ↩
8. Upgrade from Measurement Protocol (Data Manager API). Rehber farkları ürünler arası ortak veri modeli, şifreleme desteği, tek istekte birden fazla hedef, api_secret gerekmemesi ve fail-fast hata modeli olarak sıralıyor. ↩
9. ECAPI specification mapping (Data Manager API). IAB Tech Lab Event and Conversion API standardını takip eden entegrasyonlar için alan eşlemesi. ↩
10. Manage your connections (Google Ads Data Manager Yardım). Zamanlama bölümünde import sıklığının en fazla günlük olduğu ve verinin çalıştırmadan önce tazelenmesi gerektiği yazılı. Aynı sayfa hesap düzeyi consent varsayılanlarını ve hangi özellikleri kapsadığını da veriyor. ↩
11. Prepare your data for import (Google Ads Data Manager Yardım). Satır sınırı birebir: “Data imports shouldn’t exceed 100 million rows.” Aynı sayfa PII alanları için SHA256 hash ve normalizasyon kurallarını, dosya biçimi ve tarih biçimi şartlarını da tanımlıyor. ↩
12. Boost your tag with additional data sources (Google Ads Data Manager Yardım). Zorunlu alanlar transaction ID ve dönüşüm tarihi ile saati; bunun yanında en az bir ilişkilendirme kimliği gerekiyor, hash’lenmiş kullanıcı verisi ya da GCLID, GBRAID, WBRAID gibi bir tıklama kimliği. ↩
13. Manage your connections (Google Ads Data Manager Yardım). İçe aktarılan ve yüklenen veri için hesap düzeyinde varsayılan consent durumu ayrı bir ayar; bağlantı, import ya da yükleme düzeyinde belirtilen consent değerleri bu varsayılanı geçersiz kılıyor. ↩

Önemli Noktalar

• 01 Hedef, ürün adı değil hesap tipidir. Dokümantasyon hedefleri GOOGLE_ADS, DISPLAY_VIDEO_ADVERTISER, DISPLAY_VIDEO_PARTNER, GOOGLE_ANALYTICS_PROPERTY, FLOODLIGHT_CONFIG, GOOGLE_AD_MANAGER_AUDIENCE_LINK ve DATA_PARTNER olarak ayırıyor; her isteğin ayrıca operating hesabı ve login hesabı var.
• 02 GA4 ve Floodlight hedeflerinde login hesabı operating hesabıyla eşleşmek zorunda. Eşleşmezse istek OPERATING_ACCOUNT_LOGIN_ACCOUNT_MISMATCH ile düşer, yani yetki modeli Ads tarafındaki manager hesap alışkanlığıyla aynı değil.
• 03 Audience tarafı ile event tarafı iki ayrı istek. Customer Match, mobil cihaz kimliği ve PAIR verisi audience isteğine; offline dönüşüm, enhanced conversions for leads, store sales, multi-source dönüşüm ve GA4 event'leri event isteğine gider.
• 04 Kapıların bir kısmı teknik değil idari. Store sales ve GA4 multi-source event'leri allowlist istiyor, data partner hesabı onay sürecinden geçiyor, AB'de reklam veren hesaplarda politik reklam beyanı olmadan audience çağrıları hata veriyor.
• 05 Panel connector'ı ile API aynı şey değil. Panel tarafında import sıklığı en fazla günlük ve tek seferde 100 milyon satır sınırı var; API tarafında bu iki sınır yok, buna karşılık alan eşleme, hash ve zamanlama tamamen çağıran tarafın sorumluluğunda.

Sık Sorulan Sorular (FAQ)

+ Data Manager API hangi Google ürünlerine veri gönderiyor?

Audience tarafında Google Ads, Display & Video 360 ve Google Ad Manager; event tarafında Google Ads, Google Analytics ve Google Marketing Platform'un Floodlight ürünleri, yani Campaign Manager 360, Search Ads 360 ve Display & Video 360. Dokümantasyon bunları ürün adıyla değil hesap tipiyle listeliyor ve her isteğe hedef olarak bir hesap kimliği ile o hesabın içindeki bir ürün kimliği veriliyor: audience kimliği, conversion action kimliği, GA4 tarafında measurement kimliği ya da Floodlight activity kimliği.

+ Google Ads offline dönüşüm yüklemesi için Ads API yerine bu API mi kullanılmalı?

Yeni kurulan entegrasyonlarda evet, çünkü yeni özellikler bu tarafta çıkıyor. Multi-source dönüşümler 2026-02-10 itibarıyla tüm Google Ads hesaplarına açıldı, store sales ve Floodlight offline dönüşüm desteği de sürüm sürüm buraya eklendi. Google eski yollardan geçiş için ayrı upgrade rehberleri yayımlıyor: Google Ads store sales, Customer Match, Campaign Manager 360 offline dönüşüm ve Measurement Protocol için ayrı ayrı. Mevcut ve çalışan bir entegrasyonu tek başına yenilik olduğu için taşımak gerekmiyor, taşıma kararı yeni bir hedef veya yeni bir alan ihtiyacı doğduğunda anlamlı.

+ GA4 tarafında Measurement Protocol'den geçmenin somut farkı ne?

Kimlik doğrulama modeli değişiyor. Measurement Protocol api_secret ile çalışıyordu, Data Manager tarafında api_secret gerekmiyor ve OAuth tabanlı kimlik doğrulama kullanılıyor. Bunun yanında veri modeli ürünler arasında ortak, tek istekte birden fazla hedefe gönderim yapılabiliyor ve hata modeli fail-fast, yani hatalı istek sessizce kabul edilmiyor. Measurement Protocol'ün sessiz kabul davranışı doğrulamayı zorlaştıran tarafıydı.

+ Panel üzerinden connector kurmak varken API'ye neden ihtiyaç duyulur?

İki sert sınır yüzünden, biri sıklıkta biri hacimde. Panel tarafında bir connection'ın import sıklığı en fazla günlük ve veri kaynağının çalıştırmadan önce tazelenmiş olması gerekiyor; ayrıca tek import 100 milyon satırı geçemiyor. Günlük ritim ve tablo tabanlı akış bu iki sınırın altında kalıyorsa panel connector'ı daha az bakım istiyor, çünkü alan eşleme, hash ve zamanlama panelde tanımlanıyor. Canlı bir event akışı, saatlik yükleme ya da 100 milyon satırın üstünde bir hacim varsa API tarafına geçmek gerekiyor.

+ Bu API'yi kullanmak için Google Cloud projesi şart mı?

Evet. API'nin etkinleştirileceği bir Google Cloud projesi, o projede serviceusage.services.enable yetkisi olan bir hesap ve gcloud komut satırı aracı ön koşul olarak veriliyor. Kimlik doğrulama tarafında API anahtarı dışındaki yöntemler kullanılabiliyor; pratikte kullanıcı hesabı ya da servis hesabı taklidi üzerinden Application Default Credentials kuruluyor. Data Manager kapsamı hassas kapsam sayıldığı için proje tarafında ayrıca kapsam onayı adımı var.