The LiveLike profile system can be used to handle a variety of scenarios, ranging from local anonymous experiences to persistent integration with existing user account systems. You can read more about those use cases in the profiles product guide.
Creating new profiles again may result in higher than expected MAU(Monthly Active User) count which can effect billing.
The LiveLike initializer returns a promise that resolves a profile object. Unless an access token is provided, those calls to init will resolve a new profile each time. This may be appropriate for one-off micro experiences, but usually an integration would persist the profile so that it is re-used the next time the SDK is initialized. Here is an example of how this might be managed in a purely client-side integration:
We also recommend that you initialize the SDK as late as possible in your application - just before the user accesses the EngagementSDK features.
saveAccessToken functions are just placeholders, you can imagine they might store the access token in local storage to be re-used later. A more complex integration might save and load them from your user account service on the backend, for example.
Initialization will create a profile if an access token is not provided
Take note that the
initmethod will create a new profile if an
accessTokenoption is not provided and already existing profile data is not available in localStorage. This can result in duplicate profiles being created if not managed carefully.
If you already have an access token for a LiveLike profile, you can pass it into the init function as
accessToken. This will load the user profile associated with that access token. This is common when LiveLike access tokens are being stored your own user account records in your backend.
Updated 12 months ago