> ## 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. # Phân tích sản phẩm là gì? Chỉ số và người dùng quay lại > Chọn dự án và khoảng ngày. Xem hoạt động, phễu, tỷ lệ quay lại và vòng đời. Kiểm tra độ bao phủ dữ liệu trước khi dựa vào kết quả. Phân tích sản phẩm cho thấy người dùng sử dụng ứng dụng của bạn như thế nào. LogBrew đọc các hành động sản phẩm mà ứng dụng gửi lên, gồm lượt xem trang, lượt xem màn hình và tương tác. Dùng [Ghi nhận sự kiện sản phẩm](/vi/guides/product-events) để gửi các sự kiện này kèm ngữ cảnh người dùng và phiên. Mỗi kết quả thuộc về một dự án và một khoảng thời gian. Tên dịch vụ không dùng để chọn dự án. Log và vấn đề là các tín hiệu riêng. Có log hoặc vấn đề không có nghĩa là có dữ liệu phân tích trong cùng khoảng thời gian. ## Sự kiện, người dùng và phiên | Đơn vị | Ý nghĩa | | - | - | | Sự kiện | Một hành động được ghi lại. Một người có thể gửi nhiều sự kiện. | | Người dùng đã định danh | ID chủ thể ổn định, opaque (không mang thông tin nhận dạng), do ứng dụng cung cấp, có loại `user`. | | Chủ thể ẩn danh | ID chủ thể có khai báo loại, nhưng không phải người dùng. Chủ thể này không bao giờ được tính là người dùng. | | Phiên | ID phiên do ứng dụng cung cấp một cách tường minh. Một người có thể có nhiều phiên. | Ví dụ, 200 hành động trong 20 phiên không có nghĩa là 20 người đã dùng ứng dụng. Tổng số sự kiện là số chính xác trong khoảng thời gian đã chọn. Số người dùng, phiên và chủ thể ẩn danh duy nhất là số ước tính. Dùng ID opaque. Không dùng tên, địa chỉ email hoặc dữ liệu cá nhân khác làm ID. Phản hồi phân tích không bao giờ trả về ID người dùng hoặc ID phiên thô. ## Mở trang tổng quan trên bảng điều khiển 1. Mở **Phân tích** trong bảng điều khiển LogBrew. 2. Chọn một dự án. 3. Chọn **24 giờ**, **7 ngày**, **14 ngày**, **30 ngày** hoặc **Tùy chỉnh**. 4. Xem biểu đồ hoạt động, rồi xem **Sự kiện hàng đầu** và **Trang và màn hình hàng đầu**. 5. Mở **Độ phủ và giới hạn** trước khi đọc số người dùng. Với **Tùy chỉnh**, chọn ngày đầu và ngày cuối, rồi chọn **Áp dụng**. Khoảng ngày bao gồm cả hai ngày này. Ví dụ, từ ngày 12 tháng 4 đến ngày 16 tháng 4 là 5 ngày. Bảng điều khiển dùng ngày theo UTC. Khoảng tùy chỉnh dài tối đa 31 ngày và không được chứa ngày trong tương lai. Bảng điều khiển cũng hiển thị hai xu hướng người dùng cho cùng dự án và khoảng ngày. **Người dùng có quay lại không?** cho thấy tỷ lệ quay lại. **Tập người dùng đang thay đổi thế nào?** cho thấy các nhóm vòng đời. Cả hai xu hướng dùng toàn bộ hoạt động đã phân loại của người dùng đã định danh. Bạn không chọn sự kiện nào cho hai xu hướng này. ## Đọc tổng quan dự án ```bash theme={null} logbrew analytics overview --project "" --since 7d --json ``` Thêm `--until ` để đặt thời điểm kết thúc. Thời điểm này không thuộc khoảng thời gian. `--interval` nhận `auto`, `1m`, `5m`, `15m`, `1h`, `6h` hoặc `1d`. `--top-limit` đặt số dòng trong mỗi danh sách hàng đầu, từ `1` đến `20`. Mặc định là `10`. Thêm `--service`, `--release` hoặc `--environment` để lọc theo đúng ngữ cảnh. Endpoint API là `GET /api/telemetry/analytics/overview`. Bản tổng quan gồm tổng số hoạt động, chuỗi thời gian, các hành động hàng đầu và hoạt động đã phân loại. Đoạn trích sau cho thấy các tổng số và độ bao phủ của chúng: ```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" } } ``` Năm số đếm trong `subject_coverage` cộng lại bằng `summary.actions`. Chỉ `identified_user_events` được tính vào số người dùng. `anonymous_actions` gồm bốn trạng thái còn lại. Trong ví dụ này, 8 sự kiện của chủ thể ẩn danh đến từ khoảng 7 chủ thể ẩn danh khác nhau. Cả hai số đều không phải số người dùng. Danh sách hàng đầu bị cắt bớt không chứng tỏ các sự kiện có số lượng thấp hơn không tồn tại. `analysis_level` là `no_data`, `event_only`, `user_level` hoặc `user_and_session`. Giá trị này cho biết dữ liệu trả lời được những câu hỏi nào. Đây là mức cao nhất mà `summary` hoặc `classified_activity` hỗ trợ. Mức này không có nghĩa là cả hai nhóm đều có người dùng hoặc phiên. ### Tách riêng hai nhóm hoạt động | Trường phản hồi | Sự kiện được tính | | - | - | | `summary`, `coverage`, `series`, `top_actions` | Sự kiện hành động sản phẩm, kể cả hành động không có phân loại được hỗ trợ. | | `classified_activity` | Lượt xem trang, lượt xem màn hình và tương tác. Lượt xem trang không phải là hành động. | Lượt xem màn hình và tương tác đã phân loại cũng là hành động. Không cộng `summary.actions` với `classified_activity.summary.events`. Đọc độ bao phủ của nhóm mà bạn dùng. Các số đếm chủ thể trong `classified_activity.coverage.subject_coverage` cộng lại bằng `classified_activity.summary.events`. `summary.actions` có thể bằng `0` trong khi lượt xem trang đã phân loại vẫn cung cấp số người dùng và số phiên. Kiểm tra `classified_activity` trước khi kết luận rằng không có hoạt động sản phẩm. ### Làm theo bước tiếp theo được đề xuất `next_action` có `code`, `target` và `reason`. Trường này cho biết chỗ thiếu quan trọng nhất trong dữ liệu ghi nhận, hoặc bước phân tích tiếp theo: | `next_action.code` | Ý nghĩa | | - | - | | `capture_product_activity` | Không có sự kiện sản phẩm nào khớp với phạm vi. | | `classify_product_activity` | Có sự kiện, nhưng không sự kiện nào là lượt xem trang, lượt xem màn hình hoặc tương tác. | | `identify_product_users` | Không sự kiện nào có chủ thể với loại `user`. | | `sessionize_product_activity` | Không sự kiện nào có ID phiên. | | `capture_funnel_steps` | Có ít hơn hai sự kiện đã phân loại có tên. | | `build_product_funnel` | Dữ liệu đủ để dựng phễu. | Thay đổi cách ghi nhận trong ứng dụng, rồi kiểm tra một sự kiện mới. Sự kiện cũ không chứng tỏ thay đổi đó đã có tác dụng. ### Gọi API trực tiếp Gửi bearer token của tài khoản. Gửi `response_version=3` để nhận cùng phản hồi mà CLI đọc. Nếu bỏ `response_version`, API trả về phiên bản `1`. Phiên bản này không có số đếm chủ thể ẩn danh và không có `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=" \ --data-urlencode "since=7d" \ --data-urlencode "response_version=3" ``` `since` là một thời lượng dương, như `24h`, `7d` hoặc `30d`, hoặc một dấu thời gian RFC3339. `until` là dấu thời gian RFC3339 không bắt buộc. Khoảng thời gian bao gồm `since` và không bao gồm `until`. Nếu bỏ `until`, khoảng thời gian kết thúc tại thời điểm gửi yêu cầu. Khoảng thời gian không được dài quá 31 ngày. Với khoảng từ ngày 12 tháng 4 đến ngày 16 tháng 4 năm 2026, gửi `2026-04-12T00:00:00Z` làm `since` và `2026-04-17T00:00:00Z` làm `until`. Khoảng thời gian dài hơn 31 ngày trả về 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" } } ``` Đọc `code` và `next_action` trong logic chương trình. Hiển thị `error` và `next` cho người đọc. [Lỗi API](/vi/reference/api-errors) liệt kê các phản hồi lỗi khác. Các route phân tích `POST` bên dưới nhận body JSON có cùng các trường `project_id`, `since`, `until`, `service_name`, `release` và `environment`. Trường lạ trong body sẽ bị từ chối. ## Đo phễu Phễu đo tỷ lệ chuyển đổi qua 2 đến 8 bước có thứ tự: ```bash theme={null} logbrew analytics funnel --project "" --since 7d \ --step page-view /pricing \ --step interaction checkout_started \ --step interaction checkout_completed \ --json ``` Mỗi bước sau phải có dấu thời gian muộn hơn bước trước. Một sự kiện không thể hoàn thành hai bước. Đơn vị mặc định là phiên. Dùng `--unit identified-user` để đếm người dùng qua nhiều phiên. Sao chép tên sự kiện từ bản tổng quan. Tỷ lệ giữa hai tổng số không liên quan không phải là tỷ lệ chuyển đổi. Bước cuối phải xảy ra trong cửa sổ chuyển đổi, tính từ bước đầu tiên. Đặt cửa sổ này bằng `--conversion-window`, ví dụ `30m` hoặc `1h`. Mặc định là 24 giờ, hoặc toàn bộ khoảng thời gian nếu khoảng đó ngắn hơn. Cửa sổ không được dài hơn khoảng thời gian. Route API là `POST /api/telemetry/analytics/funnel`. Mục [phản hồi phễu theo thứ tự](/vi/reference/telemetry-response-shapes#ordered-funnel-response) cho thấy body yêu cầu và phản hồi. ## Khám phá đường dẫn quanh một sự kiện Đường dẫn cho thấy các chuỗi sự kiện có tên phổ biến nhất sau hoặc trước một sự kiện neo: ```bash theme={null} logbrew analytics paths following --project "" --since 24h \ --anchor-kind page-view --anchor-event /pricing \ --json ``` Dùng `preceding` thay cho `following` để xem các sự kiện trước sự kiện neo. `--depth` đặt số sự kiện ở phía đó, từ `1` đến `8`. Mặc định là `4`. `--path-limit` đặt số đường dẫn, từ `1` đến `20`. Mặc định là `10`. Các sự kiện giống nhau liên tiếp được tính là một sự kiện. Thêm `--keep-repeated` để giữ từng sự kiện. Đường dẫn dùng ID phiên. Đường dẫn sau sự kiện neo bắt đầu tại sự kiện neo đầu tiên trong mỗi phiên. Đường dẫn trước sự kiện neo kết thúc tại sự kiện neo cuối cùng. Đường dẫn không đếm người dùng và không cho biết vì sao một hành động thất bại. Route API là `POST /api/telemetry/analytics/paths`. ## Đọc tỷ lệ quay lại Tỷ lệ quay lại cho biết người dùng đã định danh có quay lại sau một sự kiện bắt đầu hay không: ```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` là `hour`, `day`, `week` hoặc `thirty-day`. `thirty-day` là 30 ngày, không phải một tháng theo lịch. `--interval-count` từ `1` đến `31`. Mặc định là `10`. `--mode return-on` đếm lượt quay lại trong đúng từng kỳ. `return-on-or-after` đếm lượt quay lại trong hoặc sau từng kỳ. Lượt quay lại phải xảy ra sau sự kiện bắt đầu của người dùng. Mỗi người dùng chỉ bắt đầu một lần, tại sự kiện bắt đầu đầu tiên trong khoảng thời gian. Sự kiện đó không phải lúc nào cũng là sự kiện đầu tiên của người dùng từ trước đến nay. Người dùng quay lại nhiều lần trong một kỳ chỉ được tính một lần cho kỳ đó. Đọc số người dùng quay lại cùng với số người dùng đủ điều kiện của từng kỳ. Người dùng có kỳ chưa kết thúc thì chưa đủ điều kiện. Họ không bị tính là đã rời bỏ. Ví dụ, 40 người dùng quay lại trên 100 người dùng đủ điều kiện là tỷ lệ quay lại 40%. Tỷ lệ quay lại thấp hơn không cho biết vì sao mọi người rời đi. ### Lấy tỷ lệ quay lại theo mọi hoạt động Route API là `POST /api/telemetry/analytics/retention`. Để đo tỷ lệ quay lại mà không cần tên sự kiện, gửi `response_version` `2` và bỏ `start_event` cùng `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": "", "since": "14d", "response_version": 2, "interval": "day", "interval_count": 10, "mode": "return_on", "cohort_mode": "first_in_range" }' ``` Phản hồi đặt `query.activity_scope` thành `all_classified_activity`. Mọi lượt xem trang, lượt xem màn hình hoặc tương tác về sau đều được tính là lượt quay lại. Để chọn sự kiện, bỏ `response_version` và gửi cả `start_event` lẫn `return_event` dưới dạng `{ "kind": "page_view", "event_name": "/signup" }`. Độ dài khoảng thời gian chia cho độ dài một kỳ, rồi nhân với `interval_count`, không được vượt quá 500. Ví dụ, 14 ngày với `day` và `10` kỳ cho kết quả 140. Nếu bỏ `interval`, API dùng `hour` cho khoảng thời gian tối đa 48 giờ và `day` cho khoảng dài hơn. ## Đọc vòng đời Vòng đời xếp mỗi người dùng đã định danh có thực hiện một sự kiện vào một nhóm trong mỗi kỳ: ```bash theme={null} logbrew analytics lifecycle --project "" --since 30d \ --event-kind interaction --event report_opened \ --json ``` | Nhóm | Ý nghĩa | | - | - | | Mới trong lịch sử quan sát | Hoạt động ở kỳ này, không có sự kiện nào trước đó trong cửa sổ lịch sử. | | Quay lại | Hoạt động ở kỳ này và kỳ trước. | | Hoạt động trở lại | Hoạt động ở kỳ này sau một khoảng gián đoạn. | | Không hoạt động | Hoạt động ở kỳ trước nhưng không hoạt động ở kỳ này. | “Mới trong lịch sử quan sát” không có nghĩa là khách hàng lần đầu. Hoạt động trước đó có thể nằm ngoài cửa sổ lịch sử, được đặt bằng `--history-periods`. Không cộng tổng của các kỳ để đếm người dùng duy nhất trong cả khoảng thời gian. `--history-periods` nhận từ `2` đến `31` kỳ trước `since`. Mặc định là `2`. Lịch sử không được dài hơn 62 ngày. Khoảng thời gian có tối đa 100 kỳ. Mỗi kỳ có `fully_observed`, bằng `false` khi kỳ chưa kết thúc. “Không hoạt động” nghĩa là không hoạt động trong kỳ hiện tại, không phải đã rời bỏ vĩnh viễn. Route API là `POST /api/telemetry/analytics/lifecycle`. Để dùng mọi hoạt động đã phân loại thay vì một sự kiện, gửi `response_version` `2` và bỏ `event`: ```json theme={null} { "project_id": "", "since": "30d", "response_version": 2, "interval": "day", "history_period_count": 7 } ``` ## So sánh hai kỳ Gửi yêu cầu riêng cho từng kỳ. Dùng cùng dự án, thời lượng, tên sự kiện và bộ lọc. So sánh hoạt động, cơ cấu sự kiện, độ bao phủ danh tính và phiên trước khi so sánh số người dùng. Kỳ chưa kết thúc có thể có hoạt động thấp hơn kỳ đã kết thúc. | Quan sát | Kiểm tra tiếp theo | Giới hạn | | - | - | - | | Một sự kiện tăng | Kiểm tra số phiên và độ bao phủ của sự kiện đó. | Nhiều sự kiện hơn không có nghĩa là nhiều người hơn. | | Tỷ lệ chuyển đổi thay đổi | Dùng cùng các bước phễu và cùng đơn vị cho cả hai kỳ. | Không so sánh các định nghĩa phễu khác nhau. | | Số người dùng quay lại giảm | Kiểm tra người dùng đủ điều kiện và các kỳ đã kết thúc. | Nhóm người dùng gần đây có thể trông kém hơn nhóm cũ. | | Người dùng dừng ở một bước | Đọc các vấn đề và log của bước đó. | Trùng khoảng thời gian không chứng tỏ nguyên nhân. | Khi kết quả cho thấy có lỗi, đọc các vấn đề và log liên quan trong cùng dự án và cùng thời gian. Chỉ mở trace khi sự kiện có liên kết trace chính xác. Trùng khoảng thời gian không chứng tỏ lỗi đã gây ra mức sụt giảm. Để lặp lại một phép so sánh, ghi lại ID dự án, cả hai khoảng thời gian UTC, độ dài kỳ, bộ lọc, đơn vị, độ bao phủ và trạng thái cắt bớt. Không ghi lại ID người dùng thô. Để xem các trường phản hồi và lỗi, đọc [Telemetry API](/vi/reference/telemetry-api) và [Lỗi API](/vi/reference/api-errors). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.