Seguimiento de enlaces en Mixpanel: clics de enlaces cortos como eventos

El seguimiento de enlaces en Mixpanel dentro de Elido es del lado del servidor y unidireccional: cada vez que alguien hace clic en uno de tus enlaces cortos, Elido publica un evento link_click en el endpoint de seguimiento de Mixpanel con el token de tu proyecto. El evento lleva el slug del enlace, el ID del enlace, el país y el dispositivo del visitante, el destino al que fue enviado, y una marca de tiempo. Nada se ejecuta en el navegador del visitante, así que los bloqueadores de anuncios y los banners de consentimiento no lo tocan.

El detalle importante es la identidad. Cada evento está indexado al enlace, no a la persona, lo que significa que puedes contar y segmentar clics en Mixpanel todo el día pero no puedes seguir a alguien que hizo clic dentro de tu producto solo a partir de ese evento. Te mostraré para qué sirve, cómo configurarlo, cómo comprobarlo en la vista Events, y los sitios donde yo recurriría a otra cosa.

Si todavía estás decidiendo qué etiquetar antes de todo esto, la guía de referencia sobre seguimiento de UTM de principio a fin es el mejor punto de partida. Mixpanel solo ve lo que lleva el enlace.

Qué envía Elido a Mixpanel en cada clic

Un clic, un evento. El reenviador construye un lote de un solo evento y lo envía con POST a /track en el host de ingesta que coincide con la configuración de residencia de datos de la integración (api.mixpanel.com para EE. UU., api-eu.mixpanel.com para la UE, api-in.mixpanel.com para India), autenticado por el token dentro de las propiedades, que es como la API de ingesta de Mixpanel espera que lleguen los eventos del lado del servidor.

Aquí está el payload completo, recortado solo en el valor del token:

[
  {
    "event": "link_click",
    "properties": {
      "token": "<your project token>",
      "distinct_id": "elido-link-4711",
      "workspace_id": 12,
      "link_id": 4711,
      "slug": "spring-26",
      "country": "DE",
      "device": "mobile",
      "destination": "https://shop.example/spring?utm_source=newsletter",
      "time": 1790000000,
      "ip": "203.0.113.24"
    }
  }
]

Eso es todo. Una lista corta, y a propósito.

Dos detalles que vale la pena conocer. El destination es el ya resuelto, así que si un smart link envía los iPhone a la App Store y a todos los demás a tu sitio, verás ambas URLs. Y las etiquetas UTM viajan solo dentro de esa cadena de destino; no hay propiedades separadas utm_source o utm_campaign, así que si las quieres como columnas necesitarás una propiedad derivada en Mixpanel. Eso es lo único que yo configuraría desde el primer día.

Los bots evidentes, los rastreadores que se anuncian a sí mismos en su user agent, se filtran en la redirección y nunca llegan a Mixpanel.

Configurar la integración de Mixpanel

Toda la configuración son dos campos. Para enviar eventos de clic a Mixpanel necesitas un proyecto de Mixpanel y su token de proyecto, que vive en Project Settings dentro de Mixpanel; el token es una clave de escritura pensada para incrustarse, así que pegarla en un proveedor externo es normal. No pegues el secreto de la API, que es una cadena distinta y no es lo que usa el reenviador.

1. En tu workspace de Elido, abre Integrations y elige la tarjeta de Mixpanel.
2. Haz clic en Connect Mixpanel, pega el token en Project Token, y elige Data residency: US (el valor por defecto), EU o India, según el valor de Data Residency de la configuración de tu proyecto de Mixpanel. Guarda. Elido cifra el token en reposo y nunca te lo vuelve a mostrar completo.
3. Espera unos minutos. La configuración de integración del workspace se guarda en caché brevemente del lado del reenvío, así que los primeros clics tras guardar puede que todavía no se envíen.
4. Haz clic en uno de tus propios enlaces desde un teléfono.

No hay un interruptor por enlace. Una vez conectado, cada clic en el workspace se reenvía, lo que le va bien a un equipo que vive en Mixpanel y no le va bien a un workspace que aloja enlaces cortos para veinte clientes sin relación entre sí. Si ese es tu caso, separa primero los clientes en workspaces distintos.

Comprobar la vista Events antes de confiar en nada

Lo que Mixpanel solía llamar Live View ahora es la vista Events, bajo Data en la navegación izquierda, y la guía de depuración de Mixpanel la recomienda como la primera parada exactamente para este trabajo. Ábrela, filtra por link_click, y luego toca tu enlace corto desde un teléfono que no esté en el wifi de la oficina.

Deberías ver el evento en segundos. Despliégalo y comprueba tres cosas: slug coincide con el enlace que tocaste, country es donde realmente está el teléfono, y la ciudad y región propias de Mixpanel están rellenadas a partir de la ip. Si la ciudad muestra un centro de datos, tu prueba pasó por una VPN.

