Apa Komponen Data Peristiwa?

Ini adalah bagian empat dari seri lima bagian tentang Data Pelanggan. Ini bagian satu, dua, dan tiga.

Data Pelanggan terdiri dari Data Peristiwa dan Data Entitas—Anda sudah mengetahuinya jika Anda telah melalui bagian pertama (Apa Itu Data Pelanggan?).

Dalam panduan ini, Anda akan mempelajari tentang komponen data peristiwa, konvensi penamaan yang lebih disukai untuk menentukan peristiwa, kategori data entitas, dan dua tipe utama entitas.

Data Acara

Karena Anda mungkin telah membeli barang secara online, mari kita mulai dengan contoh e-niaga.

Saat berinteraksi dengan aplikasi e-niaga (web atau seluler), Anda biasanya membeli produk dengan menambahkannya ke keranjang, melanjutkan ke checkout, dan menyelesaikan pembayaran—ini adalah peristiwa yang Anda lakukan saat menjalani proses pembelian item di aplikasi.

Perjalanan pembeli, bagaimanapun, tidak begitu mudah dan ada beberapa peristiwa lain yang dapat terjadi seperti:

• Sebuah produk dilihat
• Gerobak dilihat
• Produk dikeluarkan dari keranjang
• Kupon diterapkan
• Alamat dipilih
• Metode pembayaran dipilih
• Sebuah pesanan selesai

Dan seterusnya.

Peristiwa umum seperti Tambahkan ke Keranjang, Lanjutkan ke Checkout, dan Lakukan Pembayaran segera muncul di benak Anda, tetapi untuk memahami perilaku pengguna, seseorang juga perlu melacak peristiwa lain seperti yang disebutkan di atas.

Memutuskan peristiwa mana yang akan dilacak dan memberi nama peristiwa menggunakan konvensi penamaan yang tepat adalah dua langkah pertama dalam proses pengumpulan data peristiwa.

Apa dua langkah selanjutnya?

Senang Anda bertanya!

Setiap peristiwa disertai dengan properti peristiwa (atau atribut peristiwa ) yang memberikan lebih banyak konteks tentang suatu peristiwa. Memutuskan properti mana yang akan dikaitkan dengan suatu peristiwa dan menamai properti tersebut adalah dua langkah berikutnya dalam proses pengumpulan data peristiwa.

Apalah arti sebuah nama?

Ketika datang ke data, semuanya.

Konvensi penamaan atau taksonomi yang tepat adalah yang membuat data yang baik menonjol dari data yang buruk dan memungkinkan pemangku kepentingan untuk memahami apa yang mereka lihat. Tidak mempertahankan taksonomi standar, di sisi lain, adalah salah satu penyebab utama kumpulan data miring atau membengkak dengan redundansi.

Selain itu, saat bekerja dengan data pelanggan, tidak mempertahankan casing yang seragam saat memberi nama peristiwa dan properti peristiwa adalah salah satu kesalahan terbesar yang dapat Anda lakukan—kesalahan yang dapat memiliki konsekuensi jangka panjang. Sebuah konvensi penamaan yang baik harus selalu disertai dengan pedoman casing yang ketat.

Inilah alasannya:

Tambahkan ke Keranjang, tambah_ke_keranjang, produkDitambahkan, tambahkan ke troli, Ditambahkan ke troli, Ditambahkan Produk adalah cara berbeda untuk mendefinisikan acara yang sama.

Meskipun tidak satu pun dari ini yang salah, dan tidak ada aturan yang ditetapkan terkait penamaan peristiwa dan properti, ada praktik terbaik yang harus dipertimbangkan untuk diikuti.

Konvensi penamaan objek-tindakan telah cukup banyak menjadi standar industri dan untuk alasan yang baik—ini dengan jelas menggambarkan tindakan yang telah terjadi. Product Added pasti berarti bahwa suatu objek (produk) diikuti oleh suatu tindakan (ditambahkan).

Pelajari lebih lanjut tentang menyiapkan taksonomi yang konsisten untuk acara Anda .

Komponen data acara

Ada dua komponen kunci dari suatu peristiwa—entitas (satu atau lebih) dan properti peristiwa.

Mengaitkan data entitas seperti user_id dengan suatu peristiwa memberikan informasi tentang pengguna yang melakukan peristiwa tersebut.

Dengan tidak adanya pengenal unik seperti user_id , data acara akan tetap anonim dan tidak akan ada cara untuk mengetahui siapa yang melakukan acara tersebut. Demikian pula, dalam konteks B2B SaaS, di mana pengguna berpotensi menjadi bagian dari beberapa organisasi, organization_id perlu dikaitkan dengan peristiwa untuk mengetahui di mana peristiwa terjadi.

