Skip to main content
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 để 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

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

Thêm --until <RFC3339> để đặ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:
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

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: 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.
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:
Đọc code và next_action trong logic chương trình. Hiển thị error và next cho người đọc. Lỗi API 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ự:
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ự 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:
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:
--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:
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ỳ:
“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:

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. 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 và Lỗi API.