Dev guide: how to best pick a date to migrate from rental to PPE while reducing chargebacks

Why submit timing matters

Apify requires roughly 14 days between when you submit a monetization change and when it goes live:

Submit date + 14 days = Effective date

On a rental model, subscribers prepay for the month. If you switch them to PPE while they’re still inside that prepaid window, Apify automatically refunds them — it’s built into the platform, not users manually calling their bank. You still eat the revenue clawback.

In practice, these “chargebacks” are refunds to users for the remaining days of their prepaid rental period — always pro-rated (unused days ÷ 30 × rent). Someone who paid $20 for a month on Nov 13 still has unused rental days if PPE goes live on Dec 1 — Apify credits them back for that portion only, and that amount is clawed back from your payout. Time the switch so most subscribers have finished their prepaid month first.

The fix isn’t guessing. Your Insights → Monetization chart shows when renewals hit — but the shape varies by Actor: one big spike, several smaller cohorts, or a chart that looks spread out with no obvious peak. Match your data to a pattern first, then apply the formula.

Goal 2: the next invoice after the switch

Even with decent timing, your first developer payout / invoice after PPE goes live can come as a shock compared with rental months: chargeback and refund line items, prepaid rental revenue tailing off, PPE usage still finding its level. That’s normal — not necessarily a sign you picked the wrong date. Compare against the approximate chargeback math in this guide, not against a peak rental month. Minimizing chargebacks is goal 1; reading the post-change invoice without panicking is goal 2.

Revenue patterns — yours may not be a single cluster

Before you pick dates, classify what you see in the monthly chart under Insights → Monetization:

Multiple clusters: you rarely get zero chargeback on every slot at once. Run the active-renewal rule per day-of-month — subs renew monthly on the same dates, so the following month’s calendar matters as much as the spike you’re avoiding.

Looks flat? You might still shave a little off chargebacks with careful timing, but don’t expect a big win — and don’t trust eyeballing the Monetization chart. Use exported data; sparse or small bars are easy to misread.

Step-by-step: map your renewal clusters

1. In Apify Console, open your Actor → Insights tab → Monetization.
2. Set the view to monthly. Note every day-of-month where rent spikes (e.g. 12th, 13th, 20th). If the chart looks flat, skip visual guessing — pull JSON and tabulate by date instead.
3. For each busy slot, record sub count and rent per renewal (each $20 bar ≈ one sub).
4. Pick which pattern from the table above fits, then apply the active-renewal rule for your target effective date — one row per slot, not one lump per cluster.

Not 100% accurate. This is a heuristic — past Monetization charts are a guide, not a forecast. Subscribers may not renew (churn), and new users can subscribe on different days than last month’s pattern. Chargeback totals and optimal dates can shift. Use this to reduce risk, not eliminate it — then hope for the best 😅

Worked example: one dominant cluster + smaller cohorts

This is one real rental Actor — everyone’s data is different. November had $180 total at 100% margin: a mid-month cluster (~67% of revenue) plus a few one-off renewal days. Yours may be multiple spikes, one dominant cluster, or a visually flat chart — use the pattern table and JSON workflow on your Monetization data, not these dates.

The math: rental → PPE (dominant-cluster example)

Goal 1: don’t switch to PPE while subscribers are still inside a prepaid rental window — calculated per day-of-month slot, using whichever renewal is active on the effective date. Below walks through the dominant-cluster example; for multiple spikes, add one row per slot in each spike.

Chargeback formula (always pro-rated, per sub, per active renewal)

Assume each $20 bar = one monthly rental renewal (30-day prepaid). November total = $180 (9 renewals). The main cluster is not one block — Nov 13, Nov 14, and Nov 15 each have their own subs and prepaid end dates. Sum chargebacks slot by slot:

Chargeback = (unused days ÷ 30) × $20  ·  unused days = last prepaid day − effective date + 1  (0 if PPE starts after last prepaid day)

A Nov 13 renewal covers 30 days → last prepaid day Dec 12. That sub’s November cycle is finished on Dec 13 — but the same sub renews again on Dec 13, starting a new prepaid window through Jan 11.

Critical rule — active renewal per slot: subs renew on roughly the same day-of-month every month. For each slot (12th, 13th, 20th…), ask: which payment is still mid-prepaid on the effective date?

• If that slot’s current-month renewal has not happened yet → use the prior month renewal (e.g. Nov 14 effective, Nov 20 slot → Oct 20 payment still active).
• If that slot’s current-month renewal has happened (effective day is after that slot in the month) → use that payment (e.g. Dec 15 effective, Nov 12 slot → Dec 12 payment just renewed — 27 unused days).
• If effective lands on a slot’s renewal day during a spike → count that day’s payment too (Scenario C, Nov 14 slot on Nov 14 effective). If the same-day renewal hasn’t posted yet, the prior month cycle may already be expired → $0 (Scenario D, Nov 15 slot on Dec 15 effective).

