Launch Architecture

Tag management has surfaced repeatedly in this guide, most directly in Tag Management Systems, where the choice was framed as a trade. This module takes the thing head on, because saying a tag management system is "useful" or "good" is not enough. You need to know what the thing actually is, and why it earns your time as a subject in its own right. It sits on top of AppMeasurement, the Web SDK, the data layer, the different kinds of variables, and report suites, each with its own reasoning, history and practical edges. So why give this a separate module? Because this is where all of that turns into something running on a real website. This is the actual work.

Think about what comes to mind when someone says "Adobe Analytics." Most people picture the reports: dimensions and metrics, trended lines, a Workspace project open on a screen, a room of people arguing about what the numbers mean. That is the visible half. The other half is the quieter question of where any of that data came from in the first place, and it has a name too. It is called implementation, and it means what it sounds like: installing Adobe Analytics onto your digital property, your website or your app.

An analogy that holds up here: you can finalize every detail of an interior design, every color, every measurement, every piece of furniture, and still have nothing you can live in. The design is not the room. Skilled people have to show up, take real measurements against real walls, and install the furniture against the finalized plan. Implementation is that installation step for Analytics, and it matters more here than it does for some tools. Adobe Analytics vs Google Analytics covered how Google Analytics is closer to plug and play, quick to stand up. Adobe Analytics can technically be plug and play too, but its real power only shows once you customize it to your business, which makes an Adobe Analytics implementation a more deliberate, more shaped thing than the GA equivalent. Both get implemented; the implemented versions simply have a different shape.

So when you picture an Adobe Analytics implementation, the platform you are really picturing, the place where that work happens, is Launch.

What "Launch" actually is

"Launch" is the popular name, and like a lot of popular names it sits one rename behind the truth. There is a short history worth knowing, because it explains why the same product has three names floating around in conversation.

Adobe's first tag management system that really mattered came from a 2013 acquisition: a product called Satellite, from Search Discovery, which Adobe renamed Dynamic Tag Management, or DTM. DTM was given away free to anyone who already held an Adobe marketing license, which is a large part of why it spread so widely. Then, around 2018, Adobe shipped something genuinely new and called it Launch. This is the part that people who have been in the Adobe ecosystem for a decade remember in their bones. Launch was not a fresh coat of paint on DTM. It was a ground-up rebuild on a new foundation, a new platform with a new interface, and moving an enterprise from DTM to Launch was real migration work, not a settings change. DTM was retired; Launch was the new living thing.

Then came a quieter shift. Adobe did not announce this one with the same volume, but the product was folded into a larger home called Data Collection, and the client-side tag manager you knew as Launch was renamed Tags. Data Collection kept growing past tag management. It now also covers things like event forwarding, datastreams, and the secure storage of credentials, so it is fair to say Data Collection is no longer "a tag management system" so much as the hub through which data is collected and routed in every direction. The piece of it that you build your implementation in, the part everyone still calls Launch out of habit, is Tags.

Throughout this module, Launch means Tags inside Adobe Experience Platform Data Collection. The habit name and the current name point at the same screen.

Why Launch, and not Tealium or Google Tag Manager

The other tag managers, Tealium, Ensighten, and Google Tag Manager, are not off limits, and this is not a turf war. They are good products, and there are real companies running happily on them. But step back and ask the plain question a business asks. Adobe gives you its tag manager, Tags, included with your Experience Cloud license at no extra cost. Why pay for a third-party product on top of that, unless you have a very strong, specific reason to? For most accounts there is no such reason, which is why Tags is what the large majority of Adobe Analytics implementations actually run on. If you were standing up Adobe Analytics for a new website tomorrow, Tags would still be the recommendation.

The case has only grown stronger, because Tags no longer stands alone. It is wired deeply into the rest of the Adobe stack: Analytics, Target, Audience Manager, Customer Journey Analytics, the Experience Platform, Journey Optimizer. That tight binding is something a neutral third-party tag manager cannot match by design. There is also the wider Data Collection capability sitting around it. If you are already on the Edge Network, for example, you can forward your collected data out to non-Adobe destinations from Adobe's own servers using event forwarding, rather than stacking more third-party pixels onto the page. That particular capability is a paid add-on rather than part of the free tier, and it is a topic for much later, but it is worth knowing that the platform reaches well past simple tag management now. No standalone tag manager offers that whole picture.

That is the what and the why. The how is the rest of this module, and it starts with how Launch is put together.

How Launch is organized

Start at the top, with the property. A company may run one website or many. Report Suites met the same reality: one global suite, or several, or virtual views carved from a parent, depending on how the business needs to see its data. Launch answers the same kind of question on the implementation side: a single Launch account can hold multiple properties, and a property is the container that takes care of a given site or app.

The relationship between a property and a report suite is not fixed at one to one. One property might feed many report suites; many properties might feed a single report suite. Which arrangement is right is not a setting you look up, it is a design decision, and it lands on you, the architect. What does the business look like, what questions does it need to answer, and what structure will answer them cleanly? That is the property for you. Everything else in Launch lives inside it: the rules, the data elements, the extensions, and the publishing flow that ships them.

Each of those has a full section of its own in this module. For now, here is the map.

Rules are the logic of the implementation. A rule is a construct that says, in effect, when this happens, collect this. The "this happens" is an event you care about, a download, a form completion, an on-site search, a page loading, and the rule defines both how that event is recognized and what data goes out when it does. Rules are where the implementation comes alive.

Data elements are, at first glance, Launch's version of variables: named things that hold a value. But they are more capable than a plain variable. A data element can read a value from the page, but it can also reshape it, make a decision based on it, and even correct it with a bit of code before anything is collected. They are the reusable building blocks the rules draw on.

Extensions are not, despite the name, a phone line you dial to talk to Adobe. The cleaner way to picture them is as apps on a phone. Launch has a catalog, an app store, and any vendor that wants to put something on your website can build an extension for it and list it there. Once Launch is on your site, you generally do not need to hand-place third-party pixels or snippets; you install the relevant extension from the catalog and configure it. Meta, for example, publishes a Meta Pixel extension. You install it, make the handful of adjustments its own documentation calls for, and you are done. The Adobe Analytics and Web SDK extensions you will work with most are simply the Adobe-built members of the same catalog.

And finally the publishing flow. You build your rules, data elements, and extensions, and then, like any software, the changes have to be tested before they reach real visitors. A library is the collection of changes you are working on, and it is built and then deployed through a series of environments, development, then staging, then production, the same staged path a website or an application takes on its way to release. The good part is that the whole flow is tightly controlled by permissions. Some people can develop but not publish; some can review what has been published without changing it; some can push an approved library to production without being able to alter what is in it; and a few administrators can do everything. Who is allowed to do what is part of the design, and it is what keeps an implementation from sliding into chaos.

That, in a nutshell, is Launch: a property that holds your extensions, data elements, and rules, built into a library, and deployed through controlled environments to your live site. It is a simple story at this height, and the sections ahead take each piece down to the level you will actually work at.