Traitement des données personnelles

Le tag Contentsquare masque les données personnelles avant qu'elles ne quittent le navigateur et propose des commandes configurables, des attributs HTML et des modes de collecte chiffrée pour contrôler ce qui est envoyé et stocké.

Le traitement des données personnelles par le tag Contentsquare repose sur trois niveaux :

1. Masquage automatique des données personnelles — le tag détecte les motifs courants (e-mails, JWT, tokens OAuth, numéros de carte bancaire) et les remplace avant que toute donnée ne quitte le navigateur. Voir Masquage automatique des données personnelles.
2. Fonctionnalités de masquage que vous configurez — commandes et attributs HTML pour masquer ou supprimer des données personnelles dans les URLs, les URLs d'erreurs d'API, le contenu du DOM et le texte des éléments cliqués. Voir Fonctionnalités de masquage.
3. Controlled Exposure — collectez et chiffrez certaines valeurs côté client pour que Contentsquare ne puisse pas les voir, et ne les déchiffrez qu'avec votre clé privée lors de la consultation des replays. Voir Controlled Exposure.

Certaines données sont envoyées telles quelles et ne sont pas masquées automatiquement — notamment les chaînes d'identité (identify), les propriétés utilisateur, les noms d'événements, les propriétés d'événements et de pageviews, les attributs d'erreurs personnalisées et le titre de la page. Vous devez vous assurer qu'elles ne contiennent pas de données personnelles. Voir Données envoyées telles quelles.

Le tag détecte et remplace automatiquement certains types de données personnelles avant que toute information ne quitte le navigateur. Cette opération s'effectue sans aucune configuration.

Les types de données personnelles détectés dépendent du canal de données.

Les chiffres peuvent être écrits en un seul bloc ou groupés par quatre avec des espaces ou des tirets, à condition d'utiliser le même séparateur partout (4111 1111 1111 1111, 4111-1111-1111-1111). Les numéros déjà partiellement masqués, comme 4***-****-****-1234, sont également remplacés par CS_ANONYMIZED_PII.

Dans le Session Replay, lorsqu'un texte ou une valeur d'attribut contient une séquence de 9 chiffres ou plus, tous les chiffres de ce texte ou de cette valeur sont masqués, même avec No masking. Ils s'affichent sous la forme •, ou a sur les pages où le texte est masqué. Les paramètres de Data masking les désignent comme des nombres sensibles. Cela couvre les numéros de téléphone, de sécurité sociale et les identifiants similaires.

• Lorsque les nombres sont masqués sur une page (avec Full masking, Partial masking ou une page rule), chaque chiffre est masqué, quelle que soit la longueur de la séquence.
• Le texte des éléments marqués avec data-cs-capture n'est pas soumis à cette règle. Les adresses e-mail et les numéros de carte bancaire y restent masqués.

Toutes les détections ne s'appliquent pas partout. Le tableau suivant indique précisément quels types de données personnelles sont masqués dans chaque canal de données.

Noms de fichier d'erreur JavaScript : le masquage indiqué ci-dessus, ainsi que vos surcharges setPath et setQuery, ne s'appliquent que lorsque le nom de fichier est l'URL de la page courante, ce qui est le cas des erreurs levées par des scripts inline. Les URLs des autres fichiers de script sont collectées telles quelles.

Messages d'erreur personnalisée : par défaut, seules les adresses e-mail sont masquées dans les messages d'erreur personnalisée, y compris dans les URLs qu'ils contiennent. Le masquage des tokens JWT et OAuth dans ces URLs n'est appliqué que s'il est activé pour votre projet.

URLs de requêtes réseau dans le Session Replay : la chaîne de requête est supprimée, et les patterns enregistrés avec networkRequest:maskUrls sont appliqués.

De plus, les protections suivantes propres à chaque type de données sont toujours appliquées :

