Birinci Parti Veri Mimarisi: Google Ads ve Meta Rehberi

Reklam platformları ve tarayıcı gizlilik politikalarındaki değişiklikler, pazarlama ve ölçüm ekiplerinin üçüncü taraf çerezleri ve dış kaynaklı veri bağımlılığını yeniden değerlendirmesine neden oldu. Bu bağlamda birinci parti veri (first‑party data), doğrudan kullanıcı etkileşimlerinden toplanan olayların doğruluğunu, devamlılığını ve kontrolünü artırmaya odaklanan bir yaklaşım sunar.

Birinci parti veri mimarisinin temel amacı, pazarlama hedefleri ile teknik uygulama arasında ortak bir dil ve süreç sağlamaktır. Hangi olayların (events) toplanacağı, bu olayların nasıl etiketleneceği ve hangi kanal/katmanlardan gönderileceği gibi kararların hem iş hem de mühendislik tarafında net olması gerekir. Ayrıca veri kalitesini güvence altına almak, gizlilik kurallarına uygunluğu sağlamak ve reklam platformlarına güvenli aktivasyon yolları oluşturmak da mimarinin ayrılmaz parçalarıdır.

Bu rehber, Google Ads ve Meta (Facebook/Instagram) ekosistemlerinde uygulanabilir teknik adımları, event standardizasyonu önerilerini ve operasyonel kontrolleri pratik bir çerçevede sunmayı hedefler. Rehber boyunca hem front‑end hem de back‑end uygulanabilirlik, test ve monitoring pratikleri ile Conversions API / server‑side entegrasyonlarına ilişkin temel akışlar ele alınacaktır.

Her kuruluşun ihtiyaçları ve hedefleri farklıdır; bu yüzden event önceliklendirmesi yapılırken pazarlama hedefleri ve raporlama gereksinimleri birlikte değerlendirilmelidir. Dönüşüm odaklı bir yaklaşım genellikle önceliklendirme için iyi bir başlangıç noktasıdır: satın alma/dönüşüm, ödeme sayfası olayları (checkout_started, payment_success), sepete ekleme (add_to_cart), ürün detay görüntülemesi (product_view) ve form gönderimleri (lead_submitted) gibi olaylar doğrudan optimizasyona katkı sağlar.

Buna ek olarak analitik ve segmentasyon ihtiyaçları da göz önünde tutulmalıdır. Örneğin tekrar satın alma davranışlarını veya yüksek yaşam boyu değer (LTV) gösteren kullanıcıları izlemek istiyorsanız, kullanıcı oturumları, ürün kategorisi etkileşimleri ve uygulama içi kritik eylemler gibi olayları da planınıza dahil etmelisiniz.

Önceliklendirme sürecinde şu soruları sorun: Bu event doğrudan kampanya optimizasyonuna katkı sağlıyor mu? Raporlama ve LTV analizleri için kritik mi? Sunucu tarafı ile gönderilmesi gereken hassas kullanıcı tanımlayıcılar içeriyor mu? Bu soruların yanıtı hangi olayların hemen uygulanması gerektiğini belirlemenize yardımcı olacaktır.

Veri layer (data layer) tasarımı, front‑end ve back‑end ekipleri arasında ortak bir sözlük oluşturur. Her event için net bir şema tanımlanmalıdır: event adı, kategori, özellikler (properties), varsa product/item objesi ve zaman damgası (timestamp). Bu şema hem client hem de server tarafında tutarlı veri aktarımına imkan verir.

Event isimlendirmesinde okunabilir, platformdan bağımsız ve tekrar kullanılabilir anahtarlar tercih edilmelidir. Örnek isimlendirme: purchase_completed, product_view, add_to_cart, lead_submitted. Property anahtarlarında ise price, currency, product_id, user_id gibi sabit anahtarlar kullanılmalıdır. Böyle bir standardizasyon Google Tag Manager, server‑side kolektörler ve reklam platformlarına gönderilecek feed'ler için uyumluluk sağlar.

Ek olarak, versiyonlama ve şemada yapılacak değişikliklerin dokümantasyonu önemlidir. Yeni property eklendiğinde veya mevcut property tipi değiştiğinde bunun merkezi bir repo veya paylaşılan dokümanda takip edilmesi, test süreçlerinin ve entegrasyonların başarısı için gereklidir.

