ETL ve veri yönetimi: ham veriden güvenilir tabloya.

Veri yönetimi ve ETL, panolardan önce gelen ve genellikle atlanan katman. Reklam platformları, site analitiği, e-ticaret altyapısı ve CRM verisinin düzenli olarak tek bir yerde toplanması olmadan, birleşik raporlama da güvenilir karar da mümkün değil.

Bu sayfada veriyi nereden nereye taşıdığımızı, platform arayüzlerinin bilinmesi gereken taraflarını, taşıma sırasında en sık hangi sorunların çıktığını ve altyapıyı hangi katmanlarda kurduğumuzu anlattık. Tüm pazarlama hizmetlerimiz için ana sayfaya, veri tarafının bütününü görmek için veri ve analitik çözümleri sayfasına bakabilir, ücretsiz performans analizi ile başlayabilirsiniz.

ETL ne demek, neden gerekiyor

ETL, verinin kaynaktan çıkarılması, kullanılabilir hale getirilmesi ve bir hedefe yüklenmesi anlamına geliyor. Pazarlama tarafında pratik karşılığı şu: her platformun kendi paneline tek tek girip rakam kopyalamak yerine, tüm verinin otomatik olarak tek bir yerde toplanması.

Bunun gerekli olmasının sebebi, platformların birbirine benzemeyen veri yapıları. Aynı kavram her yerde farklı isimle, farklı zaman diliminde ve farklı para biriminde geliyor. Bu farklar ortadan kaldırılmadan iki platformun rakamını yan yana koymak, elma ile armut toplamak oluyor.

İkinci sebep kalıcılık. Reklam platformlarının çoğu geçmiş veriyi sınırlı süre saklıyor ya da belirli bir tarihten öncesine erişimi kısıtlıyor. Veri düzenli olarak kendi ambarınıza akmadığında, bir yıl sonra geçmiş dönem karşılaştırması yapma imkânınız kalmıyor.

Hangi kaynakları bağlıyoruz

Reklam platformları. Google Ads, Meta, TikTok, LinkedIn, Apple Search Ads ve programatik platformlar. Kampanya, reklam grubu ve kreatif seviyesinde harcama, gösterim, tıklama ve dönüşüm verisi.

Site analitiği. Oturum, kanal, sayfa ve dönüşüm verisi. Ham veri aktarımı mümkün olduğunda arayüzdeki örneklenmiş rapor yerine ham veri kullanılıyor.

E-ticaret altyapısı. Sipariş, ürün, stok ve iade verisi. Reklam tarafındaki iddiaların doğrulanacağı asıl kaynak burası.

Ürün feed’leri. Alışveriş ve katalog kampanyalarının beslendiği veri. Feed sağlığının izlenmesi, sessiz performans kaybının önlenmesi için gerekli.

CRM. Uzun satış döngüsü olan işlerde, formun ne olduğu değil görüşmenin nasıl sonuçlandığı önemli. Bu bilgi geri beslenmeden B2B ölçümü kurulmuş sayılmıyor.

Arama konsolu. Organik tarafın kelime bazlı gösterim, tıklama ve sıra verisi.

Taşıma sırasında çıkan sorunlar

Para birimi karışması. Farklı pazarlarda farklı para biriminde gelen harcama ve ciro verisinin, dönüşüm yapılmadan toplanması. Rakam makul göründüğü için fark edilmesi zor; toplam sessizce yanlış çıkıyor.

Zaman dilimi kayması. Her platformun kendi zaman dilimi var. Gün sınırları hizalanmadan yapılan günlük karşılaştırmalar, özellikle gece yoğunluğu olan işlerde belirgin sapma üretiyor. Hafta bucketlarının yanlış hesaplanması da aynı sınıftan bir hata.

Geriye dönük güncelleme. Platformlar dönüşüm verisini birkaç gün sonra güncelleyebiliyor. Veriyi bir kez çekip bir daha dokunmamak, geçmiş günlerin eksik kalmasına yol açıyor. Belirli bir pencereyi düzenli olarak yeniden çekmek gerekiyor.

Kimlik uyuşmazlığı. Aynı kampanyanın farklı sistemlerde farklı isimle geçmesi. İsimlendirme standardı olmadan, kampanya bazlı birleştirme elle eşleştirmeye dönüşüyor.

Mükerrer kayıt. Eşzamanlı çalışan iki çekim işinin aynı veriyi iki kez yazması. Yazma işleminin çakışmaya karşı korunması gerekiyor.

Sessiz kesinti. Bir bağlantının yetki süresi dolduğunda veri akışı durur ama tablo boşalmaz; sadece güncellenmeyi bırakır. Rakamlar makul görünmeye devam ettiği için bu, en geç fark edilen arıza türü. Bu yüzden tazelik kontrolü kuruyoruz.

Platform arayüzlerinin bilinmesi gerekenleri

Reklam platformlarından veri çekmek, göründüğü kadar basit bir iş değil. Her platformun kendine özgü davranışları var ve bunlar bilinmediğinde altyapı bir gün sessizce durmuş oluyor.

Sürüm emekliliği. Platformlar veri arayüzlerinin eski sürümlerini belirli takvimlerle kullanımdan kaldırıyor. Kullandığınız sürüm emekli olduğunda, çağrılar ya hata veriyor ya da sessizce en yakın desteklenen sürüme yönlendiriliyor. İkincisi daha tehlikeli: veri gelmeye devam ediyor ama alan yapısı ve bazı metriklerin tanımı değişmiş oluyor. Bu yüzden sürüm takvimlerini izliyor ve yükseltmeyi son tarihe bırakmıyoruz.

Kota ve hız sınırları. Her platformun günlük çağrı ve eşzamanlı istek sınırı var. Sınır aşıldığında bazı platformlar hata döndürüyor, bazıları ise eksik veri döndürüyor. Eksik veri dönen durumlarda hiçbir alarm çalmıyor; çekim başarılı görünüyor ama satırların bir kısmı gelmiyor. Çekim işlerini sıraya alıyor, paralel çalıştırmaktan kaçınıyoruz.

Ağır sorguların asenkron çalışması. Uzun tarih aralığı ve çok sayıda kırılım içeren raporlar, anlık cevap yerine bir iş kuyruğuna alınıyor. Sonucun hazır olması beklenmeden okunduğunda boş ya da kısmi veri geliyor. İşin tamamlandığını doğrulamadan sonucu yazmıyoruz.

Atıf penceresi parametreleri. Aynı kampanya için farklı atıf penceresiyle çekim yapıldığında farklı rakamlar geliyor. Hangi pencerenin kullanıldığı yazılı değilse, altı ay sonra rakamların neden değiştiği bilinemiyor. Pencere ayarını çekim yapılandırmasının parçası olarak belgeliyoruz.

Yetki süreleri. Bağlantı yetkileri süreli ve yenilenmediğinde akış duruyor. Sona erme tarihi olmayan ya da izlenmeyen yetkiler, en sık karşılaştığımız sessiz kesinti sebebi. Yetki sağlığını da tazelik kontrollerine dahil ediyoruz.

Kırılım sınırları. Bazı platformlar belirli metrikleri belirli kırılımlarla birlikte döndürmüyor. Uyumsuz bir metrik ve kırılım birlikte istendiğinde, hata yerine sıfır dönebiliyor. Sıfır gelen bir satırın gerçekten sıfır mı yoksa uyumsuzluk mu olduğunu ayırt etmek, çekim tasarımının bir parçası.

Birleştirme anahtarları

Verinin taşınması işin kolay kısmı. Zor kısım, farklı sistemlerden gelen kayıtların birbirine hangi alan üzerinden bağlanacağı. Anahtar tanımlanmadan yapılan birleştirme, elle eşleştirmeye dönüşüyor ve her ay yeniden yapılıyor.

