A Client SDK is a library present in the code of the device (mobile, browser, IoT, ...).
Example: An Android application would benefit from the Android SDK. That SDK is directly present inside the code of the application, on the device of the user. That's a client SDK. It also means that it serves only one user at a time.
Our Client SDKs are JS, React, ReactNative, Android & iOS.
A Server SDK is a library present in your server.
It manages several users at a time (thousands/billions).
Example: An Express JS server serving a website. This server would use an SDK Server and use it to reply to each HTTP call coming from multiple user sessions.
Our Server SDKs are Python, Go & NodeJS.
Each account has 2 environments currently, Preprod and Prod.
Each environment gives the customer the possibility to separate their features and experiments inside the platform: the ones which are already in production from the ones which have not been released yet and are still in QA.
A flag is a variable present in your code that you want to act on with a specific value (Boolean, integer, string). That variable can also be called
Dynamic Variable or
Once your flags are released, you will be able to manage them from the Flagship platform.
Thanks to our Universal Collect, we are able to directly track events and retrieve them inside the platform.
TRANSACTION hit types can be analysed as KPIs and define the different goals you want to follow.
If you want more precision regarding a specific SDK, you can check it's specificities inside the corresponding SDK documentation.
Type of modification you want to apply in your flags:
At the end, the decision API will translate everything into a JSON object.
The panic mode is a way to not display any modifications set up in Flagship anymore. It could be also used as a "Code Freeze mode"
Scenarios are behavioral use cases. You want to target users which are VIP, between 25 and 35 years old, living in France => Your scenario would be "French Gen Y VIPs". Each scenario has their own variation group ID.
It logs every action made by the SDK.
It enables you to target your visitors/users. Each user has a context with some criteria. Depending on your plan, you will be able to use some or all of those criteria inside the platform, to target on them.
The Variation Group ID is a sub ID of a feature/campaign. It helps us define the assignment of the user.
The Visitor ID has to be unique for each user/visitor. Thanks to that ID, you can guarantee the same experience to each of your users every time.
Based on the Visitor ID and the Variation Group ID, a hash is computed to define which variation a visitor should be assigned for.
More info about the MurmurHash algorithm used here.
Using the Decision API directly, or one of our SDK (in API or Bucketing mode), you can target your users via different criteria depending on the package you have subscribed to.
These criteria are useful to target users, but also to filter reporting of your feature when analyzing its results.
Updated 3 months ago