There is a time in implementation work where you inevitably run into the world of PII and data security. This is the case with a client of ours recently, and we’ve researched a solution which allows for versatile development library testing. We’ve taken the time to perform emulation to validate this method is applicable and decided to share it for the needs of anyone who can use it.
First, we’d like to share some references to thank some people.
- Thank you Pedro Monjo for your ‘enhanced security’ suggestion
- Thank you Jenn Kunz for your solid ‘Debugger’ reference
The following instructions are a catered step-by-step guide to making sure that the testing and development libraries can be accessible to UAT from the cloud, shortening time for change validation; while maintaining a whole ‘self-hosted’ library which can be accessed from the same server as the application, or from a separate secured instance with special access permissions built in.
This is a validated, supported, and tested method and this documentation will walk you through each step required to get a complete understanding of how this approach can be applied.
Step 1: Select a property to begin developing the library for the DTM container.
Step 2: Click the ‘Embed’ tab to access the library management view.
- This view is of our testing sandbox, but the same options should exist within DTM for users with admin/approve & publish rights.
Step 3: Set up the ‘Staging’ dynamic reference by using the ‘Akamai’ cloud hosting option within the options.
- If the gray switch on the top right is not showing a green (active) state, click the switch.
- Click the clipboard for the ‘Staging’ header code.
- Paste the script reference into the global <head> of your HTML template.
It is worth noting here that the library which is being created here will ALSO exist in a production format. The ONLY use we will have for this is building against the staging version for testing and approval. However, when a library is approved and published, it will be available both on ‘Akamai’ and accessible to the public if they can reverse the keys to determine how the relationship between the library works. This CAN BE EXPLOITED.
DO NOT INCLUDE PASSWORDS/KEYS TO DATABASE FUNCTIONS OR MAKE PII AVAILABLE TO DTM/SATELLITE OBJECTS.
*(end paranoid data security rant)
Step 4: Copy the ‘Header Code’ STAGING script library reference to your clipboard.
- This will allow you to regularly and efficiently review changes to DTM rules and code without affecting production OR requiring an update to the local PRODUCTION library which will be managed on your server.
Step 5: Paste the library reference from your clipboard into the STAGING global template <head> portion of the HTML.
- This creates a static REMOTE reference to the staging changes which are functional before publication.
- Any change which is made within DTM will be immediately reflected within the Akamai remote DTM assets.
- NOTE: The reference library for the remote DTM library will always originate at the host: assets.adobedtm.com
Section II – Preparing the ‘Library Download’ Method for Secure Local DTM on PRODUCTION ENV
Step 1: Configure the settings for your staging and production paths.
- Enable the library by turning the switch to the right on.
- The PATH needs to include the server folder destination of the library to be stored.
- ex: http://www.yourserver.com/dtm/
- ex: https://secure.yourserver.com/scripts/
- Once the path is determined for both ports (80 and 443[SSL]), save the library settings.
- The PRODUCTION library can be downloaded when the first version is approved and published, until then, the link will return no file.
NOTE: It may be advisable to speak to the application developers/engineers prior to submitting this configuration. Applications dealing with health, finance, or privacy typically rely on strict governance for how/where a client-side script can be referenced. The options here are simply for illustration and may have no relationship whatsoever to the architecture for script reference within our application.
Step 2: Now that the ‘Download’ libraries are configured, DTM will produce a link to the ZIP package to bring down.
- Click the clipboard beneath the ‘Production URL’ window.
- Paste the link into your browser.
Step 3: When the link is executed, you will be prompted with a dialog which will ask you to open or save the library.
- ZIP files are currently recognized by the Windows/Mac operating systems and can be navigated.
- NOTE: You WILL NOT be able to download the ‘Production’ ZIP package without first publishing a version.
Step 4: The DTM UI produces predetermined script references to the production library for use in the application.
- Click the clipboard to add the ‘Production Embed Code’ to your clipboard.
- Paste the link in the global ‘<head>’ of your application HTML template
- This should be the ONLY time this is necessary if its set in the right place within the application
Step 5: Add the script snippet to reference the _satellite object within the <body> of the HTML template.
- The code should be placed as close to the </body> tag as is possible.
- Once established, we do not have to edit or modify the reference libraries or the _satellite object.
- This reference is static to the location determined to be compliant with your JS governance standard
Section III – Set Up Initial Instances of STAGING and PRODUCTION Tests for a ‘Hello World’
Reference (c/o Jenn Kunz) : Setting up for debugging.
|_satellite.settings.isStaging||Determines current DTM library|
|localStorage.setItem(‘sdsat_stagingLibrary’, true)||Uses staging library (after page reload)|
|localStorage.setItem(‘sdsat_stagingLibrary’, false)||Goes back to default library (after page reload)|
|_satellite.buildDate||Let’s you know what the publish date of the library is.|
Part I: Staging Library Validation Test
In order to properly see that changes are being accepted by the remote library, we typically create a series of rules based on static assignment of a ‘Page Load Rule’ using our own data object. In the snippet below, you can see we’ve added the DDC object and assigned a ‘child’ object into the rules. In this instance, we simply identify this Page Load as being the PageType: ‘home’. This is NOT REQUIRED and may vary. This is simply to show the relationship between the on page data layer, and the rules listening in DTM.
- We use a standardized version of our data objects to help prepare implementations for scale.
- The goal here is to create a practice where you can differentiate how tags should react on specific content.
- If defined by a backend server application, these can be the easiest method to install reliable tag management.
(There is a published W3C standard on the use of Digital Data Layers.)
Step 2: Create a DTM Data Element which will read and recognize the object reference: DDC.Rules.PageType
- Name the Data Element
- Make it simple and clear
- Use conventions to make this more functional.
- Later you can reference these in code for scaling your implementation
- You can also reference the value by checking or using _satellite.getDataElement(“PageType”)
Step 3: Create a Page Load Rule that reads from the Data Element created in Step 2.
- Name the rule, make it simple and logical.
- In the ‘Rule Conditions’ choose the criteria for a pivot on the Data Element Value
- Identify the PageType Data Element and input the string value for our ‘home’ page.
- Our goal is simply to see that the code is operating logically as is needed.
- Anonymous functions help to limit scope of variables from exposure to the window object and prevent collision.
- Save the code and begin the approval process.
Step 5: Test code in STAGING ENV prior to approval.
- Open your browser and point to your staging location.
- Enable developer tools and activate a window for a developer console – (most browsers recognize F12)
- Run the command: _satellite.setDebug(true) – this will enable verbose reporting for DTM in the console.
- Load your page and observe functional logic of the DTM system operate on the page.
Part II: Approval and Publication for PRODUCTION Library Download
Now that the STAGING test has shown success for acceptance of the changes without issues, we can produce an updated library by stepping through the approval and publication process.
Step 1: Review each of the changes and notes available.
- The DTM UI provides a side by side review of each change.
- In this example, differences are highlighted with the colors blue and green.
- If the change has been tested, and there’s no additional edit necessary, approve the change.
Step 2: Review Approved Publish Queue
- This is useful for large scale implementations working with AGILE teams with multiple approvers/publishers.
- Once all changes have been tested and approved, and are rendered to the Publish Queue, execute the dialog
Step 3: Return to ‘Embed’ Tab to Download the PRODUCTION Library package.
- Scroll down to the Download URLs window.
Step 4: Download and Install the contents of the ZIP package in the designated folder for the library.
- Overwrite the old production library.
- Notice the ‘scripts’ folder. This includes all the reference script which are bound to rules within the container.
- The library itself is a separate entity from each of the s-code contents (Adobe) and any third-party scripts.
Step 5: Now test the production server front to ensure the changes have been accepted and the library runs seamlessly.
- Remember to set the ‘debug’ dialog in the developer console.
- Render the page on the server.
The DTM Library/Container is now available on local PRODUCTION server with the approved and published changes which were validated and tested using the STAGING library. If the UAT->PRODUCTION relationship DOES NOT have parity (meaning it is not an exact copy) there can be situations where code dependencies may affect how this process works.