İstemci tarafı (browser/app) toplama, hızlı kurulum, zengin kullanıcı bağlamı ve anlık etkileşim verisi sağlar. Ancak, tarayıcı engellemeleri, çerez kısıtlamaları ve ad‑blocking gibi etkenler nedeniyle veri kayıpları yaşanabilir. Bu katman, kullanıcı etkileşimlerinin ayrıntılı bağlamını (ör. sayfa konumu, DOM etkileşimleri) sunar.

Sunucu tarafı (server‑side/edge) toplama ise daha güvenilir bir teslimat ve daha yüksek eşleşme oranları sağlayabilir; ayrıca identifier hashing gibi güvenlik uygulamalarını sunucu tarafında yöneterek gizlilik gereksinimlerine daha kolay uyum sağlar. Sunucu tarafı, client tarafından gelen ham veriyi doğrulama, temizleme ve zenginleştirme için de uygun bir noktadır.

Karar verirken dikkate alınması gereken genel kriterler: veri güvenilirliği gereksinimi, consent/izin yönetimi akışı, teknik kapasite ve işletme maliyetleri. Pratikte hibrit bir yaklaşım çoğu durumda dengeli sonuç verir: kritik dönüşümlerin server‑side kopyası gönderilirken client‑side zengin bağlam verisi tamamlayıcı olarak tutulur.

Veri kalitesini sürdürülebilir hale getirmek için operasyonel bir kontrol listesi oluşturun. Temel maddeler şunlardır: event tanımlarının güncelliği, property tip ve format tutarlılığı, duplicate event tespiti, timestamp doğruluğu ve hata/eksik veri oranlarının izlenmesi.

Ayrıca veri eşleme (mapping) adımlarının merkezi bir dokümantasyonda toplanması önemlidir. Google Ads dönüşüm kimlikleri, Meta event isimleri ve internal data layer alanları arasındaki eşlemeler tek bir kaynakta tutulmalı; bu, test ve QA süreçlerini hızlandırır ve farklı ekipler arasındaki uyumsuzlukları azaltır.

Test süreçlerinde hem pozitif hem negatif senaryoları doğrulayın: beklenen event gönderimi, eksik field’ların nasıl ele alınacağı, hashing ve anonimleştirme adımlarının doğrulanması ve API hatalarına karşı retry mekanizmalarının test edilmesi gibi. Düzenli olarak run edilen veri kalitesi raporları, sapmaları erken tespit etmeye yardımcı olur.

Google ekosisteminde, server‑side implementasyonlar için Google Tag Manager Server‑Side ve Google Ads Conversion API gibi araçlar kullanılabilir. Bir yaygın akış, client tarafından gönderilen data layer push’larının GTM Server‑Side collector tarafından alınması, temizlenmesi ve Google Ads Conversion API’ye iletilmesidir. Bu akış, client‑side kayıplarını azaltmaya ve daha yüksek eşleşme oranları elde etmeye yardımcı olabilir.

Meta tarafında Conversions API (CAPI), Pixel ile paralel çalışarak sunucu kaynaklı dönüşümleri göndermenize imkan tanır. Temel akış: data layer → server collector endpoint → mapping/validation → Conversions API. CAPI entegrasyonunda kullanıcı tanımlayıcıların (örn. hashed email, phone) güvenli ve uygun şekilde işlenmesi önemlidir. Hashing ve veri saklama politikaları entegrasyonun ayrılmaz parçalarıdır.

Her iki platform için de hangi alanların zorunlu, hangilerinin opsiyonel olduğuna ilişkin dokümantasyon hazırlayın ve bir test/staging ortamı kurun. Canlıya almadan önce eşleşme oranlarını ve event doğruluğunu test etmek, aktivasyon başarısı için kritik bir adımdır.

Toplanan veriyi aktivasyona dönüştürmenin temel yolları arasında hedef kitle (audience) oluşturma, müşteri dosyası upload’u (hashed identifiers ile), LTV tabanlı segmentler ve offline conversion feed bulunur. Google Ads Veri Yöneticisi (Google Ads Data Manager) farklı veri kaynaklarını bir araya getirmeye ve Google Ads içinde kullanılacak hale getirmeye yardımcı olur.

