Monitor Changes to Specific Areas of a Web Page
Fluxguard is engineered to monitor changes to content that you care about. Nonetheless, on any given website, many areas legitimately change... but those changes are irrelevant. We call these “false-positives.”
Fluxguard has effective tools to reduce them, including Network Blocks, Filters, Transforms, and more. In this tutorial, we dive into our Inclusion and Exclusion Filters, as well as our “Selector Ignores.”
Related use case: monitor changes to on-page SEO.
Use Exclusion Filters to Remove Areas From a Monitored Page
It is possible to add Exclusion Filters from Session View or Page View, and in Account Settings.
- Adding Exclusion Filters in Account Settings will apply to every site in your org.
- Adding Exclusion Filters at the session level will be used on every page in that session.
- For more page-specific removals, set Exclusion Filters at the page level.
It is possible to add multiple Exclusion Filters. Fluxguard will attempt to utilize all levels of set filters.
1. Add the page/site and perform an initial crawl
An initial crawl of the page is necessary to obtain an initial version without the filter. This way, you can validate filter performance. Visual Selector simplifies filter setup.
2. Click into Session or Page Settings
Remember, Exclusion Filters can be added at the Session level (where the filters will be used on every page of the session), or Page level (where the filters will be used for that page only). You can also set up global filters in Account Settings.
3. Locate the section titled “Exclusion Filters”
In Page Settings, this should be visible in the modal. From Session Settings, click the “Crawl Settings” tab.
4. Manually enter CSS selectors to ignore
Don’t know what this means? Then skip to the next bullet item. Fluxguard utilizes CSS selectors to determine what areas to filter. If you are familiar with how web pages are constructed, it may be better to use Google Chrome’s DevTools to identify the areas you wish to disregard. Briefly, here’s how:
- Use Google Chrome, load the monitored page, and right-click on the section you want to ignore.
- Select “Inspect” from the drop-down menu.
- Mouse up-and-down in the “Elements” panel that opens in the bottom portion of the browser. This will highlight different fields of the page. Move up-and-down until you have highlighted the area to dismiss.
- Now right-click and select Copy and then choose Copy Selector. This will copy a unique identifier for this particular section.
- Paste the filter in the Exclusion Filters section.
5. Or use Visual Selector to identify areas to ignore
Our interactive Visual Selector tool will open in a new window and utilize the HTML from the initial crawl in an attempt to display the site. It’s not always perfect, but it’s sufficient enough. Mouse around the page and click on the areas you wish to disregard.
The selected areas will become highlighted.
6. Save Settings
Now click “Save” and wait to learn the CSS selector that best identifies each area.
7. Start a new crawl to see the filter in action
(To the extent that a filter doesn’t contain text, then no new version may be generated.)
Once the crawl is complete, the areas should be removed. In the example above, note how the left sidebar and header are absent.
Note that Exclusion Filters REMOVE identified areas from the DOM prior to capturing. More often than not, this is what you want. Further on this page, take a peek at our “selector ignores” for a feature that modifies this approach for various monitoring use cases.
Note: changes detected after the first crawl with filters (assuming an initial crawl without filters preceded) will be included in your next change summary email. This sometimes confuses customers, but it’s a useful way to test that everything’s functioning, too.
8. You’re all set!
Keep reading to learn more filter techniques. Or check out how to use Network Blocks for more ways to reduce false-positives.
Use Inclusion Filters to Isolate a Key Area for Monitoring
Inclusion Filters are the inverse of Exclusion Filters described above. As such, we won’t go into much detail about them, apart from the following:
- Inclusion Filters can be found beside the Exclusion Filters.
- Instead of selecting areas to ignore, Inclusion Filters tell Fluxguard what area to focus on. Everything else will be removed from the DOM!
- Using Inclusion Filters and you get an alert with a blank page? This means no Inclusion Filter matches were discovered: either the filter wasn’t set up the proper way, or that area of the page is missing! When this transpires, examine the page to determine the issue.
- Add as many Inclusion Filters as you wish, but as soon as an Inclusion Filter matches, we will stop all further Inclusion Filter matching.
- Use a combination of Exclusion and Inclusion Filters for extreme filtering.
Selector Ignores: Filter Out Noisy HTML Tags or Tag Attributes Such as Classes, Styles, IDs
Selector Ignores and Selector Attribute Ignores are advanced features for refining how to perform HTML change comparisons. They are only available when you select “HTML change” as the change detection strategy (under the Detect tab of Session Settings).
At core, these filters tell Fluxguard to remove specific tags or attributes of tags. These attributes can be things like classes, IDs, inline styles, or any other item that might be included in a tag. Why would you need this? Nowadays, many attributes change each time you load a page. For example, class attributes may have a semi-dynamic value based on CMS generation. Or inline styles may change to reflect an ongoing animation. Selector Attribute Ignores remove these elements prior to comparison. Selector Ignores remove the entire tag from consideration when determining if a change has occurred.
Unlike Exclusion and Inclusion Filters, described above, Selector Ignores will not affect the DOM before Fluxguard’s saving; instead, they will be utilized when performing an HTML comparison.
This is beneficial for capturing and preserving an area of the page – say, a footer – without alterations to this area triggering a new version when doing an HTML comparison. The difference between this and the Exclusion Filters is subtle.
By default, we apply Selector Ignores on all inline script and style tags. In these cases, it is best not to remove these key areas of the page prior to rendering: if we had, the site might not load without its Javascript and associated styles. Rather, changes in these areas need not be considered when creating an HTML comparison. And that’s what transpires. This description is useful regarding Selector Ignores.
Selector Attribute Ignores remove any attribute from a selector. For instance, if a pesky class on every div always changes, you can instruct Fluxguard to strip these attributes. They won’t be expunged at the time the version is captured (after all, they may be necessary for style application). Instead, like Selector Ignores, it only operates when doing an HTML comparison.
Filters Best Practices
- Add commonsense filters at the account level to reduce false-positives.
- Use as few filters as possible. Adding more filters can create brittleness. Sites change, and you can’t rely on them to maintain their structure. As such, each filter adds some ongoing maintenance.
- At first, don’t set up filters. Wait until false-positives necessitate them.
- Consider adjusting the change detection strategy. HTML comparisons will often trigger far more false-positives than text comparisons and therefore require more filters. Can you swap to another change detection strategy to meet your goals and reduce the need for filters?
- Avoid complex hierarchical selectors. If your selector has multiple nests, such as
div > div > div > span > .myAreait’s brittle. Why? Because any change in the scaffolding of the page might render the selector inoperable. - Manual filter setup can beat our Visual Selector. Visual Selector tries to locate the minimal selector for the chosen area. However, if you’re savvy with DOM setup, you might find a more appropriate, less verbose selector.
- More than 5 Exclusion Filters? That’s too many. Swap to a smaller set of Inclusion Filters instead.
- Use Network Blocks, Transforms, and other techniques as effective alternatives to minimize false-positives.
- Weigh the pros and cons of where you set up filters. It can be done at the Page, Site, or Account levels. Account-wide or Site-wide filters are powerful; but may interfer with the successful monitoring of unique pages.
- Favor broad filters over multiple precise filters. For example, exclude an entire sidebar versus one or two links in the sidebar. Why? Because the placement of those links is more likely to change than the placement of the sidebar itself. Moreover, a single filter reduces the maintenance burden over multiple filters.
- Don’t overlap filters.
- Remove unused filters.
- Induce Fluxguard to crawl after each filter set up. Why? Because Fluxguard will scan the page and return a difference with the filtered area removed at once. This ensures things have been set up as they should.