Una aplicación Electron no es una página web aunque esté hecha a partir de una, así que aquí no hay etiqueta script: hay un paquete y una llamada por proceso. Véase medir una aplicación para lo que eso te da. El paquete Electron de Skomi no depende de nada más que de Electron.

El código fuente, y una aplicación de demostración que se mide a sí misma, están en skomi-sdk-electron.

Tres procesos, tres líneas

// main.js — arráncalo una vez
const skomi = require('@skomi/electron').init({
    appId: 'your-app-id',
});

skomi.screen('launch');

// preload.js — exponlo a la ventana
require('@skomi/electron/preload');

// renderer — donde vive tu enrutado
window.skomi.screen('checkout/review', { tier: 'gold' });

Esa es toda la integración. El identificador de la aplicación viene de My Apps en Skomi. No es un secreto y su sitio está en tu código fuente: identifica una aplicación en vez de autenticarla, igual que un identificador de sitio.

⚠ No eches mano del fragmento web en tu renderer. Ese mide un sitio: quiere un nombre de host, un documento que vigilar y una red con la que poder contar, y una ventana de Electron no tiene nada de eso de la forma que él espera. El SDK existe porque los problemas de una aplicación de escritorio son otros.

Nombra tus pantallas

No hay captura automática, y es deliberado: una ruta es lo que tu código llama una pantalla, no lo que tú llamarías así en un informe. Hasta 20 propiedades por pantalla: cadenas, números o booleanos.

Lo que resuelve el SDK y tendrías que escribir tú

Funciona sin conexión. Las pantallas se ponen en cola en el disco, en el directorio de datos propio de la aplicación, y sobreviven a cerrarla, a un fallo y a quince días sin red. Una aplicación de escritorio que solo informara estando en línea perdería justo las sesiones que importan.

No cuenta dos veces. Cada pantalla lleva un identificador emitido una vez y reenviado sin cambios, así que un lote reintentado se reconoce en vez de contarse otra vez. Una cola sin conexión sin eso convierte lo que salva tus datos en lo que se los inventa.

Sobrevive a un reloj mal puesto. Cada lote registra cuándo se vació, así que el servidor puede calcular cuánto se desvía el reloj de la máquina y corregir el lote. Un portátil puesto en el martes que viene informaría si no del martes que viene.

Nunca lanza una excepción dentro de tu código. Argumentos malos, un servidor inalcanzable, un directorio de perfil en el que no se puede escribir; todo se trata internamente y se informa por onError si quieres saberlo. La analítica es lo menos importante que hace tu aplicación.

Esperar el consentimiento

const skomi = require('@skomi/electron').init({ appId: '…', enabled: false });

// más adelante, una vez que el usuario haya dado su acuerdo
skomi.setEnabled(true);

No se registra nada mientras está desactivado, ni siquiera se pone en cola para más tarde. Una pantalla vista antes de que alguien diera su acuerdo no es una pantalla que debieras mandar después.

Errores y fallos

skomi.captureError(err, { screenName: 'checkout', fatal: false });

Puestos en cola, guardados y reintentados como una pantalla, y desduplicados por la misma regla, lo que importa más aquí, porque un fallo se manda casi siempre desde la cola en el siguiente arranque.

⚠ captureUncaught está apagado de serie, y piénsalo antes de encenderlo. Poner un escucha en uncaughtException es precisamente lo que impide que Node salga, así que un informador de fallos instalado de serie convertiría un fallo fatal en un proceso que sigue corriendo sobre un estado corrupto. Con el interruptor encendido, la semántica se restablece: el informe se escribe en el disco de forma síncrona, el escucha se quita, y el error se vuelve a lanzar.

Opciones

init({
    appId: '…',                     // requerido
    appVersion: app.getVersion(),   // por defecto: se le pregunta a Electron
    origin: 'https://t.skomi.com',  // a sustituir si te autoalojas
    enabled: true,                  // empieza en false, enciéndelo tras el consentimiento
    flushIntervalMs: 10000,
    onError(error, context) { },    // 'screen' | 'flush' | 'transport' | 'rejected' | 'queue'
});

init cablea el canal del renderer y vacía la cola al salir. Si quieres un cliente cuya vida controles tú (sin IPC, sin gancho de salida), usa createClient en su lugar.

Lo que una aplicación no obtiene

⚠ Solo la analítica lee una aplicación. Los mapas de calor, las grabaciones de sesión y el widget de opiniones son productos para sitios: necesitan una página en un navegador, y no hay nada a lo que agarrarse en una ventana de escritorio. Una aplicación informa de pantallas, sesiones, versiones, plataformas y errores, y eso es todo.

Véase medir una aplicación para lo que hace el panel con ellas, y instalación en MAUI o Flutter si además publicas el mismo producto ahí.