Segregate Internal & External Traffic In Adobe Analytics

Within the Adobe Analytics tool there are 4 main ways to deal with IP address exclusions:

1) Out of the box “Exclude by IP” functionality

This method can be accessed by going to the global ‘Admin’ drop down menu and selecting “Exclude by IP”.  Instructions on how to use this are contained within the page and it is by far the easiest method of removing traffic from specific IP addresses/ranges.

However, the disadvantage of this is that any excluded data is effectively lost for ever so this is not suitable if you ever want to analyse data from internal traffic for a given report suite.

Hint: what is not immediately obvious is that the exclusions work on a report suite by report suite basis – you need to make sure the correct report suite is selected in the top right hand corner

2) Get Adobe engineering to build a DB VISTA Rule

Typically this method would be used if you wanted to siphon off the internal traffic into a separate report suite to analyse separately from your external traffic.  However, Adobe engineering have an awful lot of flexibility within VISTA rules you are not limited on just siphoning data to a separate report suite if you can think of something more creative that you want to do!

The basic approach would be for Adobe Engineering to build a “DB” (Database) Vista rule that allow you to upload and manage via FTP a list of IP address that are excluded (i.e. allowing you to manage going forward without further intervention from Adobe Engineering).

As with all VISTA rules there will almost certainly be a cost associated with this.

3) Use Processing Rules in combination with Virtual Report Suites

IP address is available in processing rules, even if you’ve set your privacy settings to remove IP a ddress from your data.

This means you can using processing rules to set a value into a variable whenever you see an internal IP address (e.g. overwrite prop1 with a custom value of “internal traffic”)

The value captured can be used to segment your data or, as we do, used to created virtual report suites (e.g. one with external traffic, one with internal traffic)

The advantages of this is that it is non destructive and there is no cost. Though it is not retroactive process and will be affective after the setup.

4) Use segment or VRS

If you have list of IP address available in report suite then you can create segment and apply that on reports or create a VRS and you can share that VRS to stake holders. It is retro-active process.

How To Enable Or Disable Activity Map in Adobe Launch

Once Activity Map is enabled for an Adobe Analytics report suite, it can not be disabled, and so instead Adobe recommends that you remove the Activity Map module from your implementation to disable the functionality. 

AppMeasurement.js self-hosted

This can be completed simply by accessing your AppMeasurement.js and removing the Activity Map module. 

AppMeasurement.js hosted via the Adobe CDN

By default on console if you type s_c_il it will show the following.

Now to disable Activity Map.You have to use the available latest version of Adobe Analytics Extension so if it is not upgraded then upgrade that.

Go to the configuration of Adobe Analytics Extension and disable Activity Map by unchecked the box

After this publish the build and reload the page and this time the Activity Map will not load and can be checked through console.

In case you don’t want to stop the tracking through Activity Map but want to limit the tracking then you can check Activity Map Customizer Extension.

Feel free to comment in case you have any question or add any insights.

Why should I use HTTPS and how it impact Web Tracking?

HTTPS is an encrypted communication protocol — essentially, a more secure way of browsing the web, since you get a private channel directly between your browser and the web server. That’s why most major sites use it.

If a site’s using HTTPS, you’ll see a little padlock icon in the address field, just as in the screenshot below:

Screenshot of the "secure site" padlock icon

Here are the most common reasons you might want to use HTTPS on your own site:

Faster. One might think that HTTPS would make your site slower, since it takes some time to encrypt and decrypt all data. But a lot of efficiency improvements to HTTP are only available when you use HTTPS. As a result, HTTPS will actually make your site faster for almost all visitors.

Trust. Users find it easier to trust a secure site. While they don’t necessarily know their traffic is encrypted, they do know the little padlock icon means a site cares about their privacy. Tech people will know that any servers between your computer and the web server won’t be able to see the information flowing forth and back, and won’t be able to change it.

Payment security. If you sell anything on your site, users want to know their payment information is secure. HTTPS, and the little padlock, assure that their information travels safely to the web server.

