Mobil Analitik ve Gizlilik: Olay Taksonomisi Kurmak

1. Ekranlardan Değil Karar Sorularından Başlayın

Önce ekibin önümüzdeki çeyrekte vereceği kararları yazın. Yeni kullanıcılar hangi temel değere ulaşamıyor? Arama mı kategori gezinmesi mi daha etkili? İzin ekranı görev tamamlamayı etkiliyor mu? Hangi hata ödeme akışını durduruyor? Bir sorunun olası kararı yoksa onu ölçmenin önceliğini sorgulayın. Analitik, merak arşivi değil ürün yönetimi aracıdır.

Her soru için davranış zincirini tanımlayın: başlangıç koşulu, kullanıcının niyetini gösteren eylem, başarı sonucu ve kabul edilebilir süre. Uygulama açılışı bir hedef değildir; rezervasyonun onaylanması veya ilk dosyanın çevrim dışı kaydedilmesi hedef olabilir. Ekran görüntüleme bağlam sağlar, fakat gerçek değeri temsil eden olayla ilişkilendirilmelidir.

Son olarak dengeleyici metrik ekleyin. Daha fazla bildirim izni almak iyi görünürken uygulama kaldırma veya şikâyet artabilir. Daha kısa checkout, yanlış siparişi çoğaltabilir. Hız metriğini hata, iptal ve destek sinyaliyle birlikte okuyun.

2. Olay Sözlüğünü Fiil, Nesne ve Bağlamla Tasarlayın

Adlandırma düzeni kısa, tutarlı ve teknoloji bağımsız olsun. `product_viewed`, `search_submitted`, `payment_failed` gibi geçmiş zamanlı fiil-nesne yapısı olayın gerçekleştiğini anlatır. Ekran veya buton metnini doğrudan olay adı yapmak, arayüz değişince analitik anlamını bozar. Dil seçin ve tüm platformlarda aynı sözlüğü kullanın; büyük-küçük harf ile tekil-çoğul farklarını yeni olay saymayın.

Parametreler olayı açıklamalıdır, kullanıcıyı yeniden tanımlamak için gereksiz ayrıntı taşımamalıdır. `payment_failed` için hata sınıfı, ödeme yöntemi kategorisi ve akış sürümü yararlı olabilir; tam kart verisi, serbest metin hata mesajı veya kişisel bilgi değildir. Serbest metin alanları beklenmedik hassas veri taşıyabilir. İzin verilen değerleri sözlükle sınırlandırın.

Her kayıtta açıklama, tetikleme kuralı, zorunlu parametreler, örnek, platform, sahip, ilk sürüm, saklama sınıfı ve test kimliği yer alsın. Değişiklik için sürüm notu tutun; mevcut olayın anlamını sessizce değiştirmek zaman serisini kırar.

3. Gizlilik Sınırını SDK'dan Önce Çizin

Veri envanterini olay sözlüğüne bağlayın. Her alan için amaç, gereklilik, saklama süresi, erişen ekipler, aktarılan hizmetler ve silme yöntemi belgelenmelidir. 'İleride lazım olabilir' ölçüm amacı değildir. Toplanmayan veri sızmaz, yanlış segmente girmez ve gereksiz bakım yaratmaz. Ürün sorusunu toplulaştırılmış veya cihaz üzerinde hesaplanan veriyle cevaplayabiliyorsanız daha ayrıntılı kimlik toplamayı tercih etmeyin.

Apple'ın resmi App Tracking Transparency belgesi, uygulama veya cihaz verisi başka şirketlerin uygulama ve siteleri arasında takip amacıyla kullanılıyorsa ATT çerçevesiyle izin istenmesi gerektiğini belirtir. Apple ayrıca üçüncü taraf SDK kodu ve veri uygulamalarından geliştiricinin sorumlu olduğunu açıklar. Analitik ile reklam takibini aynı kavram sanmayın; kullandığınız SDK'nın gerçek veri akışını ve amacı teknik olarak inceleyin.Apple Developer — User Privacy and Data Use

Platform izni, yürürlükteki veri koruma yükümlülüklerinin yerine geçen genel onay değildir. Hukuki rol, dayanak, bilgilendirme ve hak talepleri ülke ile işleme amacına göre değişir; gizlilik ve hukuk uzmanlarıyla doğrulayın. Tasarımda reddetme ve sonradan değiştirme yollarını çalışır tutun.

4. Varsayımsal Senaryo: Teslimat Uygulamasında Olayları Sadeleştirmek

Bu senaryo varsayımsaldır; gerçek ürün sonucu değildir. Bir teslimat uygulamasında iOS ekibi 140, Android ekibi 95 özel olay göndermektedir. Aynı adres ekleme akışı platformlarda farklı adlarla ölçülür; bazı olaylarda tam hata mesajı, bazılarında yazılan adresin bir bölümü bulunmaktadır. Ürün ekibi onboarding kaybını açıklayamıyor çünkü ekran açılışı ile başarı arasındaki kurallar tutarsızdır.

Ekip önce karar sorusunu daraltır: Kullanıcı teslimat adresini neden doğrulayamıyor? Ortak sözlükte `address_started`, `address_validation_failed` ve `address_saved` olayları tanımlanır. Hata parametresi `network`, `unsupported_area`, `missing_field` gibi sınırlı kategorilere dönüşür; adres ve serbest metin kaldırılır. Akış sürümü ile çevrim içi durum eklenir. Her iki platform aynı test vakalarını çalıştırır.