Segmentleri oluştururken her segmentin açık bir kullanım senaryosu olmalı: yeniden hedefleme, benzer kitle (lookalike) üretimi, kampanya optimizasyonu veya offline satış eşleştirmesi gibi. Upload işlemlerinde veri şifreleme/hashed aktarım, retention politikaları ve erişim kontrollerinin işletilmesi gereklidir.

Offline conversions (ör. mağaza satışları veya çağrı merkezinden gelen dönüşümler) sunucu tarafı beslemelerle Google Ads ve Meta’ya yansıtılabilir. Bu tür entegrasyonlar, çevrimdışı etkinliklerin online kampanyalarla ilişkilendirilmesini sağlar ve kampanya ölçümlemesinde bütüncül bir görünüm sunar.

Gizlilik uyumu yalnız teknik çözümlerle sınırlı değildir; süreçsel uygulamalar da gerektirir. İzin (consent) akışının başlangıcından verinin kullanımına kadar kayıt tutulmalı; hangi event’in hangi koşulda gönderileceği açıkça tanımlanmalıdır. Consent yönetimi, hem client hem de server tarafı akışlarda tutarlı olmalıdır.

Veri saklama politikaları, erişim yetkilendirmeleri ve hashing/encryption uygulamaları operasyonel olarak hayata geçirilmelidir. Ayrıca GDPR, KVKK ve platformların kendi politikaları hakkında hukuki değerlendirmeler yapılarak veri kullanım politikaları güncel tutulmalıdır. Teknik ekiplerin bu gereksinimleri nasıl uygulayacağı açık ve test edilebilir olmalıdır.

Pratikte izin verisi server‑side’da merkezi olarak saklanıp, collector endpoint’lerin her istekte bu izin durumunu kontrol etmesi yaygın bir yaklaşımdır. Bu sayede yanlışlıkla izin dışı veri gönderimi riski azaltılabilir.

Birinci parti veri mimarisi canlıya alındıktan sonra düzenli audit, test ve monitoring süreçleri gereklidir. Test senaryoları, smoke test'ler ve regresyon testleri ile event akışlarının beklenen biçimde çalıştığını doğrulayın. Testler hem dev/staging hem de production öncesi ortamlarında otomatik veya yarı‑otomatik şekilde yürütülmelidir.

Otomatik uyarılar ve dashboardlar kurun: event kayıpları, eşleme oranları, API hata oranları ve latency gibi göstergeler izlenmelidir. Bu göstergeler reklam performansındaki düşüşleri erken tespit etmeye ve gerekli düzeltmeleri hızlıca uygulamaya yardımcı olur.

Ayrıca periyodik auditler ile event isimlendirme standardı, veri şeması uyumu ve consent uygulamalarının doğruluğu kontrol edilmelidir. Operasyonel sorumluluklar (owner’lar) ve eskalasyon yolları net olarak belirlenmelidir.

Basit bir uygulama akışı şu şekilde olabilir: kullanıcı alışverişi → client data layer push → server collector endpoint (validation & enrich) → Google Ads Conversion API ve Meta Conversions API’ya gönderim → audience builder’da segment oluşturma → kampanyalarda kullanma. Her adımda logging, retry mekanizmaları ve hata sınıflandırması bulunmalıdır.

Kısa kontrol listesi (örnek): 1) Event tanımları dokümante edildi mi? 2) Data layer schema testleri yapıldı mı? 3) Server collector endpoint doğrulandı mı? 4) API gönderimleri staging ortamında test edildi mi? 5) Consent koşulları uygulandı mı? 6) Monitoring ve alertler aktif mi? Bu maddeler operasyonel geçiş için asgari bir başlangıç sağlar.

Son olarak, ekipler arası iletişim ve merkezi dokümantasyonun sürekliliği sağlanmalıdır: event şemaları, mapping tabloları, test raporları ve izin politikaları güncel tutulmalı; değişiklikler küçük adımlarla, test edilerek uygulanmalıdır.