Kampanya isimlendirme standardı. En yüksek getirili ve en az sevilen iş. Kampanya adının içine kanal, ülke, huni aşaması, kategori ve dönem bilgisinin sabit bir kalıpla yazılması, sonraki tüm raporlamayı mümkün kılıyor. Standart yoksa, “hangi kampanyalar üst huni” sorusunun cevabı her ay elle çıkarılıyor. Standardı geçmişe dönük uygulamak mümkün olmadığı için, kurulumun en başında karara bağlıyoruz.

Ürün kimliği. E-ticaret altyapısındaki ürün kodu ile feed’deki kimlik ile reklam platformundaki ürün kimliğinin aynı olması gerekiyor. Varyantlı ürünlerde ana ürün ile varyant kimliğinin hangisinin kullanıldığı da netleşmeli. Bu eşleşme bozukken, ürün bazlı reklam performansı ile gerçek satış verisi birbirine bağlanamıyor. Feed tarafındaki ayrıntılar: Merchant Center ürün feed’i.

Kampanya parametreleri. Reklamdan siteye gelen adreslerdeki kaynak, ortam ve kampanya alanlarının tüm platformlarda aynı kurala göre doldurulması. Küçük harf ve büyük harf farkı bile iki ayrı kanal satırı üretiyor; bu yüzden yazımı normalleştiren bir katman kuruyoruz.

Sipariş kimliği. Analitikteki işlem kimliği ile sipariş sistemindeki numaranın aynı olması, iki kaynağın karşılaştırılmasını mümkün kılıyor. Farklı olduğunda, çapraz doğrulama yapmanın yolu kalmıyor.

Müşteri kimliği. Tekrar satın alma ve kohort analizi için gerekli. Kişisel veri içermeyen, geri çözülemez bir değer kullanıyoruz.

Tarih anahtarı. Her satırın hangi güne ait olduğu, tek bir zaman dilimine hizalanmış olarak. Platformların kendi gün tanımları farklı olduğu için bu dönüşüm standart katmanda yapılıyor.

Nasıl kuruyoruz

Kaynak envanteri. Hangi veri nerede duruyor, kimin erişimi var, hangi formatta geliyor. Bu liste çıkarılmadan yapılan kurulum, ilerleyen aşamada eksik kaynakla yeniden yapılıyor.

Ambar kurulumu. Veri ambarı markanın kendi hesabında kuruluyor. Erişimi siz yönetiyorsunuz, çalışma bittiğinde veri sizde kalıyor.

Çekim işleri. Her kaynak için düzenli çalışan işler. Sıklık, verinin değişme hızına göre belirleniyor; her şeyi saatlik çekmek gereksiz maliyet üretiyor.

Standartlaştırma. Para birimi, zaman dilimi, kampanya isimlendirmesi ve metrik tanımları tek bir modelde hizalanıyor. Bu adım, birleşik raporlamayı mümkün kılan asıl iş.

Kalite kontrolleri. Tazelik, satır sayısı, beklenmedik boş değerler ve toplamların kaynakla karşılaştırılması. Kontroller otomatik çalışıyor ve sapma olduğunda uyarı üretiyor.

Dokümantasyon. Hangi tablonun nereden geldiği ve nasıl hesaplandığı yazılı. Bu belge olmadan altyapının bakımı, onu kuran kişiye bağımlı hale geliyor.

Veri kalitesini nasıl izliyoruz

Kurulumun bittiği an, işin bittiği an değil. Kaynak sistemler değişiyor: platformlar arayüz sürümlerini emekliye ayırıyor, e-ticaret altyapısı alan ekliyor, biri bir kampanya isimlendirmesini değiştiriyor. Bu değişiklikler haber verilmeden geliyor.

Bu yüzden veri kalitesini sürekli izliyoruz. Tazelik: her tablonun en son ne zaman güncellendiği. Hacim: günlük satır sayısının normal aralıkta olup olmadığı. Tutarlılık: ambardaki toplamın kaynak paneldeki rakamla karşılaştırılması. Şema değişikliği: beklenmedik yeni ya da kaybolan alanlar.

