Product Metric'leri: North Star, HEART ve AARRR

Sürüm notu: Bu yazı kavramsaldır; North Star için Amplitude'un "The North Star Playbook" rehberi, HEART (Happiness, Engagement, Adoption, Retention, Task success) için Rodden, Hutchinson ve Fu'nun Google'daki CHI (Conference on Human Factors in Computing Systems) 2010 makalesi esas alınmıştır.

Önce Tahmin Et

Bookstore'un aylık yönetim toplantısında ilk slayt hep aynı: "Kayıtlı kullanıcı sayısı 48.000, geçen aya göre %6 artış." Grafik yukarı doğru gidiyor, herkes memnun. Aynı ay, 07. yazıda SQL (Structured Query Language) ile hesaplayacağımız funnel'a göre sepet terk oranı %66,7 ve yeni kayıt olanların yalnız %37–43'ü bir sonraki hafta siteye geri dönüyor.

Kayıtlı kullanıcı sayısındaki %6'lık artış iyi bir haber mi? Bu sayı, ekibin geçen ay yaptığı işin iyi olup olmadığını söyler mi? Bir de şunu düşün: bu sayının hiç düşmesi mümkün mü? Düşmesi mümkün olmayan bir metric sana ne anlatır?

North Star Metric

Bir ürün ekibinin onlarca metric'i olabilir, ama ekiplerin aynı yöne çekmesi için bir tanesinin diğerlerinden önemli olması gerekir. Amplitude'un "The North Star Playbook" rehberinin önerdiği North Star metric, ürünün müşteriye sağladığı temel value'yu en iyi yakalayan tek metric'tir. Rehber bu metric'in hem müşterinin aldığı value'yu yansıtmasını hem de sürdürülebilir iş sonuçlarının öncü bir göstergesi olmasını ister; North Star tek başına durmaz, onu hareket ettiren birkaç input metric'iyle birlikte bir çerçeve oluşturur.

Kayıtlı kullanıcı sayısı bir North Star olamaz, çünkü kimsenin value aldığını söylemez: bir kişi kayıt olup hiç alışveriş yapmayabilir. Bookstore için daha iyi bir aday "ayda en az bir sipariş veren müşteri sayısı"dır. Bir okurun gerçekten bir kitap alması, Bookstore'un ona sağladığı value'nun en doğrudan kanıtıdır; bu sayının büyümesi geliri de büyütür, ama gelirden farklı olarak tek seferlik büyük bir siparişle şişmez.

Input Metric'leri ve Metric Ağacı

North Star'ın sorunu, ekibin onu doğrudan hareket ettirememesidir; "ayda sipariş veren müşteri sayısı" haftalar içinde yavaş yavaş değişir ve birçok etkenden etkilenir. Bu yüzden North Star'ın altına, ekiplerin haftalık çalışmasıyla hareket ettirebileceği input metric'leri yerleştirilir:

Bookstore'un ağacında dört input var. Activation, yeni kayıt olan müşterinin ilk yedi gün içinde ilk siparişini vermesidir. Checkout, sepete eklenen kitabın siparişe dönüşme oranıdır ve sepet terk çalışmasının doğrudan hedefidir. Retention, ilk siparişten sonraki 30 gün içinde ikinci siparişin gelmesidir. Discovery ise arama yapan okurun bir ürün sayfasına geçme oranıdır; aradığını bulamayan okur sipariş veremez.

Her input farklı bir ekibe ya da farklı bir roadmap satırına bağlanabilir. Önceki yazıdaki Now-Next-Later tablosunun satırlarına bakarsan, her birinin bu ağaçta bir yeri olduğunu görürsün: misafir sepet terki Checkout'u, ikinci siparişe dönme Retention'ı, sonuçsuz aramalar Discovery'yi hareket ettirir. Ağaç, roadmap'teki problemlerin neden önemli olduğunu sayıyla bağlar.

Ağacın altındaki kırmızı şerit guardrail'lerdir. Bunlara aşağıda döneceğiz.

HEART ve Goals-Signals-Metrics

North Star ürünün tamamına bakar. Tek bir feature'ın ya da ekranın başarısını ölçmek için Google'dan Kerry Rodden, Hilary Hutchinson ve Xin Fu'nun 2010'da CHI konferansında yayımladıkları HEART framework'ü daha uygundur. HEART beş kategoriden oluşur: Happiness (memnuniyet, algı), Engagement (kullanımın yoğunluğu ve sıklığı), Adoption (yeni kullanıcıların ya da yeni bir feature'ı kullanmaya başlayanların oranı), Retention (kullanıcıların geri gelmesi) ve Task success (görevin verimli ve hatasız tamamlanması).

