Mobil Uygulamada Hangi Olaylar Ölçülmeli? Firebase Analytics Olay Planı Rehberi

Çoğu ekip Firebase Analytics kurulumunu bir paket ekleyip bırakmak olarak görür. Ancak otomatik toplanan veriler size yalnız kaç kişinin uygulamayı açtığını söyler. Kullanıcının nerede vazgeçtiğini, hangi ekranın para kazandırdığını ya da hangi sürümün elde tutmayı bozduğunu görmek için bir olay planı gerekir.

Talha Aslan ve ekibi olarak mobil projelerde ölçüm planını kodlamadan önce yazıyoruz. Bu rehberde aynı yöntemi adım adım anlatıyoruz:

• Hangi olayların zaten otomatik geldiğini öğreneceksiniz.
• Kayıt, ilk değer, satın alma ve abonelik için hangi olayları eklemeniz gerektiğini göreceksiniz.
• Olay adlandırma kurallarını ve sınırlarını tek tabloda bulacaksınız.
• Kişisel veri göndermeden nasıl ölçüm yapacağınızı ve kurulumu nasıl test edeceğinizi öğreneceksiniz.

Olay (event) nedir, ekran görüntülemeden farkı ne?

Olay, uygulamada belirli bir anda gerçekleşen tek bir hareketin kaydıdır. Örneğin kullanıcının bir ürünü sepete eklemesi, bir videoyu başlatması ya da ödeme ekranını açması birer olaydır. Her olay bir ada ve isteğe bağlı parametrelere sahiptir; parametreler o anın ayrıntısını taşır.

Ekran görüntüleme ise olayların özel bir türüdür. Firebase, ekran geçişlerini screen_view adıyla kendisi kaydeder. Yani hangi ekranın kaç kez açıldığını kod yazmadan görürsünüz. Fakat ekranın açılması, kullanıcının o ekranda bir şey yaptığı anlamına gelmez.

Bir örnekle düşünelim. Ödeme ekranını 1.000 kişi açmış olabilir; ancak kaçının kart bilgisini girdiğini ve kaçının ödemeyi tamamladığını ekran verisi söylemez. Bu nedenle ekran görüntülemeyi bir başlangıç noktası, olayları ise asıl karar verisi olarak düşünmelisiniz. Kısacası ekran sayısı trafiği, olaylar davranışı anlatır.

Web tarafındaki karşılığı merak ediyorsanız GA4 nedir ve neler sunar yazımız aynı olay mantığının web sitelerindeki halini anlatıyor.

Firebase Analytics hangi olayları otomatik toplar?

Firebase Analytics, SDK uygulamaya eklendiği andan itibaren bir grup olayı kod yazmanıza gerek kalmadan kaydeder. Google'ın otomatik toplanan olaylar listesi bu olayları ve hangi platformda çalıştıklarını gösterir. Uygulamalar için en sık kullanacaklarınız şunlardır:

• first_open: kullanıcı uygulamayı kurduktan ya da yeniden kurduktan sonra ilk kez açtığında.
• session_start ve user_engagement: oturum başladığında ve uygulama en az bir saniye ön planda kaldığında.
• screen_view: ekran geçişi olduğunda.
• app_update ve os_update: uygulama ya da işletim sistemi güncellendiğinde.
• in_app_purchase: uygulama içi satın alma tamamlandığında.
• app_remove: uygulama silindiğinde; bu olay yalnız Android'de çalışır.
• notification_open: kullanıcı bir Firebase bildirimini açtığında.

Ayrıca app_exception olayı Crashlytics entegrasyonu ile gelir. Abonelik dönüşümü, yenileme ve iptal olayları ise listeye göre yalnız Google Play tarafında otomatik çalışır. Dolayısıyla iOS'ta aynı bilgiyi görmek için kendi olaylarınızı ya da sunucu tarafı bir çözümü planlamanız gerekir.

Otomatik olaylar neden tek başına yetmez?

Otomatik olaylar her uygulamada aynıdır; sizin iş modelinizi bilmezler. Bir randevu uygulaması ile bir oyun aynı first_open ve session_start verisini üretir. Oysa birinin başarısı randevu oluşturmakla, diğerininki seviye geçmekle ölçülür.