Search Engine Optimization. Many search engines will add a penalty to web sites that don’t use HTTPS, thus making it harder to reach the best spots in search results.

Your good name. Have you noticed that some websites have the text “not secure” next to their address?

That happens when your web browser wants you to know a site is NOT using HTTPS. Browsers want you to think (rightly!) that site owners who can’t be bothered using HTTPS (it’s free in many cases) aren’t worth your time and certainly not your money.

In turn, you don’t want browsers suggesting you might be that kind of shady site owner yourself.

How it impact referrer for Web Analytics tools:

Never Tag for an eVar or Mbox Again,Meet Alloy.js

Over the years, as Adobe has built or acquired new technology and collected lots of JavaScript libraries — AppMeasurement.js, mbox.js, at.js, DIL.js, Visitor.js, just to name a few. Each has its own strengths, features, history, functions, schema, quirks and interdependencies. Although Adobe Experience Platform Launch makes it as easy as possible to manage all these libraries, customers have been asking us for years why we can’t just have one JavaScript tag and library. 

Now meet the new Alloy.js. Adobe worked hard all year to take all the best features of our current libraries and build a new one that supports Adobe Experience Platform, Adobe Analytics, Adobe Audience Manager and Adobe Target. One library and beacon, sent to a single destination, then mapped and sent to all your Adobe solutions server side. And that’s just the beginning.

Alloy is the code name for the Adobe Experience Platform Web SDK. It allows for streaming data into the platform, syncing identities, personalizing content, and more.

For documentation on how to use Alloy, please see the user documentation.

For documentation on how to contribute to Alloy, please see the developer documentation

Adobe Web SDK (alloy.js) FAQ’s


How to Run Analysis on Adobe Launch Rules

Combination of Launch,Tagtacian & Adobe analytivs

If you want to do analysis on your Adobe Launch Rules.

 Find out what rules are most frequently used? Or which rules are failing?

This document provides a quick and simple way to leverage Tagtician (3rd party tool) and Adobe Analytics to track the performance of your Adobe Launch configuration and answer some of the basic questions surrounding your implementation. It will help answer the following questions:

  • Which rules run most, and which haven’t run over a period of time?
  • Which rules triggered but failed over conditions?
  • Which rules have triggered a certain Tag/Extension/Action most?
  • Which page of your site is the rule firing?

Getting these answers wouldn’t be just interesting but would help you to optimize/audit your Launch property by:

  • Removing rules/tags/extensions which haven’t run lately and have become obsolete.
  • Checking rules which aren’t supposed to run before/after a certain point in time.
  • Auditing if a certain rule/tag has stopped working suddenly.
  • Auditing if there are too many rules which fail over conditions on a single page (You might want to change the event).

