Create an Audit


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 500 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
      • 10 Simultaneous browsers (default)
      • 20 Simultaneous browsers 
      • 50 Simultaneous browsers 

Note: You will want to make sure that the ObservePoint IP addresses have been whitelisted 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).

  • 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 together 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 a non-proxy in Oregon, United States (Pacific Time Zone). Most Audits do not need to run on a proxy.
  • Browser
    • ObservePoint uses Chrome or Chromium to crawl pages. Chrome is selected by default and is recommended for almost all Audits.  Chromium is an open-source browser and should be used in niche scenarios. 
      • Chromium is most commonly used to prevent videos from loading on the page. Chromium supports open-source codecs, whereas Chrome only supports licensed codecs. 
      • Chrome is selected by default   
  • 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
    • You can specify areas of your website that should be included in the Audit by using RegEx. The app will insert a default RegEx statement when you enter the starting URL.
  • 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 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.
  • File Substitutions (Formerly Remote File Mapping) 
    • File Substitutions allows 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 Accessing Content Through VPN).

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 Create or Edit a Web Journey 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 Create or Edit a Web 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.
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us