Otomatik verinin cevaplayamadığı birkaç tipik soru şöyle:

• Kayıt formunu açanların kaçı formu tamamladı?
• Kullanıcılar ilk değeri kaçıncı oturumda gördü?
• Ücretli plana geçenler daha önce hangi özelliği kullanmıştı?
• Arama yapan kullanıcı sonuç bulamadığında ne yaptı?

Bu soruların hiçbiri ekran sayısıyla çözülmez. Üstelik otomatik olaylar raporları kalabalıklaştırır; özel olay eklemeden baktığınız her grafik size yalnız trafik hacmini gösterir. Bu yüzden Firebase Analytics kurulumunu iki katmanlı düşünün: alt katmanda otomatik olaylar, üst katmanda iş sorularınıza cevap veren önerilen ve özel olaylar.

Özellikle ilk günlerdeki kaybı anlamak istiyorsanız kullanıcıların uygulamayı neden sildiğini anlattığımız yazı, hangi anları ölçmeniz gerektiğine dair iyi bir kontrol listesi sunuyor.

Önerilen olaylar ile özel olaylar arasındaki fark nedir?

Önerilen olaylar, Google'ın adını ve parametrelerini önceden tanımladığı olaylardır. Örneğin sign_up, login, search, share, add_to_cart, begin_checkout, purchase ve refund bu gruptadır. Bu olayları önerilen adlarla gönderirseniz raporlar onları tanır ve hazır alanlarda gösterir.

Firebase'in olay kaydetme belgesi de aynı yolu önerir: uygulamanıza uyan önerilen olayları, belirlenen parametreleriyle kaydedin. Uygun bir önerilen olay yoksa kendi özel olayınızı tanımlarsınız. Belgedeki örnek, görsel paylaşımını anlatan share_image adlı özel bir olaydır.

Pratikte kural basittir. Önce önerilen listede karşılığı olan bir hareket var mı diye bakarsınız. Varsa onun adını ve parametrelerini aynen kullanırsınız. Yoksa, örneğin randevu oluşturma ya da paywall gösterimi gibi işinize özel bir an için kısa ve açık bir özel ad seçersiniz.

Öte yandan önerilen olayı kendi adınızla yeniden icat etmek sık görülen bir hatadır. Satın almayı order_completed diye kaydederseniz gelir raporları boş kalır. Bu nedenle özel ad vermeden önce mutlaka önerilen listeyi kontrol edin.

Ölçüm planına hangi sorudan başlamalısınız?

Ölçüm planı, olay listesinden değil iş sorularından başlar. Önce uygulamanın başarısını hangi cümleyle tanımladığınızı yazarsınız. Ardından o cümleyi doğrulayacak olayları seçersiniz. Böylece gereksiz olaylarla dolu ama karar üretmeyen bir kurulumdan kaçınırsınız.

Bizim projelerde kullandığımız sıra şöyledir:

1. Uygulamanın tek cümlelik başarı tanımını yazın; örneğin haftada en az bir randevu alan kullanıcı.
2. Bu tanıma giden yolu adım adım listeleyin: kurulum, kayıt, ilk arama, ilk randevu, tekrar randevu.
3. Her adım için bir olay belirleyin ve önerilen listede karşılığı olup olmadığına bakın.
4. Her olayın hangi soruyu cevaplayacağını bir satırla not edin.
5. Olaya eklenecek parametreleri en fazla birkaç tane ile sınırlayın.
6. Planı geliştirici ve pazarlama ekibiyle aynı tabloda paylaşın.

Bu tablo aynı zamanda sürümler arasında ortak dil olur. Yeni bir özellik eklendiğinde önce tabloya satır ekler, sonra kod yazarsınız. Yani ölçüm, ürün geliştirmenin sonradan eklenen bir parçası değil, baştan tasarlanan bir parçası olur. İlk sürümde hangi özelliklerin yer alacağını henüz netleştirmediyseniz mobil uygulama MVP rehberimiz bu karara yardım eder.

Kayıt ve giriş akışını hangi olaylarla izlersiniz?

