What to Learn Next

Somebody spends eighteen months getting good at Adobe Analytics. They can read a hit, they know why a number disagrees with the order system, and they have opinions about eVar expiration they can defend.

Then they read that Customer Journey Analytics is the next generation product, that eVars and props do not exist in it, and that the processing model works the other way round.

The reasonable question is whether any of it was worth learning. The honest answer is not reassurance. Some of what they learned is disposable. A larger part is not, and telling the two apart is the most useful thing anybody can do at this stage.

What you look up, and what you remember

Think about someone who has used relational databases for years. They remember what a key is, why a join exists, and when a denormalized table is the right answer anyway. They look up the syntax. Every time.

Nobody calls that a gap. The part they carry decides things. The part they look up is answered by a reference in eight seconds.

Analytics divides the same way, and a lot of what feels like expertise sits on the wrong side of the line.

The parts that survive the product

Six ideas do most of the transferring, and none of them belongs to Adobe.

Where a decision gets made decides what you can fix. Adobe Analytics settles things at collection and stores the answer, so a mistake is permanent and correctness has to happen up front. CJA settles them at report time, so mistakes are cheap and the settings become the thing to govern. Every data platform sits somewhere on that line. Knowing which end you are at tells you where the risk is before you read a page of its documentation.

A value has a scope, and somebody chose it. Allocation, expiration, a container, a lookback window, a data view setting. All of them ask the same question: what does this value apply to, and for how long. Two people can pull the same report and get different numbers because of a choice neither of them made.

Broken things stay silent. Analytics has no failure signal. A wrong value looks like a right one, nothing errors, and somebody finds it months later in a report they built for another reason. Distrusting a system that has told you nothing transfers to every pipeline anybody will hand you.

A count is not a decision. The work is not producing a number. It is producing something somebody can act on, in a meeting where three people disagree and one owns the budget. That is a communication skill wearing technical clothes, and it decides whose analysis gets used.

A document where one change costs one edit stays true. One where a change costs four edits across three places becomes false quietly, and nobody can name the day it stopped being reliable. That is a property of documents rather than of analytics.

An identifier decides what is possible. Cross-device reporting, stitching, profiles, activation, and every join between two systems come down to whether the same person produces the same value in two places. The technology around it changes constantly. The dependency does not.

Four directions, and who each one suits

What comes next depends on what you want to be doing in three years. The four honest options pull in different directions.

Go deeper into reporting and analysis. Customer Journey Analytics, and the craft around it: segmentation, attribution, cohort work, and explaining findings to people who do not want a dashboard. This suits somebody who would rather answer questions than build plumbing. It is also the shortest step from Adobe Analytics, because the reporting interface is the same one.

Go wider into the platform. Experience Platform itself, then Real-Time CDP and Journey Optimizer. Here analytics stops being a reporting function and becomes the data layer of the customer experience. The same schema and identity work feeds activation rather than only reports. It suits somebody more drawn to collection and identity than to reporting, and it is where the market demand currently sits.

Go deeper technically. Web SDK and the Edge Network properly, mobile implementation, server-side collection, and the APIs. This suits somebody who enjoyed reading a hit in a network tab. It stays valuable whichever reporting product wins, because everything downstream depends on collection being right.

That direction has a starting point on this site rather than a reading list. Web SDK Migration is a complete thirteen step guide to moving a real Adobe Analytics implementation onto the Edge Network, with a knowledge base of twenty two articles behind it. It is the single piece of work that most changes what an implementation can do next, and it is the on-ramp to everything in the module before this one.

Go professional rather than technical. Requirements, design documents, estimating, running a testing cycle, and getting a client to sign something. Nobody advertises this direction, and it is what separates a competent implementer from somebody who can run a programme. It is also the least perishable of the four, because none of it is tied to a vendor.

Certification, and what it is worth

An opinion, since this topic usually attracts either enthusiasm or contempt and neither helps.

Certification opens doors and does not make you good. Both are true. It gets a CV past a filter, it satisfies a partner requirement, and in a consultancy it is often a commercial necessity. None of that makes somebody able to diagnose a discrepancy at four in the afternoon.

So take it for the door, and know which of the two you are buying. The mistake worth avoiding is treating the syllabus as a curriculum. An exam has to test things that can be marked, which pushes it toward the recall-shaped knowledge in the left column of that drawing. Studying only for the certificate means learning the half a search engine already answers.

What this site does not cover

Worth stating plainly, so nobody mistakes a gap for a claim.

Nothing here covers Adobe Target, Audience Manager, Journey Optimizer or Real-Time CDP beyond the points where they touch analytics. Streaming media collection, the Analytics APIs and Report Builder get a mention at most. B2B and account-based analysis is absent. And CJA has one module here rather than the curriculum it deserves. That is a deliberate limit. A product that inverts the processing model needs its own body of work, not a chapter borrowed from somebody else's.

That body of work is planned. Until it exists, Adobe's own documentation is the right next stop, and it becomes much easier to read once you know why the things in it exist.

Reading has a limit

Most people reach it well before they think they have. Whichever direction you pick, the thing that makes it stick is having somewhere to apply it within the next few weeks.

Write the direction down as a sentence beginning with a verb. Implement Web SDK on a real site beats learn Web SDK, because the first has a finish line and the second is a mood. Then find the thing you will build: a sandbox, a personal site, a neglected internal property, or work nobody has claimed. That step is the one people skip, and skipping it is why the others fail.

Two habits are worth building in deliberately, because almost nobody practices them on purpose. Write a one page requirements document before touching anything, even for a personal project, so the shape becomes automatic on a real one. And break what you built on purpose, then diagnose it. Send an empty variable, reuse a purchase identifier, fire a rule before the data layer is ready. Recognizing a fault by its symptoms only comes from having caused it.

Then write one finding up for somebody else, in a page, as a recommendation rather than a report. The number at the top, the method underneath. That is the skill that decides whose analysis gets acted on, and it is the one least likely to be practiced by accident.

The habit worth keeping

The tools in this curriculum will be replaced. Some already have been, inside the time it took to write it. An interface that carried reporting for fifteen years stopped working. A debugger everybody used went unmaintained. And Customer Journey Analytics is built on the opposite processing model to the one most of this site teaches.

None of that is a reason to have learned it lightly. Somebody who understands why a product made a choice can pick up its replacement in an afternoon, because the replacement answers the same question differently and they already know what the question was. Somebody who memorized where the buttons were starts from nothing each time.

So the thing to carry out of this is not a product. It is the habit of asking why something exists before asking how it works, and then refusing to accept a number until you know which decisions produced it. That is what makes Adobe's documentation readable, what makes a strange platform learnable, and what makes somebody useful in the meeting where the numbers do not match and everybody is looking at the analyst.