Matomo ve Self‑Hosted Analytics İçin Hosting Rehberi: Gizlilik Odaklı İzleme

Matomo ve Self‑Hosted Analytics İçin Doğru Hosting Neden Bu Kadar Önemli?

Günlük veya aylık raporları sadece bir grafikten ibaret görmüyorsanız, analitik altyapısının aslında başlı başına bir kritik sistem olduğunu biliyorsunuzdur. Özellikle Matomo gibi self‑hosted (kendi sunucunuzda çalışan) analytics araçlarına geçtiğinizde, artık sadece bir “rapor aracı” değil; veri toplama, saklama, anonimleştirme, yedekleme ve ölçeklendirme sorumluluğunu da üstlenmiş oluyorsunuz.

DCHost ekibi olarak hem küçük bloglardan hem de yüksek trafikli e‑ticaret sitelerinden, kamu kurumlarından ve ajanslardan çok fazla “Matomo kuracağız, nasıl bir hosting seçelim?” sorusu alıyoruz. Sorunun arkasında genelde üç temel motivasyon oluyor:

• Gizlilik ve KVKK/GDPR uyumu: Ziyaretçi verisinin nerede ve nasıl tutulduğunu tam kontrol etmek.
• Bağımsızlık ve mülkiyet: Üçüncü parti bir servis kapansa bile veriyi elinde tutmak.
• Teknik esneklik: Log temelli analiz, ısı haritası, oturum kaydı, e‑ticaret entegrasyonu gibi gelişmiş özellikleri dilediği gibi kurgulamak.

Bu rehberde Matomo başta olmak üzere self‑hosted analytics araçları için hangi hosting türünün uygun olduğundan, kaç CPU ve ne kadar RAM gerektiğine; veritabanı tasarımından log anonimleştirmeye kadar pratik, sahada denenmiş yaklaşımları toparladık. Amacımız; Matomo kurulumu belgesini kopyalamak değil, analitik sunucunuzu DCHost üzerinde uzun vadeli, güvenli ve ölçeklenebilir şekilde nasıl planlayacağınızı netleştirmek.

Neden Self‑Hosted Analytics? Matomo’yu Tercih Edenlerin Temel Gerekçeleri

Self‑hosted analytics’e geçiş kararı genellikle hukuk, pazarlama ve teknik ekiplerin ortak masasında alınıyor. Masadaki ana başlıklar:

• Veri egemenliği: Ziyaretçi verilerinin hangi ülkede saklandığı, hangi kanunlara tabi olduğu netleşsin isteniyor.
• KVKK/GDPR uyumu: IP anonimleştirme, çerez onayı, veri saklama süreleri gibi konularda granular (ince ayarlı) kontrol ihtiyacı doğuyor.
• Üçüncü partiye bağımlılığı azaltma: Hizmet kapanırsa, ücret politikasını değiştirirse veya entegrasyon sorunları yaşanırsa etkilenmemek.
• Teknik özelleştirme: Özel event şemaları, custom dimension alanları, ham veriye doğrudan SQL erişimi gibi ihtiyaçlar.

Matomo bu noktada öne çıkıyor çünkü hem tarayıcı tabanlı izleme (JavaScript tracking) hem de sunucu taraflı izleme (log analizi, server‑side tracking) seçeneklerini bir arada sunuyor. Ayrıca ek modüllerle e‑ticaret takipleri, ısı haritası, formlar, A/B testleri gibi gelişmiş yetenekler kazanabiliyorsunuz. Tüm bunlar ise doğrudan hosting kaynaklarınızı etkiliyor.

Self‑hosted analytics kurarken unutulmaması gereken kritik nokta şu: Analitik sunucunuz da bir web uygulaması; tıpkı WordPress veya bir SaaS paneli gibi CPU, RAM, disk, I/O ve ağ kaynağı tüketiyor. Bu nedenle daha önce WordPress ve SaaS için CPU/RAM planlama konularında anlattığımız prensiplerin birçoğu Matomo için de geçerli.

Matomo ve Diğer Self‑Hosted Analytics Araçlarına Kısa Bakış