To achieve this, here is high level plan:

  1. Tagtician Export of your Launch Library. (
  2. A Launch rule to track rule names using Launch library monitoring APIs.
  3. A list prop to capture rules’ names and classification reports to upload other data pertaining to Launch Rules.

Alright! Let’s get started…

1. Getting Ready:

1. Get Tagtician export of your Launch property.

2. Copy names of all the rules from Tagtician export and paste them in a new sheet. In the next column, name them as R1, R2, R3 so on…

Tagtician Export Launch Rules

3. Now create a JSON with rule names as Keys and abbreviations as Values. You can name JSON as “ruleLookUp”.

var ruleLookUp = {
"All Pages | DOM Ready | AA":"R1",
"All Pages | Lib Loaded | AT":"R2",
"User Login | Successful | AA":"R3",
"Impression | Media Pixels | gTag":"R4",
"PDP | DOM Ready | AA":"R5",
"Search Results | DOM Ready | AA":"R6",
"Search | Direct Call | AA":"R7",
"PDP | Add to Cart| Click | AA":"R8",
"Cart | Coupon | Click | AA":"R9",
"Cart | Removal | Click | AA":"R10",
"Transaction | DOM Ready | AA":"R11",
"FirstPage | LinkText | Click | FB - addToCart":"R12",
"Form Submit | Direct Call | AA":"R13",
"All Pages | Window Loaded | AA - Send Beacon":"R14",
"Video | Direct Call | AA":"R15",
"Link Click | Click | AA":"R16",
"Search | Filters | Direct Call | AA":"R17"

4. Enable two props in Adobe Analytics e.g. prop1 and prop2, name them “Rules Fired” and “Rules Failed Over Conditions” respectively.

5. Turn list support ON for these props with delimiter ‘|’.

2. Launch configurations

1. Create a rule in Launch with the following configurations:

Event: Library Loaded (Page Top) with Order 1
Condition: N.A.

This rule is supposed to run 1st on each page load. In case of SPA, you might want to change the event but ensure the order.

2. Now add Action – custom code JavaScript type – in the rule.

3. Now the idea is to capture rules which completed and those which failed over conditions into two separate arrays and put them in list props and send them in page load beacon.

For this, you will need to use Adobe Launch monitoring APIs.

var ruleCompleted = new Array();
var ruleConditionFailed = new Array() ;
window._satellite = window._satellite || {};
window._satellite._monitors = window._satellite._monitors || [];
ruleCompleted: function (event) {
ruleConditionFailed: function (event) {


The above APIs (both _satellite._monitors and _satellite._container) should not be accessed from production code. They are intended only for debugging purposes and may (will) change over time as needs dictate. If you have debugging turned on, you’ll see a related warning in the console when using these APIs. Please take this warning seriously.

4. At this moment we have two problems:

  • How to capture rules which triggers after the send beacon rule e.g. click/interaction rules, direct calls rules, 3rd party rules, etc.
  • Max size of list props is 100 bytes and may easily run out of it.

Solution to these problems are Local Storage and using Rules abbreviation (instead of full name) respectively.

5. Here is how the final code will look like:

var ruleCompleted = new Array();
var ruleConditionFailed = new Array();
var ruleLookUp = {
"All Pages | DOM Ready | AA":"R1",
"All Pages | Lib Loaded | AT":"R2",
"User Login | Successful | AA":"R3",
"Impression | Media Pixels | gTag":"R4",
"PDP | DOM Ready | AA":"R5",
"Search Results | DOM Ready | AA":"R6",
"Search | Direct Call | AA":"R7",
"PDP | Add to Cart| Click | AA":"R8",
"Cart | Coupon | Click | AA":"R9",
"Cart | Removal | Click | AA":"R10",
"Transaction | DOM Ready | AA":"R11",
"FirstPage | LinkText | Click | FB - addToCart":"R12",
"Form Submit | Direct Call | AA":"R13",
"All Pages | Window Loaded | AA - Send Beacon":"R14",
"Video | Direct Call | AA":"R15",
"Link Click | Click | AA":"R16",
"Search | Filters | Direct Call | AA":"R17"
window._satellite = window._satellite || {};
window._satellite._monitors = window._satellite._monitors || [];
ruleCompleted: function (event) {
localStorage.setItem("ruleCompleted", ruleCompleted.join("|").toString());
ruleConditionFailed: function (event) {
localStorage.setItem("ruleConditionFailed", ruleConditionFailed.join("|").toString());


ruleLookUp[] – returns rules abbreviation
join(“|”).toString() – converts array into pipe separated string to cater list props
localStorage.setItem – put rules fired after send beacon rule into local Storage

6. Now, go to your rule which sends page load beacon on every page e.g. “All Pages | Window Loaded | AA – Send Beacon”

7. Go to that rule > Actions > Set Variable – Adobe Analytics > Open Editor and paste the below snippet.

ruleCompleted = [];
ruleConditionFailed = [];

8. Add these changes to your library > Build and Publish it. And we are DONE from Launch configurations.

3. Adobe Analytics configurations

1. Create Classifications reports on the list props e.g. You can add/remove classification reports as per your needs.

2. Download the classification template and fill it using Tagtician export file.

3. Upload the file using Browser Import and check the reports after some time.

4. Now you can run classification reports to pull some cool insights for both prop1 & prop2

Note: This report is from sandbox account so showing very less data.

Adobe Analytics dashboards-Mobile App

I believe that you are aware that the Adobe Analytics dashboards is launched if not then the wait is over. Mobile App is launched now and it is available in Andriod and iOS. it provides anytime, anywhere insights from Adobe Analytics.

The app allows users mobile access to intuitive scorecards.

Adobe Analytics dashboards In-App Experience
Adobe Analytics dashboards Scorecard Builder

For more details check the overview and download the App,

How To mitigate the impact of ITP 2.1, ITP 2.2, and future ITP releases-Adobe Analytics

ITP 2.1 Capped client-side cookies that are placed on the browser using the document.cookie API to a seven-day expiry. Released February 21, 2019.
ITP 2.2 Drastically reduced the seven-day expiry cap to one day. Released April 24, 2019.

To mitigate the impact of ITP 2.1, ITP 2.2, and future ITP releases, complete the following tasks:

  1. Deploy the Experience Cloud ID (ECID) library to your pages.

The ECID library enables the people identification framework for Experience Cloud Core solutions. The ECID library allows you to identify same site visitors and their data in different Experience Cloud solutions by assigning persistent and unique identifiers. The ECID library will be updated frequently to help you mitigate any ITP-related changes that impact your implementation.

For ITP 2.1 and ITP 2.2, ECID library 4.3.0+ must be utilized for mitigation.

Check the link too:

2. Use Adobe’s CNAME and Enroll in Adobe Analytics’ Managed Certificate Program.

After installing the ECID library 4.3.0+, you can leverage Adobe Analytics’ CNAME and Managed Certificate Program. This program lets you implement a first-party certificate for first-party cookies at no charge. Leveraging CNAME will help customers mitigate the impact of ITP 2.1 and ITP 2.2.

If you are not leveraging CNAME, you can start the process by talking with your account representative and enrolling in the Adobe Managed Certificate Program .

How To Classify Page Load Time In Adobe Analytics

I captured page load time in prop as mentioned in this article:


This will assign the page load time, in tenths of a second, to prop1. For example, if my page took 3.75 seconds to load, I would get a raw value of 38 in the Page Load Time (prop1) report.

So I did it simple by capturing the page load time in seconds.


If you are using the Launch and Extension: Common Analytics Plugins then under page load rule you have to deploy following code and in this case the report will be in sec so no need to divide the result by 10:

// Get Page Load Time
if(s.pageName) s.getPageLoadTime();
s.prop10 = s._pltLoadTime;
s.prop11 = s._pltPreviousPage;
s.eVar11= s._pltPreviousPage;

console.log(“Page Load Time – ” + s.prop10);
console.log(“Prev Page Name – ” + s.prop11);

The getPageLoadTime method does not use any arguments. When calling this method, it does not return anything. Instead, it sets the following variables:

  • s._pltPreviousPage : The previous page so you can correlate load time to the previous page
  • s._pltLoadTime : The time in seconds that the previous page took to load

The getPageLoadTime plug-in creates two first-party cookies:

  • s_plt : The time, in seconds, that the previous page took to load. Expires at the end of the browser session.
  • s_pltp The value of the s.pageName variable as recorded in the previous Adobe Analytics image request. Expires at the end of the browser session.

Following is the report which I start getting after this:

This data is not much helpful for the marketer to understand data so it needs to be classified into range. I decided to create a classification for prop1 as shown below:

There are 2 option to classify the data.

  • Classification file upload
  • Classification rule builder

In classification rule builder we have to use Regx.

Less than 1 Sec : \b(^0|0.[1-9])\b

1-3 Seconds: \b(^1|1.[0-9]|^2|2.[0-9])\b

3-5 Seconds: \b(^3|3.[0-9]|^4|4.[0-9])\b

5-10 Seconds: \b(^5|5.[0-9]|^6|6.[0-9]|^7|7.[0-9]|^8|8.[0-9]|^9|9.[0-9])\b

More than 10 Seconds: [1-9][0-9]

After processing the data in report will look like as shown below: