Analyze the data › Activity Map
Activity Map Best Practices
Activity Map is the cheapest data in Adobe Analytics. Nobody instruments it, nobody maintains it, and it accumulates whether or not anyone is looking.
Cheap data invites lazy questions, and this data has a narrow honest range with a lot of plausible-looking answers just outside it. Knowing where that edge is turns out to be most of using it well.
The questions it answers, and the ones it does not
It answers three kinds of question properly.
Which of these competing elements do people use? Three calls to action on a page, four items in a navigation, two routes to the same destination. This is what it was built for and it is very good at it.
Did a design change move behaviour? Trend a link before and after a release. As long as the element kept its name, this is clean evidence.
Is anybody using this at all? A feature somebody fought for that turns out to get forty clicks a month is a real finding, and a cheap one.
Three questions it cannot answer, however confident the report looks.
What proportion of people who saw it clicked it? It has no idea who saw anything. You must supply a denominator, and page views of the containing page is an approximation rather than an answer.
Why did people not click? There is no data about non-clicks, so every explanation is a story somebody made up.
Where were people looking? Different question, different tool. Clicks are not attention.
Single page apps break the page dimension
This is the structural problem, it has no clean fix, and it affects a growing share of sites.
Activity Map watches the page for changes rather than waiting for a reload, which is what lets it work on a modern site at all. What it does not do is re-establish which page it is on. New content that appears without a page load is attributed to the page dimension value from when the view first loaded.
So a visitor who lands on the home page and moves through three views without a browser reload can produce clicks that all report as having happened on the home page. The link names are right. The region names are right. The page is wrong, and nothing in the report indicates it.
The damage depends on how you use the data. A report on Activity Map Link alone is unaffected. Anything that breaks down by page, which is most of the useful analysis, is quietly misattributed.
The test takes ten minutes. Pick a journey on your site that moves between views without a full page load, click something distinctive on the second or third view, then find that click in the Activity Map Link dimension and break it down by Activity Map Page. If it reports against the page you started on rather than the one you were actually looking at, every page-level Activity Map report in your organisation is affected. The practical response is to lean on Activity Map Link By Region and on explicit s_objectID names that carry their own context, rather than trusting the page breakdown. Naming an element checkout-step2-continue survives this problem entirely, which is another argument for explicit names on anything that matters.
Plan for losing the overlay
Any organisation moving from AppMeasurement to Web SDK should know this before the migration rather than after.
Web SDK collects Activity Map data. The setting is on by default and the four dimensions keep populating exactly as before, so every report, segment and dashboard built on them continues to work.
The browser overlay does not work with Web SDK. It is not a configuration problem to solve, it is not supported.
Which matters more than it sounds, because of who uses which half. Analysts live in Workspace and lose nothing. Designers, product managers and content teams often only ever used the overlay, and for them the feature disappears entirely on migration day. If nobody warned them, that lands as analytics being broken.
The answer is to say so early and to move those people onto reports before the migration, not after. A saved project showing the pages they care about, broken down by link and region, does the same job and survives the change.
Keep the dimension readable
Three habits, and the first is worth more than the other two together.
Name the elements that matter, to a convention. Twenty or thirty s_objectID values covering primary calls to action and key navigation is enough to make the reports usable. One naming pattern, agreed once, applied by whoever builds the front end. Renaming later splits the history, so it is worth getting right before the first one ships.
Document your exclusions. Link and region exclusions are invisible in the report. Somebody looking at the data next year cannot tell that a whole category of click was removed. Write down what is excluded and why, somewhere the next analyst will actually find it.
Re-check after every significant release. A front-end change can rename links, change region ids, or convert an anchor into a button that is no longer tracked at all. None of that produces an error. The report simply becomes less true, and it does so quietly.
The failure mode with this data is never dramatic. Nothing breaks, no alert fires, and the report keeps rendering with slightly wrong numbers for months. Because there is no incident, it never becomes urgent enough to schedule, which is why almost every mature implementation has Activity Map data nobody quite trusts. The fix is to attach the check to something that already happens: when a template changes, somebody confirms the important elements still report under the same names. Five minutes, tied to an event that occurs anyway, is the only version of this that gets done.
Follow along: an Activity Map health check
Half an hour, once a quarter or after a significant release. This is the routine worth handing to somebody else.
-
Put
Activity Map Linkin a table over the last month and read the top twenty rows. Look for new generic names, new blanks, and names that fragmented into near-duplicates after a release. -
Check that your named elements are still reporting under their
s_objectIDvalues. Search the dimension for each convention prefix. A missing one means a developer removed the attribute. -
Put
Activity Map Regionin a table and look for machine-generated ids. New framework ids appearing means a component was rebuilt and the region setup needs revisiting. - Run the single page application test: click something on a second view and check which page it reports against. If it reports the entry page, avoid page breakdowns and rely on explicit names instead.
-
Open your most important template and inspect its primary call to action.
Confirm it is still an anchor with an href or a tracked button, and not a
<button type="button">that vanished from the data. - Write the result down, even when everything passed. A dated note saying the check ran and found nothing is what lets somebody trust the data without repeating the work.
There is nothing to configure. Five checks against your own reports and one look at your own markup, tied to something that already happens in the release cycle.
Free data still needs a decision
Activity Map costs nothing to collect and accumulates whether anybody uses it, which is exactly why it needs more judgment than data somebody had to fight for. It answers which competing element people use, whether a change moved behaviour, and whether anything is being used at all. It cannot give you a rate without a denominator you supply, cannot explain a non-click, and knows nothing about attention.
Single page applications attribute clicks to the page value from when the view first loaded, which quietly breaks page-level breakdowns and is best worked around with explicit names that carry their own context.
Web SDK keeps the dimensions and loses the overlay, so a migration removes the feature entirely for the people who only ever used the picture. Move them onto reports first.
And the whole thing rests on names that came from your own markup, so it degrades silently with every front-end release unless somebody checks.
What Activity Map gives you for free is a name for every link somebody happened to click. What it cannot do is measure something on your terms: a specific interaction, named how you want it, carrying the variables you choose, fired when you decide it matters. That is deliberate instrumentation, and Link Tracking is where it is done. The two are complements rather than alternatives, and knowing which to reach for is the practical skill.
All four dimensions live in the components list in Analytics > Workspace. Everything in this section is done there, in reports, rather than in an admin screen.
The report suite switch is at Analytics > Admin > Report Suites > Edit Settings > General > Activity Map. Exclusions and named elements are set in your implementation, not in Adobe.
This article focuses on the concepts, architecture, and practical guidance behind the topic. For the latest UI walkthroughs and step-by-step implementation instructions, use the links below. They leave this site and open Adobe's own documentation in a new tab.