PostHog

Adapty có thể chuyển các sự kiện gói đăng ký (mua hàng, gia hạn, hoàn tiền, bắt đầu dùng thử) đến luồng sự kiện của PostHog, để chúng kết hợp với phần còn lại của dữ liệu của bạn.

Mỗi sự kiện bao gồm doanh thu, đơn vị tiền tệ, cửa hàng và thông tin sản phẩm, cùng với paywall và biến thể A/B test đã tạo ra giao dịch mua đó. Bất kỳ công cụ nào của PostHog đều có thể sử dụng dữ liệu này ngay khi nó được nhận.

Các sự kiện gói đăng ký của Adapty bổ sung thêm chiều doanh thu vào mọi thứ bạn đã theo dõi trong PostHog:

• Những hành động in-app nào dự đoán một gói đăng ký? Tương quan các sự kiện PostHog của bạn với trial_started và subscription_started để tìm ra hành vi dẫn đến mua hàng.
• Biến thể thử nghiệm nào mang lại doanh thu cao hơn? Dùng các sự kiện doanh thu của Adapty làm chỉ số cho một thử nghiệm PostHog trên bất kỳ thay đổi sản phẩm nào. A/B test của Adapty bao gồm cả paywall và onboarding.
• Điều gì xảy ra trước khi hoàn tiền? Tạo một insight từ subscription_refunded, sau đó mở hồ sơ người dùng đằng sau đó và xem các bản ghi phiên của họ.
• Lỗi có ảnh hưởng đến việc gia hạn không? Đối chiếu theo dõi lỗi với subscription_renewal_cancelled, sự kiện này kích hoạt ngay khi người dùng tắt tự động gia hạn — sớm hơn nhiều so với subscription_expired.
• Người đăng ký giữ chân tốt hơn người dùng miễn phí như thế nào? Tạo cohort và đường cong giữ chân dựa trên trạng thái truy cập — xem Cách phân biệt người đăng ký và người dùng miễn phí.
• Paywall và biến thể nào tạo ra doanh thu? Các sự kiện mua hàng mang theo thông tin paywall và biến thể đã tạo ra chúng, giúp bạn phân tích doanh thu theo từng paywall. Ghi lại lượt xem paywall bằng SDK của PostHog để đo tỷ lệ chuyển đổi từ xem sang mua hàng.
• Đặt câu hỏi trên cả hai bộ dữ liệu bằng insights hoặc SQL.

Cách tích hợp hoạt động

PostHog nhận diện từng người dùng bằng một chuỗi gọi là distinct_id. Toàn bộ tích hợp này phụ thuộc vào việc Adapty và PostHog đồng thuận về chuỗi đó.

1. PostHog SDK gán cho người dùng một distinct_id. Khi khởi chạy lần đầu, chuỗi này có phạm vi thiết bị và ẩn danh. Nhưng bạn có thể gán giá trị tùy chỉnh khi đăng nhập, hoặc đặt lại khi đăng xuất.
2. Mỗi lần khởi chạy ứng dụng, sau Adapty.activate() và trước khi bất kỳ giao dịch mua nào có thể xảy ra, hãy truyền distinct_id vào Adapty bằng setIntegrationIdentifier(). Adapty đính kèm giá trị này vào hồ sơ người dùng Adapty dưới dạng posthog_distinct_user_id.
3. Khi người dùng bắt đầu dùng thử hoặc thực hiện mua hàng, máy chủ của Adapty gửi sự kiện tới API capture của PostHog kèm theo distinct_id đó. Quá trình trao đổi diễn ra server-to-server, bên ngoài ứng dụng của bạn.
4. PostHog đính kèm sự kiện vào người dùng sở hữu distinct_id đó, nhờ vậy doanh thu từ gói đăng ký sẽ xuất hiện cùng với mọi hoạt động khác của người dùng trong ứng dụng của bạn.

Khớp ID của Adapty với PostHog

Cả hai hệ thống đều phải dùng cùng một distinct_id cho một người dùng, nếu không một người sẽ bị tách thành hai thực thể không liên kết với nhau. Có hai cách để tránh tình trạng này, và cách nào phù hợp phụ thuộc vào thời điểm có thể xảy ra giao dịch mua.

Nếu giao dịch mua yêu cầu đăng nhập, hãy gọi identify() của PostHog với Customer User ID của bạn vào thời điểm người dùng đăng nhập. Adapty đã sử dụng giá trị đó khi không có thông tin nào khác, vì vậy cả hai hệ thống sẽ khớp nhau.

Nếu người dùng ẩn danh có thể mua hàng, hãy đọc distinct_id của PostHog và truyền vào Adapty qua setIntegrationIdentifier. Gọi hàm này mỗi lần khởi động sau Adapty.activate(), và gọi lại sau mỗi lần PostHog reset(). Hồ sơ người dùng ẩn danh không có Customer User ID, vì vậy ID của chính PostHog là giá trị duy nhất mà cả hai hệ thống có thể dùng chung — xem Cấu hình mã ứng dụng của bạn.

Dù bạn chọn cách nào, giá trị đó phải tồn tại qua lần cài đặt lại. Adapty tạo một hồ sơ người dùng mới sau mỗi lần cài đặt lại, còn PostHog tạo một distinct_id ẩn danh mới cho mỗi thiết bị, vì vậy cả hai hệ thống đều không tự lưu giữ danh tính qua sự kiện đó. Adapty có chuyển tiếp mức độ truy cập đã trả phí giữa các hồ sơ người dùng ẩn danh của một người dùng, nhưng điều đó chỉ liên kết các mức độ truy cập chứ không liên kết danh tính analytics — hồ sơ người dùng kế thừa vẫn gửi sự kiện dưới ID của chính nó. Nếu không có một ID ổn định do backend của bạn quản lý, một người đăng ký cài đặt lại ứng dụng sẽ hiển thị trong PostHog như một người dùng mới với sự kiện gia hạn nhưng không có giao dịch mua trước đó.

ID không khớp sẽ gây ra phân mảnh dữ liệu — xem Một người dùng xuất hiện dưới nhiều danh tính.

Hướng dẫn cài đặt

Sao chép project token của PostHog

1. Đăng nhập vào deployment lưu trữ dữ liệu của bạn — US Cloud hoặc EU Cloud — và chọn project bạn muốn kết nối.

2. Vào Settings > Project > General và tìm phần Project token & ID.

   

3. Sao chép Project token. Token bắt đầu bằng phc_. PostHog mô tả đây là token chỉ ghi và an toàn để công khai, nên bạn không cần phải xoay vòng token này.

Cấu hình Adapty

1. Mở Integrations > PostHog trong Adapty Dashboard.

2. Bật toggle PostHog.

3. Dán token vào Project API key. Adapty sẽ kiểm tra token với PostHog khi lưu — nếu token không hợp lệ, thao tác sẽ thất bại ngay lập tức thay vì âm thầm bỏ qua các sự kiện.

4. Phần “server location” phụ thuộc vào cài đặt của bạn.

• Nếu bạn dùng PostHog Cloud, đặt Region theo deployment bạn đã đăng nhập — US Cloud hoặc EU Cloud. Để trống trường PostHog Instance URL.
  • Nếu bạn chạy instance của riêng mình, chọn Self-hosted và điền vào trường PostHog Instance URL. Không cần chọn region. Adapty phải có thể truy cập instance đó mà không cần proxy / VPN.

5. Dưới mục How the revenue data should be send, chọn loại doanh thu mà Adapty sẽ gửi đi. Ba tùy chọn tương ứng với các chế độ xem doanh thu trong Adapty Analytics, vì vậy lựa chọn của bạn cũng xác định chế độ xem mà số liệu PostHog của bạn cần khớp với.

6. Cấu hình các tùy chọn còn lại:

7. Đổi tên hoặc tắt từng sự kiện trong phần Events names. PostHog chấp nhận bất kỳ tên sự kiện nào miễn là không rỗng, vì vậy hãy dùng tên phù hợp với hệ thống phân loại hiện tại của bạn.

8. Nhấn Save.

Giữ dữ liệu sandbox tách biệt khỏi môi trường production

Adapty gửi các giao dịch sandbox và production qua cùng một integration, nên cả hai đều xuất hiện trong cùng một project PostHog. Integration này chỉ nhận một Project API key duy nhất, không có key sandbox riêng để trỏ sang nơi khác.

Việc cấp cho bản build phát triển của bạn một project PostHog riêng cũng không ngăn được các sự kiện sandbox xuất hiện trong project production. Sandbox là thuộc tính của giao dịch từ cửa hàng, không phải của bản build. Các giao dịch mua qua App Store review và TestFlight đều là giao dịch sandbox từ bản build production.

Instead, separate the two with queries. Every event includes an environment property set to Sandbox or Production. Filter it to isolate actual revenue:

WHERE properties.environment = 'Production'

Cấu hình mã ứng dụng

1. Lấy distinct_id hiện tại từ SDK của PostHog:

   • Mỗi lần khởi chạy ứng dụng, sau Adapty.activate() và trước khi có bất kỳ giao dịch mua nào xảy ra. PostHog sẽ gán các sự kiện trước đó cho một người dùng khác.
   • Sau khi PostHog gọi reset(), thường được các ứng dụng chạy khi đăng xuất. reset() tạo ra một ID ẩn danh mới và không liên kết nó với người dùng trước, vì vậy nếu dùng giá trị cũ sẽ vẫn trỏ đến người dùng vừa đăng xuất.

2. Truyền giá trị đó vào Adapty bằng setIntegrationIdentifier().

let distinctId = PostHogSDK.shared.getDistinctId()

do {
    try await Adapty.setIntegrationIdentifier(.posthogDistinctUserId(distinctId))
} catch {
    // handle the error
}

Adapty.setIntegrationIdentifier(
    AdaptyIntegrationIdentifier.posthogDistinctUserId(PostHog.distinctId())
) { error ->
    if (error != null) {
        // handle the error
    }
}

Adapty.setIntegrationIdentifier(
    AdaptyIntegrationIdentifier.posthogDistinctUserId(PostHog.distinctId()),
    error -> {
        if (error != null) {
            // handle the error
        }
    }
);

try {
    final distinctId = await Posthog().getDistinctId();

    await Adapty().setIntegrationIdentifier(
        key: "posthog_distinct_user_id",
        value: distinctId,
    );
} on AdaptyError catch (adaptyError) {
    // handle the error
} catch (e) {
    // handle the error
}

const posthog = usePostHog();

try {
    await adapty.setIntegrationIdentifier(
        "posthog_distinct_user_id",
        posthog.getDistinctId()
    );
} catch (error) {
    // handle `AdaptyError`
}

Xác minh tích hợp

1. Kích hoạt một giao dịch mua sandbox, sau đó mở Event Feed trong Adapty Dashboard. Mỗi lần gửi sẽ hiển thị kèm kết quả. Adapty xác minh Project API key và URL instance của bạn khi lưu, vì vậy lỗi ở bước này rất hiếm khi xảy ra. Các nguyên nhân thường gặp:

   • Key ngừng hoạt động. PostHog trả về 401 nếu bạn xóa key tích hợp.
   • Instance ngừng phản hồi. Adapty dừng chờ sau 10 giây. Có thể ảnh hưởng đến các triển khai tự host.

   Di chuột qua sự kiện thất bại để đọc phản hồi từ PostHog.

2. Trong PostHog, mở giao diện Activity và tìm kiếm sự kiện. Thuộc tính environment của giao dịch mua của bạn phải là Sandbox.

3. Mở hồ sơ của người dùng đó và kiểm tra tab Distinct IDs. Các sự kiện của ứng dụng và sự kiện server của Adapty phải thuộc về cùng một người. Nếu có hai người cho cùng một người dùng, nghĩa là các ID không khớp — xem Một người dùng xuất hiện thành nhiều người.

Báo cáo doanh thu trong PostHog

Adapty Analytics vẫn là nguồn dữ liệu chính xác cho các con số doanh thu, vì nó tính toán từ dữ liệu đầy đủ của cửa hàng trong khi PostHog chỉ nhận những gì integration này chuyển tiếp. Nếu bạn cũng muốn xem doanh thu trên dashboard PostHog bên cạnh các chỉ số sản phẩm, tính năng Revenue Analytics của PostHog đọc dữ liệu từ các thuộc tính event mà bạn chỉ định. Mở Data management > Revenue trong PostHog và ánh xạ:

