It seems likely that this has been discussed before but despite my excellent search skills, I was unable to find the answer to this question:
Why is there no click counter for internal links? Or rather: some internal links. Like this one or this one
edit: but what about a link without your username tracking in the URL, like this one?
Internal links that do get click counters seem to be:
Links that include http?
I’m not sure I understand the question but I suppose the answer is yes.
Links that have http get counted and those that don’t are not counted?
That was my (hard to discern) guess.
What would be an example of a link without http?
Hmm. Yeah. I was thinking that some links were relative URLs, so didn’t have http,just started with /. But that’s not it.
I got nothing.
This is really puzzling. I now found an ordinary internal link (what you get via the 
icon minus the username part) which has a click counter, but I also have multiple such links where clicks are not counted… 
Can you make a post here with specific examples on meta?
There was meant to be a sample link in the OP but apparently I posted it without pasting the link. Fixed it now. Let’s see if it will get a link counter as predicted…
In any case: could you clarify what the expected behaviour is? When does a link get a click counter and when does it not get one?
There’s something suspicious going on? Or something I’m missing.
I have two posts, linked with hyperlinked text.
When I go to the target link I see that it’s been visited from the first post several times (from the counter and link at the bottom of the post!), but there is no corresponding counter on the source page…
The link counters that don’t work have exactly the same format as the ones that do, they are all using the full URL including https and the domain and full path.
I dare say this might be some kind of bug?
I’m raising this as a potential bug.
I’ve done a very little amount of investigation so far.
I’ve confirmed so far that my suspicious links that are showing zero clicks exist in the table, and the count is zero. That’s so unlikely as to be almost impossible. So why aren’t the clicks accumulating? Other links within the same topic and post are accumulating fine … (or perhaps its an intermittent issue so the counts are lower than they should be?)
Try it yourself in Data Explorer for suspicious links with no counter:
(the topic id is in the URL, naturally)
SELECT * from topic_links where topic_id = <your affected topic id>
Next, I clicked on the suspicious link whilst impersonating a user, logged out, logged back in as admin and then ran the query again. Still zero.
So this isolates it to the point of input perhaps? Perhaps in the code behind the click action … or a data issue? But the data looks very like the data for the links that accumulate clicks. Except for the count …
I checked to see if the ID was unique (and presumably the id is a primary key in any case, but I checked anyway in case the wrong record is being updated) … it’s unique.
Am I missing something here?
UPDATE: I’ve found something here
I noticed the URL generated in the ajax call with path /click/track uses an out of date slug which was changed during the life of the target Topic - could that have affected it? I know most code should rely on the id only, but is this an isolated case where it requires the slug to remain the same as when the link was created in order to work?
BOOM, that’s the problem!
Update the old slug in the source link to the new target slug and the counter appears.
The counters fail because the slug has changed - I think this should be fixed if possible as this should not be a dependency?
WORKAROUND: Update the source link to the new target slug and the counter starts working! @tophee @sam
Unfortunately this is a lot of manual work and you need to identify each mismatching link. A fix to remove this dependency to rely only on the id would be lovely 
Would be also good to check:
Unfortunately, I cannot confirm this. Although I found one link where the target slug had indeed changed, but multiple others where correct but without a counter nonetheless. 
Ok but did fixing the slug add the counter in that instance? Worked for me. You may need to impersonate a user to accumulate a count (not sure if it registers admin clicks? Might not. Hence you need user account to check?)
Is it possible no user has clicked those links where the slug was up-to-date in the link? Don’t think using admin account is valid check.
i also think accumulation presently isn’t supported for targets involving mid post headings.
My edit is your answer @tophee, see first post
Thanks Jeff, l’ll confirm that one tomorrow too.
Any chance we can add counter support for those cases?
So you are saying that internal links will be counted if they don’t have a username appended but not if they do? (If so, is that intended behaviour and if it is why?)
This was one of the first things I checked before I wrote the post and could not confirm it. I have a long table-of-contents type post in which I intentionally omitted the username in order not to skew my stats, but none of the (internal) links had a counter. And this was the case also yesterday. Since people use that post a lot, it’s impossible that none of the links were clicked.
Looking at it today, however, I see some link counters appear for internal links. What has changed since yesterday? We upgraded to latest via a rebuild (because we had to remove the deprecated github linkback plugin).
So, if this ever was a bug (I was never sure from the start, because I wasn’t sure what the intended behaviour was), it may be fixed now.
But does anyone understand what was the cause of this? It looks like someone broke it and fixed it without even realizing it?
Or perhaps there are several things coinciding here? One is the thing with the appended username (which didn’t explain things for me), and another thing is some bug that was fixed in a recent commit.
Do any of your working links contain:
Because I don’t think these are supported at the moment and will still fail.
Also I’ve just edited a page (changed just one link) and most of the counters were reset to zero and this is reflected in the database … (according to Data Explorer).
@zogstrip I saw you were looking at this, you might be interested:
Some additional observations: I just changed the ownership of that table-of-content post I mentioned earlier and the effect was that all (both internal and external) links had their counters reset to 0; all but the first link in the post (which is an external link).
So there is definitely some huge incoherent behaviour here.
But apart from that it would be more coherent if all counters were reset (or only internal ones or only external ones), I’m wondering whether a change of post ownership should/needs to reset any counter at all? After all, information is being destroyed here.
My proposal would be that neither rebaking nor change of ownership should reset counters.
Yes.
It should.
Yes, the fix is not retro-compatible.
In the case of the bug I fixed, that was because there was a discrepancy between the cooked link and the link we stored to count the clicks.