Bu kontroller, sessiz kesintileri günler içinde yakalıyor. Kontrol kurulmamış altyapılarda aynı sorun genellikle aylar sonra, birisi rakamların tuhaf olduğunu fark ettiğinde ortaya çıkıyor ve o zamana kadarki tüm kararlar eksik veriyle verilmiş oluyor.

İş akışı ve hata yönetimi

Onlarca kaynaktan günde birkaç kez veri çeken bir altyapıda, işlerin bir kısmı er ya da geç başarısız olacak. Önemli olan hata olmaması değil, hatanın fark edilmesi ve tekrarlandığında veriyi bozmaması.

Tekrar çalıştırılabilirlik. Her çekim işi, aynı gün için ikinci kez çalıştırıldığında veriyi ikiye katlamamalı. Bunu, yazma işlemini eklemeli değil değiştirmeli yaparak sağlıyoruz. Bu tasarım kararı alınmadığında, başarısız bir işin elle yeniden çalıştırılması mükerrer kayıt üretiyor ve bu, en sık karşılaştığımız veri bozulması sebebi.

Sıralı bağımlılıklar. Bazı tablolar diğerlerine bağlı. Kaynak henüz güncellenmemişken türetilmiş tabloyu hesaplamak, eski veriden yeni rapor üretmek demek. İşleri bağımlılık sırasına göre çalıştırıyor, önceki adım tamamlanmadan sonrakini başlatmıyoruz.

Kısmi başarısızlık. Beş kaynaktan biri gelmediğinde ne olacağı önceden kararlaştırılıyor. Çoğu durumda doğru davranış, eksik kaynağı işaretleyip diğerlerini işlemek ve panoda o kaynağın güncel olmadığını göstermek. Sessizce eksik veriyle rapor üretmek en kötü seçenek.

Yeniden deneme. Geçici ağ hataları ve kota aşımları için sınırlı sayıda otomatik yeniden deneme. Sınırsız deneme, kota sorununu büyütmekten başka işe yaramıyor.

Uyarıların anlamlı olması. Her başarısız iş için bildirim göndermek, bildirimlerin okunmamasına yol açıyor. Uyarıları, verinin gerçekten eskidiği durumlarda üretiyoruz; bir işin başarısız olup yeniden denemede başarılı olması uyarı üretmiyor.

Değişikliklerin kaydı. Bir dönüşüm mantığı değiştiğinde, ne zaman ve neden değiştiği kayıt altında. Aylar sonra “bu rakam neden değişti” sorusunun cevabı ancak bu kayıtla verilebiliyor.

Veri modeli: ham veriden kullanılabilir tabloya

Veriyi taşımak işin yarısı. Asıl değer, farklı kaynaklardan gelen verinin ortak bir modelde birleştirilmesinde.

Ham katman. Kaynaktan geldiği haliyle saklanan veri. Hiçbir dönüşüm uygulanmıyor. Bu katmanın varlığı, ilerideki bir tanım değişikliğinde geçmişi yeniden hesaplayabilmeyi sağlıyor. Dönüştürülmüş veriyi saklayıp hamı atmak, geri dönüşü olmayan bir karar.

Standart katman. Para birimi, zaman dilimi, tarih formatı ve isimlendirmenin hizalandığı yer. Her kaynağın kendi alan isimleri ortak bir sözlüğe çevriliyor.

İş katmanı. Kanal performansı, kampanya özeti, ürün bazlı ciro gibi doğrudan raporlamaya giren tablolar. Metrik tanımları burada tek bir yerde hesaplanıyor; her pano kendi hesabını yapmıyor.

Bu üç katmanlı yapı, ilk bakışta gereksiz karmaşık görünüyor ama bakım maliyetini belirgin şekilde düşürüyor. Tek katmanlı kurulumlarda bir tanım değişikliği, tüm raporların tek tek elden geçirilmesini gerektiriyor.

Kişisel veri ve saklama