Hãy để tùy chọn “values are in cents” của PostHog ở trạng thái tắt. Adapty gửi số thập phân, không phải đơn vị tiền nhỏ nhất.

Cấu trúc sự kiện PostHog

Adapty gửi các sự kiện bạn đã bật trong mục Events names trên trang tích hợp PostHog, mỗi sự kiện tương ứng với một capture request:

{
  "api_key": "phc_YOUR_PROJECT_TOKEN",
  "distinct_id": "john.doe@example.com",
  "timestamp": "2026-01-08T11:06:12+00:00",
  "event": "subscription_started",
  "properties": {
    "$ip": "10.168.1.1",
    "$geoip_time_zone": "America/New_York",
    "$geoip_disable": true,
    "$set": {
      "email": "user@example.com",
      "first_name": "John",
      "last_name": "Doe",
      "birthday": "1990-01-01",
      "gender": "male",
      "os": "iOS"
    },
    "*": "{{other_event_properties}}"
  }
}

Năm thuộc tính chỉ dành cho webhook sẽ không xuất hiện ở đây — xem Giới hạn.

Thứ tự ưu tiên Distinct ID

Adapty sử dụng giá trị đầu tiên mà nó phát hiện được:

Adapty xác định thứ tự này theo từng sự kiện, không phải theo từng người dùng. Một sự kiện xảy ra trước khi lệnh gọi setIntegrationIdentifier của bạn được thực thi sẽ được ghi nhận với ID có thứ tự ưu tiên thấp hơn, và PostHog sẽ ghi lại một người dùng thứ hai cho cùng một người dùng đó.

Chọn một trong hai cách thiết lập trong Ghép ID của Adapty với PostHog, sau đó đặt giá trị đó trước khi bất kỳ sự kiện nào có thể kích hoạt. Đối với những người dùng đã bị tách, xem Một người dùng xuất hiện dưới dạng nhiều persons.

Thuộc tính IP và vị trí

Để phân khúc các sự kiện Adapty theo vị trí, hãy sử dụng thuộc tính store_country và profile_country. Adapty tắt tính năng tra cứu vị trí của PostHog, vì vậy PostHog sẽ không tự thêm các giá trị $geoip_* nào. Ba thuộc tính dưới đây áp dụng theo từng sự kiện, do đó cài đặt dự án và các sự kiện của bạn sẽ không bị ảnh hưởng.

Thuộc tính người dùng

Mọi thứ bên trong $set đều trở thành thuộc tính person của PostHog thay vì thuộc tính sự kiện. PostHog gắn thuộc tính person vào người dùng chứ không phải vào một sự kiện đơn lẻ, vì vậy chúng mô tả trạng thái hiện tại của người dùng thay vì một thời điểm cụ thể. Adapty bỏ qua bất kỳ trường nào không có giá trị, và loại bỏ $set hoàn toàn khi không có trường nào trong số đó.

Giới hạn

• Không có mức độ truy cập hay trạng thái gói đăng ký. Sự kiện access_level_updated chỉ dành riêng cho webhook integration, nên Adapty không gửi bất kỳ trường nào mô tả quyền truy cập hiện tại của người dùng đến PostHog — xem Cách phân biệt người dùng trả phí và người dùng miễn phí.
• Không có dữ liệu lịch sử. Adapty chỉ chuyển tiếp các sự kiện từ thời điểm bạn bật integration. Các giao dịch trong quá khứ sẽ không bao giờ được gửi đến PostHog.
• PostHog không gắn thẻ địa lý cho sự kiện Adapty. PostHog xác định vị trí dựa trên địa chỉ IP của nguồn gửi sự kiện. Nguồn gửi sự kiện Adapty luôn là server của Adapty — không phải thiết bị của người dùng. Để tránh làm ô nhiễm dữ liệu, Adapty yêu cầu PostHog bỏ qua bước tra cứu này. Adapty điền vào $geoip_time_zone, store_country và profile_country — nhưng không có dữ liệu vị trí chi tiết hơn.
• Bạn không thể lọc sự kiện Adapty theo nguồn. PostHog ghi lại SDK đã gửi sự kiện trong $lib — posthog-ios, posthog-android, web — nhưng Adapty gửi thẳng đến API của PostHog mà không qua SDK làm trung gian, do đó thuộc tính này sẽ để trống. Hãy lọc theo tên sự kiện thay thế.

