> 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/developer-guide/tracking-events.md).

# Tracking events

Events are the signals your app sends to Amply so campaigns can target, trigger, and measure. This page shows how a developer tells the SDK "something happened" — for example, the user opened a screen, completed a sign-up, or tapped a plan.

A PM handing this off to engineering only needs to answer two questions: **what is the event called**, and **which properties go with it**. The SDK handles batching, retries, and delivery to the Amply backend.

**Use this when** you want the SDK to record a user action so it can drive campaigns or show up in reports. **Don't use this when** you're sending internal framework state the SDK already captures — session start, app open, and config fetches are tracked automatically.

## What an event looks like

Every event has:

* A **name** — a short string you pick. Same name on every platform for the same action.
* A **property map** — optional key/value attributes describing the specifics of this occurrence (which plan, which screen, how much).

The SDK timestamps the event for you and attaches it to the current session.

## Tracking an event

{% tabs %}
{% tab title="iOS (Swift)" %}

```swift
import AmplySDK

// Simple event, no properties
amply.track(event: "OnboardingCompleted", properties: [:])

// Event with properties
amply.track(
    event: "PlanSelected",
    properties: [
        "plan_id": "annual_pro",
        "price_usd": 49.99,
        "trial_days": 7
    ]
)
```

{% endtab %}

{% tab title="Android (Kotlin)" %}

```kotlin
import tools.amply.sdk.Amply

// Simple event, no properties
amply.track("OnboardingCompleted")

// Event with properties
amply.track(
    "PlanSelected",
    mapOf(
        "plan_id" to "annual_pro",
        "price_usd" to 49.99,
        "trial_days" to 7
    )
)
```

{% endtab %}

{% tab title="React Native (TS)" %}

```ts
import Amply from '@amplytools/react-native-amply-sdk';

// Simple event, no properties
await Amply.track({ name: 'OnboardingCompleted' });

// Event with properties
await Amply.track({
  name: 'PlanSelected',
  properties: {
    plan_id: 'annual_pro',
    price_usd: 49.99,
    trial_days: 7,
  },
});
```

{% endtab %}
{% endtabs %}

## Property value types

Use simple scalar values. The accepted types differ slightly between platforms:

| Platform         | Accepted property value types                                                    |
| ---------------- | -------------------------------------------------------------------------------- |
| iOS (Swift)      | `String`, `Int`, `Int64`, `Float`, `Double`, `Bool`, `Date` (or `DateTimeValue`) |
| Android (Kotlin) | `String`, `Int`, `Long`, `Float`, `Double`, `Boolean`, `DateTimeValue`           |
| React Native     | `string`, `number`, `boolean`                                                    |

Do not pass nested objects, arrays, or custom classes as property values. If you need to encode structure, flatten it into multiple keys (`payment_method`, `payment_card_brand`) or serialize to a string before calling `track`.

## Naming conventions

Amply **recommends** **`PascalCase` for event names** (`WorkoutCompleted`, `PaywallDismissed`) and **`snake_case` for property keys** (`plan_tier`, `source_screen`) — events read like action constants, properties like data fields. Names are just strings and the SDK accepts any style; a consistent split simply keeps campaigns and reports readable.

Good:

* `PaywallViewed`
* `SubscriptionStarted`
* `TutorialStepCompleted`

Avoid:

* `paywall_viewed`, `paywall-viewed`, `Paywall Viewed` — mixing styles makes filtering painful
* `click` — too generic; you won't be able to tell clicks apart
* `user_opened_the_paywall_for_the_first_time_after_onboarding` — too long; put the detail in properties

Use the same event name across iOS, Android, and React Native for the same user action. If the same action sends different names per platform, campaign targeting and reports break silently.

## Dos and don'ts

Do:

* Fire an event once per action. One `PlanSelected` per tap, not one per frame.
* Use properties to describe the occurrence, not to encode state (store state in custom properties — see [User attributes](/developer-guide/user-attributes.md)).
* Keep the property set stable. If `price_usd` was a number yesterday, keep it a number today.

Don't:

* Track events from tight loops or scroll handlers. The SDK batches, but the app still pays to build each map.
* Send personally identifiable information in event properties. Names, emails, phone numbers belong nowhere in an event payload.
* Rename events once campaigns are live. Renames break existing scenarios. Add a new name instead.

## When the event actually ships

`track` returns quickly. The SDK writes the event to local storage, then flushes to the backend on its own schedule. Network hiccups are handled automatically — events are retried.

You do **not** need to await `track` for the event to be recorded. On React Native, `track` returns a `Promise<void>` that resolves when the SDK has accepted the event locally. You can `await` it if you want back-pressure, but most apps fire-and-forget.

## Gating an event

`track` records and returns immediately. At a few moments you may instead want the app to **wait** for a campaign action to finish before continuing — for example, show a rewarded ad before an export, and only export if the user watched it. For those, use `trackGated` and act on the decision it returns. It's the same event you'd otherwise `track`, with a wait. See [Gating actions](/developer-guide/gating-actions.md).

## Verifying your events land

See [Testing your integration](/developer-guide/testing-your-integration.md) for how to inspect recent events locally and confirm they reach the dashboard.

## Related

* [User attributes](/developer-guide/user-attributes.md) — persistent traits about the user, not per-occurrence events
* [Gating actions](/developer-guide/gating-actions.md) — when an event should pause the flow for a campaign action
* [Handling callbacks](/developer-guide/handling-callbacks.md) — subscribe to SDK lifecycle events
* [Testing your integration](/developer-guide/testing-your-integration.md) — confirm events are landing
* [Concepts — Sessions and events](/concepts/sessions-and-events.md) — why the event model works the way it does


---

# 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/developer-guide/tracking-events.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.