MarTech yığını mimarisi: Üç temel karar

Önümüzdeki çeyrekte MarTech yığını için sözleşme imzalayacaksanız bu yazıdaki üç karar masanızda olsun. Pazarlama teknolojisi yığınınızı kurarken aldığınız her karar gelecek 3-5 yıla kayıyor. Yanlış erken seçim daha sonra bir migrasyona, bir borç temizliğine ya da karar erteleme alışkanlığına dönüşüyor. Yeni bir araç ekledikten sonra çıkarmak nadirdir; arkasında veri akışı, otomasyon, atıf modeli ve ekip refleksleri birikir. Bu yüzden ilk altı ay seçilen üç-dört temel kararın bedeli orantısız ağırdır.

Son 18 ayda 12 müşteri ile çalışırken aynı üç soruyu defalarca sorduk: ortak veri katmanı kim olacak, otomasyonu kim koşturacak ve gerçek zamanlı kişiselleştirmeye ne zaman geçilecek? Çoğu ekip bu üç soruyu da farklı zamanlarda, farklı tedarikçi sunumları altında ve birbirinden bağımsız kararlaştırıyor. Sonuç, üst üste binen modüller, çift faturalanan özellikler ve hangi sistemin “gerçek” cevap verdiğini kimsenin hatırlayamadığı bir yığın. Bu yazıda kararların hangi sırayla alınması gerektiğini ve her birinde hangi koşulların hangi seçimi savunulabilir kıldığını paylaşıyoruz. Amaç sizin yerinize karar vermek değil; aynı kareleri açıkça önünüze koyup, kendi bağlamınıza göre seçimlerinizi savunulabilir kılmak. Yazı boyunca somut araçlardan bahsediyoruz çünkü “platform-bağımsız” karar matrisleri kâğıtta iyi durur, üretim ortamında işe yaramaz; ekibinizin bir hafta sonra hangi sözleşmeyi imzalayacağına karar vermesi lazım.

Karar 1: Ortak veri katmanı — CDP, warehouse ya da hibrit mi?

Müşteri verisinin “ev sahibi” olmadan hiçbir martech yığını uzun ömürlü olmuyor. Soru üç seçenekte daralıyor: Customer Data Platform (CDP), data warehouse + reverse-ETL ya da ikisinin hibridi. Karar, “veriyi kim toplayıp kim aktive edecek” sorusu ile netleşir; çünkü iki rol farklı maliyet ve farklı ekip kapasitesi gerektirir.

CDP kazandığı durum. Segment, mParticle ya da RudderStack gibi bir CDP gerçek zamanlı aktivasyon ihtiyacı yüksekse iyi seçim olur. Identity resolution, destination yönetimi, server-side hat ve consent katmanı kutudan çıkıyor. Mühendislik ekibi küçükse ya da pazarlama ekibi haftalık bağımsız hareket etmek istiyorsa CDP, kurulum maliyetini geri ödüyor. Karşılığında: tedarikçi kilidi, MTU bazlı fiyat eğrisi ve gerçekten “tek source of truth” olamayan bir profil.

Warehouse kazandığı durum. BigQuery ya da Snowflake üzerine kurulu dbt ile modellenmiş bir veri katmanı, üzerinde Hightouch ya da Census gibi reverse-ETL araçları, son yıllarda en çok tercih ettiğimiz mimari oldu. Tek source of truth gerçekten warehouse oluyor; analitik ve aktivasyon aynı tablo üzerinden konuşuyor; uzun vadede maliyet eğrisi CDP’nin üstüne çıkmıyor. Karşılığında: warehouse + dbt + reverse-ETL setini sürdürecek 1-2 mühendis kapasitesi şart. Daha küçük ölçekte bu ekip hazır değilse warehouse seçimi yarım kalır.

Hibrit kazandığı durum. Düzenleyici sınır (KVKK/GDPR sıkı veri yerelleşmesi), çok bölgeli operasyon ya da CDP’nin kapsamadığı özel kanal entegrasyonları varsa hibrit doğru olur. Tipik şekil: warehouse merkez, CDP yalnızca gerçek zamanlı aktivasyon kanalları için “ince” katman. İki sistemi senkron tutmanın operasyonel maliyeti küçümsenmemeli.

Pratik karar matrisi:

• <50K MAU + 1 ana kanal (e-posta/SMS): Warehouse + reverse-ETL. CDP gerek yok.
• 50K-150K MAU + 3-5 destination + küçük mühendislik: CDP, hızlı yol.
• 150K+ MAU + 6+ destination + mühendislik kapasitesi var: Warehouse + reverse-ETL daha esnek ve ucuz.
• Düzenleyici sınır + çok bölge: Hibrit kaçınılmaz.