Kayıt ve giriş için önerilen olaylar sign_up ve login olaylarıdır. İkisi de method adlı bir parametre alır; bu parametre kullanıcının e-posta, telefon ya da bir sosyal giriş yöntemiyle mi geldiğini anlatır. Böylece hangi yöntemin daha çok tamamlandığını karşılaştırırsınız.

Ancak yalnız tamamlanan kaydı ölçmek, kaybın nerede olduğunu göstermez. Bu yüzden akışın başına küçük bir özel olay eklemenizi öneririz. Örneğin kayıt ekranını açan kullanıcı için sign_up_start, doğrulama kodunu isteyen kullanıcı için otp_request gibi kısa adlar yeterlidir.

Örnek senaryo: Kayıt ekranını açanların önemli bir kısmı doğrulama kodu adımında kayboluyor. Bu durumda sorun büyük olasılıkla tasarımda değil, kodun gecikmesinde ya da numara biçimindedir. Olay planı sayesinde ekip doğru yere bakar.

Bir uyarı da ekleyelim. Kayıt olaylarına kullanıcının e-posta adresini ya da telefon numarasını parametre olarak yazmayın. Yöntemi yazmanız yeterlidir; kişiyi değil, davranışı ölçersiniz. Bu konuyu aşağıda kişisel veri başlığında ayrıca ele alıyoruz.

İlk değer anını nasıl ölçersiniz?

İlk değer anı, kullanıcının uygulamanın vaat ettiği faydayı ilk kez somut olarak yaşadığı andır. Bir not uygulamasında ilk notun kaydedilmesi, bir randevu uygulamasında ilk randevunun oluşması, bir alışveriş uygulamasında ilk ürünün favorilere eklenmesi bu ana örnektir. Bu an genellikle tek bir özel olayla ölçülür.

Önerilen listede doğrudan bir karşılığı olmadığı için bu olaya işinize uygun bir ad verirsiniz. Örneğin first_booking_created ya da first_note_saved gibi. Ayrıca bazı ekipler eğitim ekranları için önerilen tutorial_begin ve tutorial_complete olaylarını kullanır; böylece tanıtım akışını bitirenlerle bitirmeyenleri ayırırsınız.

Bu olay neden bu kadar önemli? Çünkü elde tutmayı en çok etkileyen şey, kullanıcının ilk oturumlarda bu ana ulaşıp ulaşmamasıdır. İlk değer olayını ölçtüğünüzde, ona ulaşan ve ulaşmayan kullanıcıların sonraki günlerde nasıl davrandığını karşılaştırabilirsiniz.

Tanıtım ekranlarınızı bu ana göre düzenlemek isterseniz onboarding ekranı tasarımı yazımıza bakın. Orada ilk değere giden yolu kısaltmanın tasarım tarafını anlatıyoruz.

Satın alma ve sepet olaylarını nasıl kurmalısınız?

Satış yapan bir uygulamada önerilen e-ticaret olaylarını sırasıyla kurarsınız: view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_payment_info ve purchase. İade için refund olayını kullanırsınız. Bu sıra, satın alma hunisinin her adımını ayrı ayrı görmenizi sağlar.

Satın alma olayında üç parametre kritik önemdedir:

• transaction_id: aynı siparişin iki kez sayılmasını önler.
• value: siparişin tutarı; gelir raporları bu alandan beslenir.
• currency: para birimi kodu; bu alan eksikse tutar doğru okunmaz.

Ayrıca items dizisi ile ürün adı, kategori ve adet bilgilerini gönderirsiniz. Böylece hangi ürünün ya da kategorinin daha çok satıldığını raporlarda görürsünüz. Ödeme tarafında uygulama içi satın alma ile web ödemesi arasında karar veriyorsanız uygulama içi satın alma ve web ödeme karşılaştırmamız bu seçimin ölçüme etkisini de anlatıyor.

Son olarak purchase olayını yalnız ödeme gerçekten onaylandığında gönderin. Kullanıcı ödeme butonuna bastığında göndermek, başarısız ödemeleri de satış gibi gösterir.

Abonelik uygulamasında hangi olaylar önemlidir?

