> For the complete documentation index, see [llms.txt](https://docs.amply.tools/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amply.tools/concepts/gating-an-action.md).

# Gating an action

Some moments in your app are worth pausing for. **Gating** lets a campaign make the app **wait for something to finish** — a rewarded ad, a quick survey, an upgrade screen — before the user's action goes through, and then continue or back out depending on how it went.

Most campaigns are fire-and-forget: they fire an action and the app keeps moving. A gate is the opposite — it holds the user's next step until the gated action resolves.

## The two halves

* **The app declares the gate-able moments.** A developer marks specific points — "Save", "Export", "Start sync", "Apply filter" — as moments the app is willing to pause at. This is a one-time setup per capability.
* **You compose the campaign.** From the dashboard you attach a campaign to one of those moments — its audience, its cadence, and the action it runs — and it starts gating. Pointing the gate at a different moment the app already exposed is a dashboard change, not a release.

## Use cases

**Watch a rewarded ad to unlock an action.** A free user taps **Export**. The campaign gates it on a rewarded ad: they watch it through → the export runs; they close it early → the export doesn't happen. You monetize a high-intent moment without a hard paywall.

**A one-tap survey before a big step.** Before **Cancel subscription** or **Delete account**, gate on a short reason picker. They pick a reason → the flow continues; they back out → they stay. You capture churn reasons exactly where intent is highest.

**A soft upgrade nudge at a premium moment.** A free user taps a pro-only filter. Gate on an upgrade screen: they upgrade → the filter applies; they dismiss → they fall back to the free version. A contextual upsell at the exact point of desire. (Your app still grants the actual entitlement — the gate shapes the moment, see *When not to gate*.)

**A value-exchange unlock.** "Invite 3 friends to unlock this theme" — gate the unlock on the invite flow completing, so the reward lands the instant the condition is met.

## When not to gate

Gating is for moments where waiting makes sense. Two things should **not** be gated:

* **Permission and consent prompts** — tracking permission, privacy consent, push permission. Don't wire these as gates. Show them as ordinary prompts, record the answer as a user attribute for targeting later, and let the user's action continue regardless. Making a core flow wait on a consent answer risks freezing the user on a prompt.
* **Opportunistic, informational, or navigational actions** — a rate-and-review prompt, a promo screen, an announcement. These should fire and let the app move on.

A simple test: gate it only if "the user deliberately didn't finish this" is a meaningful outcome you'd want to act on. For an ad or a survey, it is. For a consent prompt or a promo, it isn't.

## The safety promise

A gate **never traps the user behind a broken dependency.** If the ad fails to load, the network drops, or the app isn't ready, the user's action goes through anyway. The only time an action is held back is a deliberate "the user chose not to complete it" — for example, closing a rewarded ad before finishing — and only when the campaign is set to treat that as a cancel.

Because of that promise, **a gate is a UX tool, not a lock.** Don't use it as the thing that grants an entitlement or enforces a payment — grant the premium feature in your app or through the store as you normally would, and use the gate to shape the moment around it.

## What you control without a release

Once the app has exposed a gate-able moment, from the dashboard you control: **which campaign gates it, who it targets, how often it fires, what the gated action shows** (for example, a rewarded ad's reward amount or length), and **whether closing it cancels or lets the flow proceed.** Pointing a gate at a different moment the app already exposed needs no release.

## Related

* [Handling deeplinks](/developer-guide/handling-deeplinks.md) — how a developer wires the app's gate-able moments and the action that runs at each
* [Tracking events](/developer-guide/tracking-events.md) — the gate lives at an event the app already tracks
* [Campaign delivery](/concepts/campaign-delivery.md) — how Amply decides which campaign fires at a moment
* [Campaign actions](/concepts/campaign-actions.md) — the fire-and-forget actions a gate sits alongside


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.amply.tools/concepts/gating-an-action.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
