Oyun Geliştirme etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Oyun Geliştirme etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

21 Eylül 2026 Pazartesi

Yazılım Öldü mü? Gelin Jevons Paradoksu ile Cevap Verelim

Yazılım Öldü mü? Gelin Jevons Paradoksu ile Cevap Verelim

Teknoloji dünyası her birkaç on yılda bir kolektif bir varoluşsal panik dalgasına kapılır.

1950'lerde Fortran gibi yüksek seviyeli derleyiciler çıktığında eleştirmenler "Artık programcılara gerek kalmayacak, makineler kendi kodunu yazacak" demişti. 1990'larda görsel 4GL araçları, sürükle-bırak arayüzler ve ilişkisel veritabanı soyutlamaları popülerleştiğinde "Yazılım mühendisliği miadını dolduruyor" dedikoduları yayıldı. 2000'lerde ise dış kaynak (outsourcing) dalgasının tüm yazılımcıları işsiz bırakacağı iddia edildi.

Bugün aynı kıyamet senaryosu daha önce görülmemiş bir gürültüyle geri döndü: "Üretken yapay zeka artık kod yazıyor. Prompt mühendisliği yazılımcıların yerini alacak. Yazılım öldü."

Sosyal medya yorumcuları ve teknoloji kahinleri boşalan ofisler, anlamsızlaşan bilgisayar mühendisliği diplomaları ve yazılımın yok olduğu bir gelecek kehanetinde bulunuyorlar.

Oysa insan hırsının ve ekonominin 160 yılı aşkın bir süre önce keşfedilmiş en temel kurallarından birini tamamen gözden kaçırıyorlar: Jevons Paradoksu (Jevons Paradox).

Yazılım ölmedi. Tam aksine, insanlık tarihindeki en büyük talep ve üretim patlamasını yaşamak üzere.


1. 1865 Yılından Bir Ders: Jevons Paradoksu Nedir?

1865 yılında İngiliz iktisatçı William Stanley Jevons, Sanayi Devrimi'nin zirvesinde oldukça tuhaf bir olgu fark etti.

James Watt, buhar motorlarında devrim niteliğinde bir verimlilik artışı sağlamış ve bir birim mekanik iş üretmek için gereken kömür miktarını radikal şekilde düşürmüştü. Dönemin genel kamuoyu ve uzmanlar, motorlar artık çok daha az kömür yaktığı için İngiltere'nin toplam kömür tüketiminin hızla düşeceğini öngördü.

Ancak tam tersi oldu.

graph TD
    A["Teknolojik Atılım (James Watt'ın Motoru / Yapay Zeka)"] --> B["Birim Başına Maliyet ve Efor Radikal Şekilde Düşer"]
    B --> C["Ekonomik Olarak Yapılabilir Projelerin Alanı 100 Kat Genişler"]
    C --> D["Yeni Sektörler, Fikirler ve Kullanım Alanları Patlar"]
    D --> E["Toplam Kaynak Tüketimi ve Talep Katlanarak Artar (Jevons Paradoksu)"]

Buhar gücü ucuz, güvenilir ve verimli hale geldiği için; daha önce buhar motoru kullanmayı hayal bile edemeyen binlerce tekstil atölyesi, demir ocakları, buharlı trenler ve transatlantik gemiler bir anda buhar gücüne geçti. Kömür tüketimi azalmadı; katlanarak patladı.

Jevons Paradoksu'nun Temel Kuralı:
Teknolojik ilerleme bir kaynağın kullanım verimliliğini artırdığında, esnek talep nedeniyle o kaynağın toplam tüketimi azalmaz; tam tersine çarpan etkisiyle katlanarak artar.

  1. yüzyılda yazılım kodu yeni kömürdür. Yapay zeka ise James Watt'ın motorudur.

2. Bireysel Gerçeklik: Uykusuz Geceler ve Üretme Arzusu

Yazılımın öldüğünü iddia edenlerin düştüğü en büyük yanılgı, insan zihninin ve yazılım ihtiyacının "sabit bir tavana" sahip olduğunu sanmalarıdır. Şöyle bir senaryo hayal ediyorlar:
"Yapay zeka asistanım günlük işimi sabah 11:00'de bitirdi. O zaman dizüstü bilgisayarımı kapatayım ve günün geri kalanında hiçbir şey yapmadan yatayım."

Gerçek bir üreticiye, gerçek bir geliştiriciye hayatında hiç böyle bir şey oldu mu? Asla.

Son bir-iki yılı düşünün. Kod editörünüze akıllı yapay zeka asistanlarını, otonom ajanları dahil ettiğinizde ne oldu?

İçinizdeki üretme arzusu azaldı mı? Daha mı az çalıştınız?

Tam tersi: Kapasitenizin arttığını gördükçe içinizde öyle bir üretim tutkusu alevlendi ki, uykusuz geceler geçirip sabahlara kadar deliler gibi üretmeye başladınız.

flowchart LR
    Eski["Yavaş İlerleme & Yüksek Sürtünme\n(Eski Yöntem)"] -.-> Yorgunluk["Tükenmişlik & Terk Edilen Fikirler"]
    AI["AI ile Uçuş Hızı\n(Modern Yöntem)"] --> Akis["Anında Çıktı & Üretim Coşkusu"]
    Akis --> Tutku["Görülmemiş Üretim Hırsı\n(Uykusuz Geceler ve Yeni Projeler)"]

Kafanızdaki bir fikir ile ekrandaki çalışan kod arasındaki sürtünme sıfıra yaklaştığında, bu durum tembellik yaratmaz; büyük bir yaratıcılık öforisi doğurur.

Eskiden aylar sürecek bir oyun mekaniğini, özel bir grafik gölgelendiricisini veya arka uç servisini iki gecede çalışır halde görünce saate bakıyorsunuz: Gece 03:30. "Yatayım" demek yerine şunu düşünüyorsunuz:
"Ben bunu iki günde yapabiliyorsam, o zaman şu dinamik hava durumu sistemini de ekleyeyim! Oyunu 64 dile yerelleştireyim! Yanına bir de çok oyunculu sunucu mimarisi kurayım!"

İnsan kapasitesi araçlarla genişledikçe, insanın hayal gücü ve hırsı o yeni kapasiteyi son damlasına kadar tüketmek için genişler. Yazılımcılar işi bırakıp yatmaz; tek bir insanın üretebileceği sınırları gökyüzüne çıkarır.


3. Kurumsal Gerçeklik: Rafta Bekleyen ve Asla Bitmeyen Projeler

Şimdi denkleme patronun, yöneticinin ve şirketin gözünden bakın.

Bazı felaket tellalları, şirketlerin ve CEO'ların yapay zekayı bahane ederek yazılımcıların %80'ini işten çıkaracağını, geriye kalan birkaç kişiye de sadece prompt yazdıracağını iddia ediyor.

Bunu söyleyen bir kişi, hayatında tek bir kurumsal ürün planlama veya IT bütçe toplantısına girmemiştir.

Dünyadaki istisnasız her şirketin çekmecesinde, bütçe ve insan kaynağı yetmediği için yıllardır rafta bekletilen yüzlerce IT projesi vardır. Jira panolarında, Excel tablolarında "Geliştirici kaynağı yetersiz olduğu için ertelendi" etiketiyle çürüyen mobil uygulamalar, otomasyon araçları, veri analiz boru hatları, müşteri portalları ve güvenlik entegrasyonları yığınla beklemektedir.

sequenceDiagram
    participant Patron as Şirket Yönetimi / Patron
    participant Ekip as Yazılım Ekibi
    participant AI as Yapay Zeka Araçları

    Note over Patron,Ekip: Eski Düzen: 10 Proje İstenir, Bütçe Yalnızca 2'sine Yeter
    Patron->>Ekip: "Bu 10 projeyi yapabilir miyiz?"
    Ekip-->>Patron: "Kapasitemiz yılda 2 projeye yetiyor, zaman yok."

    Note over Patron,Ekip: Yapay Zeka ile Jevons Gerçekliği
    Ekip->>AI: Hızı ve kapasiteyi 5 katına çıkarır
    Ekip->>Patron: "O 2 projeyi 2 ayda canlıya aldık!"
    Patron->>Ekip: "Muazzam! O zaman raftaki diğer 8 projeyi indirin, üstüne 15 yeni müşteri entegrasyonu ekliyoruz!"

Bir şirketin patronu, elindeki 5 kişilik yazılım ekibinin yapay zeka ile 5 kat daha hızlı üretebildiğini gördüğünde ne yapar?

  1. 4 yazılımcıyı kovup üretimi aynı düşük seviyede mi tutar?
  2. Yoksa rakiplerinin önüne geçmek için yıllardır bekleyen o 40 projeyi birbiri ardına sahaya mı sürer?

