Event Tracking

You need to track your users' behaviour to understand them. Some behaviour is automatically detected, while other events need to be manually tracked. Many of these methods have analogous events in our website tracker.

Automatically Tracked Events

These events are tracked automatically once the SDK is initialized. Linking and initialising the SDK is enough to take advantage of these; no further integration is required.

Event	Description
Application installed	The app was just installed. Usually can't be sent when the app is actually installed, but instead only sent the first time the app is launched.
Application launched	Someone has just launched the app.
Application foregrounded	The app was already launched, but it was in the background. It has just been brought to the foreground.
Application backgrounded	The app was in active use and has just been sent to the background.
Push token refreshed	The push token generated by Firebase has been updated.
Notification received	A push notification was received by the system. On iOS, receiving notifications in quit state requires a Notification Service Extension.
Notification interacted	The user has just clicked on / tapped on / opened a notification.
Error occurred	An error occurred on the client side. We try to detect any problems with actual notification payload on our side, so we don't expect any errors which need to be fed back to end users.

Manually Tracked Events

See the following guides for details on each event type:

• Profile Events - User identification and logout
• Product Events - Product views and listings
• Basket Events - Shopping cart interactions
• Order Events - Checkout and purchases
• Screen Events - Home and custom screen views
• Custom Events - App-specific events

Flush tracked events

In order to reduce power and bandwidth consumption, the Ometria library doesn't send the events one by one unless you request it to do so.

Instead, it composes batches of events that are sent to the backend during application runtime when one of the following happens:

• it has collected 10 events
• there was a firebase token refresh (pushTokenRefreshed event)
• a notificationReceived event
• an appForegrounded event
• an appBackgrounded event

You can request the library to send all remaining events to the backend whenever you want by calling:

Ometria.flush();

Clear tracked events

You can completely clear all the events that have been tracked and not yet flushed:

Ometria.clear();

Manage tracking consent

Ometria allows you to manage the user's consent for activity tracking. Tracking is enabled by default. Use this when you need to honour user preferences around analytics/tracking (e.g. as part of a privacy or GDPR-style consent flow, or in response to the App Tracking Transparency prompt on iOS).

Call setTrackingEnabled(enabled) whenever the user changes their tracking consent preference. The value is persisted locally, so you do not need to call it on every app launch - only when the user updates their choice.

// Resume tracking (e.g. the user granted consent)
Ometria.setTrackingEnabled(true);

// Stop tracking (e.g. the user declined consent)
Ometria.setTrackingEnabled(false);

note

Disabling tracking also opts out the contact from receiving push notifications, since we need tracking information to target the contacts. When disabling tracking, the SDK sends one final opt-out event and flushes any pending events, then blocks everything afterwards. No events leave the SDK while it is off, including automatically tracked ones (lifecycle, push token refresh, permission updates). Re-enabling sends an opt-in event and resumes normal tracking. The setting is persisted across app restarts, so the SDK stays disabled until you explicitly re-enable it. Deciding when the user has consented remains the responsibility of your app.

To read the user's current tracking consent state, call getTrackingEnabled(). It returns a promise that resolves to a boolean.

const isEnabled = await Ometria.getTrackingEnabled();