Subscription Integrations Data Handling Requirements

These are best practices from analyzing and working with hundreds of brands that have migrated to subscription providers and the data cleanliness was not handled well. We are writing this document to educate all on what needs to be done so your truth (your data) is handled with the utmost care.

Reach out to [email protected] with any questions.

We work very closely with the following service providers:

Awtomic
Bold
Recharge
Skio
Smartrr
Stay.ai
(secret and private integrations) 🤫

Data quality and integrity

Data integrity is what allows you to actually analyze and measure your subscription performance. If the data (customer creation dates, subscription dates, subscription statuses, etc.) are not being handled when you migrate from one provider to another, then the data will be messy and practically illegible.

You won’t be able to extract information if the information is muddled.

Why does my subscription provider not notice the same issues?

Most data issues we notice are due to historical inaccuracies, which do not impact day-to-day billing but will impact the decisions you make.

The bare minimum for a successful migration and maintenance of your subscription accounts are the customer details, the price, the subscription status, the schedule for future charges, and the payment details.

However, to properly analyze your data, you will want the following information to be accurate:

the creation date to avoid seeing a spike associated with the migration
the churn date in case a subscription was canceled, otherwise, we can’t know that occurred
the products, SKU, tags, etc., on each subscription so you’re able to segment subscriptions and figure out if some products underperform in subscriptions compared to others
the cancellation reasons, accurate subscription edits over time, paused dates, etc., to be able to understand what happened to your subscribers and not just count currently active and recently churned subscribers

What are the most common sources of issues?

Migrations and Bulk edits. When migrating between two providers, it is very common for some of the data to be omitted or corrupted.

Bulk edits are another source of issues we see a lot. On Recharge, it’ll be common to edit a product variant on subscriptions while leaving the old SKU fields unchanged or to cancel many subscriptions without setting a cancellation date.

Our team has built dozens of fail-safe and, in some cases, will be able to repair your data. Contact us for a quote and more details!

Best practices and migration check-list

Here are the best practices that you need to ensure are handled by your subscription partner in order for the analysis (built using the data) to be clean.

When you migrate, follow these pieces of advice and talk to your provider about them:

Migrate all subscriptions if you can, even the churned ones! – about half of our partners will do this for you.
Make sure your new provider keeps the original subscription dates. All of our partners can do that, but not all of them will perform this automatically. Subscription dates (creation, cancellation, churn, and paused dates) are what Peel relies on to give you historical metrics. We cannot rely on the status of subscriptions since it’s only indicating the latest state of things.
Keep the same product variants if you can Recharge will famously create copies of other “regular” variants or products when selling them through subscriptions. Keep using the same, or make clean copies with the same SKUs, parent products, vendors, tags, and categories if you rely on them for reporting!
Be careful when switching to multi-product subscriptions! Recharge also famously has only one product variant per subscription, so it’s common for build-a-box providers and others to have many subscriptions per subscriber. Some providers will combine multiple subscriptions into one with multiple products. To do this properly, they need to conserve the original dates of each product subscription in case they’re not the same, and you will see a drop in the number of subscriptions. Peel reports on subscriptions and subscribers, so you’ll want to focus on subscriber metrics from now on.
Do not delete products. In general, it’s important never to delete data unless it’s corrupted. If you change products on Shopify, archive the old ones, but do not delete them. Without them, historical metrics will not be able to identify products, SKUs, vendors, etc., and the segmentation will be limited.
Each provider can access their own data, so do not assume the transfer will be automatic. Peel has built custom integrations with no less than nine subscription providers because, despite much of the data now residing on Shopify, neither Peel nor the new provider will have automatic access to your old subscriptions. Take each step of the migration one by one and ensure all parties have been granted access to what they need. That includes Peel!
Keep the transition period short. It’s common for migration to go in several steps, starting with new subscribers on the new service before the old subscribers are migrated. Make sure you keep these steps close to each other. A common issue is offering a pause or cancellation UI to users on one or multiple platforms at once and not tracking them accurately or editing data that’s already been considered stale by your new provider or by your analytics.
If you switch providers more than once, expect more chaos. We’ve worked with brands who’ve tried four or more subscription providers, and each migration resulted in data corruption because some of the advice above was not followed. It becomes much more complicated to clean up when we must overlap multiple providers and see which ones have correct dates, overlapping data, etc.
Trust then verify but not with Shopify orders and tags. Migrations are tricky, and there are so many combinations of the issues listed here that can happen. Avoid relying on Shopify orders and subscription tags as they tend to have a 5-10% error rate when compared to the number of active and churned subscriptions. It’s always better to download a list of subscriptions from the source if you must and analyze them.

Why should I care? ❌

If you ignore this, you will notice some of the following issues in your analytics and start doubting everything else:

it will look like all your subscriptions started on one specific date
or you will notice a spike in new or churned subscriptions around the migration date
previous product segment reports will stop showing data, or products will appear to have dropped sales while new ones will have picked up the sales
the number of active subscribers will appear to be almost double what it actually is
cohort retention will show 100% retention on the first few days after migrating
the number of subscribers will remain correct, while the number of subscriptions will drop abruptly

About change and how we handle it

Not all issues should be resolved. We believe it’s a good thing each provider brings with them new innovations, such as fewer subscriptions with several products in them or the ability to pause subscriptions or skip orders. We will keep doing our best to handle all these new features and the transition to them in the most intuitive way, but sometimes it will mean reporting changes.

For that reason and many others, we’ve created many secret settings we can apply to your accounts or integrations depending on how you wish to repair or keep unchanged some of these modifications.

Here are some of our (secret) settings:

Peel will automatically fill in cancellation dates when missing on canceled subscriptions, using the last known charge date or the last update date. We can also ignore these subscriptions, which is often the preferred approach
Peel will ignore subscriptions canceled on the day of their creation. More often than not, they’ve been created during a migration and canceled right away, or canceled by your CS/CX team
Peel will detect whether prices are unit or total prices and whether they include taxes, shipping, and discount. That allows us to compute accurate LTV, but some integrations make those distinctions very hard to follow, so feel free to check with them and let us know if you have a doubt
Peel will use product details (SKU, name, vendor) from the Shopify product table rather than any of the details provided by subscription services. We find that using the product variant and nothing else from them eliminates most of the data corruption. In some cases, customers have asked to use the subscription SKU, especially when it differs from the variant SKU on Shopify.
Peel can also enable a segment of Charge/Order SKU in case the SKU at the time of the order was different from the latest subscription product

If you have any questions please reach out to us [email protected].