Suivi de liens Mixpanel : les clics sur liens courts comme événements

Le suivi de liens Mixpanel dans Elido est côté serveur et unidirectionnel : chaque fois que quelqu'un clique sur l'un de vos liens courts, Elido publie un événement link_click vers le point d'entrée de suivi de Mixpanel avec votre jeton de projet. L'événement porte le slug du lien, l'ID du lien, le pays et l'appareil du visiteur, la destination vers laquelle il a été envoyé, et un horodatage. Rien ne s'exécute dans le navigateur du visiteur, donc les bloqueurs de publicité et les bannières de consentement n'y touchent pas.

Le hic, c'est l'identité. Chaque événement est indexé sur le lien, pas la personne, ce qui signifie que vous pouvez compter et segmenter les clics dans Mixpanel toute la journée mais vous ne pouvez pas suivre un cliqueur dans votre produit depuis cet événement seul. Je vais vous montrer à quoi c'est bon, comment le configurer, comment le vérifier dans la vue Événements, et les endroits où je me tournerais vers autre chose.

Si vous décidez encore quoi taguer avant tout ceci, le guide pilier sur le suivi UTM de bout en bout est le meilleur point de départ. Mixpanel ne voit jamais que ce que le lien porte.

Ce qu'Elido envoie à Mixpanel à chaque clic

Un clic, un événement. Le transmetteur construit un lot à événement unique et le publie vers /track sur l'hôte d'ingestion correspondant au paramètre Data residency de l'intégration (api.mixpanel.com pour les États-Unis, api-eu.mixpanel.com pour l'UE, api-in.mixpanel.com pour l'Inde), authentifié par le jeton à l'intérieur des propriétés, ce qui est la manière dont l'API d'ingestion de Mixpanel attend que les événements côté serveur arrivent.

Voici la charge utile complète, tronquée uniquement de la valeur du jeton :

[
  {
    "event": "link_click",
    "properties": {
      "token": "<votre jeton de projet>",
      "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"
    }
  }
]

C'est tout. Liste courte, et délibérément.

Deux détails qui valent la peine d'être connus. La destination est celle résolue, donc si un lien intelligent envoie les iPhone vers l'App Store et tout le monde ailleurs vers votre site, vous verrez les deux URL. Et les tags UTM ne voyagent qu'à l'intérieur de cette chaîne de destination ; il n'y a pas de propriétés utm_source ou utm_campaign séparées, donc si vous les voulez comme colonnes, vous aurez besoin d'une propriété dérivée dans Mixpanel. C'est le seul bout de configuration que je ferais le premier jour.

Les robots évidents, les crawlers qui s'annoncent dans leur agent utilisateur, sont filtrés à la redirection et n'atteignent jamais Mixpanel.

Configurer l'intégration Mixpanel

Toute la configuration tient en deux champs. Pour envoyer des événements de clic à Mixpanel, vous avez besoin d'un projet Mixpanel et de son jeton de projet, qui vit sous Paramètres du projet dans Mixpanel ; le jeton est une clé d'écriture destinée à être intégrée, donc le coller dans un fournisseur est normal. Ne collez pas le secret API, qui est une chaîne différente et n'est pas ce que le transmetteur utilise.

1. Dans votre espace de travail Elido, ouvrez Intégrations et choisissez la carte Mixpanel.
2. Cliquez sur Connecter Mixpanel, collez le jeton dans Project Token, et choisissez Data residency : US (par défaut), EU ou India, en fonction de la valeur Data Residency dans les paramètres de votre projet Mixpanel. Enregistrez. Elido chiffre le jeton au repos et ne vous le remontre jamais en entier.
3. Attendez quelques minutes. Les paramètres d'intégration de l'espace de travail sont mis en cache brièvement côté transmission, donc les premiers clics après l'enregistrement peuvent ne pas encore être envoyés.
4. Cliquez sur l'un de vos propres liens depuis un téléphone.

Il n'y a pas de commutateur par lien. Une fois connecté, chaque clic dans l'espace de travail est transmis, ce qui convient à une équipe qui vit dans Mixpanel et ne convient pas à un espace de travail qui héberge des liens courts pour vingt clients sans rapport. Si c'est votre cas, séparez d'abord les clients en espaces de travail distincts.

Vérifier la vue Événements avant de faire confiance à quoi que ce soit

Ce que Mixpanel appelait autrefois Live View s'appelle maintenant la vue Événements, sous Données dans la navigation de gauche, et le guide de débogage de Mixpanel la recommande comme premier arrêt pour exactement ce travail. Ouvrez-la, filtrez sur link_click, puis tapez sur votre lien court depuis un téléphone qui n'est pas sur le Wi-Fi du bureau.

Vous devriez voir l'événement en quelques secondes. Développez-le et vérifiez trois choses : slug correspond au lien que vous avez tapé, country correspond à l'endroit où se trouve réellement le téléphone, et la ville et la région propres de Mixpanel sont remplies depuis l'ip. Si la ville montre un centre de données, votre test est passé par un VPN.

