• 3 min de lectura
Rejourney apunta a fugas de ingresos con herramientas de reproducción de código abierto
Rejourney es una plataforma de código abierto para detectar problemas de conversión y retención en aplicaciones web y móviles mediante reproducción, eventos y datos de fallos.

Imagen: Hacker News
Rejourney se presenta como una forma de código abierto para detectar problemas de conversión, retención y ingresos antes de que se propaguen por una aplicación web o móvil. La plataforma combina reproducción de sesiones, eventos definidos por el desarrollador y señales técnicas como fallos de solicitudes, errores y ANR para señalar patrones que merecen investigación.
Funciona pidiendo a los equipos que instrumenten un pequeño conjunto de eventos críticos del producto—por ejemplo, un registro completado, la compra de una suscripción o un pago exitoso. Rejourney registra entonces los datos del recorrido circundante, agrupa sesiones similares en cohortes y presenta informes de incidencias cuando una cohorte muestra una tendencia preocupante alrededor de un evento clave de conversión. Si un equipo conecta un repositorio de GitHub, la plataforma también puede añadir contexto de código y sugerir un cambio en el código.
El proyecto soporta un amplio conjunto de frameworks y plataformas, incluyendo Next.js, React, React Native, Expo, Swift, Vue, Nuxt, Angular, SvelteKit, Remix, Gatsby, Shopify y Hydrogen. En el lado del cliente, sus SDK recopilan contexto de la sesión, rutas o pantallas, interacciones, toques, desplazamientos, toques de frustración (rage taps) y secuencias de eventos. Cuando están disponibles, también adjuntan datos de diagnóstico como tiempos de respuesta de la API, códigos de estado, errores, trazas de fallos y ANR.
Rejourney afirma que la reproducción por sí sola no basta, por lo que combina las grabaciones con vistas de endpoints, detalles de fallos y analíticas a nivel de proyecto como adopción de versiones, interacción, estabilidad, retención y eventos personalizados. Si se conecta una fuente de ingresos, los equipos también pueden inspeccionar transacciones, reembolsos, suscriptores y tendencias más amplias.

Recomendado
Libros falsos inundan Apple Books en horas
Detalles de rendimiento e integración
El proyecto incluye una prueba comparativa web que compara el SDK de navegador de Rejourney con PostHog en fixtures locales de Next.js, SvelteKit y Nuxt. En la ejecución publicada, Rejourney reportó menor tamaño de subida, tiempo de tarea, tiempo de script y uso final de heap en los tres frameworks:
- Next.js: 21.29 KiB de subida frente a 45.35 KiB para PostHog; 417.96 ms de tiempo de tarea frente a 449.91 ms
- SvelteKit: 8.38 KiB frente a 24.99 KiB; 268.72 ms frente a 304.03 ms
- Nuxt: 8.40 KiB frente a 26.57 KiB; 305.51 ms frente a 322.24 ms
La fuente aclara que esto mide la sobrecarga de captura del SDK, no la precisión en la detección de incidencias ni ningún SLA de latencia. La ejecución usó Chromium a 1365×768, con tres iteraciones por framework/modo.
Para móvil, Rejourney compara la huella del paquete con Sentry en Bundlephobia: @rejourneyco/react-native 1.0.17 figura en 39.7 kB minificado y 13.2 kB gzipped, frente a @sentry/react-native 8.7.0 en 403 kB y 135.3 kB. Una prueba de captura registrada por separado en un iPhone 15 Pro con iOS 26, Expo SDK 54 y la React Native New Architecture reportó 12.4 ms de tiempo medio de hilo principal para la captura con UIKit + Metal.
Rejourney soporta integración web, React Native y Swift. Para iOS, requiere iOS 15.1 o posterior. El proyecto también enfatiza controles de privacidad, incluyendo consentimiento, enmascaramiento, muestreo, dominios permitidos y periodos de retención cortos que comúnmente se fijan en siete días. Tras esa ventana, indica que las grabaciones se cuantizan, las huellas se anonimizan y los datos retenidos se agregan en las analíticas del panel.
La licencia está dividida: los componentes del lado cliente, incluyendo SDK y CLI, usan Apache 2.0, mientras que los componentes del lado servidor, incluyendo el backend y el panel, usan SSPL 1.0.
Computing Editor
Tomas lives in the terminal. He covers chips, laptops, and operating systems with a focus on performance and efficiency. He reads kernel changelogs the way other people read fiction, and he's always on the hunt for the perfect mechanical keyboard switch. If it processes data, Tomas has an opinion on it.
vía Hacker News


