In this article you will learn about the Leanplum.start() call and technical information relating to how the Leanplum SDK works. There are three pillars of functionality to our SDK you will learn; resource syncing, sending/receiving data, and in-app messages.

Leanplum Start

Before jumping in let's take a minute to look at the Leanplum START call. This call is the cornerstone of your Leanplum integration. In the .start() call, a new session is started for a user and asynchronously we will deliver down relevant messages/ab tests/variables to the user on their client - whether in your mobile app, on a web page or in a server-to-server integration. The Leanplum start call is the most intensive call in the SDK/API library because of data that could be returned to client for you to use.

A few other things you should keep in mind as you implement the Leanplum.start() call.

It is best to implement the .start() call on your app launch; this will initialize the Leanplum SDK as your app initializes
Initially for a new user or new app install, we will by default assign an anonymous userId to that user based on their platform deviceId (more info at ).
If the user already exists, we will merge current and historical data on that user
On .start() will be the first call where resources will sync.

After an overview of the Leanplum.start() call, lets look at the three pillars of the Leanplum SDKs

Resource Syncing

When the Leanplum.start() call is implemented when your app initialized, we will evaluate the user and asynchronously deliver down relevant messages/ab tests/variables to the client. This means events are tracked and users can still use the app while content is being synced.

We recommend that in the case your initial screen on app launch depends on specific contents being synced, you should show a splash screen while content is being synced. You can remove the splash screen once the SDK confirms that content syncing has finished. For more information please refer to the Callbacks section of our developer documentation.

If you do not implement the callback, then the application would use last session contents until they have been synced.

We require that the application has default content set up in the SDK. For example if a user downloads app and opens for the 1st time while being offline, they will be able to get the default variables. Note that in such a situation, no in app messages will be shown on the first session, this is because in app messages needs to be synced before shown.

📘
What content will sync
Only content that has changed through Leanplum since the last session will be synced.

Sending/Receiving Data through SDK

The Leanplum SDK is extremely battery and network efficient. The SDK will queue and send session data to Leanplum every 15 minutes of user run time or when the app goes to the background / killed state. When the device is offline, the SDK will check for an active connection every 15 minutes so that it can empty the queue and send session data to Leanplum, however, if there is still no connection messages will continually be added to the queue until an active connection is detected.

Simply integrating the Leanplum SDK and calling Leanplum start, you will have access to these out of the box features.

Targeting (for example: app version, life cycle and location),
Analytics (for example: DAU, retention and engagement metrics)
Messaging (for example: in app messages and scheduled messages )

📘
Data Ingestion Limit
Leanplum will only accept data up to a week old. Meaning if session data is queued up due to no active connection (an offline session), we will accept all data up to a week old from the date the connection becomes active.

In-App Messages

All in-app messages are open sourced and native which allows our customers to use their custom branding and UI in their in-app messages. It will be able to look like just another screen in their app. Customers also have the ability to create their own in-app message templates.

In-app messages are synced to device at session start, this means that no internet connection is needed mid session when the message is being displayed.

For example if we wanted to show an in app message after a user who is in the US makes a purchase. The target would be all users who are in the US and the trigger of the in app message is the purchase event. Upon app launch, users who are in the US would qualify for the in app message and thus download the in app message. When the user triggers the purchase event mid session, the in app message is already stored in the application and is shown immediately.