Yes! You can selectively manage and control which domains you allow to capture data to FullStory, preventing things like test or staging instances from generating sessions. No need to modify or bifurcate your code, simply click a switch to enable or disable a domain or subdomain.
Navigate to Settings > Data Capture and Privacy to add excluded or included domains. We'll start with a high level screenshot and then dive into individual areas and examples.
Configuring domain allowlisting for WebViews
If your application makes use of WebViews, you must explicitly allow any domain you wish to capture within a WebView. For security and privacy reasons, you should only allow domains which are under your control. Wildcards and subdomains are supported using the same scheme as Web domain settings. The key difference between the Web and Mobile settings is that while allowing domains is optional on Web, it is mandatory on Mobile if you wish to capture content within WebViews.
Adding individual domains
Click the "Add domain" button to add a new domain to the list.
All other domains
The "All other domains" toggle does the following:
- When ON, every individual domain where data capture is OFF is effectively blocklisted.
- When OFF, every individual domain where data capture is ON is effectively allowlisted.
Wildcards (*)
You can specify wildcards (*) at any subdomain level which will match any text at that particular domain level.
Wildcards (*) and subdomains
Keep in mind that wildcards only match at the specific subdomain level, not all subdomain levels. Let's look at a few different examples.
Example 1
In this example, immediate subdomains of example.com will be captured, but the "naked" example.com will be blocked. Visits to "www.example.com" will be captured, as this satisfies the subdomain wildcard.
| Domain | Is capturing data? |
| example.com | No |
| app.example.com | Yes |
| www.example.com | Yes |
| account.app.example.com | No |
Example 2
In this example, both the top "naked" domain matches and all immediate subdomains match. Any further levels of subdomains will not match.
| Domain | Is capturing data? |
| example.com | Yes |
| app.example.com | Yes |
| www.example.com | Yes |
| account.app.example.com | No |
Example 3
In this example, the top level "naked" domain, the immediate subdomain www.example.com, and all second level subdomains will match. Any further levels of subdomains will not match.
| Domain | Is capturing data? |
| example.com | Yes |
| app.example.com | No |
| www.example.com | Yes |
| account.app.example.com | Yes |
Evaluation order
The exclusions are evaluated in order, so if multiple blocking rules could potentially apply to a domain, the first rule that matches will win out.
For example, take app.example.com and the following exclusion rules.
In the above example, app.example.com will be captured because it matches app.example.com, this first rule, which has data capture set to On.
In the above example, the order of the exclusions is reversed from the previous example. In this example, app.example.com will be blocked because it matches app.example.com, the first rule, which has data capture set to Off.
Other types of exclusions
For a complete list of all ways to block data capture, see Will I be able to block specific sessions from being captured?