Ücretsiz plan tavanına çarpan bir analitik kurulumunda ilk suçlanan şey trafik oluyor. Oysa ölçtüğüm kurulumlarda tavanı ziyaretçi sayısı değil, her ziyaretçi için kaç satır yazıldığı belirliyor. Aynı trafiği alan iki site kota tüketiminde kat kat ayrışabiliyor, çünkü sekiz property taşıyan bir event ile çıplak bir event arasında dokuz kata varan fark oluşuyor.
Bu yazı fatura biriminin ne olduğunu, kendi kurulumunun aylık bütçesinin nasıl çıkarıldığını, kotanın nereye gittiğini ve hangi eşikte plan değişikliğinin, hangi eşikte self-host’un anlamlı olduğunu anlatıyor.
Fatura Birimi Ne
Cookieless analitik araçları aynı şeyi saymıyor. Kimi üründe fatura birimi sayfa görüntüleme, kimisinde her etkileşim, kimisinde de event’e iliştirilen her alan ayrı bir kayıt. Hangi ürünün hangisini saydığı ancak o ürünün kendi kullanım tanımından okunabiliyor, fiyat tablosundan çıkmıyor. Plan seçmeden önce cevaplanması gereken soru fiyat değil, birim.
Umami bu konuda açık yazıyor. Kullanım, sayfa görüntülemeler ile custom event’lerin ve saklanan custom event property’lerinin toplamı olarak ölçülüyor; her sayfa görüntüleme bir event sayılıyor ve saklanan her property de ayrıca bir event sayılıyor.1 Yani sekiz anahtarlı bir segment objesi taşıyan tek bir custom event, kotadan bir değil dokuz birim düşüyor.
Aracın kendi kullanım paneli de bu ayrımı gösteriyor: event’ler, event data, session data ve heatmap data ayrı kalemler halinde listeleniyor. Kendi sitemde bu kırılım aylık tüketimin yüzde kırkının event’lerden, yüzde altmışının event data’dan geldiğini söylüyor. Yani kotanın çoğunu ölçtüğüm davranışlar değil, o davranışların yanına yazdığım etiketler harcıyor.
Aylık Bütçe Hesabı
Hesap üç kalemli:
günlük birim = sayfa görüntüleme + custom event + saklanan property satırı
aylık bütçe = günlük birim x 30Bu üç sayıyı panelden ya da dışa aktarma dosyalarındaki satır sayılarından okuyabiliyorsun. Tek günlük ölçüm yerine bir haftalık ortalama almak daha doğru sonuç veriyor.
Kendi içerik sitemde sekiz günlük bir pencerede ölçüm şöyleydi:
| Kalem | Sekiz günde | Aylık karşılığı |
|---|---|---|
| Sayfa görüntüleme | 1.464 | ~5.500 |
| Custom event | 6.865 | ~25.700 |
| Property satırı | 12.567 | ~47.100 |
| Toplam birim | 20.896 | ~78.400 |
Ücretsiz planın tavanı ayda yüz bin event.2 Yani sayfa görüntülemeler kotanın yüzde yedisini kullanıyor, geri kalanının tamamı ölçüm tasarımından geliyor. Trafik iki katına çıkarsa tüketim de iki katına çıkıyor, bu kaçınılmaz. Kontrol edilebilir olan çarpan ise sayfa başına yazılan satır sayısı: her event’e iki property eklemek, trafiğe hiç dokunmadan aynı etkiyi üretiyor.
Karşılaştırma için, yüksek hacimli bir e-ticaret kurulumunda üç günlük bir pencerede aynı hesabı yaptığımda günlük tüketim yaklaşık kırk dört bin birim çıktı. Ücretsiz planın tavanı bu hızda iki gün civarında doluyor. Aynı kurulumda custom event’lerin tamamı kapatılıp yalnızca sayfa görüntüleme bırakılsaydı tavan yaklaşık on bir günde dolacaktı. Yani o ölçekte ücretsiz plan bir kota yönetimi sorunu değil, yapısal bir uyumsuzluk.
Kota Nereye Gidiyor
Tüketimi büyüten dört desen var ve dördü de ölçümü zenginleştirme niyetiyle ortaya çıkıyor.
Her event’e iliştirilen segment objesi. Sayfa türü, içerik dili, üyelik durumu gibi alanlar analiz için değerli, ama bir oturum boyunca değişmiyorlar. Her event’e eklendiklerinde event sayısı kadar satır yazılıyor. Kendi kurulumumda sekiz günlük tüketimin yüzde yetmişi tek bir segment event’inden geliyordu.
Sabit değer taşıyan property. Henüz doldurulmamış bir alan varsayılan değeriyle gönderildiğinde kota harcıyor, bilgi taşımıyor. Her satırda aynı değeri taşıyan bir property, analizde ayrım üretmiyor.
İç içe objeler. Umami event data’yı düzleştirerek saklıyor ve iç içe alanlar nokta notasyonuyla ayrı satırlara açılıyor. Dört anahtarlı bir alt obje, dataLayer’da tek alan gibi görünürken kotadan dört birim düşüyor.
Eşik başına tekrar eden event’ler. Yüzde yirmi beş, elli, yetmiş beş ve yüz eşiklerinde tetiklenen bir kaydırma ölçümü, sonuna kadar okunan her sayfa için dört event yazıyor. Bu tasarım doğru olabilir, ama maliyeti sayfa başına bir değil dört.
Tasarruf Kalemleri
Etkisi büyükten küçüğe:
Segment bilgisini oturum seviyesine taşı. Oturum boyunca değişmeyen alanlar için event property’si yerine oturum property’si kullanılıyor. Umami tarafında bu umami.identify() çağrısıyla yapılıyor ve nesne argümanına kimlik alanı konulmadığında ziyaretçiye kimlik atanmıyor, yalnızca oturuma etiket yazılıyor. Oturum başına ortalama yedi event üreten bir sitede aynı bilgi yaklaşık yedi kat daha az satırla saklanıyor. Oturum property’leri kullanım panelinde ayrı bir kalem olarak listeleniyor, yani ölçüldüklerini varsaymak gerekiyor; kullanım tanımı bu kalemden açıkça söz etmiyor. Maliyet sıfırlanmıyor, ölçeği değişiyor.
Beyaz liste kullan. Bir ölçüm objesinin tamamını event’e iliştirmek yerine, analizde gerçekten kullanılan alanları tek tek seçmek gerekiyor. Kaydırma hızının varyansı ve ivme düzgünlüğü gibi türetilmiş metrikler GA4 tarafında parametre olarak sorgulanabiliyor; cookieless araçta rapor karşılığı yoksa yalnızca maliyet oluyor.
Eşik sayısını azalt. Dört eşikli kaydırma ölçümü iki eşiğe indirildiğinde hacim yarıya iniyor. Kayıp bilgi sınırlı kalıyor, çünkü hangi eşiğin geçildiği zaten event’in kendi alanında taşınıyor.
Görünürlük event’lerini kırp. Bir CTA’nın ekranda görünmesi bir karar değil, gözlem. Bu tür event’ler genelde en yüksek hacimli, en düşük karar değeri taşıyan kalem oluyor.
Kendi trafiğini dışla. Test ve önizleme oturumları hem kotayı tüketiyor hem oranları bozuyor. Etiket yönetiminde internal traffic kuralı ve önizleme oturumları için ayrı bir işaret bunun için yeterli.
Consent Event’lerinin Ayak İzi
Consent kararlarını ölçmek isteyen bir kurulumda kota tarafında üç ayrıntı var.
Kararların kendisi ucuz. Kabul, ret, tercihler ekranı ve geri alma event’leri oturum başına en fazla birkaç kez oluşuyor.
Gösterim sayımı pahalı olabiliyor. Banner, karar verilene kadar her sayfada yeniden görünüyor. Gösterim ham haliyle sayılırsa kararsız gezinen tek ziyaretçi hem paydayı şişiriyor hem kotayı harcıyor. Gösterimin oturum başına bir kez sayılması bu iki sorunu birlikte çözüyor.
Karar event’lerine property eklemek genelde gereksiz. Ölçülen şey kararın kendisi olduğu için, yanına dil ya da sayfa türü yazmak kota harcayıp analize az şey katıyor. Consent oranının nasıl ölçüldüğü ve hangi soruların export’tan cevaplanamadığı ayrı bir konu, onu consent oranı ölçümü yazısında ele aldım. Karar event’lerinin tracker’a bağlanmadan nasıl gönderildiğini ve hangi alanların payload’dan çıkarıldığını ise Umami’yi GTM ile consent’e uygun kurmak yazısında anlattım.
Tavana Çarpınca Ne Oluyor
Aşımı faturalandıran planlarda toplama sürüyor ve fazlası ücretlendiriliyor. Ücretsiz planda gönderim isteği reddediliyor.
Asıl sorun reddedilmesi değil, sessiz olması. Umami tracker’ının kaynağında gönderim fonksiyonu yanıtın başarılı olup olmadığını kontrol etmiyor, doğrudan gövdeyi okumaya çalışıyor ve hata durumunda boş bir catch bloğuna düşüyor.3 Yeniden deneme yok, konsola uyarı yok. Panelde yalnızca sıfıra inen bir çizgi kalıyor, ki bu trafik düşüşü gibi de okunabiliyor.
Pratik karşılığı şu: ölçüm sisteminin kendisi izlenmediğinde, veri kaybı haftalarca fark edilmeden sürebiliyor. Kullanım sayacına kurulumdan sonraki ilk ay günlük, sonrasında haftalık bakmak gerekiyor. Kota tüketimini bir ölçüm metriği gibi takip etmek, tavana çarpmadan önce hangi event’in büyüdüğünü de gösteriyor.
Hangi Eşikte Hangi Karar
| Durum | Belirti | Karar |
|---|---|---|
| Aylık bütçe tavanın altında, tek site | Kota tüketimi sabit, property sayısı kontrollü | Ücretsiz plan yeterli |
| Bütçe tavanı aşıyor, hacim düzenli artıyor | Tavan günler veya haftalar içinde doluyor | Ücretli plana geç, aşım birim fiyatla faturalanıyor |
| Hangi property’nin saklanacağı fatura sorusuna dönüştü | Ölçüm kararları kota kısıtıyla veriliyor | Self-host’u değerlendir |
| Veri ambara taşınacak, başka kaynaklarla birleştirilecek | Yönetilen planın dışa aktarma yolları dar kalıyor | Self-host, veritabanı erişimi için |
| Verinin nerede durduğu sözleşme konusu | Müşteri veya mevzuat gereği konum belirleniyor | Self-host, veri konumu için |
Sıralama şöyle işliyor.
Ücretsiz plan, aylık bütçesi tavanın altında kalan ve tek site ölçen kurulumlar için yeterli. İçerik siteleri bu banda genellikle sığıyor, ama sığmanın koşulu event tasarımının disiplinli kalması. Ölçtüğüm kurulumda kotanın yüzde yetmişini tek bir segment event’i harcıyordu ve bu düzeltilmeden trafik artışı tavanı getirecekti.
Ücretli plan, bütçe tavanı aştığında ilk seçenek. Aşımın birim fiyatla faturalanması, kotayı sert bir duvar olmaktan çıkarıp kaydırılabilir bir eşiğe çeviriyor. Ücretsiz planın e-ticaret ölçeğinde günler içinde dolduğu düşünülürse, bu bantta karar hesap bile gerektirmiyor.
Self-host kararı maliyetle verilmiyor. Küçük ve orta ölçekte yönetilen planla sunucu arasındaki aylık fark, bakım süresinin karşılığını nadiren buluyor. Self-host’u haklı çıkaran üç durum var:
- Veritabanına doğrudan erişim gerekiyorsa. Ambara taşınacak ve başka kaynaklarla birleştirilecek bir veri katmanı kuruluyorsa, yönetilen planın dışa aktarma yolları dar kalıyor.
- Event hacmi kotayı sürekli bir kısıt haline getirdiyse. Hangi property’nin saklanacağı sorusu bir ölçüm kararı olmaktan çıkıp fatura kararına dönüştüğünde, kısıtı kaldırmak tasarımı serbest bırakıyor.
- Verinin nerede durduğu sözleşme gereği belirleyiciyse.
Karşılığında sürüm takibi, yedekleme ve veritabanı bakımı ortaya çıkıyor. Bir de dikkat edilmesi gereken bir yan etki var: yönetilen tarafta üst pakete kilitli olan session replay ve heatmap özellikleri, kendi sunucunda bir ayar mesafesinde duruyor. Fiyat engeli kalktığı için yanlışlıkla açılması da kolaylaşıyor ve replay açıldığı anda cookieless bir kurulum oturum kaydına dönüşüyor.
Sınırlar
Buradaki sayılar sekiz günlük ve üç günlük iki ölçüm penceresinden geliyor, mevsimsellik içermiyor. Kendi kurulumunda hesabı en az bir haftalık veriyle yapman gerekiyor.
Fiyatlar ve kota tanımları değişiyor. Bu yazıdaki tanımlar ve tavanlar 27 Ağustos 2026’da kontrol edildi; karar vermeden önce ürünün kendi sayfasından teyit etmek gerekiyor.
Son olarak, kota tasarrufu tek başına bir amaç değil. Silinen her property analizde bir soruyu cevapsız bırakıyor. Doğru soru “kotayı nasıl düşürürüm” değil, “hangi alan hangi kararı besliyor” olmalı; cevabı olmayan her alan zaten iki kez maliyet üretiyor, bir kez faturada, bir kez raporda gürültü olarak.
Footnotes
- Umami, Pricing sayfasındaki sık sorulan sorular bölümü: “Usage is measured by counting pageviews to a website plus any custom events or custom event properties stored.” 27 Ağustos 2026’da kontrol edildi. ↩
- Umami Cloud plan tavanları, aynı sayfadan: ücretsiz planda aylık yüz bin event ve tek site, ücretli planda bir milyon event ve aşım için birim fiyat. 27 Ağustos 2026’da kontrol edildi. ↩
-
umami-software/umamideposu,src/tracker/index.tsdosyasınınv3.3.1sürümü, gönderim fonksiyonu. ↩
- 01 Fatura birimi araçtan araca değişiyor. Umami'nin tanımı açık: her sayfa görüntüleme bir event, her custom event bir event ve saklanan her property ayrıca bir event sayılıyor. Sekiz anahtarlı bir segment objesi taşıyan tek bir event kotadan dokuz birim düşüyor; iç içe objeler de nokta notasyonuyla düzleşip her alt anahtar için ayrı satır yazıyor.
- 02 Aylık bütçe basit bir toplamla çıkıyor: pageview + custom event + property satırı, günlük ortalamayla çarpılıp otuza vurulunca. Ölçtüğüm içerik sitesinde pageview'lar kotanın yalnızca yüzde yedisiydi.
- 03 Segment bilgisi her event'e iliştirilmek yerine oturum seviyesine taşındığında aynı bilgi event başına değil oturum başına yazılıyor. Sabit değer taşıyan property ise kota harcayıp bilgi taşımıyor.
- 04 Kota dolduğunda gönderim isteği reddediliyor ve tracker yanıtı kontrol etmediği için ne yeniden deneme ne uyarı oluyor. Ölçümün kendisi izlenmediğinde veri kaybı haftalarca fark edilmeyebiliyor.
- 05 Plan kararı ölçekle, self-host kararı ise ihtiyaçla veriliyor. Self-host'u haklı çıkaran şey aylık birkaç dolarlık fark değil, veritabanına doğrudan erişim, kota kavramının ortadan kalkması ve verinin nerede durduğu.
+ Analitik aracının ücretsiz planında tam olarak ne sayılıyor?
Ürüne göre değişiyor ve satın almadan önce bakılması gereken ilk şey bu. Umami'nin tanımına göre kullanım, sayfa görüntülemeler ile custom event'lerin ve saklanan custom event property'lerinin toplamı olarak ölçülüyor; her sayfa görüntüleme bir event, saklanan her property de ayrıca bir event sayılıyor. Yalnızca sayfa görüntüleme sayan araçlarda aynı kurulum çok daha ucuza gelirken, event ve property sayan araçlarda zengin bir veri katmanı tavanı hızla doldurabiliyor.
+ Kendi kurulumumun aylık kota tüketimini nasıl hesaplarım?
Bir günlük veriyi üç kalemde toplaman yeterli: sayfa görüntüleme sayısı, custom event sayısı ve bu event'lere bağlı saklanan property satırı sayısı. Üçünün toplamı günlük birim tüketimini veriyor, otuzla çarpınca aylık bütçe çıkıyor. Veriyi panelden okuyabilir ya da dışa aktarma dosyalarındaki satır sayılarını sayabilirsin. Ölçüm penceresi olarak tek gün yerine bir haftalık ortalama almak daha güvenli, çünkü hafta içi ve hafta sonu farkı tek günlük ölçümü yanıltıyor.
+ Property'leri event yerine oturum seviyesine taşımak kotayı gerçekten düşürür mü?
Hacim farkı kadar düşürüyor. Sayfa türü, dil, üyelik durumu gibi bir oturum boyunca değişmeyen alanlar her event'e iliştirildiğinde event sayısı kadar satır yazılıyor; oturum property'sine taşındığında oturum sayısı kadar. Oturum başına ortalama yedi event üreten bir sitede bu yaklaşık yedi kat fark demek. Oturum property'leri kullanım panelinde ayrı bir kalem olarak listeleniyor, dolayısıyla ölçüldüklerini varsaymak gerekiyor; maliyet sıfırlanmıyor, ölçeği değişiyor.
+ Consent banner kararlarını ölçmek kotayı ne kadar etkiler?
Kararların kendisi ucuz, gösterim sayımı pahalı olabiliyor. Kabul, ret ve tercihler ekranı event'leri oturum başına en fazla birkaç kez oluşuyor. Banner gösterimi ise karar verilene kadar her sayfada yeniden tetiklenebiliyor; oturum başına tekilleştirilmediğinde hem kabul oranı olduğundan düşük çıkıyor hem kota gereksiz yere tüketiliyor. Karar event'lerine property eklemek de genelde gereksiz, çünkü ölçülen şey kararın kendisi.
+ Kota dolduğunda ne oluyor, veri sonradan gelir mi?
Aşımı faturalandıran planlarda toplama devam ediyor ve fazlası ücretlendiriliyor. Ücretsiz planda ise gönderim isteği reddediliyor ve sonradan telafi edilemiyor. Kritik olan kısım sessizliği: tracker yanıt kodunu kontrol etmediği için konsolda hata görünmüyor, panelde yalnızca sıfıra inen bir çizgi kalıyor. Bu yüzden kullanım sayacına haftalık bakmak, kurulumdan sonraki ilk aya kadar günlük bakmak gerekiyor.
+ Hangi noktada self-host etmek mantıklı olur?
Karar maliyetle verilmiyor, çünkü küçük ve orta ölçekte yönetilen planın aylık bedeli ile sunucu bedeli arasındaki fark bakım süresinin karşılığını nadiren buluyor. Self-host üç durumda anlamlı: veritabanına doğrudan erişim gerekiyorsa, event hacmi kotayı bir ölçüm kararı olmaktan çıkarıp sürekli bir kısıt haline getirdiyse ve verinin nerede durduğu sözleşme gereği belirleyiciyse. Karşılığında sürüm takibi, yedekleme ve veritabanı bakımı söz konusu oluyor.