Bakın şimdi, analitik deyince çoğu kişinin aklına hâlâ GA4 geliyor. Haksız da sayılmaz açıkçası. Sonuçta yıllardır masada o var ve herkes ona alışmış, ekipler ona göre rapor düzenlemiş, yöneticiler ona göre PowerPoint hazırlamış (evet, doğru duydunuz). Ama iş küçük bir SaaS kurmaya, tek bir ekipte hem ürünü hem pazarlamayı hem de ölçümü aynı anda taşımaya gelince — GA4 bazen faydadan çok gürültü üretiyor, ciddi söylüyorum. Ben de bunu ilk kez 2024 yazında, Kadıköy’de bir startup ekibiyle oturup ürün metriklerine bakarken fark ettim: trafik var, tıklama var,. Para ile ilişki kurmak tam bir sis perdesi.
İşin aslı şu. Sorun sadece “hangi araç daha iyi” sorusu değil zaten. Sorun, hangi aracın sana gerçekten cevap verdiği. Çünkü mikro-SaaS ya da lean startup dünyasında ihtiyacın olan şey genelde üç soru: kim geldi, ne yaptı, ödeme yaptı mı? Gerisi çoğu zaman süslü ekranlar ve yarım kalan raporlar oluyor. Biraz sert söyledim ama gerçek bu.
Benzer bir sıkıntıyı 2023 sonbaharında İzmir merkezli bir e-ticaret yan projesinde de yaşamıştım. Trafik artmış görünüyordu, herkes seviniyordu… ta ki Stripe tarafına bakana kadar. Meğer kampanya güzel görünse de dönüşüm zayıfmış. Şaşırdık açıkçası. O gün anladım ki analitik araçları birbirine konuşturmadığın sürece elinde sadece ayrı ayrı hikâyeler kalıyor —. Bu hikâyeler birbirini tutmuyor.
Hmm, bunu nasıl anlatsamdı…
Tracking debt neden büyüyor?
“Tracking debt” diye tabir edilen şey aslında bildiğin teknik borç gibi çalışıyor. Başlangıçta basit. Bir GA4 etiketi ekliyorsun, sonra heatmap için Clarity koyuyorsun, ödeme tarafı için Stripe paneline bakıyorsun, araya başka event scriptleri giriyor… Derken sayfa yükü şişiyor, gizlilik politikası uzuyor, (belki yanılıyorum ama) debug işi çileye dönüyor. En kötüsü — kimse bu dağınıklığın ne zaman bu kadar büyüdüğünü hatırlamıyor bile. Küçük ekiplerde bu durum çok daha hızlı büyüyor çünkü kimse “bir dakika, bu script niye burada?” diye geri dönmüyor.
İlginç olan şu ki, Bir de şu var. Bu araçların çoğu aynı dili konuşmuyor (evet, doğru duydunuz). GA4 trafik anlatıyor, Stripe gelir anlatıyor, performans aracı LCP gösteriyor — ama bunları tek satırda bağlayamıyorsun (ciddiyim). Yani diyelim ki deploy sonrası LCP bozuldu; bunun gelir kaybına etkisini görmek için ayrı ayrı paneller arasında sekme açıp kapatıyorsun. Açık konuşayım, bu bayağı yorucu.
Evet, doğru duydunuz.
Kendi not defterime 2025 Şubat’ında İstanbul’da şunu yazmışım: “Dashboard fazla ise karar yavaşlıyor.” O cümle hâlâ geçerli. Ekipler bazen veri topladıkça rahatlayacağını sanıyor ama tam tersi oluyor. Veri artıyor. Netlik azalıyor. Peki bunu neden söylüyorum? Herkes farklı panele bakıyor, tartışmalar uzuyor.
Tek script fikri neden cazip?
Basit. Tek script, daha az karmaşa demek değil sadece — aynı zamanda daha temiz bakım anlamına geliyor. Bir kullanıcı etkileşimini izlemek için beş farklı yapılandırma dosyasına dokunmak zorunda kalmıyorsan işler hızlanıyor, hata ayıklamak kolaylaşıyor, ve yeni gelen bir geliştirici sistemi anlayabiliyor ilk haftasında. Hele bir de ürün geliştirme temposu yüksek ekiplerde bu fark baya hissediliyor.
Ama dur bir saniye. Tek script her derde deva mı? Değil. Eğer yanlış kurgulanırsa büyük çoğunluk gözlem katmanını tek noktaya bağlamış olursun — orası patlarsa ortada kalırsın, hem de hiçbir şey göremez hale gelirsin. Yani sadeleşme güzel ama körleşme pahasına olmamalı. Bu ayrımı kaçırmamak lazım.
Hmm, bunu nasıl anlatsamdı…
Next.js + Supabase yaklaşımı nasıl çalışıyor?
Vallahi, Bence burada en tatlı nokta mimarinin hafif olması. Next.js App Router ile ön yüzü toparlıyorsun; TypeScript ile olayları düzenli tutuyorsun; Supabase tarafında PostgreSQL. Sağlam zemini veriyor. Cloudflare gibi kenar katmanı çözümleriyle birleşince sistem fena durmuyor doğrusu. Şaşırdım açıkçası ilk denediğimde ne kadar az şeyle ne kadar çok şey yapılabildiğine.
Aşağıdaki tabloyu ben olsam ürün toplantısında direkt açarım (ben de ilk duyduğumda şaşırmıştım). Çünkü mesele teoriden çok pratikte ne kazandığın: Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımızda bu konuya da değinmiştik.
| Yaklaşım | Artısı | Eksi tarafı |
|---|---|---|
| GA4 ağırlıklı kurulum | Paket halinde gelir, tanıdık | Karmaşık arayüz, zayıf bağlam |
| Özel Next.js + Supabase stack | Daha esnek, daha sade raporlama | İlk kurulumda mühendislik ister |
| Melez model | Kısa vadede güvenli geçiş sağlar | Karmaşıklığı tamamen bitirmez |
Evet, özel çözümün bedeli var. Başlangıçta biraz daha fazla düşünmen gerekiyor, bir iki hafta kurulum meselesi oluyor. Ama karşılığında şunu alıyorsun — kendi ürününün dilini konuşan metrikler. Mesela sadece “ziyaretçi sayısı” değil; hangi ziyaretçinin hangi deploy’dan sonra siteyi terk ettiği ya da hangi trafik kaynağının gerçekten müşteri getirdiği görülebiliyor. Bu fark küçük değil. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
GA4 size trafiği anlatır; özel stack ise trafiğin işinize ne yaptığını gösterir.
LTV ile performansı aynı masaya oturtmak
İnanın, Beni en çok ikna eden kısım burası oldu. Bir kaynak Reddit’ten bin ziyaretçi getiriyor olabilir — sıfır satış üretiyorsa ne anlamı kaldı ki? Öte yandan niş bir newsletter on ziyaretçi getirip beş müşteri kazandırabiliyor. Gerçek resim burada çıkıyor ortaya. Hmm, bunu ilk duyduğunda kulağa basit geliyor ama veriye bakmadan önce bunu içselleştirmek zor (bizzat test ettim)
Bunu ilk kez test ettiğimde Ankara’daki küçük bir B2B projede gerçekten şaşırdım. En pahalı görünen kanal en kötü kanaldı. En sessiz görünen kanal ise aylık aboneliğin yarısını taşıyordu. Siz hiç denediniz mi? İşte bu yüzden gelir verisini trafikten ayırmadan yorumlamak bana artık eksik geliyor — neredeyse aldatıcı bile diyebilirim. Bu konuyla ilgili Apple Watch’a Nisan Sürprizi: İki Yeni Aktivite Mücadelesi yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili SQL’e Dönüşün İlk Günü: Konsantrasyon, Notlar, İnat yazımıza da göz atmanızı tavsiye ederim.
Küçük startup için ne işe yarar?
Küçük ekiplerde hız her şeydir. Her yeni araç yeni öğrenme maliyeti demek olduğundan sade panel ciddi avantaj sağlıyor. Kurucu da product manager da geliştirici de aynı ekrana bakınca tartışma kısa sürüyor, herkes aynı sayıya bakıyor, kimse “ama benim panelde farklı gösteriyor” demiyor (bizzat test ettim). Bu küçük detay ekip içi güveni inanılmaz etkiliyor. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Kurumsal tarafta durum farklı mı?
Şunu fark ettim: Evet, biraz farklı. Enterprise seviyede uyumluluk, rol yönetimi, denetim izi gibi başlıklar öne çıkıyor. Bu noktada özel stack hâlâ işe yarayabilir ama disiplin ister; yoksa birkaç ay içinde yine kontrolsüzlük başlar. Yani mesele araçtan çok yönetişim. Hani ne farkı var diyorsunuz, değil mi? Kurumsal ortamda en iyi araç bile sahipsiz kalırsa kısa sürede karmaşaya dönüyor.
Dikkat edilmesi gerekenler ve pratik ipuçları
Lafı gevelemeden söyleyeyim: Kendi analitik sistemini kurmak romantik görünebilir. Doğru sınırlar çizmezsen kısa sürede minik bir canavara dönüşür. Ciddiyim.
Mesela event isimlerini standartlaştırmazsan dashboard kirlenir. Kim hangi metriğe bakacak belli olmazsa ekip içinde güven kaybolur. Ve en önemlisi — gereksiz veri toplamaya kalkarsan gizlilik tarafını kendin zorlaştırırsın, hem teknik hem hukuki anlamda.
- Önce üç ana soruyu belirle: kim geldi, ne yaptı, para bıraktı mı?
- Tüm event adlarını baştan sabitle.
- LCP/CLS gibi performans sinyallerini doğrudan session’a bağla.
- Sadece ihtiyacın olan veriyi sakla.
(bu kritik) - A/B test yapacaksan önce ölçüm katmanını sağlamlaştır.
Neyse uzatmayayım. Ben olsam önce hibrit giderdim. Yani GA4’ü tamamen atmak yerine kritik kararlar için kendi panelini paralel kurarsın, sonra birkaç hafta kıyas yaparsın. Eğer kendi panelin net cevap veriyorsa — işte o zaman geçiş mantıklı olur. Aceleyle köprüleri yakmanın gereği yok.
Neden bazı takımlar yine de GA4’ten vazgeçemez?
Garip gelecek ama, Bazı ekiplerin işi reklam optimizasyonu üzerine kuruluysa GA4 hâlâ güçlü olabilir. Mesela büyük kampanya hacmi, çoklu segmentasyon ve pazarlama entegrasyonlarında alışkanlık gücü büyük rol oynuyor. Yani mesele siyah-beyaz değil. Her ekibin durumu farklı, her ürünün ihtiyacı farklı — bunu atlamamak lazım.
Sıkça Sorulan Sorular
GA4 yerine özel analytics sistemi kurmak zor mu?
İlk kurulum evet, biraz emek ister. Ama ihtiyaçların basitse uzun vadede bakım kolaylığı sağlayabilir.Karmaşıklığı azaltmak istiyorsan iyi planlama şart. (bizzat test ettim)
Next.js ve Supabase küçük projeler için yeterli mi?
Yani, Evet, çoğu mikro-SaaS ve erken aşama ürün için fazlasıyla yeterli olur. En çok da hızlı prototipleme istiyorsan güzel iş çıkarır.
Kendi analytics sistemimde hangi metrikleri takip etmeliyim?
Ziyaretçi kaynağı, temel etkileşimler, dönüşüm oranı, gelir. Performans metrikleri iyi başlangıç noktasıdır. Daha fazlasını ancak gerçekten ihtiyacın varsa ekle.
Böyle bir sistemde gizlilik açısından nelere dikkat edilmeli?
Sadece gerekli veriyi topla açık rızaları düzgün yönet.IP adresi,kişisel veri ve çerez tarafını hukuki açıdan mutlaka kontrol et.
Kaynaklar ve İleri Okuma
Araya gireyim: Next.js Resmî Dokümantasyonu
Şunu söyleyeyim, Google Analytics dört Geliştirici Kılavuzu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
