So sánh Apogee Watcher và PostHog Web Vitals: Giám sát hiệu năng tổng hợp hay Phân tích người dùng thực?
Bài viết so sánh chi tiết giữa Apogee Watcher (công cụ giám sát PageSpeed tổng hợp dựa trên API) và PostHog Web Vitals (phân tích hiệu năng người dùng thực thông qua SDK). Chúng tôi sẽ phân tích sự khác biệt giữa dữ liệu RUM và Synthetic, ưu nhược điểm của từng công cụ, và giải pháp tối ưu cho các đội ngũ sở hữu sản phẩm so với các đại lý kỹ thuật số quản lý nhiều website.

Core Web Vitals (Chỉ số Web Vitals cốt lõi) xuất hiện ở hai nơi hoàn toàn khác biệt. Một là từ người dùng thực: các chỉ số thu thập từ trình duyệt thông qua SDK phân tích. Hai là từ các bài kiểm tra định kỳ: cơ chế PageSpeed của Google chạy trên một URL mà bạn lựa chọn theo lịch trình đã cài đặt.
PostHog đại diện cho loại thứ nhất về mặt hiệu suất. Tính năng Web Vitals của nó nằm trong phân khúc Web Analytics và sử dụng cùng SDK posthog-js như các tính năng phân tích sản phẩm khác. Ngược lại, Apogee Watcher thuộc loại thứ hai: giám sát PageSpeed đa tenant dựa trên API PageSpeed Insights — kết hợp dữ liệu phòng lab của Lighthouse và dữ liệu CrUX (Chrome User Experience Report) nơi Google cung cấp — dành cho các đội ngũ quản lý nhiều trang web mà không cần cài mã script trên từng tên miền.
PostHog là một bộ sản phẩm mạnh mẽ (cờ tính năng, replay lại phiên, thử nghiệm A/B, phân tích kho dữ liệu). Chúng tôi không xây dựng những thứ đó. Mô-đun Web Vitals của PostHog cũng không thay thế được giám sát tổng hợp (synthetic monitoring) cho các trang web bạn chưa cài đặt công cụ theo dõi, và nó không bao gồm khả năng khám phá tự động, ngân sách hiệu năng, hay RBAC (quyền truy cập dựa trên vai trò) dành cho đại lý mặc định. Quyết định nằm ở vấn đề bạn đang muốn giải quyết trước tiên — và liệu bạn có cần cả hai hay không.
PostHog Web Vitals thực sự là gì?
Tài liệu của PostHog mô tả tính năng tự động thu thập Web Vitals cho các chỉ số FCP, LCP, INP và CLS thông qua thư viện web-vitals của Google. Bạn bật tính năng tự động thu thập Web Vitals trong cài đặt dự án (tách biệt với tính năng tự động thu thập chung) và chạy phiên bản posthog-js v1.141.2 hoặc mới hơn. Các sự kiện được đặt tên là $web_vitals, với các thuộc tính như $web_vitals_LCP_value cho từng chỉ số.
Giao diện người dùng (UI) được xây dựng dành cho các nhà phân tích dữ liệu: Web Analytics → Web Vitals cung cấp các xu hướng, bộ lọc giống như phần còn lại của Web Analytics, và bảng URL được phân loại vào các nhóm tốt / cần cải thiện / kém dựa trên ngưỡng của PostHog (các dải giá trị giống như web.dev). Bạn có thể xem p75, p90 hoặc p99; PostHog khuyên dùng p90 để cân bằng giữa tín hiệu và nhiễu. Thanh công cụ (toolbar) hiển thị các chỉ số quan trọng cho trang bạn đang xem cùng lịch sử của trang đó — rất hữu ích khi bạn gỡ lỗi trực tiếp trên sản phẩm.
Về mặt vận hành, SDK sẽ đóng gói (batch) các chỉ số (xả dữ liệu sau vài giây theo mặc định). Bạn có thể lấy mẫu (sample) sự kiện $web_vitals trong before_send nếu lo ngại về chi phí sự kiện tính phí. PostHog ước tính khoảng 30 sự kiện $web_vitals trên 100 sự kiện $pageview trung bình; các chỉ số được tính phí giống như bất kỳ sự kiện nào khác — xem thêm tại trang giá cả.
Chế độ không sử dụng Cookie (Cookieless mode). Với tính năng theo dõi không cookie của PostHog (cookieless_mode: 'always', hoặc nhánh không cookie của on_reject), posthog-js không gửi dữ liệu $web_vitals sử dụng được: mỗi tải dữ liệu chỉ số cần ID phiên và ID cửa sổ, và ở các chế độ này, đường dẫn phiên thông thường không tồn tại, do đó các chỉ số sẽ bị loại bỏ. Nếu bạn chạy chế độ không cookie always mà không có banner, đừng mong đợi bảng điều khiển Web Vitals đầy đủ chỉ từ PostHog — bạn đã hy sinh một phần độ sâu phân tích đó có chủ đích. Chi tiết SDK có thể thay đổi; hãy kiểm tra tài liệu PostHog khi bạn nâng cấp.
Bạn chỉ đo lường những khách truy cập tải đoạn mã (snippet) và có phiên cho phép thu thập chỉ số (sự đồng ý, trình chặn quảng cáo, cài đặt không cookie, và liệu trang chạy đủ lâu để phát ra chỉ số). Điều này phù hợp với sản phẩm của bạn khi việc thu thập đang bật. Nó không bao gồm hàng chục tên miền khách hàng mà bạn chưa cài đặt công cụ, hay một URL khách hàng tiềm năng trước khi bạn có quyền truy cập.
Ngân sách và cảnh báo qua email: Mỗi công cụ yêu cầu thiết lập như thế nào
PostHog không có đối tượng "ngân sách CWV" kiểu giám sát — không có giới hạn LCP/INP/CLS cho mỗi URL với lịch trình và thời gian làm mát tích hợp sẵn theo cách mà các đội ngũ vận hành hiểu về "ngân sách". Bạn khám phá các chỉ số trong UI Web Vitals; cảnh báo được gắn vào các insight xu hướng trong Product Analytics.
Để nhận được "email khi chỉ số này vượt qua giới hạn", bạn phải tạo hoặc mở một xu hướng (trend) vẽ đúng chuỗi dữ liệu (thường từ các trường $web_vitals), chọn chuỗi mà cảnh báo theo dõi, đặt ngưỡng cố định hoặc tương đối, chọn khoảng thời gian kiểm tra (hàng giờ đến hàng tháng) và thêm email, Slack hoặc webhook. Các đường mục tiêu (goal lines) trên biểu đồ có thể khớp với ngưỡng, nhưng bạn vẫn đang ở trong sản phẩm insight — không phải "thêm ngân sách cho URL này" trong một bước. Ai đó phải duy trì các insight này hợp lệ khi sự kiện, bộ lọc hoặc thuộc tính thay đổi, và căn chỉnh các phần trăm và lấy mẫu với những gì bạn đang cảnh báo.
Watcher đặt ngân sách hiệu năng và email cạnh các bài kiểm tra PageSpeed định kỳ cho tổ chức, trang web hoặc trang mà bạn đã theo dõi — không cần tạo mô hình xu hướng trước đó. Thời gian làm mát có sẵn để giảm nhiễu cảnh báo cho vận hành, không phải để xem xét phễu. Điều này chỉ dành cho synthetic + CrUX; nó không thay thế các cảnh báo của PostHog về đăng ký, doanh thu hoặc bất kỳ thứ gì không liên quan đến PageSpeed.
Các đội ngũ chuyên sâu về PostHog thường tinh chỉnh các insight và cảnh báo về chỉ số, và điều đó là đúng đắn. Nếu công việc là "giữ các trang web của khách hàng trong giới hạn CWV với ít nỗ lực kết nối hơn", một sản phẩm giám sát thường có nghĩa là ít bước hơn.
Apogee Watcher tối ưu hóa cho điều gì?
Apogee Watcher ưu tiên giám sát trước (monitoring-first), không phải phân tích trước. Chúng tôi chạy các bài kiểm tra PageSpeed định kỳ thông qua API của Google, lưu trữ lịch sử theo từng tổ chức, trang web và trang, và hiển thị dữ liệu phòng lab và CrUX cùng nhau để bạn có thể thấy cả "Lighthouse thấy gì" và "người dùng Chrome trải nghiệm quy mô lớn như thế nào" khi CrUX có dữ liệu cho URL đó. Bạn không cần triển khai mã của chúng tôi trên các trang web của khách hàng để có giám sát cơ bản — chúng tôi đánh vào các URL công khai từ cơ sở hạ tầng kiểm tra của Google.
Lựa chọn thiết kế này rất quan trọng đối với các đại lý (agencies):
- Thêm URL staging hoặc production ngay cả khi bộ phận marketing kiểm soát trình quản lý thẻ (tag manager) và không muốn thêm một script khác.
- Cấu trúc Tổ chức, Sites, Pages và vai trò Admin / Manager / Viewer khớp với cách nhân viên đại lý làm việc — không phải một thuộc tính phân tích cho mỗi sản phẩm.
- Crawl sơ đồ trang (sitemap) và HTML để các mẫu và trang đích mới không bị mắc kẹt sau danh sách URL thủ công.
- Ngân sách và cảnh báo tập trung vào "báo cho chúng tôi trước khi CWV của khách hàng trôi đi trong một tuần", không phải biểu đồ phễu.
- Quản lý khách hàng tiềm năng (Leads Management) cho kinh doanh mới: URL khách hàng tiềm năng, báo cáo một trang, liên kết chia sẻ có thời hạn, tiếp cận dựa trên dải điểm — quy trình doanh thu, không phải phân tích phiên.
Chúng tôi không cung cấp một bộ phân tích sản phẩm hoàn chỉnh, replay lại phiên (session replay) hay cờ tính năng (feature flags). Nếu bạn cần những thứ đó, hãy sử dụng một công cụ được xây dựng cho chúng — thường là PostHog.
So sánh trực tiếp: Nơi sự chồng chéo kết thúc
| Chủ đề | PostHog (Web Vitals) | Apogee Watcher |
|---|---|---|
| Nhiệm vụ chính | Hệ điều hành phân tích sản phẩm; Web Vitals là chỉ số người dùng thực từ trình duyệt | Giám sát PageSpeed tổng hợp (Synthetic) + CrUX trong kết quả |
| Công cụ triển khai | Yêu cầu cài posthog-js trên trang web | Không cần script trên các trang được giám sát |
| Chỉ số | FCP, LCP, INP, CLS từ phiên thực tế ($web_vitals) khi đang chạy thu thập | Lighthouse Lab + CrUX (nếu có) thông qua PSI |
| Analytics không dùng Cookie | Với chế độ always (và các đường dẫn không có ID phiên), $web_vitals không điền dữ liệu — xem phần chế độ Cookieless ở trên | Không có snippet; các bài kiểm tra không sử dụng trạng thái phiên của PostHog |
| Tốt nhất cho | "Người dùng của tôi trải nghiệm ứng dụng của mình như thế nào?" | "Các URL này hoạt động thế nào theo lịch trình — và trên nhiều khách hàng?" |
| Đại lý đa trang | Dự án và đội ngũ phân tích — không phải mô hình org/site/page của Watcher | Tổ chức đa tenant, vai trò, khám phá, ngân sách |
| Ngân sách & Cảnh báo email | Dựa trên Insight — xây dựng xu hướng từ $web_vitals, đính kèm cảnh báo với ngưỡng, tần suất, điểm đến; duy trì khi phân tích phát triển | Tích hợp giám sát — ngân sách hiệu năng và cảnh báo email gắn với các bài kiểm tra định kỳ; không cần insight riêng để quản lý trước |
| Tính năng bổ sung | Flags, replay, experiments, cohorts, pipeline kho dữ liệu | Hướng báo cáo kiểu PDF, quy trình khách hàng tiềm năng |
| Hình thức chi phí | Dựa trên sự kiện (chỉ số tính vào hạn ngạch sự kiện) | Đăng ký dựa trên kế hoạch; hạn ngạch PSI được bundle — hãy kiểm tra giá |
Hãy sử dụng bảng này như lưới ra quyết định, không phải bảng thông số kỹ thuật. Cả hai sản phẩm đều thay đổi; hãy xác minh chi tiết trên trang web của từng nhà cung cấp trước khi mua.
Khi nào PostHog là lựa chọn chính tốt hơn
Hãy chọn PostHog khi bạn sở hữu ứng dụng, đã muốn có phân tích sản phẩm, và cần chỉ số quan trọng của người dùng thực (real-user vitals) bên cạnh các bản phát hành, thử nghiệm và phân khúc. Nếu câu hỏi là "thay đổi React đó có làm tổn hại INP của khách hàng trả tiền trên Safari không?", bạn muốn RUM bên trong phân tích — không chỉ là một lần chạy PSI hàng đêm.
Cờ tính năng (Feature flags) và các thử nghiệm nằm cạnh Web Vitals, vì vậy bạn có thể kết nối sự thay đổi điểm số với điều đã được triển khai. Chúng tôi không thay thế lớp đó.
Khi nào Apogee Watcher là lựa chọn chính tốt hơn
Hãy chọn Watcher khi độ phủ tổng hợp (synthetic coverage) và quy trình làm việc của đại lý quan trọng hơn các sự kiện trong ứng dụng:
- Bạn giám sát nhiều trang web của khách hàng hoặc bên thứ ba nơi bạn sẽ không (hoặc không thể) triển khai PostHog cho đường cơ sở.
- Bạn muốn các bài kiểm tra định kỳ, sự tụt giảm (regressions) và ngân sách ngay cả khi lượng truy cập rất ít trong tuần này.
- Khám phá tự động rất quan trọng vì CMS và danh sách URL thay đổi liên tục.
- Bạn bán các gói dịch vụ (retainers) và cần báo cáo sẵn sàng cho khách hàng cùng với sự phân tách vai trò (nội bộ so với khách hàng).
Để biết câu chuyện nâng cấp từ các bài kiểm tra thủ công, hãy xem PageSpeed Insights so với Giám sát Tự động. Để biết thiết lập ở quy mô lớn, bài viết Cách thiết lập Giám sát PageSpeed Tự động cho Nhiều Trang web theo dõi quy trình làm việc mà chúng tôi quan tâm.
Ngăn xếp bổ sung (Lớp, đừng thay thế)
Đối với nhiều đại lý, thiết lập thực tế là cả hai: PostHog (hoặc tương tự) cho hành vi và chỉ số người dùng thực trên các trang web bạn kiểm soát, cộng với Watcher cho giám sát tổng hợp đa trang, CrUX nơi Google cung cấp, và các quy trình tìm kiếm khách hàng. Các câu hỏi khác nhau:
- PostHog Web Vitals — Người dùng đã trải nghiệm gì trên các tuyến đường chúng ta đã cài đặt công cụ?
- Watcher — Các URL của chúng ta có còn nằm trong ngân sách không — phòng lab + CrUX đã hiển thị gì trong lần chạy định kỳ gần nhất?
Chỉ RUM có thể bỏ lỡ các URL trước khi ra mắt hoặc không có lưu lượng truy cập. Chỉ Synthetic có thể bỏ lỡ các điểm đau của tương tác đã đăng nhập hoặc nặng về JS. Cùng nhau, chúng bao phủ nhiều nền tảng hơn.
Nếu bạn đã sử dụng PostHog, Watcher thêm vào gì?
Bạn đã có $web_vitals, biểu đồ và các cảnh báo xu hướng tùy chọn — ngoại trừ trong các thiết lập không dùng cookie nơi các chỉ số không kích hoạt (xem ở trên). Watcher không sao chép flags, replay hay experiments. Nó thêm vào:
Tín hiệu CWV khi PostHog không thể gửi chỉ số. Chế độ không dùng Cookie always (hoặc nhánh không dùng cookie không có phiên) để lại chế độ xem Web Vitals trống rỗng. Watcher vẫn chạy PSI + CrUX định kỳ trên các URL bạn quan tâm — độc lập với cookie, sự đồng ý hay việc tải snippet.
Điểm số mà không cần lưu lượng truy cập. PSI có thể chạy theo lịch trình khi lượt truy cập hiếm, trang mới, hoặc bản dựng trên staging không có gán thẻ production. PostHog cần khách truy cập; Watcher cần một URL công khai.
Các trang không có PostHog. Các gói dịch vụ, bàn giao, các stack thuộc sở hữu của marketing, hoặc khách hàng tiềm năng trước hợp đồng: bạn vẫn nhận được phòng lab + CrUX từ Google mà không cần cài đặt phân tích khác cho mỗi tên miền.
Hình dạng danh mục đầu tư. Tổ chức, Sites, Pages, Admin / Manager / Viewer, và khám phá qua sitemap + crawl khớp với "nhiều khách hàng, nhiều URL", không phải một dự án phân tích cho mỗi sản phẩm.
Cảnh báo giám sát. Ngưỡng và email trên kết quả kiểm tra và thời gian làm mát, mà không cần xây dựng một xu hướng (trend) cho mỗi chỉ số (xem phần Ngân sách và cảnh báo email ở trên).
Quy trình kinh doanh. Quản lý khách hàng tiềm năng — URL khách hàng tiềm năng, báo cáo một trang, liên kết chia sẻ, tiếp cận dựa trên dải điểm — nơi PageSpeed là một phần của kinh doanh mới, không phải phân tích sản phẩm.
Hai lăng kính trên một trang web. Trên trang web marketing của riêng bạn, bạn có thể so sánh RUM trình duyệt với phòng lab + CrUX định kỳ. Khi chúng mâu thuẫn, đó thường là phòng lab so với thực địa so với phiên — hữu ích, không phải mâu thuẫn.
Watcher không phải là sản phẩm phân tích thứ hai. Nó thêm vào giám sát bên ngoài, kiểm soát truy cập đại lý và lịch sử tổng hợp được lưu trữ bên cạnh những gì PostHog đã làm.
Các hạn chế chúng tôi không né tránh
Watcher không phải là replay lại phiên (session replay), phễu (funnels) hay cờ tính năng (feature flags).
PostHog Web Vitals là các luồng sự kiện từ trình duyệt, không phải các lần chạy PSI được lưu trữ của Watcher với ngữ cảnh Lighthouse đầy đủ theo lịch trình. Chúng là các đường ống khác nhau. Trong các thiết lập PostHog không dùng cookie mà $web_vitals không bao giờ đến được, bạn hoàn toàn không có chuỗi CWV trong PostHog — giám sát tổng hợp (ở đây hoặc nơi khác) là cách bạn giữ điểm số mà không thay đổi cài đặt quyền riêng tư của mình.
PostHog không dùng Cookie và Watcher hoạt động song song: lựa chọn quyền riêng tư phân tích của bạn không chặn các bài kiểm tra PageSpeed phía máy chủ.
CrUX cần đủ lưu lượng truy cập Chrome thực; các URL yên tĩnh có thể không hiển thị dữ liệu thực địa. RUM, CrUX và phòng lab có thể mâu thuẫn — đó là bình thường.
Kết luận
Tài liệu Web Vitals của PostHog bao gồm các chỉ số người dùng thực cho các đội ngũ sử dụng SDK. Watcher bao gồm tổng hợp định kỳ + CrUX cho các đội ngũ chạy nhiều URL và quy trình hướng tới khách hàng. Quyết định dựa trên độ phủ (có script hay không), câu hỏi (người dùng hay URL), và mô hình tổ chức (dự án phân tích hay danh mục đầu tư đại lý) — sau đó sử dụng một công cụ hoặc cả hai.
Nếu Watcher phù hợp với cách bạn làm việc, hãy kiểm tra giá cả và tính năng cho các nhà vận hành solo và đại lý — bao gồm những gì có sẵn cho Quản lý Khách hàng tiềm năng — trước khi bạn giả định mọi ghế ngồi đều có quyền truy cập tìm kiếm đầy đủ.
Câu hỏi thường gặp (FAQs)
Apogee Watcher có phải là sự thay thế cho PostHog không? Không. PostHog là phân tích sản phẩm; Web Vitals chỉ là một phần. Watcher là giám sát PageSpeed / CWV trên danh mục đầu tư. Sử dụng không cái nào, một cái, hoặc cả hai.
PostHog có thay thế được giám sát Lighthouse định kỳ không? Không đối với các URL bạn chưa cài đặt công cụ, hoặc các môi trường không có lưu lượng truy cập. Các lần chạy tổng hợp vẫn quan trọng.
Watcher có thay thế được chỉ số người dùng thực không? Không. RUM bắt được hành vi sau tải (SPA, quy trình đã đăng nhập). CrUX giúp ở cấp URL khi Google có dữ liệu; nó không phải là RUM đầy đủ.
Tôi nên tin tưởng phần trăm (percentile) nào? PostHog cung cấp p75–p99 và gợi ý p90 trên Web Vitals. Watcher tuân theo phân phối PSI / CrUX. Sử dụng từng cái cho những gì nó đo lường.
Cảnh báo CWV có khó hơn trong PostHog so với Watcher không? Thường là có nếu bạn có ý định "cảnh báo về hiệu suất trang theo lịch trình". PostHog: xu hướng + quy tắc cảnh báo trên các insight. Watcher: các ngưỡng trên kết quả kiểm tra. Bảo trì khác nhau.
PostHog Web Vitals có hoạt động trong chế độ không dùng Cookie không?
Không trong các thiết lập không dùng Cookie nghiêm ngặt (always, và các đường dẫn mà các chỉ số không thể gắn ID phiên — xem ở trên). Để có phòng lab + CrUX mà không có luồng đó, hãy thêm giám sát tổng hợp (Watcher hoặc quy trình PSI khác).
Các phiên bản SDK, tên sự kiện và giá cả có thể thay đổi. Kiểm tra posthog.com/docs/web-analytics/web-vitals và apogeewatcher.com trước khi bạn mua.



