Prime Big Deal Days: an app promotion readiness checklist

Prime Big Deal Days 2026 takes place on October 6–7 in the United States and the United Kingdom, according to Amazon's US announcement and UK announcement. The autumn event offers deals for Prime members. Amazon's US announcement gives a start time of 12:01 a.m. PDT; use the local announcement for each market rather than copying that timezone into a global campaign.

For an app team, a concentrated shopping event is a useful deadline for checking the whole purchase journey. A convincing offer screen is only one part of it. The same offer must survive sign-in, eligibility checks, payment retries and delivery of the purchased benefit.

This checklist is for teams running their own promotion around a busy retail period. It does not assume participation in Amazon's event or an Amazon integration. The working method also applies to an independently scheduled sale.

Define the offer before creating the campaign

Write a short offer specification that marketing, engineering and support can all use. Record the eligible audience, product, market, currency, price, start and end instants, and what the customer receives. For subscriptions, include the discounted period and subsequent renewal terms.

Separate two deadlines that can easily get confused: the last moment a customer can start redeeming an offer and the end of the benefit they have already purchased. Decide what happens if someone opens checkout before expiry but completes payment afterward. Implement that decision consistently in the offer service and payment flow.

Check the offer against the billing system that actually sells the product. For example, Apple's introductory-offer documentation limits eligibility to one introductory offer per subscription group. A returning user is not automatically eligible just because your campaign calls them a returning customer.

Run through the journey with both an eligible and an ineligible account. Make the unavailable state useful: explain why the offer cannot be redeemed and show the applicable alternative. Do not leave a discounted banner visible above a checkout that silently charges the standard price.

Match the promise across every entry point

Open each live campaign destination from a clean session and an existing account. Compare the advertisement, landing page, app offer screen and checkout. The product, price, eligibility and deadline should agree. Test deep links on a device without the app as well as one with an older installed version.

Check what survives authentication. Someone who follows a promotional link, signs in and returns to a generic home screen may never see the offer they expected. Preserve the intended destination, then revalidate eligibility and price before payment.

Use a real expiration state. After the deadline, replace or remove the offer and explain what is now available. A countdown that restarts after a refresh creates a promise your campaign cannot consistently honor. Keep marketing edits and backend configuration tied to the same approved specification.

For subscription-specific wording, use our enrollment and cancellation UX checklist. Here, the additional concern is whether a time-limited campaign remains consistent across all of its entry points.

Test payment and delivery as separate outcomes

A customer reaching a success screen does not, by itself, prove that payment settled or that the app delivered access. Treat checkout completion, payment confirmation and entitlement delivery as separate states. Give the user an honest pending state when confirmation has not arrived.

Stripe's webhook documentation describes asynchronous payment events, retries and duplicate deliveries. Its idempotency documentation explains how supported requests can be retried with an idempotency key. If you use Stripe, apply both mechanisms at their appropriate boundaries; other providers have their own transaction and notification rules.

Use the provider's test environment to exercise the cases most likely to confuse a customer or your reporting:

• A double tap or repeated payment request produces one intended purchase.
• The app closes after payment; reopening restores the confirmed benefit.
• A delayed or duplicate notification does not grant access or record the purchase twice.
• Payment is declined, abandoned or still pending; each state has an accurate explanation.
• The offer expires while checkout is open; the final charge follows the documented rule.
• A refund or reversal reaches the app's entitlement handling and reconciliation process.

Assign someone to inspect unresolved paid-but-not-delivered cases. A campaign pause should stop new promotional entries while keeping reconciliation, customer support and valid existing entitlements working.

Define the funnel before traffic arrives

Give each measurement one meaning. An offer impression answers whether the offer was actually shown; a click records an attempt to proceed; a confirmed purchase records a verified transaction. Do not use any of these as substitutes for the others.

Choose a primary outcome and a denominator before launch. One practical definition is confirmed purchasers divided by eligible users shown the offer, within a documented observation window. If you instead measure purchases per checkout start, label it that way. A session-based denominator and a user-based denominator answer different questions.

Keep payment identifiers and reconciliation details in the appropriate operational system. Use fixed campaign labels and categorical failure reasons for behavioral analysis; avoid putting personal information, payment details or raw errors into event labels. Record technical failures separately from ordinary ineligibility so the team can act on the right problem.

Before launch, complete one test journey and trace it through each expected state. Verify that a blocked or cancelled payment never produces the confirmed-success event. This is more useful than simply checking that the analytics dashboard receives traffic.

Review contribution after refunds and costs

Decide which financial measure supports the campaign decision. Customer spending, developer proceeds and a bank payout are different measures; the sales versus proceeds guide explains why those totals need separate labels.

For an internal campaign review, a useful working measure is proceeds attributable to the selected purchases, less refunds and reversals not already included, campaign spend, and directly attributable delivery or service costs. Keep the currency and reporting window consistent. If your proceeds source already deducts a fee or refund, do not subtract it again.

That calculation is a planning definition, not a claim that every provider supplies all of those fields together. Document which adjustments are available, which are delayed and which costs must come from another source. For subscriptions, keep initial purchases, trial conversions and renewals in separate cohorts and observation windows.

AppCradle can help you review imported store, advertising and subscription reports. It does not replace your checkout system or assign experiment groups. Use the transaction and campaign systems for the underlying attribution, then reconcile comparable reporting periods with the revenue differences guide.

Avoid declaring an uplift from the calendar alone

A higher total during a shopping event does not establish that your discount caused the change. Audience composition, organic demand and advertising activity can change at the same time. A before-and-after comparison is useful monitoring, but it is not automatically a causal experiment.

If you already have a suitable experimentation setup, define the comparison groups and analysis plan before launch. Otherwise, describe the observed outcome honestly: which audience saw the offer, what they purchased, what costs were included and what remains uncertain. Our monetization experiment guide covers that distinction in more detail.

Keep an operational review during the event and a later financial review after the relevant reports and adjustments arrive. Choose the later review date from your actual reporting delays and product cycle rather than assuming a universal waiting period. If the final campaign result depends on renewals, launch-day conversion cannot settle the question.

Make the launch decision explicit

Before opening the promotion, confirm that the offer specification, eligibility checks and checkout agree; retries produce the intended purchase once; confirmed access survives an app restart; and the team can trace a test purchase through measurement and reconciliation.

Write down the conditions that would pause new redemptions, who can make that decision, and how customers with pending or completed payments will be supported. If the offer or purchase path fails a critical check, fix it before spending more to send customers through it.

Afterward, bring the campaign's verified purchases, adjustments, costs and unresolved questions to your weekly metrics review. The useful outcome is a defensible decision about the next promotion, supported by a purchase journey the team has actually tested.