Abonelik modelinde ölçüm iki parçaya ayrılır: abonelik öncesi karar anları ve abonelik sonrası yaşam döngüsü. Karar anları için paywall_view, plan_select ve trial_start gibi özel olaylar tanımlarsınız. Yaşam döngüsünde ise deneme sürümünden ücretliye geçiş, yenileme ve iptal anlarını izlersiniz.

Google'ın otomatik olay listesine göre app_store_subscription_convert, app_store_subscription_renew ve app_store_subscription_cancel olayları yalnız Google Play tarafında otomatik çalışır. Dolayısıyla iOS'ta aynı yaşam döngüsünü görmek için mağaza bildirimlerini sunucunuzda karşılayıp kendi olaylarınızla eşleştirmeniz gerekir.

Örnek senaryo: Paywall'u gören kullanıcı sayısı yüksek, deneme başlatan sayısı düşük. Bu durumda fiyattan önce paywall'un hangi ekranda ve hangi anda çıktığına bakarsınız. Olay parametresine paywall'un kaynağını (ayarlar, kilitli özellik, ilk açılış) yazmak bu soruyu tek raporda cevaplar.

Abonelik kurgusunun kendisini, yani plan sayısını ve deneme süresi mantığını uygulamada abonelik modeli yazımızda ayrıntılı ele aldık. Burada yalnız ölçüm tarafına odaklanıyoruz.

Olay adlandırmada hangi kurallar işe yarar?

Olay adları büyük küçük harfe duyarlıdır. Yani Purchase ile purchase iki ayrı olay olarak kaydedilir ve raporlarınız bölünür. Google'ın olay adlandırma kurallarına göre adlar harfle başlamalı, boşluk içermemelidir; sayı ve alt çizgi kullanabilirsiniz. Bazı adlar ise sisteme ayrılmıştır.

Aşağıdaki tablo, Google'ın olay toplama sınırları sayfasındaki değerleri ve bizim pratikte kullandığımız adlandırma alışkanlıklarını bir arada gösterir. Sınırlar değişebileceği için güncel değeri resmi sayfadan kontrol edin.

Tablodaki en önemli satır dördüncüsüdür. Her varyasyon için ayrı olay açmak sınırı hızla tüketir; bunun yerine tek olay ve açıklayıcı bir parametre kullanırsınız.

Parametreleri ve kullanıcı özelliklerini nasıl seçmelisiniz?

Parametre, bir olayın bağlamını anlatan ek bilgidir; kullanıcı özelliği ise kullanıcının kendisini tanımlayan kalıcı bir niteliktir. Örneğin paywall_view olayının source parametresi paywall'un nereden açıldığını söyler. plan_type kullanıcı özelliği ise o kişinin ücretsiz mi, premium mu olduğunu taşır.

Firebase belgesine göre özel parametreleri raporlarda görmek için onları konsolda özel tanım (custom definition) olarak kaydetmeniz gerekir. Metin değerleri boyut, sayısal değerler ise metrik olarak tanımlanır. Bu kaydı yapmazsanız veri gelir ama raporda göremezsiniz.

Seçim yaparken şu soruları sorun:

• Bu bilgiyle bir rapor filtrelemek ya da karşılaştırma yapmak istiyor muyum?
• Bilgi her olayda mı değişiyor, yoksa kullanıcıya mı ait?
• Değer, kişiyi tanımlayabilecek bir bilgi içeriyor mu?
• Değerler sınırlı bir listeden mi geliyor, yoksa serbest metin mi?

Serbest metinden kaçının. Örneğin arama terimini olduğu gibi göndermek hem değer sınırını zorlar hem de kullanıcı yanlışlıkla kişisel bilgi yazabilir. Bunun yerine sonuç sayısı ya da kategori gibi sınırlı değerler kullanın.

Huni (funnel) analizi için olayları nasıl dizmelisiniz?

Huni analizi, kullanıcıların bir hedefe giden adımları hangi oranda tamamladığını gösterir. Örneğin uygulamayı açma, ürün görüntüleme, sepete ekleme ve satın alma bir satın alma hunisidir. Her adım bir olaya karşılık gelir; bu yüzden huniyi kurmadan önce olayların eksiksiz olması gerekir.

