Creación de apps

Una app representa una plataforma en la que haces seguimiento de usuarios - tu sitio web, aplicación iOS o aplicación Android - y tiene la clave de SDK que usa la compilación de esa plataforma. Esta página explica cómo crear una app y empezar a recibir los primeros eventos.

Las apps se crean dentro de un espacio de trabajo y necesitas permiso de escritura en Configuración en ese espacio.

1. Crear la app

1. En el panel de Joryio, ve a Configuración → Apps.
2. Haz clic en Crear app.
3. Introduce un nombre de app fácil de reconocer, por ejemplo «Sitio web de producción» o «iOS - App Store».
4. Selecciona la plataforma: web, iOS o Android. No se puede cambiar después; crea una app nueva en su lugar. (Las apps de Shopify, WooCommerce y Magento se crean automáticamente mediante sus integraciones, no desde este diálogo.)
5. Haz clic en Crear.

Si distribuyes en varias plataformas, crea una app por plataforma; consulta Seguimiento multiplataforma. Para React Native, crea una app de iOS y otra de Android.

2. Copiar la clave de SDK

La app nueva aparece en la tabla de apps con su clave de SDK generada, con el formato jry_sdk_<plataforma>_<aleatorio>:

jry_sdk_web_4f2a9c...

Usa el botón de copiar de la columna Clave de SDK. Trata la clave como configuración, no como un secreto que deba quedar escrito en el código: cárgala desde una variable de entorno y nunca la confirmes en un repositorio público. Si una clave se filtra, usa Regenerar clave en la fila de la app; la clave anterior deja de funcionar de inmediato, así que actualiza primero tu despliegue.

3. Integrar el SDK

Instala e inicializa el SDK correspondiente a la plataforma de la app, usando la clave que copiaste:

Plataforma	Guía de SDK	Inicialización
Web	SDK web	new JoryioSDK({ sdkKey: 'jry_sdk_web_...' })
iOS	SDK de iOS	Joryio.shared.initialize(sdkKey: "jry_sdk_ios_...")
Android	SDK de Android	Joryio.initialize(context, "jry_sdk_android_...")
React Native	SDK de React Native	Joryio.initialize(key, apiHost) con la clave de iOS o Android según Platform.OS

La clave debe corresponder a la plataforma: una clave jry_sdk_web_... en el SDK de iOS no registrará esa compilación como una app de iOS.

Después, identifica usuarios y registra tu primer evento:

// Ejemplo del SDK web: las demás plataformas usan llamadas equivalentes
const joryio = new JoryioSDK({ sdkKey: 'jry_sdk_web_...' });

joryio.identify('user_123');
joryio.track('order_placed', { order_id: 'ORD-001', total: 149.99 });

4. Verificar que lleguen los eventos

1. Activa un evento en tu app (o simplemente carga una página: el SDK registra Session Start automáticamente).
2. Abre Analítica → Explorador de eventos en el panel y busca el evento. Los SDK agrupan los eventos y los envían cada pocos segundos, así que espera un momento o llama a flush() para enviarlos de inmediato.
3. Para comprobar una app en particular, vuelve a Configuración → Apps y haz clic en Ver analítica en la app: muestra el total de eventos, usuarios activos y la marca de tiempo del último evento para esa clave de SDK.

Si no aparece nada, sigue la lista de comprobación de Registro de eventos: verificación y depuración.

Gestión continua

Desde la fila de la app en Configuración → Apps también puedes:

• Configurar credenciales de push: APNS para iOS, FCM para Android o habilitar push web (VAPID) para apps web.
• Desactivar una app: se rechazan los eventos enviados con la clave de una app desactivada; los eventos históricos se conservan.
• Regenerar la clave de SDK: una rotación inmediata que invalida la clave anterior.
• Habilitar autenticación del SDK: exigir opcionalmente un JWT firmado por el cliente (en la cabecera X-Joryio-Auth) en cada solicitud de ingesta de la app que nombre a un usuario identificado, verificado con una clave pública que registres.
• Eliminar la app: detiene permanentemente el seguimiento de esa clave; los eventos históricos se conservan.

Proteger la identidad: autenticación del SDK (recomendado)

Tu clave de SDK es pública: se incluye en tu sitio web o app y, por diseño, cualquiera puede extraerla. Por sí sola autentica la app, no al usuario final: como cualquier SDK de analítica del lado del cliente, una solicitud lleva un userId/anonymousId proporcionado por el cliente que identifica a qué contacto se refiere, pero no demuestra que quien llama controle ese contacto.

Para la mayoría de los registros de eventos, esto es suficiente. Pero en operaciones de identidad sensibles - cambiar el consentimiento, registrar un destino de push o fusionar perfiles mediante identify - significa que alguien con tu clave de SDK y un identificador de contacto conocido (a menudo un email) podría actuar sobre ese contacto. Para evitarlo, habilita la autenticación del SDK:

• Tu backend firma un JWT de corta duración (RS256/ES256) cuyo sujeto es el usuario identificado, y el SDK lo envía en X-Joryio-Auth. Joryio lo verifica con la clave pública que registres, de modo que la solicitud queda vinculada a un usuario verificado. Es el modelo estándar para autenticar el tráfico de SDK del lado del cliente.

• Una vez habilitada, toda solicitud que nombre un userId debe llevar un token válido de ese mismo usuario: sin él, o con el de otro usuario, se rechaza con 401. Los visitantes anónimos no tienen token que mostrar, así que las solicitudes anónimas se aceptan - eventos, atributos, consentimiento, registro de push, aliases e in-app por igual. Una excepción impide que esto sirva para eludir el token: un anonymousId que ya pertenece a un usuario identificado no puede usarse para escribir en su perfil (403 con code: "SDK_ANONYMOUS_ID_IDENTIFIED").

• Cerrar sesión no pierde nada. Cuando un usuario cierra sesión (reset()), las solicitudes ya en cola para él conservan su propio token, y el siguiente usuario nunca lo envía. Las retiradas - una baja, el registro de exclusión, la baja de un registro push - se aceptan con un token bien firmado hasta 30 días después de su caducidad; todo lo demás necesita un token vigente. Consulta Las retiradas se entregan siempre.

Para aplicar la postura más estricta, activa Identidad de SDK estricta en la app: además rechaza las escrituras sensibles anónimas (consentimiento, registro de push, atributos, aliases o identify) con 403 y code: "SDK_STRICT_IDENTITY_REQUIRED", de modo que cada una exige un userId verificado por autenticación del SDK.

Recomendamos habilitar la autenticación del SDK para cualquier app que permita a los usuarios finales gestionar el consentimiento o recibir push.

Elige un userId que no se pueda adivinar

La Autenticación del SDK es opcional, y la decisión de activarla es tuya. Hasta que lo hagas, el userId es lo único que hay entre una solicitud y un contacto, así que qué identificador elijas es en sí mismo una decisión de seguridad.

Un usuario siempre puede leer su propio identificador en su propio tráfico. Eso es inevitable e inofensivo. Lo que importa es que conocer un identificador no le diga a un atacante nada sobre el de ninguna otra persona.

Evita

• Direcciones de correo y números de teléfono. Cualquiera que pueda nombrar a tu cliente puede producir su identificador. Aplicar un hash no ayuda: quien conoce el correo calcula el mismo hash.
• Identificadores de base de datos secuenciales o autoincrementales. Un id conocido revela todos los demás, simplemente contando.
• Cualquier valor que ya sea público - valores que aparecen en URL, en el código de la página, en confirmaciones de pedido o en tickets de soporte.

Prefiere

• Un valor opaco y aleatorio por usuario - un UUIDv4 generado una vez y guardado junto al registro de tu usuario.
• Estable durante toda la vida de la cuenta. Cambiarlo divide a una persona en dos contactos, lo que rompe el historial y el consentimiento.

Esto es defensa en profundidad, no un sustituto. Un userId aleatorio encarece un ataque dirigido; la Autenticación del SDK elimina la categoría entera. Si tu app permite a los usuarios gestionar el consentimiento o recibir push, haz ambas cosas.

Contenido relacionado

• Resumen de apps
• Seguimiento multiplataforma
• Registro de eventos