Repository navigation
FAQ
- What is the relationship between Google Tag Manager and DAP?
- How do we send custom events to DAP?
- Does DAP provide a Subresource Integrity hash?
If you have a tag manager 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 uses additional Google Marketing Platform products, including your own, separate Google Analytics accounts, 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. Or rather, you kind of can, but it won't work the way you want it to and you shouldn't do so. For an explanation, go here.
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.
Custom event tracking is done through the gas4() JavaScript function, which the DAP code exposes after it loads. All calls follow this structure:
gas4('event_name', { key: 'value' });DAP provides a library of predefined events for common interactions — including form steps, file downloads, video progress, navigation clicks, and more. For example, to track a form submission:
gas4('form_submit', {
'form_name': 'Contact Us',
'form_id': 'contact-form',
'form_destination': '/thank-you'
});If none of the predefined events fit your use case, use the catch-all dap_event event:
gas4('dap_event', {
'link_text': 'Download Report',
'link_url': '/reports/annual-2024.pdf'
});For the full list of predefined events and their parameters, see DAP Custom Event Tracking.
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.