The November Monetization chart tells you how many subs renew on each day-of-month. The chargeback table must use whichever renewal is active on your effective date — not always the November row.

Scenario A — recommended: Nov 27 submit → Dec 11 effective

Window after the November spike prepaid periods are mostly tailing off, but before Dec 12–14 renewals fire. Every row uses the November payment (December renewals on those slots have not happened yet):

Scenario B — too early: Nov 17 submit → Dec 1 effective

Every slot still mid-prepaid on its November payment — December renewals have not started yet (Dec 1 is before the 12th):

Scenario C — during spike: Oct 31 submit → Nov 14 effective

PPE lands during the November spike. Nov 12–14 rows use November payments; Nov 20 / Nov 30 slots use October payments (November renewals on those days not paid yet):

Nov 15 slot: Nov 15 payment not made yet on Nov 14 — prior Oct 15 cycle already expired → $0. Nov 14 slot on Nov 14 effective: same-day spike renewal counts (30 unused days).

Scenario D — trap: Dec 1 submit → Dec 15 effective

Classic mistake: November cluster looks cleared, but Dec 12–14 renewals already happened — those subs just paid rent and are mid-prepaid again. Nov 20 / Nov 30 slots still use November payments (Dec 20 / Dec 30 not yet):

Nov 15 slot on Dec 15: Dec 15 payment not posted yet; Nov 15 cycle expired Dec 14 → $0. Same method on your Actor: one row per day-of-month slot, using whichever renewal is active on the effective date.

Recommended timeline (Scenario A)

• November cluster ends Nov 15 — prepaid tails run through ~Dec 14
• Dec 12–14 renewals on the same slots would start fresh chargeback exposure — avoid effective dates after Dec 11 unless you accept ~$107+ clawback
• Target effective = Dec 11 (last day before Dec 12 renewals) → submit Nov 27
• Residual chargebacks on Dec 11: all slots still have small tails — heaviest are Nov 20 + Nov 30 ($31.33 total, 17.4%)

Timelines to avoid — see Scenarios B, C & D

Quick rule of thumb

1. List every renewal cluster (start → end) from Insights → Monetization — or, if the chart looks flat, export JSON and count by day instead of eyeballing.
2. One dominant cluster: effective ≈ cluster end + ~30 days, then verify you’re before the next month’s renewals on the same day-of-month slots.
3. Multiple clusters: run the active-renewal rule per slot; effective after the latest cluster you’re protecting, but check the following month’s renewal calendar.
4. Looks flat / spread: perfectly even renewals are rare — you can usually trim chargebacks a little, but gains are modest. Use JSON, not the chart alone.
5. Submit date = effective date − 14 (all patterns).
6. Never set effective date inside a cluster or 1–3 days after it.

For this Actor only: November spike ends Nov 15, but the lowest-chargeback window is Dec 11 effective (submit Nov 27) — before Dec 12–14 renewals. Blindly using cluster end + 30 → Dec 15 hits fresh December prepaid (~$107). Your dates will differ — always check the next month’s renewals on the same slots.

My workflow (with AI)

The November chart and tables in this guide are one illustration — your Monetization data will look different. Different sub counts, rental prices, renewal days, and cluster shapes mean your submit and effective dates will not match mine. Use the pattern logic here; plug in your numbers.

1. Open your Actor → Insights tab → Monetization (monthly view for the cycle you care about).
2. Export the data — JSON from the Network tab is best (DevTools → Network → filter XHR/fetch while Monetization loads, copy the response). A screenshot works for a quick pass but is easier to misread.
3. Paste into your AI tool with context, for example:

“I’m switching this Apify Actor from rental to PPE (14-day notice: submit + 14 = effective). Here’s my Insights → Monetization data [paste JSON or paste the screenshot]. Map renewal day-of-month slots (which days have rent, how many subs). For my suggested effective date, use whichever renewal is still mid-prepaid per slot — current month if already paid, prior month if not. Suggest submit and effective dates to minimize chargebacks. Show math per slot.”

4. Cross-check the suggested submit and effective dates against your data — cluster start/end, not just the tallest bar. AI can be off by a day when labels are sparse.
5. Submit the rental → PPE change in Apify Console.

When in doubt, pick an effective date before the next month’s renewals on your busiest slots — not blindly cluster end + 30 if that lands after Dec 12-style renewals on the same day-of-month.

Tip: JSON beats screenshots. Include rental price per sub if you know it (e.g. each $20 bar = one renewal). If the chart looks flat, say so — but still paste JSON so the AI tabulates daily renewals instead of inventing spikes or telling you timing doesn’t matter.

I still sanity-check the output myself. AI is good at tabulating clusters from raw data; you own the final submit date in Console.

FAQ