Activation du contenu adaptatif

Choisissez une méthode d’authentification pour transmettre les données utilisateur à GitBook.

Pour commencer à personnaliser l’expérience de documentation pour vos lecteurs, vous devrez activer le contenu adaptatif et décider comment les données de vos visiteurs sont transmises à GitBook. Cela permet au contenu de votre site de s’adapter dynamiquement en fonction de la personne qui le consulte.

Activer le contenu adaptatif

Avant de pouvoir transmettre des données utilisateur à GitBook, vous devez configurer votre site pour utiliser le contenu adaptatif.

Rendez-vous dans votre paramètres du site, et activez Contenu adaptatif dans les paramètres d’audience de votre site. Une fois activé, vous recevrez une « clé de signature du jeton visiteur » générée, dont vous aurez besoin pour poursuivre la configuration du contenu adaptatif.

A GitBook screenshot showing the enable adaptive content toggle
Activer le contenu adaptatif

Définissez votre schéma visiteur

Après avoir activé le contenu adaptatif, vous devrez définir un schéma pour les types de revendications que vous attendez que GitBook reçoive lorsqu’un utilisateur visite votre site.

Le schéma visiteur doit refléter la structure de ces revendications lorsqu’elles sont envoyées à GitBook.

Par exemple, si vous prévoyez qu’un visiteur puisse être un utilisateur bêta de votre produit, vous définiriez un schéma visiteur similaire à :

{
  "type": "object",
  "properties": {
    "isBetaUser": {
      "type": "boolean",
      "description": "Si le visiteur est un utilisateur Beta.",
    }
  },
  "additionalProperties": false
}

Cela vous aidera également à utiliser l’autocomplétion lors de la configuration de vos revendications dans l’ éditeur de conditions. Les schémas visiteur ne prennent en charge que les types suivants :

Lire les revendications transmises en tant que chaînes.

Chaînes doit contenir une clé enum qui doit contenir toutes les valeurs attendues qui seraient trouvées sur la clé lue.

{
  "type": "object",
  "properties": {
    "language": {
          "type": "string",
          "description": "La langue du visiteur",
          "enum": [
            "en",
            "fr",
            "it"
          ]
  },
  "additionalProperties": false
}

Définir une revendication non signée

Les revendications non signées sont un type spécifique de revendication qui identifie les revendications pouvant provenir d’un client qui ne les a pas signées. Il est nécessaire de définir les revendications dans votre schéma visiteur comme non signées si vous transmettez des revendications via des paramètres d’URL, des cookies non signés ou des feature flags.

Si vous avez l’intention de travailler avec des revendications non signées, vous devrez déclarer les revendications attendues dans le schéma sous une propriété « unsigned » en parallèle de vos revendications signées.

{
  "type": "object",
  "properties": {
    "isBetaUser": {
      "type": "boolean",
      "description": "Si le visiteur est un utilisateur Beta.",
    },
    // Ajouter des revendications non signées
    "unsigned": {
      "type": "object",
      "description": "Revendications non signées du visiteur du site.",
      "properties": {
        "language": {
          "type": "string",
          "description": "La langue du visiteur",
          "enum": [
            "en",
            "fr",
            "it"
          ]
        }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}

Transmettre les données du visiteur à GitBook

GitBook propose différentes manières de transmettre les données des visiteurs pour adapter le contenu de votre site. Après avoir défini votre schéma, vous devrez décider comment vous souhaitez transmettre les données des visiteurs à GitBook.

Mis à jour

Ce contenu vous a-t-il été utile ?