Selain entitas, ada informasi lain yang dapat dikumpulkan untuk tujuan analisis dan segmentasi saat peristiwa terjadi.

Kembali ke contoh e-commerce, ketika suatu produk dibeli, selain mengetahui siapa yang melakukan pembelian, setidaknya Anda juga perlu mengetahui produk apa yang dibeli dengan harga berapa, dan kapan .

Potongan informasi tambahan tersebut dikumpulkan dalam bentuk properti acara .

Di bagian pertama dari seri ini, disebutkan bahwa data peristiwa terdiri dari tiga elemen kunci:

• Tindakan atau peristiwa yang terjadi
• Stempel waktu atau tanggal dan waktu yang tepat saat acara berlangsung
• Status atau semua properti lain yang terkait dengan peristiwa (dikenal sebagai properti peristiwa)

Mari kita lihat event Product Added (nama dalam Proper Case sesuai dengan object-action framework untuk event Add to Cart ) dan asumsikan itu dilakukan oleh pengguna pada 1 Jan 2020, pukul 10 pagi UTC. Data-data yang dikumpulkan pada saat acara berlangsung antara lain sebagai berikut:

• Tindakan: Produk Ditambahkan
• Stempel waktu: 1577872800 (stempel waktu Unix untuk ABZ 7.99 ( Status: 0123 ABZ 7.99 ( Sesuai contoh ini, properti yang terkait dengan peristiwa yang Ditambahkan Produk adalah user_id, product_id, price, dan quantity , yang masing-masing memberikan lebih banyak informasi tentang acara tersebut. Stempel waktu dikaitkan dengan acara untuk mengetahui kapan itu terjadi.

  Hal ini juga berguna untuk menentukan nama untuk stempel waktu yang pada dasarnya merupakan properti acara. Ini tidak wajib dilakukan karena praktik standarnya adalah mengaitkan stempel waktu sebagai stempel waktu dengan setiap peristiwa saat mengirim data ke alat pihak ketiga; namun, menentukan nama yang berbeda untuk properti yang menyimpan stempel waktu dapat membantu dalam jangka panjang saat Anda perlu bekerja dengan data peristiwa historis.

  Taksonomi yang direkomendasikan untuk stempel waktu adalah nama peristiwa diikuti oleh "at": product_added_at untuk peristiwa yang Ditambahkan Produk.

  Anda mungkin telah memperhatikan bahwa snake_case digunakan untuk mendefinisikan properti peristiwa yang memudahkan untuk membedakan nama peristiwa dari properti peristiwa. Karena itu, ingatlah bahwa tidak ada aturan yang telah ditentukan sebelumnya di sini dan Anda harus memilih apa pun yang paling cocok untuk Anda dan tim Anda.

  Berikut adalah tampilan akhir pada properti yang terkait dengan peristiwa yang Ditambahkan Produk dan tipe data dari masing-masing properti tersebut:

  

  

  Menentukan tipe data untuk setiap properti memastikan konsistensi data dan membuat proses instrumentasi lebih mudah.

  Catatan tambahan: Perlu diingat bahwa Sekarang harus jelas bahwa pengumpulan data peristiwa terdiri dari langkah-langkah berikut:

  • Memutuskan acara mana yang akan dilacak
  • Memberi nama acara tersebut menggunakan konvensi penamaan yang tepat
  • Memutuskan properti mana yang akan dikaitkan dengan setiap peristiwa
  • Memberi nama properti tersebut menggunakan konvensi penamaan yang tepat

  Bagian berikutnya (dan terakhir) dari seri ini mencakup proses memutuskan peristiwa mana yang akan dilacak dan data apa yang dikumpulkan.

  Namun, Anda harus memiliki gagasan yang baik tentang apa yang diharapkan saat melihat data peristiwa (baik dalam rencana pelacakan sebelum instrumentasi atau di dalam tujuan data seperti alat analisis produk Anda).

  Beberapa peristiwa umum dan propertinya

  Sebelum melanjutkan, lihat beberapa peristiwa dan properti umum yang dilacak oleh sebagian besar produk teknologi.

  

  Jenis entitas

  Saatnya untuk melihat secara mendalam entitas yang berbeda dan propertinya. Jika Anda belum melakukannya, ikuti panduan ini untuk memahami bagaimana data entitas terkait dengan data peristiwa.

  Di bagian pertama seri ini, disebutkan bahwa data yang dibagikan oleh pengguna termasuk dalam data entitas. Meskipun itu benar, tidak semua data entitas dibagikan oleh pengguna itu sendiri—data entitas juga dapat dibuat.

  Data entitas terdiri dari properti yang terkait dengan entitas—jika Pengguna adalah entitas, semua informasi tentang pengguna dikumpulkan dalam bentuk properti pengguna.

  User_id dibuat untuk setiap pengguna secara default untuk mengidentifikasi pengguna (dan bertindak sebagai pengidentifikasi untuk acara.)

  Karena itu, untuk saat ini, lupakan acara dan pikirkan berbagai informasi yang terkait secara eksklusif dengan pengguna dan beri tahu Anda tentang ciri-ciri mereka.

  Jenis data entitas

  Data Entitas dapat dikategorikan ke dalam keranjang berikut (juga disebutkan di bagian 3 seri ini):

  • Informasi identitas pribadi seperti Demografi seperti Persona seperti Preferensi seperti Data khusus produk seperti Potongan data di bawah setiap keranjang termasuk dalam properti pengguna. Dengan kata lain, properti pengguna menyimpan berbagai detail dan sifat tentang pengguna, memungkinkan Anda untuk mengidentifikasi mereka dan mengetahui lebih banyak tentang mereka.

    Sementara sebagian besar informasi berasal dari pengguna secara langsung, properti pengguna tertentu dihasilkan secara otomatis dari waktu ke waktu sebagai akibat dari penggunaan produk.

    Tetapi bukankah data peristiwa juga dihasilkan karena penggunaan produk?

    Memang benar—properti pengguna adalah detail tambahan yang terkait dengan acara yang dikumpulkan saat acara berlangsung. Mari kita lihat acara Signed Up dan propertinya:

    

    Seperti yang Anda lihat, semua properti yang terkait dengan peristiwa ini memberikan detail tentang pengguna—detail yang dibagikan oleh pengguna itu sendiri ( nama_depan, nama_belakang , email, telepon, negara ) atau detail yang dibuat secara otomatis ( sign_up_at, user_id ).

    Sangat membantu untuk mengingat hal-hal berikut:

    • Beberapa peristiwa seperti Mendaftar atau Sebagian besar properti pengguna kecuali cap waktu dan pengenal dapat berubah. Seorang pengguna dapat mengubah nama, email, telepon, lokasi, industri, peran pekerjaan, dll. Tetapi waktu mendaftar (signed_up_at) atau pengenal unik (user_id) tidak dapat diubah oleh pengguna.

    Properti pengguna vs. properti organisasi

    Dengan aplikasi konsumen, waktu yang dihabiskan, produk yang dibeli, lagu yang diputar, atau video yang ditonton adalah properti yang terkait dengan pengguna yang disimpan sebagai properti pengguna, yang nilainya terus diperbarui dengan peningkatan penggunaan.

    Dalam konteks SaaS B2B, Pengguna dan Organisasi adalah entitas utama, dan peristiwa yang dikumpulkan terkait dengan pengguna atau organisasi (atau keduanya).

    Mungkin ada entitas grup lain seperti tim atau proyek dengan potongan data tertentu yang terkait dengannya, seperti halnya dengan sebagian besar alat produktivitas—proses pengumpulan data organisasi juga berlaku dalam kasus seperti itu.

    Mari kita lihat beberapa properti pengguna umum yang relevan dengan produk SaaS B2B:

    

    Ketika pengguna adalah bagian dari organisasi , banyak informasi penting terikat pada organisasi dan bukan pengguna.

    Beberapa properti organisasi umum (juga disebut sebagai properti grup ) adalah sebagai berikut:

    

    Penting untuk diingat bahwa organization_id juga bertindak sebagai pengenal dan harus dikaitkan dengan peristiwa untuk mengetahui di bawah organisasi mana peristiwa tertentu terjadi.

    Menjaga pernyataan berikut dalam pikiran dapat membantu membedakan antara properti pengguna dan properti organisasi:

    • Setiap informasi yang membantu menentukan kelompok pengguna —dari mana mereka berasal, siapa mereka, apa tujuan mereka, atau apa yang mereka lakukan di dalam produk—disimpan sebagai properti pengguna .
    • Setiap informasi yang membantu mengelompokkan akun atau organisasi — jenis akun, pendapatan yang dihasilkan, produk atau fitur yang digunakan, sumber daya yang dikonsumsi, atau jumlah pengguna yang menjadi bagiannya — disimpan sebagai properti organisasi ( atau milik kelompok).

    Setelah Anda dapat membedakan antara hal-hal di atas, menjadi mudah untuk membawa entitas baru (seperti tim atau proyek) ke dalam campuran.

    Langkah selanjutnya

    Anda sekarang harus memiliki pemahaman yang jelas tentang cara mendefinisikan peristiwa dan properti terkaitnya, serta menentukan properti setiap entitas (pengguna dan organisasi).

    Untuk mulai menentukan acara dan mengatur data Anda hari ini, mulailah dengan akun Amplitude gratis.