Vahşi rekabetin hüküm sürdüğü bir dünyada cevap her zaman 2'dir.

Patron aynı insan kaynağını işten çıkarmayacak; tam aksine daha çok üretime yüklenecektir. "Madem kapasiteniz arttı, şu projeyi de bitirin, şu entegrasyonu da bağlayın" diyerek personeli daha çok sıkıştıracak, çıtayı yükseltecektir.

Yazılımcılar işlerini kaybetmeyecek; tam tersine, başlarını kaldıracak vakitleri olmadan çok daha devasa sistemleri kurgulamak, yapay zeka ajanlarını orkestre etmek ve görülmemiş hızda ürün çıkarmak için kullanılacaklardır.


4. Yazılım Ölmüyor; Maddenin Hal Değiştirmesi Gibi Şekil Değiştiriyor

"Yazılımın ölümü" efsanesi, klavyede sözdizimi (syntax) yazmak ile yazılım mühendisliği yapmak arasındaki farkı kavrayamamaktan kaynaklanır.

  • Ezbere kod yazmak yazılım mühendisliği değildir.
  • Standart CRUD API uç noktalarını tekrar tekrar dizmek mühendislik değildir.
  • Kütüphane dokümantasyonunu kopyala-yapıştır yapmak mühendislik değildir.

Yazılım mühendisliği; sistem tasarımıdır, mimaridir, veri akışıdır, hata toleransıdır, gecikme optimizasyonudur ve insanın karmaşık ihtiyaçlarını deterministik makine mantığına dönüştürme sanatıdır.

graph LR
    subgraph "Değer Katmanının Değişimi"
        Sozdizimi["Düşük Seviyeli Kod Yazımı\n(Yapay zeka ile metalaştı)"]
        Mimari["Sistem Mimarisi & Alan Tasarımı\n(Değeri 100 Katına Çıktı)"]
        Guvenlik["Uç Durumlar, Doğrulama & Güvenlik\n(İnsan Muhakemesi Şart)"]
    end

Derleyiciler çıktığında makine dili (assembly) yazımı bitti, ama yazılım sektörü bin kat büyüdü. C# ve Python bellek yönetimini otomatikleştirince manuel pointer yönetimi bitti, ama milyonlarca yeni yazılımcı sektöre katıldı.

Yapay zeka sadece yeni bir soyutlama katmanıdır. İnsan mühendis, duvar ören bir işçiden devasa gökdelenlerin baş mimarına ve şantiye şefine dönüşmektedir.


5. Sonuç: Gelecek, Asla Durmayan Üreticilerindir

Yazılım ölmedi. Dünya yazılıma daha önce hiç olmadığı kadar aç.

Cebinizdeki telefondan otonom arabalara, tıp cihazlarından ev aletlerine, şirket içi iş akışlarından eğlence sektörüne kadar her alan daha akıllı, daha sağlam, daha zarif kodlara muhtaç.

Yazılım üretmenin birim maliyeti sıfıra yaklaştıkça, dünyanın tüketeceği toplam yazılım miktarı sonsuza doğru koşacaktır.

Geceleri ekran başında gözleri parlayan tüm geliştiricilere çağrımızdır:

  • Araçlardan korkmayın.
  • Dünün sözdizimi alışkanlıklarının arkasından yas tutmayın.
  • Bu muazzam üretim ateşini arkanıza alın.

Bu değişimi kucaklayan, daha büyük düşünen, daha derin mimariler tasarlayan ve üretmekten asla vazgeçmeyen mühendisler işsiz kalmayacak. Onlar tarihin gördüğü en yüksek hızla yarının dünyasını inşa edecekler.


Arar Games Oyunlarını Keşfedin

Geliştirdiğimiz oyun mekaniklerini ve mühendislik yaklaşımını doğrudan deneyimleyin:

🎮 Blocked: Pixel Panzer

Dinamik ColorWheel cephane sistemi, acımasız boss savaşları, 9 yükseltilebilir tank yeteneği ve 63 dil desteğiyle donatılmış tempolu retro tank nişancı oyunu.

🚀 Paint Trek

