> For the complete documentation index, see [llms.txt](https://docs.hackle.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hackle.io/en/development-guide/faq.md). # 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. {% hint style="info" %} Cafe24-based sites are a typical example where SDK integration is possible. {% endhint %} {% hint style="danger" %} Naver Smart Store does not allow code modification, so SDK integration is not possible. {% endhint %} *** #### 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](/en/ab-test/management/ab-settings.md). {% stepper %} {% step %} **Register a Test Device** Register the identifiers of the users you want to verify into each variation. {% endstep %} {% step %} **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%`. {% endstep %} {% step %} **Check event tracking** Check the real-time tracking status on the event detail screen. {% endstep %} {% endstepper %} *** #### 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. {% hint style="warning" %} 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. {% endhint %} *** #### 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](/en/development-guide/sdk/user-identifier.md). *** #### 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. {% hint style="info" %} If you respond with the value to process instead of the `variation`, no client changes are needed after the experiment is finalized. {% endhint %} {% columns %} {% column %} {% hint style="success" %} 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) ``` {% endhint %} {% endcolumn %} {% column %} {% hint style="danger" %} 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' ``` {% endhint %} {% endcolumn %} {% endcolumns %} *** #### 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](/en/ab-test/management/realtime-status.md) 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. {% hint style="warning" %} Hackle identifies users with browser cookies.\ On `vercel.app` domains, the SDK may not be able to manage cookies correctly. {% endhint %} Use a [Vercel custom domain](https://vercel.com/guides/how-do-i-add-a-custom-domain-to-my-vercel-project). *** #### 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. {% hint style="info" %} 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. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.hackle.io/en/development-guide/faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.