Tracking plan ve governance · Amplitude öğrenme kılavuzu

Bu bölümün sonunda

Bir tracking plan satırının hangi alanları içermesi gerektiğini bileceksin.
Tutarlı bir isimlendirme kuralı kurabileceksin.
Planı yayından önce doğrulayıp yayından sonra koruyacak bir döngü kurabileceksin.

Plan neden önce gelir?

Disiplinsiz projelerde event adı sayısı zamanla büyür, ama soru sayısı büyümez. Aynı eylem üç farklı adla gelir, her biri chart'larda ayrı görünür ve kimse hangisinin doğru olduğunu bilmez.

Farklı event adı sayısı, ay ay. örnek veri Plansız projede her sürüm yeni adlar ekler (yazım farkları, platform farkları, deneme event'leri). Planlı projede sayı ancak yeni bir soru ortaya çıktığında artar.

Plan döngüsü

Doğrulamada bulunan hata planı mı, kodu mu düzeltir? Plan yanlışsa plana, kod yanlışsa geliştirmeye dönülür. Plan her zaman tek doğru kaynak olarak kalır.

Bir plan satırı neleri içerir?

Alan	Örnek	Neden gerekli
Event adı	`Checkout Completed`	Tüm platformlarda tek ad
Tetiklenme anı	Ödeme onay ekranı ilk kez göründüğünde, sipariş başına bir kez	Geliştirici ve analist aynı anı kastetsin
Kaynak	Sunucu (HTTP API), backend ödemeyi doğruladıktan sonra	Çift sayımı önler
Event property'ler	`order_id` string, `revenue` number, `currency` string (ISO 4217)	Tip ve format sabitlenir
Güncellenen user property'ler	`orders_count` add 1	Sıralama hatalarını önler
Platformlar	iOS, Android, web	Eksik platform görünür olur
Hizmet ettiği soru	Sepetten ödemeye dönüşüm, gelir analizi	Gereksiz event'ler elenir
Adjust karşılığı	Event token `abc123` (S2S)	İki aracın tutarlılığı izlenir

İsimlendirme kuralı

Hangi kuralı seçtiğin, tek kural seçmekten daha az önemlidir. Yaygın ve okunaklı bir seçim: event adlarında Nesne + geçmiş zaman fiil, Title Case (Product Viewed); property adlarında snake_case (product_id).

Aynı eylem, üç event

product_view (Android)
ProductView (iOS)
viewed product (web)
Product Viewed - Shoes, Product Viewed - Bags (kategori adın içinde)

Tek event, zengin property

Product Viewed her platformda
category: "shoes" property olarak
Sabit değer listesi: shoes, bags, accessories
Platform bilgisi SDK'dan otomatik gelir, adda tekrar edilmez

İpucu

Az event, zengin property ilkesi chart kurmayı da kolaylaştırır: "kategoriye göre ürün görüntüleme" tek bir chart'ta tek bir kırılımdır. Kategori başına event açılırsa her yeni kategori kod değişikliği ve yeni chart demektir.

Örnek plan: e-ticaret uygulaması

Event	Tetiklenme	Kaynak	Event property'ler	User property etkisi
`Onboarding Step Viewed`	Her onboarding ekranı göründüğünde	SDK	`step_number` number, `step_name` string	–
`Signup Completed`	Hesap oluşturulduğunda	SDK	`method` string	`signup_date` setOnce
`Search Performed`	Arama sonucu listelendiğinde	SDK	`query_length` number, `results_count` number	–
`Product Viewed`	Ürün detay ekranı açıldığında	SDK	`product_id`, `category`, `price` number, `source` string	–
`Product Added to Cart`	Sepete ekleme başarılı olduğunda	SDK	`product_id`, `category`, `price`, `quantity`	–
`Checkout Started`	Ödeme ekranı açıldığında	SDK	`cart_value` number, `items_count` number	–
`Checkout Completed`	Ödeme backend'de doğrulandığında	HTTP API	`order_id`, `revenue`, `currency`, `payment_method`	`orders_count` add 1
`Push Opened`	Bildirime dokunulduğunda	SDK	`campaign_id` string	–
`Subscription Started`	İlk abonelik doğrulandığında	HTTP API	`plan`, `period`, `revenue`	`plan` set (event'ten önce)
`Subscription Renewed`	Mağaza yenileme bildirimi geldiğinde	HTTP API	`plan`, `period`, `revenue`	–

source gibi property'ler (ürüne nereden gelindi: arama, ana sayfa, push) funnel ve path analizlerini çok güçlendirir. Plan yazılırken sorulması gereken soru: "Bu event'i hangi açılardan bölmek isteyeceğim?"

Doğrulama listesi

Her yeni sürümden önce test projesinde şu kontroller yapılır:

Event adı plandaki ile birebir aynı (büyük/küçük harf ve boşluk dahil).
Tüm property'ler geliyor ve tipleri doğru (sayılar sayı, boolean'lar boolean).
Event planda yazan anda ve beklenen sayıda tetikleniyor (tek sipariş, tek event).
User property güncellemesi event'ten önce mi sonra mı, plandaki sıra ile aynı.
Login sonrası user_id doğru, logout sonrası sıfırlanıyor.
Sunucu event'leri doğru kullanıcıya bağlanıyor ve tekrar gönderimde çift sayılmıyor.
Production build production API key'ini, test build test key'ini kullanıyor.
Aynı event'in Adjust karşılığı da tetikleniyor (gerekiyorsa).

Bu kutular sayfayı yenileyince sıfırlanır; kendi kontrol listen için kopyalayabilirsin.

Yayından sonra: governance

Plan dışı veri yine de gelecektir: eski sürümler, unutulmuş deneme event'leri, yazım hataları. Amplitude'un veri yönetimi araçlarıyla bunlara dört şey yapılabilir:

İşlem	Ne yapar	Ne zaman
Gizleme	Event'i arayüzde göstermez, veri durur	Artık kullanılmayan ama geçmişi korunacak event'ler
Engelleme	Gelecekte gelen bu event'i işlemez	Test veya hatalı event'ler
Birleştirme / dönüştürme	Farklı adları analizde tek event gibi gösterir	`product_view` ve `Product Viewed` gibi geçmiş yazım farkları
Plana göre doğrulama	Plan dışı event ve property'leri işaretler	Sürekli kalite takibi

Doğrula

Bu işlemlerin Amplitude'daki güncel adları, hangisinin geriye dönük uygulandığı ve hangi planda olduğu değişebilir. Özellikle "engelleme"nin geçmiş veriye dokunup dokunmadığını müşteriye söylemeden önce kontrol et.

Adjust tarafında

Adjust'ta event token listesi zaten doğal bir tracking plan'dır: token olmadan event gönderilemez. Amplitude'da bu listeyi kendin tutman gerekir. En pratik yol, iki aracın event'lerini aynı tabloda tutmak: bir kolon Amplitude adı ve property'leri, bir kolon Adjust token'ı ve parametreleri. Böylece bir event bir araçta eklenip diğerinde unutulduğunda hemen görünür.

Alıştırma

Bir müşterinin mevcut Adjust event listesinden başlayarak yukarıdaki şablonla bir tracking plan taslağı yaz. Her event için "hizmet ettiği soru" kolonunu doldur. Bu kolonu dolduramadığın event'ler, Amplitude'a taşınmaya değmeyebilir.