Bu rehberde odağımız Matomo; çünkü olgun ekosistemi, eklentileri ve KVKK/GDPR odaklı özellikleriyle en sık tercih edilen self‑hosted analytics çözümü. Yine de mimariyi planlarken piyasadaki diğer araçları da bilmek işinize yarar:

• Matomo: PHP + MySQL/MariaDB tabanlı, klasik LAMP/Lemp stack üzerinde koşuyor. Geniş plugin ekosistemi ve güçlü segmentasyon yetenekleri var.
• Log tabanlı analiz araçları (GoAccess, AWStats vb.): Web sunucusu loglarını okuyup rapor üretiyor. Çerez kullanmadan da basit trendleri görmek isteyenler için hafif bir çözüm.
• Modern self‑hosted analytics araçları: Çoğu Node.js veya Go tabanlı; olay (event) odaklı, hafif arayüzlü ve genelde basit metriklere odaklanan yapılar.

Bu çerçevede Matomo için tipik gereksinimler şöyle özetlenebilir:

• PHP 7.4+ / 8.x (güncel ve destekli sürüm)
• MySQL/MariaDB veritabanı (orta‑büyük projelerde ayrı veritabanı sunucusu önerilir)
• Apache veya Nginx (ya da LiteSpeed) web sunucusu
• CLI cron job çalıştırabilen bir ortam

Yani Matomo, tipik bir PHP uygulaması gibi davranıyor; bu da DCHost altyapısında paylaşımlı hosting, VPS, dedicated sunucu veya colocation üzerinde rahatlıkla barındırılabileceği anlamına geliyor. Önemli olan, doğru ölçeği ve mimariyi en başta kurgulamak.

Hangi Hosting Türü Matomo İçin Uygun? Paylaşımlı mı VPS mi Dedicated mı?

Analitik sunucunuzu nereye yerleştireceğiniz; sitenizin trafiğine, saklamak istediğiniz veri derinliğine ve kurum içi regülasyonlarınıza göre değişiyor. DCHost tarafında sık kullandığımız yaklaşımı üç seviyede anlatabiliriz.

1. Düşük Trafikli Siteler İçin: paylaşımlı hosting veya Küçük VPS

Aylık 10‑20 bin sayfa görüntüleme alan küçük bloglar, kurumsal tanıtım siteleri veya birkaç müşterisini takip etmek isteyen ajanslar için hafif Matomo kurulumları yeterli oluyor.

• Paylaşımlı hosting: PHP ve MySQL desteği varsa, CLI cron job çalıştırabiliyorsanız Matomo’yu temel raporlama senaryoları için kullanabilirsiniz.
• Küçük bir VPS (örneğin 1–2 vCPU, 2–4 GB RAM): Kaynak izole olduğu için performans daha öngörülebilir, ek paket/eklenti kurarken de daha özgür olursunuz.

Paylaşımlı hosting, tamamen maliyet odaklı ve basit raporların yeterli olduğu senaryolarda mantıklı. Ancak IP anonimleştirme, KVKK/GDPR odaklı log politikaları veya özel firewall kuralları gibi ihtiyaçlar devreye girdiğinde, biz genellikle VPS hosting kullanımını öneriyoruz.

2. Orta Trafikli Projeler İçin: Orta/Üst Seviye VPS

Aylık 100 bin – 2 milyon sayfa görüntüleme bandındaki sitelerde Matomo artık ciddi anlamda CPU, RAM ve disk I/O tüketmeye başlıyor. Özellikle:

• Olay (event) sayısı yüksekse,
• E‑ticaret takip modülleri aktifse,
• Isı haritası ve oturum kaydı gibi özellikler kullanılıyorsa

hem veritabanı boyutu hem de rapor oluşturma süresi hızla artıyor. Bu seviyede tipik DCHost mimarisi:

• 4–8 vCPU
• 8–16 GB RAM
• NVMe SSD disk (rastgele I/O’ya çok ihtiyaç duyulduğu için kritik)
• Ayrı yedekleme deposu (harici storage veya object storage)

Bu tür VPS’lerde güvenlik sertleştirme adımlarını, firewall ve otomatik güncellemeleri mutlaka devreye alıyoruz.

3. Yüksek Trafik ve Çok Siteli Kurumlar İçin: Dedicated Sunucu veya Colocation

