Quickstart guide

Tags are Adobe Experience Platform’s next generation of tag management technology. It is built from the ground up to support an open and sustainable ecosystem where anyone can build their own integrations that Adobe customers can deploy to their sites. It is an API first application so anything you can do through the UI you can also do programmatically through an API.

The basic tags workflow:

1. Set up groups and users

Tags are fully integrated with your Adobe ID. User permissions are managed through the Admin Console with other Adobe products and solutions from the Creative Cloud, Document Cloud, and Experience Cloud.

Tags have a rights-based user management system. This means that individual rights must be granted explicitly. These rights are assigned to groups, then users are added to the appropriate groups in order to gain access. Even if your organization has access to Data Collection, individual users cannot do anything until an administrator explicitly grants them some rights.

For detailed instructions on how to create groups and add users for tags, see the data collection permissions guide.

2. Log in

After tag rights have been added to your Adobe ID, you need to log in to the Experience Platform UI or Data Collection UI. You can do this by navigating directly to the Experience Cloud login screen, and selecting either Data Collection or Experience Platform.

3. Create a property

Once you have logged into the UI, the first thing to do is create a property. A property is basically a container that you fill with extensions, rules, data elements, and libraries as you deploy tags to your site. Many people create a property for each website (or group of closely related sites) where they want to deploy the same set of tags.

For more about creating properties, see Create a property.

4. Install extensions

An extension is an integration built by Adobe or an Adobe partner that adds new and endless options for the tags that you can deploy to your sites. If you think of a tag as an operating system, extensions are the apps that you install to do the specific things you need it to do.

All new properties come with the Core extension installed. Mobile properties come with additional extensions. The Core extension is built by Adobe to provide a robust default set of data element types for your data layer and event types for your rules. Most actions you will want to perform (get an ECID, send Adobe Analytics beacons, load the Target global mbox, etc) will come from extensions that you install from the catalog.

What makes tags in Platform truly unique is that these extensions can be built by anyone. Do you need to drop a Facebook remarketing pixel on your site? Check out the extension that Facebook built. Do you want the same for Twitter or Linked In? Use those extensions. Do you need to run a survey? Look at Question Pro or Foresee. Do you need to manage privacy and consent from your end-users to help out with GDPR? Take a good look at Evidon and Trust Arc. Would you like to see granular insight into the behavior of individual users on your site? Maybe take a look at Clicktale. For more information, For more information, see the section on adding a new extension.

5. Create data elements and rules

Data elements are pointers to the information that you want to collect and send to different places on your page:

After the data element is defined, you can use the element anywhere throughout the UI for any extension. See the documentation on Data Elements for more detailed information.

Rules are at the logical core of your implementation and control the what, when, where, and how of all the tags on your site. Define an event, set conditions and exceptions, then define the actions and order. Finally, publish your changes to see the results. For more information, see Rules.

6. Test in your Dev environment

Libraries and builds

Tag builds are never published automatically. Each set of changes you make is encapsulated into a library. Each library you create automatically inherits anything upstream (published, approved, or submitted) as a baseline, so all you need to do is define the changes you’d like to make. This library serves as the blueprint for a build. A build is the actual set of JavaScript files that are deployed and used.

It is important to understand the relationship between your web page, your hosting location, and tags.

Hosts

A host is a connection between a tag property and your hosting location. Tags currently support either Adobe managed hosting via an Akamai host or self-hosting through an SFTP host. Whenever you produce a build, tags connect to the server defined by your host and delivers the build.

If you are self-hosting, a tag build can push directly to your servers through SFTP or you can push it to Akamai and download it using your environment’s Archive option.

For more information, see Hosts.

Environments

Each library is created inside an environment. An environment defines how you want your build to look when it is published. You can specify:

After you have saved your environment, it generates the embed code which you can copy and paste into your website. Note that the embed code will not work until you have created a library and produced a build. For more information, see Environments.

Publish a build to Dev

The publishing process is described in the steps below.

7. Promote to production

After you have tested your build in your dev environment, make sure to create your stage and production environments and put the embedded codes in the necessary places. You can reuse existing hosts for this purpose.

Promoting a library all the way through to production typically requires coordination among different people with the appropriate rights.

You can assign all these rights to a single person.

For more information about the different states and options available during the publishing process, see Approval Workflow.

Additional resources

To learn more about tags, refer to these resources: