Apa itu analitik produk? Metrik dan pengguna yang kembali

Analitik produk menunjukkan cara orang memakai aplikasi Anda. LogBrew membaca aksi produk yang dikirim aplikasi Anda, termasuk tayangan halaman, tayangan layar, dan interaksi. Gunakan Perekaman peristiwa produk untuk mengirim peristiwa ini dengan konteks pengguna dan sesi. Setiap hasil berlaku untuk satu proyek dan satu rentang waktu. Nama layanan tidak memilih proyek. Log dan masalah adalah sinyal terpisah. Keberadaannya tidak berarti ada data analitik untuk rentang yang sama.

Peristiwa, pengguna, dan sesi

Unit	Arti
Peristiwa	Satu aksi yang direkam. Satu orang bisa mengirim banyak peristiwa.
Pengguna teridentifikasi	ID subjek yang stabil dan buram (tidak mengungkap identitas), diberikan aplikasi, dengan jenis `user`.
Subjek anonim	ID subjek bertipe yang bukan pengguna. Subjek ini tidak pernah dihitung sebagai pengguna.
Sesi	ID sesi eksplisit yang diberikan aplikasi. Satu orang bisa punya banyak sesi.

Misalnya, 200 aksi dalam 20 sesi tidak berarti 20 orang memakai aplikasi. Total peristiwa dihitung persis untuk rentang waktu yang dipilih. Jumlah pengguna, sesi, dan subjek anonim yang unik adalah perkiraan. Gunakan ID buram. Jangan pakai nama, alamat email, atau data pribadi lain sebagai ID. Respons analitik tidak pernah mengembalikan ID pengguna atau ID sesi mentah.

Buka ikhtisar di dasbor

Buka Analitik di dasbor LogBrew.
Pilih satu proyek.
Pilih 24 jam, 7 hari, 14 hari, 30 hari, atau Kustom.
Baca grafik aktivitas, lalu Peristiwa teratas dan Halaman dan layar teratas.
Buka Cakupan dan batas sebelum Anda membaca jumlah pengguna.

Untuk Kustom, pilih hari pertama dan terakhir, lalu pilih Terapkan. Kedua hari termasuk dalam rentang. Misalnya, 12 April sampai 16 April adalah lima hari. Dasbor memakai tanggal UTC. Rentang kustom paling panjang 31 hari dan tidak boleh mencakup tanggal di masa depan. Dasbor juga menampilkan dua tren pengguna untuk proyek dan tanggal yang sama. Apakah pengguna kembali? menampilkan retensi. Bagaimana basis pengguna berubah? menampilkan kelompok siklus hidup. Kedua tren memakai semua aktivitas terklasifikasi dari pengguna teridentifikasi. Anda tidak memilih peristiwa untuk tren ini.

Baca ikhtisar proyek

logbrew analytics overview --project "<project_id>" --since 7d --json

Tambahkan --until <RFC3339> untuk waktu akhir yang eksklusif. --interval menerima auto, 1m, 5m, 15m, 1h, 6h, atau 1d. --top-limit menentukan jumlah baris di setiap daftar teratas, dari 1 sampai 20. Nilai default-nya 10. Tambahkan --service, --release, atau --environment untuk memfilter berdasarkan konteks yang tepat. Endpoint API-nya adalah GET /api/telemetry/analytics/overview. Ikhtisar berisi total aktivitas, deret waktu, aksi teratas, dan aktivitas terklasifikasi. Kutipan ini menunjukkan total dan cakupannya:

{
  "schema_version": 3,
  "analysis_level": "user_and_session",
  "summary": {
    "actions": 120,
    "active_identified_users": 18,
    "active_anonymous_subjects": 7,
    "sessions": 24
  },
  "coverage": {
    "identified_actions": 100,
    "anonymous_actions": 20,
    "subject_coverage": {
      "index_version": 1,
      "identified_user_events": 100,
      "anonymous_subject_events": 8,
      "legacy_unknown_kind_events": 4,
      "missing_subject_events": 6,
      "historical_unindexed_events": 2
    },
    "sessionized_actions": 90,
    "traced_actions": 60,
    "top_actions_truncated": true
  },
  "next_action": { "code": "build_product_funnel" }
}

