Atribución first-party: rastrea visitantes sin cookies de terceros

Lanzas una campaña, ves 400 visitantes en Google Analytics, 12 altas… y eres incapaz de decir cuáles vienen de qué fuente. Bienvenido a la atribución post-cookies de terceros, donde entre el 30 y el 50 % de tu tráfico se ha vuelto invisible. La buena noticia: no necesitas ni GA ni pixels de terceros. Un pixel servido por tu propio dominio basta para reconstruir la cadena visita → alta → ingreso, y sobrevive a todo lo que rompe los trackers clásicos.

Por qué las soluciones clásicas se derrumban

Los pixels de terceros (Meta Pixel, el `gtag.js` de Google, Hotjar…) ponen una cookie o leen un identificador desde un dominio distinto al tuyo. Es exactamente lo que los navegadores han decidido matar. Tres fuerzas convergen y ya las estás sufriendo:

• Safari / ITP: una cookie puesta por JavaScript (`document.cookie`) está limitada a 7 días, y a 24 h si el visitante llega a través de un enlace con parámetros de tracking. Tu atribución a 30 días está muerta antes de empezar.
• Cookies de terceros bloqueadas: Safari y Firefox las bloquean por defecto desde hace años. Chrome dio marcha atrás en la eliminación total en 2024, pero generalizó un opt-out que vacía el depósito igualmente.
• Consentimiento estricto (RGPD): sin banner aceptado, GA y los pixels de marketing no deben cargarse. Resultado: un agujero enorme en tus datos, y un agujero que no es aleatorio (los rechazos correlacionan con ciertos perfiles).

El punto común de estas tres rupturas: apuntan al tercero. Si el identificador viene de tu dominio y solo te sirve a ti, la mayoría de estas reglas no se aplican de la misma forma.

El principio: un pixel first-party + un visitor_id anónimo

La idea cabe en tres piezas. Sirves un endpoint de recolección en tu propio dominio (idealmente un subdominio como `t.tuapp.com`, no un dominio de tracking externo). En la primera visita, generas un `visitor_id` aleatorio y lo guardas en una cookie first-party, HttpOnly, Secure. En cada página vista, el navegador devuelve esa cookie a tu servidor, que registra el evento. El detalle que lo cambia todo: la cookie la pone una respuesta HTTP `Set-Cookie` del lado del servidor, no `document.cookie` en JavaScript. Es ese matiz el que esquiva el límite de 7 días de ITP — la restricción apunta a las cookies puestas en JS, no a las puestas por el servidor en first-party. Y `HttpOnly` las vuelve ilegibles por cualquier script, así que inexplotables para un robo vía XSS.

# Réponse de ton endpoint /t/collect servi sur t.tonapp.com
HTTP/1.1 204 No Content
Set-Cookie: vid=8f3c1a9e-...; Max-Age=63072000; Path=/;
  Domain=.tonapp.com; HttpOnly; Secure; SameSite=Lax

// pixel.js côté client (~10 lignes) :
// fetch("https://t.tonapp.com/t/collect", {
//   method: "POST", credentials: "include", keepalive: true,
//   headers: { "Content-Type": "application/json" },
//   body: JSON.stringify({ path: location.pathname,
//     ref: document.referrer, utm: location.search, ts: Date.now() }) });

La fusión: del visitor_id anónimo a la identidad probada

Mientras el visitante es anónimo, acumulas eventos vinculados a un `visitor_id` opaco. La magia ocurre en el momento del alta: el usuario prueba su email (enlace de confirmación u OTP), y haces el stitching — enlazas el `visitor_id` de la cookie con la cuenta recién creada. En ese instante, toda la historia anónima de antes (primera visita, fuente, páginas vistas) se vincula retroactivamente a una identidad real.

1. En el momento del signup, lee la cookie `vid` del lado del servidor en la misma petición.
2. Escribe una fila `identity(visitor_id, user_id, email_verified_at)` — el email probado, no solo escrito.
3. Recoloca todos los eventos anónimos que llevan ese `visitor_id` al `user_id`. Obtienes el recorrido completo: Twitter → /pricing → /signup → email confirmado.
4. Extra: si el mismo email se reconecta desde otro dispositivo, fusiona dos `visitor_id` bajo un único `user_id`.

Lo que ganas frente a Google Analytics y los pixels de terceros

• Atribución de larga duración: tu cookie de servidor puede apuntar a 2 años en vez de 24 h. Para un funnel B2B donde la decisión tarda 3 semanas, es la diferencia entre atribuir una venta y perderla en el ruido.
• Datos completos: registras del lado del servidor, así que los bloqueadores (uBlock, Brave) que se comen `gtag.js` no te afectan. Ves tu tráfico real, no la versión agujereada por las extensiones.
• Unión directa con tus ingresos: el `visitor_id` está en tu base de datos, junto a tus tablas `users` y `subscriptions`. Haces un `JOIN` SQL entre una fuente y MRR real — imposible con el agregado anonimizado de GA4.
• Cumplimiento más fácil de encuadrar: un identificador estrictamente first-party, con finalidad de medición interna, es más fácil de justificar que mandar el dato a Google y Meta. A validar con tu abogado, pero el alcance es radicalmente más nítido.
• Sin muestreo ni umbral de cardinalidad: GA4 muestrea y oculta los segmentos < ~50 usuarios. En tus propios logs, cada fila existe.

Los errores que rompen el setup en producción

• Servir el pixel desde un subdominio realmente tuyo: un CNAME hacia un dominio de tracking conocido (del tipo `.analytics-vendor.com`) es recalificado como tercero por ITP, que reimpone el límite de 7 días. El subdominio debe resolver hacia tu* infraestructura.
• `SameSite=Lax` como mínimo: con `None` sin motivo, reintroduces comportamiento de tercero. `Lax` cubre el caso normal (clic hacia tu sitio).
• Idempotencia del stitching: un mismo `visitor_id` puede llegar dos veces (doble envío, reintento). Clave única en `(visitor_id, user_id)`.
• Borrar la PII de los logs en bruto: no registres la IP en claro eternamente. Truncar o hashear; guarda la IP justo lo necesario para el geo/anti-fraude.
• El caso "nunca se inscribió": el 95 % de los visitantes nunca se fusionarán. Es normal. Guardas el agregado anónimo para el top-of-funnel, la fusión solo concierne a los convertidos.

Empieza en pequeño: un endpoint, una cookie `Set-Cookie` HttpOnly servida en tu subdominio, una tabla `events(visitor_id, path, ref, ts)` y una tabla `identity(visitor_id, user_id)` poblada cuando el email está probado. Tendrás en una tarde una atribución que sobrevive a Safari, a los bloqueadores y al consentimiento — y que se conecta directamente con tu MRR. Cuando funcione, añade el multi-dispositivo y el conteo de fuentes. El resto es SQL.