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

iOS (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
    ]
)

Android (Kotlin)

React Native (TS)

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).

• 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.

Verifying your events land

See Testing your integration for how to inspect recent events locally and confirm they reach the dashboard.

Related

• User attributes — persistent traits about the user, not per-occurrence events

• Gating actions — when an event should pause the flow for a campaign action

• Handling callbacks — subscribe to SDK lifecycle events

• Testing your integration — confirm events are landing

• Concepts — Sessions and events — why the event model works the way it does