Audit çalışmalarımızda en sık gördüğümüz hata, ölçek 50K MAU altındayken Segment kurulması ve aylık faturanın 12 ay sonra warehouse setinden 3-4 katı çıkmasıdır. Tersi de var: 200K MAU’da hâlâ “Google Sheet + Zapier” üzerinde duran ve her kampanyada manuel ihracat yapan ekipler. Karar, ekip büyüklüğüne ve aktivasyon hızına göre verilmeli; tedarikçi sunumuna göre değil.

Karar 2: Otomasyon merkezi — MAP mı, orchestrator mı?

İkinci karar, otomasyonun “merkezi” sorusu. Ya HubSpot, Customer.io ya da Klaviyo gibi bir Marketing Automation Platform (MAP) merkezdedir; ya da n8n, Make ya da Temporal gibi bir orchestrator tüm akışları yönetir. Pek çok ekip bu sorunun cevabını CDP’nin üstüne yıkıyor — ama CDP otomasyon merkezi değil; sadece veriyi taşır.

MAP yeterli olduğu durum. Tek kanal (çoğu zaman e-posta) + basit drip + lifecycle akışları + 1-2 kişilik pazarlama ekibi varsa MAP zaten yeterli. Customer.io ve Klaviyo’nun visual editor’ü pazarlama ekibinin ürün ekibinden bağımsız çalışmasını sağlar. HubSpot CRM tarafıyla beraber kullanılıyorsa bütünleşik tek panel cazip.

Orchestrator gerektiği durum. Üç-dört kanalı koordine ediyorsanız (e-posta + SMS + push + in-app), AI tabanlı dallanma kararı veriyorsanız (LLM ile segment skoru, içerik varyantı seçimi), ya da CRM dışında ERP/ticketing/billing sistemleri ile karşılıklı veri akışı varsa MAP yetmiyor. Burada n8n ya da Make hızlı kurulur, Temporal ise yüksek hacimli ve durumlu (stateful) iş akışları için doğru. Custom kod yazmaya hazır değilseniz n8n + Make ikilisi çoğunlukla yeterli.

“İkisi birden” deseni. Pratikte en çok kullandığımız patern: MAP birincil e-posta motoru olarak kalır, orchestrator arka planda cross-channel mantığı koşturur. Örneğin Customer.io tetiklenir → n8n bir webhook ile push’u, SMS’i ve CRM güncellemesini paralel sıralar; sonuç CRM’e yazılır. MAP’in pazarlama ekibine verdiği bağımsızlık korunur, mühendislik karmaşık dallanmayı orchestrator’da tutar. Bu deseni MarTech operasyonu engagement’larımızda çoğunlukla varsayılan kabul ediyoruz; nasıl uyarladığımızı MarTech ve AI Operasyonları sayfamızda ayrıntılı anlattık.

Sık yapılan hata. CDP’yi otomasyon merkezi gibi kullanmaya çalışmak. Segment “compute” ekledi ama hâlâ orchestrator değil — koşul-zincirli, retry’lı, hatalarda human-in-the-loop onayı isteyen iş akışları için tasarlanmadı. CDP veri taşır, MAP kanal yönetir, orchestrator iş akışını koşturur. Üçü birbirini ikame etmiyor.

MAP seçiminde yan not. HubSpot’u zaten CRM olarak kullanıyorsanız MAP tarafını da HubSpot’ta tutmak panel sayısını azaltıyor; ama davranış-tetikli ve yüksek hacimli e-posta için Customer.io ya da Klaviyo daha esnek. E-ticaret tarafındaki ekiplerimiz çoğunlukla Klaviyo + Shopify ekseninde, B2B SaaS tarafı Customer.io + HubSpot ekseninde duruyor. Tek “doğru” MAP yok; iş modeline göre değişiyor.

Karar 3: Gerçek zamanlı kişiselleştirme — ne zaman bekleyin?

Üçüncü ve en pahalı karar. Gerçek zamanlı kişiselleştirme — anasayfa, ürün listesi, push içeriği, e-posta gövdesi — doğru kurulduğunda dönüşümleri %5-15 yukarı alabiliyor. Ama getiri analizi yapılırken ön koşullar atlanıyor.

Kişiselleştirmeden önce hazır olması gerekenler:

• Temiz event şeması. Frontend ve backend olayları aynı isimlendirme ve aynı property setini kullanıyor mu? Değilse her segment yarım çalışır.
• Segmentasyon olgunluğu. Kişiselleştirme yapılacak segment hâlihazırda standart kampanyalarda performans gösteriyor mu? Yoksa “her şeyi herkese gösteriyoruz” probleminden kişiselleştirmeye atlamak demek.
• İçerik varyant boru hattı. Pazarlama ekibi haftada en az 6-10 varyant üretebiliyor mu? Üretemiyorsa kişiselleştirme motoru aynı 2 varyantı döndürür.
• Ölçüm çerçevesi. Hangi metrik üzerinden değerlendirileceği önceden tanımlı mı? Aksi takdirde uplift yorumu seçilmiş örneğe dönüşür.