Le bouton Test connection dans le panneau d'intégration envoie un link_click marqué elido_test: true et affiche la réponse de Mixpanel sous le bouton. Utile, mais ce n'est pas une preuve : le point d'entrée de suivi de Mixpanel accepte n'importe quel jeton et ne vérifie jamais la résidence, donc un résultat vert avec le mauvais jeton ou la mauvaise région ne veut toujours rien dire pour votre projet. L'événement que vous voyez arriver d'un vrai clic est la seule preuve que j'accepterais.

Pourquoi distinct_id est par lien, et ce que cela casse

Voici la limite d'identité, énoncée clairement. distinct_id est elido-link- plus l'ID du lien, donc chaque clic sur spring-26 appartient à un « utilisateur » Mixpanel synthétique unique.

Les totaux fonctionnent. Les ventilations par slug, pays, appareil et destination fonctionnent, tout comme les tendances dans le temps. Trois choses cassent :

• Les Uniques sur link_click comptent des liens, pas des personnes. Une campagne avec 40 000 clics sur deux liens montre deux utilisateurs uniques.
• Les entonnoirs qui commencent à link_click et finissent à votre événement d'inscription ne se connecteront pas, parce que l'inscription appartient à un distinct_id différent.

Il y en a un troisième que la plupart des équipes ne rencontrent jamais. Mixpanel impose des limites de shard chaud de 200 000 événements par distinct_id par jour, et au-delà, les événements sont renommés en $hotshard_events. Un seul lien qui devient vraiment viral peut franchir cette ligne, et parce que l'ID est par lien, c'est ce lien-là qui est touché.

Pourquoi pas un ID par visiteur ? Parce que la redirection ne sait pas qui est le visiteur, et je préfère qu'elle ne définisse pas de cookie sur un domaine que le visiteur n'a jamais choisi de visiter. Un compromis honnête.

Recoller les clics de liens courts aux utilisateurs, la manière qui fonctionne

Le schéma qui fonctionne utilise les deux moitiés pour ce à quoi chacune excelle. Laissez l'événement côté serveur d'Elido vous donner le compte de clics complet, y compris les clics de personnes qui rebondissent avant que votre page ne charge. Laissez le SDK Mixpanel sur votre page de destination gérer l'identité.

Mettez des tags UTM sur l'URL de destination. La bibliothèque JavaScript de Mixpanel suit les paramètres UTM par défaut et enregistre les valeurs de premier contact sur le profil, donc quand ce visiteur s'inscrit plus tard et que vous appelez identify, la campagne colle à une vraie personne. Le clic sur lien court et la vue de page de destination partagent alors une valeur de campagne, pas un ID utilisateur, et vous les joignez sur utm_campaign dans un rapport. C'est une jointure au niveau de la campagne, plus grossière qu'une jointure au niveau de l'utilisateur, et je pense que c'est le bon niveau pour ces données de toute façon.

Vous voulez les totaux de clics et les sessions de page de destination côte à côte ? Attendez-vous à ce qu'ils divergent ; clics de liens courts contre sessions GA4 explique pourquoi le même écart apparaît dans n'importe quel outil d'analyse, Mixpanel inclus.

Si c'est la configuration qui vous manquait, connectez un espace de travail et faites passer votre prochaine campagne par des liens de marque.

Où cela pèche aujourd'hui

Trois lacunes, classées par probabilité de vous mordre.

L'IP du visiteur voyage dans chaque événement. Avec la résidence UE, elle va vers l'hôte d'ingestion UE ; avec le défaut US, elle va vers un point d'entrée US, et le guide de résidence des données UE couvre comment peser cela. Pour Mixpanel en particulier, notamment pour vérifier la résidence de votre projet, consultez Résidence des données UE de Mixpanel.

La livraison est au mieux. Un POST échoué obtient une nouvelle tentative après une seconde, puis est abandonné, et les événements ne portent pas de $insert_id, donc une nouvelle tentative après un succès lent peut compter en double.

Il n'y a ni referrer ni navigateur dans l'événement, et les clics que la redirection signale comme suspects sont quand même transmis. Vérifiez le tableau de bord d'analyse des clics quand vous en avez besoin.

Les conversions n'en font pas partie. Suivez le revenu là où vit votre ID utilisateur.

À lire aussi sur le blog

• Suivre les UTM de bout en bout - la convention de tagage dont dépend le schéma de recollage.
• Clics de liens courts contre sessions GA4 - pourquoi les comptes de clics et les sessions d'analyse ne correspondent jamais.
• Suivi côté serveur GA4 via les redirections - la même idée côté serveur, pointée vers Google.
• Attribution des clics e-mail pour Mailchimp, Brevo et Klaviyo - transmettre les clics vers le côté e-mail de la pile.
• Mixpanel contre GA4 pour l'analyse de liens - quel outil devrait héberger vos données de clic en premier lieu.
• Résidence des données UE de Mixpanel - les hôtes d'ingestion UE et Inde et le coût d'une discordance.