Glossary

Client SDK

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.

Server SDK

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.

Environments

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.

Flag

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 Remote Variable.

Once your flags are released, you will be able to manage them from the Flagship platform.

KPI

Thanks to our Universal Collect, we are able to directly track events and retrieve them inside the platform.

EVENT and 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.

Are you already tracking some events through Segment.com? Check our native integration!

Modification type

Type of modification you want to apply in your flags:

• HTML
• Redirection
• Image
• JSON
  At the end, the decision API will translate everything into a JSON object.

Panic Mode

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"

Scenario

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.

SDK Log Mode

It logs every action made by the SDK.

Traffic allocation

It's the percentage of users who will be assigned to specific variations. It's computed thanks to the MurmurHash algorithm applied to the Visitor ID and the Variation Group ID.

User Context

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.

Variation Group ID

The Variation Group ID is a sub ID of a feature/campaign. It helps us define the assignment of the user.

Visitor ID

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.

Visitor assignment

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.

User context

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.