Khắc phục sự cố

• Sự kiện không xuất hiện trong PostHog
• access_level_updated hiển thị là thất bại trong Event Feed
• Một người dùng xuất hiện thành nhiều người trong PostHog
• Doanh thu trong PostHog không khớp với Adapty Analytics
• Sự kiện xuất hiện trong PostHog trước khi xảy ra
• Không có dữ liệu quốc gia hoặc thành phố trên các sự kiện Adapty
• Cách phân biệt người đăng ký với người dùng miễn phí
• Lượt xem paywall không xuất hiện trong PostHog

Sự kiện không xuất hiện trong PostHog

• Kiểm tra Event Feed của Adapty trước. Nếu có lỗi giao nhận, lỗi PostHog trả về sẽ hiển thị ở đây.
• Giao nhận thành công không đồng nghĩa với việc PostHog giữ lại event đó. PostHog trả về 200 OK khi payload và key hợp lệ, nhưng sẽ âm thầm loại bỏ các event không có tên hoặc có distinct_id trống.
• Xác nhận rằng event bạn cần tìm đã được bật trong cài đặt tích hợp.
• Nếu bạn tự host PostHog, hãy đảm bảo máy chủ chấp nhận các POST request từ Adapty tại /capture. Cấu hình thành công không đảm bảo rằng quyền truy cập này tồn tại — Adapty dùng một endpoint khác để kiểm tra tính hợp lệ của key.

access_level_updated hiển thị là thất bại trong Event Feed

access_level_updated là một sự kiện chỉ dành cho webhook. Adapty không bao giờ gửi sự kiện này đến tích hợp này. Tuy nhiên, Adapty ghi lại kết quả cho mọi tích hợp đã bật, và một sự kiện không được hỗ trợ sẽ được hiển thị là thất bại.

Một người dùng xuất hiện thành nhiều người trong PostHog

PostHog không thể hoàn tác hầu hết các lần tách sau khi đã xảy ra — xem Khớp ID của Adapty với PostHog.

Tại sao các ID bị khác nhau

Mỗi sự kiện Adapty gửi đi đều mang theo distinct_id từ hồ sơ người dùng Adapty — xem Độ ưu tiên Distinct ID. Adapty đọc giá trị đó tại thời điểm gửi sự kiện, không phải khi app của bạn gọi setIntegrationIdentifier. Nếu distinct_id của một sự kiện Adapty khác với distinct_id nội bộ của lượt cài đặt app, PostHog sẽ gán hai loại sự kiện đó cho hai người dùng khác nhau.

Ba nguyên nhân dẫn đến sự không khớp này:

1. Ứng dụng của bạn chưa gọi setIntegrationIdentifier trên một trong các nền tảng. Adapty sẽ dùng Customer User ID hoặc anonymous profile ID làm giá trị dự phòng. Hãy kiểm tra tất cả các nền tảng bạn đang phát hành.
2. Lệnh gọi setIntegrationIdentifier xảy ra quá muộn. Các sự kiện gói đăng ký xảy ra trước lệnh gọi này sẽ mang ID dự phòng.
3. ID bạn gửi cho PostHog qua identify() khác với ID bạn đặt làm integration identifier. Adapty chỉ lưu giá trị bạn truyền vào lần cuối và không tự cập nhật. reset() của PostHog sẽ tạo một anonymous ID mới, khiến Adapty vẫn giữ ID cũ — vì vậy hãy gọi lại setIntegrationIdentifier sau mỗi lần gọi reset().

Sửa cả ba, và PostHog sẽ chỉ ghi nhận một người dùng từ đó trở đi.

Hợp nhất các user ID khác nhau tại lần gọi identify() đầu tiên

