Olay Verilerinin Bileşenleri Nelerdir?

Bu, Müşteri Verileri üzerine beş bölümlük dizinin dördüncü bölümüdür. İşte birinci, ikinci ve üçüncü bölümler.

Müşteri Verileri, Etkinlik Verileri ve Varlık Verilerinden oluşur; birinci bölümü (Müşteri Verileri Nedir?) geçtiyseniz bunu zaten biliyorsunuzdur.

Bu kılavuzda, olay verilerinin bileşenleri, olayları tanımlamak için tercih edilen adlandırma kuralı, varlık verilerinin kategorileri ve iki ana varlık türü hakkında bilgi edineceksiniz.

Olay Verileri

Muhtemelen çevrimiçi bir şeyler satın aldığınız için, bir e-ticaret örneği ile başlayalım.

Bir e-ticaret uygulamasıyla (web veya mobil) etkileşim kurarken, genellikle bir ürünü sepetinize ekleyerek, ödeme işlemine geçerek ve ödemeyi tamamlayarak satın alırsınız; bunlar, bir ürünü satın alma sürecinden geçerken gerçekleştirdiğiniz etkinliklerdir. uygulama.

Bununla birlikte, alıcı yolculuğu o kadar basit değildir ve aşağıdakiler gibi gerçekleşebilecek birkaç başka olay vardır:

• bir ürün görüntülendi
• Sepet görüntüleniyor
• Sepetten bir ürün kaldırıldı
• Kupon uygulanır
• bir adres seçildi
• Bir ödeme yöntemi seçilir
• bir sipariş tamamlandı

Ve benzeri.

Sepete Ekle, Ödemeye Devam Et ve Ödeme Yap gibi yaygın olaylar hemen akla gelir, ancak kullanıcı davranışını anlamak için yukarıda belirtilenler gibi diğer olayları da izlemek gerekir.

Hangi olayların izleneceğine karar vermek ve olayları uygun bir adlandırma kuralı kullanarak adlandırmak, olay verilerinin toplanması sürecindeki ilk iki adımdır.

Sonraki iki adım nedir?

Sorduğuna sevindim!

Her olaya, bir olay hakkında daha fazla bağlam sağlayan olay özellikleri (veya olay nitelikleri ) eşlik eder. Bir olayla hangi özelliklerin ilişkilendirileceğine karar vermek ve bu özellikleri adlandırmak, olay verilerinin toplanması sürecinde sonraki iki adımdır.

Bir isimde ne var?

Veri söz konusu olduğunda, her şey.

Uygun bir adlandırma kuralı veya sınıflandırması, iyi verileri kötü verilerden ayıran ve paydaşların neye baktıklarını anlamalarını sağlayan şeydir. Öte yandan, standartlaştırılmış bir sınıflandırmayı sürdürmemek, veri kümelerinin çarpıklığının veya fazlalıkla şişirilmesinin ana nedenlerinden biridir.

Ayrıca, müşteri verileriyle çalışırken, olayları ve olay özelliklerini adlandırırken tek tip büyük/küçük harf kullanmamak yapabileceğiniz en büyük hatalardan biridir ve uzun vadeli sonuçları olabilir. İyi bir adlandırma kuralına her zaman katı büyük/küçük harf yönergeleri eşlik etmelidir.

İşte nedeni:

Sepete Ekle, Add_to_cart, productAdded, sepete ekle, Sepete eklendi, Ürün Eklendi , aynı olayı tanımlamanın farklı yollarıdır.

Bunların hiçbiri başlı başına yanlış olmasa ve olay ve özellikleri adlandırma söz konusu olduğunda belirlenmiş kurallar olmasa da, göz önünde bulundurulması gereken en iyi uygulamalar vardır.

Nesne eylemi adlandırma kuralı hemen hemen endüstri standardı haline geldi ve bunun iyi bir nedeni var - zaten gerçekleşmiş olan eylemi açıkça tanımlıyor. Ürün Eklendi kesinlikle bir nesnenin (ürün) ardından bir eylemin (eklendi) geldiği anlamına gelir.

Etkinlikleriniz için tutarlı bir sınıflandırma oluşturma hakkında daha fazla bilgi edinin .

Olay verilerinin bileşenleri

Bir olayın iki temel bileşeni vardır: bir varlık (bir veya daha fazla) ve olay özellikleri.

user_id gibi varlık verilerini bir olayla ilişkilendirmek, olayı gerçekleştiren kullanıcı hakkında bilgi sağlar.

user_id gibi benzersiz bir tanımlayıcının yokluğunda, olay verileri anonim kalacaktır ve söz konusu olayı kimin gerçekleştirdiğini bilmenin hiçbir yolu olmayacaktır. Benzer şekilde, bir kullanıcının potansiyel olarak birden fazla organizasyonun parçası olabileceği B2B SaaS bağlamında, event_id'nin, olayların nerede gerçekleştiğini bilmek için olaylarla ilişkilendirilmesi gerekir.

Varlıkların yanı sıra, olaylar gerçekleştiğinde analiz ve segmentasyon amacıyla toplanabilecek başka bilgi parçaları da vardır.

