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
- Mở Phân tích trong bảng điều khiển LogBrew.
- Chọn một dự án.
- Chọn 24 giờ, 7 ngày, 14 ngày, 30 ngày hoặc Tùy chỉnh.
- 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.
- Mở Độ phủ và giới hạn trước khi đọc số người dùng.
Đọc tổng quan dự án
--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:
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ửiresponse_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:
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ự:--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: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:
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.