Klasik arcade reflekslerini modern .NET 9 performansı, el çizimi grafikler ve tam MSIX paketleme mimarisiyle birleştiren 2D uzay savaşı.


#monogame #blockedpixelpanzer #firebase #painttrek #arargames #jevonssparadox #ai #softwareengineering #dotnet #csharp #indiedev #gamedev #mayhemco

CPI Tuzağından Sadık Oyunculara: Firebase Uygulama İçi İşlemleri ve Google Ads (UAC 2.0) ile Mobil Oyun Büyütme

CPI Tuzağından Sadık Oyunculara: Firebase Uygulama İçi İşlemleri ve Google Ads (UAC 2.0) ile Mobil Oyun Büyütme

Mobil platforma oyun çıkaran her bağımsız (indie) oyun geliştiricisi er ya da geç Yükleme Başına Maliyet (CPI) Paradoksu ile yüzleşir:

Ücretli bir kullanıcı kazanım (UA) kampanyası başlatır, Google Play'de artan indirme sayılarını kutlar ve heyecanla beklersiniz. Fakat 48 saat sonra analitik panelini açtığınızda acı gerçekle karşılaşırsınız:

1.000 İndirme ──► 500 Anında Silme (< 2 dk) ──► 50 Seviye 1 Tamamlama ──► 5 Sadık Oyuncu

Kazanılan kullanıcıların %50'den fazlası daha ilk bölümü dahi bitirmeden oyunu telefonundan silmiştir.

Eğer standart bir Google Ads Yükleme Kampanyası (UAC 1.0 - CPI) yürütüyorsanız, Google'ın makine öğrenimi algoritması tam olarak sizin ona emrettiğiniz şeyi yapmaktadır: "Google Play'de Yükle butonuna basacak en ucuz kişileri bul." Ne yazık ki reklam ağlarındaki en ucuz kullanıcılar genellikle ödüllü reklam avcıları, yanlışlıkla tıklayanlar veya oyununuzla asla derin bir bağ kurmayacak olan kullanıcılardır.

Bu makalede, Arar Games tarafından MonoGame ve C# ile geliştirilen hızlı tempolu retro tank aksiyon oyunumuz Blocked: Pixel Panzer üzerinde kurduğumuz gerçek dünya mühendislik ve pazarlama mimarisini paylaşıyoruz. Cihaz içi telemetriyi Google Analytics 4 (GA4) ve Google Ads Uygulama İçi İşlemler (UAC 2.0) kampanyalarıyla nasıl bağladığımızı; boş indirmelere para saçmak yerine nasıl oyunu gerçekten oynayan kaliteli oyuncuları çektiğimizi tüm adımlarıyla inceliyoruz.


1. Huniyi Teşhis Etmek: Canlı Analitik Bize Ne Öğretti?

Reklam ağlarına tek bir kuruş harcamadan önce oyuncuların nerede döküldüğünü (churn) bilmek zorundasınız.

Blocked: Pixel Panzer oyununda telemetri sistemimiz temel oynanış döngülerini Firebase'e asenkron olarak kaydeder:

  • first_open (ilk açılış)
  • screen_view (40'tan fazla özel MonoGame ekranının takibi)
  • level_completed (level_number, score, duration_seconds parametreleriyle)
  • skill_upgraded (yetenek geliştirme)
  • boss_fight_result (boss savaşı zafer/yenilgi)
  • app_remove (işletim sisteminin oyunu silme sinyali)

GA4 Yol Keşfi (Path Exploration) raporunda oyunu silen kullanıcıları incelediğimizde tablo çok netti:

  • İncelenen silinmiş oturumlarda kullanıcıların yaklaşık 30'u daha Seviye 1'i dahi bitirmeden oyunu silmişti.
  • 14 kullanıcı ilk yeteneklerini geliştirdikten hemen sonra oyun döngüsünden ayrılmıştı.
  • Oyunu silen oyuncuların ulaştığı maksimum nokta ise Seviye 10 (İlk Dünya Boss'u) olmuştu.
[ Oyunu Yükleyenler ] 
       │
       ├──► %48 Churn: Seviye 1 bitmeden silenler <── (CPI İsraf Bölgesi)
       │
       ├──► %30 Etkileşim: Yetenek yükseltip Seviye 2-3'e geçenler
       │
       └──► %22 Sadık Kitle: Boss'a (Seviye 10) ve Meta-Oyuna Ulaşanlar

Çıkarılan ders tartışmasızdı: Yalnızca indirme sayısına para ödemek, bütçeyi doğrudan israf bölgesine dökmektir.

Sürdürülebilir bir oyun ekonomisi inşa etmek için reklam teklif modelimizin; oyunu gerçekten oynayan, Seviye 1'i geçen ve Seviye 3'e doğru ilerleyen oyuncu profillerini optimize etmesi gerekiyordu.


2. UAC 2.0 Mekaniği: Uygulama İçi İşlemlere Odaklanmak

Google Ads Uygulama Tanıtımı Kampanyaları (Universal App Campaigns) temelde farklı optimizasyon modellerine sahiptir:

Kampanya Modeli Teklif Odağı Algoritmanın Öğrendiği Profil En Uygun Olduğu Senaryo
UAC 1.0 (Yüklemeler) Yükleme Hacmi / Hedef CPI Sürekli yeni uygulama indiren kullanıcı profili İlk mağaza lansmanı, hacim patlaması
UAC 2.0 (İşlemler) Hedef EBM (İşlem Başı Maliyet) Belirli bir oyun içi eşiği tamamlayan kullanıcı profili Sürdürülebilir tutundurma, kaliteli oyuncu
UAC 2.5 (Değer / ROAS) Hedef ROAS Uygulama içi satın alma yapan (balina) profili Yoğun mikro ödeme içeren oyunlar

UAC 2.0 (Uygulama İçi İşlemler) modelinde Seviye 1 tamamlama başına bir Hedef EBM (örneğin 6,00 ₺ / ~0.20$) belirlersiniz.

Google'ın Akıllı Teklif (Smart Bidding) sinir ağı; Google Play, YouTube, Google Arama ve AdMob ağındaki milyonlarca uygulamada yüzlerce davranışsal sinyali analiz eder. Reklamı yalnızca geçmiş alışkanlıkları oyunu indirip ilk bölümü başarıyla tamamlayacağını gösteren oyunculara gösterir.


3. Adım Adım Kurulum: C# Telemetriden Google Ads'e

Oyun içi başarıları reklam dönüşüm hedefine dönüştürürken izlediğimiz teknik akış:

Adım 1: Cihaz Tarafı Telemetri Kancası (MonoGame / C#)

Blocked.Shared/Managers/AnalyticsManager.cs dosyasında oyuncu bir bölümü temizlediğinde skor ve süre hesaplanır; 60 FPS render döngüsünü aksatmadan level_completed olayı ateşlenir:

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.TotalScore] = totalScore;
        _payload[AnalyticsParams.DurationSeconds] = durationSeconds;
        _payload[AnalyticsParams.IsBoss] = IsBossLevel(level) ? 1 : 0;
        
        // Android Firebase SDK'sına JNI üzerinden iletilir (kasmayan SQLite tamponu)
        _service.LogEvent(AnalyticsEvents.LevelCompleted, _payload);
    }
    catch (Exception ex)
    {
        // Telemetri asla oyunu çökertecek bir hataya yol açmamalıdır
        Warn(ex);
    }
}

Adım 2: GA4 Özel Etkinlik Türetme (Kod Güncellemesi Gerekmez)

Google Ads doğrudan level_completed WHERE level_number == 1 gibi parametre alt sorgularını hedefleme seçeneği olarak sunmaz. Ancak Google Analytics 4 (GA4), mağazaya yeni güncelleme göndermeden panel üzerinden yeni etkinlik türetmeye imkan tanır:

  1. GA4 Konsolunda Yönetici ➔ Veri görünümü ➔ Etkinlikler yolunu izleyin.
  2. Etkinlik oluştur butonuna tıklayın:
    • Özel etkinlik adı: level_1_completed
    • Eşleşme koşulları:
      • event_name equals level_completed
      • level_number equals 1
    • Skor ve süre verilerinin korunması için "Copy parameters from the source event" kutusunu işaretleyin.
  3. Kaydedin.
  4. Önemli olaylar (Key events) sekmesinde level_1_completed olayının yanındaki Yıldızı (⭐) aktif hale getirin.

Artık dünyanın neresinde bir oyuncu Seviye 1'i tamamlarsa GA4 bunu bağımsız bir dönüşüm olayı olarak kaydeder.

Adım 3: Dönüşümün Google Ads'e Aktarılması

  1. Google Ads (ads.google.com) paneline gidin.
  2. Hedefler ➔ Dönüşümler ➔ Özet sekmesine geçin.
  3. Yeni dönüşüm işlemi ➔ İçe Aktar ➔ Google Analytics 4 mülkleri (Firebase) seçeneğini seçin.
  4. Listeden level_1_completed olayını seçip kategorisini Level achieved (Seviyeye ulaşıldı) veya Engagement olarak belirleyin.
  5. İşlemi Birincil (Primary) olarak işaretleyin; böylece reklam algoritması tekliflerini bu olaya göre optimize eder.
[ Mobil Oyun: Seviye 1 Tamamlandı ]
                │
                │  LogEvent("level_completed", { level_number: 1 })
                ▼
[ Firebase Analytics Motoru ]
                │
                │  GA4 Kuralı: "level_1_completed" sentezlenir
                ▼
[ GA4 Önemli Olay (Dönüşüm) ]
                │
                │  Google Ads Entegrasyonu
                ▼
[ Google Ads Akıllı Teklif Motoru (UAC 2.0 Hedef EBM) ]

4. Soğuk Başlangıç Problemini Aşmak: Huni Stratejisi

Geliştiricilerin UAC 2.0'a geçerken en sık yaptığı hata, doğrudan oyunun çok ileri bir aşamasını hedef seçmektir.

Makine Öğreniminin Hacim Kuralı

Google Ads Akıllı Teklif algoritmalarının sağlıklı eğitilmesi için belirli bir veri eşiği gerekir:

  • Kritik Kural: Bir kampanyanın "Öğrenme Süreci"nden başarıyla çıkıp kararlı çalışabilmesi için günde en az 10 ila 20 hedef dönüşüm toplaması önerilir.

İlk analizimizde Seviye 3 ve üzerini geçen oyunculardan oluşan Quality_Players_Level_3 adında bir kitle oluşturmuştuk ve bu kitlede 17 kullanıcı birikmişti.

Eğer doğrudan Seviye 3 hedefli bir kampanya başlatsaydık:

  • Günde 15 kişinin Seviye 3'e ulaşmasını sağlamak çok yüksek bir bütçe gerektirirdi.
  • 17 kişilik dar bir örneklemle yapay zeka genelleme yapamaz, hedefleme tıkanır veya gösterim dururdu ("Too small to serve").

Kademeli Huni Çözümü

