Documentation menu

Respuestas y webhooks

Todo lo que los destinatarios envían de vuelta — votos de encuesta, envíos de formulario, calificaciones, giros — se recopila por proyecto. Regresa a ti de dos formas: una vista de respuestas por destinatario en el panel, y un webhook opcional que envía cada interacción a tu propio endpoint en el momento en que llega.

Respuestas por destinatario en el panel

Abre Panel de control → tu correo → Respuestas. Cada interacción que el correo ha recopilado se agrupa por destinatario y se combina con la fuente de datos del proyecto. Cada grupo muestra quién respondió — su dirección de correo y los demás campos de su fila — junto con qué hizo: qué bloque, qué acción, los valores enviados, y cuándo.

La atribución funciona mediante los mismos tokens firmados que protegen los enlaces de vista en vivo. Cuando un correo se personaliza a partir de una fuente de datos, los enlaces de cada destinatario llevan un token vinculado a su fila, y las interacciones que llegan con un token válido se atribuyen a esa fila. Las interacciones que llegan sin token (por ejemplo, un voto de encuesta de un correo enviado sin personalización) igual cuentan — se listan en un grupo separado de Anónimo.

La lista de eventos sin procesar está paginada (más recientes primero): una vez que cargaste la página más reciente, una acción de Cargar más obtiene eventos más antiguos. Todo lo demás — resúmenes, histogramas, el embudo y la tendencia — no se ve afectado por esa paginación; está precalculado y siempre cubre todo el historial del proyecto.

Pedidos, cumplimiento y reembolsos

Cualquier proyecto con un bloque de producto obtiene una tabla de Pedidos en su página de Respuestas — una fila por pago, con el comprador, el monto, el estado y el momento en que se realizó.

  • En el momento en que se confirma un pago, se le envía un correo automáticamente al comprador: el contenido de entrega de un producto digital, o una confirmación de que un pedido físico va en camino a su cumplimiento.
  • Para pedidos físicos, haz clic en Marcar como cumplido una vez que lo hayas enviado — MailInApp no gestiona el envío en sí, pero sí le envía al comprador un aviso de envío en el momento en que activas el interruptor.
  • Haz clic en Reembolsar en cualquier pedido pagado para revertir el cobro a través de tu cuenta de Stripe conectada; al comprador se le envía una confirmación de reembolso. El mismo correo se envía automáticamente si una venta se confirma justo cuando se agota la última unidad — MailInApp reembolsa al comprador en lugar de sobrevender en silencio.
  • Contactar comprador abre un ticket de soporte prellenado con el contexto de ese pedido — la forma más rápida de preguntarle algo directamente a un comprador.

Métrica principal según el propósito

Si un proyecto tiene un propósito definido (encuesta, promoción, boletín o evento), la página de Respuestas encabeza con el número que más le importa a ese propósito: tasa de respuesta para encuestas, destinatarios comprometidos para promociones, y aperturas registradas para boletines y eventos. Los proyectos transaccionales y los proyectos sin propósito definido pasan directamente al embudo y a los resúmenes de abajo. Cambia o borra el propósito en cualquier momento desde el menú desplegable junto al título de la página; solo afecta qué número se destaca, nunca lo que se registra.

Resúmenes de CSAT, CES y NPS

Cada bloque de calificación obtiene un resumen encima de la lista de destinatarios: número de respuestas, promedio, y un histograma (la distribución detrás del promedio — un promedio de 4.1 puede esconder si son todos 4 o una mezcla de 5 y 1). Los bloques estilo NPS muestran conteos de promotores/pasivos/detractores y el puntaje de −100…100 en lugar de un simple promedio. Un desglose de distribución de respuestas hace lo mismo para los bloques de encuesta, por opción.

Un embudo de participación (Enviado → Abierto (aprox.) → Respondido) se ubica encima de los resúmenes. Un gráfico de tendencia de respuesta por bloque (en intervalos de día o semana) muestra el promedio a lo largo del tiempo — el valor de una encuesta recurrente está en la línea de tendencia, no en una sola instantánea. Solo se renderiza una vez que un bloque tiene al menos dos intervalos de datos.

Resúmenes de preguntas de encuesta

Cada bloque de formulario obtiene un resumen por pregunta, de la misma forma que lo hacen los bloques de calificación y encuesta. Las preguntas de opción múltiple, casillas de verificación, escala lineal y calificación con estrellas obtienen un gráfico de barras con el conteo de opciones; las preguntas de texto libre (texto corto, texto largo, correo, número, teléfono, fecha) obtienen un conteo de respuestas más un puñado de respuestas de muestra. Las encuestas multipágina se resumen igual que las de una sola página — un envío solo cuenta una vez que se completaron todas las páginas, así que una encuesta abandonada nunca aparece como una respuesta parcial.

Estos resultados de encuesta, calificación y preguntas de formulario no son un callejón sin salida — cualquiera de ellos se puede graficar directamente dentro de un correo futuro vinculando un bloque de gráfico a "respuesta de campaña", sin necesidad de volver a introducir los datos a mano. Mira Vincular gráficos a datos reales.

Tareas y libro de calificaciones

Cada bloque de tarea con al menos una finalización o entrega obtiene una tarjeta de estadísticas (finalizaciones, finalizaciones tardías, entregas) encima de una tabla de Libro de calificaciones. La tabla tiene una fila por estudiante y una columna por tarea, mostrando "Hecho" o la respuesta enviada en verde, o en rojo si llegó después de la fecha límite del bloque. Las tareas sin respuestas todavía no saturan la tabla. Como cualquier otro resumen, está precalculado y cubre todo el historial del proyecto, y ambas exportaciones CSV incluyen una columna de tarea por bloque.

Mapa de calor de clics

Debajo de los resúmenes, un Mapa de calor de clics clasifica cada bloque con enlace simple — botones, imágenes enlazadas, íconos sociales — por número de clics, con una longitud e intensidad de barra proporcional al volumen relativo. Mira cómo se rastrean los clics para saber qué cuenta y qué no.

Embudo de profundidad de desplazamiento

Un embudo de profundidad de desplazamiento muestra qué proporción de los visitantes de la vista en vivo alcanzó cada hito de 25/50/75/100% de la página, así puedes saber si la gente se va temprano o lee hasta el final. Solo refleja las visitas a la vista en vivo alojada, no al correo enviado en sí — mira Profundidad de desplazamiento para entender por qué.

Prueba A/B y ganadores automáticos

Enviar con más de una variante (mira Enviar) agrega una comparación de variantes a la página de Respuestas: tasa de apertura, tasa de clics y tasa de respuesta lado a lado para cada variante, con la líder actual marcada según la métrica que usó la prueba. Cada destinatario se asigna a una variante de forma determinista a partir de su dirección de correo, así que los reenvíos y reintentos nunca reordenan quién vio cuál. Los resultados son acumulados para el proyecto, cubriendo cada envío A/B que haya ejecutado, no solo el más reciente.

Una variante no se limita al texto de la línea de asunto; también puede cambiar la identidad del remitente, o todo el contenido del proyecto. Las propias respuestas de encuesta/cuestionario/RSVP y aperturas de una variante con contenido distinto se rastrean en la página de Respuestas de ese proyecto en lugar de incorporarse a esta comparación, ya que la validación de interacciones vincula un envío al proyecto exacto desde el que se renderizó. El panel de comparación enlaza hacia allá en lugar de mostrar un cero engañoso.

Elegir un ganador automáticamente convierte una prueba A/B manual en una que se ejecuta sola. Elige una fracción de prueba (por ejemplo, enviar al 20% de la lista dividido entre variantes), cuánto esperar antes de decidir, y con qué métrica decidir: apertura, clic, respuesta dentro del correo, o ingresos. La respuesta dentro del correo (finalización de encuesta/cuestionario/RSVP) es la opción recomendada por defecto, ya que no se ve afectada por la Protección de Privacidad de Correo de Apple de la forma en que sí lo está el seguimiento de aperturas.

Una vez que transcurre la espera, MailInApp elige la variante con la mejor tasa por destinatario. Eso nunca es un total bruto, así que una variante que simplemente se envió a más personas en la prueba no puede parecer la ganadora solo por volumen. La ganadora se envía a todos los que se retuvieron de la prueba inicial. Si el resultado es un empate o la muestra fue demasiado pequeña, MailInApp recurre a la variante 1 y lo etiqueta claramente en lugar de declarar alguna vez un ganador falso. El banner de estado en la página de Respuestas muestra exactamente en qué estado está una prueba: aún decidiendo, decidida, empatada, o muestra demasiado pequeña.

Optimización del momento de envío

