FAQ

1. SDK Integration

1.1. Can I integrate the SDK on a website built with an external solution?

If you can modify the code of the website, integration is possible. Since code work is required for SDK integration, whether integration is possible depends on whether code modification is allowed.

Examples where SDK integration is possible include Cafe24-based websites, while an example where it is not possible is Naver Smart Store.

1.2. When should I create a Hackle instance? Can it be used in other files within the same project after creation?

It is recommended to create the instance at initial app startup. Since it is implemented as a Singleton, there is no need to create it again in other files.

If you are using an SDK that requires import, simply import it within the file where you want to use it.

1.3. I'm not sure which SDK Key to select.

First, check the environment (Production or Development), and then select either Server or App/Browser based on the corresponding development platform. The SDK Keys document tells you which SDK Key to select.

1.4. Can I verify the integration is working before starting a test?

You can test in both Development and Production environments by using the Test Device registration feature. The Test Device registration feature works by force-assigning a user identifier specified in the Dashboard to a specific variation — this is also called an Override.

Refer to the [A/B Test Settings](../../A:B 테스트/manage-ab-dashboard/ab-settings.md) document for how to use it.

1. For the Development environment, first enter the User Identifiers of internal team members participating in the verification into each variation and save.

2. Then start the test and verify that the intended results appear for the members assigned to each variation.

3. For the Production environment, set Traffic Allocation to 0% before starting the test. This is to ensure the test is not exposed to anyone except the Override targets.

4. The subsequent steps are the same as the Development environment.

To check whether events are being tracked correctly, go to the Event menu on the Dashboard and check the real-time tracking status on the detail page for that Event Key.

Have the Override targets perform the action corresponding to the event, then go to the Event menu to check.

---

2. User Identifier

2.1. What should I use as the User Identifier in a mobile app?

You can use the User Identifier provided by Hackle. However, Hackle's User Identifier assigns a new identifier if the app is deleted and reinstalled. In other words, it does not recognize the same user.

If using Hackle's User Identifier is not suitable for the above reason, it is best to create your own unique value that can distinguish each user and use that as the User Identifier.

2.2. How should I set the User Identifier for non-logged-in users?

There is no single right answer, but one example is: in a web browser environment, you can generate a unique cookie for each browser and use that value.

In a mobile app environment, you can generate a unique value when the user installs the app and use that value.

There are many other approaches, so try to apply the method that best fits your service.

2.3. Are there any tips for creating a cookie-based User Identifier?

A User Identifier that is too short or too long is not ideal. Typically, 16 or 32 characters are used.

Also, it is recommended to set the cookie domain in a format like .{company}.kr. This makes it easy to share the value even when subdomains are created, and it is convenient for sharing the same value regardless of whether events are sent from the client or server.

For reference, example code for generating a User Identifier based on cookies is provided in the User Identifier document.

2.4. What should I use as the User Identifier if I want to measure by session?

In general, it is recommended to define the User Identifier at the user level.

However, if you set the User Identifier to a Session ID, you can also analyze results at the session level. In this case, you must define the session criteria and session logic yourself to establish a basis for metric calculation.

---

3. A/B Test Design and Implementation

3.1. I'm using a Server-side SDK. When the distribution result affects not just the server but also the client, what is the best implementation approach?

An easy-to-think-of approach is to pass the variation value from the server to the client and handle branching logic on the client, but this is not a good approach. When a certain logic is finalized later, changes would be required on both the server and the client.

Therefore, it is important to design the system so that only server-side code needs to be modified. For example, suppose Group A applies red and Group B applies blue.

# Good case
# The server assigns a value based on the variation and sends that value to the client
# For variation A:
HTTP/1.1 200 OK
{
  "color" : "red",
  ...
}
# For variation B:
HTTP/1.1 200 OK
{
  "color" : "blue",
  ...
}

# Client-side processing
fill_color(response.color)

# Bad case
# The server sends the variation value assigned on the server directly to the client
HTTP/1.1 200 OK
{
  "variation" : "B"
  ...
}

# Client-side processing
if response.variation == 'A'
  fill_color(red)
elif response.variation == 'B'
  fill_color(blue)

In the Bad Case, the server sends the distributed variation value to the client, and the client handles branching logic based on it. In the Good Case, the server internally completes the branching logic based on the distributed variation, and then sends the value for the client to process.

3.2. I'm using a Server-side SDK. I want to test a new feature on the client side — is it better to create a new API for each new feature?

There are two cases to consider.

If an API that manages the values being tested already exists, it is easier to manage by adding variation-specific responses to that API. However, if no such API exists, it is better to create a new API and distribute the variation within it, then return the variation-specific response.

For example, suppose you created an A/B test to observe reactions to changing the maximum character limit for input. If there was an existing API that returned the maximum character limit, have that API return the character limit for variation A and for variation B.

On the other hand, if there was no API returning the maximum character limit (because it had never needed to change), create that API and implement variation distribution within it. In this case, you can also control that only users who go through the new API are included in the population.

3.3. An A/B Test is running in the Production environment. I want to check whether variation distribution is working correctly.

Access the A/B test detail page from the A/B Test list on the Dashboard, then select the Real-time Exposure Status tab to see the distribution status per variation in the graph. Refer to the Real-time Exposure Status documentation.

---

4. Data

4.1. I need raw data for an A/B Test.

You can obtain variation distribution data and event data through the Dashboard. Note that this feature is available only for paid plans at the Pro tier or above.

1. Access the A/B test for which you need raw data.

2. Click the ... button to the right of the title.

3. Click the Export Data menu.

4. A link to download a CSV file is sent to the registered email.

5. Click the link in the email to download the CSV file.