Cómo medir los leads y las ventas de Tu propia aplicación
Mide las altas de tu SaaS o web propia, atribuidas al link que las trajo.
EN RESUMEN
| Qué mide NEMO | Leads · Ventas |
|---|---|
| Conexión | Nativa — se activa desde la app de NEMO |
| Método | «El campo oculto del formulario» · Server-side · máxima fiabilidad |
| Pasos | 6 en total, con comprobación de un minuto al final |
| A tener en cuenta | LA IDENTIDAD DEL cliente: manda el EMAIL en claro. Como la llamada va autenticada por tu token, NEMO lo hashea con la clave de TU workspace (la misma identidad que ya usan los webhooks de Stripe o Kit) y no lo guarda en claro. No tienes que calcular nada. |
Con Tu propia aplicación, NEMO mide qué link trae cada lead y qué link trae cada venta sin píxeles ni Google Analytics. Saber qué link tuyo trajo a cada persona que se da de alta o compra en tu propia aplicación, sin depender de Kit ni de una pasarela. Dos extremos. En tu WEB, el script deja que el nm_id del link viaje contigo hasta tu backend. En tu BACKEND, cuando el alta se confirma, tu servidor avisa a NEMO server-to-server. El email jamás sale de tu casa: mandas un identificador opaco. El método es «El campo oculto del formulario» (server-side · máxima fiabilidad): Tu formulario lleva un campo invisible (nemo_click_id) que viaja con cada alta hasta tu plataforma de email. NEMO lo recibe de servidor a servidor: el lead llega ya atribuido a su link de origen. LA IDENTIDAD DEL cliente: manda el EMAIL en claro. Como la llamada va autenticada por tu token, NEMO lo hashea con la clave de TU workspace (la misma identidad que ya usan los webhooks de Stripe o Kit) y no lo guarda en claro. No tienes que calcular nada. La conexión completa son 6 pasos y se comprueba con un clic de prueba.
¿Cómo llega cada lead de Tu propia aplicación con su origen?
El campo oculto del formulario · Server-side · máxima fiabilidad
Dos extremos. En tu WEB, el script deja que el nm_id del link viaje contigo hasta tu backend. En tu BACKEND, cuando el alta se confirma, tu servidor avisa a NEMO server-to-server. El email jamás sale de tu casa: mandas un identificador opaco.
- Extremo 1 · pega el script de NEMO en tu landing y en tu app (una vez). Deja que el nm_id viaje del link a tu web:
<script src="https://nemolink.app/nemo.js" defer></script> - Si tu app vive en OTRO dominio registrable que tu landing (p. ej. la landing en criptoterminal.com y la app en app.otro.com), decláralo una vez para que el nm_id salte también allí:
window.nemo.hosts(['app.otro.com']); - Cuando el usuario empieza el alta, pasa a tu backend el nm_id que ve el frontend con window.nemo.id() (campo oculto del formulario o cuerpo de tu fetch).
- Extremo 2 · cuando tu servidor confirma el alta, avisa a NEMO. Tu URL de ingest lleva el token dentro (la tienes en la tarjeta «Tu propia aplicación» de Integraciones) — trátala como un secreto:
// En tu backend, cuando alguien se da de alta: await fetch("https://nemolink.app/api/ingest/TU_TOKEN", { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ event: "lead", // "sale" para una venta (+ amount_cents) email: usuario.email, // NEMO lo hashea; no se guarda en claro nm_id: alta.nm_id ?? undefined, // el que llegó del frontend (nemo.js) }), }); - ¿Prefieres que lo cablee tu asistente de código? Pégale esto — trae los dos extremos, con tu endpoint y tu payload:
Conecta MI aplicación a NEMO para medir las altas por link (dos extremos). EXTREMO 1 · el script en mi web (frontend) Carga esta etiqueta de la forma idiomática de mi stack (Next.js: next/script strategy="afterInteractive" en el layout raíz; Astro/HTML: antes de </body>): <script src="https://nemolink.app/nemo.js" defer></script> Cárgalo en la landing Y en la app: así el nm_id viaja del link a mi web, y de mi web a mi backend (nemo.js decora los enlaces salientes a hosts de MI mismo dominio registrable — si mi app vive en otro dominio, lo declaro con window.nemo.hosts(['app.midominio.com'])). Cuando alguien empieza el alta, pasa el nm_id que ve el frontend (window.nemo.id()) al backend junto con el formulario. EXTREMO 2 · la recepción en mi backend (server-to-server) Cuando el alta se confirma en mi servidor, avisa a NEMO. La URL está autenticada por su token, así que mando el email en claro y NEMO lo hashea con la clave de mi workspace (no se guarda en claro). Guarda el nm_id JUNTO al registro del usuario. await fetch("https://nemolink.app/api/ingest/TU_TOKEN", { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ event: "lead", // "sale" para una venta (+ amount_cents) email: usuario.email, nm_id: alta.nm_id ?? undefined, // el que llegó del frontend }), }); Trata la URL como un secreto (lleva el token). Verifica al terminar: una alta de prueba devuelve {"ok":true} y, con nm_id válido, "attributed":true.
Nota: LA IDENTIDAD DEL cliente: manda el EMAIL en claro. Como la llamada va autenticada por tu token, NEMO lo hashea con la clave de TU workspace (la misma identidad que ya usan los webhooks de Stripe o Kit) y no lo guarda en claro. No tienes que calcular nada.
Nota: CASO AVANZADO — si NO quieres mandar emails: manda un `external_id` OPACO en su lugar (HMAC de tu id interno con un secreto tuyo, en hex; nunca el email, un id numérico ni un uuid del payload). Es opcional: el email es el camino normal.
Nota: QUÉ GUARDAR en tu base de datos: el nm_id JUNTO al registro del usuario (una columna al lado del alta). Las UTM son TUYAS — NEMO no las necesita; guárdalas si las quieres para tu propia analítica.
Nota: CUÁNTO DURA: el ancla del origen vive 90 días en el navegador (lo que declara /legal/cookies). En el plan free ves 30 días de histórico en el panel; el dato se guarda igual, es la ventana visible la que se acorta.
Nota: EL LÍMITE DE hosts propios usa una lista de sufijos públicos RECORTADA (las familias de uso real: .co.uk, .com.br, .com.mx, .com.ar…), no la lista completa. Cubre la práctica totalidad de los dominios; si el tuyo es un ccTLD raro que no salta solo, decláralo con window.nemo.hosts(['tu.dominio']).
Nota: PRIVACIDAD — LO TUYO, QUE AQUÍ SON DOS TRATAMIENTOS: respondes del de tu WEB (donde corre nemo.js) y del de tu BACKEND (donde guardas el nm_id junto al usuario). El nm_id en tu base es un DATO PERSONAL SEUDONIMIZADO mientras puedas cruzarlo con tu tabla de usuarios: nómbralo en tu política de privacidad y en tu registro de actividades de tratamiento, aplícale tu base jurídica y tu plazo de conservación, y trátalo con el mismo cuidado que el resto de la ficha del usuario. NEMO recibe de ti un identificador opaco y un origen, jamás el email en claro.
¿Cómo se atribuye cada venta de Tu propia aplicación?
El campo oculto del formulario · Server-side · máxima fiabilidad
La misma llamada, con event: "sale" y el importe en céntimos. Es una fuente AUTENTICADA (tu token), así que la venta cuenta de verdad — mueve dinero en tu panel.
- Cuando tu backend confirma un cobro, avisa igual que el alta pero como venta:
await fetch("https://nemolink.app/api/ingest/TU_TOKEN", { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ event: "sale", email: usuario.email, // el MISMO email del alta amount_cents: 4900, // 49,00 € nm_id: alta.nm_id ?? undefined, }), });
Nota: El mismo email (o el mismo external_id, si usas el caso avanzado) para el alta y para la compra: así NEMO une el lead y la venta de esa persona. El email se hashea; no se guarda en claro.
Compruébalo en un minuto
- En la tarjeta «Tu propia aplicación» de Integraciones, pulsa «Enviar prueba»: recorre el circuito real y te dice qué se aceptó.
- Con un nm_id válido la respuesta trae "attributed": true; si trae "attributed": false, el que falla es el nm_id (caducado o no capturado), no tu llamada.
- Un alta de prueba desde tu backend devuelve {"ok":true} y aparece en Inicio, atribuida a su link.
Preguntas frecuentes
- ¿Qué hago si el alta entra pero llega «sin origen» (attributed:false)?
- El nm_id no llegó o no resuelve. Revisa que el frontend lo capture (window.nemo.id()) y lo pase a tu backend, y que el link fuera de NEMO. La llamada está bien; es el origen lo que falta.
- ¿Qué hago si el ingest devuelve 422 «weak_external_id»?
- Solo pasa por el caso avanzado: estás mandando un `external_id` que no es opaco (un email, un número, un uuid). Lo normal es mandar `email` en claro y dejar que NEMO lo hashee — así no hay nada que validar.
- ¿Qué hago si el ingest devuelve 404?
- El token de tu URL no es válido (o lo rotaste). Copia la URL actual desde la tarjeta «Tu propia aplicación».
- ¿Qué hago si el nm_id no salta de mi landing a mi app en otro dominio?
- nemo.js solo decora hosts de tu MISMO dominio registrable. Si la app vive en otro dominio, decláralo: window.nemo.hosts(['app.otro.com']).
FUENTES OFICIALES
Guía verificada contra la documentación oficial el 2026-09-11.
TAMBIÉN SE INTEGRA CON
Mide Tu propia aplicación desde tu primer link.
Gratis durante el acceso anticipado. Los primeros usuarios tendrán condiciones especiales cuando lancemos los planes.