Reteno SDK provides powerful tools to track user behavior in iOS applications. This includes logging screen views, custom events, and monitoring push notification subscription status. Events can be tracked either manually or automatically, depending on the level of control developers require.
Below is a breakdown of events that can be tracked using Reteno SDK, divided into two categories: Custom Events and Automatically Tracked Events.

📘
Note
Tracking custom events must be configured manually. Ensure that all necessary events are properly set up to collect the required data.

Custom Events

The ability to track custom events is necessary for effective data analysis and user engagement strategies. Custom event tracking allows you to monitor specific user actions beyond standard metrics, offering tailored insights into how users interact with your app. This flexibility helps you align your data collection with business goals, measure the success of key features, and identify opportunities for improvement.

By tracking custom events, you gain a deeper understanding of user behavior, enabling data-driven decisions to enhance the app experience. For instance, you can analyze patterns like feature usage, conversion rates, or drop-off points in the user journey. These insights empower you to optimize workflows, personalize experiences, and ultimately increase user satisfaction and retention. Custom event tracking ensures your analytics adapt to the unique needs of your app, providing actionable insights that drive growth.

📘
Note
Correct planning and naming of custom events in mobile apps are essential for collecting meaningful data and making informed decisions.
For detailed guidance, check out:

Naming Custom Events

Custom events are tracked as follows:

Reteno.logEvent(event: Event)

Reteno.logEvent(Event event);

Custom Event model:

data class Custom(
    val typeKey: String,
    val dateOccurred: ZonedDateTime,
    val parameters: List<Parameter>? = null
)

typeKey - key qualifier of the event (provided by appDeveloper, confirmed by marketing team).
dateOccurred - time when event occurred
parameters - list of parameters, which describe the event

Parameter model containt key/value fields to describe the parameter:

data class Parameter(
    val name: String,
    val value: String?
)

Example of usage:

val params: List<Parameter> = listOf(Parameter("key1", "value1"), Parameter("key2", null))
reteno.logEvent(Event.Custom("eventTypeKey", ZonedDateTime.now(), params))

List<Parameter> params = new ArrayList<>();
params.add(new Parameter("key1", "value1"));
params.add(new Parameter("key2", null));

Reteno.logEvent(new Event.Custom("eventTypeKey", ZonedDateTime.now(), params));

📘
Note
Set up event-based segmentation to ensure custom events and their parameters are recorded in contact cards, enabling the creation of dynamic segments.

Automatically Tracked Events

Automatically tracked events include

Screen View Events
Mobile Push Subscribes
Session Events

Screen View Events

Reteno tracks screen appeared events and attaches information about the current screen to events.

Automatically Track Screen Events

Under the hood Reteno observes FragmentTransactions and tracks Fragment class name as screen name. If your application doesn't use Fragments you should use manual screen tracking.

Automatic screen tracking can be enabled/disabled using the following method:

Reteno.autoScreenTracking(config: ScreenTrackingConfig)

Reteno.autoScreenTracking(ScreenTrackingConfig config);

Where ScreenTrackingConfig is the configuration class for automatic tracking:

data class ScreenTrackingConfig @JvmOverloads constructor(
    val enable: Boolean,
    val excludeScreens: List<String> = listOf(),
    val trigger: ScreenTrackingTrigger = ScreenTrackingTrigger.ON_START
)

Arguments:

enable → true/false. Enable/Disable automatic screen tracking
excludeScreens → you may provide a blackList of Fragment names which should not be tracked. Default argument is emptyList
trigger → Fragment Lifecycle callback to trigger screenView event tracking. You may either choose ON_RESUME or ON_START. By default it is ON_START

If you just want to enable/disable automatic screen tracking with the default params you may use overloaded constructor of the data class

Reteno.autoScreenTracking(ScreenTrackingConfig(false))

Reteno.autoScreenTracking(new ScreenTrackingConfig(false));

Manually Track Screen Events

You can manually track screen view events whether automatic tracking is enabled or disabled. You can track these events according to you needs and based on your screen lifecycle:

Reteno.logScreenView(screenName: String)

Reteno.logScreenView(String screenName);

Mobile Push Subscribes

Your end-user may prohibit receiving pushes by disabling Reteno notification channel or disabling notifications for your application in Android OS settings menu. In this case SDK will notify its servers to prevent sending push notifications to this specific device.

SDK checks notifications enabled status in these cases:

On App resume
On push received event
On settings changed in Android OS Settings menu (starting from Android 9.0, using system broadcast)

Once status false sent to the server, the backend won't send any push notifications to this device until the end-user re-enables channel/notifications. Once the end-user re-enables channel/notifications the server will be notified and will send push notifications again.

Session Events

Reteno can track start session and end session events. This event will be tracked automatically but it can be managed.

data class LifecycleTrackingOptions(
    val sessionEventsEnabled: Boolean = true
)

When sessionEventsEnabled is enabled Reteno tracks the following events:

Event Name	Properties	Description
`SessionStarted`	sessionId, startTime	This event fires when a user's session started
`SessionEnded`	sessionID, endTime, durationInSeconds, applicationOpenedCount, applicationBackgroundedCount	This event fires when a user's session ended
`ApplicationOpened`	fromBackground	This event fires when the application is opened (brought to the foreground)
`ApplicationBackgrounded`	applicationOpenedTime, secondsInForeground	This event fires when the application is moved to the background

Force Push Locally Cached Data

Reteno caches all events (events, device data, user information, user behavior, screen tracking, push statuses, etc) locally into database to save battery minimize API calls. Each n seconds (default = 30sec) SDK sends cached data to Reteno server in batches. The scheme is as follows:

If you need some of your events to be sent to the Reteno server instantly just call the following method:

Reteno.forcePushData()

Reteno.forcePushData();

It will flush all the currently accumulated data in cache (events, device data, user information, push statuses) and uploads it to Reteno server.