Developer Guide FAQ

Frequently asked questions about SDK integration, User Identifiers, and A/B Test implementation.

Frequently asked questions about integrating the Hackle SDK and implementing A/B Tests.

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

If you can modify the code, you can integrate the SDK.

Cafe24-based sites are a typical example where SDK integration is possible.

Naver Smart Store does not allow code modification, so SDK integration is not possible.

---

When should I create a Hackle instance?

Create it once at initial startup. Since it is implemented as a Singleton, there is no need to create it again.

---

Can I verify the integration before starting a test?

You can verify the integration with Test Device registration in both the Development and Production environments.

Test Device registration force-assigns a specified User Identifier to a specific variation. This is also called an Override.

Check the Override settings in A/B Test Settings.

1

Register a Test Device

Register the identifiers of the users you want to verify into each variation.

2

Start the test and check the behavior

Check that the registered users see the intended variation and screen. In the Production environment, set traffic to 0%.

3

Check event tracking

Check the real-time tracking status on the event detail screen.

---

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

We recommend using a unique user ID managed by your service.

Hackle identifiers are reissued when the app is deleted and reinstalled. The user is not recognized as the same user.

If using the User Identifier provided by Hackle is not suitable, it is best to create your own unique value that can distinguish each user and use that as the User Identifier.

---

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

On the web, you can use a unique cookie per browser. In an app, you can use a unique value generated at install time.

Choose a value that fits your service's user identification policy.

---

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

In general, use a 16-character or 32-character identifier.

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 an example of a cookie-based identifier, see User Identifier & Properties.

---

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

We recommend using a user-level identifier.

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.

---

How should I implement this when the server-side distribution result also affects the client?

Determine the value for each variation on the server, and pass only the value to process to the client. If you pass the variation value to the client and branch there, you have to modify both the server and the client after finalizing the experiment.

The following example applies red for Group A and blue for Group B.

If you respond with the value to process instead of the variation, no client changes are needed after the experiment is finalized.

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'

---

Do I need to create a new API for every client-side feature test?

If an API already exists, add variation-specific responses to that API.

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, for an experiment that changes the character limit, add variation-specific responses to the existing character-limit API. If no such API exists, handle distribution and the response in a new API.

---

How can I check variation distribution in the Production environment?

Check the distribution status per variation on the Real-time Exposure Status tab of the A/B test. See Real-time Exposure Status for details.

---

User Explorer or Override does not work in my development environment.

This may be a cookie management issue that occurs on vercel.app domains. We recommend using a custom domain.

Hackle identifies users with browser cookies. On vercel.app domains, the SDK may not be able to manage cookies correctly.

Use a Vercel custom domain.

---

Can I run an A/B Test with the React SDK on an SSG page?

This is difficult with SSG. Switch to SSR or use a client-side component.

An A/B Test determines the distribution when a user enters the page. The content is then rendered dynamically according to that distribution.

With SSG, where the content is determined at build time, this approach is difficult to implement. If you need to keep SSG, implement the A/B Test in a client-side component.