Beklenmesi gereken durum. 30K MAU altı, temiz event şeması yok, pazarlama ekibi 1-2 kişi: kişiselleştirme şu an değil. Aynı 3-6 ayı segmentasyon olgunluğuna ve içerik varyant disiplinine yatırmak çok daha yüksek dönüş veriyor. Bu erteleme kararı satış görüşmelerinde kolay değil — tedarikçi demoları her zaman etkileyici uplift örnekleri gösteriyor — ama o demolar ön koşulları çoktan karşılamış müşterilerden alınmış sonuçlar.

Yatırılması gereken durum. Yüksek frekanslı / yüksek LTV bir müşteri tabanı (e-ticaret, SaaS, medya), event şeması temiz, içerik ekibi varyant üretmeye hazır: bu durumda kişiselleştirme motoru 3-6 ay içinde kendini ödüyor.

Server-side mi, client-side mi? Client-side rendering hızlı kurulur ama Core Web Vitals’a yük bindirir; server-side daha temiz performans verir ama altyapı gerektirir. Yüksek trafikli sayfalar (anasayfa, ürün detay) için server-side; e-posta gövdesi, push içeriği gibi server-rendered alanlar için zaten doğru yer. CWV’ye etkiyi nasıl ölçtüğümüzü Core Web Vitals takibi yazımızda anlattık.

Audit çalışmalarımızda gördüğümüz örüntü açık: kişiselleştirme yatırımının %70’i ön koşullar tamamlanmadan başlatıldığı için ilk 12 ayda görünür getiri vermiyor. Sırayı tersine çevirin.

Hepsini bir araya getirmek: 90 günlük karar sırası

Üç kararın birbirine bağımlılığı şu sırayla işliyor:

1. Veri katmanı önce. Çünkü otomasyon ve kişiselleştirme veriyi tüketir. Yanlış katman seçilirse iki üst katman da sallanır. İlk 30-45 gün: warehouse + dbt başlangıcı ya da CDP karar dökümü, kanal entegrasyonu, identity resolution.
2. Otomasyon merkezi sonra. Veri katmanı stabilse MAP + orchestrator (gerekiyorsa) kurulumu hızlanır. 45-75 gün: lifecycle akışları, cross-channel patern, ilk 6-10 production workflow.
3. Kişiselleştirme en son — gerekiyorsa. Önceki iki adım yerinde değilse kişiselleştirme açılmaz. Ön koşullar varsa 75-90. günden sonra pilot.

Sırayı bozarsanız (ki çoğu ekip kişiselleştirme satışına önce kapılıyor) iki şey oluyor: birincisi, motor kötü veriyle çalıştığı için sonuçlar yanıltıcı; ikincisi, sonradan veri katmanını değiştirmek personalizasyon konfigürasyonunu da yeniden yazdırıyor. İki kez ödenmiş iş.

Bu sırayı somut bir vakada nasıl uyguladığımızı Arti2000 vaka analizinde adım adım anlattık: önce warehouse + reverse-ETL hattı, sonra Customer.io üzerine bindirdiğimiz n8n orchestrator ve nihayet 8. ayda devreye giren kişiselleştirme katmanı.

Ne öneriyoruz

Tek cümle ile özetlersek bağlama göre üç tipik öneri çıkıyor:

• <50K MAU, ürün-pazar uyumu arıyorsanız. Warehouse + reverse-ETL + tek MAP. Kişiselleştirmeyi atlayın. Aylık fatura düşük, esneklik yüksek, mühendislik ihtiyacı 1 kişi.
• PMF sonrası, ölçeklenirken. CDP ya da warehouse + reverse-ETL (ekibe göre) + orchestrator. Kişiselleştirme 12-24 ay içinde, ön koşullar tamamlandıktan sonra.
• Kurumsal + düzenlemeye tabi. Hibrit (warehouse + ince CDP) + orchestrator. Kişiselleştirme server-side. KVKK/GDPR akışı ilk günden tasarımda.

Üç senaryoda da değişmeyen şey: karar sırası. Veri katmanı önce, otomasyon merkezi ikinci, kişiselleştirme son. Bu matrisi her engagement’ın ilk haftasında müşteri ekibiyle birlikte dolduruyoruz; çıktı, sonraki 90 günün yol haritasını ve kesilebilecek araçları net gösteriyor. Sonraki üç ay, önceki yığınla yüzleşip hangi kararların hâlâ geçerli, hangilerinin yenilenmesi gerektiğine birlikte karar verdiğimiz dönem.

Kendi yığınınızda bu üç soruya cevap vermekte zorlanıyorsanız ya da mevcut kararların geriye dönüp kontrol edilmesini istiyorsanız: keşif görüşmesi için bize ulaşın — [email protected].