Overview
Creating an Audit is simply configuring instructions for ObservePoint to follow. It is a process of automating what is traditionally a very tedious manual process of looking at each page and evaluating if all the tags are firing with all the correct variables implemented and setting all the correct values. Do this for hundreds of pages and it quickly becomes apparent that an automated Audit is going to be more reliable and faster than any traditional, manual approach.
Setting up an Audit does not require code to be implemented on a page because when an Audit runs, the ObservePoint servers access pages on your site in a browser window. The ObservePoint tool sits inside the browser, visiting links and monitoring all the tag requests passing data to their collection servers as the pages load.
Audit Setup
There are several fields that are required here to create an Audit. Fill out the following fields:
Audit Name (required)
A best practice is to use short names and use labels to organize your Audits. A reminder will pop up encouraging a short name and the use of labels if your name exceeds 40 characters.
Folder (required)
You can choose a folder or create a new one here. To create a new one, click "create folder" and type in a name. The new folder will show up in the Dara Sources screen and will be available on the folder list inside the Audit setup screen.
Starting URL (required)
The Starting URL field can hold one or more URLs to visit during the Audit. These pages will be visited first in the Audit. If the Audit has not reached the page limit, it will use the include and exclude filters (see below) to guide it to additional pages. Use this field to load pages that may not be accessible from links on your site, such as landing pages.
How many pages should be Audited? (required)
The page limit controls how many pages are scanned during the Audit. The default is 100 pages. It is recommended that you start with a small Audit (10-25 pages) the first few times you create an Audit so you can get the results back quickly to help you evaluate if you need to make any changes. You can always come back into the Audit, change the number of pages, and re-run it. A best practice is to Audit up to 10,000 pages; usually fewer. Most Audits accessing more pages than this don't give additional insight, but show more of the same problems or reveal edge cases not worth spending the time fixing. If you find you have a very clean site after auditing 10,000 pages, it would likely be more useful to check out the integrity of your rules than expand to more pages.
Leaving this field blank causes the Audit to default to 50 pages when it is saved.
How fast should the Audit go? (required)
There are 4 different speeds you can set for your Audit to run. If you need the Audit to run slower, you will want to select 1 browser or stick with the default setting of 10 simultaneous browsers. If you want to run the Audit at a faster setting, you can set it to run at 20 or 50 simultaneous browsers for faster completion.
- 1 Browser
- 5 Simultaneous browsers
- 10 Simultaneous browsers (default)
- 20 Simultaneous browsers - You can use this setting for a faster Audit experience if you allowlisted ObservePoint IP addresses
- 50 Simultaneous browsers - You can use this setting for a faster Audit experience if you allowlisted ObservePoint IP addresses
Note:
You will want to make sure that the ObservePoint IP addresses have been allowlisted if you are running Audits at 20 or 50 simultaneous browsers. Failure to do so may result in a failed Audit that only reports 429 Errors (Too many requests) for every page scanned. 429 Errors occur when a user has sent too many requests in a given amount of time. Websites will often trigger this error to prevent a DDOS attack (Distributed Denial-of-Service).
In the 'Starting URL' section, if duplicate URLs are specified, the Audit will scan each unique page only once. Subsequent occurrences of the same URL will be disregarded to optimize the scanning process. The Audit will continue scanning additional pages until reaching the specified limit.
Audit notifications (optional)
Type in as many email addresses as needed to receive alerts when the Audit completes.
This is all you need to set up an Audit; click Save Audit to begin running it automatically.
Additional Setup Options (optional)
Use the additional setup options to configure other settings that help control an Audit. Click the Additional Setup Options at the bottom of the Audit Setup window to access its additional settings.
Labels
Create a label to organize your Audits and other items on the platform. You can use these to group other items such as Journeys or additional Audits.
Location
The location determines what IP address the servers use to access pages on your site. Changing this is useful if you have geo-based content or restrictions on your site--for example, a retail site for mobile phones in England may not show the same content to browsers from North America. By default, the location is set to Oregon, United States (Pacific Time Zone). Most Audits do not need to run from a different location.
User Agent
User agents tell the server what browser and operating system the visitor is using to visit the site. You can override the default user agent string to see if there are any significant changes in the way pages are served.
Browser Width & Height
You can change the browser width and height to accommodate responsive testing during an Audit. See our Common Device Browser Width help document for screen size recommendations.
Sections of the website that should be included/excluded
You can specify areas of your website that should be included/excluded in the Audit by using RegEx. The app will insert a default RegEx statement when you enter the starting URL.
Audit Same URLs
Enabling this ensure that the Audit will crawl the same urls as the previous run. This effectively eliminates any randomness in the crawl and is used to establish a baseline for more direct comparison in future runs.
De-duplicate URLs
The Audit will only scan one instance of each page if query strings are used.
Blackout Periods
Blackout Periods prevent an Audit or Journey from starting during that time frame. These periods are useful for preventing scans of the site when you know the site will return bad data, such as when the site is undergoing maintenance or updates.
Runs that would start during the blackout period are skipped. If an Audit is set to run daily during the blackout, the Audit will never run because the highest frequency for an Audit is daily. The exception to this is if the Audits are backed up and the start time is delayed due to too many Audits in the queue. In that case, if the Audit start time is pushed until after the blackout, it will run.
Tag Blocking
Select specific tags or categories of tags in ObservePoint's tag database to block and effectively disable when the Audit runs. For example, block a Tag Management System tag to see only hard coded tags. Also, consider blocking AB testing tags to ensure more consistent site experience when testing.
File Substitutions
File Substitutions allow you to test new files, scripts, and libraries on pages in your production environment before coding the new one onto the page. See our File Substitutions help document for more information.
VPN
If enabled, Virtual Private Networks will show up as a toggle button and allow outside access to secure content. The VPN settings must be configured by an administrator and are enabled by contract (see Scanning Secure Content).
Privacy Settings
Send GPC Signal
Sending GPC Signal is a critical part of validating the various opt-in/opt-out user states required to ensure privacy compliance. To enable this setting on your Audit simply toggle on Send GPC Signal. Report data reflects tags, cookies, and other technologies loading while in this state.
More information here.
CMP Accept All / Reject All
Enable this feature for testing the important user states of “Accept All” or “Reject All”. This feature needs to be configured for each domain that is being visited in an Audit and is managed in the Pre-Audit Actions tab, this should be set as your first action. This action will navigate to the starting URL you provided, clear cookies, and then execute the action you created.
More information here.
Block 3rd Party Cookies
Enable this setting to test how your website will respond when 3rd-party cookies are blocked from loading. This will allow you to mimic the behavior of browsers that do this today, so you can be confident in your end-user experience.
Standards Tab
The Standards tab lets you assign Consent Categories for privacy testing and pre-built rules or create new ones on-the-fly. Rules can look for tags, accounts, and variables on a page. In addition, you can filter which pages a rule runs on by URL, tags found, status codes, and variables.
See Applying Rules to Audits and Journeys for setup instructions.
Pre-Audit Actions
Pre-Audit Actions allows you to set up a login to access secure content or define other parameters that need to be defined at the beginning of the Audit and carried through the session, such as setting a language or country cookie. Pre-Audit Actions are executed before the starting page(s). If you set up a login, you may also need to use the Exclude filter to prevent the Audit from executing any logout links.
To create a login, see Creating Journeys for instructions on setting up actions. Most likely you will either want to create an Action Set out of these steps or use an existing Action Set to add in your configured login process from another Journey or Audit.
On-Page Actions Tab
Actions are steps that can be taken during an Audit to interact with the page in the same way you might expect a user to. Actions can be limited to execute on every page or only on pages that meet specific URL patterns.
See Creating Journey for instructions on setting up actions.
Turn on Prevent Navigation so that the browser doesn't go to the destination page on an action that would:
Load another page, if doing so would interfere with the flow of the Audit (such as with an exit link)
Load another window or tab. Audits can only work in a single window or tab.
Load a binary file, such as a PDF document. Audits can only browse web documents, such as HTML files.
Here are some examples of when you may need to use an action in an Audit:
Confirm that a button can be clicked and that it passes analytics data as expected.
Verify that tags are firing as expected on all download links. If there is a downloads section of the site, set up a filter to only execute the download click on pages where downloads are available.
Click an exit link to be sure that the link is firing the expected analytics. Selecting Prevent Navigation will click the link and capture the analytics but not load the destination page.