FAQ

Frequently Asked Questions

• What is the relationship between Google Tag Manager and DAP?
• How do we send custom events to DAP?
• What is DAP's Google Measurement ID?
• Does DAP provide a Subresource Integrity hash?

What is the relationship between Google Tag Manager and DAP?

If you have Google Tag Manager (GTM) on your site, you can use it to deploy the DAP code to your site. (For instructions on how to do so, see the DAP Quick Technical Guide.) That is the extent of the relationship.

You don't need a tag manager to install DAP. The easiest way to install DAP is to insert a one-line script tag in your site code. The only reason to install DAP with a tag manager is if your site has its own separate Google Analytics account or uses additional Google Marketing Platform products, and you already have a tag manager installed to manage those.

You cannot use your own tag manager, if you have one, to update which events you send to DAP.

You cannot use DAP's tag manager to update which events you send to DAP, because DAP does not use a tag manager. DAP's functionality is exactly that which is defined by the DAP script. The functionality only changes when we release a new version of the DAP script.

How do we send custom events to DAP?

Generally speaking, you can't.

DAP is not designed to support the free addition of custom events by our agency customers. DAP has its own schema of events, which are designed to be broadly applicable across the federal government. The DAP team adds custom dimensions and metrics to the DAP properties to support the tracking of these events and builds custom reports to display these events. The schema of DAP events consists of:

• GA4 automatically collected events
• Some GA4 enhanced measurement events, which are collected automatically (page views, outbound clicks, site search, video_start, video_progress, and video_complete, file_download)
• Some GA4 recommended events, which are collected automatically (share)
• CLS, INP and LCP events for Core Web Vitals tracking
• The list of events defined by the gas4() function

The gas4() function does offer the catch-all dap_event event, which allows you to send a generic event to DAP with arbitrary parameters. However, unlike a true custom event, you cannot control the name of the event and you will not be able to define new custom dimensions and metrics to capture additional parameters.

// 'Event name' dimension will be 'dap_event'
// 'link_text' parameter will populate the 'Link Text' dimension because DAP has defined it as a custom dimension
// 'link_color' parameter will not be available through the Google Analytics UI because DAP has not defined it as a custom dimension
gas4('dap_event', {
  'link_text': 'Download Report',
  'link_color':  'green'
});

If you want to track an event that is not currently in the DAP schema, your best option is to track it in a separate Google Analytics property that you manage yourself. The DAP script can live side-by-side with other gtag or GTM scripts on your site.

If the new event you want to track could be considered 'broadly applicable across the federal government', you are welcome to suggest it to the DAP team, via our issue tracker or by sending email to dap@gsa.gov.

What is DAP's Google Measurement ID?

People ask us this when they want to add DAP to a site that is built with a CMS or a low-code website builder. They might be trying to fill out a form in their site-building tool and the form has a field asking for a Measurement ID. The instructions provided by the DAP team for installing DAP require adding a script tag to your site's code. It may not be clear how to do that if you are using a site-building tool.

We're not going to print the DAP Measurement ID here but it's not hard to find. Measurement IDs, by their nature, are not secret. And, if you do copy our Measurement ID into your site-building tool form, you will probably start seeing traffic from your site in DAP and assume everything is working correctly.

But please don't do that. Instead, load the DAP code and let it mediate data sent to the DAP analytics property. You may need to talk to a technical person who oversees your CMS or site-building tool to get this done. If you talk to them, you may find (as we have before) that they have already added DAP to the template for your site, in which case it is automatically installed on every page. If not, they will know how to do so.

Reasons you should be using the DAP script:

1. The DAP script redacts PII from the data sent to DAP. If you send data directly to the DAP property without using the DAP script, you risk sending personally identifiable information (PII), which is a violation of our data collection policy and a risk to our status as a FISMA Low system. Also, any data sent to DAP may automatically be published to our public site at analytics.usa.gov. You don't want to be responsible for PII appearing on a public government website.
2. The DAP script adds a number of custom parameters to events, which are used in DAP's custom reports and for mapping events to the correct sub-property. If you send data directly to the DAP property without using the DAP script, your data will lack these parameters and may not show up in reports or even in the correct sub-property.
3. The DAP script adds automated tracking for different types of events. If you send data directly to the DAP property without using the DAP script, you will miss out on this automated tracking.
4. The DAP script defines an extended set of events that can be triggered manually through the gas4() function. All of these events have corresponding custom dimensions defined in the DAP property and reporting for these events within the Google Analytics UI is guaranteed to work. If you send arbitrary events with arbitrary parameters directly to the DAP property, there is no such guarantee.

Does DAP provide a Subresource Integrity hash?

No. DAP does not publish Subresource Integrity (SRI) hashes for the centrally hosted script.

SRI hashes are tied to an exact byte-for-byte version of a file — if the file changes at all, a browser enforcing the hash will refuse to load the script. Because DAP pushes updates to the centrally hosted URL frequently (new features, bug fixes, GA4 enhancements), a fixed SRI hash would break your implementation every time DAP releases a new version.

The central hosting model is intentional: it allows the DAP team to deliver updates to all participating agencies seamlessly, without requiring each agency to redeploy. Locking to a specific hash would negate that benefit.

If your security policy requires SRI for third-party scripts, the alternative is to self-host the DAP code — but note that you would then be responsible for keeping your version of DAP up-to-date.