İyi bir huni için olaylarınız üç şartı karşılamalıdır. Birincisi, adımlar arasında boşluk olmamalı; begin_checkout yoksa sepet ile satın alma arasındaki kaybı göremezsiniz. İkincisi, aynı adım her platformda aynı adla gönderilmeli. Üçüncüsü, olaylar gerçek anı yansıtmalı; ekranın açılması ile butonun çalışması aynı şey değildir.

Örnek senaryo: Android'de sepete ekleme olayı butona basıldığında, iOS'ta ise sepet ekranı açıldığında gönderiliyor. Bu durumda iki platformun hunisi karşılaştırılamaz. Çözüm, olay tetikleme anını ölçüm planında yazılı hale getirmektir.

Huni kavramının pazarlama tarafını ve aşamaların nasıl tanımlandığını dönüşüm hunisi nedir yazımızda anlattık. Uygulama hunisi aynı mantıkla çalışır; yalnız adımlar sayfa yerine olaylardır.

Kohort ve elde tutma ölçümü için hangi olaylar gerekir?

Kohort, aynı dönemde uygulamayı ilk kez açan kullanıcı grubudur. Elde tutma ise bu grubun sonraki günlerde ne kadarının geri döndüğünü gösterir. Firebase bu hesap için first_open ve oturum olaylarını otomatik kullanır; dolayısıyla temel elde tutma eğrisini kod yazmadan görürsünüz.

Ancak temel eğri, yalnız geri dönüşü ölçer. Gerçek soru genellikle şudur: geri dönen kullanıcı değer üreten hareketi tekrar yaptı mı? Bunun için ilk değer olayını ve tekrar eden ana olayı, örneğin booking_created ya da purchase olayını kohort raporunda ölçüt olarak seçersiniz.

Kohortları yorumlarken şunlara dikkat edin:

• Kohortları sürüm tarihine göre ayırın; yeni sürümün etkisini böyle görürsünüz.
• Kampanya dönemlerini ayrı değerlendirin, çünkü reklamla gelen kitlenin davranışı farklıdır.
• Android ve iOS kohortlarını ayrıca karşılaştırın.
• Tek bir kohorta göre karar vermeyin; birkaç haftalık eğilime bakın.

Reklam trafiğinin iOS tarafında nasıl ölçüldüğünü merak ediyorsanız App Tracking Transparency (ATT) yazımız izin penceresinin ölçüme etkisini anlatıyor.

Firebase Analytics olaylarına hangi kişisel verileri göndermemelisiniz?

Google'ın kişisel veri politikası, Analytics'e Google'ın bir kişiyi tanımlamak için kullanabileceği hiçbir veriyi göndermemenizi ister. Örnek olarak e-posta adresi, kişisel cep telefonu numarası ve kimlik numarası sayılır. Bu liste örnek niteliğindedir; tam bir liste değildir.

Uygulamalarda bu kural en çok şu noktalarda ihlal edilir:

• Kayıt olayına e-posta adresini parametre olarak eklemek.
• Arama kutusuna yazılan metni olduğu gibi göndermek.
• Kullanıcı kimliği alanına telefon numarası yazmak.
• Kesin konum bilgisini parametre olarak göndermek.

Politika ayrıca hassas konum verisi göndermeyi de yasaklar. Bunun yerine şehir ya da bölge gibi genel değerler kullanırsınız. Kullanıcıyı ayırt etmeniz gerekiyorsa kendi sisteminizde ürettiğiniz, kişiyi doğrudan tanımlamayan bir kimlik değeri tercih edersiniz.

Hukuki tarafta aydınlatma metni, açık rıza ve izin ekranlarını mobil uygulamada KVKK uyumu yazımızda ele aldık. Bu yazı hukuki danışmanlık değildir; kendi durumunuz için bir hukukçuya danışın.

Mağaza gizlilik beyanları ölçüm planından nasıl etkilenir?

Analitik SDK'sı eklediğiniz anda topladığınız veriyi mağazalara beyan etmeniz gerekir. Google Play Yardım belgesine göre Veri güvenliği formu, üçüncü taraf kütüphane ve SDK'ların topladığı veriyi de kapsar. Uygulama etkinliği kategorisi ve analiz amacı bu beyanın tipik parçalarıdır.

Apple tarafı da benzer bir yol izler. App Store gizlilik ayrıntıları sayfasına göre analiz araçları dahil, uygulamanıza eklediğiniz üçüncü taraf kodun topladığı veriyi de beyan edersiniz. Ürün etkileşimi veri türü ve analiz amacı burada da karşınıza çıkar.

Bu yüzden ölçüm planınız aynı zamanda beyan listenizdir. Yeni bir olay ya da parametre eklediğinizde, beyanın hâlâ doğru olup olmadığını kontrol edersiniz. Ayrıntılı adımlar için Google Play Veri güvenliği formu rehberimize göz atabilirsiniz.

Firebase ile GA4 bağlantısı ne anlama gelir?

Firebase'deki Analytics verisi, Google Analytics altyapısıyla çalışır. Pratikte bu, uygulamanızın verisini bir Google Analytics mülkünde de görebileceğiniz anlamına gelir. Web siteniz aynı mülke bağlıysa uygulama ve web verisini yan yana inceleyebilirsiniz.

Bu bağlantının üç pratik sonucu vardır. Birincisi, önemli olaylarınızı anahtar etkinlik (key event) olarak işaretleyebilirsiniz; Google'ın tanımına göre anahtar etkinlik, işinizin başarısı için özellikle önemli bir hareketi ölçer. İkincisi, kitleler oluşturup reklam ve bildirim hedeflemesinde kullanabilirsiniz. Üçüncüsü, ham veriyi ayrıntılı analiz için BigQuery'ye aktarabilirsiniz.

Otomatik olay listesine göre Google Play'deki abonelik dönüşümü ve yenileme olayları varsayılan olarak anahtar etkinlik sayılır. Diğer önemli olaylarınızı, örneğin ilk randevu ya da satın alma olayını, siz işaretlersiniz.

Anahtar etkinlikler raporda beklenenden az çıkıyorsa nedenleri GA4 dönüşümleri eksik çıkıyor yazımızda topladık.

Firebase Analytics olaylarını yayından önce nasıl test edersiniz?

Firebase Analytics olaylarını yayından önce DebugView ile test edersiniz. DebugView, hata ayıklama modunu açtığınız cihazdan gelen olayları neredeyse anlık gösterir. Böylece olay adının, parametrelerin ve tetikleme anının plana uyup uymadığını kontrol edersiniz.

DebugView belgesine göre Android'de hata ayıklama modunu bir komut satırı ayarıyla, iOS'ta ise Xcode'daki başlatma argümanıyla açarsınız. Test sırasında şu adımları izlemenizi öneririz:

1. Ölçüm planındaki her olayı tek tek tetikleyin.
2. Olay adının yazımını ve büyük küçük harfini kontrol edin.
3. Parametrelerin doğru değeri taşıdığını, boş gelmediğini doğrulayın.
4. Satın almayı test ortamında tamamlayın ve transaction_id alanına bakın.
5. Aynı akışı hem Android hem iOS cihazda tekrarlayın.

Ayrıca belge, hata ayıklama olaylarının günlük BigQuery aktarımına varsayılan olarak dahil olduğunu belirtir. Test trafiğini raporlardan ayırmak için mülkünüzde geliştirici trafiği filtresi tanımlamanızı öneriyoruz.

En sık yapılan olay kurulum hataları nelerdir?

Yıllardır gördüğümüz hataların çoğu teknik değil, planlama kaynaklıdır. Kurulum çalışır ama veri karar üretmez. En sık karşılaştığımız hatalar şunlardır:

• Önerilen olay yerine aynı anlamda özel ad kullanmak.
• Android ve iOS'ta aynı olaya farklı adlar vermek.
• Her ekran ya da buton için ayrı olay açıp sınırı tüketmek.
• Özel parametreleri konsolda tanımlamayı unutmak.
• purchase olayını ödeme onayından önce göndermek.
• Kişisel veriyi parametre ya da kullanıcı kimliği alanına yazmak.
• Test trafiğini canlı raporlardan ayırmamak.