El botón Test connection del panel de integración envía un link_click marcado como elido_test: true y muestra la respuesta de Mixpanel debajo del botón. Es útil, pero no es prueba: el endpoint de seguimiento de Mixpanel acepta cualquier token y nunca comprueba la residencia, así que un resultado verde con el token equivocado o la región equivocada igualmente significa que no llega nada a tu proyecto. El evento que ves llegar desde un clic real es la única prueba que yo aceptaría.

Por qué distinct_id es por enlace, y qué rompe eso

Aquí está el límite de identidad, dicho sin rodeos. distinct_id es elido-link- más el ID del enlace, así que cada clic en spring-26 pertenece a un único "usuario" sintético de Mixpanel.

Los totales funcionan. Los desgloses por slug, país, dispositivo y destino funcionan, y también las tendencias a lo largo del tiempo. Tres cosas se rompen:

• Uniques sobre link_click cuenta enlaces, no personas. Una campaña con 40.000 clics en dos enlaces muestra dos usuarios únicos.
• Los funnels que empiezan en link_click y terminan en tu evento de registro no conectarán, porque el registro pertenece a un distinct_id distinto.

Hay una tercera cosa que la mayoría de los equipos nunca llega a tocar. Mixpanel impone límites de hot shard de 200.000 eventos por distinct_id al día, y más allá de eso los eventos se renombran a $hotshard_events. Un solo enlace que se vuelve realmente viral puede cruzar esa línea, y como el ID es por enlace, es a ese único enlace al que le pasa.

¿Por qué no un ID por visitante? Porque la redirección no sabe quién es el visitante, y prefiero que no ponga una cookie en un dominio que el visitante nunca eligió visitar. Un compromiso honesto.

Unir los clics de enlaces cortos a usuarios, la forma que funciona

El patrón que funciona usa las dos mitades para lo que cada una hace bien. Deja que el evento del lado del servidor de Elido te dé el conteo completo de clics, incluidos los de las personas que rebotan antes de que cargue tu página. Deja que el SDK de Mixpanel en tu landing page se encargue de la identidad.

Pon etiquetas UTM en la URL de destino. La librería de JavaScript de Mixpanel rastrea los parámetros UTM por defecto y registra los valores de primer contacto en el perfil, así que cuando ese visitante se registra más tarde y llamas a identify, la campaña queda pegada a una persona real. El clic en el enlace corto y la vista de la landing page comparten entonces un valor de campaña, no un ID de usuario, y los unes por utm_campaign en un informe. Es una unión a nivel de campaña, más gruesa que una a nivel de usuario, y creo que de todos modos es el nivel correcto para estos datos.

¿Quieres los totales de clics y las sesiones de landing page uno al lado del otro? Espera que no coincidan; clics de enlaces cortos frente a sesiones de GA4 explica por qué aparece la misma brecha en cualquier herramienta de analítica, Mixpanel incluido.

Si esta es la configuración que te faltaba, conecta un workspace y envía tu próxima campaña a través de enlaces con marca.

Dónde se queda corto hoy

Tres carencias, ordenadas por lo probable que es que te muerdan.

La IP del visitante viaja en cada evento. Con residencia en la UE va al host de ingesta de la UE; con el valor por defecto de EE. UU. va a un endpoint de EE. UU., y la guía de residencia de datos en la UE cubre cómo sopesar eso. Para la parte de Mixpanel en concreto, incluida la forma de comprobar la residencia de tu proyecto, consulta residencia de datos de Mixpanel en la UE.

La entrega es de mejor esfuerzo. Un POST fallido recibe un reintento tras un segundo, y luego se descarta, y los eventos no llevan $insert_id, así que un reintento tras un éxito lento puede contar doble.

No hay referrer ni navegador en el evento, y los clics que la redirección marca como sospechosos se reenvían igualmente. Consulta el dashboard de analítica de clics cuando necesites eso.

Las conversiones no forman parte de esto. Rastrea los ingresos donde vive tu ID de usuario.

Relacionado en el blog

• Seguimiento de UTM de principio a fin: la convención de etiquetado de la que depende el patrón de unión.
• Clics de enlaces cortos frente a sesiones de GA4: por qué los conteos de clics y las sesiones de analítica nunca coinciden.
• Seguimiento del lado del servidor de GA4 a través de redirecciones: la misma idea del lado del servidor, apuntada a Google.
• Atribución de clics de email para Mailchimp, Brevo y Klaviyo: reenviando clics al lado de email de la pila.
• Mixpanel frente a GA4 para analítica de enlaces: qué herramienta debería contener tus datos de clics en primer lugar.
• Residencia de datos de Mixpanel en la UE: los hosts de ingesta de la UE y la India y lo que cuesta una discrepancia.