In-App Events and Promotional Content: Make App Moments Discoverable

A store event should point to something that is actually happening

Suppose a language-learning app is about to run a seven-day speaking challenge. Each day contains one guided conversation, the final session is live, and people who finish receive a new practice plan. Existing learners can hear about it through a push notification, but that message cannot reach someone browsing the store or a former user who has removed the app.

Apple In-App Events and Google Play Promotional Content give this moment a public entrance. A store visitor can discover the challenge, understand why it matters and open the relevant experience. That is more useful than adding a generic banner to the normal product page, because the message has a start, an end and a real destination.

The test is simple: if the event card disappeared, would there still be a distinct moment inside the product? If the answer is no, the team is probably trying to turn ordinary marketing copy into an event. Both stores expect something new, timely and user-facing, not a renamed bug-fix release or an evergreen claim such as “learn faster”.

Choose the format by the job it needs to do

A store event is one tool in a wider launch and retention system. It should not inherit work that belongs elsewhere.

An audience-specific product page is a relatively stable entrance for people arriving from a keyword, campaign, country or referral source. An event card is temporary and tied to a moment. An App Store A/B test compares creative treatments; it does not create the underlying experience. A push notification reaches people the app is allowed to contact, while a store event can appear to new, active or lapsed audiences on store surfaces.

Use the smallest format that matches the job:

The “action after opening” column prevents attractive but hollow campaigns. If the team cannot name the destination and observe the action, the event is not ready for a store card.

Build the event brief from product truth

Start with the experience, not the artwork. One person should be able to answer five practical questions before design begins: what is new, who can participate, when is it available, where does the link open and what counts as success?

The restrictions belong in the same brief. A competition may be available only to adults in selected countries. An offer may require a particular subscription. A live class may have limited capacity. Hiding those conditions until the app opens will improve neither trust nor conversion.

Give the event an operational owner. Marketing may write the card, but product confirms the experience, engineering owns the deep link, design produces event-specific media, localization rewrites the message, analytics verifies the events and support needs an answer when something goes wrong. This is a small release, not a spare image field in the console.

We would also define a fallback before submission. What should happen if the visitor is signed out, is not eligible, installs after the event ends or opens an old shared URL? A graceful screen that explains the situation and offers the next relevant action is far better than a home page with no trace of the promise.

Work backwards from Apple’s dates and review

Apple lets an In-App Event run for up to 31 days. It can appear on the App Store up to 14 days before the start, which is useful for awareness and reminders. App Store Connect currently permits up to 10 published events at once and up to 15 approved events per app. Those are capacity limits, not a reason to fill a calendar with minor updates.

The event details and media go through App Review. A new app can submit an event with its first version; an app that is already approved can submit an event with or without a new version. Leave time for review and correction, especially when the app build, event availability and store metadata must change together.

Each event receives a unique App Store URL. Apple can surface event cards on the product page, in search and on personalized or editorial areas of the store. That distribution is valuable, but it is not guaranteed reach. The event purpose, quality, relevance and store systems all influence discovery. A featuring nomination may draw editorial attention, yet submitting one does not promise a feature.

Apple’s event media has its own landscape card and portrait detail formats. Treat them as two compositions rather than cropping one busy poster twice. The card has to be understood quickly at small size; the details page can carry more atmosphere and context. Check the current Apple media specifications when production starts, because platform requirements can change.

Treat Google Play as a separate workflow

Google Play calls its system Promotional Content. Eligible apps and games can create an offer, a time-limited event or a major update. The content may appear across Apps and Games tabs, search, the store listing and other Play surfaces. A person may see an action such as Open, Update, Install or Learn more depending on the context.

Google allows an event to last up to four weeks. Teams can create content without requesting featuring, while a featuring request uses a separate quota and must currently be submitted at least 14 days before the start. A successful preview in Play Console is not a promise of placement, and neither is a featuring request. Plan the event so that it remains worthwhile even if discovery is modest.

Google’s quality guidance is refreshingly direct: the content should be new, noteworthy and easy to find in the app. A routine service description, a permanent discount or an ordinary weekly activity is not strong promotional content. The copy should answer three questions without detective work: what is happening, why it is useful and how to participate.

Taglines and descriptions need their own edit. Repeating the tagline in the first sentence wastes the small amount of space available. Event art should also be event-specific rather than a recycled store screenshot. Localize both text and media; submitting the wrong language is a preventable quality problem.

Make the tap and the in-app destination feel continuous

The event card creates an expectation before installation or opening. The app must honour it immediately. Apple recommends a deep link for every event, and the event has a unique shareable URL. On Google Play, the content likewise needs an obvious corresponding experience inside the app.

Test the complete route in more than the happy state:

1. An existing signed-in user taps the card and lands on the event.
2. A new user installs, completes the minimum onboarding and reaches the promised destination.
3. A signed-out returning user can authenticate without losing the route.
4. An ineligible user receives a clear explanation rather than a broken screen.
5. An old link opened after the end date leads to a sensible next step.

The mobile onboarding plan should preserve intent instead of resetting everyone to the same generic carousel. The launch checklist should include the event configuration, deep-link tests, analytics, support copy and the ability to disable or extend the experience safely.

*A store event is a route with preparation, a launch window and a destination, not a picture published in isolation.*

Localize the moment, not only the sentence

A global product does not need to promote the same event everywhere. A summer fitness challenge will land differently across hemispheres. A shopping offer may conflict with local rules or a more important retail period. A live session that looks convenient in London may begin after midnight in São Paulo.

Apple allows dates and times to be adjusted by country or region. Google Play supports localized promotional content. Use those controls to create a locally plausible schedule, not just translated metadata. Check the event name, cultural references, eligibility, time zone, image meaning and support capacity in every market.

Sometimes the honest decision is to launch in two markets, learn and expand. That is not failed localization; it is controlled operations. The store localization checklist can guide the wider language and asset review, but the event owner still has to confirm that the underlying experience is available and staffed locally.

Measure participation, not merely exposure

Store consoles tell only part of the story. Google Play reports unique viewers and converters, where a conversion can be an open, update or install. Apple provides App Store performance information around events. These measures show whether the card attracted action, but not whether the promised experience worked.

Create a compact product funnel before launch: event_open, event_join, the first meaningful event action and event_complete. For re-engagement, add a return-quality measure such as activity seven days later. For an offer, verify redemption and the downstream cancellation or refund rate. For a major update, track adoption of the new workflow and whether it reduces the problem the release was meant to solve.

The mobile analytics guide explains how to define and test the events without collecting unnecessary data. Segment by market, audience state and store surface where reliable attribution exists. Annotate featuring, release changes and outages. Do not credit every organic lift to a store placement simply because the dates overlap.

After the event, hold a short review. Keep the assets, timings, review lead time, deep-link failures, support questions and funnel results together. The next campaign should begin with this evidence, not with a blank design file.

Skip the store card when the product moment is weak

Not every release deserves an event. Skip it when the experience is evergreen, the change is invisible to users, the destination is difficult to find, the offer is not genuinely different, the team cannot support the date or analytics stop at the open. Promote the normal release through the normal store listing and product communications instead.

At Appfyl, we treat the card as the beginning of a product route. Before creative production, the Appfyl mobile app team checks whether the event exists in the build, whether the destination survives installation and sign-in, and whether the team can measure the promised action. That usually saves more time than polishing an event that the app is not ready to deliver.

Questions people ask