> ## 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. # Ürün analizleri nedir? Metrikler ve geri dönen kullanıcılar > Proje ve tarih seçin. Etkinliği, dönüşüm hunilerini, elde tutmayı ve yaşam döngüsünü okuyun. Harekete geçmeden önce veri kapsama oranını kontrol edin. Ürün analizleri, insanların uygulamanızı nasıl kullandığını gösterir. LogBrew, uygulamanızın gönderdiği ürün aksiyonlarını okur. Bunlara sayfa görüntülemeleri, ekran görüntülemeleri ve etkileşimler dâhildir. Bu olayları kullanıcı ve oturum bağlamıyla göndermek için [Ürün olaylarını yakalama](/tr/guides/product-events) rehberini kullanın. Her sonuç tek bir proje ve tek bir zaman aralığı içindir. Hizmet adı bir proje seçmez. Loglar ve sorunlar ayrı sinyallerdir. Bunların bulunması, aynı aralık için analiz verisi olduğu anlamına gelmez. ## Olaylar, kullanıcılar ve oturumlar | Birim | Anlamı | | - | - | | Olay | Kaydedilen tek bir aksiyon. Bir kişi çok sayıda olay gönderebilir. | | Tanımlı kullanıcı | Uygulamanın verdiği, `user` türünde, sabit ve opak bir özne kimliği. | | Anonim özne | Kullanıcı olmayan, türü belli bir özne kimliği. Asla kullanıcı olarak sayılmaz. | | Oturum | Uygulamanın açıkça verdiği bir oturum kimliği. Bir kişinin çok sayıda oturumu olabilir. | Örneğin 20 oturumdaki 200 aksiyon, uygulamayı 20 kişinin kullandığı anlamına gelmez. Olay toplamları seçilen aralık için kesindir. Benzersiz kullanıcı, oturum ve anonim özne sayıları yaklaşıktır. Opak kimlikler kullanın. Adları, e-posta adreslerini veya diğer kişisel verileri kimlik olarak kullanmayın. Analiz yanıtları asla ham kullanıcı veya oturum kimliği döndürmez. ## Paneldeki genel bakışı açın 1. LogBrew panelinde **Analizler** sayfasını açın. 2. Bir proje seçin. 3. **24 saat**, **7 gün**, **14 gün**, **30 gün** veya **Özel** seçin. 4. Etkinlik grafiğini, ardından **En sık olaylar** ve **En sık yüzeyler** bölümlerini okuyun. 5. Kullanıcı sayılarını okumadan önce **Kapsam ve sınırlar** bölümünü açın. **Özel** için ilk ve son günü seçin, ardından **Uygula** seçin. İki gün de aralığa dâhildir. Örneğin 12 Nisan ile 16 Nisan arası beş gündür. Panel UTC tarihlerini kullanır. Özel bir aralık en fazla 31 gün olabilir ve gelecekteki tarihleri içeremez. Panel aynı proje ve tarihler için iki kullanıcı eğilimi de gösterir. **Kullanıcılar geri geliyor mu?** elde tutmayı gösterir. **Kullanıcı tabanı nasıl değişiyor?** yaşam döngüsü gruplarını gösterir. İki eğilim de tanımlı kullanıcıların sınıflandırılmış tüm etkinliğini kullanır. Bunlar için olay seçmezsiniz. ## Projenin genel bakışını okuyun ```bash theme={null} logbrew analytics overview --project "" --since 7d --json ``` Aralığa dâhil olmayan bir bitiş zamanı için `--until ` ekleyin. `--interval`; `auto`, `1m`, `5m`, `15m`, `1h`, `6h` veya `1d` kabul eder. `--top-limit`, her en sık listesindeki satır sayısını `1` ile `20` arasında belirler. Varsayılan `10` olur. Tam bağlama göre filtrelemek için `--service`, `--release` veya `--environment` ekleyin. API uç noktası `GET /api/telemetry/analytics/overview` olur. Genel bakış etkinlik toplamlarını, bir zaman serisini, en sık aksiyonları ve sınıflandırılmış etkinliği içerir. Bu alıntı toplamları ve kapsama oranlarını gösterir: ```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" } } ``` Beş `subject_coverage` sayısının toplamı `summary.actions` değerine eşittir. Yalnızca `identified_user_events` kullanıcılara sayılır. `anonymous_actions` diğer dört durumu içerir. Bu örnekte 8 anonim özne olayı yaklaşık 7 farklı anonim özneden gelir. İki sayı da kullanıcı sayısı değildir. Kısaltılmış bir en sık listesi, daha az görülen olayların olmadığını göstermez. `analysis_level` değeri `no_data`, `event_only`, `user_level` veya `user_and_session` olur. Verinin hangi sorulara yanıt verebildiğini gösterir. Bu düzey, `summary` veya `classified_activity` gruplarından birinin desteklediği en yüksek düzeydir. İki grupta da kullanıcı veya oturum olduğu anlamına gelmez. ### İki etkinlik grubunu ayrı tutun | Yanıt alanları | Sayılan olaylar | | - | - | | `summary`, `coverage`, `series`, `top_actions` | Desteklenen bir sınıflandırması olmayan aksiyonlar dâhil ürün aksiyonu olayları. | | `classified_activity` | Sayfa görüntülemeleri, ekran görüntülemeleri ve etkileşimler. Sayfa görüntülemeleri aksiyon değildir. | Sınıflandırılmış ekran görüntülemeleri ve etkileşimler aynı zamanda aksiyondur. `summary.actions` değerini `classified_activity.summary.events` değerine eklemeyin. Kullandığınız grubun kapsama oranını okuyun. `classified_activity.coverage.subject_coverage` içindeki özne sayılarının toplamı `classified_activity.summary.events` değerine eşittir. Sınıflandırılmış sayfa görüntülemeleri kullanıcı ve oturum sayılarını sağlarken `summary.actions` değeri `0` olabilir. Ürün etkinliği olmadığı sonucuna varmadan önce `classified_activity` grubunu kontrol edin. ### Sonraki aksiyonu izleyin `next_action` bir `code`, bir `target` ve bir `reason` içerir. En önemli yakalama eksiğini veya sonraki analiz adımını gösterir: | `next_action.code` | Anlamı | | - | - | | `capture_product_activity` | Kapsamla eşleşen ürün olayı yok. | | `classify_product_activity` | Olaylar var, ama hiçbiri sayfa görüntüleme, ekran görüntüleme veya etkileşim değil. | | `identify_product_users` | Hiçbir olayda `user` türünde bir özne yok. | | `sessionize_product_activity` | Hiçbir olayda oturum kimliği yok. | | `capture_funnel_steps` | Adlandırılmış sınıflandırılmış olayların sayısı ikiden az. | | `build_product_funnel` | Veri bir dönüşüm hunisini destekleyebilir. | Uygulamada yakalama değişikliğini yapın, ardından yeni bir olayı kontrol edin. Eski olaylar değişikliğin çalıştığını göstermez. ### API'yi doğrudan çağırın Bir hesap bearer tokenı gönderin. CLI'ın okuduğu yanıtın aynısını almak için `response_version=3` gönderin. `response_version` göndermezseniz API `1` sürümünü döndürür. Bu sürümde anonim özne sayıları veya `subject_coverage` yoktur. ```bash theme={null} curl -sS -G "https://api.logbrew.co/api/telemetry/analytics/overview" \ -H "Authorization: Bearer $LOGBREW_ACCOUNT_BEARER" \ --data-urlencode "project_id=" \ --data-urlencode "since=7d" \ --data-urlencode "response_version=3" ``` `since`, `24h`, `7d` veya `30d` gibi pozitif bir süre ya da bir RFC3339 zaman damgasıdır. `until` isteğe bağlı bir RFC3339 zaman damgasıdır. Aralık `since` değerini içerir, `until` değerini içermez. `until` göndermezseniz aralık istek zamanında biter. Bir aralık 31 günden uzun olamaz. 12 Nisan ile 16 Nisan 2026 arası için `since` olarak `2026-04-12T00:00:00Z`, `until` olarak `2026-04-17T00:00:00Z` gönderin. 31 günden uzun bir aralık HTTP `422` döndürür: ```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" } } ``` Program mantığında `code` ve `next_action` değerlerini okuyun. Bir kişiye `error` ve `next` değerlerini gösterin. Diğer hata yanıtları [API hataları](/tr/reference/api-errors) sayfasında listelenir. Aşağıdaki `POST` analiz rotaları aynı `project_id`, `since`, `until`, `service_name`, `release` ve `environment` alanlarını içeren bir JSON gövdesi alır. Bilinmeyen gövde alanları reddedilir. ## Dönüşüm hunisini ölçün Dönüşüm hunisi, sıralı iki ila sekiz adım boyunca dönüşümü ölçer: ```bash theme={null} logbrew analytics funnel --project "" --since 7d \ --step page-view /pricing \ --step interaction checkout_started \ --step interaction checkout_completed \ --json ``` Sonraki her adımın zaman damgası bir önceki adımdan daha geç olmalıdır. Tek bir olay iki adımı tamamlayamaz. Varsayılan birim oturumdur. Kullanıcıları oturumlar boyunca saymak için `--unit identified-user` kullanın. Olay adlarını genel bakıştan kopyalayın. Birbiriyle ilgisiz iki toplamın oranı bir dönüşüm oranı değildir. Son adım, ilk adımda başlayan dönüşüm süresi içinde gerçekleşmelidir. Bu süreyi `--conversion-window` ile ayarlayın, örneğin `30m` veya `1h`. Varsayılan 24 saattir. Seçilen aralık daha kısaysa varsayılan, aralığın tamamıdır. Dönüşüm süresi seçilen aralıktan uzun olamaz. API rotası `POST /api/telemetry/analytics/funnel` olur. [Sıralı dönüşüm hunisi yanıtı](/tr/reference/telemetry-response-shapes#ordered-funnel-response) istek gövdesini ve yanıtı gösterir. ## Bir olayın etrafındaki yolları keşfedin Yollar, bir çapa olaydan sonraki veya önceki adlandırılmış olayların en sık dizilerini gösterir: ```bash theme={null} logbrew analytics paths following --project "" --since 24h \ --anchor-kind page-view --anchor-event /pricing \ --json ``` Çapadan önceki olaylar için `following` yerine `preceding` kullanın. `--depth`, o taraftaki olay sayısını `1` ile `8` arasında belirler. Varsayılan `4` olur. `--path-limit`, yol sayısını `1` ile `20` arasında belirler. Varsayılan `10` olur. Art arda gelen aynı olaylar tek olay sayılır. Her birini tutmak için `--keep-repeated` ekleyin. Yollar oturum kimliklerini kullanır. Sonraki olaylara giden bir yol her oturumdaki ilk çapada başlar. Önceki olaylardan gelen bir yol son çapada biter. Yollar kullanıcıları saymaz ve bir aksiyonun neden başarısız olduğunu göstermez. API rotası `POST /api/telemetry/analytics/paths` olur. ## Elde tutmayı okuyun Elde tutma, tanımlı kullanıcıların bir başlangıç olayından sonra geri dönüp dönmediğini gösterir: ```bash theme={null} logbrew analytics retention --project "" --since 30d \ --start-kind page-view --start-event /signup \ --return-kind interaction --return-event report_opened \ --json ``` `--interval` değeri `hour`, `day`, `week` veya `thirty-day` olur. `thirty-day` takvim ayı değil, 30 gündür. `--interval-count` değeri `1` ile `31` arasındadır. Varsayılan `10` olur. `--mode return-on` her tam dönemdeki geri dönüşleri sayar. `return-on-or-after` her dönemde veya sonrasında olan geri dönüşleri sayar. Geri dönüş, kullanıcının başlangıç olayından sonra gerçekleşmelidir. Her kullanıcı aralıktaki ilk başlangıç olayında bir kez başlar. Bu olay her zaman kullanıcının ilk olayı değildir. Bir dönemde birden fazla geri dönen kullanıcı o dönem için bir kez sayılır. Her dönem için elde tutulan sayıyı uygun kullanıcı sayısıyla birlikte okuyun. Dönemi henüz bitmemiş kullanıcılar uygun değildir. Kaybedilmiş olarak sayılmazlar. Örneğin 100 uygun kullanıcıdan 40'ının geri dönmesi %40 elde tutmadır. Daha düşük bir geri dönüş oranı, insanların neden ayrıldığını göstermez. ### Tüm etkinlik için elde tutma isteyin API rotası `POST /api/telemetry/analytics/retention` olur. Elde tutmayı olay adları olmadan ölçmek için `response_version` değerini `2` olarak gönderin ve `start_event` ile `return_event` alanlarını göndermeyin: ```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": "", "since": "14d", "response_version": 2, "interval": "day", "interval_count": 10, "mode": "return_on", "cohort_mode": "first_in_range" }' ``` Yanıt `query.activity_scope` değerini `all_classified_activity` yapar. Sonraki her sayfa görüntüleme, ekran görüntüleme veya etkileşim geri dönüş sayılır. Olay seçmek için `response_version` göndermeyin. `start_event` ve `return_event` alanlarının ikisini de `{ "kind": "page_view", "event_name": "/signup" }` biçiminde gönderin. Aralığın dönem süresine bölümü ile `interval_count` değerinin çarpımı 500 veya daha az olmalıdır. Örneğin `day` ve `10` dönemle 14 gün 140 eder. `interval` göndermezseniz API 48 saate kadar olan aralıklar için `hour`, daha uzun aralıklar için `day` kullanır. ## Yaşam döngüsünü okuyun Yaşam döngüsü, bir olayı gerçekleştiren tanımlı kullanıcıları her dönem için bir gruba yerleştirir: ```bash theme={null} logbrew analytics lifecycle --project "" --since 30d \ --event-kind interaction --event report_opened \ --json ``` | Grup | Anlamı | | - | - | | Gözlemlenen geçmişte yeni | Şu anda etkin, geçmiş aralığında daha önceki bir olayı yok. | | Geri dönen | Hem şu anda hem önceki dönemde etkin. | | Yeniden etkinleşen | Bir aradan sonra şu anda etkin. | | Etkin olmayan | Önceki dönemde etkindi ama şu anda değil. | Gözlemlenen geçmişte yeni, ilk kez gelen bir müşteri anlamına gelmez. Daha önceki etkinlik, `--history-periods` ile ayarlanan geçmiş aralığının dışında olabilir. Aralık boyunca benzersiz kullanıcıları saymak için dönem toplamlarını toplamayın. `--history-periods`, `since` öncesindeki `2` ile `31` arasında dönemdir. Varsayılan `2` olur. Geçmiş 62 günden uzun olamaz. Aralıkta en fazla 100 dönem olabilir. Her dönemde `fully_observed` bulunur. Dönem bitmemişse bu değer `false` olur. Etkin olmayan, kalıcı olarak kaybedilmiş değil, mevcut dönemde etkin olmayan anlamına gelir. API rotası `POST /api/telemetry/analytics/lifecycle` olur. Tek bir olay yerine sınıflandırılmış tüm etkinliği kullanmak için `response_version` değerini `2` olarak gönderin ve `event` alanını göndermeyin: ```json theme={null} { "project_id": "", "since": "30d", "response_version": 2, "interval": "day", "history_period_count": 7 } ``` ## İki dönemi karşılaştırın Her dönemi ayrı isteyin. Aynı projeyi, süreyi, olay adlarını ve filtreleri kullanın. Kullanıcı sayılarını karşılaştırmadan önce etkinliği, olay dağılımını, kimlik ve oturum kapsama oranlarını karşılaştırın. Tamamlanmamış bir dönem, tamamlanmış bir dönemden daha düşük etkinlik gösterebilir. | Gözlem | Sonraki kontrol | Sınır | | - | - | - | | Bir olay arttı | Oturumlarını ve kapsama oranını kontrol edin. | Daha fazla olay daha fazla kişi olduğunu göstermez. | | Bir dönüşüm oranı değişti | İki dönem için de aynı huni adımlarını ve birimi kullanın. | Farklı huni tanımlarını karşılaştırmayın. | | Geri dönen kullanıcılar azaldı | Uygun kullanıcıları ve tamamlanmış dönemleri kontrol edin. | Yeni bir kohort, eski bir kohorttan daha kötü görünebilir. | | Kullanıcılar bir adımda duruyor | O adımın sorunlarını ve loglarını okuyun. | Ortak bir zaman aralığı nedeni göstermez. | Bir sonuç bir hataya işaret ettiğinde aynı proje ve zaman için ilgili sorunları ve logları okuyun. Bir izi yalnızca bir olayın tam bir iz bağlantısı varsa açın. Ortak bir zaman aralığı, bir düşüşe bir hatanın neden olduğunu göstermez. Bir karşılaştırmayı tekrarlamak için proje kimliğini, iki UTC aralığını, dönem süresini, filtreleri, birimi, kapsama oranlarını ve kısaltma durumlarını kaydedin. Ham kullanıcı kimliklerini kaydetmeyin. Yanıt alanları ve hatalar için [Telemetri API'si](/tr/reference/telemetry-api) ve [API hataları](/tr/reference/api-errors) sayfalarını okuyun. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.