Suivi entre sous-domaines

Votre site marketing vit sur example.com, votre app sur app.example.com. Le localStorage est par origin : si l’identité ne vivait que là, le visiteur qui a lu votre page de tarifs et le visiteur qui s’inscrit dans votre app recevraient deux identifiants anonymes différents, et l’historique d’avant l’inscription — avec la campagne qui l’a amené — mourrait à la frontière avant qu’identify() ait la moindre chance de le relier.

Ça marche déjà tout seul

La persistance par défaut est 'localStorage+cookie' avec cookieDomain: 'auto', donc le snippet nu traverse les sous-domaines sans aucune configuration :

kilden.init('YOUR_WRITE_KEY');

Le paquet d’identité vit dans un cookie first-party dont la portée est le domaine enregistrable — le seul stockage que tous les sous-domaines peuvent lire —, en miroir dans le localStorage. Installez le snippet sur les deux sites avec la même write key et le visiteur garde le même identifiant anonyme en traversant ; identify() à l’inscription relie tout l’historique de navigation d’avant au nouvel utilisateur.

Ce qui vit dans le cookie

L’identité seulement : l’identifiant anonyme, le distinct id, la session, l’état d’opt-out et l’enregistrement du first touch (ci-dessous). Les super properties, caches et files d’attente restent dans le localStorage — les cookies voyagent dans le header de chaque requête vers votre domaine, donc seul ce qui doit survivre à la traversée y entre.

Le figer explicitement, ou le désactiver

cookieDomain: 'auto' teste des domaines candidats du plus large au plus étroit et garde le premier que le navigateur accepte. Les suffixes publics (io, co.uk) rebondissent sur le cookie jar, donc auto atterrit sur le domaine enregistrable (eTLD+1) : sur app.example.co.uk, le cookie a pour portée .example.co.uk. Les hôtes sans domaine (localhost, IPs) reçoivent un cookie host-only.

Si vous préférez ne pas dépendre de la détection en production, figez la portée — c’est une supposition de moins :

kilden.init('YOUR_WRITE_KEY', {
  cookieDomain: '.example.com',
});

Si le navigateur rejette la portée demandée (un domaine qui ne correspond pas à l’hôte, un suffixe public), le SDK ne fonctionne pas à moitié avec un cookie qui ne colle jamais — il retombe sur le comportement localStorage seul.

Et pour désactiver complètement les cookies :

kilden.init('YOUR_WRITE_KEY', {
  persistence: 'localStorage',
});

Cela garde tout dans le localStorage par origin — aucun cookie n’est jamais écrit, et l’identité ne traverse plus les sous-domaines.

Cookies et consentement

Le défaut écrit un cookie first-party. Si votre dispositif doit rester sans cookies, désactivez-les avec persistence: 'localStorage' — mais ne supposez pas que cela règle à soi seul la question de conformité : des réglementations comme les règles ePrivacy de l’UE sont généralement technologiquement neutres, et stocker des informations sur l’appareil du visiteur peut exiger un consentement quel que soit le mécanisme ; vérifiez donc vos propres consignes de confidentialité pour ce qui s’applique à vous. Ce qui change bel et bien avec les cookies, c’est que les scanners de consentement les détectent — attendez-vous à ce que le cookie de Kilden apparaisse dans les audits automatisés, et vérifiez que votre bannière de consentement le déclare.

Migration : les visiteurs existants gardent leur historique

Le défaut est sûr pour les sites avec du trafic existant :

• L’adoption avant la fraîcheur. Une identité préexistante dans le localStorage est adoptée dans le cookie, pas remplacée — les visiteurs existants gardent leur identifiant et leur historique au lieu de bifurquer en inconnu.
• Le cookie gagne la divergence. Quand deux sous-domaines avaient des identifiants préexistants différents, la première page à charger écrit le cookie partagé et l’autre se range — déterministe, sans bagarre. Les événements déjà envoyés sous l’autre identifiant lui restent attribués ; si ce visiteur s’identifie, la résolution d’identité réunit les pistes.

Attribution first-touch

Activée par défaut, sans configuration. Le SDK fige comme traits de la personne deux faits aux durées de vie différentes :

• Comment ils sont arrivés la première fois — écrit dès la toute première visite, même directe : $initial_referrer ($direct quand il n’y en a pas), $initial_referring_domain, $initial_landing_page.
• Quelle campagne les a atteints en premier — $initial_utm_source, $initial_utm_medium, $initial_utm_campaign, $initial_utm_term, $initial_utm_content, écrits la première fois qu’un paramètre utm_* apparaît un jour, ce qui peut être des visites plus tard.

Une première visite directe ne verrouille pas les champs de campagne à rien — une différence délibérée avec PostHog, qui fige les deux à la visite un. On répond ainsi aux deux questions au lieu d’une.

Tout part en $set_once, que le pipeline applique par clé : le tardif n’écrase jamais le précoce, et renvoyer est inoffensif. Les properties de contexte $utm_* par événement ne changent pas — chaque événement porte toujours la campagne de sa propre visite (voir Événements et propriétés).

L’enregistrement du first touch fait partie du paquet d’identité, donc avec la persistance par défaut le site marketing et l’app s’accordent sur ce qui a déjà été enregistré — la campagne capturée sur example.com n’est pas refigée différemment sur app.example.com.

Référence

Les deux options sont documentées dans la référence de configuration du SDK.