> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Preguntas frecuentes

> Esta lista se actualiza regularmente con las preguntas más habituales de los clientes.

<AccordionGroup>
  <Accordion title="¿Cuál es la función del SDK web frente al script de la aplicación Kameleoon?">
    Utilice el script de la aplicación Kameleoon para los experimentos web creados con el editor gráfico o el editor de código. Utilice el SDK web para los feature flags y los experimentos de funciones.

    Tenga en cuenta que Kameleoon puede ejecutarse en modo híbrido. El modo híbrido utiliza tanto los SDKs web como el archivo JavaScript de la aplicación Kameleoon. El modo híbrido le permite utilizar el enfoque óptimo para cada tarea. Por ejemplo, puede implementar y desplegar variaciones más fácilmente del lado del servidor, mientras que el seguimiento puede realizarse de manera más eficaz con el archivo JavaScript.
  </Accordion>

  <Accordion title="¿Cuánto tarda en inicializarse un SDK?">
    Kameleoon utiliza servidores CDN durante la inicialización. Una vez que se recibe y almacena en caché la configuración, la recuperación y la actualización se producen rápidamente (50-70 ms en función de la latencia del servidor respecto al CDN más cercano).
  </Accordion>

  <Accordion title="¿Cómo se sincroniza la configuración del SDK con el servidor?">
    Existen dos métodos para obtener la configuración: [Polling](./technical-considerations#polling-predeterminado) y [Streaming](./technical-considerations#streaming-premium-option-premium-option).
  </Accordion>

  <Accordion title="¿Qué tecnología utiliza el método de streaming?">
    Se utiliza el protocolo [Server Side Events](https://en.wikipedia.org/wiki/Server-sent_events) (SSE o EventSource).
  </Accordion>

  <Accordion title="¿Cuándo proporciona el CDN de Kameleoon una nueva configuración al SDK?">
    El CDN se purga cada vez que actualiza la configuración de un feature flag (por ejemplo, variaciones, exposiciones de tráfico y segmentación), o cada 24 horas.
  </Accordion>

  <Accordion title="¿Cuáles son los dominios de Kameleoon que debo incluir en la lista blanca?">
    Si utiliza un SDK del lado del cliente y el sitio web restringe la carga de recursos (scripts, imágenes, contenido multimedia, CSS) mediante la cabecera HTTP estándar Content-Security-Policy (CSP), actualice la CSP del sitio para permitir la carga de los recursos de Kameleoon:

    ```
    script-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev 'unsafe-eval';
    connect-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://eu-data.kameleoon.eu https://eu-data.kameleoon.io https://na-data.kameleoon.eu https://na-data.kameleoon.io https://editor.kameleoon.com https://api.kameleoon.com https://customers.kameleoon.com https://logger.kameleoon.io https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev;
    ```

    <Note>
      Si utiliza Kameleoon en [modo híbrido](../get-started/hybrid-experimentation), el dominio de sus scripts de Kameleoon `https://[your-site-code].kameleoon.xx` puede variar de un proyecto a otro. Sus proyectos pueden estar alojados en `kameleoon.eu` o en `kameleoon.io` según su fecha de creación. Asegúrese de utilizar el dominio que aparece en su proyecto dentro de la aplicación Kameleoon. Sustituya \[your-site-code] por el [site code](/user-manual/faq#how-do-i-find-my-sitecode) de Kameleoon en cada línea en la que aparezca y añádalo a su configuración.
    </Note>
  </Accordion>

  <Accordion title="¿Cómo configuro el SDK si el servidor tiene varias instancias?">
    Dado que cada instancia de servidor tiene su propia memoria, todos los datos del visitante recopilados se almacenarán en una instancia determinada. Debe utilizar un framework en el que las solicitudes del mismo visitante sean procesadas por la misma instancia del servidor. De lo contrario, los datos del visitante deben añadirse íntegramente antes de cada solicitud de seguimiento o cargarse mediante el método `getRemoteVisitorData`.

    Si el problema está en las diferencias de configuración del SDK, utilice la opción [Streaming](./technical-considerations#streaming-premium-option-premium-option).
  </Accordion>

  <Accordion title="¿La asignación de variaciones y la asignación de tráfico se realizan localmente o en un servidor?">
    Todas las evaluaciones se realizan localmente para eliminar la latencia. Las solicitudes de seguimiento se envían después de forma asíncrona a los servidores de la Data API de Kameleoon.
  </Accordion>

  <Accordion title="¿Cómo garantiza el SDK que los visitantes vean siempre la misma variación?">
    Para asignar a un visitante a una variación de un experimento, Kameleoon primero genera un identificador utilizando el código del visitante, el ID del experimento y un posible elemento adicional en caso de respooling. A continuación, una implementación síncrona de la función hash [SHA-256](https://project.kameleoon.net/issues/256) calcula un hash de este identificador. El número entero obtenido mediante el hashing se asigna a un número decimal entre cero y uno para asignarlo a una variación del experimento. La función [SHA-256](https://project.kameleoon.net/issues/256) es determinista, por lo que el mismo usuario (con el mismo código de visitante) se asignará siempre a la misma variación de un experimento, salvo que se solicite explícitamente que se vuelva a calcular la asignación.
  </Accordion>

  <Accordion title="¿Cómo muestro primero una variación específica en una simulación de feature flag?">
    Siga la metodología detallada [aquí](/user-manual/experimentation/feature-experimentation/use-cases/build-whitelists-to-rollout-a-feature-for-internal-users).
  </Accordion>

  <Accordion title="Si cambio la distribución o exposición de tráfico, ¿los visitantes seguirán viendo la variación que se les asignó?">
    Todos los casos posibles se explican en este [artículo](/user-manual/experimentation/feature-experimentation/using-the-rollout-planner/rules-and-targeting/add-a-new-rollout-rule#user-targeting-and-bucketing).
  </Accordion>

  <Accordion title="¿Por qué no se muestran visitas en la página de resultados?">
    Existen varias razones por las que no se muestran datos en la página de resultados:

    * Si ha activado el filtrado de bots en la configuración del proyecto, podría haber un error con el valor de user-agent configurado en el SDK. Consulte [este artículo](/user-manual/faq#how-does-kameleoon-filter-bot-traffic-from-my-results) para más detalles.
    * El consentimiento legal está configurado como **Required** en los ajustes del proyecto, pero no se ha invocado el método setLegalConsent del SDK. Consulte [esta documentación](/user-manual/project-management/consent-management-policy#for-web-experiments-/-feature-experiments-/-hybrid-experiments) para más detalles.
    * No se ha utilizado ninguno de los métodos del SDK que envían una solicitud de seguimiento a los servidores de Kameleoon.

    [El siguiente artículo](/es/user-manual/experiment-analytics/analyze-results/feature-flag-results/analyze-a-feature-flags-overall-results) ofrece ayuda adicional para depurar el problema.
  </Accordion>

  <Accordion title="¿Por qué el número de visitas no coincide con mi tráfico real?">
    Si observa un gran número de visitas de visitantes, podrían ser bots. Para evitar que los bots afecten a su experimento, active la opción de [filtrado de bots](/user-manual/faq#how-does-kameleoon-filter-bot-traffic-from-my-results) en los ajustes de su proyecto. Para indicar que un visitante no es un bot, debe pasar los datos UserAgent de Kameleoon mediante el método del SDK. La invocación del método evitará que Kameleoon filtre al usuario.
  </Accordion>

  <Accordion title="¿Por qué la asignación de visitantes en mis informes es incorrecta?">
    Si sus informes muestran una asignación inesperada (por ejemplo, 10/90 en lugar de 50/50) o si faltan visitantes, puede deberse a alguno de los siguientes motivos:

    * **Reducción del grupo de visitantes para variaciones específicas:** Si primero invoca `getVariations(onlyActive: true, track: false)`, el SDK solo devuelve los visitantes asignados a las variaciones activas (`ON`). Si después solo muestra las páginas del experimento e invoca `getVariation(track: true)` para esos visitantes concretos, Kameleoon solo realiza el seguimiento de la variación `ON`, lo que resulta en un informe que muestra una única variación.
    * **Tiempo insuficiente para las solicitudes de seguimiento:** Kameleoon envía datos a un intervalo determinado. Si un visitante permanece en una página con un cliente Kameleoon integrado para la variación `ON`, pero pasa a una página sin él para la variación `OFF`, es posible que el cliente no tenga tiempo suficiente para enviar la solicitud de seguimiento de la variación `OFF`.
    * **Configuración ausente para variaciones específicas:** Es posible que haya omitido el `UserAgent` o `setLegalConsent` para algunas variaciones. Por ejemplo, si solo proporciona el consentimiento en la página de la variación `ON`, Kameleoon no podrá realizar el seguimiento de los visitantes de la variación `OFF`.
    * **Datos del visitante ausentes:** El SDK no recopila datos del visitante de forma automática; debe añadirlos explícitamente para que la segmentación y el seguimiento funcionen correctamente.

    ### Compruebe la configuración de su segmentación

    Si sospecha que existen problemas de segmentación, siga estos pasos:

    1. Cree una regla sin segmentación con exposición del 100 % y asigne la variación deseada.
    2. Añada la segmentación y compruebe que el usuario deja de recibir la variación.
    3. Añada los datos necesarios de Kameleoon.

    El usuario debería volver a recibir la variación. Si no es así, pruebe a usar condiciones de segmentación más simples para aislar el problema.
  </Accordion>

  <Accordion title="Cuando utilizo addData(), ¿los datos están disponibles para la segmentación de inmediato?">
    Sí, los datos están disponibles inmediatamente para la segmentación. Los datos estarán disponibles durante la sesión del visitante en los SDKs basados en servidor y durante el tiempo de vida configurado en los SDKs basados en cliente (móviles y web).
  </Accordion>

  <Accordion title="¿Dónde se almacenan los datos?">
    Depende del tipo de SDK.

    En los SDKs de servidor, los datos del visitante se almacenan en la memoria operativa durante la sesión del visitante. La duración de la sesión puede configurarse, aunque el valor predeterminado es de 30 minutos.

    <Note>
      Cuanto mayor sea la duración de la sesión mediante el parámetro sessionDuration, más datos retendrá el SDK en memoria. Más datos significan un mayor consumo. La sesión se prolonga 30 minutos adicionales cada vez que se contacta con un visitante. De este modo, el SDK garantiza que los datos no se eliminarán al menos durante 30 minutos desde la última solicitud.
    </Note>

    En los SDKs cliente (móviles y web), los datos se almacenan en almacenamientos locales (en el LocalStorage del navegador). Los datos pueden almacenarse de forma indefinida; sin embargo, mediante el parámetro [dataExpirationInterval o targetingDataCleanupInterval](../../sdks/web-sdks/js-sdk#configuration-parameters), puede establecer la fecha de expiración de los datos, tras la cual estos se eliminarán.
  </Accordion>

  <Accordion title="¿Cuándo es buen momento para vaciar los datos?">
    Por lo general, no es necesario invocar el método "flush" manualmente: los datos se envían junto con otras llamadas a los [métodos del SDK](#which-methods-trigger-http-requests-are-they-synchronous-or-asynchronous). No obstante, si necesita enviar datos a la Data API sin activar el feature flag del visitante, utilice el método "flush".
  </Accordion>

  <Accordion title="¿Cómo utilizo datos recopilados previamente para la segmentación?">
    Si dispone de un SDK basado en servidor, los datos se almacenan durante la sesión de un visitante. No es necesario cargar los datos en cada solicitud si la sesión del usuario no ha caducado. En los SDKs móviles, los datos se almacenan indefinidamente (o conforme a su configuración).

    Si la sesión del usuario ya no está activa o si el visitante se desplaza entre dispositivos en el SDK cliente, invoque el método `getRemoteVisitorData` con los parámetros adecuados para obtener los datos enviados a la Data API. Tras la carga, los datos se incluyen en la segmentación del visitante.
  </Accordion>

  <Accordion title="¿Por qué mi experimento no está recopilando datos?">
    <Warning>
      Si el consentimiento legal está activado, los datos solo pueden recopilarse con el consentimiento de los visitantes.
    </Warning>

    Si está utilizando la regla Experimento y no recibe estadísticas de los visitantes, asegúrese de que:

    * **En la [aplicación Kameleoon](https://app.kameleoon.com)**

      * La regla se ha creado para el entorno correcto (producción, staging o desarrollo).
      * La regla está habilitada (activada).
      * La regla se dirige a tráfico que realmente puede estar expuesto.
      * Si el filtrado de bots está activado en su proyecto, [añada User Agent al filtro](/user-manual/faq#how-does-kameleoon-filter-bot-traffic-from-my-results).

    * **En el SDK**

      * El KameleoonClient se ha creado con la configuración correcta (siteCode, variable de entorno y, en su caso, networkDomain).
      * getVisitorCode se invoca una sola vez y su valor se reutiliza dondequiera que se necesite el visitorCode.
      * Si se utiliza el modo híbrido (engine.js en el front), el visitorCode está correctamente sincronizado con el front end.
      * Para las reglas de experimento, se invoca setLegalConsent(true) para garantizar que se permite la recopilación de datos.
      * Para las reglas de entrega, se invoca isFeatureActive() (o getVariation()) y devuelve true (o la variación esperada).
      * Para las reglas de experimento, se invoca getVariation() y devuelve la variación esperada.

    * **Consejos de depuración**

      * Muestre en consola: el valor del consentimiento, el visitorCode y los valores de las variaciones, y compruebe que coinciden con lo que observa en el navegador.
      * Active el registro del SDK y compruebe si aparecen errores.
  </Accordion>

  <Accordion title="¿Qué datos necesitan consentimiento para ser enviados?">
    Según las reglas del RGPD, sin el consentimiento del visitante, Kameleoon solo utiliza la información técnica necesaria para el correcto funcionamiento de la funcionalidad del producto.

    Sin consentimiento, Kameleoon envía las variaciones de las reglas de Targeted Delivery (pero no las de las reglas de Experimento). El resto de la información (por ejemplo, CustomData, vistas de página y geolocalización) se envía únicamente con el consentimiento del visitante (cuando se ha otorgado el permiso).

    Puede leer sobre la gestión del consentimiento con más detalle [aquí](/user-manual/project-management/consent-management-policy#how-to-choose-your-consent-management-policy).
  </Accordion>

  <Accordion title="¿Cuándo envía el SDK una solicitud de seguimiento para analítica?" id="when-does-the-sdk-send-a-tracking-request-for-analytics">
    De forma predeterminada, el SDK agrupa varios eventos y envía una solicitud de seguimiento a los servidores de Kameleoon con fines analíticos en un intervalo configurable. Este enfoque mejora la eficiencia y reduce la carga del servidor.

    Se enviará una solicitud de seguimiento:

    * **Periódicamente:** De forma predeterminada, se envía una solicitud cada **1000 milisegundos (1 segundo)**. Puede cambiar este intervalo configurando el valor del **intervalo de seguimiento**.
    * **Bajo demanda:** Al instante, si se invoca un método como `flush(instant=true)` en su código.

    Concretamente, se desencadena una solicitud de seguimiento si se invoca cualquiera de los siguientes métodos antes de que expire el intervalo:

    * `getVariation` (cuando `track` se establece en `true`).
    * `getVariations` (cuando `track` se establece en `true`).
    * `isFeatureActive` (cuando `track` se establece en `true`).
    * `trackConversion`
    * `flush` (con o sin `instant=true`)

    Además de las invocaciones de los métodos anteriores, los **SDKs del lado del cliente** envían una solicitud de seguimiento cada **60 segundos** de forma predeterminada si no se ha producido ninguna otra actividad, lo que ayuda a mantener la sesión del visitante. Puede cambiar este valor predeterminado configurando el parámetro `activityTrackingIntervalMillisecond` (o `activity_tracking_interval_millisecond`) en la configuración del SDK.

    En el caso de los **SDKs del lado del servidor**, el agrupamiento de eventos resulta especialmente útil, ya que cada solicitud de seguimiento puede consolidar los datos de varios visitantes en una sola solicitud. Este enfoque agrega la información de todos los visitantes afectados y la envía una vez por intervalo, mejorando la eficiencia y reduciendo la carga del servidor.

    <Warning>
      Las solicitudes de seguimiento están sujetas a los [límites de tasa de la Data API](../../apis/data-api-rest/overview#rate-limits).

      Para los **SDKs del lado del cliente**, en entornos donde varios visitantes comparten la misma red (por ejemplo, en una oficina), pueden parecer originarse desde la misma dirección IP, lo que puede superar el límite de tasa y provocar un error `429 - Too Many Requests`.
    </Warning>
  </Accordion>

  <Accordion title="¿Qué métodos desencadenan solicitudes HTTP? ¿Son síncronos o asíncronos?" id="which-methods-trigger-http-requests-are-they-synchronous-or-asynchronous">
    <Note>
      En diferentes SDKs los métodos pueden tener nombres distintos debido a las particularidades de cada lenguaje.
    </Note>

    A continuación se muestra una lista de los métodos del SDK que realizan solicitudes HTTP:

    * isFeatureActive / getFeatureVariationKey / getFeatureVariable / trackConversion / flush
      * Estos métodos realizan solicitudes asíncronas a la Data API para almacenar toda la información sobre el visitante (incluidas las variaciones recibidas por el usuario), que se utilizan para mostrar estadísticas en app.kameleoon.com.
    * getRemoteData / getRemoteVisitorData / getWarehouseAudience
      * Estos métodos realizan solicitudes síncronas a la Data API para obtener información sobre el visitante.
    * Además, el SDK realiza solicitudes asíncronas para obtener la configuración necesaria para su funcionamiento interno.
  </Accordion>

  <Accordion title="¿Cuándo debo utilizar isFeatureActive o getFeatureVariationKey?">
    `isFeatureActive` puede invocarse cuando necesite saber si el flag está activo, pero no necesite conocer la variación exacta recibida por el visitante. Cuando se usan reglas de experimento, es preferible invocar `getFeatureVariationKey` si dispone de dos o más variaciones además de "off".
  </Accordion>

  <Accordion title="¿Puedo utilizar a la vez un SDK del lado del cliente (incluido el archivo de aplicación engine.js) y un SDK del lado del servidor en mi sitio web?">
    Sí, puede implementar una integración híbrida utilizando tanto un SDK del lado del cliente (como el SDK JavaScript de Kameleoon o el archivo de aplicación `engine.js`) como un SDK del lado del servidor. En esta configuración es imprescindible invocar el método `getVisitorCode`. Esto garantiza un reconocimiento coherente del visitante entre el navegador y el servidor, y asegura una asignación coherente de variaciones al ejecutar tanto el código del lado del cliente (por ejemplo, el seguimiento de eventos) como el del lado del servidor (como la ejecución de funciones) para un mismo feature flag.
  </Accordion>

  <Accordion title="¿Necesito invocar getVisitorCode?">
    Debe utilizar `getVisitorCode` en los casos en los que esté empleando una integración híbrida (sitio web \<-> SDK servidor, JS SDK \<-> servidor, engine \<-> SDK servidor). Al invocar `getVisitorCode`, se obtendrá el código del visitante y se transmitirá mediante una cookie. Si no utiliza una integración híbrida, no necesita invocar `getVisitorCode`; aun así, puede invocarlo para generar un código de visitante aleatorio.
  </Accordion>

  <Accordion title="¿Es obligatorio el dominio para el SDK o para getVisitorCode?">
    La instalación del dominio es necesaria para `getVisitorCode`. De lo contrario, podrían asignarse variaciones distintas a un mismo visitante, ya que tendría códigos de visitante diferentes en los distintos subdominios de su sitio.
  </Accordion>

  <Accordion title="Si utilizo una integración híbrida, ¿debo gestionar el consentimiento dos veces?">
    Si utiliza simultáneamente SDKs de servidor y de cliente, debe establecer el consentimiento en ambos SDKs.

    Consulte [este](../../privacy-and-compliance/consent-management) artículo para más detalles.
  </Accordion>

  <Accordion title="¿Cómo afectan los bloqueadores de anuncios a Kameleoon?" id="how-do-ad-blockers-affect-kameleoon">
    Kameleoon, como muchas soluciones de optimización de la experiencia, puede ser bloqueado por ciertos bloqueadores de anuncios. Estos afectan principalmente al archivo de aplicación de Web Experimentation (`engine.js`) y a los SDKs del lado del cliente, que dependen de código JavaScript cargado en su sitio web. Los SDKs del lado del servidor, sin embargo, operan dentro de sus servidores y no se ven afectados por los bloqueadores de anuncios.

    Si desea que los usuarios con bloqueadores de anuncios se incluyan en sus experimentos, Kameleoon ofrece una opción premium que le permite utilizar un dominio personalizado en lugar del dominio predeterminado de Kameleoon. Los dominios personalizados impiden que los bloqueadores de anuncios detecten y bloqueen Kameleoon. Una vez configurado, Kameleoon utilizará su dominio personalizado para todas las solicitudes de red salientes hacia nuestros servidores, ya sea con fines de seguimiento o para obtener actualizaciones de configuración del SDK.

    Utilizar un dominio personalizado no es lo mismo que el self-hosting. Cuando utiliza un dominio personalizado, la infraestructura de Kameleoon sigue alojando y sirviendo todo el contenido (por ejemplo, `engine.js`, la configuración del SDK, las llamadas de seguimiento). La diferencia es que estas solicitudes se enrutan a través de un dominio que usted controla, como `experiments.mydomain.com`.

    Para habilitar esta opción, póngase en contacto con su Technical Account Manager. Debe proporcionar un dominio completo (por ejemplo, `experiments-mydomain.com`), no un subdominio (por ejemplo, `experiments.mydomain.com`). El nombre de dominio no puede contener la subcadena `kameleoon`.

    * Para Web Experimentation, sustituya las referencias al dominio predeterminado de Kameleoon (`kameleoon.`) por su dominio personalizado.
      * **Ejemplo:** `//SITE_CODE.{your-domain}/engine.js`
    * Para los SDKs del lado del cliente, utilice el parámetro `networkDomain` en la inicialización del SDK.

    Si prefiere alojar usted mismo en lugar de usar un dominio personalizado, siga [esta guía](../../web-experimentation/self-hosting/simple-self-hosting-and-on-premises-options#self-hosting-del-archivo-de-aplicación).
  </Accordion>
</AccordionGroup>