Günlük yüz binlerce / milyonlarca sayfa görüntüleme alan haber siteleri, büyük e‑ticaret platformları veya onlarca müşteriyi tek Matomo kümesi altında toplayan ajanslar için dedicated sunucu veya colocation daha gerçekçi. Bu seviyede genellikle:

• Uygulama (PHP + web sunucusu) ve veritabanını ayrı sunuculara bölmek,
• RAID korumalı NVMe veya hızlı SSD kullanmak,
• Mümkünse veritabanında replikasyon veya yüksek erişilebilirlik kurgulamak

gibi çözümler devreye giriyor. Eğer kendi donanımınız varsa ve veri merkezinde barındırmak istiyorsanız, colocation sayesinde kendi sunucunuzu DCHost veri merkezinde barındırıp, Matomo’yu tamamen kurum içi politikalarınıza göre yönetebilirsiniz.

Kaynak Planlama: Matomo İçin Kaç CPU, Ne Kadar RAM ve Disk?

Analitik sunucusunda yapılan en yaygın hata, “nasıl olsa sadece rapor” diyerek zayıf bir paketle başlamak ve birkaç ay sonra raporların dakikalarca yüklenmesini izlemek. DCHost tarafında gözlemlediğimiz metriklere göre kabaca şu ölçeklendirme kılavuzunu kullanabilirsiniz.

CPU ve RAM

• Aylık < 50.000 sayfa görüntüleme
  1–2 vCPU, 2–4 GB RAM çoğu zaman yeterli. Cron job’ları düşük yoğunluklu çalıştırmak (5–15 dakikalık aralıklarla) performansı dengeler.
• 50.000 – 500.000 sayfa görüntüleme
  2–4 vCPU, 4–8 GB RAM daha gerçekçi. Özellikle segmentasyon ve özel raporlar kullanılıyorsa 4 vCPU altına düşmemeye çalışın.
• 500.000 – 5.000.000+ sayfa görüntüleme
  4–8+ vCPU, 8–16+ GB RAM seviyesine çıkmak gerekiyor. Bu seviyede genelde veritabanını ayrı makineye ayırmayı da düşünmeye başlıyoruz.

Elbette bunlar kaba kurallar. Event sayısı, e‑ticaret verileri, arşivleme periyotları ve cron konfigurasyonu CPU ihtiyacını ciddi şekilde etkiliyor. Özellikle web arayüzünden “All websites” görünümünü açtığınızda, Matomo arkada oldukça ağır sorgular çalıştırabiliyor.

Disk Tipi ve Kapasitesi

Matomo söz konusu olduğunda disk, sadece kapasite değil IOPS ve gecikme anlamına da geliyor. Bu yüzden:

• Mutlaka SSD, tercihen NVMe kullanın. Yüksek trafikli senaryolarda klasik HDD ile raporlar işkenceye döner.
• İlk kurulumda bile en az 40–60 GB disk planlayın. Birkaç yıl veri tutmayı düşünüyorsanız 100 GB+ daha mantıklı.
• Database ve dosya yedeklerini aynı diskte saklamamaya çalışın; yedek için ayrı storage veya object storage kullanımı, yedekleme sürelerini ve güvenliği iyileştirir.

Disk planlarken, daha önce trafik ve bant genişliği hesabı için önerdiğimiz yaklaşımı burada da uygulayabilirsiniz: Günlük event sayısını, saklamak istediğiniz yıl sayısıyla çarpın; log büyümesini ve indeks boyutlarını hesaba katın.

Bant Genişliği ve Trafik

Analytics için bant genişliği, ağırlıklı olarak şu iki kaynaktan tüketiliyor:

• Ziyaretçilerin tarayıcılarından gelen tracking istekleri
• Matomo arayüzüne giren kullanıcıların dashboard / rapor istekleri

Tracking istekleri genelde küçük JSON veya GIF istekleri olduğundan tek başına büyük bir bant genişliği yükü oluşturmaz; ancak yüksek trafikli sitelerde CDN veya reverse proxy kullanmak, hem origin (kaynak) üzerindeki yükü hem de gecikmeyi azaltır. Özellikle çok bölgeden trafik alan projelerde, GeoDNS ve çok bölgeli mimari gibi çözümlerle analytics isteklerini en yakın noktaya yönlendirmek mümkündür.