[ 1. Aşama: Seviye 1 Tamamlama ] ──► Düşük maliyetle kaliteli oyuncu çekilir
                 │
                 └──► İlk dakikada silen çöp kitle tamamen elenir
                                   │
                                   └──► "Quality_Players_Level_3" havuzu hızla 100+ kişiye ulaşır
                                                     │
                                                     └──► [ 2. Aşama: Hedef Seviye 3'e Kaydırılır ]
  1. 1. Aşama (Hacim ve Temizlik): Hedef = level_1_completed. Gerçek oyuncuların %50-60'ı Seviye 1'i geçtiği için kampanya düşük maliyetle (örneğin 5-7 ₺ / ~$0.18) günde 20-30 dönüşümü rahatlıkla toplar. Bu aşama oyunu indirip açmayan botları ve çöp kitleyi anında filtreler.
  2. 2. Aşama (Rafine Etme): Seviye 1'i geçen yüzlerce oyuncunun bir kısmı Seviye 3, 5 ve 10'a ilerler. Quality_Players_Level_3 kitle havuzu 100-200 kişiyi aştığında kampanya hedefi doğrudan Seviye 3'e veya yetenek yükseltmelerine (skill_upgraded) kaydırılır.

5. Pazar Seçimi ve Coğrafi Denge

İlk testlerde doğrudan ABD, İngiltere veya Almanya gibi 1. Seviye (Tier-1) pazarlara girmek küçük bütçeleri saatler içinde eritebilir ($2.00 - $5.00 işlem maliyeti).

Blocked: Pixel Panzer için hem bütçe dostu hem de piksel aksiyon türüne yoğun ilgi gösteren 4 stratejik pazar seçtik:

  1. Türkiye (TR): Güçlü yerel oyuncu tabanı, arcade türüne sevgi ve ekonomik maliyetler.
  2. Brezilya (BR): Dünyanın en büyük Android oyun pazarlarından biri. Retro tank savaşlarına ve piksel estetiğine büyük ilgi duyarlar.
  3. Meksika (MX): Latin Amerika'nın ikinci büyük merkezi; sadık oyuncu toplulukları ve yüksek indirme hacmi sunar.
  4. Polonya (PL): Harika bir Avrupa test pazarı. AdMob reklam getirisi (eCPM) Latin Amerika'dan belirgin şekilde yüksektir, ancak reklam verme maliyeti Batı Avrupa'ya kıyasla çok daha dengelidir.

Yerel Dil Desteğinin Önemi

Yabancı pazarlarda reklam vermek ancak oyun içi deneyim oyuncunun diline hitap ediyorsa yüksek dönüşüm getirir. Blocked: Pixel Panzer bu 4 pazarı da tam yerelleştirme ile karşılar:

  • tr.json (Türkçe)
  • pt-BR.json (Brezilya Portekizcesi)
  • es-419.json (Latin Amerika İspanyolcası)
  • pl.json (Lehçe)

Konum Hedefleme İpucu: Google Ads konum ayarlarında varsayılan "Varlık veya ilgi alanı" yerine mutlaka "Varlık: Dahil ettiğiniz konumlarda bulunan veya bu konumlara düzenli olarak giden kişiler" seçeneğini işaretleyin. Böylece bütçeniz yabancı VPN'ler veya alakasız aramalara değil, doğrudan bu ülkelerde yaşayan gerçek oyunculara harcanır.


6. Reklam Görselleri: Video Resimlerin Önüne Geçer mi?

Geliştiricilerin en çok tereddüt ettiği konulardan biri: "Oynanış videosu eklersem hazırladığım görsellerin gösterimini engeller mi?"

Cevap: Kesinlikle hayır. Google Ads çok kanallı envanter mantığıyla çalışır:

  • Başlıklar ve Resimler: Google Play arama sonuçlarında, önerilen oyunlar vitrininde ve diğer uygulamaların banner alanlarında gösterilir.
  • Video: Görsellerin hiç giremediği devasa YouTube (YouTube Shorts, video arası reklamlar) ve diğer mobil oyunlardaki ödüllü video alanlarını açar.

Aksiyon odaklı oyunlarda durağan bir görsel tankı gösterir; ancak tankın ateş ettiğini, mermilerden kaçtığını ve boss'larla kapıştığını yalnızca video hissettirebilir. Oynanışı izleyerek gelen oyuncu oyunu ilk dakikada silmez; Seviye 1 tamamlama oranı çok daha yüksek olur.


7. Bağımsız Geliştiriciler İçin Özet Kontrol Listesi

Bir sonraki mobil oyun reklam kampanyanızı açmadan önce şu adımları tamamladığınızdan emin olun:

  • Oyun İçi Telemetri: level_completed olayının sıfır bellek tahsisiyle (GC-free) sorunsuz gönderildiğinden emin olun.
  • GA4 Dönüşüm Sentezi: level_1_completed olayını GA4 panelinde oluşturup Önemli Olay (Key Event) olarak işaretleyin.
  • Google Ads İçe Aktarma: İşlemi Google Ads'e aktarın ve Birincil hedef yapın.
  • Teklif Odağı: İndirme sayısı yerine Uygulama İçi İşlemler (Hedef EBM) seçin.
  • Kademeli Huni: Önce Seviye 1 ile hacim ve veri toplayın; kitle havuzu olgunlaşınca hedefi Seviye 3'e yükseltin.

Reklam stratejinizi "indirme satın almak" yerine "oynanış eşiği satın almak" olarak değiştirdiğinizde, pazarlama bütçeniz tahmin edilemeyen bir masraf olmaktan çıkıp sadık bir oyuncu büyüme motoruna dönüşür.


Arar Games / Mayhemco mühendislik ekibi tarafından kaleme alınmıştır. Retro arcade savaş dinamiklerimizi ilk elden deneyimlemek için Google Play üzerinden Blocked: Pixel Panzer oyunumuzu inceleyebilirsiniz.


Hashtags & SEO Topics

#BlockedPixelPanzer #ArarGames #Mayhemco #PaintTrek #MonoGame #GoogleAds #FirebaseAnalytics #GA4 #MobileGameDev #UserAcquisition #GameMarketing #SmartBidding #TargetCPA #InAppActions #IndieGameDev #GameAnalytics #AndroidDev

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