Jika dijumlahkan, kelima angka subject_coverage sama dengan summary.actions. Hanya identified_user_events yang dihitung sebagai pengguna. anonymous_actions mencakup empat status lainnya. Dalam contoh ini, 8 peristiwa subjek anonim berasal dari sekitar 7 subjek anonim yang berbeda. Kedua angka itu bukan jumlah pengguna. Daftar teratas yang dipotong tidak menunjukkan bahwa peristiwa bervolume lebih rendah tidak ada. analysis_level bernilai no_data, event_only, user_level, atau user_and_session. Nilai ini menunjukkan pertanyaan apa saja yang bisa dijawab data. Level ini adalah level tertinggi yang didukung oleh summary atau classified_activity. Nilai ini tidak berarti kedua kelompok punya pengguna atau sesi.

Pisahkan kedua kelompok aktivitas

Kolom respons	Peristiwa yang dihitung
`summary`, `coverage`, `series`, `top_actions`	Peristiwa aksi produk, termasuk aksi tanpa klasifikasi yang didukung.
`classified_activity`	Tayangan halaman, tayangan layar, dan interaksi. Tayangan halaman bukan aksi.

Tayangan layar dan interaksi yang terklasifikasi juga merupakan aksi. Jangan jumlahkan summary.actions dengan classified_activity.summary.events. Baca cakupan dari kelompok yang Anda pakai. Jika dijumlahkan, angka subjek di classified_activity.coverage.subject_coverage sama dengan classified_activity.summary.events. summary.actions bisa bernilai 0 sementara tayangan halaman terklasifikasi memberikan jumlah pengguna dan sesi. Periksa classified_activity sebelum Anda menyimpulkan bahwa tidak ada aktivitas produk.

Ikuti tindakan berikutnya

next_action berisi code, target, dan reason. Nilai ini menunjukkan celah perekaman yang paling penting atau langkah analisis berikutnya:

`next_action.code`	Arti
`capture_product_activity`	Tidak ada peristiwa produk yang cocok dengan lingkup.
`classify_product_activity`	Ada peristiwa, tetapi tidak satu pun berupa tayangan halaman, tayangan layar, atau interaksi.
`identify_product_users`	Tidak ada peristiwa yang punya subjek dengan jenis `user`.
`sessionize_product_activity`	Tidak ada peristiwa yang punya ID sesi.
`capture_funnel_steps`	Ada kurang dari dua peristiwa terklasifikasi yang bernama.
`build_product_funnel`	Data bisa mendukung funnel.

Ubah perekaman di aplikasi, lalu periksa peristiwa baru. Peristiwa lama tidak menunjukkan bahwa perubahan itu berhasil.

Panggil API secara langsung

Kirim bearer akun. Kirim response_version=3 untuk mendapatkan respons yang sama dengan yang dibaca CLI. Jika Anda tidak mengirim response_version, API mengembalikan versi 1, yang tidak berisi jumlah subjek anonim atau subject_coverage.

curl -sS -G "https://api.logbrew.co/api/telemetry/analytics/overview" \
  -H "Authorization: Bearer $LOGBREW_ACCOUNT_BEARER" \
  --data-urlencode "project_id=<project_id>" \
  --data-urlencode "since=7d" \
  --data-urlencode "response_version=3"

since berupa durasi positif, seperti 24h, 7d, atau 30d, atau stempel waktu RFC3339. until adalah stempel waktu RFC3339 yang opsional. Rentang mencakup since dan tidak mencakup until. Jika Anda tidak mengisi until, rentang berakhir pada waktu permintaan. Rentang tidak boleh lebih dari 31 hari. Untuk 12 April sampai 16 April 2026, kirim 2026-04-12T00:00:00Z sebagai since dan 2026-04-17T00:00:00Z sebagai until. Rentang yang lebih dari 31 hari mengembalikan HTTP 422:

{
  "error": "product analytics range must not exceed 31 days",
  "code": "validation_failed",
  "next": "use a shorter range or query consecutive bounded windows",
  "next_action": { "code": "fix_request", "target": "request" }
}

Baca code dan next_action dalam logika program. Tampilkan error dan next untuk dibaca orang. Error API mencantumkan respons error lainnya. Rute analitik POST di bawah ini menerima body JSON dengan kolom project_id, since, until, service_name, release, dan environment yang sama. Kolom body yang tidak dikenal ditolak.

Ukur funnel

Funnel mengukur konversi melalui dua sampai delapan langkah berurutan:

logbrew analytics funnel --project "<project_id>" --since 7d \
  --step page-view /pricing \
  --step interaction checkout_started \
  --step interaction checkout_completed \
  --json

