9 Eylül 2026 Çarşamba

Firebase Analytics Nasıl Çalışır? Oyun İçi Telemetri, Bölüm Döngüleri ve GA4 İlişkilendirmesi




Firebase Analytics Nasıl Çalışır? Oyun İçi Telemetri, Bölüm Döngüleri ve GA4 İlişkilendirmesi

Geleneksel backend, web veya SQL veritabanı geçmişinden geliyorsanız, veri işleme konusundaki zihinsel modeliniz temiz, senkron ve belirlidir:

Kullanıcı Hareketi ──► HTTP POST ──► API Controller ──► SQL Transaction ──► Commit

Veritabanı aracınızı açar, SELECT * FROM Logs WHERE UserId = 123; sorgusunu çalıştırır ve 10 milisaniye içinde yeni kaydınızı ekranınızda görürsünüz.

Ardından, 60 FPS çalışan yüksek performanslı bir mobil oyuna Google Firebase Analytics entegre edersiniz.

Ve birden hiçbir alışkanlığınız çalışmamaya başlar:

  • LogEvent() metodu neden bir HTTP yanıt kodu veya Task döndürmüyor?
  • 10 dakika önce tetiklediğim olay Firebase Konsolu'nda neden görünmüyor?
  • Bir oyun tek bir kare bile takılmadan (FPS düşürmeden) nasıl onlarca silah alımını ve bölüm bitişini kaydedebiliyor?
  • Google Analytics, "roket alma" olayı ile "bölümü bitirme oranını" 24 saat sonra nasıl birbiriyle ilişkilendiriyor?

Firebase Analytics yavaş bir veritabanı veya hatalı bir REST API değildir. Mobil işletim sistemlerinin katı donanım kısıtları için özel olarak tasarlanmış, pil dostu, dağıtık bir olay kuyruğu ve sütun tabanlı veri ambarı hattıdır.

İşte Firebase ve Google Analytics 4'ün (GA4) arka planda nasıl çalıştığına dair kapsamlı teknik mimari.

1. Mobil Donanım İkilemi: 16.6ms Kare Bütçesi ve Hücresel Modemler

MonoGame veya Unity ile geliştirilen 60 FPS bir oyunda, her bir karenin güncellenmesi ve ekrana çizilmesi için toplam süre sınırı yalnızca 16.6 milisaniyedir.

Eğer bir mobil oyun her mermi isabet ettiğinde, düşman öldüğünde veya elmas toplandığında sunucuya anında senkron bir HTTP POST isteği atsaydı:

  1. Kare Donmaları (FPS Düşüşü): Bir TLS el sıkışması ve hücresel bağlantı 80ms ile 800ms arasında sürer. Bunu ana iş parçacığında (UI/Game Thread) çalıştırmak oyunu anında dondurur.
  2. Pil Tüketimi: Telefonların 4G/5G hücresel modemleri yüksek enerji harcar. Küçük bir paket için modemi dakikada 30 kez uyandırmak telefonun şarjını 1 saatte tüketir.
  3. Bağlantı Kopmaları: Telefonlar sürekli tünellere, asansörlere girer. Senkron istekler ya oyunu çökertir ya da devasa veri kaybına yol açar.

Bu gerçekler nedeniyle Firebase Analytics, geleneksel istemci-sunucu modelini tamamen bir kenara bırakır.

2. Cihaz İçi Mimari: Asenkron SQLite Kuyruğu

Firebase SDK'sını projenize eklediğinizde, uygulamanızın içine otonom bir yerel telemetri servisi gömmüş olursunuz:

[ Oyun Döngüsü / GameplayScreen ]
           │
           │  1. LogLevelCompleted() (C# Cephesi)
           ▼
[ Android JNI Köprüsü ]
           │
           │  2. Bellek İçi Paket (< 0.2 ms - Donma Yok!)
           ▼
[ Yerel SQLite Arabellek (google-analytics.db) ]
           │
           │  3. Çevrimdışı olsa bile güvenle diskte saklanır
           ▼
[ Arka Plan Gönderim Servisi ]
           │
           │  Tetikleyici: Uygulama arka plana atılınca (onPause) veya ~60 dk periyot
           │  İşlem: 50-200 olayı topla -> Protobuf Gzip sıkıştır
           ▼
[ Tek Bir Toplu HTTPS POST ] ───► [ Google Telemetri Sunucuları ]
                                                 │
                                                 ▼ (200 OK)
                                    [ Gönderilen Kayıtları SQLite'tan Sil ]

İstemci Tarafındaki Temel Güvenceler:

  • Milisaniye Altı Yazma: LogEvent() çağrısı veriyi bellekteki Android Bundle nesnesine yazar ve arka plan iş parçacığına devreder. İşlem 0.2 milisaniyeden kısa sürer ve sıfır kare kaybı (0 FPS drop) garantisi verir.
  • Önce Çevrimdışı İlkesi (Offline-First): Kullanıcı uçak modundaysa olaylar yerel SQLite veritabanında bekler, hiçbir veri kaybolmaz.
  • Toplu Gönderim (Batching): Olaylar tek tek değil; uygulama arka plana alındığında (onPause) veya belirli saatlik aralıklarla topluca sıkıştırılıp gönderilir.

3. Temiz C# Mimarisi: Oyun Motorunu Bağımsız Kılmak

SOLID ve DRY prensiplerine uygun olarak oyun mantığı doğrudan Firebase SDK'sına bağlanmamalıdır:

[ Oyun Ekranı / LevelManager ]
                │
                ▼
      [ AnalyticsManager.cs ]       <-- Alan Cephesi (Domain Facade)
                │
                ▼
      [ IAnalyticsService ]         <-- Bağımsız Arayüz Sözleşmesi
          ├── [FirebaseAnalyticsService] (Android Canlı Sürüm)
          └── [NullAnalyticsService]     (Masaüstü PC / Birim Testleri)

Örnek C# Olay Gönderimi:

public static void LogLevelCompleted(int level, int score, int totalScore, string rank,
                                     int durationSeconds, int damageTaken,
                                     int blocksBroken, int enemiesKilled, int suppliesCollected)
{
    try
    {
        _payload.Clear();
        _payload[AnalyticsParams.LevelNumber] = level;
        _payload[AnalyticsParams.Score] = score;
        _payload[AnalyticsParams.DurationSeconds] = durationSeconds;
        _payload[AnalyticsParams.DamageTaken] = damageTaken;
        _payload[AnalyticsParams.EquippedGun] = EquippedGun(); // Örn: "rocket", "laser"
        _payload[AnalyticsParams.IsBoss] = IsBossLevel(level) ? 1 : 0;

        // İlgili platform servisine aktarılır (Android'de Firebase, Masaüstünde Null)
        _service.LogEvent(AnalyticsEvents.LevelCompleted, _payload);

        // Oyuncunun ilerleme seviyesini dinamik günceller
        RefreshUserProperties();
    }
    catch (Exception ex)
    {
        Warn(ex);
    }
}

4. Firebase ve Google Analytics 4 (GA4) Farkı Nedir?

Birçok geliştirici Firebase ile Google Analytics'i aynı şey sanır; oysa sistem iki farklı parçadan oluşur:

Bileşen Çalıştığı Yer Temel Sorumluluğu
Firebase Analytics SDK Cihaz Tarafı (İstemci) • Yerel olay kuyruğu ve SQLite tamponu.
• Anonim App Instance ID yönetimi.
• Çevrimdışı dayanıklılık ve toplu paketleme.
Google Analytics 4 (GA4) Bulut Tarafı (Sunucu) • Veri kabul ve temizleme hattı.
• Oturum birleştirme (ga_session_id).
• Özel Tanımlar (Custom Definitions) indeksleme.
• Huni analizleri ve BigQuery aktarımı.

Standart GA4 panolarının verileri yansıtması 12 ila 24 saat sürer; çünkü Google'ın arka uç sunucuları dünya genelindeki milyarlarca olayı gruplamak için zamanlanmış büyük veri işleri (MapReduce) çalıştırır.

5. Özel Tanımlar (Custom Definitions) Neden Şarttır?

Oyununuzdan şu şekilde özel parametreler gönderdiğinizde:

{ "weapon_type", "rocket" },
{ "level_number", 3 }
  1. Google sunucuları bu ham veriyi depolar.
  2. Ancak, siz Google Analytics panelinden Custom Definitions (Özel Tanımlar) alanına girip bu parametreleri tanımlamazsanız raporlarda görünmezler!
  3. Özel bir boyut tanımlamak, arka plandaki BigQuery veritabanına şu emri verir:
    "Bu parametre için özel bir SQL sütunu aç ve indeksle; böylece onu hunilerde filtreleyip analiz edebileyim."

6. İlişkilendirme Motoru: GA4 Olayları Nasıl Birbirine Bağlar?

Google Analytics şu soruyu nasıl yanıtlar?
"Roket alan oyuncuların 3. Bölümü bitirme oranı yüzde kaçtır?"

[ Oyuncunun Oturum Zaman Çizelgesi ]
   ├─ 14:02:10 ─► weapon_collected (weapon_type = "rocket")
   ├─ 14:02:40 ─► screen_view (GameBoard)
   └─ 14:03:30 ─► level_completed (level_number = 3)
                        │
                        ▼
[ GA4 İşleme Motoru (Oturum ve Kullanıcı Eşleme) ]
   • Oyuncu Anahtarı: user_pseudo_id (Rastgele GUID Kimlik)
   • Oturum Anahtarı: ga_session_id (Oturum Zaman Damgası)
                        │
                        ▼
[ Huni Analizi Çıktısı ]
   • 1. Adım: weapon_collected (roket) tetikleyenler ──► 100 Oyuncu (%100)
   • 2. Adım: Ardından level_completed (3) görenler  ──►  78 Oyuncu (%78)
   • Başarı Oranı: Roket Alanlar İçin %78 Başarı!

Her olay anonim user_pseudo_id, ga_session_id ve hassas zaman damgalarıyla etiketlendiği için GA4 geriye dönük olarak oyuncunun tüm hikayesini birleştirebilir.

7. Geliştirici Kasmalarını Önleme: #if !DEBUG Stratejisi

Geliştirme sırasında Visual Studio'dan hata ayıklarken ADB bağlantısı ve yoğun loglama oyunlarda anlık takılmalara yol açabilir:

#if !DEBUG
    // Canlı sürüm: Sıfır gecikmeli, toplu telemetri devrede
    Blocked.Android.Services.FirebaseAnalyticsService.Attach(ApplicationContext, canRequestAds);
#else
    // Hata ayıklama modu: Geliştirme akıcılığını korumak için telemetri devre dışı
    global::Android.Util.Log.Info("Game", "[Analytics] Debug build - Telemetri kapatıldı.");
#endif

8. GDPR, KVKK ve Gizlilik Uyumluluğu

GDPR ve Türk KVKK mevzuatı uyarınca telemetri toplamak açık rıza gerektirir.

Modern oyun mimarisinde:

  1. Uygulama açılışında veri toplama varsayılan olarak kapalıdır (AndroidManifest.xml içinde firebase_analytics_collection_enabled = false).
  2. Google UMP rıza formu gösterilir.
  3. Yalnızca kullanıcı onay verdiğinde toplama açılır: 
    FirebaseAnalytics.GetInstance(context).SetAnalyticsCollectionEnabled(true);
  4. Kullanıcı onayı reddederse, SDK sonraki tüm olayları bellekte düşürür; diske veya internete hiçbir veri yazılmaz.

9. Sonuç

Mobil telemetriye geçiş zihinsel bir dönüşüm gerektirir:

  1. Senkron beklentileri bırakın: Mobil analitik asenkrondur, çevrimdışı önceliklidir ve toplu çalışır.
  2. Yerel tampona güvenin: Sık olay kaydetmek güvenlidir çünkü yerel kuyruk işlemciyi ve pili korur.
  3. Özel Tanımları baştan kaydedin: Parametrelerin raporlara yansıması için bulut tarafında şema indekslemesi şarttır.

Etiketler ve Konular

#OyunGeliştirme #Firebase #GoogleAnalytics #BigQuery #MonoGame #IndieDev #AndroidDev #CSharp #DotNet #OyunTelemetrisi #MobilOyunlar #YazılımGeliştirme #VeriGüvenliği #ArarGames #BlockedPixelPanzer #Mayhemco #PaintTrek #GoogleAds #FirebaseAnalytics #GA4 #SmartBidding #TargetCPA #InAppActions #UserAcquisition




Gönderen zaman:
Etiketler: , , , , , , ,

Hiç yorum yok:

Yorum Gönder

Kaydol: Kayıt Yorumları (Atom)