Use tag environments and embed codes

In this video, we’ll explain how to use environments for a Web property in tags, and the types of environments that are available. While the function of environments is basically the same across all property types, there are some differences in how they’re implemented between Web, mobile, and event forwarding properties, and for this video we’ll just be focusing on Web. For Web properties, an environment is essentially a container which houses a working version of a library, allowing it to be hosted and executed on different URLs. Whenever you make a new property, three environments are automatically added – development, staging, and production. These three environments correspond to the typical environments used for websites in standard application lifecycle strategies. Each environment provides an automatically generated code snippet that you copy and paste onto the web pages that you want to install it on, making it easy to implement different versions of your build on different stages of your site’s lifecycle. Let’s quickly go over how this looks in practice. In this example flow, a developer works on the development environment to make changes to the tags implementation, which can include alterations to rules, data elements, extensions, and so on. When they’ve completed their work, they send those changes to the staging environment for QA and other teams to review. Once QA is done and changes have been approved, the code is then published to the production environment, which is deployed on the public-facing version of the website. The benefit of this is that you can safely add new features and make implementation changes available to the right users at the right time. There is also no limit to the number of development environments you can create, which is very useful if you have multiple developers working on different projects at the same time for the same website. Before we show you how to start interacting with environments, there are two important definitions that we need to understand – libraries and embed codes. A library is a set of static files that represent your build code. In other words, a library is the collection of rules, data elements, extensions, and other configurations that make up a tagging implementation. Each tag property can contain multiple libraries, and each library must be attached to a specific environment before it can be built for testing and deployment. An embed code is a code snippet that’s attached to a specific environment and is automatically generated when that environment is created. By placing this code on a web page, that page will have access to the library file that’s currently active on the corresponding environment. So now, let’s see how we can manage environments within the tags interface. Once you’ve selected the property you want to work with, click Environments in the left navigation. Here we see the three environments that were automatically created for us when we first made this property. While having one development environment can work fine, in a typical tags implementation there may be several developers or teams working on separate tasks at the same time. In these cases, it’s useful for each team or individual developer to have their own development environment. This allows them to work independently without worrying about conflicting with code changes being made by other devs at the same time. Development environments are intended to help your teams iterate through changes to your tag libraries in order to ensure that the business logic behaves as expected. So, let’s walk through the process of creating a new development environment to see what that looks like. Click Add Environment on the top right, and here we can see that we can only create new development environments. This is because while your organization can have many development environments, you can only have one staging environment and one production environment for the QA process. Since those environments have already been created, the options to create new ones have been grayed out. So, we’ll select Development, and from here we can give our environment a name. In this case, I’ll call this one luma-dev-team-alpha, since I wanted to be clear which development team this environment is intended for. The next step is to pick a host. We highly recommend that you use Manage by Adobe for development environments specifically, since this allows you to check your code on the website immediately whenever you update a build, with less maintenance overhead compared to the self-hosting option. We also have the option to enable the Archive setting for this environment. If enabled, this environment will output your build in a compressed archive format, rather than a deployable set of files. We’ll leave that toggle at the default setting for now, and just click Save here in the upper right. Once our environment is created, it’s immediately assigned a unique, automatically generated embed code. You can see the HTML script tag here, and that it contains a source attribute that references the path to a JavaScript file. This file is the library build that’s currently assigned to this environment, and when we place this script on the pages of our website, the rules that we set up in that library will execute on those pages. If you do business in China, Adobe offers a premium CDN feature that allows you to use delivery networks physically located within China, in order to comply with local content distribution regulations. If your organization has purchased this feature, you’ll see two embed codes here, one being the standard code, and the other being the code for the China CDN specifically. If your company doesn’t have this feature and would like to take advantage of it, please get in touch with your Adobe rep for more information. Now, going back to the standard embed code, notice at the end of the code that it includes the word Development. This is a really good way to double-check that you’re placing the correct embed code in the appropriate version of your website. If this was a staging environment, it would say Stage at the end of the code, and a production environment won’t have anything appended at all. So, in practice, there’s generally two things that we need to decide when it comes to an environment’s embed code. What web pages it needs to be installed on, and how the library should be loaded. When it comes to the where, the embed code should be placed within the head section of your web page’s HTML structure. If your website uses a template page, as is common, you can choose to put the embed code in the header of the template instead. So the script is replicated on every page of the website. You can see I pasted the code for the development environment here, and this would work fine if we’re just testing this out in a development sandbox, but in a real implementation you probably see something more like this. Instead of just hard-coding a single embed code for our template, we’re using some simple conditional logic to add the code dynamically. This will fetch the current web environment being used from a global variable, and add the correct embed code for that environment to the header before the page loads. We also strongly recommend that you include a data layer on your site that contains all the attributes needed to populate variables in Analytics, Target, Experience Platform, and other products. We’ve stripped down this example data layer here to something very simple just for demonstration purposes, as a real data layer would typically have a lot more information. Note though that we’ve added it above the script that outputs the embed code, which is preferable. You can still choose to declare the data layer after the embed code, as this can be useful for analytics implementations, but if you’re using a personalization application like Target, we recommend defining it above the embed code to maximize its effectiveness for those use cases. And while we’re talking about personalization, for Target implementations you’ll also want to hard-code a pre-hiding snippet before the embed code in order to manage content flicker. You can find examples of these snippets for different implementation methods within the Target documentation, which includes this one for tags. However, this is only necessary when you are loading the library asynchronously, which serves as a nice segue into our next decision. Now that we know where we want our libraries loaded, we also need to choose how they’re loaded. More specifically, for any embed code we need to choose whether we want the library to load on our website synchronously or asynchronously, using this toggle here on the upper left. You can see that when we switch between asynchronous and synchronous, the format of the embed code changes. Asynchronous embed codes will include the term async near the end of the code, and synchronous codes will include a footer tag in addition to the standard header tag. But with all that being said, let’s actually talk about what this setting does and why you would want to choose one option over the other depending on your implementation needs. The asynchronous setting is best used when the page rendering is independent of other tagging processes that are going on. This is usually more efficient because once one process starts, the next process doesn’t need to wait for the previous one to finish, and it can also immediately begin. In other words, the code executes in parallel. Because it is the faster, more performative option in most cases, Adobe recommends using the asynchronous method unless you have specific needs that require the page load process in your tag execution to run synchronously. Specifically, you should only use the synchronous option when one request or process depends on information from another request before it can proceed. This is sometimes called a blocking script because the second process is blocked until the first one completes. The synchronous option is also good to use when you have several requests that all depend on the same processor. In this case, using the async option won’t speed anything up and can actually result in more overhead work for the processor. So for this environment, I’ll stick with the async option and close the embed window. If you ever want to pull up the embed code later, you can simply click on the package icon for the environment in question. If we’re ready to install this environment on our website, we can then click on the copy symbol to copy the script tag to our clipboard, where we can then go ahead and paste it into our web page header. Now, if we were a developer and we wanted to test our embed code without outright installing it on our site, we can actually use Adobe Experience Platform Debugger to simulate that behavior instead, without needing to directly touch our code. When browsing your website, open up the extension and select Experience Platform Tags in the left navigation. At the top, we’re given some basic info about the build that’s currently active on the page, including its parent property, the environment it’s tied to, the different extensions it has installed, and so on. Click into the Configuration tab, and here we can see the embed code. We’ll select Actions, then click Replace, and then we can paste our embed code here to replace the library that’s running locally on our browser, providing a non-invasive way to test our implementation against our website. Debugger detects the change in real-time, and we can see which environment and extensions are now active, so we can confirm we’ve added the right build. It’s also good practice to double-check the updated version and build date to make sure you’re not using a cached version of the library. Once initial testing is done, environments play a key role in how libraries are reviewed, approved, and published. Within the Publishing Flow tab, you can see which libraries are available in the system, where they are in the publishing process, and their corresponding environments, if applicable. As developers use their corresponding dev environments to test whether the tagging behavior is working as designed, they can move their libraries to the Submitted column for review, where they’ll then be hosted on the staging environment. Builds that are approved will move to the Next column, where they’re removed from any active environment, before ultimately making the final step to the Published column, and the Production environment by extension. Remember, this entire process only works once you’ve installed the embed codes for your various tag environments to their corresponding environments within your actual website, from dev through staging to production. So, those were the basics of working with environments for web properties and tags, which connect your web pages to your hosted tag libraries, and allow your development teams to confidently test and iterate on different builds using the same application lifecycle management stages as the website itself. Thanks for watching!