Disponible en Pro y superior. En lugar de que todos en un envío salgan a la vez, Enviar en el mejor momento de cada destinatario revisa el historial de aperturas de cada contacto — a qué hora del día, en UTC, ha abierto tu correo con más frecuencia. Retiene su mensaje hasta esa hora. Cualquiera sin suficiente historial de aperturas todavía para tener una señal confiable pasa directamente a un envío inmediato normal.

Se aplica de la misma forma a un envío manual, una programación recurrente, y el propio paso de envío de un recorrido; una programación igual envía a todos los que no tienen señal a su propia hora configurada, igual que el comportamiento previo a la optimización. Actualmente no se puede combinar con una prueba de ganador automático en el mismo envío, ya que un destinatario diferido no se contaría para cuando se decida un ganador.

Desglosar por un campo

Usa Desglosar por para agrupar los mismos resúmenes por cualquier campo de tu fuente de datos — CSAT promedio por agente, NPS por plan, y así sucesivamente. Los destinatarios cuya fila fue eliminada o reducida desde el envío se agrupan bajo (desconocido); si un campo de texto libre produce más de 20 valores distintos, los grupos más pequeños se combinan en un grupo final de Otros para que la vista no se sature.

Exportación CSV

Descargar CSV en la página de Respuestas exporta un archivo amplio, de una fila por destinatario: cada campo de la fuente de datos, hora de primera apertura, y una columna por bloque interactivo (encabezada por su pregunta). Las respuestas de seguimiento obtienen su propia columna <pregunta> — seguimiento. Una segunda exportación de eventos sin procesar da una fila por evento (destinatario, bloque, acción, valor, marca de tiempo) para analistas que prefieren el formato largo.

Ciclo de vida de la encuesta

Un proyecto puede tener una fecha de cierre y/o un límite de respuestas (maxResponses). Una vez que se alcanza cualquiera de los dos, los nuevos eventos de interacción se rechazan — la vista en vivo muestra un aviso de cierre en lugar de bloques interactivos, aunque el contenido estático se sigue mostrando — y la página de Respuestas muestra si la encuesta está actualmente cerrada. Nada se filtra de forma retroactiva: las respuestas ya registradas permanecen en tus datos.

Alertas de puntaje bajo dentro de la aplicación

Además del indicador lowScore del webhook (más abajo), un proyecto puede listar hasta un puñado de direcciones de correo para notificar directamente — sin necesidad de un paso en Zapier/Make. Cada vez que una respuesta de calificación cruza el umbral configurado de su bloque, MailInApp envía un correo a esas direcciones (a través de tu propia configuración SMTP) con la pregunta, el puntaje, la identidad del destinatario cuando se conoce, y un enlace directo a la página de Respuestas. Si no hay un relé SMTP configurado, la alerta se omite en silencio — el webhook sigue disparándose. Las alertas están limitadas por proyecto por hora, así una ráfaga de puntajes bajos no puede saturar tu relé.

Reconstruir resúmenes

Los resúmenes, el embudo y la tendencia se sirven desde un resumen precalculado por proyecto, actualizado a medida que llegan los eventos — así se mantienen rápidos sin importar cuánto historial tenga un proyecto. Si un proyecto muestra totales inesperadamente bajos o en cero, probablemente recopiló respuestas antes de que este resumen existiera para él; haz clic en Reconstruir resúmenes en su página de Respuestas una vez para volver a procesar todo su historial de eventos dentro del resumen. Los proyectos nuevos nunca necesitan esto.

Webhooks

Si prefieres que los datos lleguen directamente a tus propios sistemas — un CRM, una hoja de cálculo, una herramienta de automatización — configura un webhook en la misma página de Respuestas: ingresa una URL HTTPS y haz clic en Activar.

Ocurren dos cosas:

  1. Se te muestra un secreto de firma (whsec_…) — cópialo de inmediato, se muestra solo esta vez. Se almacena del lado del servidor y se enmascara en todas partes después, como todas las credenciales en MailInApp.
  2. A partir de ese momento, cada interacción se envía como POST en formato JSON a tu URL, justo después de registrarse.

Puedes rotar el secreto (se genera y se muestra uno nuevo) o eliminar el webhook en cualquier momento.

Payload