• Erreurs JavaScript : les valeurs de champs de formulaire (motifs comme value="...") sont supprimées des messages d'erreur.
• Erreurs personnalisées : voir Messages d'erreur personnalisée.
• Erreurs d'API : la chaîne de requête est entièrement retirée de l'URL collectée, en plus du masquage indiqué ci-dessus. Un #fragment est conservé lorsque l'URL n'a pas de chaîne de requête. Voir Supprimer des données personnelles dans les erreurs d'API pour le détail des données collectées avec les erreurs d'API.
• Texte des éléments cliqués : le texte entier est supprimé lorsqu'il contient une adresse e-mail, un numéro de carte bancaire ou une séquence de 9 chiffres ou plus. Voir Supprimer des données personnelles dans les éléments cliqués.
• Événements externes (tags d'événements Voice of Customer) : voir Événements externes.

Le message transmis à trackError est tronqué à 300 caractères, puis les motifs suivants sont remplacés :

• Les adresses e-mail sont remplacées par CS_ANONYMIZED_EMAIL.
• Les numéros de téléphone sont remplacés par CS_ANONYMIZED_PHONE.
• Les noms sont remplacés par CS_ANONYMIZED_NAME lorsqu'ils sont entre guillemets après une clé de nom. Les clés de nom commencent par first, last, user, profile ou primary, suivi de name. Par exemple, firstName="John", lastName: 'Doe', userName:"jsnow" et {key:"firstName", value:"John"} sont masqués.

Les valeurs sans guillemets, comme firstName=John, ne sont pas masquées.

Les tags d'événements envoyés à Voice of Customer sont entièrement supprimés, et non collectés, lorsqu'ils :

• Contiennent une adresse e-mail, une adresse IP ou une séquence de 9 chiffres ou plus.
• Contiennent des caractères autres que les lettres a-z et A-Z, les chiffres, les espaces et _, -, ., :, /.
• Sont vides ou font plus de 250 caractères.

Les données suivantes sont transmises sans aucun masquage automatique des données personnelles. Si ces canaux peuvent contenir des données personnelles, vous êtes responsable de les supprimer avant de les envoyer à Contentsquare.

Les noms des Custom et Dynamic Variables sont tronqués à 512 caractères, et leurs valeurs à 255 caractères.

En plus du masquage automatique des données personnelles, Contentsquare propose plusieurs commandes et attributs HTML pour masquer ou supprimer des données personnelles dans des canaux précis. Cette section liste toutes les fonctionnalités disponibles et explique comment et où les utiliser.

Les commandes et attributs suivants permettent de contrôler la collecte des données personnelles. Chacun est détaillé dans la section correspondante ci-dessous ou dans la référence des commandes.

Le tag expose plusieurs commandes pour associer une identité ou des attributs à un utilisateur. Aucune de ces valeurs n'est masquée automatiquement — ce que vous transmettez est ce qui est envoyé et stocké.

• identify : associe une chaîne d'identité à l'utilisateur courant. La valeur est envoyée telle quelle, sauf si vous utilisez l'option { hash: true }, qui la hache côté client. Privilégiez des valeurs non directement identifiantes (UUID, numéros de compte) plutôt que des e-mails ou des numéros de téléphone. Voir Track Users → Bonnes pratiques pour les compromis du hachage côté client.
• resetIdentity : efface l'identité associée à l'utilisateur courant. Utilisez-la à la déconnexion pour qu'un utilisateur suivant sur le même appareil n'hérite pas de l'identité précédente.
• addUserProperties, customProperties:visit:add, customProperties:page:add : associent des propriétés personnalisées à l'utilisateur, à la visite ou à la pageview. Les clés et les valeurs sont envoyées sans aucun masquage de données personnelles — n'y transmettez pas de données personnelles. Seules des limites de longueur s'appliquent :
  • addUserProperties tronque les clés et les valeurs à 255 caractères.
  • customProperties:visit:add et customProperties:page:add suppriment les clés de plus de 512 caractères et tronquent les valeurs chaînes à 1 024 caractères.
• trackEvent tronque le nom de l'événement à 1 024 caractères, et trackPageEvent l'envoie tel quel. Ni l'une ni l'autre n'applique de masquage des données personnelles.

Pour l'API complète, voir Track Users.

Une session sera enregistrée pour le Session Replay si :

• La fonctionnalité Session Replay est activée pour votre compte.
• Le seuil défini par le paramètre Session Replay Collection Rate n'est pas dépassé.

Pour que le contenu HTML soit envoyé, toutes les conditions suivantes doivent être vérifiées :

• L'utilisateur n'a pas opt-out.
• La session est trackée.
• Le navigateur est compatible.
• La session est marquée comme "Enregistrée par le Session Replay", via le cookie _cs_s

Lorsque le Session Replay est activé et que la session utilisateur est enregistrée, le contenu HTML de la page est envoyé après chaque pageview (naturelle ou artificielle) et chaque mise à jour du DOM (seuls les éléments mis à jour sont envoyés).

La page Data masking des paramètres de votre projet contrôle la quantité de contenu collectée sur la page. Les Admins définissent une approche par défaut pour toutes les pages :

• Full masking : masque tout le texte, tous les nombres et tous les médias.
• Partial masking : masque tout le texte et tous les nombres, affiche tous les médias.
• No masking : affiche tout le texte, les nombres non sensibles et tous les médias.

Les page rules remplacent l'approche par défaut sur des pages précises, et les element rules masquent ou démasquent des éléments précis.

Les protections suivantes s'appliquent quelle que soit l'approche par défaut : Contentsquare ne collecte jamais le texte réellement saisi dans les champs <input> ou <textarea>.

• La valeur saisie dans chaque élément <input> est remplacée par des points avant l'envoi du HTML, quel que soit son type. Pour les éléments <input> de type number, tous les caractères autres que les espaces sont remplacés par 0.
• La valeur des éléments <select> est remplacée de la même manière. L'état coché des cases à cocher et des boutons radio, ainsi que l'option sélectionnée dans un <select>, restent visibles dans le replay.
• L'attribut value est supprimé de tous les éléments <input>, sauf pour les types button et submit, où il contient le libellé affiché sur le bouton.
• Le contenu des éléments <textarea> est remplacé par des points avant l'envoi du HTML.
• Le contenu de tout élément possédant un attribut contenteditable est remplacé par des points avant l'envoi du HTML, quelle que soit la valeur de l'attribut (y compris contenteditable="false").
• Le contenu des éléments <script> est vidé. L'élément et ses attributs sont conservés.
• Les commentaires HTML ne sont jamais collectés.
• Les adresses e-mail, les numéros de carte bancaire et les longues séquences de chiffres sont masqués dans le texte et dans les valeurs d'attributs, sauf dans les attributs conservés tels quels listés dans Avec Full masking ou Partial masking. Dans le href des éléments <a> et le src des éléments <iframe>, seules les adresses e-mail sont masquées.
• Le contenu de tous les éléments marqués avec le data attribute data-cs-mask, ou correspondant à l'un des sélecteurs masqués par défaut, est supprimé (voir la section Tagger les éléments du DOM).
• À part les exceptions ci-dessus, tout le contenu HTML est envoyé, l'élément <head> compris.

Toutes les protections listées dans Avec No masking s'appliquent également. Sur les pages où le texte est masqué, les règles suivantes s'appliquent en plus :

• Chaque caractère du texte inclus dans les éléments envoyés est remplacé par un « a » minuscule. Les caractères des écritures chinoise et japonaise sont remplacés par le « ａ » pleine largeur. Les autres caractères, y compris le coréen, sont remplacés par « a ». Les espaces sont conservés, de sorte que le replay garde la forme du texte.
• Full masking et Partial masking masquent aussi les nombres : les chiffres s'affichent sous la forme « a ». Lorsqu'une page rule démasque les nombres mais pas le texte, les chiffres sont conservés, sauf si le texte contient une séquence de 9 chiffres ou plus.
• Avec Full masking, les images, vidéos et fichiers audio sont remplacés par des blocs gris.
• Le libellé des éléments <input> de type button ou submit (leur value) est remplacé par « a », comme les autres textes.
• Le contenu de tous les éléments marqués avec le data attribute data-cs-capture est collecté et affiché, sauf s'il s'agit des éléments exclus listés plus haut (<input>, <textarea>).
• Les attributs suivants sont conservés tels quels :
  • id, class, style, srcset, sizes, rel, type, width, height, media, align, dir, bgcolor, color, border, colspan, rowspan, cols, rows, size, start et slot
  • href et src. Les adresses e-mail sont masquées dans le href des éléments <a> et le src des éléments <iframe>. Sur les autres éléments, comme <img>, elles sont collectées telles quelles
  • name sur les boutons radio
  • Tous les attributs des éléments SVG
  • Les attributs figurant dans la liste d'autorisation de votre projet
• Tous les autres attributs, comme alt, title, placeholder, aria-* ou data-*, sont conservés mais leur valeur est vidée.

Les page rules remplacent votre approche par défaut sur des pages précises, afin de ne pas avoir à appliquer le même masquage sur l'ensemble du site. Les Admins les définissent dans la section Page rules de la page Data masking :

• Avec Full masking ou Partial masking comme approche par défaut, les page rules démasquent le contenu des pages correspondantes.
• Avec No masking comme approche par défaut, les page rules masquent le contenu des pages correspondantes.

Pour les pages correspondantes, cochez ce qu'il faut masquer ou démasquer : Text, Numbers et Media. Les nombres masqués sont cachés quelle que soit leur longueur, et les médias masqués (images, vidéos et fichiers audio) sont remplacés par des blocs gris.

Chaque règle cible les pages d'après leur URL : URL starts with, URL ends with, URL contains, URL matches exactly, leurs formes négatives, ou Regex. Sous More options, vous pouvez ignorer la chaîne de requête, les fragments d'URI ou la casse. Utilisez Check URL pour vérifier quelles URLs vos règles couvrent.

Sur les projets configurés pour cela, le consentement d'un visiteur peut lever le masquage du texte dans les replays de ce visiteur. Transmettez la décision du visiteur avec les commandes replay:consent:unanonymized:granted et replay:consent:unanonymized:withdrawn. Ces commandes ne fonctionnent que lorsque l'approche par défaut est Full masking ou Partial masking et que le projet est configuré pour le consentement du visiteur sur les replays masqués. Avec No masking, elles n'ont aucun effet, même sur les pages masquées par des page rules.

Une fois le consentement accordé, le masquage du texte est levé pour ce visiteur sur toutes les pages. Les nombres et les médias restent masqués.

Ce consentement est différent de celui que certains projets exigent avant le début de la collecte du Session Replay, décrit dans Suivre les requêtes Session Replay.

Utilisez la commande excludeURLforReplay pour bloquer l'enregistrement de certaines pages d'après leur URL. Cette commande est utile dans plusieurs cas :

• Des données personnelles ont été exposées.
• Vous souhaitez bloquer l'enregistrement de parties complètes de votre site.
• Certains enregistrements pour le Session Replay causent des problèmes de performance (lorsque la page contient un nombre important d'images ou de vidéos, par exemple) — vous pouvez bloquer leur enregistrement jusqu'à la résolution du problème.

window._uxa = window._uxa || [];
window._uxa.push(["excludeURLforReplay", "URL_REGEX"]);

Une fois transmise, l'expression régulière reste active jusqu'au rechargement de la page. Le tag la teste à chaque pageview naturelle et artificielle, de sorte qu'un seul appel couvre toutes les routes d'une application monopage. Transmettez à nouveau la commande à chaque chargement complet de page, avant le chargement du tag.

• L'expression régulière est testée sur l'URL collectée, c'est-à-dire l'URL après vos surcharges setPath et setQuery et après le masquage automatique des données personnelles.
• Le pattern n'a pas besoin de correspondre à l'URL entière. Par exemple, www\.example\.com/checkout correspond sans le protocole. Si vous ancrez le pattern avec ^, incluez le protocole, par exemple ^https://www\.example\.com/checkout. La correspondance est sensible à la casse.
• Chaque appel remplace l'expression régulière de l'appel précédent. Pour exclure plusieurs sections, combinez-les dans une seule expression, par exemple (checkout|account).
• Transmettre la commande après le début de la collecte du Session Replay n'arrête pas la collecte de la pageview courante. Elle s'applique à partir de la pageview suivante.

Cette commande ne bloque pas les pageviews pour les pages concernées — elle bloque uniquement l'enregistrement pour le Session Replay.

Deux méthodes sont à votre disposition dans votre code :

1. Utiliser le Contentsquare Personal Data Selector
2. Tagger les éléments du DOM

Les Admins peuvent aussi créer des element rules sans code, dans la section Element rules de la page Data masking. Une règle Mask masque les éléments correspondant à des sélecteurs CSS et peut masquer des attributs précis (Mask attributes). Une règle s'applique à All pages ou à Some pages, ciblées d'après leur URL. Sense peut analyser vos pages à la recherche de données personnelles et suggérer des element rules.

Chaque élément du DOM à masquer est identifié par un sélecteur CSS. Ces sélecteurs sont envoyés à l'API Contentsquare sous la forme d'un objet JavaScript. Le contenu de ces éléments sera supprimé de l'enregistrement.

L'objet contenant les sélecteurs CSS pour le texte et les attributs doit être envoyé à l'API Contentsquare comme dans l'exemple ci-dessous, avant le chargement du Tag principal :

window._uxa = window._uxa || [];
window._uxa.push(['setPIISelectors', PIIObject]);

La structure du PIIObject est la suivante :

• PIISelectors : Liste des sélecteurs CSS séparés par des virgules, qui permet aux éléments correspondants du DOM d'être masqués par le tag.

• Attributes : Cette clé permet de supprimer les attributs définis sur les éléments du DOM qui correspondent aux sélecteurs CSS. attrName accepte un nom d'attribut unique ou un tableau de noms d'attributs, comme dans l'exemple ci-dessous.

L'utilisation des deux clés PII Selectors et Attributes n'est pas obligatoire : vous pouvez utiliser des sélecteurs d'éléments complets, des sélecteurs d'attributs spécifiques, ou les deux, au sein du même objet :

{
  PIISelectors: [".css-selector, selector"], // Éléments du DOM à masquer
  Attributes: [
      {
          selector: "select#month option, select#year option", // Sélecteurs CSS
          attrName: 'id' // Nom de l'attribut à masquer
      },
      {
          selector: ".link-page-7", // Sélecteurs CSS
          attrName: ['href','name'] // Noms des attributs à masquer en tableau
      }
  ]
};

Chaque appel à setPIISelectors ajoute ses sélecteurs à ceux déjà enregistrés. Les sélecteurs CSS invalides sont ignorés sans message d'erreur : vérifiez vos sélecteurs dans la console du navigateur avec document.querySelectorAll() avant de les déployer. Voir Quand les règles de masquage prennent effet pour le moment d'application.

Pour exclure du contenu HTML de la page à enregistrer, ajoutez l'attribut data-cs-mask sur les éléments concernés :

Content before
<p data-cs-mask>emailaddress@sentitivedata.com</p>
Content after

Leur contenu est supprimé dans le navigateur avant d'être envoyé vers Contentsquare :

Content before
<p data-cs-mask>emailaddress@sentitivedata.com</p>
Content after

Pour un élément masqué :

• Son contenu textuel et tous ses éléments enfants sont supprimés.
• L'élément lui-même est conservé avec sa taille : le replay affiche un espace réservé vide à sa place et la mise en page est préservée.
• Ses attributs value, checked, src, data et alt sont supprimés.

Vous pouvez également ajouter l'attribut data-cs-mask avec du JavaScript. Voir Quand les règles de masquage prennent effet.

Événements sur des éléments HTML supprimés — Dans le Session Replay, les clics, survols, événements clavier et de défilement qui ciblent des éléments à l'intérieur d'un élément masqué ne sont pas collectés. Les événements d'analyse utilisés pour les heatmaps et le Zoning Analysis, comme les clics, sont toujours collectés pour ces éléments.

Les éléments correspondant aux sélecteurs suivants sont toujours masqués, de la même manière que les éléments marqués avec data-cs-mask. Cela préserve le masquage déjà configuré pour d'autres outils :

• [data-hj-suppress] et .data-hj-suppress
• [data-hj-masked]
• [data-heap-redact-text]
• [data-heap-redact-attributes]
• [data-heap-ignore] et [heap-ignore]
• .ctHidden

Deux méthodes sont à votre disposition dans votre code :

1. Utiliser le Contentsquare Personal Data Selector
2. Tagger les éléments du DOM

Les Admins peuvent aussi créer une element rule Unmask sur la page Data masking, pour afficher les éléments correspondant à des sélecteurs CSS sur les pages masquées.

Chaque élément du DOM à afficher est identifié par un sélecteur CSS. Ces sélecteurs sont envoyés à l'API Contentsquare sous la forme d'un objet JavaScript. Le contenu de ces éléments sera affiché dans le Session Replay.

La chaîne de caractères contenant les sélecteurs CSS séparés par des virgules, pour le texte et les attributs, doit être envoyée à l'API Contentsquare, avant le chargement du Tag principal, comme dans l'exemple ci-dessous :

window._uxa = window._uxa || [];
window._uxa.push(["setCapturedElementsSelector", "#capture-me, .show-me"]);

Chaque appel à setCapturedElementsSelector remplace les sélecteurs de l'appel précédent. Pour exposer plusieurs éléments, transmettez tous leurs sélecteurs dans une seule chaîne séparée par des virgules.

Pour afficher un élément HTML dans une page masquée, ajoutez l'attribut data-cs-capture sur les éléments HTML :

Sensitive Content before
<p data-cs-capture>some piece of text that is not sensitive</p>
Sensitive Content after

Le contenu de cet élément est capturé tel quel :

aaaaaaaaa aaaaaaa aaaaaa
<p data-cs-capture>some piece of text that is not sensitive</p>
aaaaaaaaa aaaaaaa aaaaa

data-cs-capture et setCapturedElementsSelector s'appliquent à l'élément correspondant et à tous ses descendants. Seul le texte est exposé : les valeurs des attributs que le masquage vide restent vides.

L'attribut data-cs-capture peut aussi être ajouté avec du JavaScript. Voir Quand les règles de masquage prennent effet.

Le tag lit les attributs et sélecteurs de masquage au début d'une pageview. Cela concerne les attributs data-cs-mask, data-cs-capture et data-cs-encrypt, ainsi que les commandes setPIISelectors, setCapturedElementsSelector et setEncryptionSelectors :

• Ajoutez les attributs, ou transmettez les commandes, avant l'envoi de la pageview.
• Les éléments insérés plus tard dans la page sont pris en compte au moment de leur ajout.
• Ajouter un attribut à un élément déjà présent après l'envoi de la pageview ne prend effet qu'à la prochaine pageview naturelle ou artificielle.

• Avoir installé Google Chrome.
• Télécharger l'extension Chrome Contentsquare Tracking Setup Assistant ↗.
• Masquer des éléments du replay en utilisant les sélecteurs CSS ou l'attribut data-cs-mask — les éléments <input> ne sont pas capturés par défaut, à l'exception des listes déroulantes, qui doivent être masquées.
• Définir l'approche par défaut sur Full masking.
• Si vous avez déjà fourni une liste de vos adresses IP internes/de bureau pour qu'elles soient ajoutées à la liste d'exclusion, informez votre Success Manager Contentsquare afin de suspendre temporairement cette liste d'exclusion. Sinon, les sessions de test depuis ces IPs ne seront pas collectées par Contentsquare.

1. Démarrez un parcours sur votre site web, comprenant les éléments qui seront masqués.

2. Dans l'extension Contentsquare Tracking Setup Assistant, sélectionnez Turn off automasking afin que le masquage du texte (aaa) ne s'applique pas à votre session locale.

   

3. Sélectionnez Collected for Session Replay pour activer l'enregistrement du replay pour votre session.

   

4. Sélectionnez Trigger testing pageEvent pour créer l'événement de page SR Testing identifiant votre session courante.

   

5. Assurez-vous que les éléments à masquer sont visibles tout au long de votre parcours de test. Si nécessaire, saisissez des informations personnelles fictives. Vous pourrez vérifier qu'elles ont bien été masquées dans le replay.

6. Lorsque vous avez terminé le parcours, fermez l'onglet de session ou supprimez vos cookies.

   

7. Regardez le replay en portant attention à tous les endroits où des données personnelles pourraient apparaître :

• ❌ Si des données personnelles sont visibles, mettez à jour votre masquage et recommencez les tests.
• ✅ Si aucune donnée personnelle n'est présente, votre implémentation est conforme en matière de confidentialité.

Si vous êtes dans la phase d'implémentation initiale de votre projet, informez votre Success Manager des résultats afin qu'il/elle puisse les vérifier, puis passer l'approche par défaut sur No masking pour vous permettre d'utiliser le Session Replay complet.

Si vous avez passé la phase d'implémentation et que vos tests sont réussis, vous pouvez mettre à jour vous-même l'approche par défaut, les page rules et les element rules si vous êtes Admin, depuis la page Data masking des paramètres de votre projet.

Pour plus d'informations, consultez l'article du centre d'aide ↗.

Le contenu HTML est envoyé via une requête à l'un des endpoints ci-dessous, selon la région où vos données sont stockées :

• https://k.aeu1.contentsquare.net/{apiVersion}/recording
• https://k.aus1.contentsquare.net/{apiVersion}/recording
• https://k.eu1.az.contentsquare.net/{apiVersion}/recording
• https://k.us1.az.contentsquare.net/{apiVersion}/recording
• https://k.ba.contentsquare.net/{apiVersion}/recording
• https://k.bf.contentsquare.net/{apiVersion}/recording
• https://k.aa.contentsquare.net/{apiVersion}/recording
• https://k.af.contentsquare.net/{apiVersion}/recording

La requête est envoyée lorsque la 2e valeur du cookie _cs_s (état de la collecte du Session Replay) est l'une des suivantes, ou lorsque Event Triggered Replay (ETR) est activé sur le projet :

• 5 : collecté, selon le taux d'échantillonnage global du projet
• 6 : collecté, selon une règle d'échantillonnage par URL
• 8 : collecté, selon une règle de ciblage

Lorsque votre projet exige le consentement du visiteur pour le Session Replay, aucune requête n'est envoyée tant que le visiteur ne l'a pas accordé.

La requête contient l'intégralité du DOM.

Des données personnelles peuvent apparaître ailleurs que dans le contenu HTML.

Pour une page donnée, vous devez également masquer les données personnelles qui peuvent se trouver dans :

• Le path de la page courante
• Les paramètres de l'URL
• Le referrer de la prochaine page visitée

Des données non masquées peuvent être exposées dans le Session Replay et dans le module Error Analysis.

Pour supprimer des données personnelles dans l'URL de la page courante, réécrivez l'URL du pageview avant que le Tag ne la collecte, en utilisant la commande setPath.

La commande setPath prend en paramètre le nouveau chemin exact à collecter. Le tag collecte cette valeur telle quelle : il n'y remplace rien. C'est le code de votre site qui doit calculer le chemin masqué.

window._uxa = window._uxa || [];
window._uxa.push([
  'setPath', <NEW_PATH_TO_COLLECT>, { lifespan: 'onNextPageviewOnly' }
]);

Exécutez cette commande sur toutes les pages dont l'URL contient des données personnelles, avant le chargement du Tag principal. Transmettez uniquement un chemin, commençant par /, jamais une URL complète.

L'option lifespan: 'onNextPageviewOnly' limite la surcharge à la pageview suivante. Dans une Single Page Application, appelez à nouveau setPath avant chaque changement de route. Sinon, les pageviews suivantes sont collectées avec l'URL réelle, y compris ses données personnelles. Voir Durée d'application de setPath et setQuery.

Le code de votre site remplace le nom d'utilisateur du chemin courant par un espace réservé, puis transmet le résultat à setPath :

window._uxa = window._uxa || [];
var maskedPath = window.location.pathname.replace(/\/users\/[^/]+/, "/users/CS_ANONYMIZED_USER_ID");
window._uxa.push(["setPath", maskedPath, { lifespan: "onNextPageviewOnly" }]);

Lorsque des données personnelles apparaissent dans les paramètres de requête d'une URL, utilisez la commande setQuery pour remplacer la query string dans l'URL par une version masquée.

window._uxa = window._uxa || [];
window._uxa.push([
  'setQuery',
  <ANONIMYZED_QUERY_STRING>
]);

La commande setQuery prend en paramètre la nouvelle query string exacte à afficher dans l'URL. Cette commande spécifie au Tag de remplacer tout ce qui suit le caractère ? dans l'URL par des valeurs masquées. Le ? initial est facultatif. Pour supprimer entièrement la query string, transmettez une chaîne vide : setQuery("").

Exécutez cette commande sur toutes les pages dont l'URL contient des données personnelles, avant le chargement du Tag principal. Seule la query string doit être configurée, pas l'URL complète.

window._uxa = window._uxa || [];
window._uxa.push(["setQuery", "?user_id=CS_ANONYMIZED_USER_NAME&address=CS_ANONYMIZED_ADDRESS"]);

Personnalisez le masking selon le type de paramètre à remplacer, afin que le résultat soit explicite :

• CS_ANONYMIZED_USER_ID
• CS_ANONYMIZED_EMAIL
• CS_ANONYMIZED_ADDRESS

...et ainsi de suite.

• Par défaut, le chemin ou la query string remplacés restent en vigueur pour toutes les pageviews suivantes du même chargement de page, y compris les pageviews artificielles des applications monopage. Transmettez à nouveau la commande avec la nouvelle valeur à chaque changement de route.
• Pour n'appliquer la surcharge qu'à la pageview suivante, utilisez l'option lifespan. Voir setPath et setQuery dans la référence des commandes.
• Lorsque vous remplacez le chemin ou la query string, la partie #fragment de l'URL n'est pas collectée.
• Le masquage automatique des données personnelles s'applique toujours à l'URL obtenue.

Même lorsqu'elles sont masquées dans les URLs et les paramètres de requête, les données personnelles se propagent dans la page suivante du parcours utilisateur via le referrer ↗ du navigateur. Pour ce cas d'usage, utilisez les commandes préfixées referrer: ci-dessous.

Prenons l'exemple de ce parcours :

1. L'utilisateur navigue de https://www.example.com/users/123456/products/ABCDEF vers https://www.example.com/.
2. Un pageview est envoyé sur https://www.example.com/.
3. La valeur du referrer dans le navigateur et dans la requête pageview est https://www.example.com/users/123456/products/ABCDEF.

Pour masquer les données personnelles dans l'URL du referrer, utilisez la commande referrer:maskUrl :

var referrers = [
  "https://www.example.com/users/:USER_ID/products/:PRODUCT_ID",
  "https://www.example.com/account/cancelOrder/:ORDER_ID",
  "https://www.example.com/order/:ORDER_ID/merge/:ORDER_ID",
];
window._uxa = window._uxa || [];
for (var i = 0; i < referrers.length; i++) {
  window._uxa.push(["referrer:maskUrl", referrers[i]]);
}

La valeur du referrer dans la requête pageview pour la page https://www.example.com/ sera :

• https://www.example.com/users/CS_ANONYMIZED_USER_ID/products/CS_ANONYMIZED_PRODUCT_ID
• https://www.example.com/account/cancelOrder/CS_ANONYMIZED_ORDER_ID
• https://www.example.com/order/CS_ANONYMIZED_ORDER_ID/merge/CS_ANONYMIZED_ORDER_ID

Fonctionnement de la correspondance des patterns referrer:maskUrl :

• Les patterns doivent inclure le protocole et l'hôte, par exemple https://www.example.com/users/:user_id.
• Un pattern correspond au début de l'URL du referrer. Les segments de chemin situés après la fin du pattern sont conservés.
• La query string est ignorée pour la correspondance, et conservée dans le referrer collecté. Utilisez referrer:removeQueryString pour la supprimer.
• Les segments littéraux sont sensibles à la casse.
• Les noms de variables sont mis en majuscules pour construire le remplacement : :user_id devient CS_ANONYMIZED_USER_ID, et :userId devient CS_ANONYMIZED_USERID.

Prenons l'exemple de ce parcours :

1. L'utilisateur navigue de https://www.example.com/confirmation?firstname=jon&lastname=snow vers https://www.example.com/.
2. Un pageview est envoyé sur https://www.example.com/.
3. La valeur du referrer dans le navigateur et dans la requête pageview est https://www.example.com/confirmation?firstname=jon&lastname=snow.

Pour masquer les données personnelles dans les paramètres de la requête du referrer, utilisez la commande referrer:removeQueryString :

window._uxa = window._uxa || [];
window._uxa.push(["referrer:removeQueryString"]);

La valeur du referrer dans la requête pageview pour la page https://www.example.com/ sera :

https://www.example.com/?

Sur les projets qui collectent des données Product Analytics, le titre de la page est collecté sans aucun masquage de données personnelles. Si vos titres de page peuvent contenir des données personnelles, comme un numéro de commande ou un nom de client, masquez-les avec l'une de ces méthodes :

• Ajoutez l'attribut data-cs-hide-title à l'élément <title>. L'attribut data-heap-redact-text a le même effet.
• Transmettez la commande hidePageTitle, pour la pageview suivante uniquement ou pour toutes les suivantes. Utilisez resetHidePageTitle pour collecter à nouveau le titre.

<title data-cs-hide-title>Order #12345 for Jane Smith - Retail Store</title>

Le titre de la page est alors remplacé par ****.

Utilisez la commande networkRequest:maskUrls pour réécrire l'URL avant que le Tag ne collecte l'URL de l'erreur d'API. Les mêmes patterns s'appliquent aussi aux URLs de requêtes réseau collectées dans le Session Replay pour les temps de performance.

La commande reçoit en paramètre un pattern de masking (une chaîne) ou plusieurs (un tableau de chaînes) à appliquer aux URLs contenant des données personnelles. Un pattern correspond à n'importe quelle suite de segments de chemin consécutifs de l'URL : il peut inclure l'hôte, mais ce n'est pas obligatoire.

window._uxa = window._uxa || [];
window._uxa.push([
  'networkRequest:maskUrls',
  <PATTERN>
]);

Les patterns incluent des fragments d'URL à masquer, passés comme des variables préfixées par :. Ces variables sont remplacées par CS_ANONYMIZED_{FRAGMENT} :

• :user_id devient CS_ANONYMIZED_USER_ID
• :address devient CS_ANONYMIZED_ADDRESS
• :email devient CS_ANONYMIZED_EMAIL

Exécutez cette commande sur toutes les pages contenant des données personnelles et qui appellent l'API Contentsquare, avant le chargement du Tag principal.

• Chaque appel ajoute ses patterns à ceux déjà enregistrés. Pour effacer tous les patterns enregistrés, utilisez networkRequest:maskUrls:reset.
• Commencez chaque pattern par un segment littéral, comme order/:order_id. Un pattern qui commence par une variable peut aussi correspondre au nom d'hôte.
• La commande obsolète api-errors:maskUrl prend des patterns d'URL complète. Lorsque l'un de ses patterns correspond à une URL, les patterns de networkRequest:maskUrls ne sont pas appliqués à cette URL.

window._uxa.push([
  "networkRequest:maskUrls",
  ["order/:order_id/merge/:order_id", "order/:order_id/item", "cancelOrder/:order_id"]
]);

Lorsque la collecte des détails des erreurs d'API est configurée pour votre projet, les corps de requête et de réponse, les paramètres de requête, ainsi que les en-têtes et éléments de corps configurés pour le chiffrement, sont collectés chiffrés avec votre clé publique Controlled Exposure. Si le chiffrement n'est pas disponible, ces valeurs ne sont pas collectées.

Les en-têtes personnalisés et les éléments de corps de requête et de réponse qui ne sont pas configurés pour le chiffrement sont envoyés en clair, avec les adresses e-mail masquées. Cela inclut les éléments de corps de réponse non chiffrés utilisés dans l'Errors Dashboard, les Alerts et l'Analysis Context (voir Dépannage avancé). Les en-têtes standard sont envoyés tels quels. Ne configurez pas en clair des éléments de corps pouvant contenir des données personnelles.

Lorsque la collecte des éléments cliqués est activée et que la session utilisateur est enregistrée, le Tag collecte le contenu textuel des éléments cliqués dans le cadre des autres données d'analyse (voir /events request).

La collecte des éléments cliqués est désactivée par défaut. Elle s'active par projet, soit pour les boutons et les liens uniquement, soit pour tout élément cliqué (voir Target text). Le texte est tronqué à 100 caractères, et le texte entier est supprimé lorsque :

• Il contient une adresse e-mail, un numéro de carte bancaire ou une séquence de 9 chiffres ou plus. Lorsque les nombres sont masqués sur la page, un seul chiffre suffit à supprimer le texte.
• Une partie de ce texte est masquée, chiffrée ou non capturée.

L'élément cliqué est collecté à moins qu'il ne soit masqué via l'attribut data-cs-mask.

Le texte de l'élément cliqué n'est pas collecté, sauf si l'élément dont le texte est collecté (l'élément cliqué, ou le bouton ou lien le plus proche) est exposé avec data-cs-capture ou setCapturedElementsSelector, directement ou via l'un de ses ancêtres.

Vous pouvez aussi masquer des éléments précis sur la page. Ce masquage est prioritaire sur l'approche par défaut et les page rules. Pour plus d'informations, voir la section Personal Data Selector.

Le tag Contentsquare ne collecte pas le texte saisi dans les champs de type input ou textarea.

Si vous avez besoin d'afficher les données personnelles d'un utilisateur, telles que les adresses de livraison, les noms, les numéros de téléphone, les adresses e-mail, ou le texte saisi dans un champ de formulaire, utilisez le mode collecte et chiffrement.

Avec le mode collecte et chiffrement, vous pouvez collecter, stocker et afficher le texte d'un champ input, d'un champ textarea ou de tout autre élément d'une page qui est habituellement masqué par le tag, avant qu'il ne soit envoyé aux serveurs de Contentsquare.

Il existe deux méthodes pour collecter et chiffrer les données personnelles à partir du HTML collecté :

• Utiliser le Contentsquare Encryption Selector
• Tagger les éléments du DOM

Chaque élément du DOM à collecter et à chiffrer est identifié par son sélecteur CSS. Ces sélecteurs sont transmis à l'API par l'intermédiaire d'un objet JavaScript. Le contenu de l'élément identifié est alors chiffré et collecté pour les Session Replays.

L'objet suivant, qui contient des sélecteurs CSS pour le texte, doit être transmis à l'API comme suit, avant de déclencher le tag principal :

window._uxa = window._uxa || [];
window._uxa.push(["setEncryptionSelectors", "#cart, .total-items"]);

L'attribut data-cs-encrypt peut être ajouté à un champ de saisie, à un champ textuel ou à tout autre élément. Au lieu d'être masqué, le texte présent dans l'élément tagué est chiffré, stocké et mis à disposition pour être exposé dans des conditions spécifiques.

Le chiffrement s'applique à tout le texte de l'élément tagué, y compris le texte des éléments imbriqués, du contenu du shadow DOM et des nœuds ajoutés plus tard. Il s'applique aussi aux valeurs des éléments <input> et <textarea> :

• Les valeurs des éléments <input> de type password, number, checkbox ou radio ne sont jamais chiffrées : elles restent masquées.
• Les attributs ne sont jamais chiffrés : ils sont collectés comme ils le seraient sans data-cs-encrypt.

Ajoutez l'attribut data-cs-encrypt sur les éléments les plus granulaires qui doivent être collectés, afin de n'exposer que les données nécessaires.

<h2 class="welcoming">
  Welcome back
  <span class="user_name" data-cs-encrypt>John Doe</span>
</h2>

Vous pouvez également ajouter l'attribut data-cs-encrypt avec JavaScript. Voir Quand les règles de masquage prennent effet.

Pour utiliser Controlled Exposure, obtenez une combinaison de clés de chiffrement :

• Clé publique : utilisée par le Tracking Tag pour chiffrer les données.
• Clé privée : utilisée par l'application pour le déchiffrement.

1. Copiez le script suivant :

   function arrayBufferToString(buffer) {
     const byteArray = new Uint8Array(buffer);
     let byteString = "";
     for (let i = 0; i < byteArray.byteLength; i += 1) {
       byteString += String.fromCodePoint(byteArray[i]);
     }
     return byteString;
   }
   
   crypto.subtle
     .generateKey(
       {
         name: "RSA-OAEP",
         hash: "SHA-256",
         modulusLength: 4096,
         publicExponent: new Uint8Array([1, 0, 1]),
       },
       true,
       ["encrypt", "decrypt"],
     )
     .then((keysObject) => {
       crypto.subtle.exportKey("pkcs8", keysObject.privateKey).then((result) => {
         const privateKey = btoa(arrayBufferToString(result));
         console.log(`Private key: `, privateKey);
       });
       crypto.subtle.exportKey("spki", keysObject.publicKey).then((result) => {
         const publicKey = btoa(arrayBufferToString(result));
         console.log(`Public key: `, publicKey);
       });
     });

2. Collez le script dans la console Chrome.

3. Appuyez sur Entrée.

Sur Linux/Mac, vous pouvez utiliser OpenSSL :

openssl genpkey -out mykey.pem -algorithm RSA -pkeyopt rsa_keygen_bits:4096
openssl rsa -in mykey.pem -pubout > mykey.pub

Sur Windows vous devrez installer WSL ↗.

1. Allez dans la Console Contentsquare > Choisissez votre compte > Choisissez votre projet > Allez dans l'onglet "Encryption management".
2. Sélectionnez "Store public key".
3. Collez votre clé publique.
4. Sélectionnez "Store key".

1. Sélectionnez l'icône de clé et choisissez "Unmask on-screen text".
2. Saisissez la clé privée et sélectionnez "decrypt" (tous les replays seront exposés).

Avec la fonctionnalité User Identifier, vous pouvez rechercher des replays appartenant à des utilisateurs spécifiques grâce à un identifiant unique. Vous pouvez ainsi chercher et accéder à toutes les sessions associées à un utilisateur donné, par exemple john@gmail.com, sur la plage de dates sélectionnée. Cette fonctionnalité est particulièrement utile en cas de commentaires ou de plaintes d'utilisateurs.

L'identifiant utilisateur peut être toute valeur permettant d'identifier un utilisateur de façon unique : nom d'utilisateur, numéro de compte, adresse e-mail, numéro de téléphone, ID CRM ou ID de programme de fidélité. Dans le navigateur, le tag supprime les espaces en début et en fin de valeur, la convertit en minuscules, puis la hache dans un format à sens unique avant de l'envoyer à Contentsquare.

Lorsque vous filtrez les Session Replays avec un User Identifier dans Contentsquare, le même algorithme de hachage est utilisé et les deux hashs sont comparés pour associer l'identifiant à ses replays.

1. Choisir le bon User Identifier : Optez pour un identifiant unique tel que l'adresse e-mail, le nom d'utilisateur ou le numéro de compte, accessible depuis le front-end.

2. Collecte des User Identifiers : Pour collecter le User Identifier, envoyez un événement de page via la commande trackPageEvent, avec le préfixe @user-identifier@ :

   window._uxa = window._uxa || [];
   window._uxa.push(["trackPageEvent", "@user-identifier@user_email"]);

   Ou si vous tirez l'identifiant de votre data layer :

   window._uxa = window._uxa || [];
   window._uxa.push(["trackPageEvent", "@user-identifier@" + dataLayer.Name]);

   La valeur du User Identifier est limitée à 100 caractères. Une valeur plus longue est rejetée et n'est pas envoyée.