Kendi Laravel Analytics Paketimi Nasıl Geliştirdim (ve Neredeyse Üretimi Krize Sokmadım)

Neden Google Analytics Değil? (Ya da neden tekerleği yeniden icat etmeyi seviyorum)

Gerçekçi olmak gerekirse, bu kolay bir karar değildi. Uzun bir süredir yazılım geliştiriyorum ve GA’ya alışmıştım. Ne kadar basit: ID’nizi içeren bir script’i siteye ekleyin, veriler analitik konsoluna akmaya başlar. Geriye sadece trafiğin gelmesini beklemek ve bunu ülkeye, cinsiyete, yaş gruplarına göre analiz etmek kalır.

Evet, geçmişte böyleydi ama günümüzde bu konsepti yeniden düşünmek için nesnel nedenler var. Açık olmak gerekirse: 2026 yılında Google Analytics’i bağlamak, ön kapınıza dev bir kilit takmak ama anahtarları komşunuza vermek gibi. Her şey kontrol altında gibi görünür ama komşunuz tam olarak ne zaman eve geldiğinizi, ne satın aldığınızı ve neden mutsuz olduğunuzu biliyor. Ve biri sizi ziyaret ettiğinde ve gizli kalmak istediğinde, komşu onlara anahtarları vermez ve sizden de onları ziyaret ettiklerini söylemez. Cevapları muhtemelen şu olur: “Kimse gelmedi, ben hiç uyumam, her şey kontrol altında…” Ne demek istediğimi anladınız mı?

Genel Veri Koruma Yönetmeliği’ni (GDPR) hatırlayın mı?

Artık analitiklerinizin işlemesi için bir çerez onay banner’ı göstermeniz ve kullanıcının iznini almanız gerekiyor. Ve işte sorun burada ortaya çıkıyor. Kullanıcıların %90’ı tüm çerezleri kabul etmiyor—sadece kesinlikle gerekli olanları kabul ediyor. Peki bu ne anlama geliyor? Google Analytics iptal olmuş demektir. Üstelik herkes bu banner’lardan bıktı. Yani, bunlardan kurtulmanın yasal bir yolu varsa, neden bunu yapmayasınız?

(Veri koruma yasalarıyla yasal sorunlardan nasıl kaçınacağınızı öğrenmek için Ödemesiz GDPR: Alman Web Geliştiricileri için Bir Kılavuz makalesine göz atabilirsiniz.)

GA’yı bırakma kararı alındı. “Eject” butonuna basıp Google ekosisteminden fırlatma kararı verdiğimde, yerini neyin alacağını mantıken düşünmem gerekti: çünkü hâlâ sayılara ihtiyacım vardı. Ağır toplara bakmaya başladım.

İlk aday Matomo (eski adıyla Piwik): Muhtemelen en güçlü hepsi bir arada makine. Bahçenizde bir fil beslemek gibi. Her şeyi yapıyor, veritabanı delice büyüyor, ama ayrı bir PHP sunucusu, MySQL ve sürekli bakım gerektiriyor. Küçük proje ve iş fikirlerim için, biraz fazla karmaşık gibi hissettirdi.

İkinci aracım Plausible / Fathom: Şık, modern ve gizliliğe saygılı. Ancak bir sorun var: ya bir abonelik ücreti ödüyorsunuz (ücretsiz bir araç için mantıklı bir yatırım mı?) ya da kendi barındırmalı Docker versiyonlarıyla uğraşmanız gerekiyor; bu da VPS RAM’inizin büyük bir kısmını tüketiyor.

Bunların hepsini gözden geçirip düşündüm: “Mümkün mü, sadece makalemi 50 kişiyi okumak için tamamen bir altyapı kurmayı gerektiriyor mu?” İşte o zaman fark ettim: “Biçerdöver” istemiyorum. Minik, hassas bir cerraha ihtiyacım var; bu da tam olarak Laravel uygulamamın içinde yaşamalı.

Kendime ait, hafif bir çözüm istiyordum; kahvaltıdan sonra içilen espresso kadar hafif, ve GDPR hakkında rahatsız edici sorular sormayan. Üstelik, oleant.net‘deki güvenlik araçlarıma kimlerin (ve botların) “vurduğunu” merak ediyordum. Bu blog da aynı araca ihtiyaç duyduğu için, composer ile kolayca kurulabilen ve Packagist’te açık bir şekilde yayınlanabilen bağımsız bir paket geliştirmeye karar verdim.

Kodu incelemekle ilgilenenler için, paketin adı oleant/laravel-visit-analytics, Laravel sürümleri 10/11/12 ile uyumludur. GitHub bağlantısı: https://github.com/Oleant-NET/laravel-visit-analytics

Sistemimizin Kalbi: Middleware ve Sonuçların Büyüsü