{
  "type": "interaction.received",
  "projectId": "abc123",
  "event": {
    "campaignId": "abc123",
    "blockId": "poll-1",
    "blockType": "poll",
    "action": "vote",
    "value": { "option": "Blue" },
    "recipient": "row:3",
    "projectId": "abc123",
    "receivedAt": 1752480000000
  },
  "recipient": {
    "key": "row:3",
    "row": { "email": "[email protected]", "first_name": "Ada" }
  },
  "lowScore": false
}
  • event.value es el propio dato recopilado — la opción de encuesta elegida, los valores de los campos del formulario, la cantidad de estrellas.
  • recipient es null para interacciones anónimas. Para las atribuidas, key es el índice de fila del destinatario en tu fuente de datos ("row:3" = cuarta fila).
  • recipient.row — la fila de datos completa del destinatario — se incluye para fuentes de datos alojadas. Para fuentes de tipo API no llamamos a tu endpoint en cada interacción; combina por el índice de fila de tu lado.
  • lowScore es true cuando el evento es una acción rate en un bloque de calificación cuyo valor cae en o por debajo del umbral de alerta configurado de ese bloque — la señal que filtra una automatización de Zapier/Make (o tu propia alerta dentro de la aplicación) para avisar a un gerente de soporte. Se omite por completo en eventos que no son de calificación, o cuando el bloque no tiene un umbral configurado.

Verificación de firmas

Cada entrega está firmada para que tu endpoint pueda confirmar que realmente vino de MailInApp. Se envían dos encabezados:

| Encabezado | Contenido | | --- | --- | | X-MailInApp-Timestamp | Cuándo se firmó la entrega, en milisegundos de época | | X-MailInApp-Signature | v1= seguido del hexadecimal de HMAC-SHA256(secret, timestamp + "." + rawBody) |

Calcula la firma esperada a partir del cuerpo sin procesar de la solicitud (antes de cualquier análisis JSON) y compárala con una comparación de tiempo constante. Rechazar marcas de tiempo obsoletas bloquea las entregas repetidas:

import { createHmac, timingSafeEqual } from "node:crypto";

function isValidDelivery(headers, rawBody, secret) {
  const timestamp = headers["x-mailinapp-timestamp"];
  const given = Buffer.from(headers["x-mailinapp-signature"] ?? "");
  const expected = Buffer.from(
    "v1=" +
      createHmac("sha256", secret)
        .update(`${timestamp}.${rawBody}`)
        .digest("hex"),
  );
  if (given.length !== expected.length || !timingSafeEqual(given, expected)) {
    return false;
  }
  // Reject deliveries signed more than 5 minutes ago (replay protection).
  return Math.abs(Date.now() - Number(timestamp)) < 5 * 60 * 1000;
}

Semántica de entrega

  • El primer intento es inmediato, y luego se reintenta automáticamente. Las entregas expiran después de 5 segundos; cualquier cosa que no sea una respuesta 2xx (una expiración, un fallo de conexión, o un estado de error) se trata como un fallo. El evento siempre se almacena primero en MailInApp, así que una entrega fallida no pierde nada — trata el webhook como una señal en tiempo real y la vista de Respuestas como la fuente de verdad.
  • Reintentos automáticos con retroceso. Una entrega fallida se reintenta en intervalos crecientes — aproximadamente 1 minuto, 5 minutos, 30 minutos, 2 horas, y luego 6 horas — contra la URL y el secreto actuales de tu webhook, así que un secreto rotado o una URL actualizada se recogen automáticamente. Si todos los reintentos siguen fallando, la entrega deja de reintentarse por sí sola, pero nunca se descarta.
  • Reenvío manual. Cualquier entrega que siga fallando (reintentando o agotada) aparece bajo Entregas fallidas en la página de Respuestas, con el motivo del último fallo y un botón de Reenviar — útil justo después de haber arreglado lo que estaba roto de tu lado, en lugar de esperar el siguiente reintento programado.
  • Nunca en el camino del destinatario. Las entregas ocurren después de que se confirma la interacción del destinatario; un endpoint lento o roto no puede retrasar ni hacer fallar su voto o envío.
  • Responde rápido. Devuelve cualquier 2xx rápidamente y haz el procesamiento pesado de forma asíncrona.

Aviso sobre confianza: los endpoints de interacción son públicos por necesidad (una bandeja de entrada no puede autenticarse), así que los eventos anónimos no están autenticados por diseño. Los eventos atribuidos están protegidos por tokens de destinatario firmados. Verifica la firma de la entrega, y trata event.value como entrada de usuario.