The Trial Conversion chart is comprised of these statuses. Is there known logic to replicate these buckets with the data from the /subscribers/ endpoint? I’d like to be able to replicate these states at the database level for internal reporting.
Solved
Trial Conversion Chart -- replicating logic
+3Best answer by Miguel Carranza
Hi Jeff,
It’s maybe not impossible, but I think it would be quite difficult given what the API returns. The API is optimized to check for current subscription status, but not really for analytical purposes. For instance, you will be able to know if a subscriber is currently on a trial, promotional, intro or normal period looking at the `period_type` field. But you would not have access to the history of purchases, or whether a “normal” period was a trial conversion or not.
For analytic purposes, I would suggest to use our ETL exports instead. This way you will get a CSV of your transactions, which is way more complete. It will include fields like `is_trial_conversion`, `billing_issues_detected_at`, `renewal_number` and `unsubscribe_registered_at`
+6Hi Jeff,
It’s maybe not impossible, but I think it would be quite difficult given what the API returns. The API is optimized to check for current subscription status, but not really for analytical purposes. For instance, you will be able to know if a subscriber is currently on a trial, promotional, intro or normal period looking at the `period_type` field. But you would not have access to the history of purchases, or whether a “normal” period was a trial conversion or not.
For analytic purposes, I would suggest to use our ETL exports instead. This way you will get a CSV of your transactions, which is way more complete. It will include fields like `is_trial_conversion`, `billing_issues_detected_at`, `renewal_number` and `unsubscribe_registered_at`
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.