KVKK/GDPR Uyumlu Matomo Kurulumu: Lokasyon, Log ve Anonimleştirme

Self‑hosted analytics dünyasında en büyük avantajınız, hukuki ve teknik politikaları kendi kontrolünüzde tanımlayabilmeniz. Bunun bedeli ise doğru kurulum ve bakım sorumluluğu. DCHost tarafında Matomo planlarken şu başlıkları masaya yatırıyoruz.

1. Veri Lokasyonu ve Sunucu Bölgesi

Türkiye’de faaliyet gösteren ve KVKK’ya tabi bir şirket için, analitik verisinin hangi ülkede tutulduğu kritik. Benzer şekilde Avrupa’daki kullanıcılar için de GDPR devreye giriyor. Bu noktada:

• Hedef kitleniz ağırlıklı olarak Türkiye’deyse, analitik sunucusunu Türkiye veri merkezinde konumlandırmak hem gizlilik hem de gecikme süresi açısından avantaj sağlar.
• Avrupa odaklı projelerde, Avrupa bölgesindeki veri merkezlerimizi tercih ederek GDPR uyumu ve düşük latency arasında denge kurmak mümkün.

Bu konuyu daha geniş çerçevede ele aldığımız KVKK ve GDPR uyumlu hosting seçimi rehberine de mutlaka göz atmanızı öneririz.

2. IP Maskeleme ve Log Anonimleştirme

Matomo, IP adreslerini belirli sayıda bitten sonra sıfırlayarak anonimleştirebiliyor. Örneğin IPv4’te son okteti, IPv6’da ise son birkaç bloğu maskeleme gibi ayarlar söz konusu. Burada prensip şu:

• Analitik için gerekli olmayan hiçbir kişisel veriyi ham halde tutmamak.
• Gerekiyorsa IP’yi sadece kısa süreli (ör. 7–30 gün) ham olarak saklayıp sonrasında anonimleştirmek.

IP maskelemenin yanında, log düzeyinde de ek önlemler alabilirsiniz. Özellikle Matomo’yu Nginx/Apache arkasında çalıştırıyorsanız, web sunucusu loglarında da IP, User‑Agent ve Referrer gibi alanları KVKK/GDPR prensiplerine uygun yönetmek önemli. Bu konuda daha önce hazırladığımız log anonimleştirme ve IP maskeleme rehberi, analytics sunucularınız için de birebir uygulanabilir.

3. Veri Saklama Süreleri ve Otomatik Temizlik

Analitik verisini “sonsuz” saklamak çoğu zaman hukuki ve teknik açıdan gereksiz. Matomo içinde:

• Ham log verilerinin tutulma süresini (ör. 6 ay),
• Özetlenmiş, arşivlenmiş metriklerin saklama süresini (ör. 2–3 yıl)

ayrı ayrı tanımlayabilirsiniz. Böylece hem disk büyümesini kontrol altında tutar, hem de “gereğinden fazla veri tutma” riskini azaltırsınız. Yedekleme tarafında da KVKK, GDPR ve maliyet dengesiyle yedek saklama süresi belirleme yaklaşımıyla uyumlu bir politika kurmak en sağlıklısı.

4. Erişim Kontrolü ve Şifreleme

Analitik verisi her ne kadar doğrudan isim, soyisim içermese de, davranış profili anlamında oldukça kıymetli ve hassas. Bu nedenle:

• Matomo arayüzü için güçlü parolalar, mümkünse 2FA kullanın.
• Sunucu erişimini sadece SSH anahtarı ile, sınırlı kullanıcılarla sağlayın.
• Tüm panel ve tracking endpoint’lerini mutlaka HTTPS (TLS 1.2/1.3) üzerinden yayınlayın.

Sunucu tarafında HTTP güvenlik başlıklarını (HSTS, Content‑Security‑Policy vb.) doğru kurmak için de HTTP güvenlik başlıkları rehberimizde anlattığımız ayarlardan yararlanabilirsiniz.

Matomo İçin Önerilen Sunucu Mimarileri

Gelelim işin mimari tarafına. DCHost’ta sahada sık gördüğümüz ve çoğu senaryo için işe yarayan üç temel Matomo mimarisini paylaşalım.

