Adapting your content
Tailor your content for different users
Last updated
Was this helpful?
🇺🇸 English
Tailor your content for different users
Last updated
Was this helpful?
Was this helpful?
After setting up your authentication method, you’ll be able to use the data to adapt the content in your site for different users.
You can adapt and personalize many parts of your docs, including:
Hiding or showing pages
Hiding or showing site variants
Hiding or showing site sections
Hiding or showing header links
Adding personalized content to inline expressions
The condition editor is where you’ll set the conditions for showing or hiding a page, variant, or section. After opening the condition editor, you’ll be able to write your condition as an expression that will run against data coming from visitors to your site.
The data you pass through your users to GitBook is attached to an object called visitor.claims.
Let’s take a look at an example if we want to write a conditional statement to only show a page for users who are part of a beta program you might define.
visitor.claims.isBetaUser == trueThe expression above means that any user who matches this claim (i.e. isBetaUser is true in the user’s claim), will be able to see and access the page. Any user who does not match this claim (including visitors without any claims set), will not be able to see or access the page.
The condition editor also comes built in with autocomplete, which suggests claims or attributes that have been found on previous visitors to your site, helping you craft the conditional statement for your pages, variants, or sections.
As you use the autocomplete, you'll notice that variables are also available to use. You can combine variables that you have defined together with claims that come from user data to write conditional expressions. For example, you could:
Set a variable for the latest version of your product
Then, configure a claim that shows which version of your product is being used by a visitor to your docs
Finally, write an expression to only show certain pages when a user is on the latest version of your docs
You can write many different kinds of expressions , as long as they are written in valid Javascript. For instance, you can combine multiple claims into the condition editor to match specific users by using the && or || operator. You can read more about operators here.
Segments represent mock user data that you can configure to test your conditions.
For example, you could set up a segment that represents a developer on your enterprise plan, or a sign-in user on a free plan, and then see which pages would be visible to them.
You can read more about setting up and using segments here.
To launch the condition editor for a page, head to the actions menu 
next to a page, and click Add condition. You can also launch the condition editor from a page’s options.
You can see which pages in your space have conditions set if the page has a page condition icon 
next to it.
To launch the condition editor for a variant, head to the actions menu next to a variant, and click Add condition.
You can see which variants in your docs have conditions set if the variant has a page condition icon next to it.
To launch the condition editor for a section, head to the actions menu next to a section, and click Add condition.
You can see which sections in your docs have conditions set if the section has a page condition icon next to it.
To launch the condition editor for a page header link, head to the actions menu next to a header link, and click Add condition.
You can see which links in your docs have conditions set if the section has a page condition icon next to it.
In addition to controlling the visibility of content, you can also use claims inline using expressions, just like page and space variables.
To reference a claim inline using an expression, type / in the editor, then select 
Expression. Claims will be accessible in the expression editor as properties on visitor .
Conditions set in GitBook are synced through Git Sync and appear in the synced Markdown pages. This means blocks and pages with conditions set on their visibility are still visible in your synced repo.
Data passed through claims is never visible in Markdown, and is securely passed to GitBook.