Toplama araçları ham export'ta durur. Analitik veriyi test edilmiş dönüşümlere ve aktivasyona hazır çıktılara çeviriyor, hangi çıktının hangi kaynağa dayandığını ve hangi ekibin bu çıktıdan sorumlu olduğunu açıkça kaydediyoruz.

Birlikte çalıştığımız 500'den fazla markadan birkaçı

Tüm referansları gör
  • Amazon
  • Mini
  • Aydem Perakende
  • Yandex
  • Sompo Sigorta
  • Pozitif Live
  • GS Store

Veri toplama araçlarında duruyor ama join'lerin, türetilmiş alanların, testlerin, downstream modellerin ve aktivasyon çıktılarının kalıcı sorumlusu ya da açık kaynak izi yoksa bu alanı ele alıyoruz.

Export ve veri toplama araçları GA4 alanında kalıyor. Kalıcı dönüşümleri ve downstream modelleri Analytics Engineering ekibi ele alıyor.

Kalıcı dönüşümleri, testleri ve sorumluları başlangıçta belirliyoruz. Kontroller yeniden çalışıyor, kaynakla çıktı arasındaki ilişki görünür kalıyor ve ekibiniz modeli sürdürebileceği bir kayıt alıyor.

Ham analitik veri akışlarını iş analizine hazır, versiyon kontrollü yapılı veri modellerine dönüştürüyoruz. Zeo uzmanları dbt modelleri, otomatik veri kalitesi testleri ve BigQuery şemaları hazırlarken; veri ekibiniz iş mantığı tanımlarını ve veri ambarı erişimlerini yönetir.

Ham kayıtlardan veri ambarı modellerine uzanan disiplinli bir veri hattı geliştirme süreci.
  1. Ham veriyi modelle

    Ham GA4 BigQuery tablo dışa aktarımlarını temizler, ayrıştırır ve ilişkisel veya boyutlu veri modelleri halinde yapılandırırız.
  2. Dönüşüm hatlarını kur

    Tekrarlayan oturumlaştırma, attribution ve kullanıcı metrikleri için modüler, versiyon kontrollü dbt modelleri ve SQL kodları yazarız.
  3. Veri testlerini uygula

    Birincil anahtar benzersizliği, null değer kontrolleri ve sapma limitleri için otomatik veri kalitesi doğrulama testleri kurarız.
  4. Veriyi aktifleştir

    Modellenmiş ambar tablolarını BI araçlarına, reverse-ETL entegrasyonlarına ve pazarlama otomasyon platformlarına bağlarız.

Bir müşterimiz, işe başlarken karşılaştığımız planlama ve raporlama sorunlarını anlatıyor.

Dr. Kadir Kırmızı
Turna

Zeo ile çalışmadan önce özellikle planlama ve ölçümleme konularında önemli sıkıntılarımız vardı. Bizim için verilerin bilimsel kurallara uygun şekilde doğru olarak değerlendirilebilmesi en önemli konuydu.

Dr. Kadir Kırmızı - General Manager

Veri toplama, etiketleme, ürün analitiği ve raporlama ayrı problemler ve ayrı araçlar demek. Ölçümlemeyi üzerine kurduğumuz araçlar bunlar.

Web analitiği platformları

  • Google AnalyticsBu hizmetin adlandırdığı ham analitik veriyi modelleme adımı özellikle GA4 export'undan başlıyor ve onu nihai hedef değil, bir CDP'nin ya da dönüşüm hattının zenginleştirdiği girdi olarak ele alıyor. Bu çerçeve, bu sayfayı bir GA4 yapılandırma sayfasından ayıran şey: burada GA4 yukarı akışta, CDP ve pipeline işi ise onun aşağısında kalıyor.

Etiket yönetimi, CDP ve server-side tracking

  • Twilio SegmentMüşteri zaten geniş bir yaygın pazarlama ve ürün aracı yelpazesi kullanıyorsa toplamayı önce Segment üzerinden yönlendiriyoruz, çünkü hedef katalogu özel connector işine gerek kalmadan bu listenin çoğunu kapsıyor. Bu genişlik, onu son derece özel ya da veri ambarı öncelikli bir kurulumda tercih ettiğimiz araç yerine varsayılan başlangıç noktası yapan şey.
  • RudderStackMüşterinin veri yönetişim politikası, veri ambarının tek doğruluk kaynağı olarak kalmasını gerektiriyorsa toplamayı Segment yerine RudderStack üzerine kuruyoruz, çünkü event'leri önce sağlayıcı tarafında tutmak yerine doğrudan o ambara yazıyor. Bu mimari tercih, Segment'in modelinin karşılamadığı bir veri konumlandırma gerekliliğini karşılıyor.
  • SnowplowMüşterinin sıkı event şema zorlaması ihtiyacı varsa, yani her event kabul edilmeden önce tanımlı bir kurala göre kontrol edilmeli, toplamayı her şeyi kabul edip sonradan temizleyen bir CDP yerine Snowplow üzerine kuruyoruz. Bu girişte doğrulama davranışı, bozuk bir event'in dönüşüm hattına hiç ulaşmamasını sağlıyor.
  • mParticleMüşterinin ana toplama yüzeyi web değil de native bir mobil uygulamaysa toplamayı mParticle üzerinden yönlendiriyoruz, çünkü kimlik çözümlemesi ve SDK yönlendirmesi web öncelikli bir üründen uyarlanmak yerine baştan mobil öncelikli tasarlanmış. Bu uygulama-öncelikli temel, event'lerin çoğu hiç bir browser'a değmediğinde kimlik eşleştirmesini güvenilir tutan şey.
  • TealiumMüşteri etiket yönetimi ile CDP tipi hedef kitle oluşturmayı, ayrı bir CDP'yi GTM'e eklemek yerine tek platformda istiyorsa Tealium üzerine kuruyoruz, çünkü AudienceStream doğrudan kendi toplama katmanının üzerinde çalışıyor. Bu tek sağlayıcılı eşleşme, birlikte tasarlanmamış bir CDP'yi bir etiket yöneticisine bağlamanın getirdiği ek entegrasyon işini ortadan kaldırıyor.
  • Treasure DataYalnızca event yönlendirmesi değil, birçok kaynak sistemden derlenmiş tam customer-360 profillerine ihtiyaç duyan kurumsal bir müşteri için aktivasyon katmanını Treasure Data üzerine kuruyoruz, çünkü profil birleştirmesi ve segmentasyonu bu ölçekteki kimlik çözümlemesi için tasarlanmış. Bu, gruptaki yönlendirme odaklı CDP'lerden daha ağır bir iş, yalnızca birleştirme sorunu gerçekten asıl mesele olduğunda seçiyoruz.
  • AmperityAktivasyon sorunu aslında bir kimlik sorunuysa, yani aynı kişi müşterinin sistemlerinde birkaç farklı kayıt olarak görünüyorsa çözümleme katmanını Amperity üzerine kuruyoruz, çünkü tekilleştirme ve kimlik eşleştirme daha geniş bir CDP'ye eklenmiş bir özellik değil, onun asıl odağı. Eşleştirme, yönlendirme değil, asıl zor kısım olduğunda genel amaçlı bir CDP yerine bu uzmanlaşmayı tercih ediyoruz.
  • Salesforce Data CloudSatış ve pazarlama ekipleri zaten Salesforce içinde çalışan bir müşteri için birleştirilmiş veriyi doğrudan Salesforce Data Cloud üzerinden aktive ediyoruz, çünkü bu ekiplerin zaten her gün kullandığı CRM ve Marketing Cloud nesnelerine geri yazıyor, ayrıca öğrenmeleri gereken ayrı bir hedef değil. Bu doğal uyum, kendi Salesforce connector'ı kurulup sürdürülmesi gereken bir CDP'ye kıyasla belirleyici faktör.

BI, dashboard ve raporlama

  • Looker StudioDownstream'i aktive et adımı test edilmiş, zenginleştirilmiş veriyi teslim ettikten sonra bunu paydaş raporlaması için Looker Studio'da görünür kılıyoruz. Bir dashboard'u ham toplama yerine bu pipeline'ın çıktısından beslemek, her hareket ettiğinde yeniden açıklanması gereken bir sayı yerine tutarlı, zaten doğrulanmış bir sayı göstermesini sağlıyor.
Veri altyapınızı ve takip ihtiyaçlarınızı paylaşın. Sağlıklı veri toplayan ve karar almayı kolaylaştıran bir raporlama mimarisi tasarlayalım.
Projenizi anlatın