Adding MVP support for personalization is essential and should be a relatively low lift. As a first step, we'd like to add a new method to the SDK called getProfile. Calling this method will leverage the stored identity or optional parameters outlined below to make a single call to the Lytics personalization API and make the profile response available.
For the above call, there are a few parameters that must be included:
table this will default to user if not overridden by an optional parameter
fieldname this will be the value of the primaryIdentityKey from the config (_uid by default)
fieldval: this is the value of the primaryIdentityKey from the profile (by default this will be the generated identifier)
One open question we have is the best way to handle asynchronous activities for both iOS and Android. In the case of JavaScript, it would be a callback or promise where you pass a function, and then once the data is returned, it calls that function and passes the newly received data as a parameter. I think that will look something like this in Swift (maybe):
In the above example we'd be using the default parameters to get the profile and then upon receiving it call the doSomethingCool function to do something with it.
async func Lytics.shared.getProfile(
identifier: "uuid", // optional -- if defined we must require a value as well rather than pull the stored value
value: "123ABC" // optional -- if defined we must require an identifier as well rather than pull the stored value
table: "content" // optional
) -> doSomethingCool
In the above case we are going to override some of defaults for a one off call. This allows us to handle the different types of entities (user/content/etc) as well as any combination of custom identifiers even if they are not on the profile. It is unlikely that this will be used often as the default should be the best, easiest method.
Things to Consider
We'll want to provide a config option to handle retry attempts. By default I think its fair to just limit to one and then error but I can see a world where a customer may want more control.
Error handling will have to be pretty solid so that we don't break apps and consider how to most gracefully manage a failure. Definitley open to suggestions and best practices here.
We'll also want to have a config option to handle timeout length. It is unlikely that the API will be unrepsonsive but in the event that it is we don't want it to hang forever and we'll want a customer to be able to override a sane default of maybe 5 seconds?
Future
A few things to keep in mind though not a part of this ticket is eventually it is likely to be desired that as part of the Lytics.shared.identify call we'll also have an optional param to get the full profile and handle the callback. I think we want to wait here until we get feedback but just a thing to keep in mind from an architecture standpoint.
There are several other parameters the API accepts but for MVP I don't think we need to handle any of those. We will however likely want to add some in the future to have better control over what is returned and how. This can be hugely helpful for optimization if the profiles are massive and only a few keys are needed.
Adding MVP support for personalization is essential and should be a relatively low lift. As a first step, we'd like to add a new method to the SDK called
getProfile
. Calling this method will leverage the stored identity or optional parameters outlined below to make a single call to the Lytics personalization API and make the profile response available.API Call
https://learn.lytics.com/documentation/developer/api-docs/personalization#personalization-personalization-get
For the above call, there are a few parameters that must be included: table this will default to
user
if not overridden by an optional parameter fieldname this will be the value of the primaryIdentityKey from the config (_uid
by default) fieldval: this is the value of the primaryIdentityKey from the profile (by default this will be the generated identifier)So, for instance if the users
user_id
was the primary key and the value for that key wasuser123
the call would look like: https://api.lytics.io/api/entity/user/user_id/user123Sample SDK Implementation
One open question we have is the best way to handle asynchronous activities for both iOS and Android. In the case of JavaScript, it would be a callback or promise where you pass a function, and then once the data is returned, it calls that function and passes the newly received data as a parameter. I think that will look something like this in Swift (maybe):
In the above example we'd be using the default parameters to get the profile and then upon receiving it call the
doSomethingCool
function to do something with it.In the above case we are going to override some of defaults for a one off call. This allows us to handle the different types of entities (user/content/etc) as well as any combination of custom identifiers even if they are not on the profile. It is unlikely that this will be used often as the default should be the best, easiest method.
Things to Consider
We'll want to provide a config option to handle retry attempts. By default I think its fair to just limit to one and then error but I can see a world where a customer may want more control.
Error handling will have to be pretty solid so that we don't break apps and consider how to most gracefully manage a failure. Definitley open to suggestions and best practices here.
We'll also want to have a config option to handle timeout length. It is unlikely that the API will be unrepsonsive but in the event that it is we don't want it to hang forever and we'll want a customer to be able to override a sane default of maybe 5 seconds?
Future
A few things to keep in mind though not a part of this ticket is eventually it is likely to be desired that as part of the Lytics.shared.identify call we'll also have an optional param to get the full profile and handle the callback. I think we want to wait here until we get feedback but just a thing to keep in mind from an architecture standpoint.
There are several other parameters the API accepts but for MVP I don't think we need to handle any of those. We will however likely want to add some in the future to have better control over what is returned and how. This can be hugely helpful for optimization if the profiles are massive and only a few keys are needed.