Developer Documentation
This page covers advanced topics for both site developers and Launch extension developers.
There are numerous settings that can be overwritten dynamically via data elements or have callbacks. This section covers these various scenarios and how your code should behave.
Acronym has made every effort to provide as much flexibility for developers to dynamically change things. Almost every setting allows for you to use a data element to set the value, or in the case of checkboxes, dynamically check or uncheck them. You may want to do this because you need to enable a certain feature or account based on the page's data layer, user's account type, etc.
Note: Your data element should return a boolean
true or false . We attempt to parse strings as well (if it is a literal "true"), but it is highly recommended to pass a boolean instead.We want to prevent an event from firing if the visitor has been identified as an internal employee. This information is passed in the data layer, as follows:
window.dataLayer = {
"account": {
"ID": "abc123",
"type": "internal"
},
// Other data layer properties...
};
We could then setup a few data elements within Launch to grab the account type, and if they are internal or not:
Data Element Name | Data Element Type | Data Element Value |
account_type | Core / JavaScript Variable | dataLayer.account.type |
account_type_internal | Core / Custom Code | return _satellite.getVar("account_type") === "internal"; |
Then, within the rule, we'd set the enabled checkbox for the account(s) to use the
account_type_internal data element:
The overlay to show the data element in use for the checkbox
There are a couple of places you can enter custom code that will be executed: custom configuration code, and event callbacks. Launch does basic checks to make sure there aren't any syntax errors, but beyond that no checks are made. If you're running into issues with building a library because of a minification error, please check your code in the settings mentioned above. Acronym has suggested an idea to improve the build error messages and would love to have your vote.
Your code will be wrapped in a
function() { } already, so no need to add this like you would with other tag managers, like Google Tag Manager. Additionally, the extension will wrap your code in a try { } catch() { } to ensure no errors stop the code execution on the page. Note: while return values are ignored currently, future versions of the gtag extension may support return values. Those specifications are unknown at this time, so you should refrain from returning any values now.
Launch allows for extension developers to share modules to other extensions. We've opted to share the load functionality so your extension can reference the
gtag function. The module will return the function after the relevant variables, functions, and accounts have been configured. Warning: This is currently considered an experimental feature within the gtag extension. If you plan on creating an extension that utilizes the shared extension, please reach out to [email protected] so Acronym can work with you to ensure success.
var gtag = turbine.getSharedModule('acronym-gtag', 'get-gtag');
You can then call the
gtag function like you would normally:gtag("set", {
"field1": "my field value",
"another_field": "some other value"
});
Last modified 4yr ago