Bunların ortak çözümü yazılı bir ölçüm planıdır. Plan olmadan her geliştirici olayı kendi alışkanlığıyla adlandırır. Dolayısıyla birkaç sürüm sonra aynı hareket üç farklı adla raporda görünür ve geçmiş veriyi birleştirmek zorlaşır.

Bir başka sık sorun da kampanya kaynağının kaybolmasıdır. Kullanıcıyı uygulamada doğru ekrana götüren bağlantılar için deep link rehberimiz kaynağın korunmasına yardım eder.

Örnek senaryo: randevu uygulaması için olay planı

Bir güzellik salonu için randevu uygulaması düşünelim. Başarı tanımı: ilk hafta içinde randevu oluşturan ve sonraki ay tekrar randevu alan kullanıcı. Bu tanıma göre olay planı aşağıdaki gibi şekillenir. Rakamlar ya da sonuçlar değil, yalnız yapı örnektir.

1. first_open ve screen_view: otomatik gelir, ek iş gerekmez.
2. sign_up: method parametresiyle, önerilen olay olarak.
3. search: hizmet kategorisini parametre olarak taşır, serbest metin taşımaz.
4. slot_view: uygun saatlerin listelendiği özel olay.
5. booking_created: ilk değer ve ana olay; anahtar etkinlik olarak işaretlenir.
6. booking_cancel: iptal nedeni sınırlı bir listeden seçilir.
7. notification_open: hatırlatma bildirimlerinin etkisi için otomatik olay.

Bu plan ile ekip üç soruyu cevaplar: kayıt olanların kaçı randevuya ulaştı, randevuya ulaşanlar ne kadar tekrar geldi ve hatırlatma bildirimi iptali azalttı mı. Kısacası yedi olay, ürün kararlarının büyük kısmını besler.

Yayından önce ölçüm kontrol listesi

Uygulamayı mağazaya göndermeden önce ölçüm tarafında şu maddeleri tek tek işaretlemenizi öneririz. Bu liste, yayından sonra geriye dönük veri kaybını önler:

• Ölçüm planı yazılı ve ekiple paylaşılmış.
• Önerilen olaylar önerilen adlarla kurulmuş.
• Özel olay adları kısa, küçük harfli ve iki platformda aynı.
• Özel parametreler konsolda özel tanım olarak kayıtlı.
• Satın alma olayında transaction_id, value ve currency dolu.
• Hiçbir olayda e-posta, telefon ya da kesin konum yok.
• Önemli olaylar anahtar etkinlik olarak işaretli.
• DebugView testi iki platformda tamamlanmış.
• Geliştirici trafiği filtresi tanımlı.
• Mağaza gizlilik beyanları ölçüm planıyla uyumlu.

Bu listeyi her büyük sürümde yeniden gözden geçirin. Çünkü yeni özellikler genellikle yeni olaylar ve yeni beyan ihtiyacı getirir.

Ölçüm planını uygulamayla birlikte kim kurmalı?

En sağlıklı yol, ölçüm planını uygulamayı geliştiren ekiple birlikte kurmaktır. Çünkü olayın hangi anda tetikleneceğine dair kararlar koddaki akışla doğrudan bağlantılıdır. Sonradan eklenen ölçüm, çoğu zaman eksik adımlar ve platformlar arası tutarsızlıkla sonuçlanır.

Talha Aslan ve ekibi olarak mobil uygulama geliştirme projelerinde uygulamanızı biz geliştirir, mağazaya biz çıkarırız. Ölçüm planı da bu sürecin baştan parçasıdır: iş sorularınızı olaylara çevirir, Firebase Analytics kurulumunu yapar, DebugView ile test eder ve mağaza gizlilik beyanlarını planla uyumlu hazırlarız.

Mevcut bir uygulamanız varsa da aynı yöntemi uygularız. Önce mevcut olayları ve adlandırmayı inceler, ardından eksik adımları sürüm sürüm tamamlarız. Kapsamı netleştirmek için mobil uygulama hizmet sayfamızdan teklif almanız yeterlidir.