Pazarlama verisi, kişisel veri içeren alanlarla iç içe geçiyor. Altyapı kurulurken bu tarafın baştan tanımlanması, sonradan düzeltmekten çok daha ucuz.

Veri minimizasyonu. Ambara alınan her alanın bir amacı olmalı. E-posta, telefon ve adres bilgisi, raporlama için gerekli olmadığı sürece taşınmıyor. “İleride lazım olur” gerekçesiyle çekilen alanlar, hem gereksiz risk hem gereksiz maliyet üretiyor.

Maskeleme ve karma. Müşteri bazlı analiz gerektiğinde kimlik olarak düz e-posta değil, geri çözülemez bir değer kullanılıyor. Bu, kohort ve tekrar satın alma analizini mümkün kılarken kişiyi tanımlamayı gereksiz hale getiriyor.

Saklama süreleri. Ham katmanın süresiz saklanması gerekmiyor. Kişisel veri içeren alanlar için saklama süresi tanımlanıyor ve süre dolduğunda otomatik siliniyor. Bu kuralın kodda yaşaması, bir belgede yaşamasından daha güvenilir.

Erişim yetkileri. Ambardaki her tabloya herkesin erişmesi gerekmiyor. Maliyet, marj ve müşteri bazlı tabloları ayrı yetki altında tutuyoruz.

Silme talepleri. Bir kullanıcı verisinin silinmesi talep edildiğinde, verinin ambardaki karşılığının da silinebilir olması gerekiyor. Bu, kimlik alanının en baştan izlenebilir kurulmasına bağlı; sonradan eklenmesi çok zor bir gereksinim.

Dış servislere aktarım. Verinin analiz ya da modelleme için üçüncü bir servise gönderilmesi ayrı bir karar. Kişisel veri içeren alanların bu aktarımdan önce ayıklanması standart uygulamamız.

Reklam platformlarına geri gönderim. Müşteri listelerinin ve çevrim dışı dönüşümlerin platformlara yüklenmesi de bir aktarım. Platformlar bu veriyi karma biçimde istiyor; gönderimin bu kurala uygun yapılması ve hangi listenin ne zaman yüklendiğinin kayıt altında tutulması gerekiyor.

Maliyet ve sıklık dengesi

Veri ambarı maliyeti iki yerden geliyor: saklama ve sorgulama. İkisinin de kontrol altında tutulması gereken bir tarafı var.

Çekim sıklığı. Her kaynağı saatlik çekmek gereksiz maliyet üretiyor. Harcama verisi günlük yeterliyken, sipariş verisi saatlik anlamlı olabiliyor. Sıklığı verinin değişme hızına ve alınacak kararın aciliyetine göre belirliyoruz.

Geriye dönük pencere. Platformlar dönüşüm verisini sonradan güncellediği için son birkaç günün yeniden çekilmesi gerekiyor. Bu pencerenin gereğinden geniş tutulması, her gün aynı veriyi defalarca işlemek anlamına geliyor.

Bölümleme. Tabloların tarihe göre bölümlenmesi, sorguların yalnızca ilgili aralığı taramasını sağlıyor. Bu tek başına sorgulama maliyetinin büyük kısmını düşürüyor.

Saklama süresi. Ham katmanın süresiz saklanması gerekmiyor. Kişisel veri içeren alanlar için yasal saklama sınırları da bu kararın parçası.

Sık sorulan sorular

Küçük bir markayım, veri ambarına ihtiyacım var mı?

Tek kanalda ve düşük hacimde çalışıyorsanız platform panelleri yeterli olabilir. İhtiyaç, kanal sayısı arttığında ve platformların birbiriyle çelişen rakamları karar almayı zorlaştırdığında doğuyor. Karar noktası büyüklük değil, çelişki.

Verilerimiz nerede tutuluyor, güvenli mi?