Senaryo 1: Tek Site veya Küçük Portföy İçin Tek VPS

Kimin için uygun?

• 1–5 arası siteyi takip eden küçük işletmeler
• Aylık < 200.000 sayfa görüntüleme
• Temel raporlar, birkaç özel event/goal

Örnek yapı:

• 2–4 vCPU, 4–8 GB RAM, 80–160 GB NVMe SSD
• Apache veya Nginx + PHP‑FPM
• Aynı VPS üzerinde MySQL/MariaDB (küçük ölçek için yeterli)
• Günlük otomatik veritabanı + dosya yedeği (harici storage’a)

Bu senaryoda Matomo genelde analytics.siteniz.com gibi bir alt alan adında çalışıyor, sitenin kendisi ise başka bir hosting paketinde olabilir. DNS tarafında sadece ilgili alt alan için Matomo VPS’ine bir A/AAAA kaydı veriyorsunuz. Eğer DNS ve SSL yönetimini Cloudflare üzerinden yapıyorsanız, nameserver stratejinizi de buna göre kurgulayabilirsiniz.

Senaryo 2: Ajanslar ve SaaS Projeleri İçin Çok Siteli Tek Matomo

Kimin için uygun?

• Onlarca müşterisinin trafiğini tek panelden izlemek isteyen ajanslar
• Tek bir Matomo kurulumu üzerinden birden fazla ürünü, alt markayı veya SaaS tenant’ını izlemek isteyen ekipler

Örnek yapı:

• 4–8 vCPU, 8–16 GB RAM, 200+ GB NVMe SSD
• Nginx + PHP‑FPM (8–16 worker child, opcache aktif)
• Ayrı database kullanıcılarıyla tek veritabanı sunucusu (aynı VPS veya ayrı VPS)
• Log rotate ve otomatik arşivleme (Matomo archiver cron, saatlik/2 saatlik)

Bu modelde Matomo içinde her müşteri veya ürün için ayrı “website” kaydı oluşturarak, tek panelden hepsini yönetebilirsiniz. Ajansların sevdiği bir yöntem de, her müşteriye sadece kendi sitelerini görebilecekleri kullanıcı hesapları açmak. Burada dikkat edilmesi gereken:

• Veri saklama sürelerini müşteriye göre özelleştirmek (bazıları 2 yıl, bazıları 6 ay isteyebilir).
• Kaynak kullanımını düzenli izlemek. Bunun için VPS kaynak kullanımını izleme rehberimizde anlattığımız araçlardan (htop, Netdata, Prometheus+Grafana vb.) yararlanabilirsiniz.

Senaryo 3: Yüksek Trafikli Kurumsal Kurulum

Kimin için uygun?

• Günlük yüz binlerce / milyonlarca hit alan tekil site veya portal
• Kamu kurumları, bankalar, büyük e‑ticaret projeleri
• Sıkı KVKK/GDPR politikalarına tabi, detaylı denetlenebilirlik isteyen kurumlar

Örnek yapı:

• Uygulama sunucusu: 8–16 vCPU, 16–32 GB RAM, NVMe SSD
• Veritabanı sunucusu: 8–16 vCPU, 32+ GB RAM, RAID’li NVMe, replikasyon veya HA mimarisi
• Ön tarafta Nginx veya HAProxy ile reverse proxy ve temel WAF kuralları
• Yedeklerde 3‑2‑1 kuralı (3 kopya, 2 farklı medya, 1 farklı lokasyon)

Bu senaryoda genelde sistem ekipleri ve bilgi güvenliği birimiyle birlikte çalışarak aşağıdakileri ayrıca tasarlıyoruz:

• Veri sınıflandırma ve yetki matrisleri
• Yedeklerin şifrelenmesi ve saklama süreleri
• Log’ların merkezi log sistemi (ELK, Loki vb.) ile toplanması
• Periyodik zafiyet taramaları ve patch yönetimi

Güvenlik ve Bakım: Analitik Sunucusunu Uzun Vadede Sağlıklı Tutmak

