Sessions and events

The Events screen is where you confirm the events your campaigns rely on are actually arriving — and where you turn individual events on or off for campaign use.

Dashboard task page. For the model of sessions and events, see Sessions and events.

Use this when you're setting up a campaign and want to verify its triggering event is being reported, or you're auditing what the SDK knows about. Don't use this when you need a per-user analytics report — Amply isn't a BI tool.

What the Events screen shows

In a project, open Events. You'll see one row per event name, each with:

• Name — the exact event name as reported by the SDK.

• Last Seen — when the event was last seen on each platform. iOS and Android are listed separately, with the SDK's most recent timestamp per platform. Blank if a platform has never reported it.

• Available — a toggle. When off, the event is hidden from campaign configuration dropdowns.

The list covers every event name the SDK has ever reported for this project, across all users and devices. New names appear as soon as the first device reports them.

Using events in a campaign

The most common flow:

1. Open Events and find the name you want to trigger on.

2. Confirm Last Seen shows a recent timestamp on the platforms you care about — that's proof the event is actually arriving.

3. Go to Campaigns → New campaign, and in the When step, pick that event from the Trigger when event dropdown.

4. Optionally add parameter filters ("only when tier equals premium").

If an event isn't in the dropdown:

• It might be toggled off — flip Available back on.

• It might not have been reported yet — ask an engineer to trigger it on a test device, then refresh.

• The name might be different from what you expect — copy-paste from the Events screen rather than typing.

Turning events on and off

The Available toggle on each row controls whether the event is offered in campaign configuration dropdowns (the Triggering Event picker and custom-property pickers elsewhere in the form).

• Turn off noisy or low-signal events you don't want listed in the dropdowns.

• Turn on an event you had previously disabled.

Toggling Available does not stop the SDK from sending the event — it only affects what the dashboard offers for configuration.

A note on custom events

Custom events are event names your app sends from code. As a PM your role is usually:

1. Decide what events you need (names and properties) for a campaign.

2. Hand the list to your engineer.

3. Once they've shipped, watch the Events screen to confirm the names show up.

4. Use them in campaigns.

For the standard events the SDK reports automatically, the naming conventions, and how custom events get tracked from code, see Sessions and events and Tracking events.

Related

• Sessions and events (concepts) — the model: sessions, the standard event catalog, naming conventions

• Creating a campaign — picking a triggering event in the When step

• Targeting an audience — using event-sourced properties as audience rules

• Tracking events — how engineers send custom events from the SDK