Collection Methods Overview

Everything so far, variables, report suites, the shape of a metric, was about what the data means. That was Start with the foundations. This module opens the next phase, Collect the data, where that turns into something more physical: how a real human action on a screen actually becomes a row in Adobe Analytics. It is the part of the job where an analytics person stops talking to other analysts and starts talking to developers, and it is where most implementations are quietly won or lost. A perfect measurement plan still produces garbage if the data never leaves the page, or leaves it late, or leaves it twice.

The good news is that the whole thing reduces to one short journey, and a small number of decisions about how you make that journey happen.

Everything in this module is just detail hung on that line. But the line hides a trap that trips up a lot of conversations between analytics and engineering: people argue about "the implementation" as if it were one choice, when it is really two separate decisions that have nothing to do with each other.

The two questions that define every implementation

Keep these apart in your head and most of the confusion disappears:

These cross independently. You can run the old AppMeasurement library through a modern tag manager, or drop it straight onto a page with no tag manager at all. The "which library" choice and the "how deployed" choice get blurred together because in practice most teams make both at once, but treating them as a single decision is exactly how teams end up with the wrong tool for the wrong reason. Question one runs through this section and the next few, and question two has a section of its own in this module.

The four ways to capture data

Four methods, and the honest truth is that most enterprises run more than one at the same time, web through one path, mobile through another, the odd offline event through a third.

AppMeasurement and the Web SDK each earn a full section of their own next, because the choice between them is the single biggest implementation decision a team makes this decade. Server-side and mobile follow after that. For now, treat this card grid as the map, not the territory.

How teams actually choose

There is no single right answer, but there is a pattern worth knowing before you walk into the room:

• Inheriting a working setup: it is almost certainly AppMeasurement through a tag manager. Do not rip it out to feel modern. It works, and the cost of a migration is real.
• Building something new: the Web SDK is the forward-looking default, especially if Target, personalization, or the wider Experience Platform are anywhere on the roadmap.
• Capturing data the browser cannot see: reach for server-side, regardless of what your web pages use.
• Measuring a native app: the mobile SDK is the path, and it behaves differently enough from web that it is worth treating as its own discipline.

The deployment question, tag manager or not, sits on top of all of these, and Tag Management Systems is where it gets settled. It is the decision most likely to be made for you by a platform team, and the one you most want to understand before that happens.

Before any of that, though, something has to physically leave the page. The AppMeasurement Library is where a hit stops being an idea and becomes a request on the wire.