Setiap langkah berikutnya harus punya stempel waktu yang lebih akhir daripada langkah sebelumnya. Satu peristiwa tidak bisa menyelesaikan dua langkah. Unit default-nya adalah sesi. Gunakan --unit identified-user untuk menghitung pengguna lintas sesi. Salin nama peristiwa dari ikhtisar. Rasio dua total yang tidak berhubungan bukan tingkat konversi. Langkah terakhir harus terjadi di dalam periode konversi yang dimulai pada langkah pertama. Atur periode itu dengan --conversion-window, misalnya 30m atau 1h. Default-nya 24 jam, atau seluruh rentang jika rentangnya lebih pendek. Periode konversi tidak boleh lebih panjang dari rentang. Rute API-nya adalah POST /api/telemetry/analytics/funnel. Respons funnel berurutan menampilkan body permintaan dan responsnya.

Jelajahi jalur di sekitar satu peristiwa

Jalur menampilkan urutan peristiwa bernama yang paling umum setelah atau sebelum satu peristiwa jangkar:

logbrew analytics paths following --project "<project_id>" --since 24h \
  --anchor-kind page-view --anchor-event /pricing \
  --json

Gunakan preceding sebagai ganti following untuk peristiwa sebelum jangkar. --depth menentukan jumlah peristiwa di sisi itu, dari 1 sampai 8. Default-nya 4. --path-limit menentukan jumlah jalur, dari 1 sampai 20. Default-nya 10. Peristiwa identik yang berurutan dihitung sebagai satu peristiwa. Tambahkan --keep-repeated untuk mempertahankan setiap peristiwa itu. Jalur memakai ID sesi. Jalur following dimulai pada jangkar pertama di setiap sesi. Jalur preceding berakhir pada jangkar terakhir. Jalur tidak menghitung pengguna dan tidak menunjukkan mengapa suatu aksi gagal. Rute API-nya adalah POST /api/telemetry/analytics/paths.

Baca retensi

Retensi menunjukkan apakah pengguna teridentifikasi kembali setelah peristiwa awal:

logbrew analytics retention --project "<project_id>" --since 30d \
  --start-kind page-view --start-event /signup \
  --return-kind interaction --return-event report_opened \
  --json

--interval bernilai hour, day, week, atau thirty-day. thirty-day berarti 30 hari, bukan satu bulan kalender. --interval-count bernilai dari 1 sampai 31. Default-nya 10. --mode return-on menghitung pengguna yang kembali tepat di setiap periode. return-on-or-after menghitung pengguna yang kembali di periode itu atau sesudahnya. Pengguna hanya dihitung kembali jika kembali setelah peristiwa awalnya. Setiap pengguna dimulai satu kali, pada peristiwa awal pertama dalam rentang. Peristiwa itu belum tentu peristiwa pertama pengguna sepanjang masa. Pengguna yang kembali lebih dari sekali dalam satu periode dihitung satu kali untuk periode itu. Baca jumlah pengguna yang bertahan bersama jumlah pengguna yang memenuhi syarat untuk setiap periode. Pengguna yang periodenya belum berakhir tidak memenuhi syarat. Mereka tidak dihitung sebagai hilang. Misalnya, 40 pengguna yang kembali dari 100 pengguna yang memenuhi syarat berarti retensi 40%. Tingkat kembali yang lebih rendah tidak menunjukkan mengapa orang pergi.

Minta retensi untuk semua aktivitas

Rute API-nya adalah POST /api/telemetry/analytics/retention. Untuk mengukur retensi tanpa nama peristiwa, kirim response_version 2 dan jangan sertakan start_event dan return_event:

curl -sS "https://api.logbrew.co/api/telemetry/analytics/retention" \
  -H "Authorization: Bearer $LOGBREW_ACCOUNT_BEARER" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": "<project_id>",
    "since": "14d",
    "response_version": 2,
    "interval": "day",
    "interval_count": 10,
    "mode": "return_on",
    "cohort_mode": "first_in_range"
  }'

Respons mengisi query.activity_scope dengan all_classified_activity. Tayangan halaman, tayangan layar, atau interaksi apa pun sesudahnya dihitung sebagai kembali. Untuk memilih peristiwa, jangan sertakan response_version dan kirim start_event serta return_event sebagai { "kind": "page_view", "event_name": "/signup" }. Hasil rentang dibagi interval, lalu dikalikan interval_count, harus 500 atau kurang. Misalnya, 14 hari dengan day dan 10 periode menghasilkan 140. Jika Anda tidak mengisi interval, API memakai hour untuk rentang sampai 48 jam dan day untuk rentang yang lebih panjang.

Baca siklus hidup

Siklus hidup memasukkan pengguna teridentifikasi yang melakukan satu peristiwa ke satu kelompok per periode:

logbrew analytics lifecycle --project "<project_id>" --since 30d \
  --event-kind interaction --event report_opened \
  --json

Kelompok	Arti
Baru dalam riwayat teramati	Aktif sekarang, tanpa peristiwa sebelumnya di rentang waktu riwayat.
Kembali	Aktif sekarang dan di periode sebelumnya.
Aktif kembali	Aktif sekarang setelah jeda.
Tidak aktif	Aktif di periode sebelumnya, tetapi tidak sekarang.

“Baru dalam riwayat teramati” tidak berarti pelanggan yang baru pertama kali datang. Aktivitas sebelumnya bisa berada di luar rentang waktu riwayat, yang diatur dengan --history-periods. Jangan jumlahkan total per periode untuk menghitung pengguna unik di seluruh rentang. --history-periods bernilai dari 2 sampai 31 periode sebelum since. Default-nya 2. Riwayat tidak boleh lebih dari 62 hari. Rentang bisa berisi paling banyak 100 periode. Setiap periode punya fully_observed, yang bernilai false jika periode belum berakhir. “Tidak aktif” berarti tidak aktif di periode saat ini, bukan hilang selamanya. Rute API-nya adalah POST /api/telemetry/analytics/lifecycle. Untuk memakai semua aktivitas terklasifikasi sebagai ganti satu peristiwa, kirim response_version 2 dan jangan sertakan event:

{
  "project_id": "<project_id>",
  "since": "30d",
  "response_version": 2,
  "interval": "day",
  "history_period_count": 7
}

Bandingkan dua periode

Minta setiap periode secara terpisah. Gunakan proyek, durasi, nama peristiwa, dan filter yang sama. Bandingkan aktivitas, campuran peristiwa, serta cakupan identitas dan sesi sebelum Anda membandingkan jumlah pengguna. Periode yang belum lengkap bisa menunjukkan aktivitas yang lebih rendah daripada periode yang lengkap.

Pengamatan	Pemeriksaan berikutnya	Batasan
Satu peristiwa meningkat	Periksa sesi dan cakupannya.	Lebih banyak peristiwa tidak berarti lebih banyak orang.
Tingkat konversi berubah	Gunakan langkah funnel dan unit yang sama untuk kedua periode.	Jangan bandingkan definisi funnel yang berbeda.
Pengguna yang kembali menurun	Periksa pengguna yang memenuhi syarat dan periode yang lengkap.	Kohort baru bisa terlihat lebih buruk daripada kohort lama.
Pengguna berhenti di satu langkah	Baca masalah dan log untuk langkah itu.	Rentang waktu yang sama tidak menunjukkan penyebab.

Saat hasil mengarah ke kegagalan, baca masalah dan log terkait untuk proyek dan waktu yang sama. Buka trace hanya jika peristiwa punya tautan trace yang tepat. Rentang waktu yang sama tidak menunjukkan bahwa error menyebabkan penurunan. Untuk mengulangi perbandingan, catat ID proyek, kedua rentang UTC, interval, filter, unit, cakupan, dan status pemotongan. Jangan catat ID pengguna mentah. Untuk kolom respons dan error, baca API Telemetri dan Error API.

Mulai

Konsep

Instal dan kirim

Investigasi

CLI dan agen

Dukungan

Apa itu analitik produk? Metrik dan pengguna yang kembali

Peristiwa, pengguna, dan sesi

Buka ikhtisar di dasbor

Baca ikhtisar proyek

Pisahkan kedua kelompok aktivitas

Ikuti tindakan berikutnya

Panggil API secara langsung

Ukur funnel

Jelajahi jalur di sekitar satu peristiwa

Baca retensi

Minta retensi untuk semua aktivitas

Baca siklus hidup

Bandingkan dua periode

​Peristiwa, pengguna, dan sesi

​Buka ikhtisar di dasbor

​Baca ikhtisar proyek

​Pisahkan kedua kelompok aktivitas

​Ikuti tindakan berikutnya

​Panggil API secara langsung

​Ukur funnel

​Jelajahi jalur di sekitar satu peristiwa

​Baca retensi

​Minta retensi untuk semua aktivitas

​Baca siklus hidup

​Bandingkan dua periode

Peristiwa, pengguna, dan sesi

Buka ikhtisar di dasbor

Baca ikhtisar proyek

Pisahkan kedua kelompok aktivitas

Ikuti tindakan berikutnya

Panggil API secara langsung

Ukur funnel

Jelajahi jalur di sekitar satu peristiwa

Baca retensi

Minta retensi untuk semua aktivitas

Baca siklus hidup

Bandingkan dua periode