PostHog là gì? Context warehouse và MCP cho AI agent

Đến năm 2026, PostHog không còn là một công cụ phân tích sản phẩm (Product Analytics) đơn thuần. Khi AI agent tràn vào quy trình làm sản phẩm, PostHog đã tự làm một cú refactor lớn cho kiến trúc của mình, từ công cụ phân tích thành nền tảng để dựng "sản phẩm tự lái" (self-driving product). Ở đó, dữ liệu vừa nằm trên dashboard cho người xem, vừa làm "thị giác" cho AI agent thông qua lớp kho ngữ cảnh.

PostHog hiện hoạt động như một kho ngữ cảnh (context warehouse) tập trung, nơi hợp nhất dữ liệu hành vi người dùng, lỗi kỹ thuật và dữ liệu kinh doanh từ các nguồn bên ngoài.

Thay vì để AI agent của bạn "mò mẫm" trong đống mã nguồn (repo) mà không hiểu thực tế sử dụng, PostHog đưa cho chúng đủ ngữ cảnh để tự chẩn đoán vấn đề và đề xuất hành động cụ thể.

Để làm được điều đó, PostHog dựa vào Model Context Protocol (MCP), một giao thức chuẩn hóa cho phép các agent (như Claude Code hay Cursor) truy cập trực tiếp vào kho dữ liệu sản phẩm thời gian thực. Chính sự kết hợp này thu hẹp "khoảng cách ngữ cảnh" (context gap), biến AI từ một trợ lý viết code thành một thành viên thực thụ trong quy trình vận hành sản phẩm.

Kho ngữ cảnh PostHog hợp nhất dữ liệu hành vi sản phẩm và dữ liệu kinh doanh thành một nguồn duy nhất cho AI agent đọc

PostHog là gì?

PostHog là một bộ công cụ hạ tầng dành cho nhà phát triển, hợp nhất các chức năng vốn bị phân mảnh trước đây: phân tích web/app, ghi lại phiên truy cập (session replay), cờ tính năng (feature flags), thử nghiệm A/B (experiments) và theo dõi lỗi (error tracking). Hiện có hơn 500.000 đội ngũ đang dùng bộ công cụ này.

Điểm mấu chốt nằm ở chỗ tất cả các công cụ trên đều chia sẻ chung một lớp dữ liệu (data layer). Bạn không cần phải tích hợp 5 SDK khác nhau; một khi đã cài đặt PostHog, mọi sự kiện (events) đều có sẵn cho cả bộ phận sản phẩm lẫn kỹ thuật.

Về mô hình triển khai, bạn có hai lựa chọn chính:

Bản Cloud: được PostHog quản lý hoàn toàn, tách biệt lưu trữ và tính toán.
Bản tự lưu trữ (self-hosting): dành cho các bên cần tuân thủ dữ liệu khắt khe (fintech, y tế). Tuy nhiên, bạn nên biết trước về "stability ceiling" (ngưỡng ổn định): PostHog khuyến nghị chuyển sang Cloud nếu lượng sự kiện vượt quá 100.000/tháng. Duy trì cụm ClickHouse cho bản tự host ngốn khoảng 6-8 giờ bảo trì mỗi tháng, và đó mới chỉ là các tác vụ nâng cấp và dọn dẹp (housekeeping).

Khả năng thu thập của PostHog dựa trên autocapture: nó tự động ghi lại các tương tác (click, pageview) mà không cần bạn định nghĩa schema thủ công, nên thời gian của bạn dồn vào việc đọc dữ liệu chứ không phải đi khai báo tag.

Vì sao AI agent thiếu ngữ cảnh sản phẩm

Vấn đề lớn nhất của AI agent hiện nay là "mù dữ liệu thực tế". Một công ty trung bình chạy 106 ứng dụng SaaS, nên dữ liệu nằm kẹt trong từng silo biệt lập, và không có cái nào chịu nói chuyện với cái nào.

Dữ liệu nằm rời rạc trong nhiều ứng dụng SaaS, khiến AI agent chỉ nhìn thấy mã nguồn mà không thấy hành vi người dùng hay doanh thu

Nếu bạn chỉ đưa mã nguồn cho một AI agent, nó sẽ gặp các nút thắt (bottleneck) sau:

Thiếu thứ tự ưu tiên: agent thấy một lỗi (stack trace) nhưng không biết lỗi đó ảnh hưởng đến bao nhiêu người dùng VIP hoặc bao nhiêu doanh thu định kỳ hàng tháng (MRR) vì không có kết nối với dữ liệu Stripe.
Khoảng cách ngữ cảnh: AI có thể viết code rất nhanh, nhưng nếu không biết người dùng thực tế đang kẹt ở bước nào trong phễu (funnel), nó sẽ đưa ra những giải pháp tối ưu sai chỗ.
Vấn đề niềm tin: 2/3 chuyên gia dữ liệu không tin tưởng hoàn toàn vào dữ liệu mà hệ thống AI của họ đang dùng. Khi thiếu ngữ cảnh, agent thường đưa ra các câu trả lời tự tin nhưng sai lệch (hallucination) để lấp đầy khoảng trống thông tin, và giọng điệu chắc nịch đó mới là thứ khó phát hiện.

Context warehouse khác data warehouse ở đâu?

PostHog xây dựng context warehouse để giải quyết bài toán "data readiness": dữ liệu phải sẵn sàng cho cả người lẫn máy truy cập tức thì.

So sánh data warehouse truyền thống cần pipeline ETL đứng giữa với context warehouse nơi mọi công cụ đọc chung một nguồn

Đặc tính	Data warehouse truyền thống	Context warehouse (PostHog)
Dữ liệu đầu vào	Pipeline ETL phức tạp từ nhiều nguồn	Sự kiện sản phẩm có sẵn + warehouse sources
Cấu trúc	Tách biệt ingestion, modeling và storage	Hợp nhất ingestion pipeline và modeling vào một công cụ
Đối tượng dùng	Data engineer, BI analyst	Product engineer và AI agent
Glue (kết nối)	Cần reverse-ETL để đẩy ngược dữ liệu	Không cần pipeline; analytics, flags đều đọc chung một nguồn
Tốc độ	Xử lý theo lô (batch), độ trễ cao	Thời gian thực cho các vòng lặp tự vận hành

Điểm đáng để ý ở cột bên phải không phải là tốc độ, mà là chỗ đường ống dữ liệu biến mất: khi analytics và feature flags cùng đọc một nguồn thì bạn không còn khâu reverse-ETL để đẩy ngược dữ liệu về nơi cần dùng nữa.

Ngữ cảnh gồm những gì?

Để agent làm việc được, PostHog gom nguồn ngữ cảnh từ ba lớp:

Ba lớp ngữ cảnh chồng lên nhau: dữ liệu sử dụng, dữ liệu bên ngoài từ Stripe và HubSpot, và dữ liệu doanh nghiệp từ Slack và Notion

Dữ liệu sử dụng (usage data): bao gồm sự kiện, session replay, theo dõi lỗi và khảo sát người dùng. Đây là những gì diễn ra "bên trong" sản phẩm.
Dữ liệu bên ngoài (warehouse sources): các nguồn dữ liệu được quản lý (managed sources) như Stripe, HubSpot, Salesforce, Postgres... giúp agent đối chiếu hành vi người dùng với tình trạng tài chính hoặc hợp đồng.
Dữ liệu doanh nghiệp: các cuộc hội thoại Slack, tài liệu Notion và mã nguồn được kết nối để agent hiểu "tại sao" một tính năng lại được xây dựng như vậy.

Vì sao PostHog viết lại kho dữ liệu

PostHog đã refactor toàn bộ kiến trúc kho dữ liệu, chuyển từ ClickHouse sang DuckDB chạy trên S3. ClickHouse rất mạnh cho phân tích sự kiện "nóng", nhưng làm kho dữ liệu tổng quát thì đuối, vì nó thiếu cost-based query optimizer (bộ tối ưu hóa truy vấn dựa trên chi phí) và vì hành vi của nó không nhất quán giữa các phiên bản. Bỏ cả một engine mà mình đã dựng nguyên hệ thống lên trên không phải là quyết định người ta đưa ra cho vui.

Kiến trúc mới của PostHog: mỗi tổ chức chạy một instance DuckDB riêng trong Firecracker MicroVM, dữ liệu nằm trên S3

Kiến trúc mới dựa trên:

Firecracker MicroVM: mỗi tổ chức có một instance DuckDB riêng biệt, đảm bảo cách ly tính toán (compute isolation). Không có truy vấn của ai làm ảnh hưởng đến hiệu suất của bạn.
DuckHog: một DuckDB extension cho phép tính toán cục bộ (local compute). AI agent có thể kéo một tập hợp con dữ liệu về xử lý cực nhanh thay vì phải liên tục truy xuất ngược lên S3 bucket.
Postgres Wire Protocol: kết nối mọi công cụ BI hoặc agent như một database Postgres tiêu chuẩn. Hệ thống "thức dậy" từ trạng thái nghỉ chỉ mất khoảng 300 ms, tức là nhanh đến mức người dùng không kịp nhận ra nó vừa ngủ.

Agent đọc dữ liệu qua MCP server như thế nào

PostHog MCP server là một endpoint miễn phí, để agent trong các công cụ như Cursor hoặc Claude Code "nói chuyện" thẳng với dữ liệu thay vì chờ bạn copy một bảng số liệu vào khung chat.

Các nhóm công cụ MCP chính:

query-trends, query-funnel: giúp agent hiểu xu hướng hành vi.
execute-sql: chạy SQL trực tiếp trên kho dữ liệu để lấy raw data.
insight-create: cho phép agent tự tạo báo cáo để con người duyệt.

Mỗi công cụ truy vấn còn có một biến thể "actors" liệt kê đúng những người dùng đứng sau một điểm dữ liệu, nghĩa là một con số tụt giảm trở thành một danh sách phiên truy cập mà bạn xem lại được.

Quy trình thực tế: kỹ sư yêu cầu agent "Fix lỗi crash nhiều nhất tuần này". Agent gọi MCP lấy top 5 lỗi, dùng execute-sql để xem stack trace, đối chiếu mã nguồn, tự viết bản sửa lỗi và mở pull request ngay trong editor.

Lệnh cài đặt MCP server:

bash

npx @posthog/wizard mcp add

Những gì PostHog chưa làm được

Dưới góc độ kỹ thuật, PostHog vẫn còn những chỗ chưa tới nơi:

Độ trưởng thành của tooling: trình biên tập SQL và các tính năng BI vẫn được PostHog thừa nhận là "chưa sẵn sàng" (not quite ready) cho các chuyên gia phân tích dữ liệu chuyên sâu cần khả năng mô hình hóa cực kỳ phức tạp.
Lớp ngữ nghĩa (semantic layer): lớp này đã tồn tại nhưng còn ở giai đoạn beta. Cơ chế quản trị đi theo hướng con người phê duyệt: agent chỉ được đề xuất một chỉ số, một người thật bấm duyệt thì nó mới thành chuẩn, và chỉ cần sửa lại định nghĩa là chỉ số rơi ngược về trạng thái đề xuất. Đây là mức quản trị khác với những gì một stack dbt trưởng thành đang có.
Số lượng nguồn tích hợp: danh mục managed sources của PostHog phủ tốt các hệ thống phổ biến như Stripe hay Postgres, nhưng vẫn hẹp hơn các nền tảng ETL chuyên dụng: công cụ ngách hoặc hệ thống cũ trong doanh nghiệp có thể không có sẵn connector.
Vận hành bản self-host: rào cản kỹ thuật của việc tự host là rất lớn nếu bạn không có đội ngũ DevOps cứng tay để trị ClickHouse.

Khi nào nên dùng PostHog

Bạn nên chọn PostHog nếu bạn là một đội ngũ kỹ sư muốn có kết quả phân tích ngay mà không phải dựng cả một stack dữ liệu cồng kềnh. Với agentic workflow, tầng ngữ cảnh được tích hợp sẵn chính là thứ khiến tôi nghiêng về PostHog, thay vì đi ghép ba bốn công cụ rời rồi tự viết keo dán giữa chúng.

Còn nếu doanh nghiệp của bạn đã có một đội ngũ dữ liệu hùng hậu với stack Snowflake + dbt + Fivetran và quy trình quản trị cực kỳ khắt khe, hãy coi PostHog như một lớp middleware để thu thập dữ liệu sản phẩm, trước khi đẩy chúng về kho tổng để xử lý chuyên sâu hơn. Đổi lại, bạn nhận thêm một hệ thống nữa phải nuôi.