Definition
What price drift is
Price drift is the operational gap between intended state (the prices you think you set across territories) and live state (the prices actually serving customers right now on each store).
The gap rarely opens dramatically. It opens through small, asynchronous events:
- A teammate edits a single country's price directly in App Store Connect for a flash sale and forgets to revert it
- Apple ships a periodic price-point matrix update and your scheduled prices snap to slightly different rungs
- Google Play's billing engine recalculates tax on a territory and the rendered storefront price shifts
- A locale-specific override gets set during a promo and stays past the promo window
- A scheduled future price executes that nobody remembers setting
Three months after a clean push, you typically can no longer answer the question 'what's my live price in Brazil right now?' from memory.
Why drift matters
Price drift compounds quietly. Each individual change is small. Together they can mean your Brazil price is 12% off your intended Purchasing Power Parity (PPP) target, your India price hits a tier you didn't plan for, and your Turkey price hasn't tracked the lira's actual movement in nine months.
Drift directly affects:
- Conversion rate per territory (a price that no longer fits the local market underperforms)
- Subscription churn in price-sensitive markets
- Refund volume when customers compare local price to advertised website prices
- Your ability to A/B test pricing changes (you can't measure the impact of a change if you don't know the starting state)
How to detect drift
Drift detection requires two pieces of data: a durable record of intended state, and a current pull of live state.
Without an intended-state record (a config file, a database, a versioned record of past pushes), drift cannot be detected. You can only re-set prices and hope to hit the target.
With an intended-state record, detection is a per-territory diff: pull live prices from both stores, compare against the record, flag every mismatch. The flags fall into three buckets:
- Known overrides (a manual change for a sale): can be ignored or reverted on schedule
- Platform adjustments (Apple matrix update, Google tax recalc): typically need a re-push at the new target
- Unexplained drift: someone changed it and didn't record why; investigate
Why DIY scripts skip this
Most DIY bulk-price-update scripts are fire-and-forget: they compute prices, push them, log success, and exit. There's no record of what was pushed and no built-in diff against live state. The script helps with the initial push but not with the quarterly question of 'where did my prices actually end up.'
PricePush versions every push as an event, lets you diff against current live state, and has a one-click rollback that re-pushes a previous known-good state to both stores.
Examples
Drift from a single override
You push PPP-adjusted prices to 175 App Store territories on April 1st. Brazil lands at R$49.50.
April 14th, you set a R$39.90 Brazil price for a flash sale.
April 21st, the sale ends. You don't manually revert.
June 1st, you check your current prices. Brazil still shows R$39.90. Your intended price was R$49.50. That's 20% below target, and you've been pricing out of strategy for six weeks without noticing.
A per-territory diff between intended (R$49.50) and live (R$39.90) surfaces the discrepancy in seconds. Without that diff, the gap stays invisible until conversion or revenue data flags it indirectly.
Frequently asked
What causes app store price drift?
The main causes are manual overrides in App Store Connect or Google Play Console that don't get reverted, periodic Apple price-point matrix updates that snap your prices to different rungs, Google Play tax or FX recalculations that shift rendered prices, and scheduled future prices that execute without anyone remembering.
How do I detect price drift across territories?
You need two things: a durable record of your intended prices (per SKU, per territory) and a current pull of your live store prices. Diff the two per territory. Anything that doesn't match is drift. Without the intended-state record, you can only re-set prices and hope to hit your target.
Why does drift matter if my prices are 'close enough'?
Drift compounds across territories and over time. A 5% miss in twelve countries over six months pulls conversion and revenue down enough to be visible in dashboards, but the pattern shows up as 'lower numbers' rather than 'pricing problem.' Detection lets you keep the prices you intended without rerunning your entire pricing strategy from scratch.
Further reading
- Every DIY App Store pricing script I read has the same six gapsSix failure modes every DIY App Store Connect API pricing script hits, and why the maintenance cost almost always flips the build-vs-buy math.
- How to update app prices safely: versioning, history, and rollbackPricing automation without preview, history, and rollback is just faster manual work. Here's how to treat app pricing like code.
- Localized Pricing Maintenance: Why Set-and-Forget Doesn't WorkLocalized pricing isn't a launch decision, it's a maintenance habit. Here's why set-and-forget breaks, and what a review cadence looks like.
- Shipping Prices Across SKUs and Stores: The Operational ChecklistOperational checklist for rolling out localized prices to App Store Connect and Google Play across all your products.