Ứng dụng của bạn chỉ có một cơ hội để hợp nhất các ID khác nhau: lần gọi đầu tiên đến identify() của PostHog. PostHog sẽ gộp các sự kiện từ lần cài đặt ứng dụng vào người dùng bạn đặt tên trong lần gọi đó, vì vậy hãy dùng ID mà Adapty gửi — xem Khớp ID của Adapty với PostHog. Sau lần gọi đó, PostHog coi lần cài đặt ứng dụng là đã được xác định và từ chối hợp nhất hai người dùng đã được xác định.

Kiểm tra trường hợp từ chối hợp nhất

Để xác nhận rằng PostHog đã ghi nhận một người dùng thành hai person riêng biệt, hãy mở Data management > Ingestion warnings trong PostHog và tìm lỗi Refused to merge an already identified user.

PostHog cũng chặn việc merge khi ID là một trong các giá trị đã được đặt trước — xem Khớp ID của Adapty với PostHog để biết danh sách đầy đủ.

Khắc phục tình trạng split đã xảy ra

Không có identify() hay alias() nào có thể khôi phục sự phân tách sau khi cửa sổ merge đã đóng. Chỉ có $merge_dangerously của PostHog mới có thể ép buộc việc merge. PostHog ghi chú rằng thao tác này không thể hoàn tác, không có biện pháp bảo vệ, và chỉ dùng để xử lý sự cố một lần duy nhất do lỗi triển khai.

Bạn gửi nó dưới dạng một event thay vì một cài đặt, và nó chỉ định hai person. Chiều hướng xác định person nào sẽ tồn tại:

Hãy quyết định bên nào tồn tại trước khi gửi bất kỳ thứ gì. Hồ sơ người dùng Adapty lưu lịch sử gói đăng ký, còn hồ sơ người dùng trong app lưu hành vi in-app. Hãy chạy thử với một người dùng duy nhất và kiểm tra kết quả trước khi xử lý hàng loạt. Tài liệu How to merge users của PostHog có payload cho từng SDK của họ.

Doanh thu trong PostHog không khớp với Adapty Analytics

Adapty và PostHog xử lý cùng một sự kiện theo những cách khác nhau. Những khác biệt này là nguyên nhân chính của hầu hết mọi sự không khớp.

• Mỗi sự kiện Adapty đều mang theo ba giá trị doanh thu, tương ứng với ba tùy chọn trong Cách gửi dữ liệu doanh thu. Đây là cách chúng ánh xạ sang các thuộc tính PostHog:

So sánh giữa các hàng sẽ thấy sự chênh lệch bằng với phần hoa hồng, thuế, hoặc cả hai. Adapty gửi cả sáu thuộc tính trong mỗi sự kiện, bất kể Report user’s currency được đặt như thế nào.

• Adapty tính mọi sự kiện doanh thu trong một khoảng thời gian; một PostHog insight chỉ tính các sự kiện bạn thêm vào đó. Nếu bỏ qua subscription_renewed, bạn sẽ mất phần lớn doanh thu của mọi ứng dụng đã hoạt động ổn định.

• Khoảng ngày của Adapty bao phủ toàn bộ ngày cuối; bộ lọc timestamp dừng lại đúng thời điểm bạn chỉ định. Khoảng Jul 1 – Jul 15 trong Adapty bao gồm mọi sự kiện đến hết Jul 15 23:59:59. Trong PostHog, timestamp < 2026-07-15 sẽ loại bỏ toàn bộ ngày đó — hãy dùng timestamp < 2026-07-16.

• Adapty Analytics tách biệt sandbox và production; PostHog gộp chung cả hai. Lọc theo properties.environment = 'Production' — xem Giữ dữ liệu sandbox ngoài production.

• Adapty dùng múi giờ báo cáo của ứng dụng; PostHog nhận UTC. Các tích hợp luôn nhận timestamp theo UTC, bất kể bạn cài đặt gì trong App Settings. Một giao dịch mua lúc 23:30 UTC ngày 1/7 sẽ xuất hiện vào ngày 2/7 trong Adapty nếu múi giờ báo cáo của bạn là +02:00, trong khi PostHog vẫn giữ ngày 1/7.

