Analyze the data › Activity Map
Implementation and Setup
Somebody opens their first Activity Map report and finds the top link on the site is called Learn more, with 90,000 clicks. Underneath it is > with 40,000, and below that an empty value with 25,000.
All three numbers are correct. None of them is useful. There are forty different Learn more links across the site, the arrow is a carousel control that appears on every page, and the empty row is a set of icons with no text in them at all.
The tracking is working exactly as designed. The names are the problem, and names are decided by the markup rather than by Adobe.
Switching it on is the easy part
Three things have to be true before any data arrives, and on most implementations they already are.
The report suite has Activity Map enabled. It is a report suite setting, alongside the others covered in Report Suite Settings.
The collection code includes the Activity Map module. In a traditional AppMeasurement deployment, that is AppMeasurement_Module_ActivityMap inside your AppMeasurement file. If you deploy through Tags, the Analytics extension has a setting for it. With Web SDK, collection is controlled by clickCollectionEnabled, which is on unless somebody turned it off.
People have permission to see the dimensions. Granted per product profile in the Admin Console. The overlay additionally needs the Activity Map tool permission and the browser extension.
None of that is the work. The work is everything that decides what the names look like.
How Adobe decides what a link is called
When somebody clicks, the code inspects the element and takes the first usable name it can find. Broadly, it uses the visible text of the element, or the value attribute on an input, or the alt text of an image where that is what was clicked.
That works beautifully for a link that says Download the annual report and badly for everything else. Three patterns produce unusable names, and every large site has all three.
Repeated generic text. Forty links called Learn more collapse into one row with a large number and no meaning. The dimension cannot tell you which one, because as far as the page was concerned they have the same name.
No text at all. Icon buttons, image links without alt text, and controls built out of styled elements produce blank or nonsense values.
Text that changes. A link labelled with a price, a count, or a personalised name generates a new dimension value every time it renders, which fragments one link into thousands of rows.
Name the important links yourself
The fix is s_objectID, and it is the highest value thing in this module.
Setting that attribute on an element overrides the derived name completely. The link reports under the name you chose, consistently, regardless of what its visible text says or whether that text changes.
<!-- Derived name: "Learn more". Same as 39 other links. --> <a href="/pricing">Learn more</a> <!-- Explicit name, stable forever --> <a href="/pricing" id="s_objectID=hero-pricing-cta">Learn more</a>
You do not do this for every link, which would put you back in the situation Activity Map was invented to avoid. You do it for the links that matter: primary calls to action, navigation elements you compare against each other, and anything whose label is generic, empty or changeable.
Twenty or thirty named elements on a large site is usually enough to turn the reports from interesting to usable, and it is a conversation with front-end developers rather than an analytics project.
The value of an explicit name is that it stays the same across releases and reads clearly in a report next to a thousand derived names. That only holds if everybody follows one pattern. Something like area, then element, then purpose, in lower case with hyphens, gives you names that sort together and are obvious a year later. Agreeing it takes ten minutes and retrofitting it does not, because renaming an element later splits its history into two dimension values with no indication in the report that they are the same thing.
Regions come from the id attribute
Region is the second half of the picture and it is what makes the data readable at a glance. It answers where on the page the click happened: header, hero, main navigation, footer.
Adobe fills it by walking up from the clicked element until it finds an ancestor with an id attribute, and using that id as the region name. Which means the quality of your region data is entirely decided by whether your page has meaningful ids on its structural containers.
Sites built with sensible markup get this for free. Sites where ids are generated by a framework get regions called things like ember1423, which change on every build and are worthless. If that is your situation, ActivityMap.regionIDAttribute lets you point Adobe at a different attribute instead, so you can use a stable custom attribute rather than the framework's generated ids.
What it will not track, whatever you do
Several things produce no data at all, silently, and one of them catches modern sites constantly.
| Not tracked | Why | What to do |
|---|---|---|
<button type="button"> | Excluded by design | Track it with a manual link call |
Anchors with no valid href | Nothing to follow | Give it an href, or track manually |
Inputs without a src | Nothing to name it by | Use s_objectID |
| Anything seen but not clicked | It records clicks only | Nothing. This is the boundary of the feature |
| Non-link elements | Not clickable in the markup sense | Manual link tracking |
A React or Vue site built from a component library is full of <button type="button"> elements and anchors with no href, because navigation is handled in JavaScript rather than by the browser. Both are invisible to Activity Map. The reports still populate, because plenty of ordinary links remain, so nothing looks broken. What actually happens is that the most important interactive elements on the newest parts of the site are missing from a report that appears complete, and nobody notices because there is no empty row to point at. If your site is a single page application, assume this is happening and go and check specific components rather than trusting the ranked list.
Exclusions keep the noise down
Two settings remove things you do not want counted.
ActivityMap.linkExclusions filters out clicks whose link name matches what you list. Useful for controls that appear on every page and swamp the report without telling you anything, such as carousel arrows or pagination.
ActivityMap.regionExclusions does the same for regions. Useful when a framework generates a region name that changes constantly and fills your dimension with values that mean nothing.
Both are worth using deliberately and sparingly. An exclusion is invisible in the report afterwards, so somebody looking at the data in a year has no way to know that a category of click was removed, unless it is written down somewhere they will find.
Follow along: check what your own pages produce
Twenty minutes, and it usually surfaces at least one thing worth fixing.
- Part one, look at the names you already have
-
Build a freeform table with
Activity Map Linkin the rows andOccurrencesin the column, over a month. -
Read the top twenty rows and mark any that are generic, blank, or obviously the same element appearing many times.
Learn more,Next,>, and empty rows are the usual suspects. -
Break down one generic row by
Activity Map Page. This tells you how many different places share that one name, which is the size of the problem. - Part two, look at the regions
-
Put
Activity Map Regionin a table on its own. If you see generated ids that look like machine output, your regions are coming from framework ids and needregionIDAttributepointed elsewhere. - Part three, check what is missing
-
Open your most important page and inspect its primary call to action in browser developer tools.
If it is a
<button type="button">or an anchor with no href, it is not being tracked at all. - Search your Activity Map Link dimension for that element's text to confirm. Absent from the report confirms it. This is the finding worth taking to a developer.
-
Write a short list of elements to give an
s_objectID, using one naming convention. Twenty or thirty is plenty. Start with anything you would put in a report for a stakeholder.
There is nothing to configure in Adobe for any of this. The report suite setting is either on or off, and everything that decides data quality lives in the markup of your own site.
The markup decides the report
Turning Activity Map on takes three settings that are usually already correct. Everything that decides whether the data is worth reading happens in the HTML of your own site.
Link names are derived from visible text, input values and alt text, which fails for generic labels, empty icons and text that changes. s_objectID overrides the derived name and is the single most valuable change you can make, applied to twenty or thirty important elements rather than everywhere. Agree the naming convention first, because renaming later splits the history.
Regions come from the nearest ancestor id, so framework-generated ids give you meaningless regions and regionIDAttribute is the way out. Exclusions remove noise and are invisible afterwards, so write them down.
And some things are never tracked whatever you do, including <button type="button"> and anchors without an href, which is exactly what a modern component library produces. The report will look complete while the newest parts of your site are missing from it.
With names worth reading, the question becomes what to do with them. There are two quite different ways to look at this data, one on top of the live page and one in a report, and they suit different questions and different audiences. Using Activity Map covers both.
The report suite switch is at Analytics > Admin > Report Suites > select suite > Edit Settings > General > Activity Map.
Everything else is in your implementation rather than in Adobe. The module lives in AppMeasurement or is switched on in the Analytics extension in Tags. s_objectID, regionIDAttribute, linkExclusions and regionExclusions are all set in code or in your tag management configuration.
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.