Makalenin asıl katkısı kategorilerden çok, onları kullanma süreci: Goals-Signals-Metrics. Önce hedefi yazarsın (kullanıcı ne başarmalı?), sonra o hedefe ulaşıldığını ya da ulaşılamadığını gösterecek sinyali (hangi davranış bunu gösterir?), en son da sinyali sayıya çeviren metric'i. Makale her projede beş kategorinin hepsinin gerekmediğini de vurgular. Bookstore'un guest checkout feature'ı için:

Engagement bu feature için anlamlı değil; kimsenin ödeme adımında daha uzun ya da daha sık kalmasını istemiyoruz. HEART'ın gücü, hangi kategorinin bu feature için önemli olduğunu düşünmeye zorlamasıdır.

AARRR: Pirate Metrics

Dave McClure'ın 2007'de "Startup Metrics for Pirates" konuşmasında ortaya koyduğu AARRR (Acquisition, Activation, Retention, Referral, Revenue), müşterinin yaşam döngüsünü beş aşamaya böler: Acquisition (müşteri bizi nasıl buluyor), Activation (ilk iyi deneyimi yaşıyor mu), Retention (geri geliyor mu), Referral (başkalarına anlatıyor mu) ve Revenue (para kazandırıyor mu). Baş harflerin okunuşu bir korsan nidasına benzediği için "pirate metrics" diye de anılır.

Bookstore için karşılıkları kolayca bulunur: Acquisition, siteye ilk kez gelen ziyaretçi ve kaynağı; Activation, ilk sipariş; Retention, 30 gün içinde ikinci sipariş; Referral, wishlist paylaşımından gelen yeni müşteriler; Revenue, müşteri başına aylık gelir. AARRR bir funnel olarak okunur ve en büyük kaybın hangi aşamada olduğunu gösterir. Bookstore'da kayıp açıkça Activation'da; ilk kez gelen misafirlerin büyük kısmı ilk siparişe ulaşmıyor. Bu, Acquisition'a (reklama) daha çok para harcamanın neden şu an doğru yatırım olmadığını da söyler: delik bir kovaya daha çok su dökmek olur.

HEART, AARRR ve North Star birbirinin rakibi değildir. North Star ürünün tamamını tek sayıda toplar, AARRR müşterinin yaşam döngüsündeki kaybı gösterir, HEART tek bir feature'ın kullanıcı deneyimini ölçer. Web sitesi trafiği ve SEO (Search Engine Optimization) metric'leri ise bu serinin değil, ilerideki Analytics ve Ölçüm serisinin konusu.

Leading, Lagging ve Vanity Metric'ler

Lagging metric, bir sonucu geç ama kesin söyler: çeyreklik gelir, yıllık müşteri kaybı. Leading metric ise sonucu önceden haber veren daha hızlı bir sinyaldir: ilk hafta içinde ikinci kez gelen müşteri oranı, birkaç ay sonraki retention'ın öncü göstergesidir. Ekipler leading metric'lerle çalışır, çünkü onlar haftalık hareket eder; ama leading metric'in gerçekten lagging olanı öngördüğünü zaman zaman kontrol etmek gerekir. Aksi hâlde ekip, hiçbir şeyi öngörmeyen bir sayıyı optimize eder.

Vanity metric, iyi hissettiren ama karar verdirmeyen sayıdır. Baştaki "kayıtlı kullanıcı sayısı" klasik bir örnek: kümülatiftir, yani hiç düşmez; ürün kötüleşse bile her ay biraz artar. Toplam sayfa görüntülenmesi, toplam indirme sayısı da çoğu zaman vanity'dir. Bir metric'in vanity olup olmadığını anlamanın basit bir testi var: bu sayı yarın %20 değişse, ne yapardın? Cevap "hiçbir şey" ise, o sayı karar vermene yardım etmiyordur. Kümülatif toplamlar yerine oranlar, aktif kullanıcılar ve cohort'lar kullanmak çoğu vanity metric'i işe yarar hâle getirir: "kayıtlı kullanıcı" yerine "geçen hafta en az bir sipariş veren kullanıcı".

Guardrail Metric'leri

Bir ekibe tek bir metric verip onu optimize etmesini istersen, ekip onu optimize eder; bazen istemediğin yollarla. Sepet terk oranını düşürmenin en hızlı yolu, sepete eklemeyi zorlaştırmaktır. Checkout dönüşümünü artırmanın bir yolu da agresif indirim vermektir; dönüşüm artar, kâr düşer.