• PostHog thiếu các sự kiện lịch sử. Có hai giới hạn riêng biệt khiến các sự kiện cũ không được gửi đến, vì vậy các giao dịch đăng ký và gia hạn trước đó chỉ xuất hiện trong Adapty Analytics. Các sự kiện do PostHog SDK của bạn tự thu thập sẽ không bị ảnh hưởng.

• Exclude historical events (Loại trừ sự kiện lịch sử), một tùy chọn bật/tắt trên trang tích hợp PostHog, được bật theo mặc định. Adapty không gửi các sự kiện có ngày trước khi hồ sơ người dùng tồn tại, và Event Feed đánh dấu từng sự kiện đó là đã hết hạn. Do đó, các sự kiện Adapty của người dùng bắt đầu từ lần đầu tiên họ khởi chạy bản build có Adapty. Tắt tùy chọn này để cho phép các sự kiện có ngày trong quá khứ đi qua kể từ thời điểm đó.

  • No historical backfill là giới hạn vĩnh viễn. Adapty gửi sự kiện khi xử lý chúng và không bao giờ quay lại để gửi các sự kiện đã được xử lý trước khi bạn bật tích hợp.

• Các sự kiện bạn đã tắt trong cài đặt tích hợp sẽ không bao giờ được gửi đến PostHog. Adapty Analytics vẫn tính các sự kiện đó. Kiểm tra phần Events names trong Cấu hình Adapty.

Sự kiện xuất hiện trong PostHog trước khi chúng xảy ra

Đối với các lần gia hạn và chuyển đổi dùng thử, Apple thông báo cho Adapty trước khi sự kiện xảy ra. Adapty chuyển tiếp các sự kiện này ngay lập tức, giữ nguyên timestamp trong tương lai. Adapty Analytics giữ lại chúng cho đến khi thời điểm đó qua đi, vì vậy PostHog hiển thị các sự kiện mà Adapty chưa báo cáo. Cả hai đều đúng. Lọc theo timestamp để loại trừ chúng — xem Dấu thời gian sự kiện với ngày trong tương lai.

Không có dữ liệu quốc gia hoặc thành phố trên các sự kiện Adapty

Hãy dùng thuộc tính store_country và profile_country thay thế. Các giá trị $geoip_* của PostHog sẽ luôn trống đối với các sự kiện Adapty — xem Thuộc tính IP và vị trí.

Cách phân biệt người dùng trả phí và người dùng miễn phí

Báo cáo sự kiện Adapty không tiết lộ quyền truy cập hiện tại của người dùng. $set chỉ bao gồm email, first_name, last_name, birthday, gender và os. Các thuộc tính sự kiện mô tả mức độ truy cập chỉ được điền trong sự kiện access_level_updated, và Adapty chỉ chia sẻ sự kiện đó với tích hợp webhook.

Hai hướng xử lý:

• Xác định trạng thái trong PostHog dựa trên lịch sử sự kiện. Người dùng có sự kiện Adapty gần nhất là subscription_started, subscription_renewed, hoặc trial_converted hiện đang có quyền truy cập; người dùng có sự kiện gần nhất là subscription_expired, trial_expired, hoặc subscription_refunded thì không có.
• Sử dụng tích hợp webhook để nhận access_level_updated, sau đó tự chuyển tiếp nó vào PostHog. API capture của PostHog yêu cầu định dạng payload riêng, vì vậy bạn cần thực hiện bước chuyển đổi ở phía mình — payload webhook của Adapty không thể gửi trực tiếp vào PostHog mà không qua xử lý.

Lượt xem paywall không xuất hiện trong PostHog

SDK của Adapty chỉ ghi lại các tương tác với paywall, flow và onboarding cho Adapty Analytics. Server của Adapty chỉ chuyển tiếp các sự kiện gói đăng ký đến các tích hợp, còn các tương tác này không phải là sự kiện gói đăng ký. Webhook cũng không bao gồm chúng. Hãy dùng SDK của PostHog để ghi lại những tương tác này ngay tại nơi bạn hiển thị paywall.