Yeni sözlük eski panellere doğrudan karıştırılmaz. Bir geçiş döneminde sürüm etiketiyle paralel doğrulama yapılır, ardından eski olaylar planlı biçimde kullanımdan kaldırılır. Karar yalnız dönüşüm oranına bakmaz; doğrulama gecikmesi, teknik hata, destek başvurusu ve veri reddi birlikte incelenir. Taksonomi sadeleşmesinin başarı garantisi yoktur; asıl kazanım metriğin ne anlama geldiğinin tekrar güvenilir olmasıdır.

5. Uygulamayı Kod İncelemesi ve Veri Kalite Kapısıyla Yönetin

Firebase Analytics'in resmi olay rehberi otomatik ve önerilen olayların yanında özel olayların kaydedilebildiğini, olay adlarının büyük-küçük harfe duyarlı olduğunu ve önerilen olaylarla tanımlı parametrelerin rapor özelliklerinden daha iyi yararlanmayı sağladığını açıklar. Platform sınırları sürüme göre değişebileceğinden güncel belgeyi kontrol edin; geniş isim kotası, yüzlerce olayı gereksizce üretme hedefi değildir.Firebase Documentation — Log events

Analitik çağrılarını ekran koduna dağınık biçimde serpiştirmeyin. Tip güvenli bir olay katmanı, izin verilen ad ve parametreleri merkezi olarak doğrulayabilir. Geliştirme ortamında şema dışı olayı reddedin; üretimde hata kaydı ve örnekleme politikası kullanın. iOS ve Android aynı sözlükten kod veya test fikstürü üretebiliyorsa sapma azalır.

Kalite testi üç seviyede yapılır: birim test tetikleme kuralını, entegrasyon testi yükü, uçtan uca test gerçek kullanıcı akışını doğrular. Debug görünümünde gelmesi yeterli değildir; veri ambarında tür, zaman, tekrar, izin durumu ve oturum ilişkisi de kontrol edilmelidir.

• Olay adlarını şema doğrulamasından geçirin.
• Zorunlu ve yasak parametreler için otomatik test yazın.
• Aynı kullanıcı eyleminde tekrar olay oluşmasını kontrol edin.
• İzin reddinde SDK ve ağ davranışını gerçek cihazda inceleyin.
• Sürüm sonrası veri hacmi ve boş parametre alarmı kurun.

6. Sekiz Haftalık Taksonomi ve Yönetişim Planı

İlk iki haftada mevcut SDK, olay, parametre, panel ve alıcıları envanterleyin. Üçüncü hafta en önemli ürün kararlarını ve temel kullanıcı yolculuklarını seçin. Dördüncü haftada adlandırma, veri sınıfları ve olay sahipliği standardını kabul edin. Beş ve altıncı haftalarda bir kritik akışı iki platformda uygulayıp otomatik testleri kurun. Son iki haftada veri ambarı doğrulaması, eski olay geçişi ve erişim denetimini tamamlayın.

Yönetişim ağır bir kurul olmak zorunda değildir. Yeni olay önerisi karar sorusu, mevcut olayla fark, parametre gereksinimi ve gizlilik incelemesiyle kısa bir şablondan geçebilir. Haftalık değişiklik kaydı ve aylık kullanılmayan olay incelemesi sözlüğü canlı tutar.

• Her olayın yanıtladığı ürün kararı belli.
• Tetikleme anı ve başarı koşulu test edilebilir biçimde yazılı.
• Parametreler kontrollü değer sözlüğü kullanıyor.
• Kişisel veya hassas serbest metin gönderilmiyor.
• SDK veri akışı ve üçüncü taraf alıcıları belgeli.
• iOS ve Android aynı sözlük sürümünü kullanıyor.
• Eski olaylar için geçiş ve kapatma tarihi bulunuyor.

7. Sınırlar ve Başarısızlık Modları: Ölçülen Davranış Niyet Değildir

Olay verisi ne olduğunu gösterebilir; çoğu zaman nedenini tek başına açıklamaz. Kullanıcı aramayı terk ettiğinde sonuç kalitesi, ağ gecikmesi, dikkat bölünmesi veya ihtiyacın değişmesi etkili olabilir. Analitiği kullanılabilirlik testi, görüşme, destek kaydı ve performans verisiyle birleştirin. Korelasyonu nedensellik gibi sunmayın.

Kimlik ve ilişkilendirme eksik olabilir. Kullanıcı cihaz değiştirir, izni reddeder, uygulamayı siler veya çevrim dışı olaylar gecikmeli gelir. Aynı kişi birden fazla örnek gibi; farklı kişiler ortak cihazda tek kişi gibi görünebilir. Panelde kapsam, gecikme ve hariç tutma kurallarını gösterin. Veri kalitesi düştüğünde kesin oran yerine aralık ve belirsizlik belirtin.

Son başarısızlık biçimi, taksonominin yaşayan ürün yerine dokunulmaz sözlüğe dönüşmesidir. Anlamı bozacak değişiklikte yeni sürüm açın; kullanılmayan olayları kaldırın; kritik iş sonuçlarını düzenli denetleyin. Daha fazla veri değil, güvenilir ve amaçla sınırlı veri daha iyi karar üretir.