Internal URL Filters

Your friendly marketer is interested in the beginning and the end of a visitor’s visit. She wants to know where they came from, how long they were around, how many pages they saw and so on.

How do we technically determine those two important moments?

The Beginning of a Visit

Let’s look at the start first. (D’uh. Obviously.)

HTTP is a stateless protocol, so how do we know that a request for a specific page is the first in a visit?

Well, we sort of don’t. But we can use two mechanisms to help:

  1. Time — if there was a previous request from “the same person”, “not too long ago”, then we guess this is not the first request. More on time later when we look at the end of a visit.
  2. The HTTP Referer header — the HTTP Referer tells us where the browser came from, allowing us to see whether it was our own site or another.

Funny enough, those methods are anything but water-tight. But that doesn’t mean our friendly marketer wouldn’t want ot use them. She still wants to know where people came from when they enter your site, and the HTTP Referer is a good place to start.

One problem: since there is an HTTP Referer on every GET, we’d in most cases see our own site at the top of any list! So we need to add the concept of an “internal URL”, a URL that belogs to our site and should therefore not be considered an external link.

You can tell Adobe Analytics which URLs are considered internal. Go to the Report Suite Manager under Admin Tools. Select one or more report suite(s), then go to Edit Settings > General > Internal URL Filters.

Menu for Internal URL
You can now add one or more URLs that the system should treat as internal.

Note: those URLs can be complete URLs or just parts. The system will simply match what you typed to the URL in the HTTP Referer header.

Internal URL Settings
To make one thing perfectly clear: this setting only applies to visit starts! That means: reports like Referring Domains, Search, everything under Traffic Sources, basically.

Visit Endings

The end of a visit is even harder to detect than the beginning. Technically, nothing happens when a visit ends, at least nothing that our web server would get any wind of.

A visitor might close the tab or their browser. They might switch off their machine or close it. They might run out of battery or move into an area that has no network. They might even leave their machine at their desk and go for lunch or have a chat.

Some of that might be detectable, but web analytics vendors have at some point looked at all those scenarios and decided “nah, let’s work with a timeout. 30 minutes? Sounds great, let’s do it!” So it became an industry standard.

The actual timeout happens in the processing steps in the backend. The frontend (Javascript) has nothing to do with the timeout at all. Which makes sense, because why would you waste a server call?

So the timeout doesn’t really concern you as a developer, and that’s probably a good thing.

People clicking a link off site does, though. If on your site there are links that point to others, your marketer will want to know about visitors going there.

Fortunately, tracking this is really easy. In fact, it is almost out-of-the-box. All you have to do is configure it in the configuration section of the s_code.js file.

s_code – configuration section part 1
Citing from the original article:

Exit links are links on your site that transport the visitor off the site and somewhere else. Two variables configure how Adobe Analytics treats these links:

  • s.linkInternalFilters defines all URLs that are considered internal, therefore allowing the code to see which links are not.
  • s.trackExternalLinks controls whether the code should automatically track those or not.

The list in s.linkInternalFilters is a list of substrings of URLs which will be matched against the href parameter of any link clicked on the page. If the URL does not match, the system tracks the click as an “Exit Link”.

Fun fact: if you put a “.” into s.linkInternalFilters, the Javascript code will basically treat the whole Internet as internal. You will therefore not see any exit links in the reporting. Good for a development site with changing URLs, bad for production.

In essence, the decision about whether a link is external and should therefore be tracked has to be made in Javascript because if it should be tracked, well, it has to be tracked. It’s the browser that must send the tracking call, which means that the decision has to be made in the browser.


You might have noticed that the two settings are only loosely related to the beginning and the end of a visit. Bonus points for that.

As we said: your marketer likely doesn’t care that much. He might not even understand the difference. But he definitely wants to know where people came from and whether they clicked any off-site links. And that you can find out with the help of the two settings we discussed.

I think it goes without saying that the URLs in both places should be the same. There is only very few use cases for having different URLs, in fact I can think of none.

We should also mention a special case: off-site payment systems.

If in your checkout process, your site directs people to paypal or any other payment site before receiving them back for some confirmation page, make sure you add the URL of your payment provider to both places!

9 thoughts on “Internal URL Filters

  1. Thanks Jan,

    It would be easy to confuse those two settings. To clarify, s.linkInternalFilters and s.linkExternalFilters change what we see in the traffic sources and exit links reports, but do they impact the visits metric?

    Best regards,



    1. Hi Billy,

      Good point! They don’t. Visits are only calculated in the backend.

      And the two settings don’t change the Traffic Sources reports, either, only the Admin Tool Setting does.



  2. Lately I’ve observed newly created Report Suites to be set up with a dot “.” in the Internal URL Filters (in admin NOT in s_code.js). That also makes the whole Internet internal. So watch out for that setting, when you create new Report Suites!


  3. Thanks Jan,

    It’s great to get clarity on all these little bits and bobs. 🙂

    If you’re ever running low on blog post topics i’d love to hear more about the new link handling functionality in the App Measurement code. It sounds pretty cool on the face of it, but I get the feeling there might be a few watch outs to be aware of.




  4. Really incredible your post and your clean explanations, you’re becaming Omniture to an understandable tool :S. 4 months ago I started Omniture implementation maintainance and also I want migrating this to DTM, and your posts help me a lot.

    Many thanks 😀



  5. An “oldie but goody” post, thanks for the good reading as always!

    Here’s my question now…. does “javascript:” need to be an entry in the Internal URL Filters panel the same way it’s an entry in the s.linkInternalFilters setting?

    2nd question, if “javascript:” is the first entry in the s.linkInternalFilters setting, why does a pixel still fire into Adobe Analytics? Shouldn’t it be suppressed as an ‘exit link’? I would love to economize those server calls if possible….

    Thanks for any info/ideas about the above – it’s not easy to find much info on these topics!


      1. Thanks for the reply/discussion!

        Unfortunately, in my reports I’ve got rows and rows of links beginning with “javascript:” in a legacy implementation. (The devs used some deprecated techniques without a doubt)

        I would like to debug the exit link event listener code and figure out why these link tracking calls still happen, but it’s kind of a bear. Then there’s this issue with someone in the past renaming the s code object name to something other than “s”. (oh my!)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.