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. (https://tagtician.com/)
  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[event.rule.name] – 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 Fix Referrer Data Getting Lost

Email : A referring domain is considered as an email referring domain when visitors click an emailed message link containing the protocol imap:// or mail:// and arrive at your site. For example, anything coming from https://mail.yahoo.com is not counted as an email referrer because the protocol is https://. Emails from Outlook are reported in the Typed/Bookmarked line, while any referrer with an HTTP protocol where the domain is a known search engine is reported in the Search Engine line.

Reference: https://docs.adobe.com/content/help/en/analytics/components/variables/dimensions-reports/reports-ref-types.html

When you get a email or a mobile campaign, and keep a close eye on the url window, you’ll notice the click goes to your campaign solution provider and is then redirected to your site.

That’s one example of a redirect.

That is not an issue.

Make sure they are permanent, 301, redirects. The delicious type of redirects that dutifully pass the referrer string to the landing page telling your web analytics provider where the person originally came from.

You use temporary, 302, redirects and the referrer never gets passed on. Depending on how the redirect server is configured either the click looks like it came from the redirect server or with a blank referrer (direct!).

This is particularly important for URLs that are entry points on your site, as without original referrer data, you cannot know the source of sales and conversions on your site. Anyway, on to the results.

Redirect methodBrowserResultImpact on analytics
Meta refresh – 0Firefox 3Blank referrerLost data
IE8Blank referrerLost data
Opera 9Internal referrerLost data
Javascript:location.hrefFirefox 3Internal referrerLost data
IE8Blank referrerLost data
Opera 9Internal referrerLost data
Javascript:location.replaceFirefox 3Internal referrerLost data
IE8Blank referrerLost data
Opera 9Internal referrerLost data
Server-side 301Firefox 3Original referrer
IE8Original referrer
Opera 9Original referrer
Server-side 302Firefox 3Original referrer
IE8Original referrer
Opera 9Original referrer
Server-side 301 – chainedFirefox 3Original referrer
IE8Original referrer
Opera 9Original referrer


While there’s nothing too unexpected in the results, it’s clear that the only way to redirect visitors and have reliable web analytics data is to use a server-side redirect. No javascript or meta-based method works, in all cases resulting in an empty or internal referrer (which will misleadingly show up as bookmark/direct in most analytics packages). Interestingly, javascript and meta redirects can result in totally blank referrer data in some browsers.

Server-side methods worked across all major browser tested, and you can get away with chaining redirects together while still keeping the referrer data.

Basic Steps To Launch setup

Steps to follow for Launch setup:

  1. Create web property in Launch
  2. Set up Host
  3. Setup environment
  4. Install extension
  5. Deploy the script in web/mobile app
  6. Capture data in context data and use processing rule to map that data into analytics variable in case of mobile
  7. Capture the data in data element and put the value of data element in analytics variable
  8. Setup Rules
  9. Send Beacon
  10. Publish the Library

Launch guide : https://docs.adobe.com/content/help/en/launch/using/overview.html

Mobile app implementation guide:https://aep-sdks.gitbook.io/docs/getting-started/create-a-mobile-property

Check this if you are planning to upgrade from DTM to Launch: https://docs.adobe.com/content/help/en/launch/using/reference/upgrade/overview.html

Is an IP address considered “personal information” under the CCPA?

The California Consumer Privacy Act (“CCPA”) was enacted in early 2018 as a political compromise to stave off a poorly drafted, and plaintiff’s friendly ballot initiative.  Although the CCPA is scheduled to go into force in early 2020, there is a great deal of confusion regarding the requirements of the CCPA, including the degree to which it aligns with other privacy regulations such as the European General Data Protection Regulation (“GDPR”).

To help address that confusion, BCLP published the California Consumer Privacy Act Practical Guide, and is publishing a multi-part series that discusses the questions most frequently asked by clients concerning the CCPA.

Q. Is an IP address considered “personal information” under the CCPA?


Personal information is defined by the CCPA as “information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household.” While the Act provides a list of examples of personal information – which explicitly includes “Internet Protocol Address” – it qualifies the examples by stating that they only fall within the definition of personal information if they identify, relate to, describe, are “capable of being associated with,” or “could be reasonably be linked” with a particular person. 

In order to determine whether an IP address is linked to a person, it is important to understand what an IP address represents.  Computers that access the internet are assigned either a static or a dynamic Internet Protocol (“IP”) address.  A static IP address does not change over time (i.e., it is dedicated to a particular computer to that network or user).  A dynamic IP address is assigned by a network when a computer connects and, thus, changes over time (e.g., each time that the user reconnects to the network). 

When examining whether a static or a dynamic IP address constitutes personal information, California courts may look to how European regulators viewed IP addresses in the context of the European GDPR’s definition of “personal data” which is substantially similar to the CCPA’s definition of “personal information.”  The Article 29 Working Party took the position that because static IP addresses do not change, and IP addresses can be used to identify the computer (or user), “[t]he possibility exists in many cases . . . of linking the user’s IP address to other personal data . . . that identify him/her, especially if use is made of invisible processing means to collect additional data on the user (for instance, using cookies containing a unique identifier)….”  The Working Party further recognized that because of the nature of dynamic IP addresses in some cases “a third party can get to know the dynamic IP address of a user but not be able to link it to other data concerning this person that would make his/her identification possible.”

Source: https://www.bclplaw.com/en-US/thought-leadership/privacy-faqs-is-an-ip-address-considered-personal-information.html

Adobe Analytics /Resources/Article/Post Index

Often we need to check for reference or to clear doubt what we know about Adobe Analytics. So I manage to maintain reference list in Excel for my personal use, today I thought to share this list on my blog that others can take benefit out of it too. Some of them are now outdated due to new advances in Adobe Analytics. I tried my best to give credit to actual author of the blog/article, even I tried to keep this list in order as much as possible and will keep on updating it as I come across other good reference links. Feel free to share your feedback or share the link which you want me to add in this list or do let me know if you have any questions.

Stay safe!

How To Implement Adobe Analytics in Hybrid App

For the purposes of this conversation, I’ll use the following definitions:

  • Native apps are built for a specific platform with the platform SDK, tools and languages, typically provided by the platform vendor (e.g. xCode/Objective-C for iOS, Eclipse/Java for Android, Visual Studio/C# for Windows Phone).
  • Mobile Web apps are server-side apps, built with any server-side technology (PHP, Node.js, ASP.NET) that render HTML that has been styled so that it renders well on a device form factor.
  • Hybrid apps, like native apps, run on the device, and are written with web technologies (HTML5, CSS and JavaScript). Hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in Mobile Web applications, such as the accelerometer, camera and local storage.

Hybrid apps are a great option for you if you:

  1. Want to target multiple mobile platforms
  2. Want to take advantage of device capabilities like geolocation, accelerometer or the camera
  3. Want the app to be useable when the device is offline
  4. Don’t need the advanced graphics performance that you can only get from a native app.

Hybrid apps are built with web technologies which means there are millions of web developers who already have the base skill set to build mobile apps.

Adobe Analytics tracking can be enabled for Hybrid app by creating 2 web property in Adobe Launch