Ambar markanın kendi bulut hesabında kuruluyor. Erişim yetkileri sizde, biz yalnızca çalışma süresince yetkilendiriliyoruz. Kişisel veri içeren alanlar için gerekli maskeleme ve saklama süresi kuralları kurulum aşamasında tanımlanıyor.

Kurulum ne kadar sürer?

Temel reklam kaynaklarının bağlanması ve standartlaştırılması birkaç hafta. CRM ve özel e-ticaret altyapıları gibi kaynaklar bunun üzerine ekleniyor. Süreyi uzatan şey genellikle teknik zorluk değil, kaynak sistemlere erişim yetkilerinin alınması.

Mevcut kurulumumuz var, devralabilir misiniz?

Evet. Önce mevcut yapının denetimini yapıyoruz: hangi kaynaklar bağlı, veri ne kadar güncel, tanımlar tutarlı mı. Çalışan kısımlar korunuyor. Sıfırdan kurmak yerine eksikleri kapatmak çoğu durumda hem hızlı hem ucuz.

Bakım gerektiriyor mu?

Evet, ve bu genellikle küçümseniyor. Kaynak sistemler haber vermeden değişiyor; bağlantı yetkileri süre doluyor, alanlar ekleniyor, arayüz sürümleri emekliye ayrılıyor. Otomatik kalite kontrolleri bu değişiklikleri erken yakalamak için var.

Panolar da bu kapsamda mı?

Hayır, ayrı bir başlık. Bu sayfa verinin toplanması ve düzenlenmesiyle ilgili; toplanan verinin karar alınabilir hale getirilmesi iş zekâsı tarafında. Site ve reklam tarafındaki ölçümün doğru kurulması ise ileri analitik başlığı altında.

Hazır bir veri aktarım aracı kullansak olmaz mı?

Bazı kaynaklar için oluyor ve gereksiz yere kendi kodumuzu yazmıyoruz. Hazır araçlar standart reklam platformları için hızlı bir başlangıç sağlıyor. Sınırları iki yerde ortaya çıkıyor: birincisi, aracın sunduğu alan seti ihtiyacınızı karşılamadığında (özellikle özel dönüşüm tanımları ve kırılımlar), ikincisi kaynak standart olmadığında (kendi geliştirdiğiniz e-ticaret altyapısı, özel CRM, pazaryeri panelleri). Bir de maliyet tarafı var: satır bazlı ücretlendirilen araçlarda, yüksek hacimli olay verisi beklenmedik bir kaleme dönüşebiliyor. Karma bir yaklaşım kullanıyoruz: standart kaynaklarda hazır araç, özel kaynaklarda kendi işlerimiz.

Pazaryeri ve bayi verisini de bağlayabiliyor musunuz?

Erişim sağlandığında evet. Pazaryerlerinin sunduğu veri arayüzleri, reklam platformlarına göre daha sınırlı ve tarih aralığı kısıtlı olabiliyor; bu yüzden veriyi düzenli çekip kendi ambarınızda biriktirmek burada daha da kritik hale geliyor. Bayi ağlarında ise veri genellikle tek bir sistemde durmuyor; bu durumda ortak bir raporlama formatı tanımlayıp bayilerden gelen veriyi bu formata çeviren bir katman kuruyoruz. Formatın kendisinin basit tutulması, veriyi gönderen tarafın uyum sağlamasını kolaylaştırıyor.

Altyapıyı kendi ekibimize devredebilir miyiz?

Evet, kurulumu bu ihtimali gözeterek yapıyoruz. Altyapı markanın kendi bulut hesabında duruyor, dönüşüm mantığı ve tablo tanımları belgelenmiş halde bulunuyor. Devir sırasında bir oturum yapıp mimariyi ve bakım noktalarını geçiyoruz. Devir sonrası dikkat edilmesi gereken tek şey, platform sürüm takvimlerinin izlenmesi; bu iş takip edilmediğinde altyapı bir gün sessizce eksik veri toplamaya başlıyor. Reklam tarafındaki karşılıkları Google Ads ve Meta Ads sayfalarında.

Ücretsiz performans analizi talep edin