Saltar al contenido principal

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:

PlataformaGuía de SDKInicialización
WebSDK webnew JoryioSDK({ sdkKey: 'jry_sdk_web_...' })
iOSSDK de iOSJoryio.shared.initialize(sdkKey: "jry_sdk_ios_...")
AndroidSDK de AndroidJoryio.initialize(context, "jry_sdk_android_...")
React NativeSDK de React NativeJoryio.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, 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, se rechazan las escrituras sensibles solo anónimas (un anonymousId no puede vincularse criptográficamente); llama primero a identify(userId). El registro normal de eventos no se ve afectado.

Para aplicar la postura más estricta, activa Identidad de SDK estricta en la app: exige un userId verificado por autenticación del SDK para cada modificación sensible (consentimiento, registro de push o identify) y rechaza directamente los intentos anónimos y no autenticados.

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​