E-ticaret örneğine geri dönersek, bir ürün satın alındığında, satın alma işlemini kimin yaptığını bilmenin yanı sıra, en azından hangi ürünün hangi fiyattan ve ne zaman satın alındığını da bilmeniz gerekir.

Bu ek bilgiler, olay özellikleri biçiminde toplanır.

Bu dizinin birinci bölümünde, olay verilerinin üç temel unsurdan oluştuğundan bahsedildi:

• Gerçekleşen eylem veya olay
• Etkinliğin gerçekleştiği zaman damgası veya kesin tarih ve saat
• Olayla ilişkili durum veya diğer tüm özellikler (olay özellikleri olarak bilinir)

Product Added olayına bakalım ( Add to Cart olayının nesne-eylem çerçevesine göre Uygun Durumdaki ad) ve bunun bir kullanıcı tarafından 1 Ocak 2020, 10:00 UTC'de gerçekleştirildiğini varsayalım. Etkinlik gerçekleştiğinde toplanan veriler şunları içerir:

• Eylem: Ürün Eklendi
• Zaman damgası: 1577872800 ( ABZ 7.99 ( Durum: 0123 ABZ 7,99 ( Bu örneğe göre, Ürün Eklendi olayıyla ilişkili özellikler, her biri olay hakkında daha fazla bilgi sağlayan user_id, product_id, fiyat ve miktardır . Zaman damgası , ne zaman gerçekleştiğini bilmek için olayla ilişkilendirilir.

  Esasen bir olay özelliği olan zaman damgası için bir ad belirtmek de yararlıdır. Standart uygulama, üçüncü taraf araçlara veri gönderirken zaman damgasını her olayla ilişkilendirmek olduğundan, bunu yapmak zorunlu değildir; ancak, zaman damgasını depolayan özellik için ayrı bir ad belirtmek, geçmiş olay verileriyle çalışmanız gerektiğinde uzun vadede yardımcı olabilir.

  Zaman damgaları için önerilen sınıflandırma, Ürün Eklendi etkinliği için "at" ile devam eden etkinlik adıdır: product_added_at .

  Snake_case öğesinin olay özelliklerini tanımlamak için kullanıldığını fark etmiş olabilirsiniz, bu da olay adlarını olay özelliklerinden ayırt etmeyi kolaylaştırır. Bununla birlikte, burada önceden tanımlanmış kurallar olmadığını ve sizin ve ekibiniz için en iyi olanı seçmeniz gerektiğini unutmayın.

  Ürün Eklendi olayıyla ilişkili özelliklere ve bu özelliklerin her birinin veri türlerine son bir bakış:

  

  Her özellik için veri türünün belirtilmesi, verilerin tutarlılığını sağlar ve enstrümantasyon sürecini kolaylaştırır.

  Yan not: Artık olay verilerinin toplanmasının aşağıdaki adımlardan oluştuğu açık olmalıdır:

  • Hangi olayların izleneceğine karar verme
  • Uygun bir adlandırma kuralı kullanarak bu olayları adlandırma
  • Her bir olayla hangi özelliklerin ilişkilendirileceğine karar verme
  • Uygun bir adlandırma kuralı kullanarak bu özellikleri adlandırma

  Bu dizinin sonraki (ve son) bölümü, hangi olayların izleneceğine ve hangi verilerin toplanacağına karar verme sürecini kapsar.

  

  Ancak, olay verilerine bakarken ne bekleyeceğiniz konusunda iyi bir fikre sahip olmalısınız (ister enstrümantasyondan önceki bir izleme planında isterse ürün analizi aracınız gibi bir veri hedefinin içinde olsun).

  Bazı yaygın olaylar ve özellikleri

  Devam etmeden önce, çoğu teknoloji ürünü tarafından izlenen birkaç yaygın olaya ve özelliğe bir göz atın.

  

  Varlık türleri

  Farklı varlıklara ve özelliklerine derinlemesine bakmanın zamanı geldi. Henüz yapmadıysanız, varlık verilerinin olay verileriyle nasıl ilişkili olduğunu anlamak için bu kılavuzu inceleyin.

  Bu serinin ilk bölümünde, kullanıcılar tarafından paylaşılan verilerin varlık verileri kapsamına girdiğinden bahsetmiştik. Bu doğru olsa da, tüm varlık verileri kullanıcıların kendileri tarafından paylaşılmaz; varlık verileri de oluşturulabilir.

  Varlık verileri, varlıkla ilişkili özellikleri içerir—varlık Kullanıcı ise, bir kullanıcı hakkındaki tüm bilgiler, kullanıcı özellikleri biçiminde toplanır.

  Kullanıcıları tanımlamak için varsayılan olarak her kullanıcı için User_id oluşturulur (ve olaylar için bir tanımlayıcı görevi görür.)

  Bununla birlikte, şimdilik olayları unutun ve yalnızca kullanıcılarla ilgili olan ve size onların özelliklerini anlatan farklı bilgi parçalarını düşünün.

  Varlık verisi türleri

  Varlık Verileri aşağıdaki bölümlere ayrılabilir (bu serinin 3. bölümünde de bahsedilmiştir):

  • Ad, e-posta ve telefon gibi kişisel olarak tanımlanabilir bilgiler
  • Yaş, cinsiyet ve konum gibi demografik bilgiler
  • Endüstri Markalar, türler ve ürün kategorileri gibi tercihler .
  • Satın alınan ürünler, kullanılan uygulamalar, harcanan süre ve abonelik türü gibi ürüne özel veriler .

  Her bir paketin altındaki veri parçaları, kullanıcı özelliklerinin altına girer. Başka bir deyişle, kullanıcı özellikleri, kullanıcılarla ilgili çeşitli ayrıntıları ve özellikleri saklayarak onları tanımlamanıza ve onlar hakkında daha fazla bilgi edinmenize olanak tanır.

  Bilgilerin çoğu doğrudan kullanıcıdan gelirken, ürün kullanımı sonucunda belirli kullanıcı özellikleri zaman içinde otomatik olarak oluşturulur.

  Ancak ürün kullanımı nedeniyle olay verileri de oluşturulmuyor mu?

  Kesinlikle—kullanıcı özellikleri, olay gerçekleştiğinde toplanan olayla ilgili ek ayrıntılardır. Şimdi Signed Up etkinliğine ve özelliklerine bir göz atalım:

  

  Gördüğünüz gibi, bu olayla ilişkili tüm özellikler, kullanıcılar hakkında ayrıntılar sağlar; bunlar, kullanıcıların kendileri tarafından paylaşılan ayrıntılar (ad, soyadı , e-posta, telefon, ülke ) veya otomatik olarak oluşturulan ayrıntılar ( signed_up_at, user_id ).

  Aşağıdakileri akılda tutmakta fayda var:

  • Kaydolma veya Zaman damgalarını ve tanımlayıcıları engelleyen çoğu kullanıcı özelliği değiştirilebilir. Bir kullanıcı adını, e-posta adresini, telefonunu, konumunu, sektörünü, iş rolünü vb. değiştirebilir. Ancak kaydolma zamanı (signed_up_at) veya benzersiz tanımlayıcı (user_id) kullanıcı tarafından değiştirilemez.

  Kullanıcı özellikleri ve kuruluş özellikleri

  Tüketici uygulamalarında harcanan zaman, satın alınan ürünler, çalınan şarkılar veya izlenen videolar, kullanıcı özellikleri olarak depolanan ve kullanımdaki artışla birlikte değerleri sürekli olarak güncellenen kullanıcıyla ilişkili özelliklerdir.

  B2B SaaS bağlamında, Kullanıcı ve Kuruluş ana varlıklardır ve toplanan olaylar bir kullanıcıya veya bir kuruluşa (veya her ikisine) bağlıdır.

  Çoğu üretkenlik aracında olduğu gibi, kendilerine bağlı belirli veri parçalarına sahip ekip veya proje gibi başka grup varlıkları olabilir - bu gibi durumlarda da kuruluş verilerini toplama süreci geçerlidir.

  B2B SaaS ürünleriyle ilgili bazı genel kullanıcı özelliklerine bir göz atalım:

  

  Bir kullanıcı bir kuruluşun parçası olduğunda , birçok önemli bilgi parçası kullanıcıya değil kuruluşa bağlıdır.

  Bazı yaygın organizasyon özellikleri ( grup özellikleri olarak da anılır) aşağıdaki gibidir:

  

  Organization_id'nin aynı zamanda bir tanımlayıcı görevi gördüğünü ve belirli bir olayın hangi organizasyonun altında gerçekleştiğini bilmek için olaylarla ilişkilendirilmesi gerektiğini akılda tutmak önemlidir.

  Aşağıdaki ifadeleri akılda tutmak, kullanıcı özellikleri ile kuruluş özellikleri arasında ayrım yapılmasına yardımcı olabilir:

  • Kullanıcı gruplarını (nereden geldikleri, kim oldukları, amaçlarının ne olduğu veya bir ürün içinde ne yaptıkları) tanımlamaya yardımcı olan her bilgi, bir kullanıcı özelliği olarak depolanır.
  • Hesapları veya kuruluşları segmentlere ayırmaya yardımcı olan her bilgi parçası - hesap türü, oluşturduğu gelir, kullandığı ürünler veya özellikler, tükettiği kaynaklar veya bunun parçası olan kullanıcı sayısı - bir kuruluş mülkü olarak depolanır ( veya grup özelliği).

  Yukarıdakileri ayırt edebildiğinizde, yeni varlıkları (ekipler veya projeler gibi) karışıma dahil etmek kolaylaşır.

  Sonraki adımlar

  Artık olayları ve bunlarla ilişkili özellikleri nasıl tanımlayacağınızı ve ayrıca her bir varlığın (kullanıcı ve kuruluş) özelliklerini nasıl belirleyeceğiniz konusunda net bir anlayışa sahip olmalısınız.

  Etkinlikleri tanımlamaya ve verilerinizi düzenlemeye bugün başlamak için ücretsiz bir Amplitude hesabıyla başlayın.