Mixpanel Link Tracking: i clic sui link brevi come eventi

Il Mixpanel link tracking in Elido è lato server e a senso unico: ogni volta che qualcuno clicca uno dei tuoi link brevi, Elido invia un evento link_click all'endpoint track di Mixpanel con il tuo project token. L'evento porta con sé lo slug del link, l'ID del link, il paese e il dispositivo del visitatore, la destinazione a cui è stato inviato e un timestamp. Nel browser del visitatore non gira nulla, quindi ad blocker e banner sui cookie non lo toccano.

Il problema è l'identità. Ogni evento è associato al link, non alla persona, il che significa che puoi contare e segmentare i clic in Mixpanel quanto vuoi, ma non puoi seguire chi ha cliccato dentro il tuo prodotto partendo solo da quell'evento. Ti mostro a cosa serve, come configurarlo, come verificarlo nella vista Events e i casi in cui punterei su qualcos'altro.

Se stai ancora decidendo cosa taggare prima di tutto questo, la guida cornerstone su come tracciare gli UTM end to end è il punto di partenza migliore. Mixpanel vede solo ciò che il link porta con sé.

Cosa invia Elido a Mixpanel a ogni clic

Un clic, un evento. Il forwarder costruisce un batch a evento singolo e lo invia con una POST a /track sull'host di ingestione corrispondente all'impostazione Data residency dell'integrazione (api.mixpanel.com per US, api-eu.mixpanel.com per EU, api-in.mixpanel.com per India), autenticato dal token contenuto nelle proprietà, così come l'API di ingestione di Mixpanel si aspetta che arrivino gli eventi lato server.

Ecco il payload completo, privato solo del valore 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"
    }
  }
]

Tutto qui. Lista corta, e volutamente.

Due dettagli da sapere. La destination è quella risolta, quindi se uno smart link invia gli iPhone all'App Store e tutti gli altri al tuo sito, vedrai entrambi gli URL. E i tag UTM viaggiano solo dentro quella stringa di destinazione; non esistono proprietà separate utm_source o utm_campaign, quindi se le vuoi come colonne dovrai creare una proprietà derivata in Mixpanel. È l'unica cosa di configurazione che farei fin dal primo giorno.

I bot evidenti, i crawler che si dichiarano tali nel loro user agent, vengono filtrati al redirect e non arrivano mai a Mixpanel.

Configurare l'integrazione Mixpanel

L'intera configurazione è di due campi. Per inviare eventi di clic a Mixpanel ti serve un progetto Mixpanel e il suo project token, che si trova sotto Project Settings in Mixpanel; il token è una write key pensata per essere incorporata, quindi incollarla in un fornitore terzo è normale. Non incollare l'API secret, che è una stringa diversa e non è ciò che usa il forwarder.

1. Nel tuo workspace Elido, apri Integrations e scegli la card Mixpanel.
2. Clicca su Connect Mixpanel, incolla il token in Project Token e scegli Data residency: US (il valore predefinito), EU o India, corrispondente al valore di Data Residency nelle impostazioni del tuo progetto Mixpanel. Salva. Elido cifra il token a riposo e non te lo mostra mai più per intero.
3. Aspetta qualche minuto. Le impostazioni di integrazione del workspace vengono messe in cache per breve tempo lato forwarding, quindi i primi clic dopo il salvataggio potrebbero non essere ancora inviati.
4. Clicca uno dei tuoi link da un telefono.

Non c'è un interruttore per singolo link. Una volta connesso, ogni clic nel workspace viene inoltrato, il che va bene per un team che vive dentro Mixpanel ma non per un workspace che ospita link brevi per venti clienti non correlati tra loro. Se è il tuo caso, dividi prima i clienti in workspace separati.

Controllare la vista Events prima di fidarti

Quella che Mixpanel chiamava Live View ora è la vista Events, sotto Data nella navigazione a sinistra, e la guida al debugging di Mixpanel la consiglia come primo passo proprio per questo compito. Aprila, filtra per link_click, poi tocca il tuo link breve da un telefono che non è sul Wi-Fi dell'ufficio.

Dovresti vedere l'evento nel giro di secondi. Espandilo e controlla tre cose: slug corrisponde al link che hai toccato, country è dove si trova davvero il telefono, e la città e la regione di Mixpanel sono compilate a partire dall'ip. Se la città mostra un data center, il tuo test è passato attraverso una VPN.

