Integration Guide
Integration Models
There are two primary models for integration depending on your use case and circumstance. Reach out and discuss with the Joystick team any questions, we are here to assist with every step.
-
Joystick to Server
Your server will call Joystick, then process or use the configuration. The configuration content may be for server-only only use, or can also be passed on to the client.
-
Joystick to Client
Your client application can integrate directly with Joystick and get configurations quickly. This is useful for client-only configurations, or if you want to reduce the load on your server.
Tip
Regardless of how you integrate. it is recommended that you have a default for any configuration and graceful fallback in the case there is an issue attempting to retrieve the configuration from Joystick. How you handle this would depend on your use-case.
Platform / Language Support
Type | Platform | Support | Link |
---|---|---|---|
API Direct | RESTful API | ✅ | Rest API |
Game Engines | Unity 3D | ✅ | Unity SDK |
Unreal Engine | ✅ | Unreal SDK | |
Godot | ✅ | Godot SDK | |
Scripting | Javascript | ✅ | Javascript SDK |
Typescript | ✅ | Typescript SDK | |
Python | ✅ | Python SDK | |
Web / Server-side | PHP | ✅ | PHP SDK |
C# | ✅ | C# SDK | |
Java | ✅ | Java SDK |
Need something else? Let us know on Discord
Integration Flow
Here is an example high-level flow for integrating Joystick with your application. Depending on your use-case, the details will be different. Reach out and discuss with our team at any time.
Tip
It is a good practice to update the configuration content once per session, then cache it, so your users' experience remains consistent during a session, and you reduce your API call overhead.
When the user restarts the app, or comes back after a long break, you can then refresh the configuration content.
Integration with Analytics (For Segmentation and AB Testing)
Joystick can be setup to respond with different configuration content for either AB testing or segmentation purposes. On the response, Joystick will attach information regarding the AB test and/or segmentation. You should pass this information along to your analytics service to perform analysis correctly for users and segments.
See API Reference for details on request and responses.
{
"data": {...},
"hash": "2277e0d4",
"meta": {
"uid": 7363938138,
"mod": 138,
"seg": [
{
"n": "My Test",
"v": "Variant A",
"i": "Optional Information"
},
{
"n": "My Segment",
"v": null, // v is null if there was only segment details provided.
"i": "More Optional Information"
}
]
}
}
On the response, the "seg"
attribute is what you'll need to pay attention to and send along to your analytics service and attach as a user property. Each variant has three items. Learn more details about AB test and segmentation in our Dynamic Content guide.
Note
"seg"
is an array of objects. It will either be empty "seg": []
or have at least one object with three parameters.
seg object part | Description |
---|---|
n |
Name of the segment that the response was included in. |
v |
Variant Name. If you are running an AB Test using Joystick, this will the name or label of the variant that the response was included in. |
i |
This is optional information you can to send to tag or identify a particular variant. This can be configured on the Dynamic Mapping. |
Amplitude Example
Start by reviewing the Amplitude AB test guide. In Amplitude, the AB test information is added as a custom user_property on either the event action or using the Identify API.
You use the convention of adding "abtest.TEST_NAME": "VARIANT_NAME"
, where TEST_NAME and VARIANT_NAME are substituted using the payload from Joystick. If integrated correctly, the data will show up in Amplitude.
Tip
When you receive a piece of content from Joystick, check if there is variant information. If so, using the Identify API and send it to Amplitude.
Implementation Assistance
The Joystick team is here help you with your implementation! Just reach out to our team with any questions.