Guardrail metric'leri bunu engellemek için vardır: optimize edilmeyen, ama kötüleşmemesi gereken sayılar. Bookstore'un ağacında dört guardrail var: iade oranı (yanlış ya da aceleyle verilen siparişler artmasın), teslim süresinin 85. percentile'ı (hızlı satış, operasyonu boğmasın), ürün sayfasının 95. percentile yanıt süresi (kargo ücretini hesaplamak sayfayı yavaşlatmasın) ve sipariş başına destek talebi (yeni akış müşteriyi şaşırtmasın). Bir deney ya da yeni feature North Star'ı iyileştirirken bir guardrail'i belirgin şekilde kötüleştiriyorsa, sonuç başarılı sayılmaz. Bunu 08. yazıda deney sonucunu yorumlarken kullanacağız.

Üretimde Dikkat

Her metric'in yazılı bir tanımı olmalı: hangi event'lerden hesaplanıyor, hangi zaman penceresiyle, hangi kullanıcılar dahil, misafir ve kayıtlı nasıl ayrılıyor. "Aylık aktif müşteri" iki ekibin elinde iki farklı sayı üretiyorsa, metric'in tanımı yoktur, iki ayrı metric vardır. Bu tanımlar kodla birlikte yaşamalı; 07. yazıda event taxonomy'yi ve SQL sorgularını bu yüzden kodun içinde tutacağız.

Tanımı değiştirdiğinde geçmişi işaretle. Botları dışarıda bırakan yeni bir filtre eklediğinde aktif kullanıcı sayısı bir gecede düşer; grafiğe bir not düşmezsen, üç ay sonra biri o düşüşü bir ürün sorunu sanır.

Her metric'in bir sahibi olsun. Bir metric bozulduğunda (event gelmeyi kesti, sayı sıfıra düştü) kimin bakacağı belli değilse, dashboard'daki sayı haftalarca yanlış kalabilir. Ürün metric'leri de teknik metric'ler gibi alarm ve sahiplik ister.

Sık Düşülen Tuzaklar

İlk tuzak ölçülebileni ölçüp önemliyi ölçmemek. Sayfa görüntülenmesini ölçmek kolaydır, okurun aradığı kitabı bulup bulmadığını ölçmek zordur; ekip kolay olanı dashboard'a koyar ve zamanla onu optimize etmeye başlar. Metric'i seçerken "neyi ölçebiliriz?" değil, "neyi bilmemiz gerekiyor?" sorusundan başla.

İkinci tuzak tek bir metric'e optimize edip guardrail koymamak. Goodhart yasası olarak bilinen gözlem, Marilyn Strathern'in yaygınlaşan ifadesiyle, bir ölçü hedef hâline geldiğinde iyi bir ölçü olmaktan çıkar. Guardrail'ler bu kaymayı yakalamanın en basit aracıdır.

Üçüncüsü çok fazla North Star. "North Star'larımız şunlar" diye beş metric sayan bir ekibin North Star'ı yoktur. Bir North Star ve onu besleyen birkaç input; gerisi teşhis için kullanılan destek metric'leri.

Dördüncüsü ortalamaya bakıp dağılımı görmemek. "Ortalama sepet tutarı arttı" cümlesi, birkaç çok büyük kurumsal siparişin etkisi olabilir. Kanban serisindeki cycle time gibi, ürün metric'lerinde de medyan, percentile ve segment kırılımı ortalamadan çok daha fazlasını söyler.

Küçük Bir Deneme

★☆☆ Ekibinin dashboard'undaki ilk beş metric'i yaz ve her biri için "yarın %20 değişse ne yapardık?" sorusunu cevapla. Hangileri vanity çıktı?

★★☆ Ürünün için bir North Star ve üç input metric'i öner. Her input'un hangi ekibin ya da hangi roadmap satırının işiyle hareket edeceğini yaz. En az iki guardrail ekle.

★★★ Ekibinin son teslim ettiği feature için bir HEART tablosu doldur: hangi kategoriler anlamlı, her biri için goal, signal ve metric. Bu metric'lerden kaçını bugün mevcut veriyle hesaplayabiliyorsun? Hesaplayamadıkların için hangi event eksik?

Metric'leri tanımladık; şimdi onları kodda ölçme zamanı. Bir sonraki yazıda bir event taxonomy kuracak, Angular'da event gönderen bir service, ASP.NET Core'da Minimal API (Application Programming Interface) ve EF (Entity Framework) Core ile bir event tablosu yazacak ve SQL ile haftalık retention cohort'unu ve activation funnel'ını gerçek veriden hesaplayacağız.