docs(product tours): add element targeting, button, and progression docs#14826
Open
docs(product tours): add element targeting, button, and progression docs#14826
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
adboio
force-pushed
the
02-05-docs_product_tours_add_element_targeting_button_and_progression_docs
branch
from
f1ce818 to
cbc8290
Compare
adboio
force-pushed
the
02-05-docs_product_tours_add_element_targeting_button_and_progression_docs
branch
from
4e8a398 to
37a7118
Compare
edwinyjlim
approved these changes
Feb 6, 2026
|
|
||
| <Alpha /> | ||
|
|
||
| PostHog provides two ways to target specific elements for Product Tours: **auto** and **manual**. |
Member
There was a problem hiding this comment.
describe what "elements" means specifically. maybe HTML, CSS, or other words work better here, your call!
Suggested change
| PostHog provides two ways to target specific elements for Product Tours: **auto** and **manual**. | |
| PostHog provides two ways to target specific webpage elements for Product Tours: **auto** and **manual**. |
Comment on lines
+15
to
+17
| By default, we use a robust **automatic** targeting algorithm to find your elements. This is the recommended approach, but may need some configuration tweaks depending on your app. | ||
|
|
||
| If you prefer, you can swap to **manual** targeting, and provide a CSS selector for us to use for finding tour elements. |
Member
There was a problem hiding this comment.
Let's match the section headers
Suggested change
| By default, we use a robust **automatic** targeting algorithm to find your elements. This is the recommended approach, but may need some configuration tweaks depending on your app. | |
| If you prefer, you can swap to **manual** targeting, and provide a CSS selector for us to use for finding tour elements. | |
| By default, we use a robust **automatic element targeting** algorithm to find your elements. This is the recommended approach, but may need some configuration tweaks depending on your app. | |
| If you prefer, you can swap to **manual element targeting**, and provide a CSS selector for us to use for finding tour elements. |
|
|
||
| Automatic targeting is the default for all tour steps. This is the recommended option for most cases, but read on to learn when it may not work, or when you may need to tweak its configuration. | ||
|
|
||
| When you select an element, we collect information such as class names and other attributes so we can reliably find it again later. |
Member
There was a problem hiding this comment.
Suggested change
| When you select an element, we collect information such as class names and other attributes so we can reliably find it again later. | |
| When you select an element, we collect information such as CSS class names and other attributes so we can reliably find it again later. |
Comment on lines
+26
to
+30
| 1. When you select an element, we gather many "groups" of selectors that match your element (and potentially other elements) | ||
| 2. These groups are sorted by specificity, so the groups matching the lowest number of elements are prioritized | ||
| 2. At tour runtime, we reverse this algorithm to see which elements are matched by each group | ||
| 3. Each found element gets a "vote" | ||
| 4. The element with the highest number of votes "wins" and is used for the given tour step |
Member
There was a problem hiding this comment.
adding periods. these are complete and independent sentences.
Suggested change
| 1. When you select an element, we gather many "groups" of selectors that match your element (and potentially other elements) | |
| 2. These groups are sorted by specificity, so the groups matching the lowest number of elements are prioritized | |
| 2. At tour runtime, we reverse this algorithm to see which elements are matched by each group | |
| 3. Each found element gets a "vote" | |
| 4. The element with the highest number of votes "wins" and is used for the given tour step | |
| 1. When you select an element, we gather many "groups" of selectors that match your element (and potentially other elements). | |
| 2. These groups are sorted by specificity, so the groups matching the lowest number of elements are prioritized. | |
| 2. At tour runtime, we reverse this algorithm to see which elements are matched by each group. | |
| 3. Each found element gets a "vote". | |
| 4. The element with the highest number of votes "wins" and is used for the given tour step. |
| 3. Each found element gets a "vote" | ||
| 4. The element with the highest number of votes "wins" and is used for the given tour step | ||
|
|
||
| This process has proven to be far more robust than most other Product Tours products that simply build a single CSS selector for your chosen elements. |
Member
There was a problem hiding this comment.
Suggested change
| This process has proven to be far more robust than most other Product Tours products that simply build a single CSS selector for your chosen elements. | |
| This process has proven to be robust than using a single CSS selector for your chosen elements. |
|
|
||
| For more interactive tours, you can choose **Element click** as a step's progression trigger. | ||
|
|
||
| With this option we will not show a "Next" button by default, and users will get to the next step by clicking on the current step's element. |
Member
There was a problem hiding this comment.
Suggested change
| With this option we will not show a "Next" button by default, and users will get to the next step by clicking on the current step's element. | |
| With this option we will not show a **Next** button by default, and users get to the next step by clicking on the current step's element. |
|
|
||
| <Alpha /> | ||
|
|
||
| Each Product Tour step (or modal announcement) has a primary button and, optionally, a secondary button. Toggle on "custom buttons" in the Product Tour editor to configure your steps with these actions: |
Member
There was a problem hiding this comment.
Suggested change
| Each Product Tour step (or modal announcement) has a primary button and, optionally, a secondary button. Toggle on "custom buttons" in the Product Tour editor to configure your steps with these actions: | |
| Each Product Tour step (or modal announcement) has a primary button and, optionally, a secondary button. Toggle on **custom buttons** in the Product Tour editor to configure your steps with these actions: |
Comment on lines
+13
to
+37
| ## Next step | ||
|
|
||
| Default primary button behavior - moves your tour to the next step. | ||
|
|
||
| _Not available for announcements._ | ||
|
|
||
| ## Previous step | ||
|
|
||
| Default secondary button behavior - moves your tour to the previous step. | ||
|
|
||
| **Note:** if your tour causes users to navigate to another page, this action **will not navigate them back.** In these cases, we recommend disabling the secondary button, or swapping to a different action. | ||
|
|
||
| _Not available for announcements._ | ||
|
|
||
| ## Start tour | ||
|
|
||
| Ends the current tour and starts another one. This is great for triggering product tours from [announcements](/docs/product-tours/creating-announcements)! | ||
|
|
||
| ## Open link | ||
|
|
||
| Opens a given link in a new tab. | ||
|
|
||
| ## Dismiss | ||
|
|
||
| Dismisses the current tour or announcement. |
Member
There was a problem hiding this comment.
Maybe use a table instead. I can see this going either way
| classes="rounded" | ||
| /> | ||
|
|
||
| When attaching elements to steps, you'll be able to choose between **Auto** and **Manual** targeting: |
Member
There was a problem hiding this comment.
Suggested change
| When attaching elements to steps, you'll be able to choose between **Auto** and **Manual** targeting: | |
| When attaching elements to steps, you'll be able to choose between **Auto** and **Manual** targeting. |
Comment on lines
+32
to
+33
| - **Auto**: simply click your element and we'll collect data about it so we can reliably find it again during tours | ||
| - **Manual**: you provide a CSS selector for us to target the element |
Member
There was a problem hiding this comment.
Suggested change
| - **Auto**: simply click your element and we'll collect data about it so we can reliably find it again during tours | |
| - **Manual**: you provide a CSS selector for us to target the element | |
| - **Auto**: Click your element and we'll collect data about it so we can reliably find it again during tours. | |
| - **Manual**: Provide a CSS selector for us to target the element. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
product tours is moving fast! 😄 updating the docs to reflect some recent changes, and add missing config pieces
Checklist
vercel.json