> ## Documentation Index
> Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Apa itu analitik produk? Metrik dan pengguna yang kembali

> Pilih proyek dan tanggal. Baca aktivitas, funnel, retensi, dan perubahan siklus hidup. Periksa cakupan data sebelum bertindak berdasarkan hasilnya.

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](/id/guides/product-events) 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

1. Buka **Analitik** di dasbor LogBrew.
2. Pilih satu proyek.
3. Pilih **24 jam**, **7 hari**, **14 hari**, **30 hari**, atau **Kustom**.
4. Baca grafik aktivitas, lalu **Peristiwa teratas** dan
   **Halaman dan layar teratas**.
5. 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.

## <span id="use-the-analytics-api">Baca ikhtisar proyek</span>

```bash theme={null}
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:

```json theme={null}
{
  "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`.

```bash theme={null}
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`:

```json theme={null}
{
  "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](/id/reference/api-errors) 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.

## <span id="measure-a-funnel">Ukur funnel</span>

Funnel mengukur konversi melalui dua sampai delapan langkah berurutan:

```bash theme={null}
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](/id/reference/telemetry-response-shapes#ordered-funnel-response)
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:

```bash theme={null}
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:

```bash theme={null}
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`:

```bash theme={null}
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:

```bash theme={null}
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`:

```json theme={null}
{
  "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](/id/reference/telemetry-api)
dan [Error API](/id/reference/api-errors).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.