Tracking de eventos

Cómo funciona el tracking de envíos (delivered, bounced, opened, clicked) — desde SES hasta tu webhook. Self-hosted, sin costos extra.

ReallyQuickEmails trackea 5 tipos de eventos por cada email enviado. Algunos vienen de AWS SES (gratis con tu cuota), otros son self-hosted en RQE (cero costo extra). Esta página explica cómo funciona cada uno y cómo se materializan en tu webhook.

Los 5 eventos

Evento	Origen	Costo	Confiabilidad
`sent`	SES (Send)	gratis	100% — RQE lo emite cuando SES acepta
`delivered`	SES (Delivery)	gratis	~99% — depende de que el receptor responda al SMTP
`bounce`	SES (Bounce)	gratis	100% — hard y soft bounces
`complained`	SES (Complaint)	gratis	100% — usuario marcó como spam
`opened`	RQE self-hosted	gratis	~70% — depende de que el cliente cargue imágenes
`clicked`	RQE self-hosted	gratis	~99% — solo falla si el usuario copia/pega el link manual

Eventos SES (entrega + rebotes)

Cuando RQE envía un email, AWS SES procesa la entrega y publica eventos en un SNS topic dedicado. RQE consume ese topic y actualiza tu activity row + dispara webhook.

Tu app
  ↓ POST /v1/send-email
RQE
  ↓ SES SendEmail (raw MIME)
SES
  ↓ procesa entrega
  ↓ Send / Delivery / Bounce / Complaint event
SNS topic
  ↓ POST /webhooks/ses
RQE webhook processor
  ↓ INSERT email_events
  ↓ UPDATE activity (status + timestamp)
  ↓ POST a tu webhook_url (firmado HMAC)
Tu sistema recibe el evento

Bounces — soft vs hard

Tipo	Descripción	Acción de RQE
Hard bounce	Dirección no existe (`550 5.1.1`)	Agrega a suppression list permanente. Próximos envíos al mismo recipient retornan `skipped: true`
Soft bounce	Mailbox lleno, server temporalmente caído	Marca el evento, no agrega a suppression. Próximo envío reintenta

Si tu tasa de bounces supera 2%, AWS SES manda warning. Si supera 5%, suspende temporalmente tu cuenta. Limpia tu lista regularmente — un email viejo es un bounce que está esperando suceder.

Open tracking (self-hosted)

RQE inyecta un pixel 1x1 transparente en el HTML del email. Cuando el cliente de email del destinatario carga las imágenes, hace GET al pixel y RQE registra el open.

<!-- Inyectado automáticamente al final del <body> -->
<img src="https://api.reallyquickemails.com/t/o/{activityId}" width="1" height="1" />

Por qué la confiabilidad es ~70%

Outlook desktop bloquea imágenes externas por default → no detecta open
Gmail mobile/web carga imágenes vía proxy de Google → siempre detecta open (incluso para contactos no leídos en algunos casos)
Apple Mail iOS 15+ con MPP (Mail Privacy Protection) carga el pixel automáticamente al recibir → reporta open antes de que el usuario abra realmente
Clientes de texto plano (terminal mail, accessibility) → no cargan imágenes

Tratá los opens como aproximados

Por las razones de arriba, los opens son señal de tendencia (¿este send lo abre más gente que aquel?), no de comportamiento individual exacto. Para conversión real, mirá clicks.

Click tracking (self-hosted)

Antes de enviar, RQE reescribe los <a href> del HTML para que pasen por un endpoint de tracking que hace 302 redirect al destino original.

<!-- Antes -->
<a href="https://app.reallyquickemails.com/dashboard">Dashboard</a>

<!-- Después de la reescritura -->
<a href="https://api.reallyquickemails.com/t/c/{activityId}?url=https%3A%2F%2Fapp.reallyquickemails.com%2Fdashboard">Dashboard</a>

El usuario no nota nada — el redirect es instantáneo. Los clicks son ~99% confiables porque solo fallan si el usuario copia el href manualmente y lo pega en el navegador (extremadamente raro).

Esquema de la tabla `activity`

Cada email enviado crea una row en activity con timestamps por evento:

id (uuid)

recipient_primary, sender_email, subject

current_status — queued / sent / delivered / bounced / complained

sent_at, delivered_at, bounced_at, complained_at

opened_first_at — primera apertura

clicked_first_at — primer click

is_test — true si fue enviado con sk_test_*

campaign_id, automation_run_id — atribución

Solo se guarda el *_first_at por evento (no múltiples opens/clicks). Para análisis de engagement, los detalles full están en la tabla email_events.

Webhook payload

Tu webhook_url recibe POST con HMAC-SHA256 signature en el header X-RQE-Signature. Body de ejemplo para un email.delivered:

{
  "event": "email.delivered",
  "is_test": false,
  "timestamp": "2026-04-29T15:30:42.123Z",
  "project_id": "...",
  "data": {
    "activity_id": "...",
    "recipient": "user@example.com",
    "sender": "noreply@tudominio.com",
    "subject": "Confirmación de pedido",
    "delivered_at": "2026-04-29T15:30:42.000Z"
  }
}

Verificación HMAC en Node:

const crypto = require('crypto');
const expected = 'sha256=' + crypto
  .createHmac('sha256', apiKey)
  .update(rawBody)
  .digest('hex');
if (req.headers['x-rqe-signature'] !== expected) {
  return res.status(401).send('Invalid signature');
}

Ver Webhooks para el formato completo de cada evento.

Próximos pasos

Webhooks — referencia completa con todos los formatos.
Activity API — endpoints para listar y filtrar envíos.
Test mode — cómo separar tracking dev vs prod.

Tracking de eventos

On this page