Matomo veya başka bir analytics aracı kurup bırakmak, 1‑2 yıl sonra güncellenmemiş bir PHP uygulaması ve şişmiş bir veritabanı ile karşılaşmak demek. DCHost olarak bu tuzağa düşmemeniz için şu pratik kontrol listesini öneriyoruz.

1. Güvenlik Sertleştirme

• SSH’da root login’i kapatın, sadece anahtar doğrulaması kullanın.
• sshd_config, firewall (ufw/firewalld/nftables) ve fail2ban ayarlarını, VPS güvenlik sertleştirme rehberinde anlattığımız şekilde uygulayın.
• PHP için gereksiz modülleri devre dışı bırakın, upload limitlerini makul seviyede tutun.
• Matomo dizin izinlerini 644/755 gibi güvenli değerlerde tutun, config dosyalarına ekstra kısıtlama koyun.

2. Güncelleme Politikası

• Matomo çekirdeği ve eklentiler için aylık bir güncelleme penceresi belirleyin.
• PHP ve veritabanı sunucusu için minör güvenlik güncellemelerini otomatik, majör versiyon geçişlerini kontrollü yapın.
• Güncelleme öncesi otomatik snapshot veya tam yedek alın, geri dönüş senaryosunu (rollback) baştan planlayın.

3. İzleme ve Alarm Mekanizmaları

Analitik sunucusunun çalışıp çalışmadığını yalnızca pazarlama ekibinin fark etmesini beklemeyin. Şu metriklere alarm kurmak hayat kurtarır:

• Disk doluluk oranı (%80 üzeri uyarı)
• Veritabanı bağlantı hataları
• HTTP 5xx hata oranı (tracking endpoint’leri için)
• CPU’nun uzun süre %90+ seyretmesi

Bu konuda daha derinlemesine bir mimari kurmak isterseniz, Prometheus, Grafana ve Uptime Kuma ile izleme rehberimizde anlattığımız yaklaşım, Matomo sunucuları için de birebir uygulanabilir.

DCHost Üzerinde Matomo ve Self‑Hosted Analytics İçin Yol Haritası

Özetle; Matomo ve benzeri self‑hosted analytics çözümlerinde en kritik üç karar şunlar:

1. Doğru hosting türü ve bölgesi: Türkiye/Avrupa lokasyonu, paylaşımlı/VPS/dedicated/colocation kararı.
2. Gerçekçi kaynak planlama: Trafiğinize ve özelliklerinize göre CPU, RAM, disk ve bant genişliği seçimi.
3. KVKK/GDPR ve güvenlik politikası: IP maskeleme, veri saklama süresi, log anonimleştirme ve erişim kontrolleri.

DCHost olarak biz, bu üç kararı verirken sadece “kaç ziyaretçiniz var?” sorusunu sormuyoruz. Aynı zamanda:

• Kaç yıl geriye dönük veri tutmak istediğinizi,
• Ajans mısınız, tek site mi yoksa çok siteli bir yapı mı yöneteceğinizi,
• Hangi regülasyonlara tabi olduğunuzu (KVKK, GDPR vb.),
• Ekipte Linux/PHP yönetebilecek teknik kişi olup olmadığını

beraber masaya yatırıyoruz. Küçük bir blog için basit bir VPS paketi, onlarca müşterisini tek panelden takip etmek isteyen bir ajans için ise daha esnek, ölçeklenebilir VPS veya dedicated mimarileri kuruyoruz.

Eğer Matomo veya başka bir self‑hosted analytics aracına geçmeyi planlıyor, ama sunucu tarafında nereden başlayacağınızı netleştiremiyorsanız; mevcut trafik ve hedeflerinizi kısaca paylaşmanız yeterli. Sizin için uygun DCHost altyapısını, kaynak planlamasını ve KVKK/GDPR uyumlu veri stratejisini birlikte tasarlayabiliriz.

Sonuçta amaç, sadece “veri toplamak” değil; güvenli, hukuka uyumlu ve uzun vadede sürdürülebilir bir analitik platformu kurmak. Doğru hosting mimarisiyle Matomo’yu kurduğunuzda, pazarlama ekibi güvenle analiz yapar, hukuk ekibi veri yerleşimi ve anonimleştirmeden memnun olur, teknik ekip de gece ansızın uyanmak zorunda kalmaz.