> 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/getting-started/how-amply-fits.md).

# How Amply fits

Where Amply sits in your stack, what data it uses, and how a decision travels from a user action to a surfaced experience.

## The three sides Amply connects

Amply connects three sides of your app's growth loop.

**Acquisition surfaces.** How users arrive: deeplinks, Custom Product Pages, ad campaigns, organic installs, referrals. Each of these carries context Amply can act on — the campaign a user came from, the offer an ad promised, the product page they saw.

**App data.** What you know about the user: session data, device attributes, events they have triggered, custom properties you have set (plan tier, trial status, country, anything you track), and subscription state from the tool that owns it.

**In-app experiences.** What the app shows: onboarding flows, paywalls, popups, review prompts, deeplinks to specific screens. These are what Amply decides between.

Amply is the layer in the middle. It reads the context, evaluates the rules you have published, and tells the app which experience to run.

## Data flow

Here is what happens during a session.

```
  User opens app
        │
        ▼
  SDK starts a session, collects device + session data
        │
        ▼
  App calls track("EventName", properties)
        │
        ▼
  SDK evaluates published scenarios against current context
        │
        ▼
  Matching scenario? ── yes ──▶ SDK runs the scenario's steps
        │                       (deeplink, paywall, action, etc.)
        │ no
        ▼
  App continues as normal
```

More concretely, the flow is:

1. **Session starts.** The SDK initializes and collects baseline context — device, install date, user properties you have set.
2. **App emits events.** Your code calls `track()` for meaningful moments: onboarding step completed, purchase screen shown, trial started, anything you want to act on.
3. **Scenario evaluation.** The SDK checks the current event against the scenarios published for your app. Rules are evaluated locally using the configuration the SDK has already fetched.
4. **Scenario execution.** If a scenario matches, the SDK triggers its steps. That might be opening a deeplink you handle, showing a screen you have registered, prompting a store review, or firing a callback your app listens to.
5. **Your app responds.** The SDK hands control back to your code to render the actual UI. Amply decides what to show; your app shows it.

Scenarios themselves are configured in the dashboard. When you publish a change, the SDK picks it up on the next session — no app release needed.

## What stays where

Amply does not try to own every piece of user data. It coordinates with the tools you already run.

* **Subscription state** lives in RevenueCat (or whatever you use). Amply reads it through custom properties you set from your app code, or through events you emit when a subscription changes.
* **Analytics** stays in your analytics tool. Amply has its own event stream for targeting, but it is not a replacement for product analytics or BI.
* **Push notifications** stay with your push provider. Amply triggers in-app experiences, not off-app messaging.
* **Your business logic** stays in your app. Amply decides which experience to surface; your code owns the screens and the domain logic behind them.

## Where each audience touches Amply

Two audiences interact with Amply in different places.

**Product, growth, and marketing** work in the dashboard. They define projects and applications, build campaigns with targeting and triggers, configure scenarios, and watch results. They do not touch the SDK.

**Developers** integrate the SDK once. They initialize it with credentials from the dashboard, instrument key events with `track()`, set user properties when they become known (user id, plan, country), and register handlers for deeplinks and scenario actions. After integration, they rarely need to change anything for new campaigns — most campaigns reuse events and deeplinks that already exist.

## What the SDK keeps locally

The SDK keeps a small set of local data to make decisions fast and offline-tolerant.

* **Session state** — when the current session started and what has happened in it
* **Device context** — platform, version, locale, install date, anything collected at first launch
* **User identity and custom properties** — whatever you set via `setUserId` and `setCustomProperty`
* **Recent events** — a rolling buffer, available for debugging via `getRecentEvents`
* **Published scenario configuration** — what to match and what to run, refreshed between sessions

None of this is a long-term data warehouse. Analytics, history, and reporting stay in your dedicated tools. The SDK only keeps what it needs to make routing decisions.

## A concrete example

A user installs your app from a Custom Product Page tied to a fitness challenge ad.

1. Your attribution provider receives the CPP install and hands the app a campaign identifier. Your code takes that identifier and passes it to Amply as a custom property, e.g. `setCustomProperty("entry_campaign", "fitness_challenge")`. Amply itself does no attribution — it just reads whatever your app sets.
2. The user finishes the app's registration step. Your app calls `track("OnboardingStarted")`.
3. The SDK evaluates scenarios. A scenario targets `entry_campaign = "fitness_challenge"` on `OnboardingStarted` and triggers a deeplink to a fitness-themed onboarding flow.
4. The SDK fires the deeplink; your app handles it and shows the themed onboarding.
5. Later, after a trial ends, another scenario targeting `trial_state = "expired"` fires and shows a recovery paywall variant — one you launched yesterday without releasing the app.

Same app binary, different users, different experiences, all configured from the dashboard.

## Related

* [What is Amply](/getting-started/what-is-amply.md) — the product in plain language
* [Quickstart](/getting-started/quickstart.md) — set up a project and send your first event
* [Developer Guide](/developer-guide/installation.md) — SDK integration details
* [User Guide](/user-guide/overview.md) — build campaigns in the dashboard


---

# 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/getting-started/how-amply-fits.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.