What Adobe Analytics
actually is.

1 · The ecosystem (and why this is confusing)

Adobe Analytics is one product inside a much larger family called the Adobe Experience Cloud. If you read older documentation you will see it referred to as SiteCatalyst, then Omniture; the product is the same, the names changed. The reason this matters for you, the implementer, is that Adobe documentation drifts across the years and you will find code samples in three different dialects sitting on the same web page.

Here is the map you should keep in your head:

If you are new, you can ignore CJA for now. We will return to it in module 12. For the first eleven modules, "Adobe Analytics" means the classical product — the one whose reports look like Workspace and whose data lives in report suites.

2 · The collection pipeline

Every implementation problem you will ever solve can be traced through this five-step pipeline. Memorise it. When something is broken in production, your debugging instinct will be to find which of these five steps is misbehaving.

┌────────────┐   ┌───────┐   ┌──────────────┐   ┌─────────┐   ┌─────────┐
│  USER      │ → │ TAG   │ → │ APPMEASURE-  │ → │ ADOBE   │ → │ REPORT  │
│  ACTION    │   │ MGR   │   │ MENT BUILDS  │   │ COLLEC- │   │ SUITE   │
│            │   │ FIRES │   │ THE REQUEST  │   │ TION    │   │         │
└────────────┘   └───────┘   └──────────────┘   └─────────┘   └─────────┘
     ①              ②              ③                 ④             ⑤

① User action

Someone loads a page, scrolls, clicks a button, completes a checkout. Something happens in the browser that we have decided is worth measuring.

② Tag manager fires

Launch is listening. A rule says: "when this happens, run this JavaScript." The rule fires. This is where you, the implementer, do most of your configuration work — defining what counts as a meaningful event, what data to collect about it, and what to do with that data.

③ AppMeasurement builds the request

The rule's action invokes AppMeasurement. Conceptually it is two steps: set variables (s.pageName = "Home", s.events = "event3", …), then send (s.t() for a page view, s.tl() for a link). AppMeasurement serialises every variable you've set into a query string and fires it as an HTTPS request.

④ Adobe's collection servers receive it

The request goes to a URL like metrics.example.com/b/ss/<rsid>/1/<version>/<aid>. Adobe's servers acknowledge it (a 1×1 transparent GIF historically; an HTTP 200 now) and queue the hit for processing.

⑤ Processing & storage in the report suite

The hit is shredded apart, run through processing rules and VISTA rules (server-side transformations you defined), enriched with classifications, joined to the visitor profile, and finally written into the report suite's data store, ready to be reported on in Workspace.

3 · Report suites — the unit of accounting

A report suite is the database your hits land in. Think of it as a single ledger: every hit it receives is segmented and reported on independently from every other report suite.

You will work with three kinds in practice:

Each report suite has an RSID — a short identifier like examplecorp or examplecorpprod. When you set s.account = "examplecorpprod", you are choosing which ledger to write to. This is the single most consequential variable in your implementation; sending production data to a dev suite makes it invisible, and sending dev data to a production suite pollutes it.

The Multi-Suite Tagging pattern

A common pattern is to send the same hit to two report suites at once — one global, one regional. You do this by setting s.account to a comma-separated list:

s.account = "examplecorpprod,examplecorpus";
s.pageName = "Home";
s.t();
// Adobe sends one hit, replicated to both report suites.

The hit appears in both suites — but each has its own retention, schema, and processing rules. The processing rules will probably differ. We will return to this in module 10.

4 · What a "hit" actually is

A hit is an HTTPS request. Specifically a GET to a path that looks like this:

https://metrics.example.com/b/ss/examplecorpprod/1/JS-2.20.0/s12345678
  ?pageName=Home
  &ch=Home
  &events=event1
  &v1=logged-in
  &c1=US
  &g=https%3A%2F%2Fexample.com%2F
  &mid=01234567890
  &aid=12345678-ABCDEF01

Read this URL the way a colleague would. The bits to the left of the ? say "this is an Adobe Analytics hit going to the examplecorpprod report suite using AppMeasurement version 2.20.0." Everything after the ? is your payload — every variable you set, in its compressed form (v1 means eVar1, c1 means prop1, etc).

There are exactly two kinds of hits:

Link hits come in three sub-types: custom link ('o'), download link ('d'), and exit link ('e'). These categorise the link in Adobe's link-tracking reports. Module 06 covers the distinction in detail.

5 · The three libraries — and why all three still exist

You will encounter implementations built with three different libraries, sometimes on the same website. Knowing which is which is half the job.

6 · The vocabulary you need before module 02

You will not learn all of these by reading the definitions. You learn them by using them. So skim this list now, then refer back as the rest of the course makes them concrete.

7 · Checkpoint

Before you continue to module 02, you should be able to answer these out loud:

• What happens between a click in the browser and a row in a report?
• What is the difference between a page view hit and a link hit?
• Why does a report suite ID matter — and what is the cost of getting it wrong?
• What's the difference between AppMeasurement and the Web SDK?
• What is a hit, exactly, at the network level?

If any of those are fuzzy, scroll back. There is no rush.