Without knowing exactly how you have set up your click tracking I can only help with some basic suggestions.
I will start with the difference between tracking clicks, vs tracking using Activity Map.
Tracking specific clicks can be a little more reliable, because you are actually creating specific tracking "call to actions"... these server calls can be set up with whatever metrics and dimensions you need on the click. In most cases this will include enough correlation dimensions based on the page that click was triggered from, dimensions related to the click itself and optionally a metric (you could also just go with the default occurrence if needed). However, it should be noted that these are additional server calls... which will increase your server call usage, and depending on how tightly your contract is budgeted, could result in overage charges if you start adding clicks to everything.
Activity Map, on the other hand, collects some basic info about the click (Link that was clicked, Page the Link was on, and the Region the Link was part of - more on this a little later). However, these don't trigger extra server calls... the information is passed on the following Page View. This means you can collect click information without inflating your server calls. (Activity Map data actually gets sent on specific click tracking above if it's enabled and you create click tracking events).
I use a combination of both... I use specific clicks for the really important clicks... things that I really need in-depth or additional information about (things like buttons and links tied to our subscription flow, as well as expand/collapse for things that don't take me to another page - Activity Map doesn't support that). Then I rely on Activity Map for the rest (use of my main navigation, content blocks on my pages, in-line links in the content body, etc). I get enough info from Activity Map to make reports on navigation without creating a lot of special tracking code or inflating my server calls.
Now, to try and address the "dimension" part of your questions.
When you set up any click tracking, you populate props, evars and events like any other server call... however, there is a specific dimension for the clickName (this can be found in Workspace under "Custom Links"). You can use this to distinguish your clicks, or any prop/evar reserved for classifying the actual click.
In my implementation, I make sure on all clicks to send basic info - things like my evar that holds the URL of the page, a copy of the Page Name (the "page" value is stripped from clicks, so if you need this, make sure you have a custom eVar or prop set up to hold the same value), my props for the category of the page, and anything else I may want to use in my reports for the clicks - the context of the use (and the metrics) is what distinguishes values (the eVar by "page view" is obviously only coming from the page views, the occurrences is both page views and clicks, but I can use a segment for "custom link exists" to pull out just the clicks, or if I have a custom metric set up, I can use that metric instead - there are many many ways to parse out the data - it really depends on what you have set up)
Then I have some eVars/props which are only used on clicks... such as on expand/collapse functions, or maybe for a subscription click I track the package, or the placement on the page, etc... it depends on your site, and what you need.
Note that "clicks" really is more than clicks... I think of "clicks" as "special interactions"... they can be clicks, but other times they are triggered by successes... like a successful purchase, or a successful newsletter sign up... I don't track that the user clicked a button... I work with my developers to trigger an event that I can listen for that tells me the action was actually completed successfully... or maybe that it failed... but I track he result rather than just a click...
The last part I will talk about is info about the Activity Map values (which I said I would come back to).
If you just let Activity Map do it's default thing... it can be not terribly useful / easy to read.