Hangi mimariyi kullanmalıyım? Bunu uygulamanın çeşitli yolları var. Neyse ki, Laravel harika bir Middleware mekanizmasına sahip. Ben de buna bağlı kalmayı tercih ettim ama bu kullanıcıyı yavaşlatır mı? Kullanıcının benim yükümlülüğümle ilgisi olmamalı. Ve ya veritabanı çökerse ya da bir şey ters giderse? Bir 500 hata sayfası siteyle karşı karşıya geldiğimde, kesinlikle hedeflediğim şey bu değil.

Bu nedenle kritik bir karar alındı—terminate() metodunu kullanmak. Laravel Middleware’de, kibar bir garson gibidir: size hesabı getirir ve gülümser (bu handle() metodu), ve siz restorandan çıkmadan sonra geri dönüp masayı silip bahşişi kaydeder (bu terminate() metodu).

Kullanıcı sayfasını almış ve mutlu bir şekilde ayrılmışken, sunucumuz sessizce ve acele etmeden veritabanına günlükleri kaydediyor. Herhangi bir şey ters gitse bile, müşteri memnun bir şekilde çıkmış oluyor. Garson… o zaman bahşiş almaz. Şaka bir yana, işte pratikte böyle çalışıyor:

PHP

public function terminate(Request $request, Response $response): void
{
    try {
        // Hedef olmayan müşteriler, admin vb. dışındaki mantık.
        // …
        // Ardından, ziyaretçilerimizi veritabanına yaz
        $this->logVisit($request);
    } catch (\Throwable $e) {
        // Eğer DB boğulursa, kullanıcının huzurunu bozmayız
        \Log::error("Analitik başarısız oldu, ama sakin kalıyoruz: " . $e->getMessage());
    }
}

Hayat Hilesi: Tüm analitik kodları mutlaka bir try-catch bloğuna sarılmalıdır. Bana güvenin, tüm projeyi çökerten bir User-Agent string’i bile olsa, gereksiz yere “çökmek” kadar komik bir şey olamaz.

GDPR Anında: Kamu düşmanı olmaktan kaçınmak için
Ekranın yarısını kaplayan “Sizi izliyoruz, dostum” ifadesini koymamak için IP anonimleştirmesi uyguladım. Veritabanına hiç ulaşmadan önce adresin son kısmını kısaltıyoruz. Bu, kullanıcıyı anonimleştirir ve yasaya tam ve uygun bir şekilde uyar. Yine de, ziyaretin hangi ülkeden, veri merkezinden geldiğini anlayabiliyoruz. Daha fazla veri elde ettikçe, veri merkezi botları hakkında daha fazla konuşacağız.

IP anonimleştirmesi hakkında:

PHP

// Önce: 192.168.1.154 -> Sonra: 192.168.1.0

Bu, maskeli bir kalabalığı görmek gibidir: 5 kişinin geldiğini anlıyorsunuz ama kimlerin komşunuz olduğunu bilemezsiniz. Yasa tatmin olmuş, bu benim vicdanımı da rahatlatıyor.

Veri Yükü: Yalnızca Değerli Bilgileri Topla
Başlangıçta, URL’den gelen her şeyi veritabanına yazmak istedim. Ama sonra Livewire günlüklerinde gezindiğimde, gezegendeki yarısının parametrelerde geçtiğini gördüm ve anladım—veritabanı patlayacak. Bu nedenle, izne dayalı filtreleme uygulamaya karar verdim ve yalnızca konfigürasyonda izin verdiğim verilerin kaydedilmesini sağladım; bu temiz, düzenli ve gereksiz bir kirlilik değildir.

Paket yapılandırmasındaki varsayılan set şu şekildedir:

PHP

'whitelist' => [
    'utm_source',
    'utm_medium',
    'utm_campaign',
    'utm_term',
    'utm_content',
    'ref',
],

Fakat elbette, önce projede yapılandırmayı yayınlayarak bunu değiştirebilirsiniz:

Bash

php artisan vendor:publish --tag="visit-analytics-config"

Bundan sonra, konfigürasyon klasöründe bir visit-analytics.php dosyası belirecektir. Orada, yalnızca izlediğiniz parametrelerin listesini genişletmekla kalmaz (örneğin, bir sayfa veya arama gibi bir şey eklemek) aynı zamanda dışlanmış yolları belirtebilirsiniz; böylece veritabanınızı admin paneli veya teknik uç noktaların günlükleriyle doldurmazsınız.

Peki Sonrası Ne?

Paket çalışmaya başladı ve veriler akmaya başladı. Laptopumu kapatıp yatmaya gittim. Düşünüyorum ki, sabah birkaç arkadaşımın ziyaretçi grafiklerini göreceğim. Ama gerçeklik çok daha zorlayıcı (ve daha ilginç) çıktı.

Bir sonraki bölümde, “ayna’nın” ardına bakacağız: Palo Alto Networks kimdir, neden botlar Hizmet Şartlarımı 7 saniyede okur, ve neden Linux + DuckDuckGo, bir ziyaretçi için kalite rozeti gibidir?