Skip to content

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.

Server 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.

Server to Server Integration

Joystick to Client

Your client applications can integrate directly with Joystick.

Server to Client Integration

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.

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.

Integration Flow

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.

Integration with Analytics

Example Response from Joystick with AB Test or Segmentation
{
  "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.

Amplitude Dashboard

Implementation Assistance

The Joystick team is here help you with your implementation! Just reach out to our team with any questions.