Page targeting
Page targeting allows you to only monitor specific pages from your website or web application.
Let’s say, for example, that you have a fairly static and content driven website. Your site, however, has a quite complicated payments page. This is the only page in your website, that could produce bugs which are hard to reproduce.
The website has a huge number of daily visitors but only just a small fraction of them visit and use the payments page. Since one of the constraints in our plans is the number of daily monitored sessions per account, you could save up a lot of money by just monitoring the payments page instead of every page in your website.
This can be achieved in two ways:
- Copy your website snippet only in the pages that should be monitored. This is hard to manage, because if you decide to monitor a different set of pages, you need to manually edit them.
- Use page targeting.
We’re going to discuss in more detail how page targeting works and what are the current limitations.
How it actually works?
For each of your websites, you can configure specific rules that determine which pages should be monitored.
Each website can have multiple rules. If no rules are provided, every page of your website will be monitored. If rules are provided, a page needs to match at least one rule in order to be monitored.
As shown in the image, there are six different types of rules that can be applied for a website. You can read our documentation for more details about each type.
Current limitations
Currently, a page is determined whether it should be monitored when the page is loaded. This works quite well in most cases.
In many web apps, however, when some part of the UI changes, the URL also changes (for example the part after /#/ in the URL).
If you configure your web app with the following rule: www.example.com/#/view1 and you visit it, the app will be monitored. If the URL changes to www.example.com/#/view2 the app will be still monitored, because the rule evaluation only happens when the page is visited and any dynamic changes are not being applied.
For example, if the following web app is configured to monitor sessions only for the page with URL www.example.com/#/customer
and the visitor navigates to “Who we are”
SessionStack will continue monitoring the session, because the whole page is not being reloaded.
What are our plans?
In future versions we will make dynamic URL changes to apply and match with the specified rules for the website. This will make the above case work as expected.