Il pulsante Test connection nel pannello di integrazione invia un evento link_click contrassegnato elido_test: true e mostra la risposta di Mixpanel sotto il pulsante. Utile, ma non è una prova: l'endpoint track di Mixpanel accetta qualsiasi token e non controlla mai la residenza, quindi un risultato verde con il token sbagliato o la regione sbagliata continua a non significare che qualcosa arrivi nel tuo progetto. L'evento che vedi arrivare da un clic reale è l'unica prova che accetterei.

Perché distinct_id è per link, e cosa questo rompe

Ecco il limite di identità, detto chiaramente. distinct_id è elido-link- più l'ID del link, quindi ogni clic su spring-26 appartiene a un unico "utente" Mixpanel sintetico.

I totali funzionano. Funzionano i breakdown per slug, paese, dispositivo e destinazione, e funzionano anche le tendenze nel tempo. Tre cose si rompono:

• Gli Uniques su link_click contano i link, non le persone. Una campagna con 40.000 clic su due link mostra due utenti unici.
• I funnel che iniziano da link_click e finiscono sul tuo evento di signup non si collegano, perché il signup appartiene a un distinct_id diverso.

C'è una terza cosa che la maggior parte dei team non incontra mai. Mixpanel applica limiti hot shard di 200K eventi per distinct_id al giorno, e oltre quella soglia gli eventi vengono rinominati in $hotshard_events. Un singolo link che diventa davvero virale può superare quella linea, e siccome l'ID è per link, è proprio quel link a subirne le conseguenze.

Perché non un ID per visitatore? Perché il redirect non sa chi sia il visitatore, e preferisco che non imposti un cookie su un dominio che il visitatore non ha mai scelto di visitare. Un compromesso onesto.

Collegare i clic sui link brevi agli utenti nel modo che funziona

Lo schema che funziona usa le due metà per ciò in cui ciascuna è brava. Lascia che l'evento lato server di Elido ti dia il conteggio completo dei clic, inclusi quelli di persone che rimbalzano via prima che la tua pagina si carichi. Lascia che l'SDK Mixpanel sulla tua landing page gestisca l'identità.

Metti i tag UTM sull'URL di destinazione. La libreria JavaScript di Mixpanel traccia i parametri UTM per default e registra i valori first-touch sul profilo, così quando quel visitatore in seguito si registra e chiami identify, la campagna resta attaccata a una persona reale. Il clic sul link breve e la visualizzazione della landing page condividono allora un valore di campagna, non un ID utente, e li unisci su utm_campaign in un report. È un join a livello di campagna, più grezzo di uno a livello di utente, e penso sia comunque il livello giusto per questo tipo di dati.

Vuoi i totali dei clic e le sessioni della landing page fianco a fianco? Aspettati che non coincidano; clic sui link brevi rispetto alle sessioni GA4 spiega perché lo stesso divario compare in qualsiasi strumento di analytics, Mixpanel incluso.

Se questa è la configurazione che ti mancava, collega un workspace e manda la tua prossima campagna attraverso link brandizzati.

Dove oggi non basta

Tre lacune, ordinate per probabilità che ti diano fastidio.

L'IP del visitatore viaggia in ogni evento. Con la residenza EU va all'host di ingestione EU; con il default USA va a un endpoint USA, e la guida alla residenza dei dati EU spiega come valutarlo. Per quanto riguarda specificamente Mixpanel, incluso come verificare la residenza del tuo progetto, consulta la residenza dei dati Mixpanel nell'UE.

La consegna è best effort. Una POST fallita ottiene un solo tentativo di riprova dopo un secondo, poi viene scartata, e gli eventi non portano alcun $insert_id, quindi una riprova dopo un successo lento può causare un doppio conteggio.

Non c'è referrer né browser nell'evento, e i clic che il redirect segnala come sospetti vengono comunque inoltrati. Controlla la dashboard di click analytics quando ti servono quei dati.

Le conversioni non ne fanno parte. Traccia i ricavi dove vive il tuo user ID.

Correlati sul blog

• Tracciare gli UTM end to end - la convenzione di tagging da cui dipende lo schema di collegamento.
• Clic sui link brevi rispetto alle sessioni GA4 - perché il conteggio dei clic e le sessioni analytics non coincidono mai.
• Tracking server-side GA4 via redirect - la stessa idea lato server, rivolta a Google.
• Attribuzione dei clic email per Mailchimp, Brevo e Klaviyo - inoltrare i clic al lato email dello stack.
• Mixpanel vs GA4 per l'analytics dei link - quale strumento dovrebbe custodire i tuoi dati di clic fin dall'inizio.
• Residenza dei dati Mixpanel nell'UE - gli host di ingestione UE e India e il costo di una mancata corrispondenza.