- Recuperar eventos de visita de un visitante determinado.
- Enviar eventos de visita adicionales para un visitante determinado, como eventos de conversión offline.
- Enviar y recuperar datos de producto para un sitecode determinado.
- Almacenar datos adicionales para un visitante determinado, como datos de CRM o de segmentación.
Endpoints de la Data API
Los endpoints se dividen en tres categorías principales de datos:Endpoints de visita
Los endpoints de visita recuperan y envían eventos (conversiones, datos personalizados, segmentos y más) para un código de visitante determinado. Use estos endpoints para importar a Kameleoon datos de compras offline, como compras en tienda física.- GET /visit/visitor: este endpoint recupera datos de visitas recopilados por Kameleoon, como experimentos y personalizaciones disparados para el usuario o segmentos objetivo.
El acceso a este endpoint requiere la solución Feature Experimentation de Kameleoon. Para más detalles, contacte con el Customer Success Manager.
- POST /visit/forget: este endpoint elimina datos para varios visitantes.
- POST /visit/events: este endpoint publica datos para un visitante determinado, como eventos de conversión y de página vista.
Endpoints de producto
Los endpoints de producto recuperan y envían datos de producto para un sitecode determinado. Use estos endpoints para registrar eventos de producto como vista, añadir al carrito o eventos de compra, o para obtener estadísticas sobre productos concretos, como conteos históricos de compras o vistas.- POST /product/events: este endpoint publica atributos de producto y eventos (vista, añadir al carrito y compra) para varios productos. La Activation API utiliza los métodos
obtainProductDatayobtainProductInteractionspara recuperar y usar estos datos para segmentación o recomendaciones. - GET /product/productCounters: este endpoint recupera conteos (número de vistas, cantidades añadidas al carrito, cantidades de transacciones) para varios productos.
- GET /product/productData: este endpoint recupera atributos para varios productos.
Necesita acceso al módulo Product Recommendation o al add-on Product Targeting. Ambos se integran con la solución Web Experimentation. Para más información, contacte con el Customer Success Manager.
Endpoints de map
Los endpoints de map almacenan datos adicionales para una clave determinada (normalmente un código de visitante o un User ID interno). La Activation API y todos los SDKs usan el métodoretrieveDataFromRemoteSource para recuperar y usar estos datos para segmentación. Use el endpoint map para recuperar los datos almacenados para una clave específica.
- GET /map/map: este endpoint recupera datos para una clave determinada.
- GET /map/maps: este endpoint recupera datos para varias claves.
- POST /map/maps: este endpoint publica datos para varias claves.
Autenticación y rate limiting
Autenticación
La Data API utiliza el mismo flujo de autenticación que la Automation API, usando JSON web tokens. Mantenga la seguridad y proteja las credenciales de API utilizando autenticación para tipos específicos de solicitudes:- Fuentes server-side: para solicitudes que se originan en sus servidores, Kameleoon recomienda encarecidamente la autenticación, lo que aumenta los rate limits. Autentique cuando use SDKs server-side con Feature Experimentation.
- Fuentes client-side: para solicitudes que se originan en una aplicación cliente, como un navegador web, donde las credenciales de API podrían quedar expuestas, no se autentique. Kameleoon no recomienda esta configuración al usar Kameleoon Web Experimentation.
Por defecto, la Data API no requiere autenticación porque da soporte al motor de Web Experimentation para recuperar datos históricos. Si usted utiliza Feature Experimentation y SDKs server-side exclusivamente, contacte con el Customer Success Manager para habilitar la autenticación en endpoints específicos. Kameleoon ofrece una configuración flexible para asegurar endpoints y restringir la autenticación a solicitudes GET o POST.
Rate limits
La Data API aplica rate limits basados en sus Monthly Unique Visitors (MUV) contractuales y en su dirección IP. Si su aplicación supera cualquiera de estos límites, la API devuelve una respuesta HTTP 429 - “Too Many Requests”. Estos rate limits mantienen un rendimiento óptimo y una alta fiabilidad del servicio de Kameleoon para todos los clientes. Puede eliminar los límites basados en IP para las fuentes server-side mediante la autenticación.| Tipo de solicitud | Límites aplicados a todas las solicitudes | Límites adicionales aplicados solo a las solicitudes no autenticadas |
|---|---|---|
| Solicitudes GET | ((500.000 + número de MUV) / 500) * multiplier solicitudes por minuto por cuenta de cliente | 120 solicitudes por minuto por IP |
| Otros métodos HTTP | ((500.000 + número de MUV) / 50) * multiplier solicitudes por minuto por cuenta de cliente (por método) | 1.200 solicitudes por minuto por IP (por método) |
multiplier depende de su suscripción:
1— solo Web Experimentation2— Web Experimentation y Feature Experimentation
Si necesita rate limits más altos para su caso de uso, contacte con su Account Manager para más información.
Qué genera solicitudes
Entender qué operaciones generan solicitudes GET y POST le ayuda a estimar y gestionar el consumo de su rate limit. El desglose a continuación se aplica principalmente a las tecnologías client-side (engine.js, el SDK de JavaScript y los SDK móviles), donde cada dispositivo emite sus propias solicitudes. Para las solicitudes POST de tracking, los SDK server-side son más eficientes a escala porque pueden agrupar datos de múltiples visitantes en una sola solicitud; las solicitudes GET siempre se dirigen a un único visitante. Su aplicación solo activa solicitudes GET cuando llama explícitamente a una de las siguientes operaciones. El SDK y el motor no realizan ningún sondeo automático:- Recuperación de datos de visitantes:
getRemoteVisitorData()(SDKs) operformRemoteSynchronization()(engine.js) cargan datos de visitantes remotos para un visitante específico bajo demanda. - Recuperación de datos remotos y de audiencias warehouse:
getVisitorWarehouseAudience()(SDKs) oretrieveDataFromRemoteSource()(SDKs y engine.js) cargan datos del data warehouse o datos de map remotos bajo demanda.
- Solicitudes de tracking: la llamada POST recurrente principal. El SDK o el motor agrupa los datos de visitantes pendientes y los envía como máximo una vez por intervalo de tracking, solo cuando hay datos pendientes. El intervalo predeterminado es de 1 segundo. En los SDKs, puede configurar el intervalo entre 1 y 5 segundos usando
trackingIntervalMillisecond/tracking_interval_millisecond; engine.js usa un intervalo fijo de 500 milisegundos. Las conversiones, las evaluaciones de feature flags rastreadas y las llamadas explícitas aflush()ponen en cola los datos para el siguiente intervalo, o los envían inmediatamente si activa un flush instantáneo. - Tracking de actividad: un mecanismo secundario que contribuye datos de actividad del visitante (clics, desplazamientos y movimientos del ratón) en el próximo envío de tracking. El SDK solo recopila datos de actividad mientras el usuario está activo en la pestaña activa. El intervalo predeterminado es de 60 segundos. En los SDKs, puede configurarlo usando
activityTrackingIntervalMillisecond/activity_tracking_interval_millisecond; engine.js usa un intervalo fijo de 60 segundos.
flush({instant: true}) explícitamente. Cuando el motor de Kameleoon (window.Kameleoon) también está presente en la página, el SDK previene el seguimiento duplicado de actividad.
Límites a nivel de cuenta
Los límites de frecuencia se aplican a toda su cuenta de cliente, no a proyectos individuales. Si un proyecto genera un número excesivo de solicitudes (por ejemplo, porque una implementación defectuosa crea un bucle que envía eventos de datos personalizados repetidamente), ese proyecto consume el límite compartido de la cuenta y puede causar errores HTTP 429 en todos sus otros proyectos.Diagnóstico de volumen excesivo de solicitudes
Use la página Live events (Insights > Live events) para identificar qué proyecto está generando tráfico inesperado:- Verificar el volumen de eventos por proyecto: Seleccione cada proyecto por turnos y revise el recuento de eventos de la última hora o de las últimas 24 horas. Un proyecto que genera muchos más eventos de los que justifica su volumen de visitantes (por ejemplo, decenas de millones de eventos con un contrato de 100.000 MUV) es probablemente la fuente del problema.
- Filtrar por tipo de evento: Una vez que identifique el proyecto sospechoso, filtre los eventos por tipo. Los eventos de datos personalizados son la causa más frecuente de volumen inesperado. Una implementación mal configurada puede crear un bucle que envía la misma variable de datos personalizados, o todas las variables de datos personalizados, en cada carga de página, produciendo un gran número de eventos en poco tiempo.