For the complete documentation index, see llms.txt. This page is also available as Markdown.

Campaign actions

What a campaign does when it fires. Every campaign has a type that determines the action Amply performs on the device at the moment the trigger matches. The set of action types grows over time as new campaign types ship.

Action types

Routes the user to a screen or URL. When the campaign fires, the SDK calls the deeplink listener your app registered at startup and passes the URL along. Your app handles the routing — the screen you navigate to, how it looks, and what the user does there are all under your control. This is fire-and-forget: Amply sends the URL and the SDK calls your listener; no outcome flows back to the campaign.

The URL is a string you control. Two common conventions:

  • Your app's own scheme — for example yourapp://promo or yourapp://feature-discovery. This is the same scheme you would use for push-notification deeplinks or external launches. Amply routes through it the same way.

  • A dedicated scheme for campaign-triggered routes — the examples in these docs use yourapp:// as a sample convention (for example yourapp://campaign/promo/abc123). This is not a reserved namespace — use whatever scheme or pattern makes sense in your app. A separate scheme can make it easy to distinguish campaign-triggered navigation from ordinary app-wide deeplinks.

What a deeplink action is good for:

  • Routing new users to a specific onboarding screen based on the ad they came from.

  • Opening a feature-discovery walkthrough after a user completes their first core action.

  • Showing your paywall screen tied to a specific feature attempt.

  • Returning lapsed users to a "welcome back" screen with a tailored offer.

  • Triggering an in-app popup screen you render yourself (the screen is just a route your app already has).

In each case, the screen already exists in your app. Amply decides who sees it and when; your app renders it.

See Handling deeplinks for the SDK calls on iOS, Android, and React Native, and Managing deeplinks for the dashboard side.

Native rate prompt

Triggers the platform's native rating dialog — SKStoreReviewController on iOS, the in-app review dialog on Android. This is fire-and-forget: the SDK presents the system prompt and no outcome flows back to the campaign. Both platforms rate-limit and control the prompt tightly; you cannot trigger it at will, and you cannot style it.

Use the RateReview campaign type when:

  • You want the platform's native prompt at a specific moment without any prior custom screen.

  • The moment is determined by a meaningful event (a successful purchase, a milestone).

Gate it carefully with targeting and frequency rules. The platform will suppress prompts shown too often; a campaign that over-prompts will silently stop working on the platform side.

For a two-step pattern — first ask the user if they are happy, then route to the native prompt only if they are — fire a custom event such as PositiveRatingShared as the RateReview campaign's trigger. See Rate-review flows for the full pattern.

Gated action

An action that produces an outcome the app waits for before continuing. Instead of fire-and-forget, the app calls trackGated at a moment it has registered as a gate; Amply runs the campaign action at that moment and the SDK returns the outcome to the app once the action resolves — for example, after a rewarded ad completes or a user dismisses a prompt.

See Gating an action for the concept and how to use outcomes in your app flow.

Last updated