Common Questions About the Digital Analytics Program
Subscribe for email updates on the Digital Analytics Program
Below are the questions we hear most often about the Digital Analytics Program (DAP). We've divided them into the following categories:
Data Access, Retention and Privacy
Customer Satisfaction Tool Implementation
Implementation
What tool is being used to collect the data?
We’re using Google Analytics Premium to collect and analyze the Web traffic data.
Does this tool have to go on all websites? Or just top-level domains?
In the Digital Strategy, OMB calls for agencies to implement performance and customer satisfaction measuring tools on all .gov websites. The government-wide code snippet is available to agencies to help them meet this requirement.
Will agencies need to obtain a “cookie waiver” to use the tool?
No. Since we are stripping out user IP addresses, agencies do NOT need any special permission, waivers, or privacy impact assessments.
The cookie used is considered Tier 2 (multi-session without PII). This tier encompasses any use of multi-session Web measurement and customization technologies when no PII is collected (including when the agency is unable to identify an individual as a result of its use of such technologies). See page 5 of OMB Memo M-10-22 (PDF, 102.75 KB, 9 pages, June 2010).
A privacy impact assessment and sign-off by the privacy official is not required until Tier 3.
Agencies should incorporate this information into their existing website privacy policy. For an example of the disclaimer language you can use, see HHS.gov or DHS.gov.
We don't currently use Google Analytics on our site. What should we do?
You don’t need your own Google Analytics code on your site for the government-wide analytics to work.
Can the government-wide code run with other Google Analytics code?
Yes. The government-wide analytics code is sensitive to the Google Analytics code you already have on your site and synchronizes itself with your existing Google Analytics code. The government-wide code is being collected into its own account so it does not interfere with your existing Google Analytics data.
Will the code affect other analytics code running on my site, such as WebTrends, WebTrends Live, SiteCatalyst or Urchin?
The code will not interfere at all with WebTrends, WebTrends Live, SiteCatalyst, and it synchronizes itself with Urchin.
If the government-wide tracking code suffers an error, will the code stop other code from running?
No. The code makes itself “secondary” to other code by safely exiting if it encounters any problems and allows other code to continue running.
If we already have premium GA implemented, and contractors supporting our tags add customizations, how will this affect us? Will it overwrite all of our current work?
The only issue is customizations that affect:
- Cookie timeout periods
- Use _setAllowHash
- Use _setDomain with a leading period
- Use the old Urchin tracking code
The current October 15, 2012, deployment is designed to insulate itself from and be unobtrusive to existing implementations. The government-wide tool looks at the existing cookies and adjusts its own configuration to match the existing GA code configuration. The only caveat is if your existing customizations changed cookie timeout periods. In these unusual cases, this code will write to the same cookies with the standard timeout periods.
What kind of testing was done to ensure that the code doesn't cause conflicts with other script-based code already in use?
Preliminary testing has been conducted to ensure that the government-wide code script does not conflict with other script-based code. However, it's impossible to test every possible scenario when the possibilities are unknown, especially with custom code already deployed on agency websites. To ensure that the government-wide code snippet does not conflict with the other existing script-based code, each implementation will be handled uniquely, driven by the agency Web infrastructure, existing code, etc.
Customization and Access
Who can use the tool?
The initial roll-out, scheduled for October 15, 2012, is limited to executive branch agencies of the U.S. federal government.
Can my agency use it at no cost?
Yes. There is no cost for federal government agencies to use this tool.
Is a Gmail or Google account the only way to access this data?
A Google account is required, but a Gmail email address is not—any email address can be used to create a Google account. You should sign up for the DAP using your work email address.
Data Access, Retention and Privacy
Does Google or GSA collect Personally Identifiable Information (PII)?
No. Personal information is information that personally identifies you, like name, email address, or other data which can be reasonably linked to such information. GSA does not track or collect any of this information using the DAP tool.
Every computer and device connected to the Internet is assigned a unique number known as an Internet protocol (IP) address. The code that we are using anonymizes IP addresses.
Will agencies have access to the data that is gathered from the government-wide code?
The Digital Analytics Program at GSA administers the government wide analytics account to help agencies meet metrics reporting requirements from OMB e-gov office.
Agency metrics points of contact will have access to agency-based metrics profiles that will include data for the individual websites managed by their agency.
As we are rolling out the code to agencies, we are focusing on ensuring that the data and reporting makes sense. This includes ensuring the code is delivering consistent data and creating dashboards and filters to make meaning out of this huge stream of data. GSA and OMB will have initial access to this data. We are working to get this done and available to agencies as soon as possible.
Are the metrics we collect available to Google's corporate advertising partners?
No. None of the federal government data tracked as part of the DAP will be shared with or available to Google’s corporate advertising partners.
Does Google or GSA ever store IP addresses?
IP anonymization/masking takes place as soon as data is received by Google Analytics and before any storage or takes place. At no time is the full IP address written to disk as all anonymization happens in memory nearly instantaneously after the request has been received. The full IP address is never written to disk when the anonymization flag is turned on as it is with GSA's account. This process was created to meet strict EU privacy requirements. Read more about IP Anonymization in Google Analytics.
What type of security measures/testing was done on the code that GSA is asking us to install?
GSA has done an IT security review of the federated-analytics.js. We conducted a security scan using WebInspect and also conducted on "eyes-on-code" or a line-by-line analysis to further research potential vulnerabilities. No significant issues were found. The minor ones that were identified have been sent to the vendor to be mitigated. Agencies can review our analysis and, in the context of their own infrastructure, follow their processes for securing applications in their infrastructure, adding applications to their Certification and Accreditation analysis, etc. Please contact DAP@gsa.gov to request a copy of our security report.
Does my agency need a TOS with Google to use the services provided under GSA's Digital Analytics Program?
GSA’s agreement with Google for the standard (free) version of Analytics is currently governed by an Addendum we negotiated to Google's Terms of Service (TOS). Our attorneys are working with Google to modify the Google Analytics Premium TOS agreement for federal use. This agreement is part of the contract between GSA and Google.
For agencies to view the Google Analytics Dashboard, you will need a Google account. Agencies that have YouTube, Google+, or are using Google Analytics already have a Google account. You can check with your Office of General Counsel or your TOS lead for further guidance.
Is a new privacy notice needed on my agency website if we add Google Analytics Premium?
We recommend adding the following language:
This website uses Google Analytics Premium. Please refer to the following policies on Google’s website for more information:
See this notice on the HowTo.gov Site Policies page.
Reporting
With many people coming in via dynamic IP services, how can you tell the difference between new and returned visitors?
Because of cookie deletion, unique, and new vs. returning visitors metrics can never be 100% accurate, regardless of whether GA or any other cookie-based Web analytics tool is used. If a visitor deletes their browser cookies, he or she will be counted as a new visitor.
Where can I find benchmarks for things like bounce rate, returning users, unique visitors, etc.?
There are several reliable sources of competitive/benchmark data, including commercial providers like Compete, Hitwise, ComScore, and Nielsen, as well as free tools like Google Trends. Each source/solution has a specific methodology to measure Internet traffic, so their findings may not always be consistent.
There are also a variety of Web analytics blogs that publish the Google Analytics Monthly Benchmark Report, a report that Google Analytics users receive by email on a monthly basis if they opt-in to share data anonymously with Google. For example, Google Analytics Benchmark Averages for Bounce Rate are as follows:
- 40-60% Content websites
- 30-50% Lead generation sites
- 70-98% Blogs
- 20-40% Retail sites
- 10-30% Service sites
- 70-90% Landing pages
Ultimately, while there are many sources for benchmarking information, your Web data interpretation and analysis should be based on the website/department/agency goals that make sense within your organization. Industry-based benchmark percentages only make sense to measure against when they are in the proper context, and align to your specific website, the mission of your site, and other factors specific to YOUR needs and goals.
How are bounce rates measured?
Bounce rates are calculated as the percentage of single-page visits to total visits. The “Bounce Rate” calculation will include a visit with a single page view followed by 1) closing the browser, 2) browser expiration after 30 minutes due to inactivity, directly typing in a different site’s URL into the browser’s navigation bar, or clicking on the browser “back” button.
The code will track off-site/outbound links as part of a visit, so a visit will not be considered a Bounce if the user clicks on any of the external links on your website page.
Are clicks tied to bounce rate? Is it the % of people who looked at one page and left without clicking?
Most common Bounce Rate scenarios:
- Clicks the back button (most common)
- Closes the browser (window/tab)
- Types a new URL
- Does nothing (session times out after 30 min)
Bounce rate is the % of visits that only had one page view. A click is tied to a specific action, like a new page, search box, an offsite/outbound/external link, a sign-up form etc., so, it is considered to be interaction/engagement with that page, and hence, would not be considered a bounce.
Customer Satisfaction Tool Implementation
Is there a free survey tool to use on public sites to capture the Customer Satisfaction data?
GSA has negotiated federal friendly Terms of Service with the following tools that can be used to collect Customer Satisfaction data:
Take a look at the process for signing the terms and using the tool and talk to your agency POC.
Is there exact wording for the Customer Satisfaction questions? Should it be exactly what's outlined on HowTo.gov/digital-metrics?
The Digital Metrics guidance provides suggested wording for gathering the four core customer satisfaction measures. This wording is based on research and is a common way that these measures are collected. You do not need to use this exact wording. The requirement is to collect and report on four measures and to ensure they're collected in a structured, machine processable way. See the guidance on customer satisfaction metrics.
How should we report the Customer Satisfaction Metrics?
Plan to report the data on your /digitalstrategy pages. The OMB guidance identifies these reporting requirements: Agencies should report progress publicly via their /digitalstrategy pages. To meet the requirements of Milestone #8.2, agencies should post the following required reporting fields on their /digitalstrategy page by January 22nd, 2013:
For Customer Satisfaction:
- Describe the tool(s) utilized, progress toward implementing on all public-facing .gov websites (pursuant to privacy and security laws and regulations), and approach to finishing implementation on all .gov websites (if not yet complete).
- Provide links to any places where this customer satisfaction data is being shared publicly.
How should we structure the data? Open ended? Numeric scale?
The data you report should be structured and quantitative. Don't report the open ended answers to questions. The requirement is to collect and report on four measures and to ensure they're collected in a structured, machine processable way. See the guidance on customer satisfaction metrics.
How frequently should we be prompting for a survey?
Survey frequency should be determined by your survey goals, how frequently you plan to act on the data you collect, and your resources for running the survey. Most commercial survey tools will have a built-in methodology for this, and you can work with the vendor to adjust as needed, to ensure you get a sufficient response rate to ensure reliable data. HowTo.gov provides comprehensive guidance on conducting Online Surveys.
Comments
We do not screen comments before they post. Please review our commenting policy.
Content Lead:
Marina Fox
Page Reviewed/Updated: January 10, 2013
