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.

Testing scenarios contain specific settings and conditions to ensure an application (in this case, a set of web pages) performs as expected. There are several fields that are required here to create an Audit. Fill out the following fields:

A best practice is using short names and labels to organize your Audits.

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.

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

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.

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 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.

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

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 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.

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).

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.

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.

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.

Type in as many email addresses as needed to receive alerts when the Audit completes.

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.

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.

The Audit will only scan one instance of each page if query strings are used.

Enabling this ensures 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.

You can run the Audit only once or you can set a schedule for the Audit to run. Options are ranging from Daily, Weekly, Biweekly, Monthly, Quarterly, to Semiannually or Yearly. For custom schedules and other advanced scheduling options refer to the Audit & Journey Scheduling help document.

Blackout Windows 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 window 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.

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.

This new section lists out any Email Inboxes associated with this audit test scenario. Audit test scenarios can be assigned to Email Inboxes from the Inbox Library.

This is all you need to set up an Audit; click Save Audit to begin running it automatically.

The Standards tab lets you assign Alerts, 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 Tab 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.

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:

Here are some examples of when you may need to use an action in an Audit: