Adobe Analytics Implementation Guide

For information about the differences between the Dynamic Tag Management and JavaScript methods, see

bookmarklet. After it is installed, load a page where you have deployed page code and then open the debugger. The debugger displays details about the collection data that was sent.

Adobe Analytics Implementation 10

More Information

Choose an Implementation Method

The

Admin & Analytics Reference

provides report and metric descriptions, and admin reference information for

Adobe Analytics.

For a concise overview of the getting started process and help on quickly setting up your first Analytics report suite, see

Getting Started with Analytics Implementation

in the Getting Started with Analytics guide.

Release Notes

Release notes can be found at the following locations:

•

Marketing Cloud - All Solutions

•

AppMeasurement Libraries - All Platforms

Analytics Basics 11

Analytics Basics

Learn about the basics of Analytics, including terms, what's in the code, and how data is collected.

Logging In to Adobe Analytics

To learn how to log in to Analytics, refer to

Logging In to Reports and Analytics

in the Reports & Analytics Interface

Help.

Marketing Cloud Debugger

The Adobe Debugger (previously DigitalPulse Debugger) is a free tool provided by Adobe that lets you view the data being collected from your site on any given page.

See

For information about using Dynamic Tag Management to create the header and footer code for you, see

Alerts

Intelligent Alerts let you create and manage alerts in Analysis Workspace, complete with alert preview and rule contribution.

You can

• Build alerts based on anomalies (90%, 95%, or 99% thresholds; % change; above/below).

• Preview how often an alert will trigger.

• Send alerts by e-mail or SMS with links to auto-generated Analysis Workspace projects.

• Create "stacked" alerts that capture multiple metrics in a single alert.

You can access this new Alerts system from More > Alerts in any report in Reports & Analytics.

See

Alerts

in the Reports and Analytics Help.

Analytics Code

Data is sent to a report suite to display in reporting. The easiest and most common way to send data to Analytics is by using the DTM implementation. You can also enter the code with the JavaScript implementation.

Add Header and Footer Code

Here is an example of AppMeasurement JavaScript file, showing the code parts:

Analytics Basics 12

Classifications

Classifications are created by grouping (classifying) granular data from a source report.

For example, you might want to analyze display ads, but they are mixed with email, partner, text ad, and social media campaigns. You can create groups so that you can analyze them separately.

For more details, see:

•

Classifications

in the Analytics Help and Reference guide

Analytics Basics 13

Conversion Variables (eVar)

The Custom Insight Conversion Variable (or eVar) is placed in the Adobe code on selected web pages of your site.

Its primary purpose is to segment conversion success metrics in custom marketing reports.

eVars are best used to measure cause and effect, such as:

• Which internal campaigns influenced revenue

• Which banner ads ultimately resulted in a registration

• The number of times an internal search was used before making an order

Important: When implementing Analytics, it is important to know which eVars you will use, and how many.

You should also understand how to configure those eVars in the Admin Console. For detailed information about eVars, see Conversion Variables (eVar) in the Analytics Help and reference documentation.

An eVar can be visit-based and function similarly to cookies. Values passed into eVar variables follow the user for a predetermined period of time.

When an eVar is set to a value for a visitor, Adobe automatically remembers that value until it expires. Any success events that a visitor encounters while the eVar value is active are counted toward the eVar value.

For more information about variables, see:

•

Variables for Analytics Implementation and Reporting

in this help

•

Variables - How They Are Used in Reporting

in the Analytics help

•

Page Variables

in this help

•

•

•

Products Variable

in the Mobile SDK documentation

Data Collection

Learn how visits to your web site become a report in Adobe Analytics.

Adobe has created multiple ways to send data into Analytics. These methods include tracking information in real-time from:

• Applications that can access the Internet

• Campaigns

• Client-server applications

• Emails

• Mobile devices

• Web-based kiosks

• Web sites

1. When a visitor comes to your site, a request is made to your web server.

Analytics Basics

2. Your site's web server sends the page code information, and the page displays in the browser.

3. The page loads, and the Analytics JavaScript code runs.

The JavaScript code sends an image request to the Adobe server, passing the variables, metrics, and page data that you defined in your implementation.

Example JavaScript Code: The JavaScript code is placed within the body tags of a web page:

Example Image Request: A snippet of an image request with the page name outlined:

Analytics Basics 15

Note: Each image request contains a random number string to prevent browser caching and ensure that subsequent image requests are made by the browser.

4. Adobe returns a transparent pixel image.

The code automatically collects additional details (such as operating system, browser type, browser height and width, IP address, and browser language).

5. Adobe servers store web analysis data in report suites (your data repository).

report suite

defines the complete, independent reporting on a chosen website, set of websites, or subset of web pages.

6. Report suite data populates the reports that you can access in a web browser.

Example report:

Analytics Basics 16

The JavaScript code execution occurs quickly and does not noticeably affect page load times. This approach allows you to count pages that were displayed when a visitor clicked Reload or Back to reach a page, because the JavaScript runs even when the page is retrieved from cache.

For more details, see:

•

Data Collection

in this help documentation

•

Create a Data Element

in this help documentation

•

Data Warehouse

in the Analytics Help and Reference guide

•

Ad Hoc Analysis

help

•

Exclude by IP Address

in the Analytics Help and Reference guide

•

Data Sources

whitepaper

•

Data Connectors

in Using FTP and sFTP with the Adobe Marketing Cloud

•

Clickstream Data Feeds help

Code Manager

Code manager lets you download data collection code for web and mobile platforms.

Analytics > Admin > Code Manager.

After you download the library, you must configure the code to send data to the correct tracking server and report suite. Additional implementation resources are available at

Developer & Implementation

Analytics Basics 17

Code Manager Page Descriptions

Column Description

Name The name matches the platform where you want to enable data collection. Native libraries are provided for each platform listed in this column.

Type Type of applications that can be measured using each library.

Version

Documentation

List the latest version of the library. Click the version number to view the release history.

View the library reference documentation.

Data Layer

A "data layer" is a framework of JavaScript objects that developers insert into pages. The data layers can be used by tracking tools (including tag management systems like Dynamic Tag Management) to populate reports.

Implementing a data layer on your site provides ultimate control and flexibility over your implementation and allows easiest maintenance in future phases. The names of these JavaScript objects are theoretically arbitrary, but the best practice is to use something consistent and predictable. The developers may already have a data layer, or a preference for the format. There are few different standards the tracking community has created as a starting point.

The

Data Layer for Analytics Implementation

specification document uses the W3C standard "digitalData" object

that is accepted by the widest variety of tracking technology, in case there is a need to use the data layer for more than this DTM implementation.

Events

Events keep track of when a visitor has performed a specified action.

An event should be considered a milestone within a site. Success events are most commonly populated on the final confirmation page of a process, such as a registration process or newsletter sign-up.

Common types of events include:

• Success events

• Currency events

• Custom events

For detailed information, refer to

Configure Events

Success events are described in detail in the

Analytics Help and Reference

Metrics

Metrics

are quantitative information about visitor activity, such as Views, Click-Throughs, Reloads, Average Time spent, Units, Orders, and Revenue.

Analytics Basics 18

Metrics are the foundation of reports and help you view and understand data relationships. They let you perform side-by-side comparisons of different data sets about your website.

Metric Type Definitions

Traffic metrics Page View: One Web page load in a user’s browser (one execution of the Reports & Analytics code).

Visit: Any number of page views when visitor comes to your site. A visit ends after 30 minutes of inactivity.

Unique Visitor: A person visiting your site for the first time during a given time frame, such as Hour, Day, Week, Month, Quarter or year.

(This also includes Unique Visitors for any time frame.)

Conversion metrics

Video metrics

These show data about success events, such as purchases, downloads, or any other action that you want users to take on your website.

Analytics provides support for tracking a number of video metrics, including total views, time spent, and completion rates.

Social metrics You can measure your brand's presence on the social web. Social metrics work with Analytics standard metrics. By combining these with calculated metrics, you can view a report that shows how often a product is mentioned, gauge product sentiment, and see how Social metrics correlate with Analytics key performance indicators.

Calculated metrics

Calculated metrics

enable you to combine metrics to create mathematical operations that are used as new metrics. These metrics can be created for a report to which you add metrics. Administrators can create calculated metrics for all users of a report suite.

See

Metrics

in Analytics Help and Reference for metric definitions.

Processing Rules

Processing rules simplify data collection and manage content as it is sent to reports.

Processing rules help simplify interaction with IT groups and Web developers by providing an interface to:

• Set an event on the product overview page

• Populate campaign with a query string parameter

• Concatenate category and page name in a prop for easier reporting

• Copy an eVar into a prop to see paths

• Clean up misspelled site sections

• Pull internal search terms or a campaign ID from the query string into an eVar

For details about processing rules, see:

•

Processing Rules

in the Analytics Help and Reference guide

Analytics Basics

•

Create New Rule

in this help documentation

•

Getting Started with Marketing Channels

in the Marketing Channels documentation

•

VISTA Rules

in the Analytics Help and Reference guide

•

Bot Rules

in the Analytics Help and Reference guide

Reports and Report Suites

report suite

defines the complete, independent reporting on a chosen website, set of websites, or subset of web pages. Usually, a report suite is one website, but it can be a global segment where you have combined several sites' numbers to get totals. When you log in to the marketing

reports

ad hoc analysis

, and

report builder

, you select one report suite to use (except when you use roll-ups that combine report suites).

Reports provide information about the data collected by Analytics, based on specific parameters.

You can run an Analytics report after implementing Adobe Analytics. Reporting provides insights into your traditional web-based channels as well as evolving channels like mobile, video, and social networking. Some examples of marketing reports include:

• How many people visit your site

• How many of those visitors are unique visitors (counted only once)

• How they came to the site (such as whether they followed a link or came there directly)

• What keywords visitors used to search site content

• How long visitors stayed on a given page or on the entire site

• What links visitors clicked, and when they left the site

• Which marketing channels are most effective at generating revenue or conversion events

• How much time they spent watching a video

• Which browsers and devices they used to visit your site

High-level report types include:

•

Traffic

: Gives you in-depth insight into how visitors interact with your website, and your customized traffic statistics.

•

Conversion

: Displays information about success indicators that you define.

•

Paths

: Enable you to track and record entire browsing paths of visitors.

You can use

Analysis Workspace

to remove the typical limitations of a single Analytics report. It provides a robust, flexible canvas for building custom analysis projects. Drag-and-drop any number of data tables, visualizations, and components (dimensions, metrics, segments, and time granularities) to a project. Instantly create breakdowns and segments, create cohorts for analysis, create alerts, create segments, and curate reports for sharing with anyone in your business.

See Also

•

Reports and Analytics

help

•

Real-Time Reports

Analytics Basics

•

Adobe Report Builder

help

•

Data Extracts

in the Reports and Analytics help

•

ClickMap

in the Reports and Analytics help

•

Activity Map

in the Reports and Analytics help

•

Report Suite Manager

•

Analytics Product Comparison and Requirements

•

Reports and Analytics Interface Help

•

Analysis Workspace Help

•

Report Descriptions

•

Dashboards and Reportlets

•

Bookmarks

•

Virtual Report Suites

•

Anomaly Detection

in the Report Builder Documentation

•

Contribution Analysis

in the Contribution documentation

Segments

Segments are custom subsets of data, or data filtered by rules that you create.

Segments are based on:

• Hits

• Visitors

• Visits

For information about using segments for cross-device visitor identification, see

Create Segments

For in-depth information on Adobe Analytics Segmentation, please refer to the

Segmentation Guide

Traffic Props and Conversion eVars

Custom traffic variables, also called props (s.prop) or property variables, are counters that count the number of times each value is sent into Analytics.

When determining which variables are assigned where, it is important to understand the differences between Prop and eVar functionality. Understanding these differences allows your organization to decide which type of variable

is best to use. For detailed information, see

Comparing Props and eVars

Props also let you correlate custom data with specific traffic-related events. These variables are embedded in the

Analytics code on each page of your website. Through s.prop variables, Analytics lets you create custom reports, unique to your organization, industry, and business objectives.

For example, if you are an automobile manufacturer, you may be interested in seeing "Most Popular Car Model" to complement your "Pages" report. You can accomplish this by allocating one of your traffic properties to represent car model. Then implement your code to pass in car model on the appropriate pages.

Note: Analytics supports up to 75 s.prop variables.

Props are used in pathing reports or in correlation reports. For example, property variables can be used to show content type, sub-section, or template name. The resulting Custom Traffic reports show which content type, sub-section, or template is viewed most often.

Analytics Basics 21

There are endless business questions that can be answered through the custom traffic variables, depending on what you are capturing from your website. The following list contains a few common goals and objectives:

• Understanding user navigation through the website

• Understanding internal user search behavior

• Segmenting traffic by navigation or category

• Segmenting visitor behavior by demographics eVars (or Custom Conversion Insight variables) are used to identify how well specific attributes or actions contribute to success events on your site. For example, for a media site, eVars may be used to identify how well internal promotions bring visitors to register. When a visitor clicks on the internal promotion, an eVar can be used to store a unique identifier for that promotion. When the same visitor completes registration and a custom success event is fired, the original unique identifier receives credit for the registration event.

In a conversion site, eVars may be used to track how logged-in visitors compare to non-logged in visitors in completing a purchase. When a visitor logs in, an eVar is set to "logged in." When that visitor reaches the checkout page, the checkout event is attributed to the "logged in" value. When a visitor reaches the Thank You page after purchasing, the products and purchase amounts are attributed to the "logged in" value. The resulting Custom eVar report shows the total number of checkouts and orders for "logged in" and "non-logged in" visitors.

For additional information, see

Traffic Variable

in the Analytics Help and Reference.

For information about setting up properties in Digital Tag Management, see

Create Web Property

Comparing Props and eVars

There are several types of variables available in the Marketing Cloud. The two most popular types, Props and eVars, allow your organization to report on custom dimensions to your site that standard out-of-the-box reports do not offer.

Props vs eVars

The following are the main differences between props and eVars:

• Naming convention: Props are considered traffic variables, meaning they are used to report on popularity of various dimensions of your site. eVars are considered conversion variables. They are used to determine which dimensions of your site contribute the most to success events.

• Persistence: Props do not persist beyond the image request they were fired on. They cannot be associated with other variables that are not in the same image request. eVars, however, are persistent. A back-end variable is used to preserve the value originally fired so it can associate itself with success events later on.

• Success events: Success events, also known as conversion events, are metrics that measure the number of times a visitor reaches a goal. This event can be anything from purchasing something on your site, to subscribing to a newsletter. eVars are designed to report on conversion events, to show you which values are most successful in influencing visitors to reach your goals. Traffic variables do not have this same functionality. However, you can view participation metrics if you configure your report suite correctly.

• Pathing: Props can use pathing, which allows your organization to see a given path a user took within the context of the variable being viewed. An Adobe representative can enable pathing, if requested. eVars cannot use pathing.

• Potentially available metrics: The metrics available between props and eVars vary widely based on the variable's settings and data platform/version. The following list illustrates what can be enabled, not what is enabled by default.

If you want a specific metric in reporting but do not see it, have one of your organization's supported users contact

Customer Care.

Analytics Basics

Metric

Average Page Depth

Average Time Spent

Bounce Rate

Bounces

Calculated Metrics

Custom Conversion Events

Entries

Exits

Instances

Page Views

Participation Metrics

Purchase Metrics

Reloads

Shopping Cart Metrics

Single Access

Total Time Spent

Unique Visitors

Visits

Props

(Traffic Variables) eVars

(Conversion Variables)

Analytics Basics 23

• Breakdowns: Props use correlations, which display page views for other traffic variables fired in the same image request. eVars use subrelations, which provide a breakdown on other conversion variables in relation to success events.

Exclusive advantages to Props or eVars

With the release of version 15, the capabilities between Props and eVars are much less distinct. eVars have recently been updated to include capabilities such as visits/unique visitors with minimal processing load, as well as pathing metrics.

Props hold a couple advantages of eVars, some of which can be circumvented:

• Prop data is collected and available in reporting almost instantly. eVars can take upwards of 30 minutes to appear in report suite data.

• All Props can have flowchart-like reports enabled, which let you see the path visitors take to your site. These pathing flow reports are available for both Props and eVars in Ad Hoc Analysis.

• Props can be correlated multiple levels, where eVars can only be subrelated once. This limitation can be mitigated by using segmentation, giving identical data as correlations.

• Participation metrics allow you to see what prop values participated before a success event.

eVars on the other hand hold several advantages over the limited nature of Props:

• eVars can use success events as metrics. Props cannot.

• eVar expiration can be customized, including having an expiration of every hit (no persistent values whatsoever).

Props don't persist in any way.

Pathing metrics, such as Total Time Spent, Entries, and Exits, were originally not available for eVars. However, recent updates have made these metrics available, increasing the value of eVars.

Which to Use

Props: If latency is the largest concern, and you intend to only measure traffic (not success events) with this dimension.

eVars: If data breakdowns and relationships are the largest concerns.

Tip: If you don't want an eVar to persist, you can change its expiration to 'hit' so it doesn't keep any data beyond the hit.

Using Props as Counters

A counter stores (and sometimes displays) the number of times a particular event or process has occurred.

You can use a prop to count the number of times an event occurs. For example, you want to track the use of the

Real Player vs. the Windows Media Player on your site. Each page contains Code to Paste, in which you can see

s.prop variables. Use s.prop 1 to track the players. For page A, enter a value in s.prop1 to represent Real Player.

s.prop1="RealPlayer"

For page B, enter a similar value in s.prop1 for Windows Media Player, as shown below.

s.prop1="WindowsMP"

Note: Adobe offers up to 75 s.prop variables for you to use.

Analytics Basics 24

As visitors come to your site and visit the pages containing the Real Player or Windows Media Player, Analytics is able to segment the users based on which pages they visited. The Custom Traffic report then shows the number of visits to each page.

Note: The name of the Custom Traffic report can be customized. For example, the Custom Traffic report can be renamed to "Player Types Report."

Counting Content Hierarchies

A common usage of content hierarchies is to show the different paths visitors have taken from a certain page, level, and so forth.

How should I track my content hierarchy?

You must first understand the reporting requirements for tracking content hierarchies. If the requirements for tracking the hierarchy are very detailed, often times the hierarchy (hier) variable is recommended. Hierarchies usually require a strict, predefined taxonomy where the same child node rarely lives under multiple parent nodes. Consider the following example:

Global Hierarchy

All Sites > Regions > Countries > Language > Category

In this example, the hierarchy could begin to break down at the language level. If a requirement is to report on overall

"English" traffic, you can run into the problem where English appears under USA, England, Australia, and so forth.

Hierarchies allow you to only drill down. In order to slice horizontally across multiple hierarchies, the best practice is to use a custom traffic variable (prop).

If you want to provide users with the ability to drill down through the site (similar to how users would browse the site) and report on Unique Visitors at each level of the hierarchy, the hierarchy variable is recommended.

There are occasions when using both props and the hier variable makes sense. The following is a supported prop for each variable type:

Props Hierarchy

Correlations

Pathing

Page View

Unique Visitors

Classifications

What is a Predefined Event?

List of predefined events.

Analytics Basics 25 prodView scView scOpen scAdd scRemove scCheckout purchase

Success event occurs any time a visitor views a product.

Success event occurs any time a shopping cart is viewed.

Success event occurs any time a visitor opens a shopping cart for the first time.

Success event occurs any time a product is added to a shopping cart.

Success event occurs any time an item is taken out of a shopping cart.

Success event occurs on the first page of a checkout.

Success event occurs on the final page of a checkout

(includes Revenue, Orders, and Units).

When one of the predefined events above occurs, an instance of the event is incremented. You can view the metrics related to the event in several different reports. See below for an example of the code used to configure predefined events.

s.events="scAdd" s.events="scOpen,scAdd"

• In the first example above, scAdd is the value of the event. Any time an item is added to the shopping cart, the event is incremented.

• In the second example, two values are captured at the same time. When multiple success events occur on the same page, each event is incremented.

Detailed Product View Page

The products variable is used for tracking products and product categories (as well as purchase quantity and purchase price).

A success event should always be set in conjunction with the products variable.

s.events="prodView"

Note: While prodView is treated in implementation like an event, it does not have the same flexibility in the interface. The prodView event is an instance of the product and is only available in the products report. Adobe recommends you use a custom event in addition to the prodView event. This way, you can see the product view metrics alongside other metrics in other conversion reports.

s.products=";diamond earrings (54321)"

Note: The products string syntax must begin with a semicolon. This is a legacy syntax requirement. It was previously used to delimit the category and product, but that creates a limitation within the interface should you ever want to change how you are classifying products. For the maximum flexibility in your reporting, it is best to leave this blank and use Classifications to set up categories.

Shopping Cart Page (scOpen, scAdd, scRemove)

s.events="scOpen,scAdd" s.products=";SKU"

Analytics Basics 26

First Checkout Page

s.events="scCheckout" s.products=”;SKU"

Confirmation Page

s.events="purchase" s.products=";SKU"

Note: While using the SKU in the product string may make the products report less readable, it provides the maximum flexibility later when you want to classify your products. You can create categories from the SKU that indicate finish, manufacturer, category, and sub-category.

When the products variable is set in conjunction with the purchase event, the purchase quantity and total purchase price are included in the products value as shown above.

What is a Custom Event?

Custom events let you define the success type that you want to track.

Although similar to predefined events, custom events let you define your own success metric. For example, if you have a newsletter, your success event could be "Registration." Clearly, "Registration" is not part of the predefined events. By using a custom event, you can track the number of visitors who register for your newsletter. Custom events follow the standard syntax shown below.

s.events="event3"

The code above shows how to assign an event to the events variable. If you do not modify the event name in the interface, then "event3" would display in the interface.

By default, success events are configured as "counter" events. Counter events count the number of times a success event is set. Some success event uses require an event be incremented by some custom amount. These events can be set either as "numeric" events or "currency" events. You can change the event type using Admin Console.

Hash Collisions

Describes what a hash collision is and how it can manifest.

By default, Adobe treats prop and eVar values as strings, even if the value is a number. Sometimes these strings are hundreds of characters long, other times they are short. To save space, improve performance, and make everything uniformly sized, the strings are not used directly in the processing tables. Instead, a 32-bit or 64-bit hash is computed for each value. All reports run on those hashed values until the data is presented, where each hash is replaced by the original text. Without this compression, reports would likely take minutes to run.

For most fields, the string is first converted to all lower case (reducing the number of unique values). Values are hashed on a monthly basis (the first time they are seen each month). From month to month there is a small possibility that two unique variable values will be hashed to the same hash value. This is known as a hash collision.

Hash collisions can manifest in reporting as follows:

• If you are trending a value and you see a spike for a month, it is likely that another values for that variable got hashed to the same value as the value you are looking at.

• The same things happens for segments for a specific value.

Hash Collision Example

Analytics Basics 27

The likelihood of hash collisions increases with the number of unique values in a dimension (eVar). For example, one of the values that come in late in the month could get the same hash value as a value earlier in the month. The following example may help explain how this can cause segment results to change. Suppose eVar62 receives "value

100" on February 18. Analytics will maintain a table that may look like this:

eVar62 String Value Hash

Value 99 111

Value 100

Value 101

123

222

If you build a segment that looks for visits where eVar62="value 500", Analytics determines if "value 500" contains a hash. Because "value 500" does not exist, Analytics returns zero visits. Then, on February 23, eVar62 receives

"value 500", and the hash for that is also 123. The table will look like this:

eVar62 String Value Hash

Value 99 111

Value 100

Value 101

123

222

Value 500 123

When the same segment runs again, it looks for the hash of "value 500", finds 123, and the report returns all visits that contain hash 123. Now, visits that occurred on February 18 will be included in the results.

This situation can create problems when using Analytics. Adobe continues to investigate ways to reduce the likelihood of these hash collisions in the future. Suggestions to avoid this situation are to find ways to spread the unique values between variables, remove unnecessary values with processing rules, or otherwise reduce the number of values per variable.

Frequently Asked Questions about Analytics

Implementation

Frequently Asked Questions about Analytics

Implementation

Frequently asked questions about implementation, and links to more information.

Question Answer

How do I manage

Analytics users and groups?

For information about managing users and groups, refer to

User Management

in the

Adobe Analytics help.

eVar Expiration - Why are the eVars getting attributed

Expire After specifies a time period, or event, after which the eVar value expires (no longer receives credit for success events). If a success event occurs after eVar to ‘None’ in the reports?

expiration, the None value receives credit for the event (no eVar was active). If you select an event as an expiration value, the variable expires only if the event occurs. If the event does not occur, the variable never expires.

More...

Custom Event Visibility -

Why do Custom Events not appear in the reports menu?

In the Visibility column, you can hide standard (built-in) metrics, custom events, and built-in events in the Menu, Metric Selectors, Calculated Metrics Builder, and the

Segment Builder. This setting does not impact the data collection for that metric or event; it affects only its visibility in the user interface.

More...

Timestamps - What do I need to consider before changing timestamp settings?

Using the Timestamps Optional feature, you can combine non-timestamped data with timestamped data without incurring data loss. Offline data with timestamps generated from a mobile device can be combined with live, non-timestamped data from a web page—or integrated with data from any platform using a client-side timestamp call.

More...

Visitor ID - How does the

Visitor ID grace period work and how is it enabled?

If you have multiple JavaScript files that are sending data to the same report suite, or if you are using other technologies on your site such as Flash video measurement, we recommend configuring a grace period.

More...

Visitor ID - What is the difference between the

Marketing Cloud Visitor ID and the Analytics Visitor

ID?

The Marketing Cloud ID service assigns a unique, persistent identifier to all your site visitors. With this ID, visitors and their data can be shared among other solutions in the

Marketing Cloud. Also, this ID can replace or work with solution-specific IDs such as the Analytics Visitor ID.

More...

Visitor ID - How is the

Visitor ID set if cookies are blocked?

If the standard s_vi cookie is unavailable, a fallback cookie is created on the domain of the website with a randomly generated unique ID. This cookie, named s_fid, is set with a 2-year expiration and is used as the fallback identification method going forward.

More...

Frequently Asked Questions about Analytics

Implementation

Dynamic Tag Management

- Why does my DTM rule not fire?

If your event-based rule does not fire, then there is likely an issue with the selector or condition of the rule. Locate the element on your site where the desired event action occurs, right click and select Inspect element. Inspect the highlighted script in the box that opens and ensure you are targeting the correct element.

More...

How do I implement

Heartbeat Video Tracking?

This section

contains instructions on downloading the video heartbeat SDKs and developer guides for your platform. Make sure you also download the developer guide that is in the docs folder when you download the SDK as it contains the specific implementation instructions for video heartbeat.

How do I add cookies to the right subdomain?

The cookieDomainPeriods variable determines the domain on which the Analytics cookies s_cc and s_sq are set by determining the number of periods in the domain of the page URL. This variable is also used by some plug-ins in determining the correct

domain to set the plug-in's cookie.

More...

Tracking Server - How do

I correctly populate my tracking server?

When you configure an implementation to send data to Adobe Analytics servers, you must send it to the correct location. Failure to do so causes inflated visitor counting or data loss.

More...

Performance - Can a failure to load the external

Adobe JavaScript, whether due to internet connection, proxy, firewall, or service interruption at Adobe, affect performance?

No. The JavaScript file is not hosted on Adobe servers, so an Adobe outage will not affect the JavaScript execution. If dynamic tag management is employed, the JavaScript file is hosted by Akamai, or on a server location determined by customers.

See Will Dynamic Tag Management reduce my website's performance? at the

Dynamic

Tag Management FAQ

Additionally, you can host your own core dynamic tag management file if you are not comfortable relying on Akamai's CDN. See

Embed Code and Hosting Options

Performance - Can the loading of the external

The JavaScript file is cached in the visitor's browser after it is initially loaded, and is typically downloaded no more than once per session. The file is not downloaded on

Adobe JavaScript cause a each page, even though it is used by every page on the site. On most web sites, users reduction in performance? average more than a few page views per session, so transferring JavaScript that is used multiple times into this file can result in less overall downloaded data.

JavaScript for AppMeasurement Compression: If you are concerned about the page weight (size) of Adobe's JavaScript client, Adobe recommends that you consider compressing the file using GZIP. GZIP is supported by all major browsers and offers better performance than JavaScript compression to compress and decompress the core s_code.js

JavaScript file.

Performance - Can the sending of data from the browser to Adobe services reduce performance?

The Adobe JavaScript file creates an image object within the HTML page, and the browser then requests the image object from Adobe servers. If the Adobe servers were to be slow or unresponsive, the thread handling that request would be delayed until the image returns or a timeout occurs. Because browsers handle images with multiple threads, an Adobe outage would have a minimal impact on the page load time, tying up one thread while the others continue to function.

Frequently Asked Questions about Analytics

Implementation

Performance - Can a

JavaScript event from

Adobe impact system behavior or functionality?

No. See preceding performance answers.

How can I change collected data, based on defined conditions of my own?

Use processing rules to simplify data collection and manage content as it is sent to reporting.

learn more

Which is the latest version of s_code file?

This section contains a release history for AppMeasurement libraries across web and mobile platforms. The latest version of each library can be downloaded in Reports &

Analytics > Admin Tools > Code Manager.

learn more

How do I debug s_code file?

How do I track different link types?

File downloads and exit links can be automatically tracked based on parameters set in the AppMeasurement for JavaScript file.

learn more

How do I track video ?

The Adobe Debugger (previously DigitalPulse Debugger) is a free tool provided by

Adobe that lets you view the data being collected from your site on any given page.

learn more

How do I track a mobile

App?

JavaScript can be used to track a wide variety of players. To track using JavaScript, you add code to the web page that contains your player and track the player using event handlers.

learn more

Acquisition links with unique tracking codes can be generated in Adobe Mobile services.

When a user downloads and runs an app from the Apple App Store after clicking on the generated link, the SDK automatically collects and sends the acquisition data to

Adobe Mobile services.

iOSAndroid

How do I implement video tracking?

You can track media players by creating functions attached to the video player event handlers This lets you call Media.open, Media.play, Media.stop, and Media.close at the appropriate times.

learn more

How do I set up the First

Party Cookie?

Analytics uses cookies to provide information on variables and components that do not persist between image requests and browser sessions. These harmless cookies originate from a domain hosted by Adobe, known as third-party cookies.

learn more

How do I get an SSL certificate?

Determine whether your site uses https:// protocol. If it does, requesting a CSR and purchasing an SSL certificate is required. Note: An SSL certificate is not required if you do not have any secure pages or content. This entire step may be skipped if you use only http:// protocol on your site.

learn more

Where do I find information about the certification expiration notice?

SSL certificates expire each year, meaning that Adobe requires an updated certificate request each time this happens. The FPC specialist provides sufficient warning when this occurs, however, it is recommended to be proactive in monitoring the expiration and providing Adobe with this updated certificate.

learn more

What are plugins?

Information about data insertion API?

AppMeasurement for JavaScript plug-ins are programs or functions that perform several advanced functions. These plug-ins extend the capabilities of your JavaScript file to give you more functionality that is not available with a basic implementation. Adobe offers a number of other plug-ins as part of advanced solutions. Contact your Account

Manager if you want to capture data using JavaScript but are unsure how to proceed.

learn more

Adobe has created multiple ways to send data into Analytics.

learn more

Frequently Asked Questions about Analytics

Implementation

What is a 500 error?

Information about the internal server error which caused a "500 Query Error" status.

Insight query APIpageType variable

Prepare to Implement Analytics 32

Prepare to Implement Analytics

There are tasks you should complete and information you should gather when preparing to implement Analytics.

The information and documents in this section are gathered directly from Adobe Consulting. Following these guidelines and filling out the provided questionnaires will help you implement Analytics, whether you implement by yourself or work with Adobe Consulting (recommended).

If you are working with an Adobe Consultant, it is not required that you know the information in these documents before implementing Analytics. However, being familiar with the documents Consulting will create and the questions they will ask can help to speed the pre-implementation process.

Business Requirements Document

The Business Requirements Document (BRD) is used to document the key business objectives and requirements.

Consulting will work with you to compile the BRD. The contents of this document depend on a number of factors, such as the nature of your site or application, and your business vertical (such as retail, media, travel, or lead gen).

Consulting will also work with you to compile a Solution Design Reference (SDR), which documents the solution architecture, and a validation checklist to validate the implementation.

Business Governance Questionnaire

There are six pillars of digital analytics that can help you understand whether your organization is positioned to make the most of the business intelligence your data can provide.

• Clear objectives

• Organization-wide scope

• Right expertise

• Tools and technology

• Process

• Governance (that ties them all together)

Organizations that successfully make the most of their data have put into place well-defined and well-communicated roles and responsibilities. This holds teams and people accountable across the full spectrum of activities required to collect, analyze, and use data to measure and act on business goals. This is known as governance.

Responsibility is another aspect of governance. Governance is the process of outlining who has responsibility for making collection, analysis, implementation and assessment a success and how these activities can be supported.

This can range from ownership and responsibility of a particular area to simply being informed and aware of the progress or setbacks. The

Business Governance Questionnaire

contains business questions that need to be filled by our client before the Analytics implementation kick-off meeting.

Technical Questionnaire

Adobe uses proven methodologies and enlists professional help to guide our clients to accurately plan in the initial stages of the project and to successfully complete the implementation.

Prepare to Implement Analytics 33

The

Technical Pre-Implementation Questionnaire

contains technical questions, which should be filled out before the

Analytics implementation kick-off meeting.

Technical Specification

Your Adobe Consultant will discuss the technical specifications of your implementation with you.

It can be useful for you to be familiar with the content of the

Technical Specifications

document used by Consulting, although it is not required for you to know this information if you are working with a Consultant. This document is used as the standard guide for deploying Adobe Analytics on a given site. The document is divided into different sections, each of which describes a different component of the overall Analytics solution.

The industry specific Tech Specs cover the fundamental solutions and can be leveraged as a starting point for creating a more complete document.

Review Website or Application

A site or application walk-through is a key step in the implementation process, in which you lead your Implementation

Consultant through the site and explain the technical factors and business flows.

This step should be carried out whenever there is a requirement for implementation or implementation changes.

• This step happens in the "strategy planning" phase, in the "onboard" process of an engagement lifecycle.

• This step typically takes place after the kick-off call between your organization and Consulting,

Prepare to Implement Analytics 34

Prerequisites

It is important to work with your implementation consultant to provide a good understanding of your business and the overall objective of your site or application. Some of the places best suited to give some background information are:

• Contract/Pre-Kick-off call with Sales Team

• Company website (For example, the About and News pages)

• Review Industry vertical playbook & related resources

• Review important concepts in Wikipedia (such as Revenue, Affiliates, and Competitors)

• review Play Store and App Store descriptions and reviews

Key Stakeholders

Adobe:

• Implementation Consultant

• Business Consultant

• Solution Architect

• Project Manager

Client:

• Site Master

• Business Lead

• Technical Lead

Methodology

• The site/app walkthrough happens over a phone with screen share or on a site visit

• Your Consultant will ask you to demonstrate the key business flows that impact revenue

• The Consultant will observe, record, and document the outcomes

The

Adobe Pre-Implementation questionnaire

and

Digital Assets Governance

document contain the questions that

you should answer during the walkthrough session.

Key Outcomes

The following information should be known following the webite or app review:

Business:

• Purpose and the reason why the site exists

• Strategic importance of the site

• Relationships or groups with other internal/external sites (if any)

• Site sub-functions (service or account details, or referral)

• Key business processes that a visitor will go through

Technical:

• Internal and external domain names

• Secure content (if any)

• Hosted conversion process

Prepare to Implement Analytics

• Currency and time zone settings

• Hybrid app details

Dashboard Creation

As part of the implementation process, your Adobe Consultant will help you create a dashboard.

Your Consultant will schedule and hold a dashboard kickoff meeting. During the meeting, You and your Consultant will gather requirements and fill out the Dashboard Requirements Document (DRD). After the call, your Consultant will give you a final copy of the DRD and identify the next steps.

Adobe Analytics Dashboard Fundamentals

Dashboards help your business:

• Monitor key performance indicators (KPIs)

• Understand your customers better

• Respond to competitive pressures more quickly

• Assist in quick decision making and planning

Before Adobe can help your organization with the visual design of a dashboard, it is important to help your Consultant understand your requirements. The following questionsshould be answered:

1. How often should the data be updated in the dashboard?

2. Who will use the dashboard? Is it for a single person, a single group, or people in several different departments?

3. What will they use the dashboard to do? What questions will they use it to answer? What actions will they take in response to these answers?

4. What specific information should be displayed on the dashboard? List all of the data items that should be included on the dashboard. Also indicate the level of summary/detail at which each item should be expressed on the dashboard.

5. Which of the data items listed above are the key (most important) items needed to meet the objectives supported by the dashboard?

6. What are the logical groupings that could be used to organize these data items on the dashboard? Into which of these groups does each data item belong?

7. What are the useful comparisons that will allow the dashboard's users to see the data items listed above in context?

The

Adobe Analytics Dashboard Fundamentals

document contains a list of questions that will help Adobe create an initial dashboard structure. Once in place, you and your Consultant can customize the dashboards according to your business needs.

Choose an Implementation Method 36

Choose an Implementation Method

There are multiple ways to implement Adobe Analytics.

• Dynamic Tag Management (Recommended)

• JavaScript

Dynamic Tag Management

Dynamic Tag Management (DTM) automates much of the detail work required to implement Analytics. Enter the required information in a form-based interface, and Dynamic Tag Management generates the code you need to add to your pages.

Although Dynamic Tag Management greatly simplifies the implementation process, you should be familiar with

basic

before you begin. It is also useful to be familiar with JavaScript.

For example, you should understanding the following:

• What an

eVar

is and how it works

• When to use a

custom event

For information about getting access to Dynamic Tag Management and getting up and running, see

Getting Started

in the Dynamic Tag Management Product Documentation.

For more information, see

Implementing Analytics with Dynamic Tag Management

JavaScript

The JavaScript implementation method requires you to configure the JavaScript codes on your pages manually.

Much of this effort can be simplified if you use the Dynamic Tag Management implementation method. However, some users might require the JavaScript method.

The JavaScript implementation requires:

• Strong JavaScript skills

• Solid understanding of Analytics concepts and terminology

For more information, see

Implementing Analytics Using JavaScript

Getting Started with Analytics Implementation

Learn about the first-time customer experience for implementing Adobe Analytics implementation.

New users can quickly create your first Analytics report suite (data repository) using this Getting Started with Adobe

Analytics setup modal. Then, you can deploy Analytics code using Dynamic Tag Management.

In this procedure enables you to:

• Quickly create your first

report suite

• Deploy Analytics and the

Marketing Cloud ID Service

• Run reports on basic page-level data.

Choose an Implementation Method 37

Note: Before you begin, verify that Analytics is enabled in the Adobe Marketing Cloud (the solution provisioning process). If you received an email inviting you to log in to Analytics in the Enterprise Dashboard, you've completed this prerequisite.

To run the simplified implementation modal

1. Log in to the Adobe Marketing Cloud (

<your company>.marketing.adobe.com

When you access Analytics, the system determines if you have a report suite. If not, the Getting Started with

Adobe Analytics page displays.

Alternatively, you can run this setup in Analytics by clicking Help > Welcome to Adobe Analytics.

2. Specify the following basic information about your business:

Element Description

Property Type Is your implementation for web, mobile, or both?

Industries

Data Layer

Specify how your company makes money (products, customer services, leads, brand awareness, and ads).

(Recommended) A JavaScript array which is used to store information. If you perform the automatic setup using Dynamic Tag Management, you will be using a data layer.

For a blog on data layers, see

Data Later: From Buzzword to Best Practice

Data Repository (Report

Suite)

report suite

is a discrete data set that typically corresponds to a single property

(site or app) or brand. Each report suite has its own set of reports and metrics.

Time Zone

Estimated Page Views

Your local time zone. (Automatically detected.)

Roughly the number of page views your site receives per day.

Choose an Implementation Method 38

Element

Base Currency

Description

The currency in which you do business.

3. Click Next.

The system creates a report suite.

4. To begin deployment, click Next, then click one of the following options:

Element Description

Deploy Launches Dynamic Tag Management, where you can log in and deploy Analytics.

This process automatically implements the

AppMeasurement.js

file and the

Marketing Cloud ID service (

VisitorAPI.js

Important: In a new browser tab, a help page is displayed that walks you through Adobe Analytics deployment via Dynamic Tag Management.

Download Downloads the installation file, named

INSTALL-ME <report suite name>.js

This option is for experienced users who understand

JavaScript Implementation

Important: Downloading the code does not constitute deploying Analytics.

This is a manual deployment that you perform on the pages of your site, or through Adobe consulting services.

5. Run a report.

After deploying the Analytics tool, you can run a report in Reports & Analytics to confirm that data is coming to your site. (See

Sign in and Navigate

to get familiar with the Analytics interface.)

For example, a Site Metrics > Real-Time lets you see immediate data.

Note: The Real-Time report requires some configuration prior to running. See Configure Real-Time Report .

Example Real-Time Report

Choose an Implementation Method 39

40 Implementing Analytics with Dynamic Tag

Management

Implementing Analytics with Dynamic Tag Management

You can use Dynamic Tag Management (DTM) to implement Adobe Analytics.

Use Dynamic Tag Management to manage tags and collect and distribute data across digital marketing systems.

Dynamic Tag Management provides a single data layer that pushes data from multiple sources. Dynamic Tag

Management also enables responsive delivery of user-specific content.

This help section provides specific information about using Dynamic Tag Management to implement Adobe Analytics.

For detailed information about Dynamic Tag Management, refer to the

Dynamic Tag Management Product

Documentation

. For information about accessing DTM and common tasks when starting to use DTM, see

Getting

Started

in the Dynamic Tag Management Product Documentation.

For a detailed summary of the Dynamic Tag Management implementation steps, refer to

Deploy Adobe Analytics

Using Dynamic Tag Management

in Getting Started with Adobe Analytics.

Overview of Implementation Steps

This guide leads you through the following steps to implement Analytics using DTM:

Create a web property

Configure your hosting options

Add header and footer code to each managed page

Add the Adobe Analytics Tool

5. Create

data elements

rules and conditions

, and

actions

6. Publish tools and rules to the production server.

Create Web Property

A web property can be any grouping of one or more domains and subdomains with a library of rules, included in one embed code.

Note: Only a user with Admin rights can create a property. For more information about roles, see Create and

Manage Groups in DTM in the Dynamic Tag Management Product Documentation.

You can manage and track these assets with DTM. For example, suppose that you have multiple websites based on one template and you want to track the same assets on all of these websites. You can apply one web property to multiple domains.

Tip: Plan ahead to determine how many web properties you need. See Planning Your Migration to DTM in the Getting Started with Adobe Dynamic Tag Management guide.

For general information about web properties and best practices, see

Web Properties

in the Dynamic Tag Management

Product Documentation.

1. Navigate to your company page, then click Add Property.

Implementing Analytics with Dynamic Tag

Management

2. Fill in the fields:

Element

Name

Description

The name of your property.

URL

The base URL of the property.

This site spans multiple domains

You can add and remove domains if you want visitor data to persist between domains.

If this option is selected, data for the visit persists across subdomains.

This setting lets you specify how you would like to track traffic moving between your associated subdomains or domains. Links to subdomains are treated as outbound links. Visits to subdomains are tracked separately.

3. (Optional) Configure Advanced Settings.

Element

Allow Multi-Rule

Approvals

Description

Allows multiple rules for this property to be approved at one time. The default approval allows only single-rule approval.

Enable Selective Publish

Specifies whether to allow users to select which approved rules are published. This is the default option.

Implementing Analytics with Dynamic Tag

Management

Element

Tracking Cookie Name

Description

Overrides the default tracking cookie name. You can customize the name that

Dynamic Tag Management uses to track your opt-out status for receiving other cookies.

Tag Timeout

Specifies how long Dynamic Tag Management waits for a tag to fire before timing out and cancelling the tag request.

Because of how Dynamic Tag Management works, don't worry about this being a high number. DTM has effective methods of ensuring that slow tags do not affect the user experience.

Anchor Delay

Specifies how long Dynamic Tag Management waits for tags to fire on clicked links before moving to the next page. The default value is 100 milliseconds.

Longer delays improve tracking accuracy. Adobe recommends a delay of 500 milliseconds or less, which the user will not perceive.

Dynamic Tag Management will wait up to the time specified, but if the beacon fires sooner, the delay is cut short. (That is, user won't always wait the full length of the delay.)

4. Click Create Property.

Configure Hosting Options

You can deploy Dynamic Tag Management using one or more of the available hosting options.

Dynamic Tag Management provides a number of options to host the required JavaScript files.

For detailed information about hosting, see

Embed Code and Hosting Options

in the Dynamic Tag Management

Product Documentation.

On the Embed tab, select a hosting option.

Hosting Option Description Implementation

Akamai The simplest hosting option to implement.

Globally distributed delivery network.

Adds additional third-party infrastructure dependencies (DNS lookup, Akamai availability).

For more detailed information, see

Akamai

in the Dynamic Tag Management Product

Documentation.

1. Dynamic Tag Management generates custom JavaScript libraries.

2. Dynamic Tag Management exports the custom JavaScript libraries to Akamai.

3. The target website references the

Akamai-hosted Dynamic Tag Management libraries directly at the page level.

Implementing Analytics with Dynamic Tag

Management

Hosting Option Description Implementation

Self-hosting: FTP

Delivery

A push approach, whereby Dynamic Tag

Management exports custom JavaScript libraries directly to the web content server host via the FTP protocol.

1. Dynamic Tag Management generates custom JavaScript libraries.

2. Dynamic Tag Management exports the custom JavaScript libraries to host server

This solution requires an FTP server and via FTP.

credentials to be available on the web content 3. The target website locally references the server to publish changes to the custom custom Dynamic Tag Management

Dynamic Tag Management libraries.

libraries.

For more detailed information, see

FTP

in the

Dynamic Tag Management Product

Documentation.

Self-hosting:

Library Download

A pull approach, whereby the application exports custom JavaScript libraries. There, the libraries can be accessed by a hosted server-side process.

Additionally, the libraries are available via web download directly from the Dynamic Tag

Management interface.

This solution requires either a manual retrieval and publication of the Dynamic Tag

Management libraries or the creation of an automated process that pulls the libraries from

Akamai onto the web content server.

1. Dynamic Tag Management generates custom JavaScript libraries.

2. Dynamic Tag Management exports the custom JavaScript libraries to Akamai.

3. Custom Dynamic Tag Management libraries are manually or programmatically moved to the web content server.

4. The target website locally references the custom Dynamic Tag Management libraries.

This approach takes the most time to set up, but is also the most secure and flexible option.

To check if the latest version of your library file is being referenced, use the command

For more detailed information, see

Library

Download

in the Dynamic Tag Management

Product Documentation.

You can use more than one hosting option. For example, you might host your staged files using Akamai, but self-host your production site. Note that each hosting type has its own embed code, and only one embed code can be added to a page.

Add Header and Footer Code

Use Dynamic Tag Management to add header and footer code that determines the loading of JavaScript and page content on your site. You must install both the header and footer code on every page of your site, regardless of the hosting option used.

Implementing Analytics with Dynamic Tag

Management

Because Dynamic Tag Management includes a snippet of code in both your header and footer, you can run rules at the beginning or end of a page. This ability allows you to implement testing tools and other technologies while retaining control over tracking your pages.

Dynamic Tag Management creates staging and production embed codes you can use to test your changes in your staging environment before pushing changes to your production environment.

Important: For a successful implementation, it is critical that you follow these instructions as they appear in

Adobe Help. Specifically, you must place the header code in the

<head>

section of your document templates.

Also, you must place the footer code just before the closing

</body>

tag. Placing either of these embed codes elsewhere in your markup, or using asynchronous methods to append the embed codes, or wrapping the embed codes in any way, are not a supported implementations of Dynamic Tag Management. The embed codes must be implemented exactly as provided.

An unsupported implementation will yield unexpected results and prevent Customer Care and Engineering from assisting with your implementation.

1. In the Dynamic Tag Management interface, open the Embed tab and select your hosting option (such as Akamai), then toggle the switch to "On."

2. Copy the production header code provided in the Embed tab of Dynamic Tag Management and place it within the

HEAD

section of your site HTML.

Implementing Analytics with Dynamic Tag

Management

Place the code as close to the

<head>

tag as possible. This code snippet should be placed on every page of your live production site.

Note: Production embed code reflects only the published items in that property . However, embed code

for staging reflects all items in the associated property, regardless of the published or unpublished state.

To test unpublished items on your production site, locally enable staging in the console by following the

instructions in Test Unpublished Rules for Akamai Hosting .

3. Copy the production footer code and place it in the

BODY

section of your site HTML.

Place the code as close to the

</body>

tag as possible.

4. Copy the staging header and footer code, then repeat the steps above on your staging site.

Note: The difference between production and staging code snippets is the addition of

-staging

to the filename in the staging version. The footer code remains the same in staging and production.

Verify Header and Footer Code

Verify that your Dynamic Tag Management library is loading properly on your site.

Implementing Analytics with Dynamic Tag

Management

1. Open your site in your browser.

2. Open the Developer Console by right-clicking and choosing Inspect Element > Console.

3. Press Enter.

If the code was properly installed, you will see true display in the console.

If the code was not properly installed, you will see the reference error:

_satellite is not defined

If you receive this error, ensure that:

• You have included the full header code on every page of the site in the

HEAD

section, as close to the

<head> tag as possible.

• You do not have unexpected characters appearing in the code snippet, potentially as a result of copying and pasting from a formatted document.

Add Adobe Analytics Tool

Deploy Adobe Analytics (Standard and Premium) using Dynamic Tag Management by creating the Adobe Analytics tool and configuring the page code either automatically or manually. The automatic method is recommended for most users.

Note: For improved visitor tracking, it is strongly recommended that you enable Marketing Cloud ID Service .

This section contains the following information:

•

Add an Adobe Analytics Tool

•

Edit an Existing Adobe Analytics Tool

•

Enabling Adobe Analytics Premium

Add an Adobe Analytics Tool

1. Click Web Property Name > Overview > Add a Tool > Adobe Analytics.

Implementing Analytics with Dynamic Tag

Management

2. Fill in the fields:

Element

Tool Type

Tool Name

Configuration Method

Description

The type of tool, such as Adobe Analytics.

A descriptive name for this tool. This name displays on the Overview tab under

Installed Tools.

Automatic (Recommended): Use dynamic tag management to manage the configuration. This method enables automatic synchronization of Adobe Analytics report suites via a Marketing Cloud login or Web Services ID, and manages the

AppMeasurement code.

After the accounts are connected, Dynamic Tag Management pulls the Adobe

Analytics report suite IDs and names into the tool configuration interface, allowing for increased speed in tool deployment with less possibility for user errors.

Note: You must choose the Automatic option if you are an Adobe Analytics

Premium customer. See

Enabling Adobe Analytics Premium below.

Fill in the fields specific to automatic configuration:

• Marketing Cloud: (Default) Uses Marketing Cloud single sign-on. Specify your

Marketing Cloud ID and password.

• Web Services: Specify your Web Services username and shared secret.

Shared secret credentials are located in Admin Tools > Company Settings

Web Services

Implementing Analytics with Dynamic Tag

Management

Element Description

Developers, see

Get Web Service Access to the Enterprise API

for help with obtaining Web Services credentials.

Manual: Manually manage the AppMeasurement code. You can download the

AnalyticsAppMeasurement code from Admin Tools > Code Manager.

Click

JavaScript (new)

for information about downloading the code locally to copy and paste in the Edit Code field in

Library Management

Fill in the fields specific to a manual configuration:

• Production Account ID: (Required) Your production account for data collection.

For Analytics, this is your report suite ID. Dynamic Tag Management automatically installs the correct account in the production and staging environment.

• Staging Account ID: (Required) Used in your development or test environment.

For Analytics, this is your report suite ID. A staging account keeps your testing data separate from production.

• Tracking Server: Specify the information for your tracking server.

The Tracking Server and SSL Tracking Server variables are used for first-party cookie implementation to specify the domain at which the image request and cookie is written. For more information, see the

Correctly Populate the trackingServer and trackingServerSecure Variable

article.

• SSL Tracking Server: Specify the information for your SSL tracking server.

3. Click Create Tool to create the tool and display it for editing.

Tools are displayed on the Overview tab, under Installed Tools.

4. (Conditional) Configure the tool further as necessary by following the directions in the links below (General,

Library Management, Global Variables, Pageviews & Content, Link Tracking, Referrers & Campaigns,

Cookies, and Customize Page Code).

See

Frequently Asked Questions About the Adobe Analytics Tool

for additional information about this tool.

Edit an Existing Adobe Analytics Tool

You can edit an existing Adobe Analytics tool to change its configuration settings.

Click the icon next to an installed tool from the Overview tab.

2. Edit the fields as desired.

The following table includes only those elements that differ from the elements available when you are creating an Analytics tool, as described above. However, you can change any element on the page, as described in both tables.

Implementing Analytics with Dynamic Tag

Management

Element

Enable Automatic

Configuration

Description

Note: Enabling this setting changes a manually configured implementation to the automatic configuration method described in Configuration Method.

This option lets Dynamic Tag Management automatically retrieve your Adobe

Analytics account's configuration.

The latest available AppMeasurement code is used and upgrade notifications are displayed for selection as new versions become available. You can also roll back to previous AppMeasurement versions as necessary, such as for compatibility reasons. Up to five previous versions are displayed.

Refresh the API, for example, to update report suites associated with a user.

Update Credentials

3. (Conditional) Configure the tool further as necessary by following the directions in the links below (General,

Library Management, Global Variables, Pageviews & Content, Link Tracking, Referrers & Campaigns,

Cookies, and Customize Page Code).

4. Click Save Changes.

Enabling Adobe Analytics Premium

If you are an Adobe Analytics Premium customer, dynamic tag management lets you take advantage of advanced features and additional eVars and events. For more information, see

Adobe Analytics Premium

The following table displays the number of eVars and events available in each Analytics account type:

eVars

Events

Adobe Analytics (Point

Product)

100

Adobe Analytics (Standard) Adobe Analytics Premium

100

1,000

250

1,000

You add the Adobe Analytics Premium tool using dynamic tag management the same way you add Adobe Analytics

(Standard). In order to get the Analytics Premium functionality (if applicable), you must do the following:

• Use the Automatic configuration method (explained above).

• Use the Marketing Cloud or Web Services authentication method (explained above).

There is no "switch" to enable Analytics Premium functionality. Verification is done behind the scenes by API checks via the automatic configuration. The additional eVars are added to the UI if the account is authenticated as an Analytics Premium customer.

Note: If you downgrade to standard Analytics in the future, the added premium eVars that are out of the standard range will be grayed out in both tools/rules. You can view any configured variables that are now out of range and make any necessary changes to an in-range variable. You cannot add or edit any of these out-of-range variables, but you will be able to view them and delete them.

Implementing Analytics with Dynamic Tag

Management

General

Field descriptions for the General settings in dynamic tag manager, for deploying Adobe Analytics.

Property > Edit Tool > General

Element Description

Enable EU compliance for Adobe Analytics Enables or disables tracking based on the EU privacy cookie.

When a page is loaded, the system checks to see if a cookie called sat_track

is set (or the custom cookie name specified on the

Edit Property page). Consider the following information:

• If the cookie does not exist or if the cookie exists and is set to anything but true, the loading of the tool is skipped when this setting is enabled. Meaning, any portion of a rule that uses the tool will not apply.

If a rule has analytics with EU compliance on and third-party code, and the cookie is set to false, the third-party code still runs.

However, the analytics variables will not be set.

• If the cookie exists but it is set to true, the tool loads normally.

You are responsible for setting the sat_track

(or custom named) cookie to false if a visitor opts out. You can accomplish this using custom code:

_satellite.setCookie(“sat_track”, “false”);

You must also have a mechanism to set that cookie to true if you want a visitor to be able to opt in later:

_satellite.setCookie(“sat_track”, “true");

Character Set

Currency Code

Tracking Server

SSL Tracking Server

Data Center

Displays the available character encoding sets.

Displays the supported currency codes for selection.

The domain at which the image request and cookie is written.

See

trackingServer

The domain at which the image request and cookie is written.

Used for secure pages. If not defined, SSL data goes to

trackingServer.

See

trackingServerSecure

The Adobe data center used for data collection.

Implementing Analytics with Dynamic Tag

Management

Library Management

Descriptions of the fields and options in the Library Management settings in Dynamic Tag Management.

Property > Edit Tool > Library Management

Note: If more than one Adobe Analytics tool is used in a single web property, each tool must have a unique tracker variable name. Duplicative object variable names between Adobe Analytics tools within a single web property will cause conflicts.

Element Description

Page code is already present Prevents Dynamic Tag Management from installing Adobe Analytics page code if the code is already present on your site.

This feature allows you to use Dynamic Tag Management to add to your existing implementation rather than starting from scratch. Be sure to properly set your tracker variable name when checking this box.

Load library at <Page Top or

Page Bottom>

Specifies where and when to load the page code. Regardless of your selection, any rules using the Analytics tool will need to have the same setting.

Managed by Adobe

(Recommended)

Custom

Enable Dynamic Tag Management to manage your library.

If you select this option, the following option becomes available:

Library Version: Select the latest version from the Library Version menu. Dynamic tag management notifies you when new versions are available. You can revert to a previous version as necessary.

You can configure the library code.

If you select this option, the following options become available:

Set report suites using custom code below: When this box is checked, Dynamic

Tag Management looks for a variable in your custom code called s_account. This variable should contain a comma-separated list of the report suites to which you want to send data.

Code Hosted: Choose an option to host the s_code

• In DTM: You can host the s_code

within Dynamic Tag Management. Click Edit

Code to cut and paste the file directly into the editor.

• URL: If you have a good s_code

file and are happy with the process of updating it, you can provide the URL to the file here. Dynamic tag management then consumes that s_code

file for its implementation of Adobe Analytics.

Open Editor: Lets you

insert core AppMeasurement code

. This code is populated

automatically when using the automatic configuration method described in

Add

Adobe Analytics Tool

Implementing Analytics with Dynamic Tag

Management

Element

Description

Tracker Variable Name: If you want to run two instances of Adobe Analytics in parallel (one within Dynamic Tag Management and one natively), you can rename the main s object. Renaming the object name avoids collisions.

Insert Core AppMeasurement code

Insert AppMeasurement code when manually deploying Dynamic Tag Management in Adobe Analytics.

1. On the Adobe Analytics tool page, expand the General section, then click Open Editor.

2. Unzip the

AppMeasurement_JavaScript*.zip

file you downloaded in

deploy Adobe Analytics

If you opt for custom library, when you open the window it will already have the most recent code version present.

There is no need to download the zip from the Admin Console.

3. Open

AppMeasurement.js

in a text editor.

4. Copy and paste the contents into the Edit Code window.

5. Adobe recommends adding the following code above the Do Not Alter Anything Below This Line: var s_account="INSERT-RSID-HERE" var s=s_gi(s_account)

Important: If you add this code, it is recommended that you also select the Set report suites using

custom code below checkbox in the overall library settings.

6. Click Save and Close.

If you are using the Media Module, Integrate Module, or implementation plug-ins, you can copy them into the code section as well. The managed code in Dynamic Tag Management can be configured exactly like the

JavaScript file in a typical implementation.

Implementing Analytics with Dynamic Tag

Management

Global Variables

Field descriptions and information about variables when using Dynamic Tag Management to deploy Adobe Analytics.

These variables fire on all page load rule beacons. You can accomplish the same effect by using a

Page-Load rule

set to fire on all pages. These variables might not fire in

Direct-Call

and

Event-Based

rules.

Global Variables - Field Descriptions

Property > Edit Tool > Global Variables

Element Description

Server The predefined variable populates the Servers report in Adobe Analytics.

server

eVars

Props

The eVar variables are used for building custom conversion reports.

eVarN

Property (prop) variables are used for building custom traffic reports.

propN

Dynamic Variable

Prefix

A special prefix to the start of the value. The default prefix is "D=".

Dynamic Variables

Page Views and Content

Field descriptions in Dynamic Tag Management for page views and content settings when deploying Analytics.

Property > Edit Tool > Page Views & Content

Element

Page Name

Description

The name of each page on your site.

pageName

Page URL Override

Overrides the actual URL of the page.

pageURL

Channel (Site Section)

Identifies a section of your site.

channel

Hierarchy

Determines the location of a page in your site's hierarchy.

s.linkDownloadFileTypes

hierN

Implementing Analytics with Dynamic Tag

Management

Link Tracking

Field descriptions in Dynamic Tag Management for link tracking when deploying Analytics.

Property > Edit Tool > Link Tracking

Element

Enable ClickMap

Description

Determines whether visitor click map data is gathered.

See

s.trackInlineStats

Track download links

Tracks links to downloadable files on your site.

See

s.trackDownLoadLinks

Download Extensions

If your site contains links to files with any of the listed extensions, the URLs of these links will appear in reporting.

See

Track outbound links

Determines whether any link clicked is an exit link.

See

s.trackExternalLinks

Single-Page App Considerations: Because of the way some SPA websites are coded, an internal link to a page on the SPA site might look like it is an outbound link.

You can use one of the following methods to track outbound links from SPA sites:

• If you do not want to track any outbound links from your SPA, insert an entry into the Never Track section.

For example, http://testsite.com/spa/#

All # links to this host are ignored. All outbound links to other hosts are tracked, such as http://www.google.com

• If there are some links that you want to track on your SPA, use the Always Track section.

For example, if you have a spa/#/about

page, you could put "about" in the Always

Track section.

The "about" page is the only outbound link that is tracked. Any other links on the page (for example, http://www.google.com

) are not tracked.

Note that these two options are mutually exclusive.

Keep URL Parameters

Preserves query strings.

See

s.linkLeaveQueryString

Implementing Analytics with Dynamic Tag

Management

Referrers and Campaigns

Field descriptions in Dynamic Tag Management for referrers and campaign options when deploying Dynamic Tag

Management in Adobe Analytics.

Property > Edit Tool > Referrers & Campaigns

Element

Referrer Override

Description

Overrides the value set in the s.referrer variable, which is typically populated by the referrer set in the browser.

referrer

Campaign

A variable that identifies marketing campaigns used to bring visitors to your site.

The value of campaign is usually taken from a query string parameter.

s.fpCookieDomainPeriods

campaign

Use the DTM interface to choose whether you want to use a Query String or Value (which could pull from a data element):

You can either enter your query string directly in the interface, or you can reference a separate data element if you have other means of tracking a campaign.

Cookies

Field descriptions for the Cookies global settings used for deploying Dynamic Tag Management in Adobe Analytics.

Property > Edit Tool > Cookies

Element

Visitor ID

Description

Unique value that represents a customer in both the online and offline systems.

See

visitorID

Visitor Namespace

Variable to identify the domain with which cookies are set.

See

visitorNamespace

Implementing Analytics with Dynamic Tag

Management

Element

Domain Periods

FP Domain Periods

Transaction ID

Cookie Lifetime

Description

The domain on which the Analytics cookie s_cc

and s_sq

are set by determining the number of periods in the domain of the page URL. This variable is also used by some plug-ins in determining the correct domain to set the plug-in's cookie.

See

s.cookieDomainPeriods

The fpCookieDomainPeriods variable is for cookies set by JavaScript ( s_sq

, s_cc

, plug-ins) that are inherently first-party cookies, even if your implementation uses the third-party

2o7.net

or omtrdc.net

domains.

See

Unique value that represents an online transaction that resulted in offline activity.

See

transactionID

Determines the life span of a cookie.

See

s.cookieLifetime

Customize Page Code

Use field descriptions in Dynamic Tag Management to customize page code when deploying Analytics.

Add plugins to ensure that the code runs at the same time as the Analytics tool. For more information about the

Analytics plugins, see

Implementation Plug-ins

Property > Edit Tool > Customize Page Code

Element Description

Open Editor You can insert any JavaScript call that must be triggered before the final s.t()

call, which is contained in the s_code

Execute Before UI settings: Interface settings take precedence over the custom code (for example, if you want to override an eVar if a setting in the interface was enabled).

After UI settings: Custom code takes precedence over interface settings.

Frequently Asked Questions About the Adobe Analytics Tool

A FAQ about the automatic configuration of the Adobe Analytics deployment. The automatic configuration method manages the AppMeasurement code for you.

Implementing Analytics with Dynamic Tag

Management

Question Answer

Where do I put my plugins when implementing Adobe Analytics via

DTM?

If using DTM to manually host the s_code

, plugins can be added in the same editor as the hosted s_code

, just as it would be in a typical Adobe Analytics implementation.

However, it is also an option to place the plugins in the editor within the

Customize Page Code section of the tool settings. Both implementation methods should be equally effective.

See

DTM Switch Plugins

If I make configuration changes in the new version of the tool, can I test in staging before publishing to production?

Yes.

All changes can be tested in staging just like you normally would before deploying to a production environment. If you choose not to publish, because you notice issues in staging, the production code will continue to function as it did before the new integration was released.

If I switch from manual configuration

(the default setting for existing tools) to automatic configuration, will my current settings be affected?

No.

If I switch from manual library management to Managed by Adobe, will my current settings or code be affected?

Any user code that you have specified is overwritten with the base

AppMeasurement library. You must move this code to the new Custom Page

Code section at the end of the tool configuration so that the code continues executing. This method allows the AppMeasurement library to be managed

(and upgraded) separately from the user's custom code.

Will the revision history for the

Adobe Analytics tool be retained when the new integration is released?

Yes.

See

Add Adobe Analytics Tool

for configuration information.

Potential Pitfalls

There is a small chance that the integration could cause data collection issues if you currently use Adobe Analytics.

These issues could arise only if you publish your library to production subsequent to the release. (Production code remains intact until publishing occurs.)

To avoid these issues, ensure that:

• Report suite IDs are correctly entered in the tool.

• Report suite IDs in the tool match the IDs in the AppMeasurement code.

• The currency code, character set, tracking server, and SSL tracking server configuration fields are correctly set with supported values.

• Custom code is defined in Library Management.

Implementing Analytics with Dynamic Tag

Management

Manually implement Adobe Analytics (legacy)

Create an Adobe Analytics tool for deployment using Dynamic Tag Management. This procedure describes a manual

(legacy) implementation.

For information about automatic implementation management, see

Add Adobe Analytics Tool

If you want to change a manual configuration to automatic, edit a tool and click Enable Automatic Configuration.

1. Download Analytics measurement code: a) In Adobe Marketing Cloud, click Reports & Analytics > Admin Tools.

b) Click Code Manager.

c) Click

JavaScript (new)

to download the code locally.

2. In Dynamic Tag Management,

create a web property

After you create the web property, it is available for editing on the Web Properties tab on the Dashboard.

Activating the web property is not required

3. Add an Adobe Analytics tool to the property: a) On the Web Properties tab, click the property.

b) On the Overview tab, click Add a Tool.

c) From the Tool Type menu, select Adobe Analytics.

Implementing Analytics with Dynamic Tag

Management

59 d) Configure the following fields:

Element

Tool Type

Tool Name

Production Account ID

Staging Account ID

Description

The Marketing Cloud solution, such as Analytics, Target, Social, and so on.

The name for this tool. This name displays on the Overview tab under Installed

Tools.

A number for your production account for data collection. Dynamic Tag

Management automatically installs the correct account in the production and staging environment.

A number used in your development or test environment. A staging account keeps your testing data separate from production.

4. Click Create Tool.

The installed tool displays on the Overview tab.

To configure the code, click Settings ( ).

At a minimum, click Cookies and configure your tracking server and SSL tracking server.

6. Click General and

insert the core AppMeasurement code

7. Define a

page load rule

to collect Analytics data.

You are now ready to define rules to collect analytics data. You might want to define a few data elements first.

Data elements let you extract data from the page that you can use to configure your rule. To get started, you can define a page load rule that does not have any conditions to collect Analytics data on each page.

Add the header and footer code

on the Embed tab.

Implementing Analytics with Dynamic Tag

Management

For staging, you can leave the default Amazon hosting option.You can change it if needed before your production rollout.

(Optional) Click Settings ( ) on the Options tab, and configure the Adobe Analytics code.

Note: The settings on the Adobe Analytics page (General, Cookies, and so on) override settings in your s_code

. If these settings exist in your s_code

, there is no need to reiterate them here.

Create a Data Element

Create a data element in Dynamic Tag Management.

Create Web Property

, if you haven't done so already.

2. In the web property, click Rules > Data Elements.

3. Click Create New Data Element.

4. Complete the following fields and options:

Option Description

Name

The data element friendly name that a marketer can recognize. For example,

Product

Note: The name is referenced by the rules builder, not an ID. If you change the name of the Data Element , you must change its reference in every rule that uses it.

Type

Default Value

Specifies where the data is pulled from, such as JS Object, CSS Selector, Cookie, URL

Parameter, or Custom Script.

Depending on which type you select, different options display. See

Types of Data Elements

in the Dynamic Tag Management Product Documentation for more information and examples.

A default element. This value ensures that the data element always has a value, even if a URL parameter does not exist or cannot be found by Dynamic Tag Management.

Note: If there is no value and no default value, then nothing is returned. Any variable referencing that data element won't get set. Note also that the default value field is ignored if it's a "custom code" data element.

Force lowercase value

Remember this value for

Dynamic Tag Management automatically makes the value lowercased.

How long you want Dynamic Tag Management to remember this value.

Valid values include:

• Session: Session-based timing can vary depending on the implementation. Session data elements are set to the session cookie. However, this setting could be based on

Implementing Analytics with Dynamic Tag

Management

Option Description

a web server or the browser. It is not related to the session used in marketing reports

& analytics.

• Pageview

• Visitor

See

Data Elements

in the Adobe Tag Management Product Documentation for more information about how to use data elements.

5. Click Save Data Element.

Create New Rule

Steps that describe how to create rules in Dynamic Tag Management.

Create Web Property

, if you haven't done so already.

2. In the web property, click the Rules tab.

3. Select the type of rule you wish to create from the left navigation pane, such as Event Based Rules or Page Load

Rules.

4. Click Create New Rule.

5. Name the rule and select a category, if you wish.

6. Next, set up the condition(s) for the rule. The setup differs depending on the type of rule you are implementing.

Type of Rule Refer to this Topic

Event-based rule

Page Load rule

Direct Call rule

Create Conditions for Event-Based Rules

Create Conditions for Page-Load Rules

Create Conditions for Direct-Call Rules

The category field is only for your own organizational purposes and is not required. You can delete categories by clicking the x icon in the category.

Set Up Actions for the Condition to Trigger

Create Conditions for Event-Based Rules

Conditions determine when an event-based rule is triggered.

1. Select the type of interaction you want to track, such as mouse clicks, or submitting a form.

Implementing Analytics with Dynamic Tag

Management

For more information, see

Event Types

in the Adobe Tag Management Product Documentation.

2. Enable the following options as necessary:

Element Description

Delay Link Activation Enable if the event activates a link and you want the link to delay until the event has time to fire.

Apply event handler directly to element

Applies the event handler to the specific element that is targeted. This setting is tied to the bubbling and layering concept in a browser.

For example, when you click an image inside an anchor tag like

, you might expect the click to be associated with the anchor tag, because the tag is in the bubble stream. However, when you inspect the click in the developer tools, the click may actually affect only the

<img>

tag. To ensure that the event is handled correctly, associate the click with the

<img>

tag and do not depend on the browser to bubble up the click to a parent element. An event like a click can potentially bubble up

Implementing Analytics with Dynamic Tag

Management

63 to

<body>

. It is important to understand where the event is actually bound, and target it specifically to make sure that the rule fires correctly.

Bubbling means that the event is first captured and handled by the inner most element and then propagated to outer elements.

3. Indicate the name of the tag you want to track, and additional properties the tag has that you want to match.

See

Using the CSS Selector

in the Dynamic Tag Management Product Documentation for information about finding the correct element tag.

4. Select and set up any additional criteria or condition types you wish to bind to the rule.

Implementing Analytics with Dynamic Tag

Management

5. Indicate your preference regarding event bubbling.

Event bubbling is one way of event propagation in HTML DOM.

If you...

Check this option

Want related interactions on child elements of the rule selector you identified to fire the rule.

Allow events on child elements to bubble.

Want to prevent bubbling when the child element already triggers its own event.

Do not allow if child element already triggers event.

Don't want the events of the rule selector you identified to go beyond the element itself in the event hierarchy.

Do not allow events to bubble upwards to parents.

Create Conditions for Page-Load Rules

Create rules that determine on what pages a rule is triggered.

1. Specify where on the page you want the rule to trigger.

The timing of where the rule fires on the page becomes more important when there are dependencies on page content within the rule.

Implementing Analytics with Dynamic Tag

Management

2. Specify the condition that causes the rule to fire.

For example, you can select Path to identify specific pages for which you want the rule to fire.

Implementing Analytics with Dynamic Tag

Management

Create Conditions for Direct-Call Rules

Create conditions for direct-call rules.

In the Conditions dialog, specify the string that will be passed to

_satellite.track()

in your direct call, without quotes.

Note: If you specify the string that will be passed to

_satellite.track()

in your direct call using the UI,

as described above, do not use quotation marks. If you insert customized page code using the editor, you

must use quotation marks.

Set Up Actions for the Condition to Trigger

Set up actions that you want the condition to trigger.

Implementing Analytics with Dynamic Tag

Management

After setting up the condition, you must set up the actions that you want the condition to trigger. These actions can include Analytics events, third-party tags, and custom scripts. This example describes how to set up scripts or third-party tags.

Beyond integrated tools like Adobe Analytics and Google Analytics, Dynamic Tag Management can trigger any type of JavaScript or inject HTML into your site, in select pages or in specific scenarios.

Each rule can trigger as many scripts or HTML injections as you want.

Note: Because DTM allows you to inject custom code into your page, please take care not to create cross-site scripting (XSS) vulnerabilities (see OWASP’s guide for more info). Using data elements within a script requires particular attention. Always assume data element values might come from an untrusted source.

To set up actions for the condition to trigger

1. Click JavaScript / Third Party Tags to add a new script to your rule.

2. Click Add New Script.

3. Name the script.

Implementing Analytics with Dynamic Tag

Management

4. Specify how you want the script to trigger, and paste the desired content into the text

a e r a

Implementing Analytics with Dynamic Tag

Management

5. Click Save Code, and the script will be added to the queue for the

e l u r

Test Unpublished Rules for Akamai Hosting

Test unpublished rules from your console if you use Akamai hosting.

The Switcher plugin is often the easiest way to test. See

Search Discovery Plugins

in the Dynamic Tag Management

Product Documentation for more information.

The following steps show how to test without using the Switcher plugin:

1. Access your web console on your site and type localStorage.setItem('sdsat_stagingLibrary', true)

2. Press Enter.

3. Type

_satellite.setDebug(true)

, then press Enter.

4. Refresh the page.

This action loads your staging library and sets the debugger, so that you can see details of all available (published

/ unpublished) rules firing on the page.

5. When finished, run localStorage.setItem('sdsat_stagingLibrary', false)

, then press Enter.

Test Rules for Library Download or FTP

If you use library download or FTP delivery, or you do not have a testing environment, you can use a Rewrite tool such as Charles to test unpublished rules. This need varies based on your specific implementation.

Implementing Analytics Using JavaScript

To begin using Analytics, data must be sent to a report suite to display in reporting.

The easiest and recommended way to send data to Analytics is by using

Dynamic Tag Management

. However, in

some cases, you might want to implement Analytics using the older JavaScript method.

Note: This section describes the legacy method of implementing Analytics. All Analytics customers have access to Dynamic Tag Management which is the standard method to deploy Marketing Cloud tags.

Implementation Steps

To successfully implement a page with code to collect data, you must have access to your hosting servers to upload new content to your website. It is also useful to have an existing site to implement code.

The following steps walk you through a basic Analytics implementation.

Step Task

Download

AppMeasurement for

JavaScript and the

Visitor ID service.

Description

The download is available in

Code Manager

This download zip contains several files.

AppMeasurement.js

and

VisitorAPI.js

are the relevant files when implementing Analytics.

Set up the Marketing

Cloud ID service.

(Formerly Visitor ID service.) See

Set Up the Marketing Cloud ID Service for

Analytics

Update

AppMeasurement.js

Copy the

Example AppMeasurement.js Code

and paste it at the beginning of

your

AppMeasurement.js

file. At a minimum, update the following variables:

• s.account="INSERT-RSID-HERE"

• s.trackingServer="INSERT-TRACKING-SERVER-HERE"

• s.visitorNamespace = "INSERT-NAMESPACE-HERE"

• s.visitor = Visitor.getInstance("INSERT-MCORG-ID-HERE")

See

Correctly populate the trackingServer and trackingServerSecure variable

contact Client Care

if you are unsure about any of these values. If they are not set correctly, data will not be collected by your implementation.

Host

AppMeasurement.js

and

VisitorAPI.js

These core JavaScript files must be hosted on a web server that is accessible to all pages on your site. You need the path to these files in the next step.

Reference

AppMeasurement.js

and

VisitorAPI.js

on all site pages.

Include the Visitor ID Service by adding the following line of code in the

<head> or <body> tag on each page.

VisitorAPI.js

must be included before

AppMeasurement.js

Include AppMeasurement for JavaScript by adding the following line of code in the

<head>

<body>

tag on each page:

Implementing Analytics Using JavaScript 71

Step Task Description

Update and deploy page code.

Copy the

Example Page Code

and paste it just after the opening

<body>

tag on each page you want to track. At a minimum, update the following variables:

• var s=s_gi("INSERT-RSID-HERE")

• s.pageName="INSERT-NAME-HERE" // for example, s.pageName=document.title

Use the DigitalPulse

Debugger to verify that data is being sent.

Install the

Implementing Analytics Using JavaScript

bookmarklet. After it is installed, load a page where you have deployed page code and then open the debugger. The debugger displays details about the collection data that was sent.

Caching

The JavaScript file is cached in the visitor's browser after it is initially loaded, and is typically downloaded no more than once per session. The file is not downloaded on each page, even though it is used by every page on the site.

On most websites, users average more than a few page views per session, so transferring JavaScript that is used multiple times into this file can result in less overall downloaded data.

JavaScript for AppMeasurement Compression

If you are concerned about page weight (size) of H Code (AppMeasurement for JavaScript 1.0 is pre-compressed),

Adobe recommends that you consider compressing the file using GZIP. GZIP is supported by all major browsers and offers better performance than JavaScript compression to compress and decompress the core s_code.js

JavaScript file.

The following links help explain how you can use GZIP functionality on your site to handle compression of the s_code.js

JavaScript code:

Apache Module mod_deflate

Enabling gzip compression with Tomcat and Flex

Example Page Code and Global Configuration

This section contains example code for your core JavaScript file and the pages on your site.

Important: This example uses the visitor ID service, which is deployed as part of your

Implementing Analytics

Using JavaScript

. Enabling the visitor ID service in AppMeasurement before you have included the Visitor API

JavaScript file on all site pages could result in duplicate visitor counts. To avoid duplicate visitor counts, make sure that you understand and follow the process described in

Visitor ID Service

Example AppMeasurement.js Code

Important: Configuration variables should be set above the doPlugins function.

For new implementations, you can paste the following global configuration code at the beginning of

AppMeasurement.js

to get started:

//initialize AppMeasurement var s_account="INSERT-RSID-HERE"

Implementing Analytics Using JavaScript var s=s_gi(s_account)

/******** VISITOR ID SERVICE CONFIG - REQUIRES VisitorAPI.js ********/ s.visitor=Visitor.getInstance("INSERT-MCORG-ID-HERE")

/************************** CONFIG SECTION **************************/

/* You may add or alter any code config here. */

/* Link Tracking Config */ s.trackDownloadLinks=true s.trackExternalLinks=true s.trackInlineStats=true s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,wmv,pdf,doc,docx,xls,xlsx,ppt,pptx" s.linkInternalFilters="javascript:" //optional: add your internal domain here s.linkLeaveQueryString=false s.linkTrackVars="None" s.linkTrackEvents="None"

/* uncomment below to use doPlugins */

/* s.usePlugins=true function s_doPlugins(s) {

// use implementation plug-ins that are defined below

// in this section. For example, if you copied the append

// list plug-in code below, you could call:

// s.events=s.apl(s.events,"event1",",",1);

} s.doPlugins=s_doPlugins */

/* WARNING: Changing any of the below variables will cause drastic changes to how your visitor data is collected. Changes should only be made when instructed to do so by your account manager.*/ s.trackingServer="INSERT-TRACKING-SERVER-HERE" s.trackingServerSecure="INSERT-SECURE-TRACKING-SERVER-HERE"

/************************** PLUGINS SECTION *************************/

// copy and paste implementation plug-ins here - See "Implementation Plug-ins" @

// https://marketing.adobe.com/resources/help/en_US/sc/implement/#Implementation_Plugins

// Plug-ins can then be used in the s_doPlugins(s) function above

/****************************** MODULES *****************************/

// copy and paste implementation modules (Media, Integrate) here

// AppMeasurement_Module_Media.js - Media Module, included in AppMeasurement zip

// AppMeasurement_Module_Integrate.js - Integrate Module, included in AppMeasurement zip

/* ============== DO NOT ALTER ANYTHING BELOW THIS LINE ! ===============

Example Page Code

For new implementations, you can paste the following page code just after the opening <body> tag on pages you want to track:

/* You may give each page an identifying name, server, and channel on the next lines. */ s.pageName="" s.server="" s.channel="" s.pageType="" s.prop1="" s.prop2="" s.prop3="" s.prop4="" s.prop5=""

/* Conversion Variables */ s.campaign="" s.state=""

Implementing Analytics Using JavaScript 73 s.zip="" s.events="" s.products="" s.purchaseID="" s.eVar1="" s.eVar2="" s.eVar3="" s.eVar4="" s.eVar5="" var s_code=s.t();if(s_code)document.write(s_code)//--></script>

Make sure that you have also included a reference to

AppMeasurement.js

and

VisitorAPI.js

on each page. See

for instructions.

About AppMeasurement for JavaScript

AppMeasurement for JavaScript is a new library that provides the same core functionality of s_code.js

, but is lighter and faster for use on both mobile and desktop sites.

Things to know before you migrate

The following list contains changes you need to understand before switching to this new AppMeasurement version:

• Some plug-ins are no longer supported. See

AppMeasurement Plug-in Support

• The library does not support dynamic account selection (

s.dynamicAccountList

s.dynamicAccountMatch

, and

s.dynamicAccountSelection

• The library and page code can be deployed inside the

<head>

tag.

• The Media and Integrate modules are supported using updated module code that is in the JavaScript

AppMeasurement download package. The Survey module is not supported.

• Your existing page code is compatible with the new version.

• The library provides native utilities to get query parameters, read and write cookies, and perform advanced link tracking.

Frequently Asked Questions

See the

FAQ

for information about performance, video tracking, mobile, and more.

Initialization process

Call s_gi()

, passing the report suite ID to initialize an AppMeasurement instance: var s_account="INSERT-RSID-HERE" var s=s_gi(s_account)

When s_gi

is called, if an AppMeasurement instance does not exist for the specified s_account

, a new instance is created. Otherwise the existing instance is returned. This helps avoid creating duplicate objects for the same account.

Retrieve an AppMeasurement instance

Throughout your code, call the global

s_gi() function

to retrieve an existing AppMeasurement instance.

Utilities

JavaScript AppMeasurement provides the following built-in utilities:

•

Util.cookieRead

•

Util.cookieWrite

•

Util.getQueryParam

Implementing Analytics Using JavaScript 74

Clear Vars

A new clearVars

method is available to clear the following values from the instance object:

• props

• eVars

• hier

• list

• events

• eventList

• products

• productsList

• channel

• purchaseID

• transactionID

• state

• zip

• campaign

For example: s.clearVars()

Benefits

• 3-7x faster than H.25 code.

• Only 21k uncompressed and 8k gzipped (H.25 code is 33k uncompressed and 13k gzipped).

• Native support for several common plugins ().

• Small and fast enough to be used with mobile sites, and robust enough to be used on the full desktop web, allowing you to leverage a single library across all web environments.

Migrating to AppMeasurement for JavaScript

The following table contains a list of tasks you need to perform to migrate your implementation.

Note: We recommend migrating to the Marketing Cloud ID Service

when you migrate to AppMeasurement for JavaScript.

Step Task

Check plug-in compatibility

Download the new

AppMeasurement

Copy your s_code.js

customization to

AppMeasurement.js

Where

s_code.js

Description

Some plug-ins are longer supported. See

AppMeasurement Plug-in Support

Admin Console > Code

Manager

The download zip contains a minified

AppMeasurement.js

file, and Javascript files for the Media and Integrate modules.

s_code.js

and

AppMeasurement.js

Move all code that appears before the

DO NOT

ALTER ANYTHING BELOW THIS LINE

section in s_code.js

to the beginning of

AppMeasurement.js

Implementing Analytics Using JavaScript 75

Step Task

(Optional) Update plug-ins

Where

AppMeasurement.js

Description

If you are using the getQueryParam plug-in, update these calls to use the new utility,

Util.getQueryParam

(Optional) Update Media and

Integrate modules

AppMeasurement.js

If you are using either of these modules, copy and paste the code from

AppMeasurement_Module_Media.js

and/or

AppMeasurement_Module_Integrate.js

and paste it just before the

DO NOT ALTER

ANYTHING BELOW THIS LINE

AppMeasurement.js

Deploy new JavaScript Your website

The new JavaScript file can be deployed according to your standard process. Your existing page code is compatible with this version.

AppMeasurement Plug-in Support

Plug-in support has changed in the new version of JavaScript AppMeasurement.

Tested Plug-ins

The following plug-ins were tested and verified as compatible:

•

appendList

• crossVisitParticipation

• userAgentManager

•

getTimeParting

• join

• split

•

getDaysSinceLastVisit

•

getNewRepeat

• getTimeToComplete

• manageVars (requires s.pt

plugin utility)

• channelManager

• Cookie Combining Utility

• getPageName

Untested Plug-ins

The following plug-ins should continue to work since the underlying functionality is still supported, but they have not been tested and verified as compatible. You should test these plug-ins in your development environment before migration.

• getActionDepth

•

getAndPersistValue

Implementing Analytics Using JavaScript 76

• getCookiesAccepted

•

getValOnce

Unsupported Plug-ins

These plug-ins are not supported and no longer function due to their use of functionality that no longer exists in the new AppMeasurement for JavaScript library.

• callBack

• channelExtract

• detectRIA

• deviceOrientationChanges

• DynamicObjectIDs

• Form Analysis

• manageQueryParam

• HTML5Storage

Accelerated Mobile Pages

Implement the Accelerated Mobile Pages (AMP) project in Adobe Analytics.

AMP is an

open source project

that lets you build web pages for static content that renders quickly. This feature is ideal for publishers who want to create mobile-optimized content once, and have it load instantly everywhere. Topics include:

•

How it Works

•

Using the amp-analytics tag with the "adobeanalytics" template

•

Using the amp-analytics tag with the "adobeanalytics_nativeConfig" template

•

Summary

•

Frequently Asked Questions

Additional Documentation and Examples

• External, open-source AMP project

documentation

• Setup

examples

How it Works

AMPs have specially tagged HTML pages cached around the web on different content delivery networks (CDNs) of participating technology partners and publishers. By doing this, AMP content is delivered from the closest possible source with the lowest possible latency. This creates an analytics challenge because you can never be 100% sure where a publisher's content will be loaded from, and third-party cookies are troublesome for visitor identification.

In addition, to dramatically reduce page weight and speed page load time, AMPs restrict the use of JavaScript and cookies. While this is advantageous for your mobile device because it reduces the amount of processing, it introduces challenges to accurately measuring unique visitors and understanding user acquisition and retention.

To solve these problems, Adobe has collaborated with AMP partners and publishers on two options that a publisher can choose from to best suit their business needs, both using the amp-analytics

tag. The first approach uses the

"adobeanalytics"

tracking template to construct the Analytics request directly from within the AMP. The second approach uses the

"analytics_nativeConfig"

tracking template, which uses an iframe containing the

AppMeasurement code you deploy on your normal site. The following table gives you an idea of the pros and cons of each approach.

Implementing Analytics Using JavaScript 77

"adobeanalytics" template

Visitor/visit counts (in existing report suite)

High inflation

Using a separate report suite

New vs. return visitors

Visitor ID service

Video & link tracking

Difficulty of implementation

Marketing Cloud integrations

Recommended

Not supported

Partial support

Somewhat difficult

Not supported

"adobeanalytics_nativeConfig" template

Minimal inflation

Not necessary

Supported

Not yet supported

Relatively easy

Supported with caveats

Using the amp-analytics tag with the "adobeanalytics" template

The

"adobeanalytics" tracking template utilizes the amp-analytics

tag to construct a tracking request directly.

Using the

"adobeanalytics"

template in the amp-analytics

tag, you can specify hit requests that fire on specific page events, like the page becoming visible or on a click (and in the future, video views and more). Click events can be customized to apply to certain element IDs or classes by specifying a selector. Adobe has made this easy to set up using the

"adobeanalytics"

template specifically designed for Adobe Analytics. You can load the template by adding type="adobeanalytics"

to the amp-analytics tag.

In the following code example, there are two triggers defined: pageLoad

and click

. The pageLoad

trigger will fire when the document becomes visible and will include the pageName

variable as defined in the vars section

. The second trigger click

will fire when a button is clicked.

eVar 1

will be set for this event with the value button clicked

<amp-analytics type="adobeanalytics">

{

"requests": {

"myClick": "${click}&v1=${eVar1}",

"vars": {

"host": "metrics.example.com",

"reportSuites": "reportSuiteID",

"pageName": "Adobe Analytics Using amp-analytics tag"

"triggers": {

"pageLoad": {

"on": "visible",

"request": "pageView"

"click": {

"on": "click",

"selector": "button",

"request": "myClick",

"vars": {

"eVar1": "button clicked"

}

</script>

</amp-analytics>

In the click

trigger, you can specify a selector to ensure that whenever the specific DOM element is clicked (in this case, any button), the buttonClick

request is fired and will be automatically set to denote this hit as a non-stage event (i.e.

trackLink

call).

Implementing Analytics Using JavaScript 78

Additionally, amp-analytics

supports a number of variable substitutions so that AMP can provide data values that it is aware of. You can learn all about those and more by visiting:

amp-analytics variable documentation

Be aware that if you want to incorporate any technology or DOM variables (such as browser, screen size, device, referrer, etc.) you will have to explicitly add them to any request, as they are not automatically generated for you.

Documentation on each of our available query string parameters used for tracking can be found

here

If you inspect the hits created by amp-analytics, you will notice that in each request, Adobe has included the vid query parameter. We set the vid

based on a built-in AMP function to set a custom Analytics cookie ID named adobe_amp_id

. This ID is independent of any other ID being set by Adobe Analytics elsewhere (e.g.

s_vi cookie

) and creates new visitors in any report suite the hits are sent to.

There are a few caveats to be aware of. When using the amp-analytics tag as mentioned above, visitors will be independent of your normal tracking, and because the AMP can be loaded from any content delivery network, you will get a unique visitor for each CDN a visitor sees this AMP on (hence the visitor inflation mentioned previously).

For this reason, Adobe recommends that if you use the

"adobeanalytics"

template for amp-analytics

, you put your data into a separate report suite specific to AMP. Also, the Marketing Cloud ID service (formerly, visitor ID

service) is not supported using this method, so if your business requires additional Marketing Cloud integrations, or will in the future, this is probably not the option for you.

Finally, and perhaps most importantly, this amp-analytics

solution requires that the tracking server you specify in the vars

section matches the tracking server on your main site, so that your existing privacy policy controls are respected. Otherwise, you must create a separate privacy policy just for AMPs.

Using the amp-analytics tag with the "adobeanalytics_nativeConfig" template

The

"adobeanalytics_nativeConfig"

tag is easier to implement, as it will use the same tagging methodology you use on your normal web pages. To accomplish this, add the following to your amp-analytics

tag:

<amp-analytics type="adobeanalytics_nativeConfig">

{

"requests": {

"base": "https://${host}",

"iframeMessage":

"${base}/stats.html?campaign=${queryParam(campaign)}&pageURL=${ampdocUrl}&ref=${documentReferrer}"

"vars": {

"host": "statshost.publishersite.com"

"extraUrlParams": {

"pageName": "Adobe Analytics Using amp-analytics tag",

"v1": "eVar1 test value"

}

</script>

</amp-analytics>

This approach sends data to a utility web page via special query string parameters added to the iframeMessage request parameter. In this case, notice that we have added the ampdocUrl AMP

variable, and the documentReferrer to the query string parameters pageURL

, and refer respectively to the iframeMessage

request above. These extra query string parameters can be named whatever you like, as long as your stats.html

page (shown below) is configured to collect the appropriate data from them.

Implementing Analytics Using JavaScript 79

The

"adobeanalytics_nativeConfig"

template also adds query string parameters based on the variables listed in the extraUrlParams

section of the amp-analytics tag. In this case, you can see we have specified the pageName and v1

parameters , which will be used by our stats.html

page.

Be aware that you can only use a single amp-analytics

template at a time and can not use the

"adobeanalytics" template as well as the

"adobeanalytics_nativeConfig"

template on the same AMP. If you attempt to do so, you might see an error in the browser console, and you will erroneously inflate your visitor count.

<html>

<head>

<title>Stats Test</title>

<html>

<head>

<title>Stats Test</title>

</head>

<body>

</script>

</body>

</html>

As shown above, you can use or link to your existing

VisitorAPI.js

and

AppMeasurement.js

(as in our example), or whatever your existing implementation uses, then add the correct configuration parameters. To capture the correct values into the correct variables, you can use the provided s.Util.getQueryParam

function to grab the value(s) that you passed in from the iframeMessage

URL and set the appropriate variables, just as you would on a typical page. If you use tag management software like Adobe's

Dynamic Tag Manager

, the query string parameters should be straightforward to capture. In this case, s.pageName

is set to the value we passed in the query string parameter pageName

. Here, the page name would be set to Adobe Analytics Example 2.

Important: Due to restrictions on iframes in the AMP framework, your stats.html

page must be hosted on a separate subdomain from the domain the AMP itself is hosted on. The AMP framework does not allow for iframes from the same subdomain that the AMP page itself exists on. For example, if your AMP is hosted on amp.example.com

, be sure to host your stats.html

page on a separate subdomain such as ampmetrics.example.com

or something similar.

Because the utility page is hosted on your original site, no additional work is needed to support your existing privacy policy across all AMPs. This means that if an end user opts out of tracking on your primary site, they are also opted out of tracking on all your AMPs, with no additional steps required. Using this utility page also means that AMP can

Implementing Analytics Using JavaScript 80 support Adobe's Marketing Cloud ID service so that you can integrate the measurement captured on your AMPs with the rest of the Marketing Cloud (for targeted advertising using Adobe Audience Manager for example).

To reiterate, if your organization is not yet using the Marketing Cloud ID service (or has tag management software like Adobe's Dynamic Tag Manager), you can tag the stats.html

page however you want. Use your existing implementation as a reference point. The only difference from your standard implementation is that you will get the applicable data points from the amp-analytics iframeMessage

URL (or document.URL

from within the stats.html

page ) for each of the variables you want to set. Also, if you want to use any of the

AMP specific variables

(as mentioned above) like the AMP referrer or AMP page URL, please include them in the iframeMessage object as shown in our example above.

As flexible as this solution is, there are caveats. Due to inherent restrictions in the amp-analytics iframeMessage

, it can only be loaded on a page load once. This means you will not be able to do link tracking or video tracking with the

"adobeanalytics_nativeConfig"

template. Moreover, some DOM values that are typically captured automatically by our AppMeasurement code, such as referrer

(which impacts the Search Engine Keyword reports, Referrer, and Referrer Type reports, or may include a marketing campaign tracking code) will have to be passed manually to the iframeMessage

using whatever AMP variables

are available

. For this reason, Adobe recommends setting a custom variable with the value AMP if you put AMP data into an existing report suite, so that you can segment out

AMP traffic when viewing the aforementioned reports. That said, standard technology reports, such as browser, device, screen size or resolution, should work automatically.

Finally, because the iframe loads as a separate page and fully executes the JavaScript on that page, the AMP is not as lightweight as the AMP standard intended. To be clear, this does not affect page load time (the iframe loads after the page is done loading), but the CPU and network will be doing slightly more than they otherwise would, which might impact scrolling smoothness. In practice, we have not seen a large impact, but we are working with

Google to minimize the user experience impact of this approach.

Summary

If you need click tracking and don't mind visitors being counted as entirely new visitors separate from your site, use the

"adobeanalytics"

tracking template, with our recommendation that you put the data into a separate report

suite. If you need the Marketing Cloud ID service, do not want visitor or visit inflation, and are okay with only firing

Analytics on page load, we recommend using the

"adobeanalytics_nativeConfig"

solution.

Adobe Analytics is excited to partner with Google and our publishers to bring industry leading analytics capabilities to publishers on the mobile web in a blazing fast user experience. Although these two solutions currently offer their own tradeoffs, we are committed to building the best long term solution to answer the evolving analytics needs our customers have.

The AMP Project is moving fast and changes occur frequently, so check back

here

frequently for updates to our examples. What we've shown you here should be enough to get started, but expect changes as we improve our integrations further and as more publishers adopt AMP over time.

If you have questions or problems, please reach out to your Adobe Consultant or Customer Care.

Frequently Asked Questions

Question Answer

Is video tracking available for either the

"adobeanalytics"

Unfortunately, not yet. The AMP standard supports only triggers for "visible",

"click", and "timer", and does not yet support explicit triggers for video tracking

Implementing Analytics Using JavaScript 81

Question Answer

"adobeanalytics_nativeConfig" template?

that can be listened to by the amp-analytics tag. Also, because the

"adobeanalytics_nativeConfig"

tag can only be loaded once, it is not compatible with video viewing which occurs after the AMP has loaded.

You mention that visitor inflation is lower for the

"adobeanalytics_nativeConfig" template in your comparison. What does that mean? What would cause visitor inflation in the

"adobeanalytics"

solution?

There is only one scenario in which visitor/visit inflation will occur:

A visitor using Safari and who has never been to publisher.com's site visits an AMP page for the first time, then later visits publisher.com's normal

(non-AMP) site.

In this scenario, the visitor would be counted as two visitors in Analytics, assuming the AMP and the main site are in the same report suite. However, if the visitor had been to publisher.com's main site before visiting the AMP, it will still count as only one visitor in reporting.

Should I use a separate report suite for AMPs?

We recommend using a separate report suite for AMPs if you use the adobeanalytics template, because of the visitor/visit inflation issue. However, we will also set the JavaScript version to "AMP vX.X" from the amp-analytics tag template so that you can segment that traffic out of a combined report suite if necessary.

What is the Marketing Cloud ID service? Do I need it?

The

Marketing Cloud ID Service

(formerly visitor ID service) enables Marketing

Cloud core services and allows integrations between different Adobe

Marketing Cloud solutions. If you have integrations with Adobe Audience

Manager or Adobe Target, you are likely using this service. This service is also the foundation for many upcoming Adobe Analytics features. If you need

ID service support or will need it in the future, we recommend using the iframeMessage

solution.

For the

"adobeanalytics_nativeConfig" template, where should I host my utility page?

The AMP standard does not allow for iframes to load from the exact domain and subdomain of the AMP itself. As such, we recommend that you host the utility page on a separate subdomain from your main site, especially if your company has its own CDN that plans on caching AMPs. For maximum compatibility, pick a subdomain such as ampmetrics.publisher.com

that is apart from where the actual AMP content will reside.

Isn't this similar to Facebook Instant

Articles? How do I setup Adobe

Analytics with Facebook Instant

Articles?

Facebook Instant Articles support a similar solution to the nativeConfig solution outlined above. In fact, the stats.html page created above can serve your analytics needs for both AMP and FIA simultaneously. For more

information on implementing tracking on FIA, see

Facebook Instant Articles

Facebook Instant Articles

How to implement Analytics in Facebook Instant Articles.

Implementing Analytics Using JavaScript 82

Facebook Instant Articles is a new method for publishers to build fast, interactive articles on Facebook. Instant

Articles can load content up to 10 times faster than mobile web.

Adobe Analytics can be embedded within the Facebook Instant Articles to track visitor behavior as they interact with the content. Because publisher content is within the Facebook app and not on the publisher's websites, the tagging approach is slightly different than a standard Analytics implementation.

1. Embed an Analytics HTML page

When creating your Facebook Instant Article content, you can embed the analytics HTML content within an iFrame.

For example:

2. Modify your Analytics HTML

The sample HTML below can be used to capture stats from the instant articles. This file would typically be hosted on one of your company's web servers. Each time an Instant Article is loaded, it loads the file in an iframe as outlined in step one, which triggers sending the analytics data to Adobe.

<html>

<head>

<title>Facebook Stats</title>

</head>

<body>

//Standard Variable Configuration

var v_orgId = "[your-marketing-cloud-org-id]@AdobeOrg";

var s_account = "[your-report-suite-id]";

var s_trackingServer = "[your-tracking-server]";

var s_visitorNamespace = "[your-namespace]";

//Instantiation

var visitor = Visitor.getInstance(v_orgId);

visitor.trackingServer = s_trackingServer;

var s = s_gi(s_account);

s.account = s_account;

s.trackingServer = s_trackingServer;

s.visitorNamespace = s_visitorNamespace;

s.visitor = visitor;

//Custom Variables

s.pageName = s.Util.getQueryParam("pageName");

s.prop10 = "Facebook Instant Article";

//Page View Image Request Call

s.t();

</script>

</body>

</html>

To modify this sample HTML for your specific implementation

1. It is recommended to host the latest copies of unmodified versions of the VisitorAPI.js and AppMeasurement.js

on a common directory on your company's web servers.

These files can also be downloaded from within the Code Manager in the Analytics UI if required.

2. Include your Analytics implementation standard configuration variables:

Implementing Analytics Using JavaScript 83 a. Your Marketing Cloud Org ID.

b. The report suite ID where the Facebook Instant Article traffic will be captured.

c. Your company's tracking server domain.

d. Your visitor namespace variable. Note: Many of these values can be found within your standard Analytics implementation. Customer Care or Adobe Consulting can assist in providing the proper values if necessary.

Set custom variable and event tracking

4. Include the page view image request syntax

( s.t())

3. Set custom variable and event tracking

Custom variables and events can be tracked within your analytics HTML via different approaches. The first approach is to include JavaScript logic in your custom configuration, similar to what you might do with a standard Analytics implementation. For example, to set the value of a prop, simply use the same syntax that you would use in a normal implementation: s.prop10 = "Facebook Instant Article";

You can also dynamically send variables to the iframe by leveraging query string parameters in the iframe src attribute. For example:

height="0"></iframe>

Those query string parameters can subsequently be set in the custom variables section of your analytics HTML

JavaScript by using the

Util.getQueryParam

function within the default AppMeasurement library, as follows: s.pageName = s.Util.getQueryParam("pageName"); s.campaign = s.Util.getQueryParam("cmpId"); s.eVar1 = s.Util.getQueryParam("eVar1"); s.prop1 = s.Util.getQueryParam("prop1");

Visitor Tracking

As long as the Analytics HTML page is hosted on your web server, Adobe can support your existing privacy policy across all Facebook Instant Articles. This means that if an end user has opted out of tracking on your primary site, they will also be opted out of tracking on all your Facebook Instant Articles, with no additional steps required. Using this utility page also means that the Marketing Cloud ID service (visitor ID) is supported so that you can integrate the metrics and variables captured on your Facebook Instant Articles with the rest of the Marketing Cloud. (An example is for targeted advertising using Adobe Audience Manager).

Tracking Limitations

There are few issues that should be noted with this approach. Any DOM values that are typically only accessible via JavaScript on the Facebook Instant Article (such as referrer) will not be retrievable in the iframe for tracking.

However, standard technology reports like browser, device, screen size or resolution should work normally. Moreover, the pageURL can be obtained by referencing document.referrer

from your utility page.

What's Next?

Adobe Analytics is excited to partner with Facebook and our publishers to bring industry leading analytics capabilities to publishers on the mobile web in a blazing fast user experience. We are committed to building the best long term solution to answer the evolving analytics needs our customers have.

Implementing Analytics Using JavaScript 84

The Facebook Instant Article project is moving quickly and changes are happening all the time, so check back with us frequently for updates. Expect changes as we improve our integrations further and as more publishers adopt

Facebook Instant Articles in the future.

If you have questions or problems, please reach out to your Adobe Consultant or Customer Care.

Additional Web and Mobile Measurement Libraries

Lists the available measurement libraries.

The following table outlines the libraries available to collect Analytics data across all available platforms. For more information, see

Data Collection in Analytics

Location

Web Browser

Options

All Marketing Cloud customers have access to

Dynamic Tag Management

, which is the standard for deploying JavaScript and HTML page tags for all solutions to your website.

Other ways of implementing JavaScript and HTML measurement are described in the

Analytics Implementation Guide

Web Server

You can use native PHP and Java libraries on your web server to send analytics data.

The Data Insertion API lets you send XML data directly to the data collection server using

HTTP POST and GET, and Data Sources lets you send delimited hit data directly to

Analytics.

•

PHP AppMeasurement

•

Java AppMeasurement

•

Data Insertion API

•

Data Sources

Mobile Device

Native libraries are provided for iOS, Android, Windows Phone 8, Blackberry, Symbian, and others.

•

iOS AppMeasurement 4.x

(latest version)

•

iOS AppMeasurement 3.x

•

Android AppMeasurement 4.x

(latest version)

•

Android AppMeasurement 3.x

•

Windows Phone 8 AppMeasurement 3.x

(latest version)

•

Blackberry AppMeasurement

•

Symbian AppMeasurement

•

Silverlight, .NET, XBOX, and Windows Phone 7 AppMeasurement

Flash

Flash apps using ActionScript can be measured on the desktop and on the web.

Flash, Flex, and OSMF AppMeasurement

Desktop

•

WinRT for Windows 8 AppMeasurement 3.x

(latest version)

•

OS X AppMeasurement 3.x

(latest version)

•

Java AppMeasurement

Implementing Analytics Using JavaScript 85

Location

Video

Options

•

Silverlight, .NET, XBOX, and Windows Phone 7 AppMeasurement

Video measurement across all platforms is available in the following guides:

•

Heartbeat video measurement

(latest version)

•

Milestone video measurement

REST and SOAP Web Services (on

Developer Connection

)

•

Getting Started

•

API Documentation Home

Implementing Analytics using HTML image tags

Implement Analytics using an HTML image tag (hardcoded image request).

The browser then requests the image. Data moves with this image request via variables in the query string of the image request. The JavaScript combines browser-level variables with page-level variables for a comprehensive data collection solution. In some cases, a fully server-created image tag is appropriate. The standard elements of a JavaScript-based implementation are listed as follows:

HTML Code This portion consists of JavaScript code that is placed in HTML pages (or templates) that set the value of JavaScript variables.

JavaScript Library

This file contains common code that:

• Queries the browser about various properties, such as JavaScript version,

OS version, the size and resolution of monitor being used, and other variables

• Encodes and concatenates all the variables into an image request (<img>) that transports these variables to the data collection servers. It then references a JavaScript library file which is loaded and executed.

JavaScript can detect browser settings that are not available to a server, such as browser window height/width, monitor resolution, and Netscape plug-ins. By using a server-side method to create an image tag, these variables cannot be captured. The JavaScript sets a random number in the image request to overcome browser and proxy server caching. This allows all page views to be accurately tracked. In certain situations, server-side code has advantages over the JavaScript-based code, including the following:

• JavaScript is very accurate (98-100%). There are times when the utmost accuracy is desired, even in situations where a user quickly clicks to another page before the JavaScript has executed. Creating the image tag server-side increases the accuracy level by several percentage points.

• For tracking conversion events, such as purchases, where accuracy is very important.

• This strategy may also be used to fully populate the image request within the <noscript> tag for tracking users without JavaScript, or with JavaScript disabled.

Note: The use of server-generated image tags requires additional time to implement, and is more difficult to debug, deploy, and maintain. Adobe strongly encourages clients to use JavaScript-based data collection on

Implementing Analytics Using JavaScript 86

every page where possible. Various reports and features, including visitor click map, download links, exit links, and browser-based variables (browser width/height, etc.) cannot be collected or supported using this implementation method.

Implementing without JavaScript Guidelines

There are additional requirements and configurations for implementing Analytics without JavaScript.

You can view sample code to further understand the implementation. The following table outlines the additional requirements and configurations:

Requirement

Case-Sensitive

Description

The parameter names (pageName, purchaseID, and so forth) are case-sensitive and will not properly record data unless they appear as

designated in the table displayed in

Data Collection Query Parameters

Encode Query Parameters

The values for each of the query string parameters must be URL encoded.

URL encoding converts characters that are normally illegal when appearing in a query string, such as a space character, into an encoded character beginning with %. For example, a space character is converted into %20.

The JavaScript version of this function is called escape (and to decode, unescape). Microsoft IIS Version 5.0 also includes an Escape and

Unescape function for encoding query strings. Other Web server scripting languages also provide encoding/decoding utilities.

Maximum Variable Length

Invalid Characters

Each variable has a maximum length. This length is specified for each variable in

Analytics Variables

. Exceeding the maximum length for a

variable causes the value of this variable to be truncated for storage and display in Analytics.

Characters with character codes above decimal 128 are invalid, as are not-printing character codes under 128. HTML formatting ("<h1>") is also invalid, as are trademark, registered trademark, and copyright symbols.

Secure (https:> vs. Non-Secure (http:)

Image Requests

On pages that are accessed via https (secure protocol), the URL portion of the image request changes to accommodate a different set of data collection servers.

The following table illustrates the different URLs used for secure and non-secure image requests.

Protocol

https: http:

URL

https://namespace.<data center-specific…>.207.net/b/ss/ reportsuite

/1/G.5--NS/… http://namespace.<data center-specific

URL*>.207.net/b/ss/ reportsuite /1/G.5--NS/…

Implementing Analytics Using JavaScript

Requirement

URL and Referring URL

Effects of Caching

Description

The * in the URL above denotes a data-center specific URL that is provided to you by your Adobe Consultant. Adobe uses several data centers, and it is necessary to implement the correct URL your organization has been assigned. Any code downloaded out of Admin Console within your company account has the correct data center supplied automatically. Code provided from external sources may need to be corrected in order to point to the correct data center.

For clients who use multiple report suites, they should be listed only in the directory section, and not the domain section of the URL, as shown below.

Protocol

https: http:

URL

https://102.112.207.net/b/ss/ suite1,suite2

/1/G.5--NS/...

http:// suite1 .112.207.net/b/ss/ suite1,suite2

/1/G.5--NS/...

The URL and Referring URL may be populated from the server in the g= and r= variables. Use the Request ServerVariables (HTTP_REFERRER) or Request ServerVariables (URL) (IIS/ASP), or the appropriate variable for your server/scripting technology. The referring URL (r=) is extremely important for tracking referring URLs, domains, search engines, and search terms.

If pageName is not being used, it is imperative that the Current URL field is uniquely populated. If neither pageName nor Current URL (g=) is populated, the record is invalid and is not processed. At a minimum, the

URL is a required field in order to process the record.

HTML and other Web pages can be cached by browsers or servers that are between the visitor and the website that is serving the content. Caching prevents an accurate count of page views and other events unless a

"cache-busting' technique is employed.

Adobe's standard JavaScript includes a dynamic method of changing the image request to avoid page and image caching, allowing an accurate count of page views.

However, in creating a server-side image request, this randomization does not occur. Page reloads and cached pages (either in the browser's cache or in a proxy server) are not counted in certain cases when using server-side image requests.

Implementing Analytics Using JavaScript

Requirement

nameSpace Variable

Description

SSL (https:) pages are not, by definition, ever cached so this warning applies only to non-secure (http:) pages. Additionally, pages with parameters ( http://www.samplesite.com/page.asp?parameter=1

) or certain file extensions (

.asp

.jsp

, etc.) are also not cached.

The examples below also illustrate a minimal JavaScript solution that primarily assembles the image request server-side, and tacks on a random number in the browser. This method overcomes the caching that would otherwise be encountered on static HTML pages accessed via the http: protocol.

The nameSpace query string parameter is required for non-JavaScript implementations.

Example: ns=nameSpace

Contact your Adobe Consultant or Account Manager to obtain your organization's nameSpace value.

Sample Code

Examples to illustrate the use of a server-generated image tag within a HTML sample page.

The table below displays the values used in the sample.

Variable

pageName

Current URL events c1 purchaseID products state zip a random #

Value

Order Confirmation https://www.somesite.com/cart/confirmation.asp

purchase,event1

Registered

0123456

Books;Book Name;1;19.95

90210

123456

Example 1

The example below displays a server-side image tag. The highlighted random number prevents caching of the image.

<html>

<head>

</head>

<body>

Order Confirmation<br>

Thanks for your order #0123456.

<img src="https://102.112.207.net/b/ss/suite1,suite2/1/G.4--NS/123456?pageName=Order%20

Confirmation&events=purchase%2Cevent1&c1=Registered&purchaseID=0123456&products=Books%3BBook%20Name%3B1%3B19.95&state=CA&zip=90210&g=https%3A//www.somesite.com/cart/confirmation.asp"

Implementing Analytics Using JavaScript

width="1" height="1" border="0" />

</body>

</html>

Example 2

The example below shows a minimal JavaScript image tag.

<html>

<head>

</head>

<body>

Order Confirmation<br>

Thanks for your order #0123456.

"?pageName=Order%20Confirmation&events=purchase%2Cevent1&c1=Registered

&purchaseID=0123456&products=Books%3BBook%20Name%3B1%3B19.95&state=CA&zip=90210&g=http s%3A//www.somesite.com/cart/confirmation.asp\">"; document.write(s.s_desturl);

//--></script>

</body>

</html>

Mobile Tracking over WAP and I-Mode Protocols

This section describes the tracking methodology for legacy mobile devices that do not use http browsers.

Mobile Network Protocols

WAP and I-Mode are the two major protocols or standards used today. WAP is mostly used in the US, and I-Mode is popular in Japan and Europe.

Sites must often be designed separately for different protocols. The Adobe image tag does not need to be customized for each protocol.

WAP 1.0

WAP 2.0

WAP 1.0 is quickly losing popularity in the US. This required pages be built in WML, and had its own protocol.

Most phones are WAP 2.0 compliant, meaning they support XHTML MP (a mobile version of

XHTML).

I-Mode

I-Mode supports CHTML (compact HTML) and does not download third-party images. First-party collection domain implementations should always be used with I-Mode sites so images are downloaded.

Mobile Protocol Network Gateway

When a mobile device requests a page from a Web server, the request is sent through a gateway, which converts the mobile request (usually in the WAP or I-Mode protocol) into an HTTP request that is sent to a Web server.

Web server responds to the gateway, which forwards the request to the phone. This gateway acts much like a standard proxy server. The gateway does, however, pass the user agent string of the mobile device on to the Web server. This lets the Web server respond with a page that is built specifically for the device requesting it.

Implementing Analytics Using JavaScript 90

Because screen size on WAP mobile devices is so limited, mobile pages are very light, often containing only text and one cached image. When the image tag is added to the pages, a request is sent on every page for an image from Adobe servers. When the image, a WBMP, is returned, Adobe servers instruct the browser not to cache it.

Consequently, the image is requested again on subsequent pages. The random number described above should be used to protect against browsers that do not obey the Adobe no-cache directives.

Tagging Pages For Mobile Protocols

Mobile tracking code is placed on the page in the form of a server-generated image tag.

Mobile tracking code is placed on the page in the form of a server-generated image tag. Because scripting languages like JavaScript and WMLScript are not generally supported across mobile devices, the tracking beacon cannot be generated dynamically via a scripting language.

· While the mobile beacon image is actually 2x2 pixels, to ensure support for all mobile devices, you should set height and width properties to 5. For example:

<img sr c="http://metric.mydomain.com/b/ss/<Report_Suite_Name>/5/<random_number>?pageName=" alt="" width="5" height="5"/>

Use a Random Number to Prevent Caching

While Adobe servers instruct browsers not to cache the tracking beacon, not all browsers are guaranteed to follow those instructions. To further prevent caching of the beacon, it is recommended that the Web server dynamically generate a random number in the image URL path. Doing so insures greater accuracy of reporting. The random number should be in the last section of the path, as shown here:

<img src="http://rsid.112.2O7.net/b/ss/rsid/5/H.5--WAP/12345?pageName=" />.

Include an ALT Tag

Some mobile browsers require that all images have alt text included in the image tag. The following shows how the

ALT attribute should appear in the image tag:

<img src="http://rsid.112.2O7.net/b/ss/rsid/5/H.5--WAP/12345?pageName=" alt=""/>.

It is important that the /5/ always appears correctly in the path. This is used by Adobe servers to identify mobile devices. If the standard /1/ is used, Adobe servers attempt to set a cookie on the mobile device.

Change the Default Image Type

If the default image type is not supported on a particular device, no data is returned. To avoid this, you can force the Adobe data collection server to return a particular graphic type that the mobile device supports. The code following the report suite name specifies the image type:

•

/5/

returns the default image type.

•

/5.1/

/1/

always returns a GIF image.

•

/5.5/

always returns a WBMP image.

See

Identifying Mobile Devices

Reports for Devices Using Mobile Protocols

Because mobile devices are tracked via a beacon, just like other visitors, most reports are available and correct.

VISTA can be used to alter data collected from both Mobile and standard methods. All CustomInsight (prop and

eVar), Event, Site Traffic, and Pathing reports are supported.

Implementing Analytics Using JavaScript 91

Search Engines, Search Keywords, Referring Domains, and Referrers

These reports only have data if the referrer is populated in the image request sent from the mobile page. The referrer is populated via the "r" query string parameter, as outlined in the Implementing without JavaScript white paper. You must also manually pass the referrer information into the image request.

The ‘r’ query string parameter must include the protocol of the referrer. If the protocol is left off, the referrer report is not populated. For example, use r=http://msn.com

not r=msn.com

Geosegmentation and Domains

Geosegmentation reports are based on the IP address of the device sending the request. Because mobile devices rely on a gateway to request images from Adobe servers, the gateway's IP address is used to determine the geo-location of the user. Because gateways and their IP addresses are registered for large networks, the associated geo-location is often less accurate.

Domains are also based on the IP address of the gateway, which means the domains report often contains the name of the carrier who owns the gateway. Due to Mobile Virtual Network Operators (MVNOs), this may not be accurate.

Connection Types

Adobe maintains a known range of IP addresses that belong to mobile carriers. When a hit is received from an IP range that belongs to a known mobile carrier, the hit appears as "Mobile Carrier" on the Connection Type Report.

Otherwise, mobile traffic is listed under "Lan/Wifi".

Time Zones, Cookies, Java, JavaScript, Monitor Colors and Resolutions, Browser Width and Height, and

Netscape Plug-ins

These reports are all collected by using JavaScript to detect specific settings of the browser. Because JavaScript is not used to create the image beacon on mobile devices, data collected from mobile users is not included in these reports.

Custom Link Measurement on Mobile Protocols

Many mobile device users download files to their devices such as podcasts, ring tones, and similar files. Because many mobile devices do not support JavaScript, link measurement must be implemented through redirects. To use redirects, you must modify the href links in the html to include the REDIR element. The general format for a custom link is as follows: http://<your_Namespace>.112.2o7.net/b/ss/<RSID>/4/REDIR/

?url=<destination_URL>&pe=<link_type>&pev1=<current_URL>&pev2=<link_name>

Keep in mind the following when creating link reference:

• The URL value must be URL encoded.

• You should set a pageName or page URL (g) parameter.

• Dynamic variables can read the URL parameter but not set it.

• If no cookie is set, Adobe servers perform a normal cookie handshake.

• To track links, you must include pe, pev1, and pev2 parameters.

A custom link measurement URL looks similar to the following:

<a href=" http://johnny_appleseed.122.2o7.net/b/ss/appleseedpodcasts/4/REDIR/

?url=http%3A%2F%2Fwww.johnny_appleseed.org%2Fmpegs%2Fplanting_apple_trees.mpeg&pe=lnk_d

&pev1=http%3A%2F%2Fwww.johnny_appleseed.org%2Fmpegs%2Fplanting_apple_trees.mpeg&pev2=pl anting_apple_trees&">Planting an Apple Tree</a>

Implementing Analytics Using JavaScript

For more information, see the

Exit Link Tracking Redirects whitepaper

Tag management 2.0

Adobe Tag Management Deprecation Notice

Important:

In September 2013, Adobe launched Dynamic Tag Management (DTM) as an included core service of the

Adobe Marketing Cloud. As part of our ongoing commitment to expand and add continued value to the DTM platform, Adobe Tag Manager (ATM) will be discontinued, and customers will be transitioned to DTM. The advantages of DTM include significantly improved integrations with Adobe marketing solutions and the overall

Marketing Cloud, improved tag performance, and powerful rule-based controls over when and how your tags are deployed.

We want to make this transition as smooth as possible, so here is what you need to know about our transition plan:

• Starting August 1, 2015, you will no longer be able to edit your tags or containers in ATM. You will still be able to log into the application to view and export existing tags and containers, and your tags will continue to be served. However, if you want to make changes, you will need to deploy DTM on your site(s) and transition these tags to DTM.

• Starting October 1, 2015, the ATM application will become unavailable and your tags will no longer be served.

If you have not transitioned your sites away from ATM by this date, it is possible that your website visitors may experience errors. It is critical that you transition prior to this date. Adobe will begin sending periodic reminders between now and this date to remind you to begin the migration process as soon as possible.

See Migrating from Adobe Tag Manager for information about migrating to DTM from ATM versions 1.0 and

2.0.

Tag management Architecture

This section describes the architecture of tag management and changes to the architecture from version 1.0.

Before tag management, an Analytics implementation included a JavaScript file that you hosted on your website, called s_code.js

. Each page included a snippet of code that leveraged this core JavaScript file. When updates were released or if you wanted to use an additional module or plug-in, the JavaScript file had to be updated. Target,

AudienceManager, and other products used a similar process.

With tag management, you now place a snippet of code on your pages, and all tags are loaded directly from tag management, including any core JavaScript required. Tag updates and new tag deployments are managed in the tag management UI.

Implementing Analytics Using JavaScript 93

Tag management architecture includes the following:

• New, product-agnostic page code for invoking the tag loader and tag containers.

• A fully-hosted tag loader on an Adobe-managed CDN (Akamai), with built-in availability safeguards to prevent errors. You are not required to host any JavaScript on your web server.

• Support for Target mbox.js

and global mbox deployment.

• Optional synchronous loading alongside the asynchronous container.

• Controls for managing the execution of on-page function calls.

• Enhanced rule building functionality to control tag firing, including reusable rules and support for regular expressions.

• Backwards compatibility with current Tag management page code and containers.

Changes from tag management 1.0

Version 2.0 of tag management includes significant changes to the architecture of the tool.

Tag management 1.0 leveraged existing script tagging and page code from legacy Analytics implementations. Tag management 1.0 replaced the contents of the s_code.js file with a tag container. This architecture simplified deployment since page code updates weren't required, but it had several limitations.

In tag management 2.0, the loader and tag containers are hosted on the Adobe CDN and are managed by tag management. To deploy tag management 2.0, you must update the page code on your pages. With these changes, you can deploy multiple Adobe Marketing Cloud products with the same page code and are enabled to quickly deploy new functionality when it is added to the product.

Tag Container Environments

Tag management provides a dev, stage, and live environment for each tag container. Each environment has a separate current version and revision history.

Tag management uses the same page code for each environment. This lets you test multiple code versions on the same site without requiring page-level changes. You can use these environments to align with your existing release process. For example, your development team can use the dev version of the tag container to test changes directly on your live site without impacting the live version.

Selecting the Tag Container Environment

When you load a page that includes the tag loader, an attempt is made to load the current live version of the tag container. To instruct the tag loader to retrieve the version from the stage or dev environment, you can set a cookie in your browser that instructs the JavaScript tag loader to retrieve a different version:

Implementing Analytics Using JavaScript 94

The cookie can be set using the bookmarklets available in the tag management interface. If your browser does not support adding the bookmarklet, you can manually create a bookmark by copying and pasting the URL: javascript:document.cookie='s_tagEnv=dev;%20path=/';void(0)

These bookmarklets can be used to quickly switch between the current versions in each environment.

Setting the Dev Cookie to Test a New Tag Container

When you create a tag container, a version is initially created in the dev environment only. There is no version of this tag container deployed to the stage or production environments:

Implementing Analytics Using JavaScript 95

If you browse to a site that includes the tag loader without setting the dev cookie, an attempt is made to load the live version. Since there isn't a version in live, the tag container is not found and the loader fails gracefully.

If a tag container fails to load make sure the dev cookie is set correctly or that you have promoted a live version of the tag container.

Tag Processing Order

By default, most tag management tags are executed asynchronously. This provides a number of performance benefits, since your page continues to load while tags execute. However, there are some cases where you need to load and execute a tag synchronously, such as with an implementation of Adobe Target. Synchronous loading was added as an option in tag management 2.0 to provide for this use case.

When a page loads, tag management inserts all synchronous tags defined in a tag container at the location of the page code, which should be placed directly after the opening

<body>

tag.

These synchronous tags are executed in order in the main processing thread. Asynchronous tags are executed in separate threads, and multiple asynchronous scripts might be executed in parallel depending on the browser.

For example, in the previous diagram, synchronous tag 1 executes before synchronous tag 2. Asynchronous tags can be executed in any order, depending on how long they take to execute and the processing architecture of the browser. In the previous diagram, asynchronous tag 2 might complete before asynchronous tag 1, but might complete after synchronous tag 2.

Product Tag On Load

Each product tag provides an On Load section in the UI. Code placed in this section is executed after the tag loads.

Implementing Analytics Using JavaScript 96

If you need more control over tag execution, you can also execute code based on tag events. See

amc.on Tag Event

Callbacks

Tag management Quick Start

This section contains an overview of the tasks required to deploy tag management.

Step

Step 1

Task

Create a New Container

Location

Tag management

Description

Define a tag container to provide analytics on your website.

Step 2

Step 3

Step 4

Step 5

Define Tags

Copy Environment Bookmarklets

Include the Page Code on Site

Pages

Test and Promote Revisions

Tag management

Your website

Tag management

Add support for products, Genesis integrations, and affiliate beacons to the tag container.

Save bookmarklets that let you switch between the dev, state, and live environments to test your tag container.

Add tag management page code to each page on your website.

Set up your workflow to test and promote tag container versions.

Create a New Container

The first step is to define a tag container in the Admin interface. A tag container is associated with a digital property.

See

Create a tag container

for detailed instructions.

Implementing Analytics Using JavaScript 97

Define Tags

After you create a new tag container, the Edit Tags page displays. This page is where you add product tags and add any custom code.

Keep the following key concepts in mind as you create and deploy a tag container:

• Tag containers are hosted on a CDN. Each time a new revision is deployed it takes several minutes to propagate to the edge nodes.

• Tag Containers are optimized to use asynchronous loading where possible to improve performance. If variables are not being populated or resources are not being found, make sure the code is inserted in the correct location or if necessary, switch to synchronous loading.

• Each tag container has a dev, stage, and live environment. New tag containers are created with a dev version only. You must set a cookie to load the dev version. See

Tag Container Environments

For details on product deployment, see

Marketing Cloud Deployment

If you are an existing Analytics, Target, or Media Optimizer customer migrating to tag management, see

Migrating to tag management 2.0 from a Legacy Implementation

If you are an existing tag management 1.0 customer migrating to tag management 2.0, see

Migrating to tag management 2.0 from tag management 1.0

Copy Environment Bookmarklets

To test each version of the tag as it moves from dev, stage, and live, copy the bookmarklets from the Environment

Overview page. See

Tag Container Environments

for additional details.

Include the Page Code on Site Pages

Place the page code directly after the

<body>

tag on site pages.

Variables and other properties are set in the UI in the Tag Code or in the On Load section of the tag container. If you include code that is dependent on tag code outside of the tag manager interface, code must be wrapped in

amc.on Tag Event Callbacks

<!-- example, do not copy - each tag container has unique page code -- >

<!-- Adobe Marketing Cloud Tag Loader Code

More info available at http://www.adobe.com/solutions/digital-marketing.html -->

//]]></script>

The custom page code for each Tag Container is available in the interface by clicking Get Page Code.

Test and Promote Revisions

When you are ready, use the links in the Actions column to copy a revision to the next environment. The current version in Live Environment is sent to users when they view a page that includes the tag loader.

Create a tag container

A tag container is associated with a digital property.

Implementing Analytics Using JavaScript

Note: Tag Containers cannot be deleted or renamed after they are created.

1. Start tag management.

2. Click Create New Container.

3. (Optional) Assign group access to the new container. All groups that have tag management Environment

Privileges are displayed in the Container Groups Access list. If a group is selected, the container is added to the list of containers to which the users in that group receive the access defined by Environment Privileges.

For example, if the "TM Devs" group has Development privileges and that group is selected on this screen, members are granted Development access to the new tag container.

Container access can be assigned or modified at any time. See

Tag management Permissions

4. On the Container Environment Overview page, click Create to create an initial version in the Development environment.

Tag Container Environments

5. On the Edit Tags page, define tags to deploy Marketing Cloud products.

Marketing Cloud Deployment

6. Click Save and Deploy, or click Save and deploy the container at a later time from the Container Environment

Overview page.

Check the Status column for confirmation that the container was deployed.

Migrating to tag management 2.0 from tag management 1.0

Tag management provides a migration wizard and tag backward compatibility to help migrate from tag management

1.0.

The migration process is designed to keep your live tag management 1.0 implementation operational throughout the migration. The following table contains details on each of the migration steps:

Step

Step 1

Task

Upgrade the Tag Container

Location

Tag

Manager UI

Description

Start the tag container Migration Wizard.

Implementing Analytics Using JavaScript 99

Step

Step 2

Step 3

Step 4

Step 5

Task

Update Page Code

Create a 2.0 Revision

Deploy and Test

Promote to Live

Location Description

Your website

The tag management 2.0 page code is backward compatible with 1.0 tag containers.

During the migration, your live 1.0 tag container and development 2.0 tag container can use the same 2.0 page code. This lets you migrate your page code first, then test and deploy a 2.0 tag container without disrupting your live implementation.

Tag

Manager UI

Create a 2.0 revision of the tag container and migrate your

tags. See

1.0 to 2.0 Tag Mapping

Your website

Deploy and test the 2.0 tag container in the dev and stage environments to make sure everything works correctly.

Tag

Manager UI

When testing is complete, promote the 2.0 tag container to the live environment.

The

tag management 1.0

guide is available for reference during your migration.

Upgrade the Tag Container

Edit your 1.0 tag container, and under the Upgrade to tag management 2.0 heading, click the Upgrade this

Container button. This starts the Migration Wizard.

Update Page Code

Important: Do not edit the page code in your live environment until you have completed Step 5 and have deployed a 2.0 tag container to live and verified the deployment status.

Replace your existing 1.0 page code with the 2.0 page code in a dev environment. The 2.0 page code should be inserted directly after the opening

<body>

tag. For now, the 2.0 page code continues to reference the 1.0 tag container.

After the new page code is deployed, click the I have deployed the Page Code button.

Implementing Analytics Using JavaScript 100

Create a 2.0 Revision

After the page code is deployed, click Create Revision. This creates a new 2.0 tag container in the dev environment.

Your live 1.0 tag container continues to operate in the live environment.

Because of the new structure of tag management 2.0 containers, you need to recreate your 1.0 tags using 2.0 tags.

See

1.0 to 2.0 Tag Mapping

Deploy and Test

Deploy and test the 2.0 tag container in the dev and stage environments to make sure everything works correctly.

Promote to Live

When testing is complete, promote the 2.0 tag container to the live environment. After you have verified that the tag container is deployed to live, you can update the page code in your live environment.

1.0 to 2.0 Tag Mapping

This section describes how to migrate from each tag management 1.0 tag to a tag management 2.0 tag.

Custom Core Javascript

1.0 Custom Core

Javascript Tag

2.0 Tag

Custom Core

Javascript

JavaScript

Script

Remote

Migration Instructions

Insert a Custom Code Javascript tag and paste the code directly into this tag. This tag should appear before any product tags that depend on functionality defined in this tag.

(optional) Tag management 2.0 adds the ability to load remote scripts before products. Depending on the size of the code in this section, you might consider moving it to an external file and then referencing it using a remote script tag instead. If so, insert a Custom Code

Remote Script tag instead and select the synchronous option.

Product Code

1.0 Product Code

Tag

2.0 Tag

Analytics Adobe Analytics

Migration Instructions

Copy all of the code from the 1.0 Analytics Tag Code section to the

2.0 Analytics Tag Code section.

Implementing Analytics Using JavaScript

Migration Instructions

101

1.0 Product Code

Tag

2.0 Tag Migration Instructions

Analytics > Survey Adobe Analytics > Survey

Copy all of the code from the 1.0 Survey Tag Code section to the

2.0 Survey Tag Code section.

Analytics > Video

Tracking

Adobe Analytics > Video

Copy all of the code from the 1.0 Video Tracking Tag Code section to the 2.0 Video Tag Code section.

Analytics > *

Genesis

Integrations

Adobe Analytics >

Integrate Module

Insert any additional tags under the Analytics product or in the

Genesis Integrations section using the Integrate Module tag.

For each tag, insert a new Integrate Module tag and set the

Description field equal to the integration name set in the

Integrate.add

call: s.Integrate.add("DFA")

Copy all of the code from the 1.0 tag to the 2.0 tag.

Target Adobe Target

Insert a new 2.0 Target tag and provide your client code when prompted.

Locate the mboxOnLoad

function in your 1.0 Target tag. Copy the contents of this function to the matching function in the On Load section of the 2.0 tag.

Note: Do not overwrite the entire On Load section as the 2.0

tag contains some syntax differences.

Demdex AudienceManager

The 2.0 AudienceManager tag delivers the required JavaScript library and plug-ins for Audience Manager.

Copy your implementation code from the 1.0 Demdex Tag Code section to the 2.0 AudienceManager Tag Code section.

Custom Code (after products)

1.0 Custom Code

Tag

2.0 Tag

HTML HTML

Javascript

Image Beacon

Javascript

HTML

Copy all of the code from the 1.0 tag to the 2.0 tag and recreate the

Copy all of the code from the 1.0 tag to the 2.0 tag and recreate the

an HTML tag and recreate the

Copy the image URL from the 1.0 tag, then insert an

<img>

tag into

Implementing Analytics Using JavaScript

1.0 Custom Code

Tag

2.0 Tag

Remote

JavaScript

Remote Script

IFrame IFrame

102

Migration Instructions

Copy all of the code from the 1.0 tag to the 2.0 tag and recreate the

Copy all of the code from the 1.0 tag to the 2.0 tag and recreate the

If you are currently using tag management 1.0, see

Migrating to tag management 2.0 from a Legacy Implementation

The following process describes the steps required to migrate from a legacy implementation to tag management.

Migrating to tag management 2.0 from tag management 1.0

Step

Step 1

Step 2

Step 3

Step 4

Step 5

Task

Tag management Quick

Start

Migrate Legacy

Implementation Code

Ensure Tag Availability

Promote a Live Version

Update Live Page Code

Location Description

Tag management

Create a new tag container and deploy it in a development environment. Add the tag management page code to some pages in a development environment, but do not make any changes to your live site.

Tag management

Migrate your legacy implementation code to tags. See

Legacy Implementation to Tag Mapping

Tag management

Update your implementation to leverage asynchronous tag loading.

Tag management

Deploy and test the tag container to make sure everything works correctly. When testing is complete, promote a tag container to the live environment.

Your website

Replace the current page code on your live site with the updated tag management 2.0 page code.

Migrate Legacy Implementation Code

Migrate your legacy implementation code to tags. See

Legacy Implementation to Tag Mapping

Ensure Tag Availability

If you have a legacy implementation with all variables set in the page code section, tag management migration is straightforward.

The biggest barrier existing customers face when migrating to tag management 2.0 are references to the s

object within the page itself and within external JavaScript files. Since tag management leverages asynchronous loading for enhanced performance, you might need to modify how you interact with the s

object since you can't guarantee it is available as the page loads. This also prevents JavaScript errors in the rare case that the CDN is unavailable.

If you need to interact with the s

object within the page, for example when a link is clicked or other content is loaded, use one of the following options:

Attach an Event Handler in tag management

Implementing Analytics Using JavaScript 103

Instead of placing AppMeasurement for JavaScript code directly in the page, you can place

amc.on Tag Event

Callbacks

directly in the tag management UI. For example, to track the following custom exit link:

The following code is added in the On Load section of the Site Catalyst component : amc.on('domcontentloaded', function () {

var link = document.getElementById('linkExit1');

link.onclick = function() {

s.tl(this,'e','AnotherSite',null,'navigate'); return false;

}

});

When the DOM is loaded and this callback is executed, this code retrieves the link using the ID and attaches the s.tl

call to the link click event.

If you need advanced functionality, you could use a jQuery or similar loop to add similar tracking code to all links on the page.

Wrap the Code Directly in an amc.on Callback

If you have only a few locations where you need to interact with the s

object, you can wrap calls directly in a callback:

<a href="http://anothersite.com" onclick="var scope=this; amc.on('tagload.analytics',function()

{s.tl(scope,'e','AnotherSite',null,'navigate'); }); return false;">

The

<a>

object is stored in a variable named scope, which is passed to the s.tl

function. When the Analytics tag is loaded, the event handler is attached.

Aside from the code management difficulties, the biggest drawback is that this link won't function in the rare case that the tag container can't be loaded from the CDN. For situations where tag unavailabilty prevents interaction with the page, we recommend adding the event handler in tag management.

Promote a Live Version

Deploy and test the tag container to make sure everything works correctly. When testing is complete, promote a tag container to the live environment.

Update Live Page Code

Replace current page code on your live site with the updated tag management 2.0 page code.

Legacy Implementation to Tag Mapping

This section describes how to migrate code from a legacy implementation to a tag management 2.0 tag.

Implementing Analytics Using JavaScript 104

Description

External

JavaScript

Libraries

Target

Current Code Tag Action

type="text/javascript"></script>

Remote Script External JavaScript libraries are placed in a remote Script tag. If other tags depend on this library, select synchronous and place it before any dependent tags.

var mboxServerHost='omniture.tt.omtrdc.net;'

(function mboxOnLoad() {

//place code here that will

//run after Target is loaded

Target Add a Target tag, provide your client code, and then add code to execute after Target is loaded.

})();

Analytics Code var s_account="rs" var s=s_gi(s_account) s.debugTracking=false s.charSet = "UTF-8"

...

s.linkTrackEvents="None"

Plugins

Survey

Media Module

Genesis

Integrations s.usePlugins=true function s_doPlugins(s) {

/* Add usage of plugins here */

} s.doPlugins=s_doPlugins s.loadModule("Survey") s.loadModule("Media") s.Integrate.add("DFA");

Adobe

Analytics > reporting and analytics

Insert an Analytics tag, and replace the generated code in the tag with the code from your current page code and s_code.js

The Analytics tag in the tag management UI matches the structure of your existing

Analytics page code, and your configuration can be copied straight to the Tag Code section of the Analytics tag.

Adobe

Analytics > reporting and analytics

Overwrite the default plugins code that is generated in the

Analytics Product Code section with your current plugins code.

Adobe

Analytics > reporting and analytics >

Survey

Insert a Survey tag, and then overwrite the default code with your current Survey module code.

Adobe

Analytics > reporting and analytics >

Video

Insert a Video tag, and then overwrite the default code with your current Media module code.

Adobe

Analytics > reporting and analytics >

Integrate

Module

For each integration, insert a

Integrate Module tag and set the Description field equal to the integration name set in the

Integrate.add

call:

Implementing Analytics Using JavaScript

Description Current Code Tag

105

Action

s.Integrate.add("DFA")

Copy your current integration code to the Tag Code section.

Marketing Cloud Deployment

Marketing Cloud products are added by selecting the product in the Add Product or Code drop-down list when editing a tag container.

Analytics

Analytics implementations though tag management support all of the variables and functions available with a legacy implementation.

For detailed information on implementing Analytics, see the

Analytics Implementation Guide

Setting

Accounts

Secure Server

Character Set

Currency Code

Instance Variable

Description

Select one or more report suites to receive the data that is sent by this tag.

(Optional) If you have a secure server URL, provide it here. Leave it blank to default to the non-secure server URL.

Select the character set used by your report suite.

Select the currency code used by your report suite.

If your instance variable name has changed from the default, provide the new variable name.

When a new version of AppMeasurement for JavaScript is release, you are prompted to upgrade the next time you edit.

JavaScript Video Measurement

Video measurement code is placed in the code block in the Video Tracking section.

Implementation details on measuring video are included in the

Measuring Video in Analytics

guide.

Survey

Integration with Survey is provided through the Survey module. After you add the module, you can define any additional settings required by your implementation.

See

Standard Survey Implementations on the Web

s.loadModule("Survey") var s_sv_dynamic_root = "delivery.d1.sv.omtrdc.net/survey/dynamic" var s_sv_gather_root = "collection.d1.sv.omtrdc.net/survey/gather"

Target

Provide your client id when prompted. The necessary dependencies, such as mbox.js

are delivered automatically.

You can use the On Load field to deliver a global mbox at the top of the page. You can also leverage amc.on

to control the execution of on-page mbox create function calls.

AudienceManager

The Audience Manager tag delivers the required JavaScript library and plug-ins for Audience Manager.

After adding this tag, place your implementation code in the On Load section of the tag.

Implementing Analytics Using JavaScript 106

Custom Tag Deployment

Third-party and custom tags are deployed using custom code sections.

Custom code tags can be

conditionally executed

HTML

HTML custom code tags are typically used to deploy third-party tags that use

<img>

, or

elements.

All HTML elements defined in an HTML custom code tag, with the exception of

Document.write()

Since you can't specify a location to append tags, custom code tags should not be used to change page content.

JavaScript

JavaScript custom code tags contain a snippet of JavaScript code.

Code in a JavaScript tag is executed synchronously. Functions and other code in these sections cannot be used in the

<head>

element on the page since that loads before the page code.

Remote Script

Remote scripts are loaded by providing the full URL to the script.

Remote Scripts can be loaded synchronously or asynchronously. If you are loading frameworks, such as jQuery, that you want to use throughout the page, we recommending loading these scripts synchronously. This ensures that any functions defined are available to other elements on the page.

Functions and other code defined in script tags cannot be used in the

<head>

element on the page since that loads before the page code.

IFrame

IFrame custom code tags are created by providing the full URL to the page to load in the IFrame.

The IFrame element is generated automatically and inserted at the location where the tag loads. Since you can't specify a location to append tags, custom code tags should not be used to change page content.

Conditional Execution using Firing Rules

Tags defined in custom code tags can be fired conditionally based on matching criteria.

All conditions that you define for a custom code tag must be met for the code to execute. For example, if you provide a Host Match and Path Match, both conditions must match.

The following match parameters are available:

• Host

• Path

• Cookie

• Query Parameter

• Date

The following match conditions are available:

• Contains

• Matches RegEx

• Does not contain

• Does not match RegEx

RegEx conditions use standard JavaScript

RegEx patterns

Implementing Analytics Using JavaScript 107

Match strings in contains and does not contain conditions are case-sensitive.

Tag management Permissions

All administrators have access to tag management.

Using groups, you can define the following permissions for other users:

• Access to all tag containers in a specific environment (dev, stage, or live).

• Access to a specific tag container in all environments.

Assign Permissions

Admin > User Management > Groups> Click a group.

Tag management permissions can be assigned to any custom group or any individual members of a custom group.

amc.on Tag Event Callbacks

To avoid errors due to asynchronous tag loading and rare cases of CDN unavailability, you should use the tag event callbacks provided by amc.on

to wrap any code that depends on tags delivered by tag management.

Avoiding Availability Errors

An amc

object is defined in the tag management page code: var amc=amc||{};if(!amc.on){amc.on=amc.call=function(){}};

Since this object is defined on the page, any code that is contained in amc.on

event callbacks fails silently if the tag container does not load for any reason.

Callback Events

Instead of relying on browser execution order, tag management provides an interface that lets you execute code based on tag events. This lets you deliver tags asynchronously to optimize performance, and still execute additional code after a tag loads or when other events occur.

Callbacks can be associated with the following events using amc.on

Event name

tagload tagappend

Description

Triggered when a tag has been loaded and is ready to use.

Triggered when a tag is appended in the page by tag management.

Implementing Analytics Using JavaScript 108

Event name

tagignore

Description

Triggered when by some unknown reason one tag could not be append in the page.

pageload Triggered when the onload event is triggered by the browser.

domcontentloaded Triggered when the DOMContentLoaded event from the browser is triggered.

load Triggered when all the tags have been loaded.

tagload.tagid

tagappend.tagid

tagignore.tagid

For the events starting with tag ( tagload

, tagappend

, tagignore

) hierarchical event names are supported. This means that the id

of the tag can be added after the event name.

Don't confuse these events with the

DomContentLoaded

or the onload

events from browser. These events can be triggered before or after the events triggered by the browser.

Callback methods have the following syntax: amc.on('eventname', function (event, data) {

});

Each callback method receives the following arguments:

• event - the event name for which this callback will be processed.

• data - an object having the following structure:

{

id: 'tagid',

tag: TagInstance

}

Note: Any code using the amc.on

method should be added in the page after the page code. Code that depends on tags that are delivered by tag management should not be placed in the

<head>

element.

Examples

The following examples are based on a tag container that has 2 components:

• Analytics - with the id 'analytics'

• Target - with the id 'testandtarget'

Load

amc.on('load', function (event, data) {

// Here we can add code that will be triggered once all the tags have been loaded by tag management.

// For set eVars, props, events, and then call s.t(). You can also do this directly

// in tagmanager UI if you don't need page elements

});

Tag Load

amc.on('tagload', function (event, data) {

//called twice. Once for Analytics, and once for Target

});

You can find out the component for which the event was triggered by looking at the data object. This callback is for advanced users who need complex functionality. For example, you might have 10 tags to add in the page, but want to define an action when only 3 of them are loaded, independent of the other 7.

Implementing Analytics Using JavaScript 109

Specific Tag Loaded

amc.on('tagload.analytics', function (matchedmessage, data) {

});

This callback is triggered when the tag with the ID of analytics

has been loaded by the browser. This is the same as placing the code in the On Load section of the Analytics tag in the tag management UI (assuming your Analytics tag has an id of ' analytics

').

For example, if you need to place code that is dependent on Analytics in the Target tag, you can add code similar to the following in the On Load section of the Target tag: var mboxServerHost='omniture.tt.omtrdc.net;'

(function mboxOnLoad() {

//place code here that will run after Target is loaded

})(); amc.on('tagload.analytics', function () {

//place code here that will run after Analytics and Target are loaded

});

Nested DOM Content Loaded within the Analytics Tag

If you need to call s.t

on the page instead of within the On Load section in the Analytics tag, the call should be contained within two callbacks. The first when the Analytics tag is loaded, and the second when the DOM is loaded: amc.on('tagload.analytics', function (matchedmessage, data) {

amc.on('domcontentloaded', function () {

if (s) {

s.pageName = document.getElementById('pagetitle').innerHTML;

s.t();

}

});

This method is used if you need to interact with the DOM before making the tracking call.

Troubleshooting

This section contains instructions to help troubleshoot tag container deployment.

Confirm that the container is deployed

The Status column on the Container Environment Overview displays which revision is deployed in each environment.

Confirm that a tag revision is deployed in the environment you are testing.

Implementing Analytics Using JavaScript 110

Verify the environment cookie

If you are testing a development or stage version, verify that the s_tagEnv

cookie is set with a value of dev

, stage

, or live

If not, use the

environment bookmarklets

to set the environment cookie, or define the cookie using a debugger:

• name: s_tag_Env

• host: your hostname

• path:

• expiration: session

• value: dev

, stage

, or live

Verify the page code and amc.js

Use a debugger to verify that the tag management 2.0 page code is on the page directly after the opening

<body> element.

Implementing Analytics Using JavaScript 111

If the page code is present but the tag container is not loading on some of your pages, verify that the bucket_id

in your page code matches the bucket_id

in amc.js

Implementing Analytics Using JavaScript 112

To get the bucket_id

of a tag container, click Get Page code and find the bucket_id

. Confirm that the bucket ID of this page code matches the page code you deployed.

Variables for Analytics Implementation and Reporting

Analytics provides a number of variables to collect Analytics data. For example, the value in the pageName variable is the name of the Web page being reported. This section lists the variables that are supported by AppMeasurment.

For a listing of how each variable appears in Analytics reports, see

Variables - How They Are Used in Reporting

How to Set Variables

AppMeasurement requires that all configuration variables be set before the initial call to the track function, t(). If configuration variables are set after the call to t(), unexpected results may occur.

Configuration variables are set inside the doPlugins function, which is called during the execution of the track function.

The specific configuration variable causing this issue is trackInlineStats, which enables ClickMap data collection.

This leaves the ClickMap module in an indeterminate state, which results in the first tracking call appending the string "undefined" to the Adobe Analytics beacon, affecting the currency code.

To resolve this issue, move all configuration variables above the doPlugins function.

/************************** CONFIG SECTION **************************/

/* Ensure these variables are correct before deploying */ var s_account="[INSERT-REPORT-SUITE-ID-HERE]" var s=s_gi(s_account) s.trackingServer="[INSERT-TRACKING-SERVER-HERE]" s.visitorNamespace="[INSERT-VISITOR-NAMESPACE-HERE]" s.charSet="ISO-8859-1" s.currencyCode="USD" s.trackDownloadLinks=true s.trackExternalLinks=true

Implementing Analytics Using JavaScript 113 s.trackInlineStats=true s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,wmv,doc,pdf,xls" s.linkInternalFilters="javascript:,three,two,one,dev16,.,nike" s.linkLeaveQueryString=false s.linkTrackVars="None" s.linkTrackEvents="None" s.debugTracking=true s.usePlugins=true; function s_doPlugins(s) {

//add your custom plugin code here

} s.doPlugins=s_doPlugins;

============== DO NOT ALTER ANYTHING BELOW THIS LINE ! ===============

AppMeasurement for JavaScript version: 1.5.3

More info available at http://www.omniture.com

*/ function AppMeasurement(){var a=this;a.version="1.5.3";var k=window;k.s_c_in||(k.s_c_il=[],k.s_c_in=0);a._il=k.s_c_il;a._in=k.s_c_in;a._il[a._in]=a;k.s_c_in++;a._c="s_c";var

q=k.AppMeasurement.zb;q||(q=null);var r k , t { r = p e , r o t n & .

c i & & " .

c i !

" & .

c i & " .

c i !

" .

c i & .

c i .

s = h t r , r a n c c u } o f c o a t { n l l ( } t ( { ; z f c o a r r " p s n a = + a r l e u t n , ) r u !

0>a.indexOf(b)?a:a.split(b).join(d)};a.escape=function(c){var b,d;if(!c)return c;c=encodeURIComponent(c);for(b=0;7>b;b++)d="+~!*()'".substring(b,b+1),0<=c.indexOf(d)&&(c=a.replace(c,d,"%"+d.charCodeAt(0).toString(16).toUpperCase()));return

c};a.unescape=function(c){if(!c)return c;c=0<=c.indexOf("+")?a.replace(c,"+"," "):c;try{return

decodeURIComponent(c)}catch(b){}return unescape(c)};a.gb=function(){var c=k.location.hostname,b=a.fpCookieDomainPeriods,d;b||(b=a.cookieDomainPeriods);if(c&&!a.cookieDomain&&

Configuration Variables

Configuration variables set in the AppMeasurement.js.

Configuration variables control the way data is captured and processed in reporting. The most-common configuration variables that are typically set in the main global JavaScript (

AppMeasurement.js

). These variables can be set within the Reports & Analytics page-level code and links when appropriate.

Not all of these variables appear in the code by default when you generate code through the Admin Tool > Code

Manager. Some of these configuration variables may not be applicable to your site's implementation needs.

Some of the goals of using these configuration variables are:

• Track multiple sites/domains.

• Use any currency on purchases.

• Capture data indifferent languages.

• Link tracking (number of downloaded files, links to external sites.

• Track custom links for unique purposes.

Note: AppMeasurement requires that all configuration variables are set before the initial call to the track function, t(). If configuration variables are set after the call to t(), unexpected results may occur. To ensure proper data collection, all configuration variables must be above the doPlugins function.

s.account

The s.account variable determines the report suite where data is stored and reported.

If sending to multiple report suites (multi-suite tagging), s.account may be a comma-separated list of values. The report suite ID is determined by Adobe.

Implementing Analytics Using JavaScript 114

Parameters

Max Size

40 Bytes

Debugger Parameter

In the URL path

Reports Populated

N/A

Default Value

N/A

Each report suite ID must match the value created in the Admin Console. Each report suite ID must be 40 bytes or less, but the aggregate of all report suites (the entire comma-separated list) has no limit.

The report suite is the most fundamental level of segmentation in reporting. You can set as many report suites as your contract allows. Each report suite refers to a dedicated set of tables that are populated in Adobe's collection servers. A report suite is identified by the s_account variable in your JavaScript code.

Within Analytics, the site drop-down box in the upper left of the reports displays the current report suite. Each report suite has a unique identifier called a report suite ID. The s_account variable contains one or more report suite IDs to which data is sent. The report suite ID value, which is invisible to Analytics users, must be provided or approved by Adobe before you use it. Every report suite ID has an associated "friendly name" that can be changed in the report suites section of the Admin Console.

The s_account variable is normally declared inside the JavaScript file (s_code.js). You can declare the s_account variable on the HTML page, which is a common practice when the value of s_account may change from page to page. Because the s_account variable has a global scope, it should be declared immediately before including Adobe's

JavaScript file. If s_account does not have a value when the JavaScript file is loaded, no data is sent to Analytics.

Adobe's DigitalPulse Debugger displays the value of s_account in the path of the URL that appears just below the word "Image," just after /b/ss/. In some cases, the value of s_account also appears in the domain, before 112.2o7.net.

The value in the path is the only value that determines the destination report suite. The bold text below shows the

report suites that data is sent to, as it appears in the debugger. See

http://mycompany.112.207.net/b/ss/mycompanycom,mycompanysection/1/H.1-pdv-2/s21553246810948?[AQB]

Syntax and Possible Values

The report suite ID is an alphanumeric string of ASCII characters, no more than 40 bytes in length. The only non-alphanumeric character allowed is a hyphen. Spaces, periods, commas and other punctuation are not allowed.

The s_account variable may contain multiple report suites, all of which receive data from that page.

var s_account="reportsuitecom[,reportsuite2[,reportsuite3]]"

All values of s_account must be provided or approved by Adobe.

Examples

var s_account="mycompanycom" var s_account="mycompanycom,mycompanysection"

Configuring the Variable in Analytics

The friendly name associated with each report suite ID can be changed by Adobe Customer Care. The friendly name can be seen in Analytics in the site drop-down box in the top, left section of the screen.

Pitfalls, Questions, and Tips

• If s_account is empty, not declared, or contains an unexpected value, no data is collected.

Implementing Analytics Using JavaScript 115

• When the s_account variable is a comma-separated list (multi-suite tagging), do not put spaces between report suite IDs.

• If s.dynamicAccountSelection is set to 'True,' the URL is used to determine the destination report suite. Use the

DigitalPulse Debugger to determine the destination report suite(s).

• In some cases, VISTA can be used to alter the destination report suite. UsingVISTA to re-route or copy the data to another report suite is recommended when using first-party cookies, or if your site has more than 20 active report suites.

• Always declare s_account inside the JS file or just before it is included.

s.dynamicAccountSelection

The dynamicAccountSelection variable lets you dynamically select the report suite based on the URL of each page.

Note: dynamicAccountSelection does not work with custom link tracking.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

False

Note: Both dynamicAccountList and dynamicAccountMatch are ignored if the dynamicAccountSelection variable is not declared or set to 'false.'

Syntax and Possible Values

s.dynamicAccountSelection=[true|false]

Only 'true' and 'false' are allowed as values of dynamicAccountSelection.

Examples

s.dynamicAccountSelection=true s.dynamicAccountSelection=false

Configuration Settings

None

Pitfalls, Questions, and Tips

• Dynamic account selection is not supported by

• Always use the DigitalPulse Debugger to determine which report suite is receiving data from each page.

s.dynamicAccountList

AppMeasurement for JavaScript can dynamically select a report suite to which it sends data. The dynamicAccountList variable contains the rules used to determine the destination report suite.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

This variable is used in conjunction with the dynamicAccountSelection and dynamicAccountMatch variables. The rules in dynamicAccountList are applied if dynamicAccountSelection is set to 'true,' and they apply to the section of the URL specified in dynamicAccountMatch.

Implementing Analytics Using JavaScript 116

If none of the rules in dynamicAccountList matches the URL of the page, the report suite identified in s_account is used. The rules listed in this variable are applied in a left-to-right order. If the page URL matches more than one rule, the left-most rule is used to determine the report suite. As a result, your more generic rules should be moved to the right of the list.

In the following examples, the page URL is http://www.mycompany.com/path1/?prod_id=12345

dynamicAccountSelection is set to 'true,' and s_account is set to "mysuitecom."

DynamicAccountList Value DynamicAccountMatch Value

mysuite2=www2.mycompany.com;mysuite1=mycompany.com" window.location.host

Report Suite to Receive Data

mysuite1

"mysuite1=path4,path1;mysuite2=path2" window.location.pathname

"mysuite1=path5"

"myprodsuite=prod_id" window.location.pathname

window.location.search?window.location.search:"?") mysuite1, mysuite2 mysuitecom, mysuite1 myprodsuite

Syntax and Possible Values

The dynamicAccountList variable is a semicolon-separated list of name=value pairs (rules). Each piece of the list should contain the following items:

• one or more report suite ID (separated by commas)

• an equals sign

• one or more URL filters (comma-separated) s.dynamicAccountList=rs1[,rs2]=domain1.com[,domain2.com/path][;...]

Only standard ASCII characters should be used in the string (no spaces).

Examples

s.dynamicAccountList="mysuite2=www2.mycompany.com;mysuite1=mycompany.com" s.dynamicAccountList="ms1,ms2=site1.com;ms1,ms3=site3.com"

Configuration Settings

None

Pitfalls, Questions, and Tips

• Dynamic account selection is not supported by

• If the page URL matches multiple rules, the furthest rule on the left is used.

• If no rules match, the default report suite is used.

• If your page is saved to someone's hard drive or translated via a web-based translation engine (such as Google's translated pages), the dynamic account selection probably won't work. For more precise tracking, populate the

s_account variable server-side.

• The dynamicAccountSelection rules apply only to the section of the URL specified in dynamicAccountMatch.

• When using dynamic account selection, be sure to update dynamicAccountList every time you obtain a new domain.

• Use the DigitalPulse Debugger when trying to identify the destination report suite. The dynamicAccountSelection variable always overrides the value of s_account.

s.dynamicAccountMatch

The dynamicAccountMatch variable uses the DOM object to retrieve the section of the URL to which all rules in

dynamicAccountList are applied.

Implementing Analytics Using JavaScript 117

This variable is only valid when dynamicAccountSelection is set to 'True.' Since the default value is window.location.host

, this variable is not required for Dynamic Account Selection to work. For additional information, see

dynamicAccountList

The rules found in dynamicAccountList are applied to the value of dynamicAccountMatch. If dynamicAccountMatch only contains window.location.host

(default), the rules in dynamicAccountList apply only to the domain of the page.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

window.location.host

Syntax and Possible Values

The dynamicAccountMatch variable is usually populated by the Adobe consultant who provides the AppMeasurement for JavaScript file. However, the values listed below may be applied at any time.

s.dynamicAccountMatch=[DOM object]

Description

Domain (default)

Path

Query String

Domain and Path

Path and Query String

Full URL

Value

window.location.host

window.location.pathname

(window.location.search?window.location.search:"?") window.location.host+window.location.pathname

window.location.pathname+(window.location.search?window.location.search:"?") window.location.href

Examples

s.dynamicAccountMatch=window.location.pathname

s.dynamicAccountMatch=window.location.host+window.location.pathname

Configuration Settings

None

Pitfalls, Questions, and Tips

• Dynamic account selection is not supported by

string. For more information on products, see

• When pages are saved to a hard drive, window.location.host

is empty, causing those page views to be sent to the default report suite (in s_account).

• When a page is translated via a web-based translation engine, such as Google, the Dynamic Account Selection does not work as designed. For more precise tracking, populate the s_account variable server-side.

s.dynamicVariablePrefix

The dynamicVariablePrefix variable allows deployment to flag variables, which should be populated dynamically.

Cookies, request headers, and image query string parameters are available to be populated dynamically.

Max Size

N/A

Debugger Parameter

Reports Populated

Any

Default Value

Implementing Analytics Using JavaScript 118

Syntax and Possible Values

s.prop1="D=User-Agent”

OR USE CUSTOM FLAG FOR DYNAMIC VARIABLES s.dynamicVariablePrefix=".."

Examples

s.prop1="D=User-Agent”

OR USE CUSTOM FLAG FOR DYNAMIC VARIABLES s.dynamicVariablePrefix=".." s.prop1="..User-Agent"

Pitfalls, Questions, and Tips

• Dynamic variables can be used to significantly reduce the total length of the URL by copying values into other variables.

• Dynamic variables can be used to collect data from headers and cookies not otherwise available for data collection.

s.charSet

The charSet variable translates the character set of the Web page into UTF-8.

If the charSet variable contains an incorrect value, the data in all other variables are translated incorrectly. If JavaScript variables on your pages (e.g. pageName, prop1, or channel) contain only ASCII characters, charSet does not need to be defined. However, if the variables on your pages contain non-ASCII characters, the charSet variable must be populated.

Parameters

Max Size Debugger Parameter Reports Populated Default Value

N/A CE N/A

The charSet variable is used to identify the character set of the page. For more information on character sets, see the

Multi-byte Character Sets

white paper before using the charSet variable.

Syntax and Possible Values

The charSet variable may only contain one of a predefined set of values, as listed in

Multi-byte Character Sets

s.charSet="character_set"

Examples

s.charSet="ISO-8859-1" s.charSet="SJIS"

Pitfalls, Questions, and Tips

• The value of charSet must match the possible values listed in

Multi-byte Character Sets

• The value of charSet should reflect the character set of the page.

s.currencyCode

The currencyCode variable determines the conversion rate to be applied to revenue.

Implementing Analytics Using JavaScript 119

All monetary amounts are stored in a currency of your choice. If that currency is the same as that specified in

currencyCode, or currencyCode is empty, no conversion is applied.

Max Size

N/A

Debugger Parameter

Reports Populated

All Conversion reports showing Revenue or monetary values

Default Value

Conversion > Purchases >

Revenue

"USD"

If your site allows visitors to purchase in multiple currencies, you should use the currencyCode variable to make sure revenue is stored in the appropriate currency. For example, if the base currency for your report suite is USD, and you sell an item for 40 Euros, you should populate the currencyCode with "EUR" on the HTML page. As soon as data collection receives the data, it uses the current conversion rate to convert the 40 Euros to its USD equivalent.

Populating the currencyCode variable on the HTML page instead of in the JavaScript file is recommend if you sell in multiple currencies. If you want to use your own conversion rates rather than the conversion rates used by Adobe, set the currencyCode to equal the base currency of your report suite. You then convert all revenue before sending it into Analytics.

Currency conversion applies to both revenue and any currency events. These are events that are used to sum values similar to revenue, such as tax and shipping. The revenue and currency events are specified in the products

events

. For more details on how currencies are managed, see

Multi-Currency Support

Syntax and Possible Values

s.currencyCode="currency_code"

Only the currency codes listed in

Multi-Currency Support

are allowed.

Examples

s.currencyCode="GBP" s.currencyCode="EUR"

Configuration Settings

Adobe Customer Care can change the default currency setting for your report suite. When you change the base currency for a report suite, the existing revenue in the system is not converted. All new revenue values will be converted accordingly.

Pitfalls, Questions, and Tips

• If you notice surprisingly large amounts of revenue in reports, ensure that the currencyCode variable and base currency of the report suite are set correctly.

• The currencyCode variable is not persistent, meaning that the variable must be passed in the same image request as any revenue or other currency-related metrics.

• Currency events should not be used for non-currency purposes. If you need to count arbitrary or dynamic values that are not currency, use the numeric event type.

• When the currencyCode variable is empty, no conversion is applied.

Implementing Analytics Using JavaScript 120

s.cookieDomain

The cookieDomain variable determines the domain on which the Analytics cookies s_cc

and s_sq

are set.

Commonly, s.cookieDomainPeriods

is used to generate s.cookieDomain

from window.location.hostnam

Instead of using s.cookieDomainPeriods

, you can explicitly set s.cookieDomain

to what you want to use in your implementation. For example, you could set cookies at the fully qualified page-name using: s.cookieDomain = window.location.hostname;

s.cookieDomainPeriods

The cookieDomainPeriods variable determines the domain on which the Analytics cookies s_cc

and s_sq

are set by determining the number of periods in the domain of the page URL. This variable is also used by some plug-ins in determining the correct domain to set the plug-in's cookie.

The default value for cookieDomainPeriods is "2". This is the value that is used if cookieDomainPeriods is omitted.

For example, using the domain www.mysite.com, cookieDomainPeriods should be "2". For www.mysite.co.jp,

cookieDomainPeriods should be "3".

If cookieDomainPeriods is set to "2" but the domain contains three periods, the JavaScript file attempts to set cookies on the domain suffix.

For example, if setting cookieDomainPeriods to "2" on the domain www.mysite.co.jp

, the s_cc

and s_sq

cookies are created on the domain co.jp

. Because co.jp

is an invalid domain, almost all browsers reject these cookies.

As a consequence, visitor click map data is lost, and the Visitor Profile > Technology > Cookies report indicates that almost 100% of visitors reject cookies.

If cookieDomainPeriods is set to "3" but the domain contains only two periods, the JavaScript file sets the cookies on the subdomain of the site. For example, if setting cookieDomainPeriods to "3" on the domain www2.mysite.com

, the s_cc

and s_sq

cookies are created on the domain www2.mysite.com

. When a visitor goes to another subdomain of your site (such as www4.mysite.com

), all cookies set with www2.mysite.com

cannot be read.

Note: Do not include additional subdomains as part of cookieDomainPeriods. For example, store.toys.mysite.com

would still have cookieDomainPeriods set to "2". This variable definition correctly sets the cookies on the root domain, mysite.com

. Setting cookieDomainPeriods to "3" in this example would set cookies on the domain toys.mysite.com

, which has the same implications as the prior example.

Context Data Variables

Context data variables let you define custom variables on each page that can be read by processing rules.

Instead of explicitly assigning values to props and eVars in your code, you can send data in context data variables that are mapped using processing rules. Processing rules provide a powerful graphical interface to make changes to data as it is received. Based on the values sent in context data, you can set events, copy values to eVars and props, and execute additional conditional statements.

Note: Context data variables are not case sensitive. For example, the following 2 variables are effectively identical: s.contextData['article_title'] = 'Weekend Concert Controversy'; and s.contextData['ARTICLE_TITLE'] = 'Weekend Concert Controversy';

Using context data helps prevent you from making code updates to support different report suite configurations.

For example, you can define the following s.contextData variable: s.contextData['myco.rsid'] = 'value'

Using processing rules you can add a condition that checks for a myco.rsid

context data variable. When this variable is found, you can add an action to copy it to a prop or eVar.

Context data variables can also be defined directly in the processing rules interface to temporarily store a value, or to collect values from a context data variable you know will be used on the report suite. For example, if you need to swap two values, you could create a context data variable to store a value during the swap.

Since processing rules are applied only when data is collected, it is important to set up processing rules before you start sending context data. Context data values that are not read by processing rules when a hit is processed are discarded.

Rules

Rule Description

Supported names and characters Context data variable names can contain only alphanumeric characters, underscores and dots. Any additional characters are stripped out. Context cata variables do not have a numeric designation. Rather, they are named.

Implementing Analytics Using JavaScript 133

Rule Description

For example, the context data variable login_page-home

automatically becomes login_pagehome

. All data sent to the login_page-home

variable is allocated under login_pagehome

Namespace

URL Limits for Internet Explorer

A good practice is to prefix your variables with your company name, site name, or a similar value to make sure the name is unique across your report suite.

Context data variables can be named similar to other JavaScript variables.

Be aware that the namespace a.*

is reserved for use by Adobe products in context variable names. For example, the AppMeasurement Library for iOS uses a.InstallEvent

to measure application installations.

You might encounter a older URL limitation for Internet Explorer 6 and 7, where URLs are truncated at 2000 bytes. You can use the DigitalPulse debugger to determine the size of a URL string.

With the recent updates to AppMeasurement (September 2014),HTTP POST is used with Internet Explorer 8+, which eliminates truncation issues.

Supported AppMeasurement version Context data variables require at least H23 code or higher.

Sending Context Data on a Track Link Call

Include

ContextData

+ the name of the variable that you would like included in s.linkTrackVars

: s.contextData['myco.value'] = "some value"; s.linkTrackVars = "contextData.myco.value"; s.tl(true,"o","Link Name");

Examples

Possible ways to replace implementation of the s.pageName variable, assuming that processing rules are set up correctly for each: s.contextData['page'] = "Home Page" s.contextData['pagename'] = document.title // Takes the web page's title and passes it into the pageName context data variable s.contextData['pagevar'] = s.pageName // This example would be considered redundant, as both the pageName and contextData variable are available in Processing rules

Other examples to implement context data variables: s.contextData['owner'] = "Jesse" s.contextData['campaign'] = "Campaign A" s.contextData['author'] = "Sheridan Andrius"

For an example, see

Copy a Context Data Variable to an eVar

in Analytics Reference.

Dynamic Variables

Dynamic variables let you copy values from one variable to another without typing the full values multiple times in the image requests on your site.

Implementing Analytics Using JavaScript 134

Dynamic variables are used when capturing the same data (for example, campaign tracking codes) in multiple variables concurrently. This is a common practice in cases where different reports offer unique and important metrics.

For example, capturing internal search keywords in a Custom Conversion variable and in a Custom Traffic variable lets you view the Revenue and the Weekly Unique Visitors metrics associated with these keywords, respectively.

Dynamic variables are also useful for viewing data under various reporting conditions. A campaign tracking code can be captured in multiple eVars with various allocation and cookie expiration settings. This lets users choose the way they want to attribute conversion metrics to these campaigns.

Note: Dynamic variables are not supported in conjunction with cookies (s_cc, s_sq, s_fid, s_vi and any cookie that is set by a plugin). You can not use D=<cookie value>.

A significant benefit of dynamic variables is the ability to capture long strings of data in multiple variables without actually passing the long string repeatedly. Some browsers limit the maximum length of HTTP GET requests (including the Adobe image request). Using dynamic variables ensures that all data is captured by reducing the length of the request to Adobe servers in cases where data is duplicated across several variables.

In the Adobe image request that occurs on the page view, if you are using dynamic variables to copy the value of

Custom Traffic 1 to Custom Conversion 1, you would see v1=D=c1

. If eVar1 received a value previously in the request, Adobe's servers dynamically copy the value of Custom Traffic 1 to Custom Conversion 1 during data processing. As a result, the value originally passed using Custom Traffic 1 also appears in the Custom Conversion

1 reports.

Dynamic variables are passed by setting a variable to the desired value and then setting other variables to

D=[variable abbreviation]

. For abbreviations for each variable, see

Data Collection Query Parameters

. Dynamic variables can pull data from the following locations:

• Other query-string variables

• HTTP headers (except for the Cookie HTTP header)

To create a dynamic variable, add a special prefix to the start of the value. The default prefix is "D=". There are two methods of flagging dynamic variables:

• Use a default prefix of D= (For example: s.prop1="D=User-Agent" )

• For non-JavaScript implementations, you can define a custom prefix using the "D" query-string parameter. For example, if the query-string parameter is

"&D=$"

, you can create a dynamic variable with the following command: s.prop1="$User-Agent"

The variable abbreviation used must match the variable parameter name passed in the image request. Some variables have multiple accepted parameters used in different cases. For example, pageName=

and gn=

both pass the page name, but the latter is most often used in mobile and hard-coded implementations. If the image request uses pageName=

to pass the page name, then

D=pageName

is acceptable but

D=gn

is not. If the image request uses gn=

, then

D=gn

is acceptable, but

D=pageName

is not.

The following information applies to dynamic variables:

• Dynamic variables work with all versions of AppMeasurement code.

• Dynamic variables are case sensitive.

• Dynamic variables support literal strings contained in quotes.

• Dynamic variable replacement occurs before processing rules, VISTA, and other processing.

• The dynamic variable prefix "D=" must be at the start of the variable value not in the middle. For example, use c2='D="test7"+User-Agent'

rather than c2='"test7"+D=User-Agent'

Implementing Analytics Using JavaScript 135

• As with all implementation techniques, Adobe strongly recommends testing dynamic variable implementations heavily in a development environment before deploying to production. Because the full strings that are copied are not visible in client-side debugging tools, review the affected Analytics reports to confirm successful implementation.

• When copying values between variables with different maximum lengths, note that copying a value that exceeds the maximum length of the destination variable causes truncation. For example, Custom Traffic variables have

100-character limits and Custom Conversion variables have 255-characters limits. When copying a 150-character value from s.eVar1

to s.prop1

using dynamic variables, this value is truncated in the Custom Traffic report at

100 characters.

Dynamic Variable Examples

Examples of dynamic variables you can use in Analytics.

In the Adobe image request that occurs on the page view, if you are using dynamic variables to copy the value of

Custom Traffic 1 to Custom Conversion 1, you would see v1=D=c1

1 reports.

Note that the

D=[variable]

value should be in quotes. The Analytics code treats this as a string. The string will be

URL encoded when passed into Analytics (as you will see if viewing the request in the DigitalPulse Debugger or a similar utility). This is normal. Adobe's servers recognize the

D=[variable]

construction and will copy the appropriate value when they encounter this string.

Note: When using the image request to track links, the type of link (download=lnk_d, exit=lnk_e, or custom link=lnk_o) must be defined, as does the Link URL/Name (pev2). Links require manual implementation by inserting code within the <a href> tag.

Implementing Analytics Using JavaScript 136

Note: Dynamic variables are not supported in conjunction with cookies (s_cc, s_sq, s_fid, s_vi and any cookie that is set by a plugin). You can not use D=<cookie value>.

JavaScript Example

s.eVar1="D=pageName"

Description

Captures the pageName value in eVar1.

s.prop1='D=v2+":"+c2'

Concatenates eVar2:prop2 into prop1.

s.prop1=s.eVar1="D=g"

Passes the page URL into both prop1 and eVar1.

s.eVar1="D=v0"

Captures the campaign in eVar 1.

s.prop1='D=User-Agent+" - "+Accept-Language'

Concatenates the user agent and accept language headers in prop1.

s.prop1="D=User-Agent"

Captures the user agent in prop1,

Image Request Example

/b/ss/rsid/?gn=Home&D=~~&c1=~~v0

/b/ss/rsid/?gn=Home&D=~~&c1=~~campaign

/b/ss/rsid/?gn=Home&c1=D%3dv0%3d is

/b/ss/rsid/?gn=Home&c1=%5b%5bv0%5d%5d%5b

/b/ss/rsid/?gn=Home&D=~~&c2=~~x-up-subno

&c1=D%3DUser-Agent

Description

Four ways to set prop1 to a campaign

&c1=D%3D%22test%22

&c1=D%3D%22US%3A%20%22%2BUser-Agent

&vid=D%3DX-TM-ANTID

Pulls the x-up-subno header into prop2

Makes prop1 a dynamic variable filled in with the HTTP header User-Agent

Makes prop1 a dynamic variable filled in with the string

"test". This becomes more useful when used with concatenation which utilizes the + operator.

Makes prop1 a dynamic variable filled in with the

User-Agent prefixed by "UA:"

This example searches for a unique header, which in this case is X-TM-ANTID.

Page Variables

Page variables directly populate a report, such as pageName, List Props, List Variables, and so on.

Implementing Analytics Using JavaScript 137

Additional eVars and Events

If you want to track additional information, but don’t have enough variables to do so, you now have access to additional eVars and success events:

Note: JavaScript H-Code does not support these additional eVars and events.

Overview

If you have this Adobe

Analytics Product

Analytics

You now have access to

Adobe Analytics - Mobile

Apps

75 eVars, 100 Events

Adobe Analytics (Standard) 100 eVars, 1000 Events

100 eVars, 1000 Events

Adobe Analytics Premium -

Attribution

250 eVars, 1000 Events

Adobe Analytics Premium -

Predictive Intelligence

250 eVars, 1000 Events

Adobe Analytics Premium -

Customer 360

250 eVars, 1000 Events

Adobe Analytics Premium -

Complete

250 eVars, 1000 Events

Populating Variables and Events

• Variables can be populated in the data collection library if you are using these versions of AppMeasurement:

• AppMeasurement for JavaScript version 1.4+

• AppMeasurement for Flash version 3.9+

• AppMeasurement for Java version 1.2.8+

• AppMeasurement for Silverlight/.NET version 1.4.2+

• AppMeasurement for PHP version 1.2.2+

• If you are on an earlier version of code, or on JavaScript H.*, you can populate context data and use processing rules to populate variables.

• All versions of data collection code can populate events 101-1000.

• Processing rules can be used to populate eVars 76-250 based on context data or other variables.

Frequently Asked Questions

• Will all Adobe Analytics interfaces have immediate access to these new variables?

These interfaces will have immediate access: Reports & Analytics, Report Builder, Ad Hoc Analysis, and APIs.

However, the Data Workbench feed from Analytics will not be updated for the new variables until May. If you turn on a variable, you won't be able to access it in Data Workbench until the next version of Data workbench is released

(in the May 2015 time frame.)

• Will these additional eVars and events automatically show up in my data feeds?

Implementing Analytics Using JavaScript 138

Data feeds will have access to the new variables and events once enabled. New eVar columns will not appear until you choose to include them. However, new events will appear in the event_list column as soon as they’re enabled, and the events lookup table contains the event names for those event IDs. Do not enable new events unless you are ready to consume them in Data Feeds.

• How do I request new data feed columns?

To request new columns, refer to

Configuring Data Feeds

• What if I am an Analytics Premium customer who wants to go back to Analytics Standard and I currently

have more than 100 eVars enabled?

Adobe will not disable any of your existing eVars, but you will not be able to enable more. If you disable eVars, you cannot turn them back on until you are below the Analytics Standard limit of 100 enabled eVars.

browserHeight

The browserHeight variable displays the height of the browser window.

This variable is populated after the page code and before doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Parameters

Query Param Value Example Reports Affected

bh A positive integer 865 Traffic > Technology >

Browser Height

browserWidth

The browserWidth variable displays the width of the browser window.

This variable is populated after the page code and before doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Parameters

Query Param Value Example Reports Affected

bw A positive integer 1179 Traffic > Technology >

Browser Width

Implementing Analytics Using JavaScript 139

campaign

The campaign variable identifies marketing campaigns used to bring visitors to your site. The value of campaign is usually taken from a query string parameter.

Parameters

Max Size Debugger Parameter Reports Populated Default Value

255 Bytes v0 Conversion > Campaigns

> Tracking Code

Every element in a marketing campaign should have an associated unique tracking code. For example, a paid search engine keyword may have a tracking code of 112233. When someone clicks the keyword with the 112233 tracking code and is routed to the corresponding website, the campaign variable records the tracking code.

There are two main ways to populate the campaign variable:

• The getQueryParam plug-in, used in the JavaScript file, retrieves a query string parameter from the URL. For more information on the getQueryParam plugin, see

Implementation Plug-ins

• Assign a value to the campaign variable in the HTML on the Web page.

With either method of populating the campaign variable, the Back button traffic may inflate the actual number of click-throughs from a campaign element.

For example, a visitor enters your site by clicking a paid search keyword. When the visitor arrives on the landing page, the URL contains a query string parameter identifying the tracking code for the keyword. The visitor then clicks a link to another page, but then immediately clicks the Back button to return to the landing page. When the visitor arrives a second time on the landing page, the URL with the query string parameter identifies the tracking code again. And a second click-through is registered, thereby falsely inflating the number of click-throughs.

To avoid this inflation of click-throughs, Adobe recommends using the getValOnce plugin to force each campaign

click-through to be counted only once per session. For more information on the getValOnce plugin, see

Implementation

Plug-ins

Syntax and Possible Values

s.campaign="112233"

The campaign variable has the same limitations as all other variables. Adobe recommends limiting the value to standard ASCII characters.

Case Sensitivity

eVars are case insensitive, but they are displayed in the capitalization of the first occurrence. For example, if the first instance of eVar1 is set to "Logged In," but all subsequent instances are passed as "logged in," reports always show "Logged In" as the value of the eVar.

Examples

s.campaign="112233" s.campaign=s.getQueryParam('cid');

Implementing Analytics Using JavaScript 140

Configuration Settings

Each campaign value remains active for a user, and receives credit for that user's activities and success events until it expires. You can change the expiration of the campaign variable in the Admin Console.

Pitfalls, Questions, and Tips

• To keep click-throughs from being inflated, use the getValOnce plugin to let the click-through for a campaign be

counted only once per session. For more information on the getValOnce plug-in, see

Implementation Plug-ins

• For more information on tracking marketing campaigns and keyword buys, see

Campaigns

• Use the DigitalPulse Debugger to see the actual value of campaigns (v0 in the debugger). If v0 does not appear in the debugger, no campaign data is recorded for that page.

channel

The channel variable is most often used to identify a section of your site.

For example, a merchant may have sections such as Electronics, Toys, or Apparel. A media site may have sections such as News, Sports, or Business.

Max Size

100 Bytes

Debugger Parameter

Reports Populated Default Value

Site Content > Site Sections ""

Adobe recommends populating the channel variable on every page. You can also turn on a correlation between the

channel and page name variables.

When sections have one or more levels of subsections, you can show those sections in the channel variable or use separate variables to identify levels.

Syntax and Possible Values

s.channel="value"

The channel variable has no extra limitations on its values.

Examples

s.channel="Electronics" s.channel="Media"

Pitfalls, Questions, and Tips

If your site contains multiple levels, you can use the hierarchy or another variable to designate those levels. The

channel value does not persist, but the success events fired on the same page are attributed to the channel value.

colorDepth

The colorDepth variable is used to show the number of bits used to display color on each pixel of the screen.

For example, 32 represents 32 bits of color on the screen. This variable is populated after the page code and before

doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Implementing Analytics Using JavaScript

Query Param

Value

8,16, and 32

Example

Reports Affected

Traffic > Technology >

Monitor Color Depth

141

connectionType

The connectionType variable, in Internet Explorer, indicates whether the browser is configured on a LAN or modem connection.

This variable is populated after the page code and before doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Query Param

Value

lan or modem

Example

lan

Reports Affected

Traffic > Technology >

Connection Type

cookiesEnabled

The cookiesEnabled variable indicates whether a first-party session cookie could be set by JavaScript.

This variable is populated after the page code and before doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Query Param

Value

Y or N

Example

(Deprecated) The dc variable lets you select the data center to which your data is sent.

Note: The dc variable is deprecated. You should set trackingServer for all implementations to the value that is generated by Code Manager in s_code.js

Default Value

112

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

The data center is identified in the dc variable in order to match ActionSource.

eVarN

The eVar variables are used for building custom reports.

Implementing Analytics Using JavaScript 142

When an eVar is set to a value for a visitor, the value is remembered until it expires. Any success events that a visitor encounters while the eVar value is active are counted toward the eVar value.

Max Size

255 Bytes

Debugger Parameter

V1-v75 (

or v100 or v250

)

Reports Populated

Custom Conversion

Default Value

Expiration

eVars expire after a time period you specify. After the eVar expires, it no longer receives credit for success events.

eVars can also be configured to expire on success events. For example, if you have an internal promotion that expires at the end of a visit, the internal promotion receives credit only for purchases or registrations that occur during the visit in which they were activated.

There are two ways to expire an eVar:

• You can set the eVar to expire after a specified time period or event.

• You can use force the expiration of an eVar, which is useful when repurposing a variable.

If an eVar is used in May to reflect internal promotions and expires after 21 days, and in June it is used to capture internal search keywords, then on June 1 st

, you should force the expiration of, or reset, the variable. Doing so will help keep internal promotion values out of June's reports.

Case Sensitivity

Counters

While eVars are most often used to hold string values, they may also be configured to act as counters. eVars are useful as counters when you are trying to count the number of actions a user takes before an event. For example, you may use an eVar to capture the number of internal searches before purchase. Each time a visitor searches, the eVar should contain a value of '+1.' If a visitor searches four times before a purchase, you will see an instance for each total count: 1.00, 2.00, 3.00, and 4.00. However, only the 4.00 receives credit for the purchase event (Orders and Revenue Metrics). Only positive numbers are allowed as values of an eVar counter.

Subrelations

A common requirement for a Custom eVar report is the ability to break down one Custom eVar report by another.

For example, if one eVar contains gender, and another contains salary, you may ask the following question: of the female visitors to my site, how much revenue was generated by women who make more than $50,000 per year.

Any eVar that is fully sub-related allows this type of break down in reports. For example, if the gender eVar has full subrelations enabled, all other custom eVar reports can be broken down by gender, and gender can be broken down by all others. To see the relationship between two reports, only one of them needs full subrelations enabled. By default, Campaigns, Products, and Category reports are fully sub-related (any eVar can be broken down by campaign or products).

Implementing Analytics Using JavaScript 143

Syntax and Possible Values

While eVars may be renamed, they should always be referred to in the JavaScript file by eVarX, where X is a number

between 1 and 75 (

or 100, or 250

s.eVarX="value"

When not used as a counter, eVars have the same limitations as all other variables. If the eVar is a "counter," it is expected to receive numeric values like "1" or "2.5." If more than two decimal places are given, the eVar counter rounds to two decimal places. An eVar counter may not contain negative numbers.

Examples

s.eVar1="logged in" s.eVar23="internal spring promo 4"

Configuration Settings

eVars can be configured in the Admin Console. All eVars can be configured with a Name, Type, Allocation, Expire

After Setting, or Reset. Each configuration setting is addressed separately.

Setting

Name

Description

Allows you to change the name of the eVar report within Analytics.

The eVar should still be referenced as s.eVarX in the JavaScript code, no matter what name is given to the report in Analytics.

Type

Allocation

Expire After

Reset

Allows you to show whether the eVar is a Text String or Counter.

Used to configure which value of the eVar receives credit for success events.

If Allocation is set to "Most Recent (Last)," then B receives credit.

If Allocation is set to "Original Value (First)" then A receives credit.

If Allocation is set to "Linear", then both A and B receive credit for half the purchase value.

Lets you determine whether an eVar expires on a specific event, like purchase, or after a custom or predefined time period.

By selecting the Reset check box for an eVar, and clicking Save at the bottom of the page, all values of that eVar are immediately expired. After this happens, only new values of the eVar receive credit for success events.

Pitfalls, Questions, and Tips

• Unlike prop variables, eVar variables are not allowed to be lists of delimited values. If you populate an eVar with a list of values, for example "one,two,three," then that exact string appears in reports.

• eVar counters may not contain negative numbers.

Configure Events

The s.events variable is used to record common shopping cart success events as well as custom success events.

Max Size

No Limit

Debugger Parameter

events

Reports Populated Default Value

N/A

Shopping Cart Events

Implementing Analytics Using JavaScript 144

Max Size Debugger Parameter Reports Populated

Custom Events

Default Value

An event should be considered a milestone within a site. Success events are most commonly populated on the final confirmation page of a process, such as a registration process or newsletter sign-up. Custom events are defined by

populating the events variable with the literal values defined in the

Possible Values

section below.

By default, success events are configured as counter events. Counter events count the number of times a success event is set (x+1). Events can also be configured as numeric events. Numeric events allow you to specify the number to increment (as might be necessary when counting dynamic or arbitrary values, such as the number of results returned by an internal search).

A final event type, currency, allows you to define the amount to be added (similar to numeric events), but displays as currency in reports, and is subject to currency conversions based on the s.currencyCode value and the default currency setting for your report suite. For additional information on using numeric and currency events, see

Products

Configuring the Variable

The s.events variable is enabled by default for all implementations. The seven pre-configured conversion events

are automatically enabled for all new report suites. New custom events (event1-

event100 or event1000

) can be

enabled by any admin-level user using the Admin Console.

Possible Values

The following is a list of possible values for the events variable:

Event

prodView scOpen scAdd scRemove scView scCheckout purchase event1 - event1000 (event100 for point product)

Description

Product Views

Reports Populated

Products

Open / Initialize a new shopping cart Carts

Add item(s) to the shopping cart Cart Additions

Cart Removals Remove item(s) from the shopping cart

View shopping cart

Beginning of the checkout process

Completion of a purchase (order)

Custom events

Cart Views

Checkouts

Orders

Custom Events

Syntax and Examples

Counter Events

Counter events are set by placing the desired events in the s.events variable, in a comma-separated list (if multiple events are to be passed).

s.events="scAdd" s.events="scAdd,event1,event7" s.events="event5" s.events="purchase,event10"

Implementing Analytics Using JavaScript 145

If on H23 code or higher, counter events can have integers greater than one assigned to them.

s.events="event1=10" s.events="scRemove=3,event6,event2=4"

Implementing counter events with assigned integer values treat the event as if it fired multiple times within the image request. Counter events do not allow decimals- it is recommended to use numeric events instead if this functionality is required.

Numeric/Currency Events

Numeric and currency events must be included in the s.events variable, though they typically receive their numerical value (e.g., 24.99) in the s.products variable. This allows you to tie specific numeric and currency values to individual product entries.

With Products

s.events="event1" s.products="Footwear;Running Shoes;1;99.99;event1=4.50" s.events="event1,event4" s.products="Footwear;Running Shoes;1;99.99;event1=4.50|event4=1.99"

Without Products

You can also track these types of events by leaving the product and category fields blank. This was the process to measure data such as tax and shipping before support was added for decimal values outside of the products string.

If you want to pass a numeric or currency value but do not want to tie these to an individual product (such as a discount applied to an entire order, or a value captured outside of the product view or shopping cart process), this can be done by using s.products as shown below, but leaving the product and category fields blank.

s.events="event1" s.products=";;;;event1=4.50" s.events="event1,event4" s.products=";;;;event1=4.50|event4=1.99"

In the Events List

Numeric/Currency Events that are given a value directly in events list apply to all products in the products list.

This is useful to track order-wide discounts, shipping, and similar values, without modifying the product price or by tracking it in the product list separately. For example, if you configured event10 to contain order-wide discounts, a purchase with a 10% discount might appear similar to the following: s.events="purchase,event10=9.95" s.products="Footwear;Running Shoes;1;69.95,Running Essentials;Socks;10;29.50"

On Numeric/Currency Event reports, the report total represents the de-duplicated event total (in this example, the total amount of discounts during the reporting period), not the sum of the event values for each product.

Note: if a value for a Numeric/Currency Event is specified in the products string and in the event string, the value from the event string is used.

Combining Counter Events and Numeric/Currency Events

Counter events can be passed along with numeric/currency events by passing all desired events in the s.events variable, and then passing only the numeric/currency events in the s.products variable.

Event Serialization

By default, an event is counted every time the event is set on your site.

Implementing Analytics Using JavaScript 146

See

Event Serialization

for more information.

Syntax

s.events="event1:3167fhjkah"

Examples

s.events="scAdd:003717174" s.events="scAdd:user228197,event1:577247280,event7:P7fhF8571"

hierN

The hierarchy variable determines the location of a page in your site's hierarchy.

This variable is most useful for sites that have more than three levels in the site structure. For example, a media site may have 4 levels to the Sports section: Sports, Local Sports, Baseball, and Red Sox. If someone visits the

Baseball page, Sports, Local Sports, and Baseball, all levels reflect that visit.

Max Size

255 Bytes

Debugger Parameter

H1-H5

Reports Populated

Hierarchy

Default Value

There are five hierarchy variables available, which must be enabled by Adobe Customer Care. At the time the hierarchy is enabled, you should decide on a delimiter for the variable and the maximum number of levels for the hierarchy. For example, if the delimiter is a comma, the sports hierarchy may display as follows.

s.hier1="Sports,Local Sports,Baseball"

Make sure that none of your section names have the delimiter in them. For example, if one of your sections is called

"Coach Griffin, Jim," then you should choose a delimiter other than comma. Each hierarchy section is limited to 255 bytes, while the total variable limit is 255 bytes. After a delimiter is chosen (at the time the hierarchy is created) it is not easily changed.

Contact Adobe Customer Care about changing the delimiter for an existing hierarchy. Delimiters may also consist of multiple characters, such as || or /|\, which are less likely to appear in a hierarchy section.

Syntax and Possible Values

Do not put a space between each delimiter. In the following example syntax, N is a number between one and five.

s.hierN="Level 1[<delimiter>Level 2[<delimiter>Level 3[...]]]"

Do not use the delimiter except to delimit the levels of the hierarchy. The delimiter may be any character or characters of your choice.

Examples

s.hier1="Toys|Boys 6+|Legos|Super Block Tub" s.hier4="Sports/Local Sports/Baseball"

Configuration Settings

None

Implementing Analytics Using JavaScript 147

Pitfalls, Questions, and Tips

• The delimiter may not be changed after the hierarchy is set up. If the delimiter for your hierarchy must be changed, contact Adobe Customer Care.

• The number of levels may not be changed after the hierarchy is set up.

Note: Changes to hierarchies can result in a service charge.

homepage

The homepage variable, in Internet Explorer, indicates whether the current page is set as the user's home page.

This variable is populated after the page code and before doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Query Param

Value

Y or N

Example

Reports Affected

Traffic > Technology >

Home Page

javaEnabled

The javaEnabled variable indicates whether Java is enabled on the browser.

This variable is populated after the page code and before doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Query Param

Value

Y or N

Example

Reports Affected

Traffic > Technology > Java

javascriptVersion

The javascriptVersion variable indicates the version of JavaScript supported by the browser.

This variable is populated after the page code and before doPlugins is run.

Note: This variable should only be read and never set.

You may read these values and copy them into props/eVars

, but you should never alter them. This variable is introduced with version H.11 of the JavaScript file.

Query Param Value

1.0, 1.1, 1.2, … 1.7

Example

1.7

Reports Affected

Traffic > Technology >

JavaScript Version

Implementing Analytics Using JavaScript 148

Version H.10 and higher of the JavaScript file accurately detect up to version 1.7 (the highest version at the time

H.10 was released). Prior versions of the JavaScript file only detected up to version 1.3

linkName

The linkName variable is an optional variable used in Link Tracking that determines the name of a custom, download, or exit link.

The linkName variable is not normally needed because the third parameter in the tl() function replaces it.

Max Size

100 bytes

Debugger Parameter

pev2

Reports Populated Default Value

File Downloads

Custom Links

Exit Links

Custom Links refer to links that send tracking data. The linkName variable (or the third parameter in the tl() function) is used to identify the value that appears in the Custom, Download, or Exit Links report. If linkName is not populated, the URL of the link appears in the report.

Syntax and Possible Values

s.linkName="Link Name"

There are no limitations on linkName outside of the standard variable limitations.

Examples

s.linkName="Nav Bar Home Link" s.linkName="Partner Link to A.com"

Configuration Settings

None

Pitfalls, Questions, and Tips

• The linkName variable is replaced by the third parameter in the tl() function.

• If the linkName variable and the third parameter in the tl() function are blank, the full URL of the link (with the exception of the query string) appears in the report (even if the link is relative).

linkType

The linkType variable is an optional variable used in link tracking that determines which report a link name or URL appears (custom, download, or exit links).

The linkType variable is not normally needed because the second parameter in the tl() function replaces it.

Max Size

One character

Debugger Parameter

pe=[lnk_o|lnk_d|lnk_e]

Reports Populated Default Value

File Downloads

Custom Links

Exit Links

Implementing Analytics Using JavaScript 149

Custom links send data to Analytics. The linkType variable (or the second parameter in the tl() function) is used to identify the report in which the link name or URL appears (Custom, Download, or Exit Links report).

For exit and download Links, the linkType variable is automatically populated depending on whether the link clicked is an exit or download link. A custom link may be configured to send data to any of the three reports with this variable or with the second parameter in the tl() function. By setting linkType to 'o,' 'e,' or 'd,' the linkName or link URL is sent to the Custom Links, Exit Links, or File Downloads report respectively.

Syntax and Possible Values

The linkType variable syntax depends on whether you use XML or a query string.

If you are using XML, the variable may only contain a single character, namely 'o,' 'e,' or 'd.' s.tl(this,’o’,’Link Name’);

If you are using the query-string pe

, you need to use lnk_d

, lnk_e

, or lnk_o

Examples

<a href="index.html" onClick="

var s=s_gi('rsid'); **see note below on the rsid**

s.tl(this,'o','Link Name');

">My Page</a>

Configuration Settings

None

Pitfalls, Questions, and Tips

• If linkType is not specified, custom links ('o') is assumed.

List Props

List props are a delimited list of values that are passed into a variable, then reported as individual line items. List props are most commonly implemented on pages that contain user-selectable values, such as listed items with check boxes or radio buttons. They are useful in any circumstance where you want to define multiple values in a variable without sending multiple image requests.

Considerations

• List props are enabled only on traffic variables (

props

• Pathing and correlations cannot be enabled for list props.

• Analytics provides visits and unique visitors to almost every report, including all list prop reports.

• Classifications are supported for list props.

• Any custom traffic variable can become a list prop. (Exceptions:

pageName

channel

, and

server

• When defining duplicate values in the same image request, instances are not deduplicated.

A prop can be changed into a list prop on the Admin Tools > Report Suite > Traffic Variables page by enabling List

Support and then selecting a delimiter. Popular delimiters are colons, semi-colons, commas, or pipes. The delimiter can technically be any of the first 127 ASCII characters.

Implementation Examples

When you request enabling of list props, indicate the delimiter that you would like to use. After the s.prop of your choice is enabled, multiple values can be set in the variable as shown in the following examples:

Implementing Analytics Using JavaScript 150

A list prop delimited by a pipe, passing in two values: s.prop1="Banner ad impression|Sidebar impression"

A list prop delimited by a comma passing in several values: s.prop2="cerulean,vermilion,saffron"

List props can also be sent with a single value: s.prop3="Single value"

The delimiter can be changed at any time. However, the implementation must match the new delimiter. Failure to use the correct delimiter results in the list prop value being treated as a single concatenated line item in reporting.

Because a list prop is still a Traffic Variable, it is subject to Traffic Variable limitations. List props are limited to 100 bytes of data and are affected by case sensitivity settings.

List Variable

Also known as List Var. Similar to how List Props function, List Vars allow multiple values within the same image request. They also act similarly to eVars, which persist beyond the image request they were defined on. You can use these variables to see cause and effect among multiple elements on a single page, such as product lists, wish lists, lists of search refinements, or lists of display ads.

Considerations:

• List Vars remember their specific values by referencing the VisitorID cookie in the visitor's browser.

• A limit of 250 maximum values are stored at one time per visitor. If 250 values per visitor are exceeded, the latest

250 values are used. Expiration for these values is based on the configured expiration for the variable.

• Each delimited value can contain a maximum of 255 characters (or less if using multi-byte characters). This is the maximum length of each element.

• There is no limit to the number of characters within this variable. The only exception to this limitation is within older

Internet Explorer browsers, which impose a 2083-character limitation on all URL requests.

• A total of three List Vars are available per report suite.

• Using List Vars requires H23 code or higher.

• List Vars can be classified.

• If duplicate values are defined in the same image request, list vars deduplicate all instances of those values.

• The most granular list vars can be segmented is on a hit (or page view) level. If you have a list var with three values in the same image request, any segment rules that match one value will pull all three into reporting. Conversely, if an exclude rule is defined that matches a single value, all three values are excluded.

Configuration

You can access the configuration in the Admin Console and update it without Adobe Client Care having to get involved:

1. Go to Analytics > Admin > Report Suites

2. Select the report suite.

3. Click Edit Settings > Conversion > List Variables.

• Name: Each delimited value can contain a maximum of 255 characters (or less if using multi-byte characters). This is the maximum length of each element.

• Value Delimiter: The character used to separate values within the List Var. Most commonly these are characters such as commas, colons, pipes, or something similar.

Note: Multi-byte characters are not supported as delimiters in List Vars. The delimiter must be single byte.

Implementing Analytics Using JavaScript 151

• Expiration: Similar to eVar expiration, this determines the amount of time that can occur between the List Var and the conversion event for them to be related.

• At a page view or visit level: Success events beyond the page view or visit would not link back to any values within the List Var.

• Based on a time period, such as day, week, month, etc: Success events beyond the specified time period would not link back to any values within the List Var. A custom number of days can be defined as well.

• Specific conversion events: Any other success events that fire after the specific event designated would not link back to any values within the List Var.

• Never: Any amount of time can pass between the List Var and success event.

• Allocation: This setting determines how success events divide credit between values:

• Full: All variable values defined prior to the variable's expiration get full credit for success events.

• Linear: All variable values defined prior to the variable's expiration get credit divided credit for conversion events.

• Variable values are never overwritten, but instead added to the values that get credit for success events.

• Max Values: Designates the number of active values allowed for this list variable. For example, if set to 3, only the last 3 values captured is saved and any previous values captured are discarded. Note that if multiple values for the same list var are sent in on the same hit and you have restricted using max values, each value will have the same timestamp and there is not guarantee as to which value is saved.

A limit of 250 maximum values are stored at one time per visitor. If 250 values per visitor are exceeded, the latest

250 values are used. Expiration for these values is based on the configured expiration for the variable.

The Max Values setting is useful to limit attribution to a specific number of values. For example, if a list var is set to "A,B,C" on the first page of a visit, then set to "X,Y,Z" on the next page, attribution is distributed to these six values based on the allocation. If you wanted to limit attribution to only "X,Y,Z", you can set max values to three.

To set up or edit List Vars, go to Analytics > Admin > Report Suites > Edit Settings > Conversion > List

Variables.

Implementation Examples

Each of the following examples use a comma for the value delimiter.

Defining a single value within a List Var:

s.list1="Cat";

Passing in multiple values:

s.list2="Tabby,Persian,Siamese"; s.list1="Product 1,Product 2,Product 3";

Attributing revenue to a List Var:

//Define this code on the landing page: s.list3="Top Banner Ad,Side Bar Ad,Internal Campaign 1";

//Have these variables fire on the purchase confirmation page: s.products=";Kitten;1;50" s.events="purchase";

This result would show three line items with $50 each in revenue. (Top Banner Ad; Side Bar Ad; and Internal

Campaign 1.) Note the total for this report deduplicates revenue, so the total would also reflect $50.

Attributing revenue to a List Var that was set multiple times during a visit:

Allocation: Full

Expiration: Visit

Implementing Analytics Using JavaScript 152

Page

Page 1

Page 2

s.list1

s.list1=”value1,value2,value3”; s.list1=”value4,value5,value6”;

s.events/s.products

(not set) s.events=”purchase”; s.products=”;product;1;200”

Result: All values set in the list var1 at any point during the visit (value1,value2,value3,value4,value5,value6) get full credit for the purchase.

maxDelay

The s.maxDelay variable is used primarily in Genesis DFA integrations to determine the timeout period in contacting the DFA host. If Adobe does not receive a response from DFA's servers within the specified period set in the

s.maxDelay variable, the connection is severed, and data is processed normally. Implement this variable if you are concerned with DFA's response time on each page. It is recommended to experiment with this value to determine the optimum timeout period.

Implementation Example

s.maxDelay="750";

Properties

• This variable is an optional event metric populated via the JavaScript implemented on your site.

• If the DFA host does not respond within the given amount of time, the event designated to Timeout runs (assigned via the Genesis integration wizard).

• This variable can only contain a numeric value.

• The amount of time specified is measured in milliseconds.

• Increasing the wait time collects more DFA data, but also increases the risk of losing Analytics hit data.

Losing Analytics hit data would occur when the user navigates away from the page during the s.maxDelay period.

• Decreasing the wait time will lower the risk of losing Analytics hit data, but can reduce the amount of DFA data sent with hit data.

Losing DFA integration data would occur when the s.maxDelay period does not accommodate enough time for the

DFA host to respond.

Note: Adobe does not have control over DFA's response time. If you are seeing consistent issues even after raising the max delay period to a reasonable time frame, consult your organization's DFA account administrator.

mediaLength

The mediaLenght variable specifies the total length of the media being played.

Max Size Debugger Parameter

No max size for entire pev3 request - size is limited to the browser's URL length limit.

pev3

Reports Populated

Time Spent on Video;

Video Segments Viewed

Default Value

None

Syntax and Possible Values autoTrack Method:

Implementing Analytics Using JavaScript 153

If using s.Media.autoTrack, the mediaLength variable does not need to be implemented explicitly. It is determined automatically by the AppMeasurement for JavaScript code.

Manual Tracking Method:

Syntax: s.Media.open(mediaName,mediaLength,mediaPlayerName)

Possible Values: s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230")

Examples

s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230")

Resulting pev3 parameter syntax: pev3= [Asset Name]--**--[Total length of asset]--**--[Player

name]--**--[Total seconds consumed]--**--[Timestamp]--**--[Chronological record of all starts

and stops along with accompanying markers]

Possible pev3 values: pev3=de_bofr_1045Making_400k--**--414--**--Windows Media Player

11.0.5721.5230--**--288--**--1207893838--**--S0E0S0E256S0E32

Pitfalls, Questions, and Tips

• You must call the media tracking methods only if the player cannot be tracked using s.Media.autoTrack = true.

• If not tracking using autoTrack, be sure to set the length in seconds.

mediaName

This variable specifies the name of the video or media item.

It is only available via the Data Insertion API and Full Processing Data Source.

Max Size

64 KB

Debugger Parameter

pev3

Reports Populated Default Value

Videos; Next Video Flow;

Previous Video Flow; Video

Segments Viewed; Time

Spent on Video

None

Syntax and Possible Values autoTrack Method:

If using s.Media.autoTrack, the mediaName variable does not need to be implemented explicitly. It is determined automatically by the AppMeasurement for JavaScript code.

Manual Tracking Method:

Syntax: s.Media.open(mediaName,mediaLength,mediaPlayerName) s.Media.play(mediaName,mediaOffset) s.Media.stop(mediaName,mediaOffset) s.Media.close(mediaName)

Implementing Analytics Using JavaScript 154

Possible Values: s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230") s.Media.play("de_bofr_1045Making_400k", "0") s.Media.play("de_bofr_1045Making_400k", "414") s.Media.close("de_bofr_1045Making_400k")

Examples

s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230") s.Media.play("de_bofr_1045Making_400k", "0") s.Media.play("de_bofr_1045Making_400k", "414") s.Media.close("de_bofr_1045Making_400k")

Resulting pev3 parameter syntax: pev3=[Asset Name]--**--[Total length of asset]--**--[Player name]--**--[Total seconds consumed]--**--[Timestamp]--**--[Chronological record of all starts

and stops along with accompanying markers]

Possible pev3 Values:

pev3=de_bofr_1045Making_400k--**--414--**--Windows Media Player

11.0.5721.5230--**--288--**--1207893838--**--S0E0S0E256S0E32

Pitfalls, Questions, and Tips

• You must call the media tracking methods only if player cannot be tracked using s.Media.autoTrack = true.

• This variable is stored as a mySQL TEXT variable as opposed to VARCHAR(100).

mediaPlayer

This variable specifies the player used to consume a video or media item.

Max Size

100 Bytes

Debugger Parameter

pev3

Reports Populated

Video Players

Default Value

None

Syntax and Possible Values autoTrack Method:

s.Media.playerName = "My Custom Player Name" //configure player name in global JavaScript or

ActionSource

Manual Tracking Method:

s.Media.open(mediaName,mediaLength,mediaPlayerName)

Possible Values: s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230")

Examples

s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230")

Resulting pev3 parameter syntax: pev3=[Asset Name]--**--[Total length of asset]--**--[Player name]--**--[Total seconds consumed]--**--[Timestamp]--**--[Chronological record of all starts

and stops along with accompanying markers]

Possible pev3 Values: pev3=de_bofr_1045Making_400k--**--414--**--Windows Media Player

11.0.5721.5230--**--288--**--1207893838--**--S0E0S0E256S0E32

Implementing Analytics Using JavaScript

Pitfalls, Questions, and Tips

You must call the media tracking methods only if player cannot be tracked using s.Media.autoTrack

= true.

mediaSession

This variable specifies the segments of a video or media asset consumed.

Max Size

255 Bytes

Debugger Parameter

pev3

Reports Populated

Time Spent on Video

Video Segments Viewed

Default Value

None

155

Syntax and Possible Values autoTrack Method:

If using s.Media.autoTrack, the mediaName does not need to be implemented explicitly. It will be determined automatically by the AppMeasurement for JavaScript code.

Manual Tracking Method:

Syntax: s.Media.open(mediaName,mediaLength,mediaPlayerName) s.Media.play(mediaName,mediaOffset) s.Media.stop(mediaName,mediaOffset)

Possible Values: s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230") s.Media.play("de_bofr_1045Making_400k", "0") s.Media.play("de_bofr_1045Making_400k", "414")

Examples

s.Media.open("de_bofr_1045Making_400k", "414","Windows Media Player 11.0.5721.5230") s.Media.play("de_bofr_1045Making_400k", "0") s.Media.play("de_bofr_1045Making_400k", "414")

Resulting pev3 parameter syntax: pev3=[Asset Name]--**--[Total length of asset]--**--[Player name]--**--[Total seconds consumed]--**--[Timestamp]--**--[Chronological record of all starts

and stops along with accompanying markers]

Possible pev3 Values: pev3=de_bofr_1045Making_400k--**--414--**--Windows Media Player

11.0.5721.5230--**--288--**--1207893838--**--S0E0S0E256S0E32

Pitfalls, Questions, and Tips

You must call the media tracking methods only if player cannot be tracked using s.Media.autoTrack = true.

Media.trackEvents

The Media.trackEvents variable identifies which events should be sent with a media hit.

It is only applicable with JavaScript and ActionSource.

Implementing Analytics Using JavaScript 156

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

s.Media.trackEvents="None"

Syntax and Possible Values

Event names such as event1 or purchase.

Examples

s.Media.trackEvents=”event1,purchase”

Pitfalls, Questions, and Tips

Make sure to populate trackVars with "events" whenever this variable is populated.

Media.trackVars

The Media.trackVars variable identifies which variables should be sent with a media hit.

It is only applicable with JavaScript and ActionSource.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

s.Media.trackVars="None"

Syntax and Possible Values

Variable names such as propN, eVarN, events, channel, and so forth.

Examples

s.Media.trackVars=”prop2,events,eVar3”

Pitfalls, Questions, and Tips

• Even if eVar3 is specified in trackVars, it is sent with the media hit.

mobile

The mobile variable controls the order in which cookies and subscriber IDs are used to identify visitors.

See

Mobile Tracking over WAP and I-Mode Protocols

Max Size

N/A

Debugger Parameter Reports Populated

/5/ or /1/ in path of image url N/A

Default Value

None

Syntax and Possible Values

s.mobile="any_string" //subscriber id used first, produces /5/ in path of image url s.mobile="" // if set to an empty string or not set at all, cookies used first, produces /1/

in path of image url

Pitfalls, Questions, and Tips

Use cross-visitor identification to mitigate possible spikes in visitor traffic when using the s.mobile variable with the

JavaScript cookie implementation.

Implementing Analytics Using JavaScript 157

pageName

The pageName variable contains the name of each page on your site.

Max Size

100 bytes

Debugger Parameter

pageName

Reports Populated

Pages

Paths

Default Value

page URL

The pageName variable should be populated with a value that business users recognize. In most cases the pageName value is not the URL or the path to the file. Common pageName values include names such as "Home Page,"

"Checkout," "Purchase Thank you," or "Registration."

Be careful not to allow new-line, -em or -en dashes, or any HTML characters to appear in the page name and other variables. Some browsers send new line characters while others don't, which causes the data in Analytics to be split between two seemingly identical page names. Many word processors and email clients will automatically convert a hyphen into an -en or -em dash when typing. Since -en and -em dashes are illegal characters in Analytics variables

(ASCII characters with codes above 127), Analytics won't record the page name containing the illegal character and show the URL instead.

If pageName is left blank, the URL is used to represent the page name. Leaving pageName blank is often problematic because the URL may not always be the same for a page (www.mysite.com and mysite.com are the same page with different URLs).

Syntax and Possible Values

The pageName variable should contain a useful identifier for business users of Analytics.

s.pageName="page_name"

There are no limitations on pageName outside of the standard variable limitations.

Examples

s.pageName="Search Results" s.pageName="Standard Offer List"

Configuration Settings

Administrators have the ability to change the visible page name in Analytics with the Name Pages tool, which is potentially dangerous and may negatively affect your reports. Please contact Adobe Customer Care before using the Name Pages tool.

Pitfalls, Questions, and Tips

Make sure the pageName doesn't contain illegal characters.

pageType

The pageType variable is used only to designate a 404 Page Not Found Error page.

Implementing Analytics Using JavaScript 158

Max Size

20 bytes

Debugger Parameter

pageType

Reports Populated

Paths > Pages > Pages

Not Found

Default Value

The pageType variable captures the errant URL when a 404 Error page is displayed, which allows you to quickly find broken links and paths that are no longer valid on the custom site. Set up the pageType variable on the error page exactly as shown below.

Do not use the page name variable on 404 error pages. The pageType variable is only used for the 404 Error page.

In most cases, the 404 Error page is a static page that is hard-coded. In these cases, it is important that the reference to the .JS file is set to an appropriate global or relative path/directory.

Syntax and Possible Values

The only allowable value of pageType is "errorPage" as shown below.

s.pageType="errorPage"

Examples

s.pageType="errorPage"

Configuration Settings

None

Pitfalls, Questions, and Tips

To capture other server-side errors (such as 500 errors), use a prop to capture the error message and put "500

Error: <URL>" where <URL> is the URL requested, in the pageName variable. By following this course of action, you can use Pathing reports to see which paths caused users to generate 500 errors. The prop explains which error message is given by the server.

pageURL

The pageURL variable overrides the actual URL of the page.

In rare cases, the URL of the page is not the URL that you would like reported in Analytics.

Max Size

No Limit*

Debugger Parameter

Reports Populated Default Value

Traffic > Segmentation >

Additional eVars and Events

If you want to track additional information, but don’t have enough variables to do so, you now have access to additional eVars and success events:

Note: JavaScript H-Code does not support these additional eVars and events.

Implementing Analytics Using JavaScript 173

Overview

If you have this Adobe

Analytics Product

Analytics

You now have access to

75 eVars, 100 Events

Adobe Analytics (Standard) 100 eVars, 1000 Events

Adobe Analytics - Mobile

Apps

100 eVars, 1000 Events

Adobe Analytics Premium -

Attribution

250 eVars, 1000 Events

Adobe Analytics Premium -

Predictive Intelligence

250 eVars, 1000 Events

Adobe Analytics Premium -

Customer 360

250 eVars, 1000 Events

Adobe Analytics Premium -

Complete

250 eVars, 1000 Events

Populating Variables and Events

• Variables can be populated in the data collection library if you are using these versions of AppMeasurement:

• AppMeasurement for JavaScript version 1.4+

• AppMeasurement for Flash version 3.9+

• AppMeasurement for Java version 1.2.8+

• AppMeasurement for Silverlight/.NET version 1.4.2+

• AppMeasurement for PHP version 1.2.2+

• If you are on an earlier version of code, or on JavaScript H.*, you can populate context data and use processing rules to populate variables.

• All versions of data collection code can populate events 101-1000.

• Processing rules can be used to populate eVars 76-250 based on context data or other variables.

Frequently Asked Questions

• Will all Adobe Analytics interfaces have immediate access to these new variables?

These interfaces will have immediate access: Reports & Analytics, Report Builder, Ad Hoc Analysis, and APIs.

(in the May 2015 time frame.)

• Will these additional eVars and events automatically show up in my data feeds?

• How do I request new data feed columns?

To request new columns, refer to

Configuring Data Feeds

• What if I am an Analytics Premium customer who wants to go back to Analytics Standard and I currently

have more than 100 eVars enabled?

Implementing Analytics Using JavaScript

174

Variables and Limitations

High-level look at variables and their limitations.

Note: See

Configuration Variables and

Page Variables

for an in-depth look at the most common Analytics variables.

The following table provides at-a-glance information about Analytics variables:

Variable

s_account browserHeight browserWidth campaign channel charSet colorDepth connectionType cookieDomainPeriods cookieLifetime cookiesEnabled currencyCode dc doPlugins dynamicAccountList dynamicAccountMatch dynamicAccountSelection

Description

Determines the report suite where data is stored and reported.

Displays the height of the browser window.

Displays the width of the browser window.

Identifies marketing campaigns used to bring visitors to your site. The value of

campaign is usually taken from a query string parameter.

Usually identifies a section of your website. For example, a merchant may have sections such as Electronics, Toys, or Apparel. A media site may have sections such as News, Sports, or Business.

Translates the character set of the Web page into UTF-8.

Displays the number of bits used to display color on each pixel of the screen.

Indicates (in Microsoft Internet Explorer) whether the browser is configured on a LAN or modem connection.

Determines the domain on which the Analyticsvisitor ID (s_vi) cookie will be set by determining the number of periods in the domain of the page URL. For www.mysite.com, cookieDomainPeriods should be "2." For www.mysite.co.jp,

cookieDomainPeriods should be "3."

Used by both JavaScript and Analytics servers to determine the lifespan of a cookie.

Indicates whether a first-party session cookie could be set by JavaScript.

Determines the conversion rate to be applied to revenue as it enters the Analytics databases. Analytics databases store all monetary amounts in a currency of your choice. If that currency is the same as that specified in currencyCode, or

currencyCode is empty, no conversion is applied.

Lets you set the data center to which your data is sent.

doPlugins is a reference to the s_doPlugins function. It allows the s_doPlugins function to be called at the appropriate location within the JavaScript file.

Dynamically selects a report suite to which data is sent. The dynamicAccountList variable contains the rules that used to determine the destination report suite.

Uses the DOM object to retrieve the section of the URL to which all rules in

dynamicAccountList are applied. This variable is only valid when

dynamicAccountSelection is set to 'True.'

Lets you dynamically select the report suite based on the URL of each page.

Implementing Analytics Using JavaScript

Variable

dynamicVariablePrefix eVarN events fpCookieDomainPeriods hierN homepage javaEnabled javascriptVersion linkDownloadFileTypes linkExternalFilters linkInternalFilters linkLeaveQueryString linkName linkTrackEvents linkTrackVars linkType mediaLength mediaName mediaPlayer mediaSession

175

Description

Allows deployment to flag variables that should be populated dynamically.

Cookies, request headers, and image query string parameters are available to be populated dynamically.

Used for building custom reports within the AnalyticsConversion Module. When an eVar is set to a value for a visitor, Analytics remembers that value until it expires. Any success events that a visitor encounters while the eVar value is active are counted toward the eVar value.

Records common shopping cart success events and custom success events.

Determines the domain on which Analytics cookies other than the visitor ID

(s_vi) cookie will be set by determining the number of periods in the domain of the page.

Determines the location of a page in your site's hierarchy. This variable is most useful for sites that have more than three levels in the site structure.

Indicates (in Internet Explorer) whether the current page is set as the user's home page.

Indicates whether Java is enabled in the browser.

Displays the version of JavaScript supported by the browser.

A comma-separated list of file extensions. If your site contains links to files with any of these extensions, the URLs of these links appear in the File Downloads report.

If your site contains many links to external sites, and you don't want to track all exit links, linkExternalFilters can be used to report on a specific subset of exit links.

Determines which links on your site are exit links. It is a comma-separated list of filters that represent the links that are part of the site.

Determines whether or not the query string should be included in the Exit Links and File Download reports.

An optional variable used in Link Tracking that determines the name of a custom, download, or exit link. The linkName variable is not normally needed because the third parameter in the tl() function replaces it.

Contains the events that should be sent with custom, download, and exit links.

This variable is only considered if linkTrackVars contains "events."

A comma-separated list of variables that will be sent with custom, exit, and download links. If linkTrackVars is set to "", all variables that have values are sent with link data.

An optional variable used in link tracking that determines which report a Link

Name or URL will appear (custom, download, or exit Links). linkType is not normally needed because the second parameter in the tl() function replaces it.

Specifies the total length of the media being played.

Specifies the name of the video or media item. It is only available via the Data

Insertion API and Full Processing Data Source.

Specifies the player used to consume a video or media item.

Specifies the segments of a video or media asset consumed.

Implementing Analytics Using JavaScript

Variable

Media.trackEvents

Media.trackVars

mobile s_objectID pageName pageType pageURL plugins products propN purchaseID referrer resolution server state trackDownloadLinks trackExternalLinks trackingServer trackingServerSecure trackInlineStats

176

Description

Identifies which events should be sent with a media hit. It is only applicable with

JavaScriptActionSource..

Identifies which variables should be sent with a media hit. It is only applicable with JavaScriptActionSource..

Controls the order in which cookies and subscriber ids are used to identify visitors.

A global variable that should be set in the onClick event of a link. By creating a unique object ID for a link or link location on a page, you can improve visitor click map tracking or use visitor click map to report on a link type or location, rather than the link URL.

Contains the name of each page on your site. If pageName is blank, the URL is used to represent the page name in Analytics.

Used only to designate a 404 Page Not Found Error page. It only has one possible value, which is "errorPage." On a 404 Error page, the pageName variable should not be populated.

In rare cases, the URL of the page is not the URL that you would like reported in Analytics. To accommodate these situations, Analytics offers the pageURL variable, which overrides the actual URL of the page.

On Netscape and Mozilla-based browsers, lists the plugins installed in the browser.

Used for tracking products and product categories as well as purchase quantity and purchase price. The products variable should always be set in conjunction with a success event. Optionally, the products variable can track custom numeric and currency events, as well as Merchandising eVars.

Used for building custom reports within the AnalyticsTraffic Module. props may be used as counters (to count the number of times a page view is sent), for pathing reports, or in correlation reports.

Used to keep an order from being counted multiple times by Analytics. Whenever the purchase event is used on your site, you should use the purchaseID variable.

Restores lost referrer information.

Displays the monitor resolution of the visitor viewing the Web page.

Shows either the domain of a Web page (to show which domains people come to) or the server serving the page (for a load balancing quick reference).

Captures the state in which a visitor to your site resides.

Set trackDownloadLinks to 'true' if you want to track links to downloadable files on your site. If trackDownloadLinks is 'true,' linkDownloadFileTypes determines which links are downloadable files.

If trackExternalLinks is 'true,' linkInternalFilters and linkExternalFilters determines whether any link clicked is an exit link.

Used for first-party cookie implementation to specify the domain at which the image request and cookie is written. Used for non-secure pages.

Used for first-party cookie implementation to specify the domain at which the image request and cookie is written. Used for secure pages.

Determines whether visitor click map data is gathered.

Implementing Analytics Using JavaScript

Variable

transactionID s_usePlugins visitorID visitorNamespace zip

177

Description

Ties offline data to an online transaction (like a lead or purchase generated online). Each unique transactionID sent to Adobe is recorded in preparation for a Data Sources upload of offline information about that transaction. See the

Data Sources Guide

If the s_doPlugins function is available and contains useful code, s_usePlugins should be set to 'true.' When usePlugins is 'true,' the s_doPlugins function is called prior to each image request.

Visitors may be identified by the visitorID tag, or by IP address/User Agent. The

visitorID may be up to 100 alphanumeric characters and must not contain a hyphen.

If visitorNamespace is used in your JavaScript file, do not delete or alter it. This variable is used to identify the domain with which cookies are set. If

visitorNamespace changes, all visitors reported in Analytics may become new visitors. In short, do not alter this variable without approval from an Adobe consultant.

Captures the ZIP code in which a visitor to your site resides.

Illegal JavaScript Characters

Characters and strings that are never allowed in JavaScript variables.

• Tab (0x09)

• Carriage return (0x0D)

• Newline (0x0A)

• ASCII characters with codes above 127 (unless multi-byte characters are enabled and charSet is populated appropriately)

• HTML tags (e.g. <b></b> or &#153)

Many variables, most notably products, hierarchy, and events, have additional limitations or syntax requirements.

For individual variable limitations and syntax requirements, see the section corresponding to the s_account variable parameters.

Merchandising Variables

When measuring the success of external campaigns or external search terms, you typically want a single value to receive credit for any success events that occur. For example, if a customer clicks a link in an email campaign to visit your website, all purchases made as a result should be credited to that campaign.

But what about events that are driven by internal search or by category browsing when a customer is looking for multiple items? For example, a customer searches your site for "goggles" and then adds a pair to the cart:

Implementing Analytics Using JavaScript 178

Before checkout, the customer searches for "winter coat", and then adds a down jacket to the to the cart:

When this purchase is completed, assuming the allocation wasn't changed from Most Recent, you'll have an internal search for "winter coat" credited with the purchase of a pair of goggles. Good for "winter coat", but bad for marketing decisions:

Implementing Analytics Using JavaScript 179

Internal Search Term Revenue

winter coat $157

How merchandising variables solve this problem

Cross-category merchandising variables, or "merchandising evars", let you assign the current value of an eVar to a product at the time a success event takes place. This value remains tied to that product, even if one or more new values are later set for that particular eVar.

If merchandising is enabled for the eVar in the previous example, the search term "goggles" is tied to the Fernie

Snow Goggles, and the search term "winter coat" is tied to the El Gordo Down Jacket. Merchandising variables allocate revenue at the product level, so each term receives credit for the amount of revenue for the product to which the term was associated:

Internal Search Term Revenue

winter coat goggles

$119

$38

Implementing a Merchandising Variable

Describes how to enable and implement a merchandising variable.

Enable a Merchandising Variable

Merchandising can be enabled for any custom eVar on the Admin Tools > Report Suites > Conversion Variables page (you no longer need to call Adobe):

Setting

Expire After

Merchandising

Description

Determines how long merchandising values should persist.

Product Syntax

: The value is set within s.products

Implementing Analytics Using JavaScript 180

Setting Description

Conversion Variable Syntax

: The value is set in the designated merchandising s.eVar

Merchandising

Binding Event

(Conversion variable syntax only)

Indicates when a product should be tied to the current merchandising category. Multiple events may be selected by holding down Ctrl and clicking on multiple items in the list.

Note: When "Product Syntax" is selected, you can not choose an event (it is disabled, but not grayed out).You can select an event only when the "Conversion Variable Syntax" is selected.

Implementing Using Product Syntax

When Product Syntax is enabled, the merchandising category is populated directly within the products variable, so selecting and setting a binding event is not required. This is the recommended method and should be used unless the value is not available to set in s.products

when the success event takes place.

• Syntax s.products="category;product;quantity;price;event_incrementer;eVarN=merch_category|eVarM=merch_category2"

• Example s.events="prodView" s.products=";Fernie Snow Goggles;;;;eVar1=goggles"

The value "goggles" for eVar1 is assigned to the product "Fernie Snow Goggles". All subsequent success events

(product adds, checkouts, purchases, and so on) that involve this product are credited to "goggles".

Implementing Using Conversion Variable Syntax

Conversion Variable Syntax should be used when the eVar value is not available to set in s.products

. This typically means that your page has no context of the merchandising channel or finding method. In these cases you must set the merchandising variable before you arrive at the product page, and the value persists until the binding event occurs.

When the binding event selected during configuration occurs, the persisted value of the eVar is associated with the product. For example, if prodView is specified as the binding event, the merchandising category is tied to the current product list only at the time the event occurs. Only subsequent binding events can update a merchandising eVar that has already been assigned to a product.

• Syntax

On the same or previous page before the binding event: s.eVar1="merchandising_category"

On the page where the binding event occurs: s.events="prodView" s.products="category;product"

• Example

Page 1 of the visit: s.eVar1="Outdoors:Ski Goggles"

Implementing Analytics Using JavaScript 181

Page 2 of the visit: s.events="prodView" s.products=";Fernie Snow Goggles"

The value "Outdoors:Ski Goggles" for eVar1 is assigned to the product "Fernie Snow Goggles". All subsequent success events (product adds, checkouts, purchases, and so on) that involve this product are credited to "goggles".

Additionally, the current value of the merchandising variable is tied to all subsequent products until one of the following conditions is met:

• eVar expires (based on the "Expire After" setting)

• The merchandising eVar is overwritten with a new value.

For more information, see "

Advanced Conversion Syntax Merchandising

" at analyticsdemystified.com

Instances on Merchandising Variables

Describes how instances are counted on merchandising variables.

Instances are not currently supported for merchandising variables. If you notice instances in a report containing a merchandising variable, it indicates that the eVar is being set in some locations outside of the products string and should not be considered as a true count of instances for the selected merchandising variable.

If you are using Conversion Variable Syntax, an instance is counted each time the variable is set. However, the instance is attributed to "None" unless the following occurs each time the variable is set:

• A binding event is set.

• The products variable is set.

• The merchandising eVar has a value.

For example, the following instance of eVar1 is allocated to "Outdoors:Ski Goggles": s.eVar1="Outdoors:Ski Goggles" s.events="prodView" s.products=";Fernie Snow Goggles"

However, in the next example, the instance of eVar1 is allocated to "None" since all conditions are not met when the eVar is set (there is no binding event and the products variable is not set):

Page 1 of the visit: s.eVar1="Outdoors:Ski Goggles"

Page 2 of the visit: s.events="prodView" s.products=";Fernie Snow Goggles"

Allocation to "None" occurs if you set a value for an eVar on a page where no binding event occurs, or if you set the eVar value in the products string without a binding event.

Note: The current functionality for counting instances on merchandising variables is being reviewed and is scheduled to change in an upcoming release.

The s.t() Function - Page Tracking

The s.t() function is what compiles all the variables defined on that page into an image request and sends it to our servers.

Implementing Analytics Using JavaScript 182

Properties of the Function

• Removing the s.t() call prevents any data from reaching Analytics. Multiple s.t() calls fires multiple image requests

(doubling the reported traffic on your site).

• If you wish to fire more than one image request on a single page load, using the s.tl() function is recommended.

• Triggering this function always increases pageviewsand always include the s.pageName variable.

Implementation

Upon generating code within the code manager, you are given the following at the bottom of the page code: var s_code=s.t();if(s_code)document.write(s_code)//--></script>

Each line of code has a specific purpose: var s_code=s.t();if(s_code)document.write(s_code)//-->

This line of code is what actually fires the Javascript function. The s_code variable and it's accompanying document.write method is for browsers that don't support image objects (Netscape browsers prior to version 3 and

Internet Explorer prior to version 4; estimated less than .5% of all internet users).

For any additional questions about the s.t() function, contact your organization's Account Manager. They can arrange a meeting with an Adobe Implementation Consultant, who can provide assistance.

The s.tl() Function - Link Tracking

File downloads and exit links can be automatically tracked based on parameters set in the AppMeasurement for

JavaScript file.

If needed, these types of links can be manually tracked using custom link code as explained below. In addition, custom link code can be used to track generic custom links that can be used for a variety of tracking and reporting needs.

s.tl() Parameter Reference

Variable

this

Description

The first argument should always be set either to this (default) or true. The argument refers to the object being clicked; when set to "this," it refers to the HREF property of the link.

If you are implementing link tracking on an object that has no HREF property, you should always set this argument to "true."

Because clicking a link often takes a visitor off the current page, a 500ms delay is used to ensure that an image request is sent to Adobe before the user leaves the page. This delay is only necessary when leaving the page, but is typically present when the s.tl() function is called. If you want to disable the delay, pass the keyword 'true' as the first parameter when calling the s.tl() function.

Implementing Analytics Using JavaScript 183

Variable

linkType

Description

s.tl(this,linkType,linkName, variableOverrides, doneAction) linkType has three possible values, depending on the type of link that you want to capture.

If the link is not a download or an exit link, you should choose the Custom links option.

Type

File Downloads

Exit Links

Custom Links

linkType value

'd'

'e'

'o' linkName variableOverrides

This can be any custom value, up to 100 characters. This determines how the link is displayed in the appropriate report.

(Optional, pass null if not using) This lets you change variable values for this single call, It is similar to other AppMeasurement libraries.

useForcedLinkTracking

This flag is used to disable forced link tracking for some browsers. Forced link tracking is enabled by default for FireFox 20+ and WebKit browsers.

Default Value

true

Example

s.useForcedLinkTracking = false forcedLinkTrackingTimeout

The maximum number of milliseconds to wait for tracking to finish before performing the

doneAction that was passed into s.tl

. This value specifies the maximum wait time. If the track link call completes before this timeout, the doneAction is executed immediately. If you notice that track link calls are not completing, you might need to increase this timeout.

Default Value

250

Example

s.forcedLinkTrackingTimeout = 500 doneAction

An optional parameter to specify a navigation action to execute after the track link call completes when useForcedLinkTracking

is enabled.

Syntax

s.tl(linkObject,linkType,linkName,variableOverrides,doneAction)

doneAction : (optional) Specifies the action to take after the link track call is sent or has timed out, based on the value specified by: s.forcedLinkTrackingTimeout

Implementing Analytics Using JavaScript 184

Variable Description

The doneAction variable can be the string navigate, which causes the method to set document.location

to the href attribute of linkObject. The doneAction variable can also be a function allowing for advanced customization.

If providing a value for doneAction in an anchor onClick event, you must return false after the s.tl

call to prevent the default browser navigation.

To mirror the default behavior and follow the URL specified by the href attribute, provide a string of navigate as the doneAction .

Optionally, you can provide your own function to handle the navigation event by passing this function as the doneAction.

Examples

<a href="..." onclick="s.tl(this,'o','MyLink',null,'navigate');return false">Click Here</a> <a href="#" onclick="s.tl(this,'o','MyLink',null,function(){if(confirm('Proceed?'))document.location=...});return

false">Click Here</a>

Example

The following example of an s.tl() function call uses the default 500 ms delay to ensure data is collected before leaving the page.

s.tl(this,'o','link name');

The following example disables the 500 ms delay, if the user is not going to leave the page, or whenever the object being clicked has no HREF.

s.tl(true,'o','link name');

The 500ms delay is a maximum delay. If the image requested returns in less than 500 ms, the delay stops immediately.

This allows the visitor to move onto the next page or next action within the page.

The following examples are for handling custom links on WebKit browsers:

<a href="..." onclick="s.tl(this,'o','MyLink',null,'navigate');return false">Click Here</a>

<a href="#" onclick="s.tl(this,'o','MyLink',null, function(){if(confirm('Proceed?'))document.location=...});return false">Click Here</a>

Note: Uses of custom link code are often very specific to your Web site and reporting needs. You can contact your Adobe Consultant or Customer Care before implementing custom link code to understand the possibilities available to you and how best to leverage this feature based on your business needs.

The basic code to track a link using custom link code is shown in the following example:

Note: The s_gi function must contain your report suite ID as a function parameter. Be sure to swap out rsid for your unique report suite ID.

Note: If the link name parameter is not defined, the URL of the link (determined from the "this" object) is used as the link name.

Analytics variables can be defined as part of custom link code.

Implementing Analytics Using JavaScript 185

Automatic Tracking of Exit Links and File Downloads

The JavaScript file can be configured to automatically track file downloads and exit links based on parameters that define file download file types and exit links.

The parameters that control automatic tracking are as follows: s.trackDownloadLinks=true s.trackExternalLinks=true s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,doc,pdf,xls" s.linkInternalFilters="javascript:,mysite.com,[more filters here]" s.linkLeaveQueryString=false

The parameters trackDownloadLinks and trackExternalLinks determine if automatic file download and exit link tracking are enabled. When enabled, any link with a file type matching one of the values in linkDownloadFileTypes is automatically tracked as a file download. Any link with a URL that does not contain one of the values in

linkInternalFilters is automatically tracked as an exit link.

In JavaScript H.25.4 (released February 2013), automatic exit link tracking was updated to always ignore links with

HREF

attributes that start with

, about:

, or javascript:

Example 1

The file types jpg

and aspx

are not included in linkDownloadFileTypes above, therefore no clicks on them are automatically tracked and reported as file downloads.

The parameter linkLeaveQueryString modifies the logic used to determine exit links. When linkLeaveQueryString=false, exit links are determined using only the domain, path, and file portion of the link URL. When linkLeaveQueryString=true, the query string portion of the link URL is also used to determine an exit link.

Example 2

With the following settings, the example below will be counted as an exit link:

//JS file s.linkInternalFilters="javascript:,mysite.com" s.linkLeaveQueryString=false

//HTML file

<a href='http://othersite.com/index.html?r=mysite.com'>Visit Other Site!</a>

Example 3

With the following settings, the link below is not counted as an exit link:

//JS file s.linkInternalFilters="javascript:,mysite.com" s.linkLeaveQueryString=true

//HTML

<a href='http://othersite.com/index.html?r=mysite.com'>Visit Other Site</a>

Note: A single link can be tracked only as a file download or exit link, with file download taking priority. If a link is both an exit link and file download based on the parameters linkDownloadFileTypes and linkInternalFilters, it is tracked and reported as a file download and not an exit link. The following table summarizes the automatic tracking of file downloads and exit links.

Implementing Analytics Using JavaScript 186

Manual Link Tracking Using Custom Link Code

Custom link code lets file downloads, exit links, and custom links be tracked in situations where automatic tracking is not sufficient or applicable.

Custom link code is typically implemented by adding an onClick event handler to a link or by adding code to an existing routine. It can be implemented from essentially any JavaScript event handler or function.

Link Tracking consists of calling the AppMeasurement for JavaScript function whenever the user performs actions that generate data you want to capture. This function, s.tl(), is either called directly in an event handler, such as

onClick or onChange, or from within a separate function. This s.tl() function has five arguments. The first three are required: s.tl(this,linkType,linkName, variableOverrides, doneAction)

Custom Link Tracking on FireFox and WebKit Browsers

JavaScript H.25 includes an update to ensure that link tracking completes successfully on WebKit browsers (Safari and Chrome). JavaScript H.26 includes an update to ensure that link tracking completes successfully on FireFox

20+.

After this update, download and exit links that are automatically tracked (determined by s.trackDownloadLinks

and s.trackExternalLinks

) are tracked successfully. If you are tracking custom links using manual JavaScript calls, you need to modify how these calls are made. For example, exit and download links are often tracked using code similar to the following:

Internet Explorer executes the track link call and open the new page. Other browsers might cancel execution of the track link call when the new page opens. This often prevents track link calls from completing.

To work around this behavior, H.25 (released July 2012) includes an overloaded track link method ( s.tl

) that forces browsers with this behavior to wait for the track link call to complete. This new method executes the track link call and handles the navigation event, instead of using the default browser action. This overloaded method requires an additional parameter, called doneAction, to specify the action to take when the link tracking call completes.

To use this new method, update calls to s.tl

with an additional doneAction parameter, similar to the following:

Passing navigate as the doneAction mirrors the default browser behavior and opens the URL specified by the href attribute when the tracking call completes.

In JavaScript H.25.4 (released February 2013), the following scope limitations were added to links tracked when useForcedLinkTracking

is enabled. The automatic forced link tracking applies only to:

•

<A>

and

<AREA>

tags.

• The tag must have an

HREF

attribute.

• The

HREF

can't start with

, about:

, or javascript:

• The

TARGET

attribute must not be set, or the

TARGET

needs to refer to the current window (

_self

_top

, or the value of window.name

Link Tracking Using an Image Request

Links can be tracked without calling the s.tl() function by constructing an image request.

Implementing Analytics Using JavaScript 187

Image requests are hard coded by adding the "pe" parameter to your image request src parameter as follows: pe=[type]

Where

[type]

is replaced with the type of link you want to track:

• lnk_d = download

• lnk_e = exit

• lnk_o = custom

Additionally, a link URL can be specified by passing the URL in the pev1 parameter: pev1=mylink.com

A link name can be specified by passing the name in the pev2 parameter: pev2=My%20Link

For example:

<img src="http://collectiondomain.112.2o7.net/b/ss/reportsuite/1/H.25.3--NS/0?pe=lnk_e&pev1=othersite.com&pev2=Offsite%20Link"

width="1" height="1" border="0" />

Setting Additional Variables for File Downloads, Exit Links, and Custom Links

Two parameters (linkTrackVars and linkTrackEvents) control which Analytics variables are set for file downloads, exit links, and custom links.

They are, by default, set within the JS file as follows: s.linkTrackVars="None" s.linkTrackEvents="None"

The linkTrackVars parameter should include each variable that you want to track with every file download, exit link, and custom link. The linkTrackEvents parameter should include each event you want to track with every file download, exit link, and custom link. When one of these link types occur, the current value of each variable identified is tracked.

For example to track prop1, eVar1, and event1 with every file download, exit link, and custom link, use the following settings within the global JS file: s.linkTrackVars="prop1,eVar1,events" s.linkTrackEvents="event1"

Note: The variable pageName cannot be set for a file download, exit link, or custom link, because each of the link types is not a page view and does not have an associated page name.

Note: If linkTrackVars (or linkTrackEvents) is null (or an empty string), all Analytics variables (or events) that are defined for the current page are tracked. This most likely inflates instances of each variable inadvertently and should be avoided.

Best Practices

The settings for linkTrackVars and linkTrackEvents within the JS file affect every file download, exit link, and custom link. Instances of each variable and event can be inflated in situations where the variable (or event) applies to the current page, but not the specific file download, exit link, or custom link.

Implementing Analytics Using JavaScript 188

To ensure that the proper variables are set with custom link code, Adobe recommends setting linkTrackVars and

linkTrackEvents within the custom link code, as follows:

<a href="index.html" onClick=" var s=s_gi('rsid'); s.linkTrackVars='prop1,prop2,eVar1,eVar2,events'; s.linkTrackEvents='event1'; s.prop1='Custom Property of Link'; s.events='event1'; s.tl(this,'o','Link Name');

">My Page

The values of linkTrackVars and linkTrackEvents override the settings in the JS file and ensure only the variables and events specified in the custom link code are set for the specific link.

Note: In the above example, the value for prop1 is set within the custom link code itself. The value of prop2 comes from the current value of the variable as set on the page.

Using Function Calls with Custom Link Code

Due to the complex nature of custom link code, you can consolidate the code into a self-contained JavaScript function

(defined on the page or in a linked JavaScript file) and make calls to the function within the onClick handler.

For example, you could insert the following two functions in your

AppMeasurement.js

file, just below the s_doPlugins()

function, and then use them throughout your site:

/* Set Click Interaction values (with timeout – H25 code and higher*/ function trackClickInteraction(name){

var s=s_gi('rsid');

s.linkTrackVars='prop42,prop35';

s.prop42=name;

s.prop35=s.pageName;

s.tl(true,'o','track interaction',null,'navigate');

}

/* Set Click Interaction values (without timeout – pre H25 code*/ function trackClickInteraction(name){

var s=s_gi('rsid');

s.linkTrackVars='prop42,prop35';

s.prop42=name;

s.prop35=s.pageName;

s.tl(true,'o','track interaction');

}

Note: If needed, you can pass the link type and link name as additional parameters for the JavaScript function.

You can use code similar to the following to call these functions:

Avoiding Duplicate Link Counts

It is possible for the link to be double-counted in situations where the link is normally captured by automatic file download or exit link tracking.

Implementing Analytics Using JavaScript 189

For example, if you are tracking PDF downloads automatically, the following code results in a duplicate download count: function trackDownload(obj) {

var s=s_gi('rsid');

s.linkTrackVars='None';

s.linkTrackEvents='None';

s.tl(obj,'d','PDF Document');

}

To ensure link double counting does not occur, use the following modified JavaScript function:

var s=s_gi('rsid');

s.linkTrackVars='None';

s.linkTrackEvents='None';

var lt=obj.href!=null?s.lt(obj.href):"";

if (lt=="") { s.tl(obj,'d','PDF Document'); }

}

The last two lines of the code above modify the behavior of custom link code so only the automatic tracking behavior occurs, eliminating any possible double counting.

Popup Windows with useForcedLinkTracking

When useForcedLinkTracking

is enabled, AppMeasurement overrides the default link behavior on some browsers to prevent the track link call from being canceled when the new page opens. AppMeasurement executes the track link call and handles the navigation event manually, instead of using the default browser action.

When tracking some links that open a popup window, the Chrome built-in popup blocker might prevent

AppMeasurement from opening a popup window that would normally be allowed. To avoid this, add a target="_blank"

attribute to calls that open a window:

This allows the link to be tracked and the popup to load as expected.

Links from URL Shorteners

Links from URL shortener services (such as bit.ly) are typically not tracked as page views or as referrers. These services return 301/302 redirects with the full URL to the web browser, which then sends a new, separate request to the full URL. The original referrer is preserved since the shortener is no longer in the loop, and there isn't an indication on the request that a redirect service was used to get the URL.

Due to the variety of services available, we recommending testing the specific scenarios in use on your site to determine the redirect mechanism used by the service.

Link Tracking Variables in doPlugins

To help manage link tracking, these following variables are populated before the doPlugins

function runs.

Inside of doPlugins

, you can use the following values to modify link tracking behavior. For example, you can abort tracking, or add additional variables to tracking requests.

Implementing Analytics Using JavaScript 190

Variable

linkType linkName linkURL linkObject

Description Impact

Contains the automatically determined link type, if any. Can be set to one of the following:

If set with linkURL

or linkName

, a server call is sent as a download, custom, or exit link.

• d (download)

• e (exit)

• o (custom/other)

This is the pe

parameter in the image request.

The name that will appear in the custom, download or exit link report. Truncated at 100 characters. Can be set to any string.

If set with linkType

, an image request will be sent as a download, custom or exit link

This is the pev2

parameter in the image request.

The URL of the link, which acts as the name if a linkName does not exist. Can be set to any URL string.

This is the pev1

parameter in the image request.

If set with linkType

, an image request will be sent as a download, custom or exit link

The clicked object for reference. This is read-only.

No direct impact on measurement.

Example

function s_doPlugins(s) {

if (s.linkType == "d" && s.linkURL.indexOf(".aspx?f=") {

//special tracking for .aspx file download script

s.eVar11 = s.linkURL.substring(s.linkURL.lastIndexOf("?f=") + 3, s.linkURL.length);

}

else if (s.linkType == "o" ) {

// note: linkType is set to "o" only if you make a custom call

// to s.tl() and set the link type to "o". Automatically tracked

// links are set to "d" or "e" only.

s.eVar10 = s.LinkURL;

}

Validating File Downloads, Exit Links, and Custom Links

To fully validate download, exit, and custom links, Adobe recommends using a packet analyzer to examine the links in real-time.

File downloads, exit links, and custom links are not page views, so the DigitalPulse Debugger tool cannot be used to verify parameters and variable settings. You must use a

Packet Analyzers

to view track link data.

The s.sa() Function

The s.sa() function lets you dynamically change a report suite at any time on the page, before or after an image request fires.

If your organization wants to send data to different report suites without a page reload, using this function is strongly recommended.

Implementing Analytics Using JavaScript 191

This information is suited for advanced users who are well-versed in both reporting and implementation. Do not attempt to make any edits to your implementation without complete knowledge of its consequences. If you require implementation changes, contact your organization's Account Manager.

Properties of the Function

Setting this function takes all previously defined variables and lets them be used in a different report suite.

Implementation Examples

Sending video data to one report suite while sending the rest to another:

// Set in the core JS file by default var s=s_gi('prodrsid');

// Define this when a user interacts with a video s.sa('videorsid'); s.t(); // Sends an image request

Using s.sa() and multi-suite tagging:

// Set in the core JS file by default var s=s_gi('rsid1');

// Call the function when you wish to change report suites s.sa('rsid1,rsid2'); s.t();

The s.clearVars() Function

clears the following values from the instance object.

• props

• eVars

• hier

• list

• events

• eventList

• products

• productsList

• channel

• purchaseID

• transactionID

• state

• zip

• campaign

For example: s.clearVars()

Note:

clearVars()

is included in About AppMeasurement for JavaScript , it is not available in H code and

previous.

Implementing Analytics Using JavaScript 192

The s_gi() Function

The s_gi()

function is used to create or find your instance of AppMeasurement by report suite ID. Internally,

AppMeasurement keeps track of every instance created, and s_gi()

returns the existing instance for a report suite if one exists. If an instance does not exist, a new instance is created and returned.

We recommend calling s_gi()

before setting variables and making tracking calls throughout your page code. This ensures that the correct object is used to make the tracking call in the case that the s variable is inadvertently overwritten.

Using Multiple Report Suites

The object returned varies based on the report suite ID(s) passed. For example, if you make the following initial call to s_gi()

: var s=s_gi('rsid1,rsid2')

The following table outlines what is returned by subsequent calls:

Subsequent Call to s_gi

s=s_gi('rsid1,rsid2') s=s_gi('rsid1') s=s_gi('rsid1,rsid3') s=s_gi('rsid3')

Description of Object Returned

The same object referenced earlier.

A copy of the object created earlier, but not the original.

A new, empty object, with no config variables set (e.g. linkTrackVars is empty, as is linkDownloadFileTypes).

Util.cookieRead

Gets the value for a cookie.

Syntax:

s.Util.cookieRead(key)

Parameters:

Parameter

key

Description

(required) key to write value for in cookies.

Returns:

Cookie value or an empty string if the cookie is not found.

Example:

var myCookie = s.Util.cookieRead("my_cookie");

Util.cookieWrite

Writes a value to a cookie.

Implementing Analytics Using JavaScript

Syntax:

s.Util.cookieWrite(key, value [,expire])

Parameters:

Parameter

key value expire

Description

(required) key to write value for in cookies.

(optional) value to write to cookies.

(optional) Date object containing the expiration date for the cookie. Default is to use a session cookie.

Returns:

Example:

//set a cookie with an expiration 6 months from now var date = new Date(); date.setMonth(date.getMonth() + 6); var success = s.Util.cookieWrite("my_cookie", "my_value", date);

193

Util.getQueryParam

Returns the value of a specified query string parameter, if found in the current page URL or in the provided string.

Because important data (such as campaign tracking codes, internal search keywords, etc.) is available in the query string on a page, getQueryParam helps capture the data into Analytics variables.

This utility replaces the

getQueryParam

plug-in.

Syntax:

s.Util.getQueryParam(key, [url], [delim])

Note: The syntax for the utility differs from the syntax for the plug-in.

Parameters:

Parameter

key url delim

Description

(required) The name of the query string parameter that you want to get. This parameter is case sensitive.

(optional) Default url is s.pageURL

or window.location

. Specifying a value for this parameter overrides the URL from which the query parameter is retrieved to the one specified.

(optional) Parameter delimiter in the URL. Default delimiter is "&". This lets you to specify an alternate query-string delimiter, such as ";".

Returns:

This function returns the value of the query-string variable or an empty string if it's not found.

Example:

s.doPlugins = function(s) {

s.campaign = s.Util.getQueryParam("cid");

};

Implementing Analytics Using JavaScript 194

Offline Tracking

The following variables and functions let you store measurement calls when the application is offline.

Note: To enable offline tracking, your report suite must be timestamp-enabled. If timestamps are enabled on your report suite, your trackOffline

configuration property must be true. if your report suite is not timestamp enabled, your trackOffline

configuration property must be false. If this is not configured correctly, data will

be lost. If you are not sure if a report suite is timestamp enabled, contact Customer Care

When enabled, Offline AppMeasurement behaves in the following way:

• The application sends a server call, but the data transmission fails.

• AppMeasurement generates a timestamp for the current hit.

• AppMeasurement buffers the hit data, and backs up buffered hit data to persistent storage to prevent data loss.

At each subsequent hit, or at the interval defined by offlineThrottleDelay

, AppMeasurement attempts to send the buffered hit data, maintaining the original hit order. If the data transmission fails, it continues to buffer the hit data (This continues while the device is offline).

Property or Method Description

trackOffline Default: false

Enables or disables offline tracking for the measurement library.

Examples:

s.trackOffline=true; offlineLimit offlineThrottleDelay forceOnline forceOffline

Default: no limit

Maximum number of offline hits stored in the queue.

Examples:

s.offlineHitLimit=100;

Default: 0

Specifies a cadence (or delay), in milliseconds, for sending buffered hit data when

AppMeasurement detects an active network connection. Doing so mitigates the performance impact of sending multiple hits on the application.

For example, if offlineThrottleDelay=1000, and it takes 300ms to send the hit data,

AppMeasurement waits 700ms before sending the next buffered hit.

s.offlineThrottleDelay=1000;

Manually set the online or offline state of the measurement object. The library automatically detects when the device is offline or online, so these methods are needed only if you want to force measurement offline.

forceOnline

is used only to return to the online state after manually going offline.

When measurement is offline:

Implementing Analytics Using JavaScript

Property or Method Description

• If trackOffline

is true: hits are stored until measurement is online.

• If trackOffline

is false: hits are discarded.

Examples:

s.forceOffline(); s.forceOnline();

195

Data Collection

Data Collection Query Parameters

The following tables lists the query parameter that contains the value for each analytics variable that is sent to data collection.

This information can be used when debugging using

Packet Analyzers

, when manually constructing image requests,

or when using

Dynamic Variables

Parameter

aamlh aamb aid

AQB

AQE bh bw c

Analytics Variable

None

Report Populated

None

Description

Audience Manager Location

Hint (used in Marketing

Cloud Shared Profile integration)

Audience Manager Blob

(used in Marketing Cloud

Shared Profile integration)

Analytics visitor ID

Indicates the beginning of an image request.

Indicates the end of an image request, meaning the request was not truncated.

Visitor Profile | Technology

| Browser Height

Browser window height (in pixels)

Visitor Profile | Technology

| Browser Width

Browser window width (in pixels)

Visitor Profile | Technology

| Monitor Color Depths

Color quality (in bits) c.[key] s.contextData

None Key-values pairs are specified in one of the following formats:

<my.a>red</my.a> or:

ch ct ce cl

j k l1-l3 pccr pe pev1 pev2 mid ndh ns oid ot p pageName (or gn) pageType (or gt)

Implementing Analytics Using JavaScript

Parameter

Analytics Variable

None

None s.list1-s.list3

None

None s.visitorNameSpace

s.objectID

None

None s.pageName

s.pageType

None s.linkType

None

197

Report Populated Description

Visitor Profile | Visitor Home

Page

Indicates if current page is browser's home page (Y or

N; can only populate in IE browsers)

Visitor Profile | Technology

| Javascript Version

Shows the current

Javascript version installed

(generally 1.x)

Visitor Profile | Technology

| Cookies

Are cookies supported in the browser (Y, N or U)

Custom Conversion

None

A delimited list of values that are passed into a variable, then reported as individual line items for reporting.

Marketing Cloud Visitor ID

None

Indicates whether the image request originated from JS file (1 or 0)

Specifies what domain the cookies are set on

Site Content | Links |

ClickMap

Site Content | Links |

ClickMap

Object identifier for last page; used in ClickMap

Object tag name for last page; used in ClickMap

Visitor Profile | Technology

| Netscape Plug-Ins

Site Content | Pages

Semicolon delimited browser plug-in names

The page's designated name in reporting

Site Content | Pages Not

Foun

None

Indicates whether it is a 404 page or not (Either 'error' or blank)

Only occurs for new visitors; prevents infinite redirects

(Always true)

Determines the type of custom link hit fired

Site Content | Links | Exit

Links, File Downloads,

Custom Links

Site Content | Links | Exit

Links, File Downloads,

Custom Links

URL the custom link hit occurred on

Site Content | Links | Exit

Links, File Downloads,

Custom Links

Custom link friendly name

Implementing Analytics Using JavaScript

Parameter

pev3 t r pf pid pidt products (or pl) purchaseID (or pi) s server (or sv) state ts v

198

Analytics Variable

None

None s.products

Report Populated

All video reports

None

Site Content | Links |

ClickMap

Site Content | Links |

ClickMap

Products | Products

Description

Used to track milestones in legacy video reporting; deprecated with v15

For Adobe use only. Do not alter.

Page identifier for last page; used in ClickMap

Page identifier type for last page; used in ClickMap

Products variable used in conversion reporting s.purchaseID

s.referrer

None s.server

None Used to deduplicate purchases, preventing revenue inflation

Referring URL All traffic sources reports

Visitor Profile | Technology

| Monitor Resolutions

Screen resolution (width x height)

Site Content | Servers The page's server; used in traffic reporting s.state

Visitor Profile | Visitor State Specifies the state as defined by the variable.

(automatic, sent with every hit that does not have a custom timestamp)

None

The t

parameter is in the following format: dd/mm/yyyy hh:mm:ss D

OFFSET

Where D is a number in the range

0-6

specifying the day of the week, and

OFFSET

represents: offset from GMT in hours * 60 * - 1

For example:

23/09/2016 14:00:00 1

420 timestamp

None

The custom timestamp calculated and sent in with the hit. Typically used for offline tracking.

Visitor Profile | Technology

| Java

Java enabled (Y or N)

Implementing Analytics Using JavaScript

Parameter

v0 v1-v75

Analytics Variable

s.campaign

s.eVar1-s.eVar75

vid vmk vvp xact s.visitorID

s.vmk

s.variableProvider

s.transactionID

zip s.zip

/5/ (for mobile protocol) or

/1/ (for non-mobile protocol) in the image request URL.

None

199

Report Populated

Campaigns | Tracking

Codes

All Custom Conversion reports

None

Visitor Profile | Visitor

ZIP/Postal Code

None

Description

The campaign variable used in conversion reporting

Conversion variables used in custom conversion reporting

The visitor's unique ID as set in the

visitorID

variable.

Visitor migration key; used to migrate from third-party to first-party cookies.

Deprecated.

Used in Genesis integrations

The transaction ID used to link online data to offline data

Determines the zip code as defined by the variable

Controls the order in which cookies and other methods are used to identify visitors.

Data Collection HTTP Headers

HTTP request and response headers are used to collect additional data beyond what is collected by AppMeasurement.

This section describes the headers used during data collection.

HTTP Request Headers

Header

Usage

Reading cookies previously created by our data collection servers.

As of 2014, Adobe servers will discard all cookies that accompany a server call except those set by Adobe. See

Cookies Used in the Marketing Cloud

for the full list of Adobe's cookies.

User-Agent

X-Device-User-Agent

Used for browser, operating system, and mobile device detection.

Used as an alternative to User-Agent for correct browser, operating system, and mobile device detection for some browsers like OperaMini.

X-Original-User-Agent

X-OperaMini-Phone-UA

Used as an alternative to User-Agent for correct browser, operating system, and mobile device detection for some browsers like OperaMini.

Implementing Analytics Using JavaScript 200

X-Skyfire-Phone

X-Bolt-Phone-UA

UA-OS

UA-Pixels

UA-Color

X-moz

X-Purpose

Referrer

X-Forwarded-For

Used as an alternative to User-Agent for correct browser, operating system, and mobile device detection for some browsers like OperaMini.

Used as an alternative was to identify the operating system.

Used as an alternate source for the screen resolution of the client screen.

Used as an alternate source for the color depth of the client screen.

Detecting that the data collection request was made as part of pre-fetching a webpage.

Detecting that the data collection request was made as the browser was showing a preview of a webpage.

Used to identify the image formats supported by the browser so we know if we need to send back a GIF or WBMP image.

Used as a fallback for getting information about the page URL the data collection request was made from when it wasn't passed in on the query-string or when it's different from the value in the query-string.

Used to find the correct IP address for the client that made the data collection request.

The IP address is used to generate geographic region, mobile carrier, and other reports.

Note: Implementations using dynamic variables have the option of reading in other HTTP request headers not listed above.

HTTP Response Headers

Header Usage

Access-Control-Allow-Origin Used to enable support for cross-origin resource sharing style data collection requests to our servers.

Expires Browser caching control.

Last-Modified

Cache-Control

Pragma

ETag

Browser caching control.

Vary

P3P

Status

Reason

Location

Content-Type

Content-Length

Browser caching control.

Provides the default or custom P3P policy for the data collection request.

Contains "SUCCESS" or "FAILURE" status for a no content request. Used only when the request specifies that no content should be returned.

Contains the reason for the failure status of a no content request. Used only when the request specifies that no content should be returned.

Used to redirect the client making the data collection request off to a different URL. An example is our cookie handshake to detect the ability to set the visitor ID cookie.

Specifies the type of content sent back to the client (GIF, text, Javascript, etc).

Specifies the size of the content sent back to the client.

Implementing Analytics Using JavaScript 201

Note: Other HTTP headers may be set in the response for internal status monitoring. Some of these headers might be returned to the browser, but it is not necessary that they receive them.

Variable Overrides

Variable overrides let you change a variable value for a single track or track link call.

To override variables, create a new object, assign variable values, and pass this object as the first parameter to s.t()

, or as the fourth parameter to s.tl()

: s.eVar1="one"; s.eVar2="two"; s.eVar3="three"; overrides = new Object(); overrides.eVar1="1_one"; overrides.eVar2=""; s.t(overrides);

// values passed: eVar1="1_one", eVar2="", eVar3="three" s.linkTrackVars="eVar1,eVar2,eVar3,events"; s.eVar1="one"; s.eVar2="two"; s.eVar3="three"; overrides = new Object(); overrides.eVar1="1_one"; overrides.eVar2=""; s.tl(this,'e','AnotherSite',overrides,'navigate')

// values passed: eVar1="1_one", eVar2="", eVar3="three"

Report Suite IDs - Dynamic Accounts

The

.js

file can be configured to automatically select a report suite ID. The

.js

file automatically sends the image request to the report suite based on the URL. For example, if the URL is www.mysite.com

, the image request is automatically sent to report suite A. If the URL is www.mysite1.com

, the image request is automatically sent to report suite B.

These strings can be found within any of the following:

• Host/domain (default setting)

• Path

• Query String

• Host/domain and Path

• Path and Query String

• Full URL

For more information on configuring Analytics to automatically select a Report Suite ID, contact Adobe Live Support.

Defining the URL Segment to Match

Given the following sample URL, the portions of the URL are shown below, along with the s.dynamicAccountMatch variable that must be set. (The default - if s.dynamicAccountMatch is not defined - is to search the Host/Domain

Name only).

Sample URL: http://www.client.com/directory1/directory2/filename.html?param1=1234&param2=4321

Implementing Analytics Using JavaScript 202

Portion

Host/Domain Name

Path

Query String

Host/Domain and Path

Path and Query String

URL

Portion

Host/Domain Name

Path

Query String

Host/Domain and Path

Path and Query String

URL

Example (from above)

www.client.com

directory1/directory2/filename.html

param1=1234&param2=4321 www.client.com/directory1/directory2/filename.html

directory1/directory2/filename.html?param1=1234&param2=4321 http://www.client.com/directory1/directory2/filename.html?param1=1234&param2=4321 s.dynamicAccountmatch

Undefined window.location.pathname

(window.location.search?window.location.search:"?") window.location.host+window.location.pathname

window.location.pathname+(window.location.search?window.location.search:"?") window.location.href

Consider the following example:

• s.dynamicAccountSelection=true

• s.dynamicAccountList="devreportsuite1=qa.client.com;reportsuite2=clientdirectory;reportsuite1=client.com"

• s.dynamicAccountMatch=window.location.host+window.location.pathname

Multiple Rules

If multiple rules are selected (see example above), the rules are executed from left to right. The rules stop as soon as a match is made, as shown below (with the given set of rules).

• s.dynamicAccountSelection=true

• s.dynamicAccountList="devreportsuite1=qa.client.com;reportsuite1=client.com"

The code first checks to determine if "qa.client.com" exists within the Host/Domain Name. If so, the report suite

"devreportsuite1" is selected, and the match stops. Separate multiple rules with semi-colons.

Default Report Suite

The s_account variable can be set first, and acts as a default value in case any of the specified strings cannot be found. Below is an example: var s_account="defaultreportsuiteid" s.dynamicAccountSelection=true s.dynamicAccountList="devreportsuite1=qa.client.com;reportsuite1=client.com"

In the case above, if the host/domain name did not contain either "qa.client.com" or "client.com," the report suite

"defaultreportsuiteid" would be used.

Common Errors

Common errors in dynamic accounts are described in the following sections.

Implementing Analytics Using JavaScript 203

Hard Coded Account

If the desire is to always send data to a specific report suite, set s_dynamicAccountSelection to false (alternately, the variables may be removed altogether: var s_account="defaultreportsuiteid"

REMOVE: s.dynamicAccountSelection=true

REMOVE: s.dynamicAccountList="devreportsuite1=qa.client.com;reportsuite1=client.com"

In the case above, defaultreportsuiteid is always used after the other two lines are removed.

Placement of Code

Defining s_account after the lines of code does not override the dynamic account selection, as shown below.

var s_account="defaultreportsuiteid" s.dynamicAccountSelection=true s.dynamicAccountList="devreportsuite1=qa.client.com;reportsuite1=client.com" s_account="anotherreportsuiteid"

In the example above, the account "anotherreportsuiteid" overrides "defaultreportsuiteid," but does not override any matches that occur in s.dynamicAccountList. The function that evaluates s.dynamicAccountList is actually executed much later in the .JS file.

Multi-Suite Tagging

Multi-suite tagging may be used in conjunction with dynamic account selection, as shown below.

s.dynamicAccountSelection=true s.dynamicAccountList="suiteid1,suiteid2=client.com"

Dynamic Account Match

Do not put the dynamic account match variables in quotes. The options are displayed below.

Host/Domain Name

Query String

Host/Domain and Path

Path and Query String

Full URL

None s.dynamicAccountMatch=(window.location.search?window.location.search:"?") s.dynamicAccountMatch=window.location.host+window.lcation.pathname

s.dynamicAccountMatch=window.location.pathname+(window.location.search?window.location.search""?") s.dynamicAccountMatch=window.location.href

Collecting Data From Form Elements

You can capture the values of form elements, such as radio button and checkbox items, into reports. This helps you analyze the most popular choices in your online forms.

For example, if you had a radio button letting the user specify his or her favorite genre of music (such as rock, rap, classical, or jazz), you could capture this response in a variable to determine the overall music preferences of your user base.

The best way to capture this data depends on how your forms are processed. It also depends on whether the form selections you want to capture are available in the query string on the page following the form submission. Examples in this article are given in PHP. However, you can adapt these concepts to another language, depending on your server environment.

Implementing Analytics Using JavaScript 204

GET Method

If your form uses a GET method to submit data, you have access to the desired data in the query string of the URL on the page following form submission. You can use the getQueryParam plug-in to capture this data out of the query string automatically and place it into the variable of your choosing.

POST Method

If your form uses a POST method to submit data (which is more common), you have the results for each specific form element available to you in the $_POST superglobal. To capture this in a variable, you want to determine the form element name in question. Using the music genre example mentioned before, part of the form element in question look like this:

This radio button belongs to the "music_genre" form element. You then have access to the user's selected value by using $_POST['music_genre']. This can be written to a variable on the page following the form submission: s.eVar1="<?=$_POST['music_genre'];?>"

The eVar1 variable receives a copy of whatever value was submitted to your server through the form, as specified in the value= property.

If you need additional information regarding this custom implementation method, contact your organization's Account

Manager. They can arrange a meeting with one of our Implementation Consultants to provide the help you need.

Tracking Across Different Implementation Types

This information is intended for advanced users who are well-versed in both reporting and implementation. Do not attempt to edit your implementation without understanding the consequences. If you require implementation changes, contact your organization's Account Manager.

If you use more than one type of implementation (such as JavaScript and hardcoded image requests), ensure that the following variables are specified and match each other:

• s_account

• s.visitorNamespace

• s.trackingServer

• s.trackingServerSecure (if using SSL)

If each of these do not match across implementations, users may be tracked as separate visitors.

Implementation Guidelines

Following these guidelines results in using the same cookie domains, which lets visits be tracked between various types of implementations.

• RSID: The report suite ID

• VNS: Visitor name space, the subdomain of

2o7.net

or omtrdc.net

used to store the visitor ID cookie

• COOKIEDOMAIN: Your VNS + trackingServer. Depending on your data center and RDC configuration, these can greatly vary. See

Correctly populate the trackingServer and trackingServerSecure variable

contact Client Care

if you are unsure about you data collection domain.

Implementing Analytics Using JavaScript 205

Javascript:

var s_account="RSID" s.visitorNamespace="VNS" s.trackingServer="VNS.COOKIEDOMAIN.net"

Hardcoded image request:

AppMeasurement:

var s_account="RSID" s.visitorNamespace="VNS" s.trackingServer="VNS.COOKIEDOMAIN.net"

Hardcoded image request:

<img border="0" alt="" src="https://VNS.COOKIEDOMAIN.net/b/ss/RSID/5?ns=VNS" width="1" height="1"

<!-- Note that the visitor namespace is defined twice in hardcoded image requests; once in the

http subdomain, and another using the ns= query string parameter! -->

If using a first-party cookie implementation,

VNS.COOKIEDOMAIN.net

can be replaced with the first-party cookie domain used. For example, first-party cookies on adobe.com

would be replaced with something similar to metrics.adobe.com

Implementation Example

Using adobe.com as an example, the implementations described here reference the same visid cookie.

Javascript:

var s_account="omniturecom" s.visitorNamespace="omniture" s.trackingServer="omniture.112.2o7.net"

Hardcoded image request:

Appmeasurement:

s.account="omniturecom"; s.visitorNamespace="omniture"; s.trackingServer="omniture.112.2o7.net";

And if first-party cookies are utilized:

Javascript:

var s_account="omniturecom" s.visitorNamespace"omniture" s.trackingServer="metrics.omniture.com"

Hardcoded image request:

<img border="0" alt="" src="https://metrics.omniture.com/b/ss/omniturecom/5" width="1" height="1"

Appmeasurement:

s.account="omniturecom"; s.visitorNamespace="omniture"; s.trackingServer="metrics.omniture.com";

AJAX-Tracking Rich Media Applications

AJAX is an emerging concept in web design that uses multiple technologies to create and manage dynamic content on Web pages.

Implementing Analytics Using JavaScript 206

The need to track user interaction with AJAX and other rich media applications is paramount to analytics success and realization of the return on investment in the Web design. The focus of this white paper is to provide recommendations for tracking rich Internet applications, specifically those that use AJAX.

Rich Internet Applications (RIA)

Rich Internet Applications (RIAs) are changing the face of the Web. They bridge the gap between the promise of on-demand technologies for the masses and realistic user experiences. RIAs have been maturing for years. The biggest leaps forward have occurred with wide-scale adoption of browsers, which support the underlying technologies that power these applications. While RIA has many forms and supporting technologies, the most common, and perhaps most widely adopted, are AJAX and Flash. It is important to understand that the technology is not what defines an RIA, but its usability and application.

What to Track

One of the most commonly asked questions with RIA is how to track micro-level activity separate from macro-level activity, and when it is appropriate to do either. For example, say you have an application that allows customers to uniquely configure a product. The application may have significant steps the users are exposed to. Are these steps considered page views? In addition, there are micro-level activities within each step. Should these activities be tracked as page views?

What if you want to understand the flow between activities, or which features get the most activity? The trouble with

RIA is that each application is unique. They are designed to mimic realistic actions, and since actions are relative to the situation, the possibilities are endless. However, most applications have a few major components: milestone steps, features, and micro-level actions within features. So, while each application requires some consideration as to what specifically should be measured, there are some generalizations that can be applied to RIA tracking.

Macro-Level Activity

Macro-level activity usually constitutes the loading of the application. This provides information on visits, visitors, instances, value to future actions, and so forth. It can, and should, also represent major steps in the process. A good rule of thumb is that if an RIA action changes the application more than 50% (or whatever is considered significantly changing the user experience or content), then it is macro-level, and should be tracked as a page view.

Micro-Level Activity

Micro-level activity includes any changes less than 50% (or not considered as significantly changing the user experience or content). Toggling between color selections, for instance, would be considered micro-level activity.

Adobe recommends that micro-level tracking be related to features. For example, in the case of toggling between colors, is it really important to understand which colors were considered? Or is it more important to know that the color selection feature was used? Perhaps both are important, and if so, capture both, but when measuring the effectiveness of RIA, consider the feature level activity as being more valuable.

All micro-level activity should be tracked as custom links with specifics measured through associated traffic variables

(props and eVars if the use needs to be measured against success events). This ensures that page views are not inflated by micro-level activity, and allows for path analysis through the traffic variable.

Implementing Analytics Using JavaScript 207

What to Analyze

It is important to understand how effectively your RIA is driving success. Success is most commonly measured through conversions. A macro-level analysis provides insight into RIA effectiveness as a whole. Micro-level analysis may provide insight into which features help drive conversion.

You should measure efficiency of your RIA. This is an analysis of micro-level activity relative to the RIA macro metrics. Do users go through more steps than necessary to arrive at the same goal? Analysis metrics might include visits/features activity; page views/feature activity, visitors/feature activity, and so forth.

Conduct analysis on path flow and fall out. Are users avoiding the RIA and finding another path to the goal? Run fallout reports built around the site and RIA flow. Run path analysis from landing pages to gauge the true traffic patterns. Look at barriers and incentives to guide users toward the goal.

Suggested Metrics

• RIA Visits

• RIA Visitors

• RIA Page Views

• RIA Feature Activity (Custom Links) measure click activity by feature

Suggested Analysis

• RIA Feature Activity / RIA Page Views

• RIA Feature Activity / RIA Visits -

• RIA Page Views / Success Metric - Conversion Ratio: measures application effectiveness

• Total RIA Activity / Success Metric - Conversion Ratio: measures application efficiency

• Feature RIA Activity / Success Metric - Conversion Ratio: measures application feature efficiency

• Path Flow to and from RIA

• Fallout Rates through RIA conversion process

Implementing with AJAX

Implementing with AJAX is exactly like deploying code on a standard HTML page.

The business has questions that need answers, the needs are assessed and variables assigned. The design is then applied and deployed. These concepts should be familiar if you have already been through the initial stages of implementation.

Designing the Solution

The difference when throwing AJAX into the mix is first understanding the level of detail that needs to be gathered.

The potential of content changing on the page (macro-level) or tracking attributes of the application (micro-level) determines which variables need to be set and which method of sending data to Adobe works best.

Deploying the Code

There are two functions in the JavaScript code that allow you to send data. There are some distinct guidelines that should be followed to know which method should be used to send data.

Collecting Macro-Data (Page)

The t()

function in the Adobe code sends a standard format image request, incrementing total site page views. All

Adobe variables that have been assigned values send data. The primary focus of using this function within RIAs revolves around the value of the pageName variable. You should use this function when:

Implementing Analytics Using JavaScript 208

• The new content is considered a page view for the site or is considered moving from one page to another.

• The content of the page changes more than 50% (or whatever is considered significantly changing the user experience or content).

• The page path must be tracked for each user interaction with the RIA.

Sending Macro-Data (Page)

If an image request was previously made on the same page, you must first clear the values of the previously-set variables. Use the clearVars()

funtion in AppMeasurement for JavaScript, or write a simple JavaScript function to clear the variables if you are using H code. Set the values appropriate for the changed content, namely the pageName variable. After the variables are set call the t() function.

Example

Note: Before you call s.t()

, you must clear any values on the s object that you do not want to persist. if you are using AppMeasurement for JavaScript, you can call s.clearVars()

. If you are using H code, write a simple routine to set variables to an empty string.

s.clearVars(); s.pageName="New Page" s.prop1="some value" void(s.t());

The following example shows a tracking call in the done

callback of the JQuery

.ajax

function:

$.ajax({

url: "test.html",

dataType: "html"

})

.done(function( response ) {

$( "#content" ).html( response );

s.clearVars();

s.pageName = $( "h1:first" ).text();

s.t();

});

Collecting Micro-Data (Link)

The tl()

function does not send the pageName variable and is selective in the other variables that are sent. Because of this restrictive design, it is well-suited for tracking micro-level statistics such as button clicks, link clicks, scrolling, and other similar events. You should use this function when:

• You do not include a new page name or inflate page view statistics for the site.

• The tracking of user interactions with buttons, links, or specific features within a page/application is desired.

• Track the interaction path of the application.

Path analysis can be enabled for traffic variables (not restricted to page pathing) which is a useful tool in analyzing the order users interact with your page or application. For example, you see that a user interacted first with button1 and then clicked on button4 before leaving the application. This link-level path can be traced without inflating page-level statistics by using the tl()

function.

Sending Micro-Data (Link)

If an image request was previously made on the same page, clear the values of the previously-set variables. This can be accomplished by:

• Writing a simple JavaScript function to clear the Adobe variables.

• Set the linkTrackVars and linkTrackEvents variables if you have not already done it in the s_code.js

file.

Implementing Analytics Using JavaScript 209

• Set the values appropriate for the changed content, namely the pageName variable.

• After the variables are set, call the tl() function.

Syntax

//set linkTrackVars and linkTrackEvents> (if applicable)

//set new variables s.tl(this,'o','Link Name');

Example

s.linkTrackVars="prop1,eVar1,events"; s.linkTrackEvents="event1"; s.prop1="some value"; s.eVar1="another value"; s.events="event1"; s.tl(this,'o','My Link Name');

Placement of Code

There are generally two places to track data with AJAX: at the time of the request or in the reply. In most cases, macro-data (page information) should be sent at the time of reply by having the code embedded in the HTML of the new content. For micro-data tracking (links, etc.) it is more common to use a custom links approach by inserting the code in the onClick attribute of the link, button, etc.

External Email Tracking

Companies use Analytics to determine the success of an email campaign.

Analytics can report email campaign analysis data in several key metrics, including the following:

Metric

Click-throughs

Purchases and/or Successes

Orders

Yield

Conversion

Description

Displays the number of click-throughs tracked from the email to the landing page.

Displays the number of purchases resulting from the email.

Displays the number of orders placed as a result of the email.

Displays the dollar amount per visit generated from the email.

Displays the number of leads, registrations, or any other success event generated from the email.

Modifications to the HTML email body and the JavaScript library are required in order to capture the key metrics shown above.

Implementation

There are several steps to follow in order to successfully display email campaign analysis data. The steps are described as follows:

1. Create unique tracking codes.

Often, users ask for tracking recommendations for each unique campaign. This is entirely up to them, based on what works best. Each user is different. Adobe recommends that each user generate friendly tracking codes, as shown in the example below:

• sc_cid=A1123A321 > "A" flags affiliate campaign

• sc_cid=EM033007 > "EM" flags email campaign

• sc_cid=GG987123 > "GG" signifies Google and is a paid search campaign

Implementing Analytics Using JavaScript 210

Contact Adobe Customer Care for details on setting up and using tracking codes.

2. Add query string parameters to HTML email links.

In order to track a user click-through and subsequent success events, a query string parameter needs to be added to each link within the HTML email. You can choose to track each link separately or track all links together.

Each link can have a unique tracking code, or all links can have the same tracking code. Consider the following hypothetical link within the email to a website:

<a href="http://www.mycompany.com/index.asp">Visit our home page</a>

The following query string parameters ?sc_cid=112233B should be added to the link above:

<a href= "http://www.mycompany.com/index.asp?sc_cid=112233B">Visit our home page</a>

3. Update the JavaScript library.

Altering code in the JavaScript file, s_code.js

, lets you capture how many users (and which users) clicked-through from the email and participated in subsequent success events. There are two steps to updating the JavaScript library.

a. Customize s_code.js

by calling getQueryParam.

The

s_code.js

file should be placed in a location on the Web server where each Web page can access it.

The doPlugins function within this file should be altered so it captures the query string parameters on the email links. For example:

/* Plugin Config */ s.usePlugins=true function s_doPlugins(s) {

/* Add calls to plugins here */

// External Campaigns s.campaign=s.getQueryParam('source')

} s.doPlugins=s_doPlugins

Each query string parameter that needs to be copied into a variable should have one getQueryParam call.

In the example above, the query string parameter sc_cid is copied into campaign.

Only the first call to getQueryParam is required to capture click-throughs. Contact Adobe Customer Care to implement this function and ensure that your version of the JavaScript file contains the getQueryParam plug-in.

b. Make sure the Code to Paste JavaScript tags are on all landing pages. This Code to Paste must reference the version of s_code.js

altered in Part A.

The following points are important to remember when updating the JavaScript library. These points are listed below.

• The query string parameter sc_cid must be visible in the URL on the final landing page otherwise no click-through conversion is recorded.

• The sc_cid parameter is an example of a query string parameter. Any query string parameter can be used and captured by the getQueryParam plug-in. Make sure that the query string parameters are used only for campaign tracking. Any time the parameters appear in a query string, their values are copied into campaign.

4. Use SAINT to classify campaign tracking codes.

The SAINT Campaign Management Tool can be used to convert tracking codes into user-friendly names. It can also be used to summarize the success of each email campaign. Step 5, below, outlines the process required to set up an email campaign.

5. See pathing by email campaign (optional).

Implementing Analytics Using JavaScript 211

Pathing analysis by email campaign can be accomplished similarly to pathing by another campaign. You can use a variable to show pathing by campaign, as explained in the following steps: a. Consult Adobe Customer Care about turning on pathing for a Custom Insight variable (prop) b. On all pages, copy the page name into the designated s.prop

c. On the email landing page, append the name of the email campaign to the prop. The result displays as shown below: s.prop1="Home Page : 123456"

When pathing is enabled for the Custom Insight variable, you can use Path reports (such as Next Page

Flow or Fallout) to see visitor navigation from the landing page.

Implementing Adobe Opt-Outs

Some visitors to your website may prefer not to have their browsing information aggregated and analyzed by Adobe

Marketing Cloud products and services or used to provide relevant content and advertising. Adobe offers you the ability to provide visitors to your website a means to opt out of their information being collected by the following

Adobe products:

• Adobe Analytics

• Adobe Target

• Adobe Audience Targeted Creative

• Adobe AudienceManager

• Adobe AdLens

• Adobe Experience Manager

Privacy policy recommendations

Adobe recommends that you provide your website visitors with easy-to-find and easy-to-understand information regarding the ability to opt out of having their browsing information collected by Adobe products or services.

Visitors can learn more about how Adobe generally uses information it collects in connection with providing our products and services to our customers in the

Adobe Privacy Center

. However, because you exclusively control how to implement our services on your web sites, it is up to you to describe to your website visitors the specific ways in which they use our products and services. You are responsible for the creation of your own privacy policy, for complying with your privacy policy, for complying with your service agreement with Adobe, and for complying with all applicable laws.

Opt-outs for Adobe Analytics (including reports & analytics, data warehouse, ad hoc analysis and

SearchCenter+)

Adobe offers three types of opt-outs for Adobe Analytics (including reports & analytics, data warehouse, ad hoc analysis and SearchCenter+):

• If you implement Adobe Analytics products with your own first-party cookie, you need to

develop your own customized opt-out link

for your website visitors.

• Adobe also provides an opt-out mechanism to the public for websites using cookies set from Adobe’s 2o7.net and omtrdc.net domains. This opt-out mechanism can be accessed from the

Adobe Privacy Center

• Your customers have the option of enabling opt-out using the browser's cookie settings. See

Enable privacy settings for browser cookies

Implementing Analytics Using JavaScript 212

Regardless of the opt-out mechanism you choose, Adobe recommends that you clearly describe the availability of the opt-out mechanism in your privacy policy or as otherwise required by law or recommended according to current best practices.

Add an Opt-Out Link

Specify an opt-out link, and customize the branding for the link. Visitors to your web site may choose not to have their activity tracked in Adobe’s analytics products by visiting the opt-out page for your data collection domain.

If a user chooses not to be tracked and an opt-out cookie is set, your JavaScript file will continue to send data to

Adobe servers but that data will not be processed or reported on.

The collection_domain section of the URL structure is the trackingServer used in your JavaScript file. The collection domain used for your Adobe Analytics implementation can be seen in the DigitalPulse debugger in the first row of the Adobe Analytics table, which is labeled either “First Party Cookies” or “Third Party Cookies” depending on your implementation. The collection domain for your website may contain 2o7.net, omtrdc.net or your website domain, such as metrics.example.com.

Visitors opt-out by clicking the link on the opt-out page, thereby causing a cookie to be set in their browser. By having the omniture_optout

cookie for the applicable tracking domain, the user's activities will not be reported by Adobe

Analytics. You can provide your own link to the opt-out cookie, or you can follow the steps below to set the opt-out cookie.

Adobe offers opt-outs for all implementation types.You are responsible for your own privacy policy and for remaining in compliance with your signed terms. Note that the link to the opt-out page changes based on your implementation type, as outlined here.

If you implement Adobe Analytics products and services with cookies set on domains owned by Adobe (i.e. 207.net

or omtrdc.net), you can point your website visitors to the opt-out mechanism provided in the

Adobe Privacy Center

for all sites that use Adobe cookies for Adobe Analytics products and services. The direct link to the Adobe opt-out mechanism is http://collection_domain/optout.html.

More information about Adobe Analytics privacy practices can be found at

http://www.adobe.com/privacy/advertising-services.html

•

Opt-out Page URL Structure

•

Example Opt-Out URLs

•

Branding your Opt-Out URL

Opt-out Page URL Structure

Your opt out page is at the following URL: http://collection_domain/optout.html[?optional_parameters]

The optional_parameters

include: locale=[code]

: Provides a translated version of the opt-out page. The following locales are supported:

• en_US (default)

• de_DE

• es_ES

• fr_FR

• jp_JP

• ko_KR

• zh_CN

Implementing Analytics Using JavaScript 213

• zh_TW popup=1

: Treats the page as if it were a popup, and offers a “Close Window” button.

Example Opt-Out URLs

An English web page in a full window containing a link that, when clicked, will prevent the visitor from being tracked on metrics.example.com: http://metrics.example.com/optout.html

A French web page in a full window, containing a link that, when clicked, will prevent the visitor from being tracked on example.d3.sc.omtrdc.net: http://example.d3.sc.omtrdc.net/optout.html?locale=fr_FR

A German web page, in a popup window, containing a link that, when clicked, will prevent the visitor from being tracked on example.112.2o7.net: http://example.112.2o7.net/optout.html?popup=1&locale=de_DE

Branding your Opt-Out URL

You can provide a link, such as the following somewhere on your website:

Click Here to Opt Out! </a>

Where stats.adobe.com is replaced with whatever the s.trackingServer variable is set to.

Additionally, if you want like to provide a link to opt-in, use the same URL, but replace

?optout=1

with

?optin=1

, and keep the confirm_change=1

Implementation Plug-ins

AppMeasurement for JavaScript plug-ins are programs or functions that perform several advanced functions.

These plug-ins extend the capabilities of your JavaScript file to give you more functionality that is not available with a basic implementation. Adobe offers a number of other plug-ins as part of advanced solutions. Contact your Account

Manager if you want to capture data using JavaScript but are unsure how to proceed.

**Calling Plug-ins with doPlugins Function**

JavaScript plug-ins are usually called by the doPlugins function, which is executed when the t() function is called in the Code to Paste.

Consequently, if you set a variable in the doPlugins function, you can overwrite a variable you set on the HTML page. The only time the doPlugins function is not called is when the usePlugins variable is set to 'false.'

Code Example

The code example below is what the doPlugins function looks like in your JavaScript file:

AppMeasurement for JavaScript:

/* Plugin Config */ s.usePlugins=true s.doPlugins=function(s) {

/* Add calls to plugins here */

}

Implementing Analytics Using JavaScript

H code:

/* Plugin Config */ s.usePlugins=true function s_doPlugins(s) {

/* Add calls to plugins here */

} s.doPlugins=s_doPlugins

Note: H code and earlier versions use a different syntax to support some very old browsers (such as IE 4 and 5).

214

Renaming the doPlugins Function

The doPlugins function is typically called s_doPlugins. In certain circumstances, (usually when more than one version of code may appear on a single page) the doPlugins function name may be changed. If the standard doPlugins function needs to be renamed to avoid conflicts, ensure that doPlugins is assigned the correct function name, as shown in the example below.

/* Plugin Config */ s_mc.usePlugins=true function s_mc_doPlugins(s_mc) {

/* Add calls to plugins here */

} s_mc.doPlugins=s_mc_doPlugins

Using doPlugins

The doPlugins function provides an easy way to give default values to variables or to take values from query string

parameters on any page of the site. Using doPlugins is often easier than populating the values in the HTML page because only one file must be updated. Keep in mind that changes to the JavaScript file are not always immediate.

Return visitors to your site are often using cached versions of the JavaScript file. This means that updates to the file may not be applied to all visitors for up to one month after the change is made.

The following example shows how the doPlugins function can be used to set a default value for a variable and to get a value from the query string.

/* Plugin Config */ s.usePlugins=true s.doPlugins=function(s) {

/* Add calls to plugins here */

// if prop1 doesn't have a value, set it to "Default Value"

if(!s.prop1) s.prop1="Default Value"

// if campaign doesn't have a value, get cid from the query string

if(!s.campaign) s.campaign=s.getQueryParam('cid');

// Note: The code to read query parameters is different for

// Appmeasurement for JavaScript since a plug-in is not required:

// s.campaign=s.Util.getQueryParam('cid');

}

Installed Plug-ins

To find out whether a plug-in is included in your JavaScript file and ready for use, look in the Plugins Section of the JavaScript file. The following example shows the getQueryParam function.

/************************** PLUGINS SECTION *************************/

/* You may insert any plugins you wish to use here. */

* Plugin: getQueryParam 1.3 - Return query string parameter values

Implementing Analytics Using JavaScript

*/ s.getQueryParam=new Function("qp","d",""

+"var s=this,v='',i,t;d=d?d:'';while(qp){i=qp.indexOf(',');i=i<0?qp.l"

// ... more code below ...

215

s.abort flag

The abort flag can be set inside doPlugins to cause the current track call to not be sent.

The abort flag is reset with every tracking call, so if a subsequent tracking call also needs to be aborted the flag will need to be set again inside doPlugins.

s.doPlugins = function(s) {

s.campaign = s.getQueryParam("cid");

if ((!s.campaign) && (!s.events)) {

s.abort = true;

}

};

This lets you centralize the logic you use to identify activity that you do not want to track, such as some custom links or external links in display ads.

appendList

The apl (or appendList) plug-in lets you append a value to any delimited lists, with the option of a case-sensitive or case-insensitive check to ensure that the value does not already exist in the list. The APL plug-in is referenced by several standard plug-ins but can be used directly in a variety of situations.

This plug-in is useful for:

• Adding an event to the current events variable

• Adding a value to a list variable without duplicating a value in the list

• Adding a product to the current products variable based on some page logic

• Adding values to the parameters linkTrackVars and linkTrackEvents

Use Case 1

Scenario

Code

Results

Add event1 to the current events variable while ensuring the event isn't duplicated.

s.events="scCheckout" s.events=s.apl(s.events,"event1",",",1) s.events="scCheckout,event1"

Use Case 2

Scenario

Code

Add the value history to the list variable prop1, with history and History considered the same value.

s.prop1="Science,History" s.prop1=s.apl(s.prop1,"history",",",2)

Implementing Analytics Using JavaScript 216

Results s.prop1="Science,History"

history is not added because History is already in the list.

Note: The following instructions require you to alter the data collection code on your site. This can affect data collection on your site, and should only be done by a developer with experience using and implementing

Analytics.

Implementation

Follow these steps to implement the APL plug-in.

1. Request the plug-in code from Customer Care or your currently assigned Adobe consultant.

2. Add call(s) to the API function as needed within the s_doPlugins function

Here is how the code might look on your site:

/* Plugin Config */ s.usePlugins=true function s_doPlugins(s) {

/* Add calls to plugins here */ s.events=s.apl(s.events,"event1",",",1)

} s.doPlugins=s_doPlugins

Supported Browsers

This plug-in requires that the browser supports JavaScript version 1.0.

Plug-in Information

Plug-in Information Description

Parameters apl((L,v,d,u)

L= source list, empty list is accepted v = value to append d = list delimiter u (optional, defaults to 0) Unique value check. 0=no unique check, value is always appended.

1=case-insensitive check, append only if value isn't in list. 2=case-sensitive check, append only if value isn't in list.

Return Value original list, with appended value if added

Usage Examples s.events=s.apl(s.events,"event1",",",1);

Implementing Analytics Using JavaScript 217

The source list L can be an empty list, such as L="". The returned value will either be an empty list, or a list of one value.

Plug-in Code

/********************************************************************

* Main Plug-in code (should be in Plug-ins section)

*******************************************************************/

* Plugin Utility: apl v1.1

*/ s.apl=new Function("l","v","d","u",""

+"var s=this,m=0;if(!l)l='';if(u){var i,n,a=s.split(l,d);for(i=0;i<a."

+"length;i++){n=a[i];m=m||(u==1?(n==v):(n.toLowerCase()==v.toLowerCas"

+"e()));}}if(!m)l=l?l+d+v:v;return l");

/********************************************************************

* Commented example of how to use this is doPlugins function

*******************************************************************/

Not Applicable - Utility function only

/********************************************************************

* Config variables (should be above doPlugins section)

*******************************************************************/

None

/********************************************************************

* Utility functions that may be shared between plug-ins (name only)

*******************************************************************/

s.split

doPlugins Function

JavaScript plug-ins are usually called by the doPlugins

function, which is executed when the t()

function is called in the Code to Paste.

Consequently, if you set a variable in the doPlugins

function, you may overwrite a variable you set on the HTML page. The only time the doPlugins

function is not called is when the usePlugins variable is set to false

Code Example

The doPlugins

function is typically called s_doPlugins

. However, in certain circumstances (usually when more than one version of Analytics code may appear on a single page), you can change the doPlugins

function name.

If the standard doPlugins

function needs to be renamed to avoid conflicts, assign doPlugins

the correct function name, as shown in the example below.

/* Plugin Config */ s_mc.usePlugins=true function s_mc_doPlugins(s_mc) {

/* Add calls to plugins here */

} s_mc.doPlugins=s_mc_doPlugins

Implementing Analytics Using JavaScript 218

Using doPlugins

This function provides an easy way to give default values to variables, or to take values from query string parameters on any page of the site. Using doPlugins

can be easier than populating the values in the HTML page, because only one file must be updated. Changes to the JavaScript file are not always immediate. Return visitors to your site are often using cached versions of the JavaScript file. Meaning, updates to the file may not be applied to all visitors for up to one month after the change is made.

The following examples show how you can use the doPlugins

function to set a default value for a variable and to get a value from the query string.

/* Plugin Config */ s.usePlugins=true function s_doPlugins(s) {

/* Add calls to plugins here */

// if prop1 doesn't have a value, set it to "Default Value" if(!s.prop1) s.prop1="Default Value"

// if campaign doesn't have a value, get cid from the query string if(!s.campaign) s.campaign=getQueryParam('cid');

} s.doPlugins=s_doPlugins

Installed Plug-ins

To find out whether a plugin is included in your JavaScript file and ready for use, look in the Plugins Section of the

JavaScript file. The following example shows what the getQueryParam

function looks like in the Plugins Section.

/************************** PLUGINS SECTION *************************/

/* You may insert any plugins you wish to use here. */

* Plugin: getQueryParam 1.3 - Return query string parameter values

*/ s.getQueryParam=new Function("qp","d",""

+"vars=this,v='',i,t;d=d?d:'';while(qp){i=qp.indexOf(',');i=i<0?qp.l"

// ... more code below ...

getAndPersistValue

The getAndPersistValue plug-in obtains a value of your choosing and populates it into a Analytics variable for a determined period. A common use is to see how many page views a campaign generates after a click-through, which enables you to easily see the most common pages for each campaign.

Important: This plug-in has not been validated to be compatible with

AppMeasurement for JavaScript . See

AppMeasurement Plug-in Support .

For example, you might use this plug-in to set a campaign tracking code from the campaign variable into a Custom

Traffic (s.prop) variable on each visitor's page view made for the next 30 days. This example lets you determine how many page views the tracking code generated as a result of the original click-through.

Analytics.

Implementing Analytics Using JavaScript 219

Plug-in Code and Implementation

CONFIG SECTION: No changes required for this section.

Plug-in Configuration

Place the following code within the s_doPlugins() function, which is located in the area of the s_code.js file labeled

Plugin Config. Choose one Custom Traffic (s.prop) variable or one Custom Conversion (s.eVar) variable for use in capturing persisted value data. This should be a variable that has been enabled using the Admin Console, but which is not currently in use for any other purpose. You can use the following example and update it based on your requirements.

s.prop1=s.getAndPersistValue(s.campaign,'s_getval',30);

s.getAndPersistValue has three arguments:

1. Currently populated variable or value to persist (s.campaign shown above).

2. Cookie name, used to store the value (s_getval shown above).

3. Period of time for persistence, in days. "30" as shown above would cause the value to be populated into the selected variable on every page view made by the user for the next 30 days. If omitted, the setting defaults to

session.

PLUGINS SECTION: Add the following code to the area of the s_code.js

file labeled PLUGINS SECTION. Do not make any changes to this portion of the plug-in code.

* Plugin: getAndPersistValue 0.3 - get a value on every page

*/ s.getAndPersistValue=new Function("v","c","e",""

+"var s=this,a=new Date;e=e?e:0;a.setTime(a.getTime()+e*86400000);if("

+"v)s.c_w(c,v,e?a:0);return s.c_r(c);");

Always test plug-in installations extensively to ensure that data collection is as expected before deploying in a production environment.

getDaysSinceLastVisit

Determines the number of days since a user last visited your site, and captures this information in a Analytics variable.

This return frequency data can be used to answer the following questions:

• How frequently do users revisit my site?

• How does return frequency correlate with conversion? Do repeat buyers visit frequently or infrequently?

• Do users who click through my campaigns then return frequently?

The plug-in can also generate values used for segmentation. For example, you can create a segment to view all of the data for only those visits that were preceded by 30 or more days of non-visitation by the user.

Analytics.

Plug-in Code and Implementation

CONFIG SECTION

No changes required.

Plugin Config

Implementing Analytics Using JavaScript 220

Place the following code within the s_doPlugins()

function, which is located in the area of the s_code.js

file labeled Plugin Config. Choose one Custom Traffic (s.prop) variable and/or one Custom Converesion (s.eVar) variable for use in capturing return frequency data. This selection should be a variable that has been enabled using the Admin

Console but is not currently in use for any other purpose. The following is given as an example, and should be updated appropriately based on your needs.

s.prop1=s.getDaysSinceLastVisit(Cookie_Name);

PLUGINS SECTION

Add the following code to the area of the s_code.js

file labeled PLUGINS SECTION. Do not make any changes to this portion of the plug-in code.

* Plugin: Days since last Visit 1.1 - capture time from last visit

*/ s.getDaysSinceLastVisit=new Function("c",""

+"var s=this,e=new Date(),es=new Date(),cval,cval_s,cval_ss,ct=e.getT"

+"ime(),day=24*60*60*1000,f1,f2,f3,f4,f5;e.setTime(ct+3*365*day);es.s"

+"etTime(ct+30*60*1000);f0='Cookies Not Supported';f1='First Visit';f"

+"2='More than 30 days';f3='More than 7 days';f4='Less than 7 days';f"

+"5='Less than 1 day';cval=s.c_r(c);if(cval.length==0){s.c_w(c,ct,e);"

+"s.c_w(c+'_s',f1,es);}else{var d=ct-cval;if(d>30*60*1000){if(d>30*da"

+"y){s.c_w(c,ct,e);s.c_w(c+'_s',f2,es);}else if(d<30*day+1 && d>7*day"

+"){s.c_w(c,ct,e);s.c_w(c+'_s',f3,es);}else if(d<7*day+1 && d>day){s."

+"c_w(c,ct,e);s.c_w(c+'_s',f4,es);}else if(d<day+1){s.c_w(c,ct,e);s.c"

+"_w(c+'_s',f5,es);}}else{s.c_w(c,ct,e);cval_ss=s.c_r(c+'_s');s.c_w(c"

+"+'_s',cval_ss,es);}}cval_s=s.c_r(c+'_s');if(cval_s.length==0) retur"

+"n f0;else if(cval_s!=f1&&cval_s!=f2&&cval_s!=f3&&cval_s!=f4&&cval_s"

+"!=f5) return '';else return cval_s;");

Notes

• Always test plug-in installations extensively to ensure that data collection is as expected before deploying in a production environment.

• The plug-in categorizes users by return frequency into the following groups:

• First Visit

• Less than 1 day

• Less than 7 days

• More than 7 days

• More than 30 days

• This plug-in relies on cookies to flag a user has having visited previously. If the browser does not accept cookies, the plug-in returns a value of Cookies Not Supported.

getLoadTime

Gets the page load time in tenths of a second and lets you store the value in a prop, eVar, and/or a numeric event.

To use this plugin, you insert the function code, then call the function twice in your s_code.js

file. Once at the beginning of the file, and then again in the doPlugins

section. This plugin is intentionally not defined as a method of the s object. Doing so would have added to the calculated page load time.

Analytics.

Plug-in Code and Implementation

Add the function

Implementing Analytics Using JavaScript 221

Add the following definition of the s_getLoadTime

function in s_code.js

, anywhere before the "DO NOT ALTER

ANYTHING BELOW THIS LINE" section: function s_getLoadTime(){if(!window.s_loadT){var b=new

Date().getTime(),o=window.performance?performance.timing:0,a=o?o.requestStart:window.inHeadTS||0;s_loadT=a?Math.round((b-a)/100):''}return

s_loadT}

Make the initial function call

Add a call to s_getLoadTime()

near the beginning of s_code.js

, outside of any function.

Make the final function call

Add another call to s_getLoadTime()

in the s_doPlugins()

function, saving the returned value in a prop, eVar, and/or a numeric event.

Usage Example 1 - Save the page load time in prop10 and eVar20: s.eVar20=s.prop10=s_getLoadTime();

Usage Example 2 - Save the page load time in numeric event99: if(s_getLoadTime())s.events=s.apl(s.events,'event90='+s_getLoadTime(),',',1);

(Optional) Add support for older browsers

To support older browsers that don't provide the

window.performance.timing

property, include the following line in the HEAD section of the page's HTML near the beginning and prior to invoking .js, .css, or other files:

getNewRepeat

Determines whether a visitor is a new visitor or a repeat visitor, and captures this information in a Analytics variable.

Use this plug-in to answer the following questions:

• What percentage of my visitors are new (as opposed to repeat) visitors?

• Do return visitors generate higher conversion per capita than new visitors? What is this ratio?

• Do my marketing campaigns cause persistence across visits? For example, do users who click through my campaigns then return later?

Analytics.

Plug-in Code and Implementation

CONFIG SECTION: No changes required for this section.

Plug-in Configuration

Place the following code within the s_doPlugins() function, which is located in the area of the s_code.js file labeled

s.prop1=s.getNewRepeat(30,'s_getNewRepeat');

s.getNewRepeat has two optional arguments:

Implementing Analytics Using JavaScript 222

1. The first optional argument is the number of days that the cookie should last. The default value if this argument is omitted is 30 days.

2. The second optional argument is the cookie name. A default value is used if this argument is omitted.

PLUGINS SECTION: Add the following code to the area of the s_code.js

file labeled PLUGINS SECTION. Do not make any changes to this portion of the plug-in code.

* Plugin: getNewRepeat 1.2 - Returns whether user is new or repeat

*/ s.getNewRepeat=new Function("d","cn",""

+"var s=this,e=new Date(),cval,sval,ct=e.getTime();d=d?d:30;cn=cn?cn:"

+"'s_nr';e.setTime(ct+d*24*60*60*1000);cval=s.c_r(cn);if(cval.length="

+"=0){s.c_w(cn,ct+'-New',e);return'New';}sval=s.split(cval,'-');if(ct"

+"-sval[0]<30*60*1000&&sval[1]=='New'){s.c_w(cn,ct+'-New',e);return'N"

+"ew';}else{s.c_w(cn,ct+'-Repeat',e);return'Repeat';}");

* Utility Function: split v1.5 (JS 1.0 compatible)

*/ s.split=new Function("l","d",""

+"var i,x=0,a=new Array;while(l){i=l.indexOf(d);i=i>-1?i:l.length;a[x"

+"++]=l.substring(0,i);l=l.substring(i+d.length);}return a");

Always test plug-in installations extensively to ensure that data collection is as expected before deploying in a production environment.

getPageVisibility

Records the number of seconds your page was the active tab within the browser, and passes that value into a metric on the next page view.

Note: This is a beta version of the plugin, and additional updates may be forthcoming.

This plug-in requires

getVisitStart

This plug-in also records the total seconds the page was within the browser (both active and passive viewing time).

It is required to use the getPreviousValue plug-in in order to track the previous page name associated with the page visibility events. Tracking these values helps you better understand visitor engagement and more accurately track visitor behavior on your sites.

It is required that you use the getPreviousValue plug-in to track the previous page name associated with the page visibility events. Tracking these values helps you better understand visitor engagement and more accurately track visitor behavior on your sites.

Analytics. This plug-in is compatible only with AppMeasurement tracking libraries.

Required Supporting Plug-ins

• appendList

• getPreviousValue

• getVisitStart

Plug-in Code and Implementation

Config Section

Implementing Analytics Using JavaScript 223

The s.pvel

variable should contain the three events you wish to use:

Event Definition

Total Page

Visibility Seconds

(Numeric)

The amount of time the page was active within the browser

Total Page

Seconds

(Numeric)

The amount of time the page was loaded in the browser, regardless of its visibility state

Total Page

Visibility Instances

(Counter)

The total number of times a value was recorded for the previous two events

Sample Calls

//Page Visibility Event List (total page visibility seconds, total page seconds, total page visibility instances) s.pvel='event7,event8,event9'

doPlugins Section

To initialize the plug-in, two lines of code are required in the doPlugins

section of your s_code, preferably after you have designated the s.pageName

variable.

Sample Calls

/* Page Visibility */ s.eVar9 = s.getPreviousValue(s.pageName,'gpv_v9',''); //Record the previous page name in the

designated eVar of your choice s.getPageVisibility();

Plug-ins Section

/* Page Visibility Plugin 0.1 (BETA) */ s.getPageVisibility=new Function("",""

+"var s=this;if(s.getVisitStart()){s.Util.cookieWrite('s_pvs','');s.U"

+"til.cookieWrite('s_tps','');}if(s.Util.cookieRead('s_pvs')&&s.pvt<1"

+"){if(parseInt(s.Util.cookieRead('s_pvs'))<=parseInt(s.Util.cookieRe"

+"ad('s_tps'))){s.pve=s.pvel.split(',');s.events=s.apl(s.events,s.pve"

+"[0]+'='+(parseInt(s.Util.cookieRead('s_pvs'))),',',2);s.Util.cookie"

+"Write('s_pvs','');s.events=s.apl(s.events,s.pve[1]+'='+(parseInt(s."

+"Util.cookieRead('s_tps'))),',',2);s.Util.cookieWrite('s_tps','');s."

+"events=s.apl(s.events,s.pve[2],',',2);}}s.pvi=setInterval(s.pvx,100"

+"0);s.wpvi=setInterval(s.wpvc,5000);"); s.gbp=new Function("",""

+"if('hidden'in document){return null;}var bp=['moz','ms','o','webkit"

+"'];for(var i=0;i<bp.length;i++){var p=bp[i]+'Hidden';if(p in docume"

+"nt){return bp[i];}}return null;"); s.hp=new Function("p",""

+"if(p){return p+'Hidden';}else{return'hidden';}"); s.vs=new Function("p",""

+"if(p){return p+'VisibilityState';}else{return'visibilityState';}"); s.ve=new Function("p",""

+"if(p){return p+'visibilitychange';}else{return'visibilitychange';}"); s.pvx=new Function("",""

+"s.pvt+=1;"); s.wpvc = function(){var tempDate = Date.now();s.Util.cookieWrite('s_tps',

Math.ceil((tempDate - s.totalTime)/1000));s.Util.cookieWrite('s_pvs', s.pvt)} document.addEventListener('visibilitychange',function(event){if(document.hidden){s.visibility

= false;clearTimeout(s.pvi);}else{s.visibility=true;s.pvi=setInterval(s.pvx,1000);}});s.totalTime=new

Date();s.pvt=0;s.prefix=s.gbp;s.hidden=s.hp(s.prefix);s.visibility=true;s.visibilityState=s.vs(s.prefix);s.visibilityEvent=s.ve(s.prefix);

Implementing Analytics Using JavaScript 224

Notes

• Always test plug-in installations to ensure that data collection is as expected before deploying in a production environment.

• Because the plug-in passes the page visibility seconds and total seconds as they are associated with the previous page, data is not collected for the final page view of the visit.

• This plug-in relies on the ability to set cookies in the user's web browser. If the user does not accept first-party cookies, the plug-in will not pass data into Analytics.

• The plug-in creates its own first-party cookies named s_tps

and s_pvs

• A very small percentage of users will not pass percentage of page viewed data due to browser limitations, and logic is contained within the plugin to ensure that the data is not skewed as a result. However, this plug-in has been successfully tested in IE, Firefox, Chrome, and Safari.

• Due to the way the plugin measures total seconds and associates that value with the previous page name, there will be differences between default time spent on page metrics and total seconds metrics.

• Calculated metrics can be created to aid in summarizing and understanding visitor behavior associated with these metrics:

• Page Visibility Ratio (Total Page Visibility Seconds / Total Page Seconds)

• Total Hidden Seconds (Total Page Seconds – Total Page Visibility Seconds)

• Average Page Visibility Seconds (Total Page Visibility Seconds/Total Page Visibility Instances)

• Average Page Hidden Seconds ((Total Page Seconds - Total Page Visibility Seconds)/Total Page Visibility

Instances)

• Due to the way the plug-in rounds up the seconds, there can be a 1-2 second difference between the total page visibility seconds and total seconds, with total seconds being higher. (To be resolved in a future update)

• Using the getVisitStart plug-in should account for visitors that have a new visit start after a period of 30+ minutes of inactivity. This is not working as designed; however, there will likely be a workaround when we incorporate the

“total active seconds” in a future iteration of the plug-in.

Frequently Asked Questions

Will this plug-in make additional server calls?

The plugin will only record page visibility values on subsequent page view server calls. No additional server calls are used in conjunction with it.

If I do not want to capture total page seconds or total page visibility instances, can I leave those out of the event list?

Yes, the total page seconds and total visibility instances are optional events and can be left out of the list if desired.

Will the events captured make sense if I use them in reports other than the Previous Page Name?

Since the plugin records values on the subsequent image request only other eVars that have been captured in a

‘previous page’ context could be applied, i.e. ‘Previous Page URL’.

Will the plug-in send the visibility time on an s.tl() call, or only on an s.t() call?

The visibility time is only recorded with s.t() calls.

getVisitStart

Determines if a new visit is starting.

Configuration Variables

None

Implementing Analytics Using JavaScript 225

Parameters

c = (string) cookie name for tracking.

Returns

(integer) 1 on first page of visit, otherwise 0.

Sample Calls

s.eVar50 = s.getVisitStart("s_visit");

getPercentPageViewed

Record the portion of a page (0-100%) that the user views and pass the value into a variable on the next page view.

This plugin lets you determine how much of your content users are seeing on average, so that you can optimize your page lengths and layouts based on user behaviors.

You can also use classifications to group percentages (such as Less than 25% or Less than 50%) so that you can identify page-viewing trends.

Analytics.

Plug-in Code and Implementation

Config Section: No changes required for this section.

Sample Calls

* Add one of the following examples in s.doPlugins(), after s.pageName has been assigned:

// >>>>>>>>>>>>>>>>>>>>> IMPORTANT NOTE - PLEASE READ! <<<<<<<<<<<<<<<<<<<<

// The getPercentPageViewed plugin returns an integer if the pageID argument is unspecified

// or is set to an empty string or evaluates to false, as shown in example 1 below. If the

// PageID is specified, the plugin returns an array as shown in example 2.

// Example 1: Get maximum percent viewed only, using s.pageName as an implicit identifier s.prop21 = s.getPreviousValue(s.pageName,'s_ppn'); //prop21: prev page name s.prop22 = s.getPercentPageViewed(); //prop22: max % viewed of prev page if(!s.prop21||s.prop21=='no value')s.prop22=''; //clear max % viewed if no prev page view

//Example 2: Get entire percent page viewed array and save metrics s.prop21 = s.getPreviousValue(s.pageName,'s_ppn'); //prop21: prev page name var ppv = s.getPercentPageViewed(s.pageName); //get array of data on prev page % viewed if( ppv && typeof ppv=='object' && ppv[0] == s.prop21 ) { //if ppv array returned and prev page

id matches prev page name

s.prop22 = ppv[1] + '|' + ppv[2]; //prop22: prev page max and initial % viewed, delimited by

"|". (Use classifications to separate values)

s.prop23 = ppv[4] + 'x' + ppv[5]; //prop23: viewport width x height in CSS pixels

s.prop24 = ppv[6] + 'x' + ppv[7]; //prop24: display width x height in real pixels

s.prop25 = ppv[8]; //prop25: pixel density, i.e. number of virtual pixels per real pixel

s.prop26 = ppv[9]; //prop26: device orientation: initial and final (final only present if rotation occurred)

}

Returns

Implementing Analytics Using JavaScript

• If there was not a previous page view in this visit, an empty string is returned

• If pid is "-", or unspecified, an integer containing the last page's maximum percent viewed is returned

• Otherwise, an array is returned with the following elements:

• array[0] - Page ID

• array[1] - Maximum percent viewed

• array[2] - Initial percent viewed

• array[3] - Maximum vertical pixels viewed

• array[4] - Viewport width in CSS pixels new

• array[5] - Viewport height in CSS pixels new

• array[6] - Display width in real pixels (reflecting orientation) new

• array[7] - Display height in real pixels (reflecting orientation) new

• array[8] - Final pixel density new

• array[9] - Device orientation, set to one of the following text strings: new

• "L" - Landscape (rotation did not occur)

• "P" - Portrait (rotation did not occur)

• "LP" - started landscape, ended portrait

• "PL" - started portrait, ended landscape

Plugins Section: Add the following code to the area of the s_code.js

file labeled PLUGINS SECTION. Do not make any changes to this portion of the plug-in code.

* Plugin: getPercentPageViewed v1.71

*/ s.getPercentPageViewed=new Function("n",""

+"var s=this,W=window,EL=W.addEventListener,AE=W.attachEvent,E=['load"

+"','unload','scroll','resize','zoom','keyup','mouseup','touchend','o"

+"rientationchange','pan'];W.s_Obj=s;s_PPVid=(n=='-'?s.pageName:n)||s"

+".pageName||location.href;if(!W.s_PPVevent){s.s_PPVg=function(n,r){v"

+"ar k='s_ppv',p=k+'l',c=s.c_r(n||r?k:p),a=c.indexOf(',')>-1?c.split("

+"',',10):[''],l=a.length,i;a[0]=unescape(a[0]);r=r||(n&&n!=a[0])||0;"

+"a.length=10;if(typeof a[0]!='string')a[0]='';for(i=1;i<10;i++)a[i]="

+"!r&&i<l?parseInt(a[i])||0:0;if(l<10||typeof a[9]!='string')a[9]='';"

+"if(r){s.c_w(p,c);s.c_w(k,'?')}return a};W.s_PPVevent=function(e){va"

+"r W=window,D=document,B=D.body,E=D.documentElement,S=window.screen|"

+"|0,Ho='offsetHeight',Hs='scrollHeight',Ts='scrollTop',Wc='clientWid"

+"th',Hc='clientHeight',C=100,M=Math,J='object',N='number',s=W.s_Obj|"

+"|W.s||0;e=e&&typeof e==J?e.type||'':'';if(!e.indexOf('on'))e=e.subs"

+"tring(2);s_PPVi=W.s_PPVi||0;if(W.s_PPVt&&!e){clearTimeout(s_PPVt);s"

+"_PPVt=0;if(s_PPVi<2)s_PPVi++}if(typeof s==J){var h=M.max(B[Hs]||E[H"

+"s],B[Ho]||E[Ho],B[Hc]||E[Hc]),X=W.innerWidth||E[Wc]||B[Wc]||0,Y=W.i"

+"nnerHeight||E[Hc]||B[Hc]||0,x=S?S.width:0,y=S?S.height:0,r=M.round("

+"C*(W.devicePixelRatio||1))/C,b=(D.pageYOffset||E[Ts]||B[Ts]||0)+Y,p"

+"=h>0&&b>0?M.round(C*b/h):0,O=W.orientation,o=!isNaN(O)?M.abs(o)%180"

+":Y>X?0:90,L=e=='load'||s_PPVi<1,a=s.s_PPVg(s_PPVid,L),V=function(i,"

+"v,f,n){i=parseInt(typeof a==J&&a.length>i?a[i]:'0')||0;v=typeof v!="

+"N?i:v;v=f||v>i?v:i;return n?v:v>C?C:v<0?0:v};if(new RegExp('(iPod|i"

+"Pad|iPhone)').exec(navigator.userAgent||'')&&o){o=x;x=y;y=o}o=o?'P'"

+":'L';a[9]=L?'':a[9].substring(0,1);s.c_w('s_ppv',escape(W.s_PPVid)+"

+"','+V(1,p,L)+','+(L||!V(2)?p:V(2))+','+V(3,b,L,1)+','+X+','+Y+','+x"

+"+','+y+','+r+','+a[9]+(a[9]==o?'':o))}if(!W.s_PPVt&&e!='unload')W.s"

+"_PPVt=setTimeout(W.s_PPVevent,333)};for(var f=W.s_PPVevent,i=0;i<E."

+"length;i++)if(EL)EL(E[i],f,false);else if(AE)AE('on'+E[i],f);f()};v"

+"ar a=s.s_PPVg();return!n||n=='-'?a[1]:a");

Notes

• Always test plug-in installations to ensure that data collection is as expected before deploying in a production environment.

226

Implementing Analytics Using JavaScript 227

• Because the plug-in passes the percentage of page viewed on the previous page, data is not collected for the final page view of the visit. One way around this is to use a function on all exit links to call s.getPercentPageViewed().

• This plug-in relies on the ability to set cookies in the user's web browser. If the user does not accept first-party cookies, the plug-in will not pass data into Analytics.

• The plug-in creates its own first-party cookie named s_ppv

• A very small percentage of users will not pass percentage of page viewed data due to browser limitations. However, this plug-in has been successfully tested in IE, Firefox, Chrome, Safari, and Opera.

getPreviousValue

Captures the value of a Analytics variable on the next page view. For example, you can use plug-in to capture the

s.pageName value from the previous page view into a Custom Traffic variable. It also has an option to capture a previous value only when designated success events are set.

Analytics.

Plug-in Code and Implementation

CONFIG SECTION: No changes required for this section.

Plug-in Configuration

Place the following code within the s_doPlugins() function, which is located in the area of the s_code.js file labeled

s.prop1=s.getPreviousValue(s.pageName,'gpv_pn','event1');

s.getPreviousValue has three arguments:

1. The variable to be captured from the previous page (s.pageName above).

2. The cookie name for use in storing the value for retrieval (gpv_pn above).

3. The events that must be set on the page view in order to trigger the retrieval of the previous value (event1 above).

When left blank or omitted, the plug-in captures the previous value on all page views.

PLUGINS SECTION: Add the following code to the area of the s_code.js

file labeled PLUGINS SECTION. Do not make any changes to this portion of the plug-in code.

* Plugin: getPreviousValue_v1.0 - return previous value of designated

* variable (requires split utility)

*/ s.getPreviousValue=new Function("v","c","el",""

+"var s=this,t=new Date,i,j,r='';t.setTime(t.getTime()+1800000);if(el"

+"){if(s.events){i=s.split(el,',');j=s.split(s.events,',');for(x in i"

+"){for(y in j){if(i[x]==j[y]){if(s.c_r(c)) r=s.c_r(c);v?s.c_w(c,v,t)"

+":s.c_w(c,'no value',t);return r}}}}}else{if(s.c_r(c)) r=s.c_r(c);v?"

+"s.c_w(c,v,t):s.c_w(c,'no value',t);return r}");

* Utility Function: split v1.5 - split a string (JS 1.0 compatible)

*/ s.split=new Function("l","d",""

+"var i,x=0,a=new Array;while(l){i=l.indexOf(d);i=i>-1?i:l.length;a[x"

+"++]=l.substring(0,i);l=l.substring(i+d.length);}return a");

Implementing Analytics Using JavaScript 228

Notes

• Always test plug-in installations extensively to ensure that data collection is as expected before deploying in a production environment.

• If no value is present for the selected variable on any given page, the text no value will be set in the cookie.

• A fixed 30-minute cookie expiration is now set for each cookie, and refreshed with each page load. The plug-in works for the length of a visit.

• Because the function must be called as part of the plug-ins section of code, the code runs each time s.t() or s.tl() is called.

• The chosen variable should be populated with a value prior to the call to s.getPreviousValue. Because the

s_doPlugins() function is executed after the variables on the page are populated, this issue rarely occurs. It should only be a matter of concern if the variable used with this plug-in is populated within the s_doPlugins() function and after the call to s.getPreviousValue.

getQueryParam

Returns the value of a specified query string parameter, if found in the current page URL. Because important data

(such as campaign tracking codes, internal search keywords, etc.) is available in the query string on a page,

getQueryParam is helps capture the data into Analytics variables.

Important: This plug-in is used by H code only.

AppMeasurement for JavaScript provides this functionality

natively using

Util.getQueryParam

Once installed in your AppMeasurement for JavaScript code, the plug-in is configured by selecting a Analytics variable to populate using data found in the query string, and specifying which query string values to capture. The plug-in detects the specified query string, if present, and populates the chosen variable with its value. If no query string parameter is found with that value, an empty string is returned. If a query string parameter exists but does not have a value (such as param1 in

?param1&param2=value

), the word true is returned.

Note: The base code for the plug-in must be installed in your AppMeasurement for JavaScript code before the examples below will work.

If you wanted to use s.campaign to capture campaign tracking codes available as values of the cid query parameter, you would enter the following in the doPlugins() function in your AppMeasurement for JavaScript code: s.campaign=s.getQueryParam('cid')

In this example, if the user arrived at a landing page on your site where the URL was http://www.yoursite.com/index.html?cid=123456

, then s.campaign would receive a value of 123456.

This could be seen using the DigitalPulse Debugger, which should show v0=123456 as part of the image request.

Note: The parameter cid and others are used here as examples. You can replace them with any query string parameters that exist on your site.

The getQueryParam plug-in has two additional arguments (options) that can be used to capture data into Analytics variables: s.getQueryParam('p','d','u') where: p = comma-separated list of query parameters to locate (can also be a single value with no comma)

Implementing Analytics Using JavaScript 229 d = delimiter for list of values (in case more than one specified parameter is found) u = where to search for value (e.g., document.referrer); set to current page URL by default

If p is a list of query string parameters and more than one query string parameter is found in the URL, all values are returned in a list separated by the delimiter, d, which can be a single character or a string of characters, such as "

: " (space-colon-space). If d is omitted, no delimiter is used between values. If one query string parameter should take precedence over another, when both are found, use an if statement as shown below.

// cid takes precedence over iid if both exist in the query string s.campaign=s.getQueryParam('cid');

if(!s.campaign)

s.campaign=s.getQueryParam('iid');

As of version getQueryParam v2.0, the plug-in accepts an optional third argument, u, which allows you to specify the URL from which you would like to extract query string parameters. By default (i.e. if this third argument is omitted or left blank), the plug-in uses the page URL. For example, if you would like extract a query string from the referrer, you can use the following code:

// take the query string from the referrer

s.eVar1=s.getQueryParam('pid','',document.referrer);

The flag "f" should be used in this third argument with frames, when the necessary query string parameter is found in the address bar rather than the current frame's URL:

// take the query string from the parent frame

s.eVar1=s.getQueryParam('pid','',f);

When using frames and the f parameter, it is recommended that the getValOnce plug-in be used to prevent the campaign tracking code to be sent with each page view.

Analytics.

Plug-in Code

/********************************************************************

* Main Plug-in code (should be in Plug-ins section)

*******************************************************************/

* Plugin: getQueryParam 2.3

*/ s.getQueryParam=new Function("p","d","u",""

+"var s=this,v='',i,t;d=d?d:'';u=u?u:(s.pageURL?s.pageURL:s.wd.locati"

+"on);if(u=='f')u=s.gtfs().location;while(p){i=p.indexOf(',');i=i<0?p"

+".length:i;t=s.p_gpv(p.substring(0,i),u+'');if(t){t=t.indexOf('#')>-"

+"1?t.substring(0,t.indexOf('#')):t;}if(t)v+=v?d+t:t;p=p.substring(i="

+"=p.length?i:i+1)}return v"); s.p_gpv=new Function("k","u",""

+"var s=this,v='',i=u.indexOf('?'),q;if(k&&i>-1){q=u.substring(i+1);v"

+"=s.pt(q,'&','p_gvf',k)}return v"); s.p_gvf=new Function("t","k",""

+"if(t){var s=this,i=t.indexOf('='),p=i<0?t:t.substring(0,i),v=i<0?'T"

+"rue':t.substring(i+1);if(p.toLowerCase()==k.toLowerCase())return s."

+"epa(v)}return ''");

/********************************************************************

* Commented example of how to use this is doPlugins function

*******************************************************************/

/* Plugin Example: getQueryParam 2.3

//single parameter

Implementing Analytics Using JavaScript

s.campaign=s.getQueryParam('cid');

//multiple parameters

s.campaign=s.getQueryParam('cid,sid',':');

//non-page URL example

s.campaign=s.getQueryParam('cid','',document.referrer);

//parent frame example

s.campaign=s.getQueryParam('cid','','f');

/********************************************************************

* Config variables (should be above doPlugins section)

*******************************************************************/

None

/********************************************************************

* Utility functions that may be shared between plug-ins (name only)

*******************************************************************/

None

230

getTimeParting

The getTimeParting plug-in populates reports with hour of day, day of week, and weekend and weekday values.

This plug-in is useful in performing analysis based on the time of day or day of week. It can help to answer the following questions:

• Across a large date range, what is the most popular time of day for visitors to access my site?

• Are there days of the week on which conversion is higher on my site?

• How do my weekend sales compare to my weekday sales?

• Does a certain marketing campaign generate higher conversions in the morning, or in the afternoon?

This plug-in captures the date and time information available in the user's web browser. It obtains the hour of the day and the day of the week from this information. It then converts this data to the time zone of your choosing. It also accounts for Daylight Savings Time.

Analytics.

Plug-in Code

Config Section

Place the following code in the area of the s_code.js

file labeled CONFIG SECTION, and make the necessary updates as described below.

s._tpDST

- an array of DST values. The array is structured in the following format:

YYYY:'MM/DD,MM/DD'

//time parting configuration

//Australia s._tpDST = {

2012:'4/1,10/7',

Implementing Analytics Using JavaScript 231

2013:'4/7,10/6',

2014:'4/6,10/5',

2015:'4/5,10/4',

2016:'4/3,10/2',

2017:'4/2,10/1',

2018:'4/1,10/7',

2019:'4/7,10/6'}

//US s._tpDST = {

2012:'3/11,11/4',

2013:'3/10,11/3',

2014:'3/9,11/2',

2015:'3/8,11/1',

2016:'3/13,11/6',

2017:'3/12,11/5',

2018:'3/11,11/4',

2019:'3/10,11/3'}

//Europe s._tpDST = {

2012:'3/25,10/28',

2013:'3/31,10/27',

2014:'3/30,10/26',

2015:'3/29,10/25',

2016:'3/27,10/30',

2017:'3/26,10/29',

2018:'3/25,10/28',

2019:'3/31,10/27'}

Note for Northern Hemisphere clients: in the array DST values are DST start, DST end.

Note for Southern Hemisphere clients: in the array DST values are DST end, DST start.

Parameters

var tp = s.getTimeParting(h,z);

• h = (required) Hemisphere - Specify what hemisphere you are converting the time to. This is a value of 'n' or 's'.

This is used to determine how to use the DST array passed. If 'n' is passed the plugin uses the dates when DST is on. If 's' is passed the plugin uses the dates when DST is off.

• z = (optional) Time Zone - If you would like the data to be based upon a specific time period, then that will need to be specified as the hours different from GMT here. Note this should be the GMT during non DST. If no value is specified, it defaults to GMT (i.e. '-5' for US Eastern Time)

Returns

Returns a concatenated value of time at minute level and day of week, for example:

8:03 AM|Monday

You can then use

Classifications

to group visits into time periods. For example, you could set up a rule in Classification

Rule Builder to bucket visits between 9:00 AM and 9:59 AM to "9:00 AM - 10:00 AM". As an alternative to classifications, you could provide additional client-side logic to bucket visits in JavaScript.

Example Call

var tp = s.getTimeParting('n','-7'); s.prop1 = tp;

PLUGINS SECTION

Add the following code to the PLUGINS SECTION in the s_code.js

file.

* Plugin: getTimeParting 3.4

Implementing Analytics Using JavaScript 232 s.getTimeParting=new Function("h","z",""

+"var s=this,od;od=new Date('1/1/2000');if(od.getDay()!=6||od.getMont"

+"h()!=0){return'Data Not Available';}else{var H,M,D,U,ds,de,tm,da=['"

+"Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturda"

+"y'],d=new Date();z=z?z:0;z=parseFloat(z);if(s._tpDST){var dso=s._tp"

+"DST[d.getFullYear()].split(/,/);ds=new Date(dso[0]+'/'+d.getFullYea"

+"r());de=new Date(dso[1]+'/'+d.getFullYear());if(h=='n'&&d>ds&&d<de)"

+"{z=z+1;}else if(h=='s'&&(d>de||d<ds)){z=z+1;}}d=d.getTime()+(d.getT"

+"imezoneOffset()*60000);d=new Date(d+(3600000*z));H=d.getHours();M=d"

+".getMinutes();M=(M<10)?'0'+M:M;D=d.getDay();U=' AM';if(H>=12){U=' P"

+"M';H=H-12;}if(H==0){H=12;}D=da[D];tm=H+':'+M+U;return(tm+'|'+D);}");

Notes

• Always test plug-in installations to ensure that data collection is as expected before deploying to production.

• Configuration variables must be set for plugin to work correctly.

getValOnce

The getValOnce plug-in prevents a given variable from being set to the previously defined value. It uses a cookie to determine a variable's last seen value. If the current value matches the cookie value, the variable is overwritten with a blank string before it is sent to Adobe's processing servers. This plug-in is useful to prevent conversion variable instance inflation caused when users refresh the page or click the Back button.

Important: This plug-in has not been validated to be compatible with

AppMeasurement for JavaScript . See

AppMeasurement Plug-in Support .

Parameters

s.eVar1=s.getValOnce(variable,cookie,expiration,minute);

• Variable: The variable that will be checked. This is typically the same as the variable being defined.

• Cookie: The name of the cookie that stores the previous value to compare against. The cookie can be any value.

• (Optional) Expiration: The number of days the cookie will expire. If not set or set to 0, the default expiration is the browser session.

• (Optional) Minute: If you set this to the string value m, the expiration value is defined in minutes instead of days.

If not set, days is the default expiration.

Properties

• This plug-in is commonly used on conversion variables. However, you can use it on any Analytics variable.

• When Javascript encounters this function, it compares the defined value to what is stored in the cookie. If the defined value is different from the cookie value, the defined value is set. If the defined value is the same as the cookie value, an empty string is returned.

• The cookie can only store a single value, meaning the plug-in only looks as the last defined value.

• The plug-in does not stop all values from defining the variable after it is defined. The plug-in only prevents the last value from being set multiple times consecutively.

• If the end user blocks or rejects cookies, the original value is always returned.

• The plug-in's session is different from what Analytics defines as a session (or visit). Analytics terminates a session after 12 hours of activity or 30 minutes of inactivity. Because the plug-in uses the browser's session definition, it is terminated only after the user closes the tab or exits the browser.

• If a user closes your page, opens a different tab and navigates back to your site within 30 minutes, the plug-in creates a new session while keeping the Analytics visit open.

• If a user keeps the browser window open without clicking on a link for more than 30 minutes, the Analytics visit expires while keeping the browser session open.

Implementing Analytics Using JavaScript 233

Analytics.

Implementation

Note: If your organization uses Marketing Channels and has rules set up based on s.campaign

, it is recommended that you not use the getValOnce plugin when setting the

s.campaign value. Doing so could lead to an incorrect channel being assigned on a secondary campaign click-through.

To implement this plug-in, place the following code within your s_code.js

file

/********************************************************************

* Main Plug-in code (should be in Plug-ins section)

*******************************************************************/

* Plugin: getValOnce_v1.11

*/ s.getValOnce=new Function("v","c","e","t",""

+"var s=this,a=new Date,v=v?v:'',c=c?c:'s_gvo',e=e?e:0,i=t=='m'?6000"

+"0:86400000,k=s.c_r(c);if(v){a.setTime(a.getTime()+e*i);s.c_w(c,v,e"

+"==0?0:a);}return v==k?'':v");

Once the above code is implemented, define the desired variable using the getValOnce function. The following are several examples on how it can be implemented:

Preventing the same campaign value from being defined if a duplicate value is detected within 30 days of cookie being set:

s.campaign=s.getValOnce(s.campaign,'s_cmp',30);

Prevents the same eVar1 value from being defined if a duplicate value is detected within 30 minutes of the cookie being set:

s.eVar1=s.getValOnce(s.eVar1,'s_ev1',30,'m');

Prevents the same eVar2 value from being defined multiple times in the same browser session:

s.eVar2=s.getValOnce(s.eVar2,'s_ev2');

Notes

• Always test plug-in installations extensively to ensure that data collection is as expected before deploying in a production environment.

• Make sure you delete the cookie or use new, unique values during testing or variables will not be sent.

getVisitNum

The getVisitNum plug-in determines how many visits a user has made to your site and captures this number in a

Analytics variable.

Plug-in Code and Implementation

CONFIG SECTION: No changes required for this section.

Plug-in Configuration

Implementing Analytics Using JavaScript 234

Place the following code within the s_doPlugins() function, which is located in the area of the s_code.js file labeled

Plugin Config. Choose one Custom Traffic (s.prop) variable or one Custom Conversion (s.eVar) variable for use in capturing visit number data. This should be a variable that has been enabled using the Admin Console, but which is not currently in use for another purpose. You can use the following example and update it based on your requirements.

s.prop1=s.getVisitNum();

Analytics.

PLUGINS SECTION: Add the following code to the area of the s_code.js

file labeled PLUGINS SECTION. Do not make any changes to this portion of the plug-in code.

* Plugin: getVisitNum - version 3.0

*/ s.getVisitNum=new Function("tp","c","c2",""

+"var s=this,e=new Date,cval,cvisit,ct=e.getTime(),d;if(!tp){tp='m';}"

+"if(tp=='m'||tp=='w'||tp=='d'){eo=s.endof(tp),y=eo.getTime();e.setTi"

+"me(y);}else {d=tp*86400000;e.setTime(ct+d);}if(!c){c='s_vnum';}if(!"

+"c2){c2='s_invisit';}cval=s.c_r(c);if(cval){var i=cval.indexOf('&vn="

+"'),str=cval.substring(i+4,cval.length),k;}cvisit=s.c_r(c2);if(cvisi"

+"t){if(str){e.setTime(ct+1800000);s.c_w(c2,'true',e);return str;}els"

+"e {return 'unknown visit number';}}else {if(str){str++;k=cval.substri"

+"ng(0,i);e.setTime(k);s.c_w(c,k+'&vn='+str,e);e.setTime(ct+1800000);"

+"s.c_w(c2,'true',e);return str;}else {s.c_w(c,e.getTime()+'&vn=1',e)"

+";e.setTime(ct+1800000);s.c_w(c2,'true',e);return 1;}}"); s.dimo=new Function("m","y",""

+"var d=new Date(y,m+1,0);return d.getDate();"); s.endof=new Function("x",""

+"var t=new Date;t.setHours(0);t.setMinutes(0);t.setSeconds(0);if(x=="

+"'m'){d=s.dimo(t.getMonth(),t.getFullYear())-t.getDate()+1;}else if("

+"x=='w'){d=7-t.getDay();}else {d=1;}t.setDate(t.getDate()+d);return "

+"t;");

Parameters

• tp = (string, optional) Tracking period. use "d" for day, "w" for week, "m" for month, or a number for a custom number of days.

• If day, week, or month is selected then the visit number will reset at the end of the day/week/month.

• If a custom number of days is selected then the visit number will reset after that number of days.

• If no value is provided then "m" will be used.

• c = (string, optional) Specify the persistent cookie name. Default is 's_vnum'.

• c2 = (string, optional) Specify the session cookie name. Default is 's_invisit'

Returns

• returns the visit number (1,2,3,etc) of the visit. This number is incremented only on the first page of each visit.

• returns "unknown visit number" if the plug-in is unable to identify the visit number (cookies are blocked).

Examples

s.prop1=s.getVisitNum(365); //custom length, 365 days. Default cookie names s.prop1=s.getVisitNum('w'); //resets weekly s.prop1=s.getVisitNum('m','s_vmonthnum','s_monthinvisit'); //resets montly, custom cookie names s.prop1=s.getVisitNum('d'); //resets daily

Notes

Implementing Analytics Using JavaScript 235

• Always test plug-in installations extensively to ensure that data collection is as expected before deploying in a production environment.

• This plug-in relies on the ability to set cookies in the user's web browser. If the user does not accept cookies, all visits will appear to be first visits.

performanceTiming

This plug-in operates by using the Navigation Timing JavaScript API for accurately measuring performance on the web. This provides a native method to get accurate and detailed timing statistics for page load events & asset load times. Previously, measurements of this sort have either utilized the JavaScript Date object for timing metrics, or a rudimentary extrapolation of the Navigation Timing metrics. Both methodologies, even though they provide some trended data for page load times, are unreliable.

What This Plug-In Does

Important: This is a beta version of the plugin, and additional updates may be forthcoming.

This plug-in utilizes the following detailed events to track the individual timing components of a page load:

Event Name

Redirect Timing

App Cache Timing

DNS Timing

TCP Timing

Request Timing

Response Timing

Processing Timing onLoad Timing

Total Page Load Time

Performance Instances

Calculated From

fetchStart - navigationStart domainLookupStart - fetchStart domainLookupEnd - domainLookupStart connectEnd - connectStart responseStart - connectEnd responseEnd - responseStart loadEventStart - domLoading loadEventEnd - loadEventStart loadEventEnd - navigationStart

Counter

The following graph illustrates the timing attributes defined by the PerformanceTiming interface and the

PerformanceNavigation interface with or without redirect, respectively.

Implementing Analytics Using JavaScript 236

Full details on the Navigation Timing object can be found here:

http://www.w3.org/TR/navigation-timing/#sec-navigation-timing-interface

In addition, the plugin can optionally use the performanceEntries object to record the asset name, asset load time start, and asset load time duration details for each individual asset loaded on a given page. A large amount of information is recorded with this plugin, and as such it requires that the DOM storage object is enabled in order to store the page load information between page views. Please be sure that your company’s privacy policy allows for the use of the DOM storage object before enabling this functionality. It also requires the use of a listVar to track all assets.

Required Supporting Plug-Ins

• appendList

• getPreviousValue

Plug-In Code and Implementation

Note: The following instructions require you to alter the data collection code on your site. This can affect data collection on your site, and should be done only by a developer with experience using and implementing Adobe

Analytics. This plugin is compatible only with AppMeasurement tracking libraries.

Config Section (before doPlugins):

s.pte

: Comma-separated list of events containing the 10 events you wish to use - the individual timing event components (events 1 - 8), the total page load time (event 9), and total performance instances (event 10) - in that specific order.

s.ptc

: Set to determine whether or not to execute the plugin within doPlugins. Always set to false.

Implementing Analytics Using JavaScript 237

Sample Calls

s.pte = 'event10,event11,event12,event13,event14,event15,event16,event17,event18,event19'

//[--------------------------- 1 to 8 ---------------------------][-- 9 --][- 10 -] s.ptc = false;

doPlugins Section:

To initialize the plug-in, one line of code is required in the doPlugins

section of your s_code, preferably after you have designated the s.pageName variable. If you wish to utilize the asset load time functionality within the plug-in, you must pass in the name of the list variable to be used. Otherwise, only the performance timing entries will be tracked in the events you previously specified in the s.pte

variable.

Note: In order to correlate performance timing entries with pages on your site, you must also initialize the getPreviousValue

plug-in. We recommend comparing these performance entries with either the previous page name or the previous page URL value.

Sample Calls

/* Performance Timing */ s.eVar9 = s.getPreviousValue(s.pageName,'gpv_v9',''); //Record the previous page name in the

designated eVar of your choice s.performanceTiming('list2')

Plugins Section:

Lastly, add the plug-in itself to your JavaScript implementation.

/* Plugin: Performance Timing Tracking - 0.11 BETA */ s.performanceTiming=new Function("v",""

+"var s=this;if(v)s.ptv=v;if(typeof performance!='undefined'){if(perf"

+"ormance.timing.loadEventEnd==0){s.pi=setInterval(function(){s.perfo"

+"rmanceWrite()},250);}if(!s.ptc||s.linkType=='e'){s.performanceRead("

+");}else{s.rfe();s[s.ptv]='';}}"); s.performanceWrite=new Function("",""

+"var s=this;if(performance.timing.loadEventEnd>0)clearInterval(s.pi)"

+";try{if(s.c_r('s_ptc')==''&&performance.timing.loadEventEnd>0){try{"

+"var pt=performance.timing;var pta='';pta=s.performanceCheck(pt.fetc"

+"hStart,pt.navigationStart);pta+='^^'+s.performanceCheck(pt.domainLo"

+"okupStart,pt.fetchStart);pta+='^^'+s.performanceCheck(pt.domainLook"

+"upEnd,pt.domainLookupStart);pta+='^^'+s.performanceCheck(pt.connect"

+"End,pt.connectStart);pta+='^^'+s.performanceCheck(pt.responseStart,"

+"pt.connectEnd);pta+='^^'+s.performanceCheck(pt.responseEnd,pt.respo"

+"nseStart);pta+='^^'+s.performanceCheck(pt.loadEventStart,pt.domLoad"

+"ing);pta+='^^'+s.performanceCheck(pt.loadEventEnd,pt.loadEventStart"

+");pta+='^^'+s.performanceCheck(pt.loadEventEnd,pt.navigationStart);"

+"s.c_w('s_ptc',pta);if(sessionStorage&&navigator.cookieEnabled&&s.pt"

+"v!='undefined'){var pe=performance.getEntries();var tempPe='';for(v"

+"ar i=0;i<pe.length;i++){tempPe+='!';tempPe+=pe[i].name.indexOf('?')"

+">-1?pe[i].name.split('?')[0]:pe[i].name;tempPe+='|'+(Math.round(pe["

+"i].startTime)/1000).toFixed(1)+'|'+(Math.round(pe[i].duration)/1000"

+").toFixed(1)+'|'+pe[i].initiatorType;}sessionStorage.setItem('s_pec"

+"',tempPe);}}catch(err){return;}}}catch(err){return;}"); s.performanceCheck=new Function("a","b",""

+"if(a>=0&&b>=0){if((a-b)<60000&&((a-b)>=0)){return((a-b)/1000).toFix"

+"ed(2);}else{return 600;}}"); s.performanceRead=new Function("",""

+"var s=this;if(performance.timing.loadEventEnd>0)clearInterval(s.pi)"

+";var cv=s.c_r('s_ptc');if(s.pte){var ela=s.pte.split(',');}if(cv!='"

+"'){var cva=s.split(cv,'^^');if(cva[1]!=''){for(var x=0;x<(ela.lengt"

+"h-1);x++){s.events=s.apl(s.events,ela[x]+'='+cva[x],',',2);}}s.even"

+"ts=s.apl(s.events,ela[ela.length-1],',',2);}s.linkTrackEvents=s.apl"

+"(s.linkTrackEvents,s.pte,',',2);s.c_w('s_ptc','',0);if(sessionStora"

+"ge&&navigator.cookieEnabled&&s.ptv!='undefined'){s[s.ptv]=sessionSt"

+"orage.getItem('s_pec');sessionStorage.setItem('s_pec','',0);}else{s"

+"[s.ptv]='sessionStorage Unavailable';}s.ptc=true;");

/* Remove from Events 0.1 - Performance Specific,

Implementing Analytics Using JavaScript 238 removes all performance events from s.events once being tracked. */ s.rfe=new Function("",""

+"var s=this;var ea=s.split(s.events,',');var pta=s.split(s.pte,',');"

+"try{for(x in pta){s.events=s.rfl(s.events,pta[x]);s.contextData['ev"

+"ents']=s.events;}}catch(e){return;}");

/* Plugin Utility - RFL (remove from list) 1.0*/ s.rfl=new Function("l","v","d1","d2","ku",""

+"var s=this,R=new Array(),C='',d1=!d1?',':d1,d2=!d2?',':d2,ku=!ku?0:"

+"1;if(!l)return'';L=l.split(d1);for(i=0;i<L.length;i++){if(L[i].inde"

+"xOf(':')>-1){C=L[i].split(':');C[1]=C[0]+':'+C[1];L[i]=C[0];}if(L[i"

+"].indexOf('=')>-1){C=L[i].split('=');C[1]=C[0]+'='+C[1];L[i]=C[0];}"

+"if(L[i]!=v&&C)R.push(C[1]);else if(L[i]!=v)R.push(L[i]);else if(L[i"

+"]==v&&ku){ku=0;if(C)R.push(C[1]);else R.push(L[i]);}C='';}return s."

+"join(R,{delim:d2})");

Notes

• Always test plug-in installations to ensure that data collection is as expected before deploying in a production environment.

• Because the plug-in passes the performance data as they are associated with the previous page, data is not collected for the final page view of the visit.

• If you are tracking asset timing, this plug-in relies on the ability to set DOM storage values in the user's web browser.

If the user does not accept cookies and have DOM storage enabled, the plug-in will not pass data into Analytics.

• A very small percentage of users will not pass navigation timing data due to browser limitations, and logic is contained within the plugin to ensure that the data is not skewed as a result – particularly with a small portion of mobile browsers. However, this plug-in has been successfully tested in IE, Firefox, Chrome, and Safari.

• Calculated metrics should be created to aid in summarizing and understanding visitor behavior associated with these metrics:

• Average Redirect Timing (Redirect Timing/Performance Timing Instances)

• Average App Cache Timing (App Cache Timing/Performance Timing Instances)

• Average DNS Timing (DNS Timing/Performance Timing Instances)

• Average TCP Timing (TCP Timing/Performance Timing Instances)

• Average Request Timing (Request Timing/Performance Timing Instances)

• Average Response Timing (Response Timing/Performance Timing Instances)

• Average Processing Timing (Processing Timing/Performance Timing Instances)

• Average onLoad Timing (onLoad Timing/Performance Timing Instances)

• Average Page Load Timing (Total Page Load Time/Performance Timing Instances)

trackTNT

Collects the information for the Target to Analytics integration. This plug-in is replaced by the Adobe Analytics and

Adobe target integration.

See

Adobe Analytics and Adobe Target integration

Pathing

Pathing is defined as the path that users take through your site.

For example, a visitor went to page A, then page B, then page C. Pathing is one of the very powerful features of

Analytics. The tremendous insight it brings is critical to businesses looking to understand visitor traffic patterns.

Out-of-the-box Analytics provides pathing at the page level. The basic idea behind pathing is you are shown the order of pages that users saw during their visits. This data is presented in several different reports that format the data in different ways, depending on what you are trying to see.

Implementing Analytics Using JavaScript 239

Note: To enable pathing, go to Admin > Report Suites > Edit Settings > Traffic > Traffic Variables. To enable pathing on the Site Section and Server reports, contact Customer Care.

Enabling Pathing on a prop

Though pathing reports are available out-of-the-box for pages, pathing can also be enabled for custom traffic variables.

Enabling pathing on a prop can be done in the Admin Console. The following list contains few examples of a business question that can be solved by enabling pathing for a prop.

• Where does a user go on my site after they come to my site from a campaign?

• What are the common site sections my users go to in their visits?

• How do I see page pathing by user type?

Advanced pathing is available in Ad hoc analysis. Ad hoc analysis provides segmentation on any report on the fly without needing to enable this setting, or structure data in the prop in certain ways. It is the easiest and most optimal way to segment your path reports as well. For more information see the

Ad hoc analysis documentation

When pathing is enabled for a prop, you get a new set of pathing reports that are found below the standard pathing reports. Pathing reports tell you the order that it saw the pages come in for that visitor. When you enable pathing on a prop, it does the same thing: it tells you the order of the prop values it saw come in for the user. This order of values is displayed in different ways depending on the path report you are viewing.

Note: To enable pathing, go to Admin > Report Suites > Edit Settings > Traffic > Traffic Variables. To enable pathing on the Site Section and Server reports, contact Customer Care.

Pathing by Campaign or Tracking Code

Helps you answer the question, "After a user clicks into my site from a campaign, where do they go on my site?"

To answer this question, you need to set aside an sprop to be used for this report. You then need to structure the data to populate into the prop in such a way that it makes sense when pathing is enabled.

For this example, you are going to use prop1 as your campaign pathing prop. Now you want to populate this sprop with the same value you put in the page name variable. See below: s.prop1=s.pageName;

You should do this on all pages unless the person has clicked from a campaign. If they have clicked from a campaign and are on the landing page of the campaign, then you populate the prop with a concatenation of the campaign and the pagename. See below:

s.prop1=s.campaign + ‘ : ’ + s.pageName;

If the campaign they clicked was named "banner1234," and the page it landed on was named "Home Page," the value in that prop would be "banner1234 : Home Page." On every subsequent page you put the pagename in the prop as shown above.

When a user clicks this campaign and views four total pages in that visit, you get the following values in the sprop in this order:

“banner1234 : Home Page” > “Page 2” > “Page 3” > “Page 4”

Implementing Analytics Using JavaScript 240

With our data captured in prop1 in this way, with pathing enabled on this prop, you can now look at one of various pathing reports to understand how they path through the site after they click from a campaign.

You can specify the start page from which to start the path report. In this case, you selected "banner1234 : Home

Page", because you want to know where users went after they clicked from campaign "banner 1234." This report is only an example of one of many path reports.

Reasons Pathing may not be Recorded

List of reasons pathing information might not be recorded and displayed in reporting.

• Pathing has not been enabled for that prop in that report suite. This enablement is report suite specific.

• Data is not being passed into the correct prop.

• Pathing has been enabled and the data is in the prop, but it hasn't shown up in the reports. Though the sprop data may show up within 10 minutes, the pathing data will not show up until the visitor's session has ended. It ends after

30 minutes of inactivity. Analytics then takes another 10 minutes to finish the processing of the path data for final presentation in reports.

If you have checked all of these and the data is still not showing up, check with Customer Care for further debugging.

Moving from Section to Section

If you want to know how visitors move from section to section on your site, you first need to ensure that you are tagging your sections with the channel variable.

With this data in place, you must have pathing enabled on the channel variable. If a user starts on the home page and moves to the Sports section, then to the News section, this activity shows up in the Site Section path reports.

These reports display after pathing is enabled on this variable.

Moving from Page Template to Page Template

If your site has types of pages or page templates, you could use pathing to understand how they move from type to type.

You need to first capture the page type or template in a prop set aside for only that purpose. Then have Adobe

Customer Care enable pathing on that prop. You can now view your page template pathing reports to understand how users move from template to template on your site.

Segmenting Paths by User Type

Segmenting paths by user type is a common request for trying to understand how specific user types path on your site.

You can concatenate the user type and page name into a sprop and enable pathing on the sprop.

For example, let's say you have two user types: "Registered" users and "Non-Registered" users. You need to distinguish between these two user types on each page and put these values into your designated sprop. When you populate the prop, it should display as shown below:

s.prop1=”Registered : “ + s.pageName;

If the user is a registered user and visited the home page, the value in the prop displays as follows:

“Registered : Home Page”

If they click to another page named "Page 2", the value on that page displays as follows:

“Registered : Page 2”

Implementing Analytics Using JavaScript 241

With Pathing turned on, you see those two values in succession. If you want to know how registered users move from the home page, find the value "Registered : Home Page" in one of the path reports and see the next pages they visited. In this case, they next went to "Page 2."

Purchase Events

For the purchase event, Analytics variables are used to capture specific purchase information. The s.purchaseID variable is used to serialize (de-duplicate) the event.

The purchaseID is limited to 20 characters. The purchaseID variable serializes all events passed in the variable

s.events, and overrides any serialization value for events. If purchaseID is left blank, each instance of the purchase event, even page reloads, is counted.

If a purchase event is called without a purchaseID, a unique one is automatically generated based on the s.products and s.events variables. This automatically generated purchaseID is stored locally as a cookie value within the visitor's browser, and is not sent to any report suite tables. Manually defined purchaseIDs on the other hand are sent to a back-end table within the report suite. The last five purchases made by a visitor (with or without purchaseID) are stored in the local cookie.

When a visitor makes any purchase, the following checks are made:

• Does the purchaseID match any of the five cookie values? If so, the image request is considered a duplicate purchase. All conversion variables, including the purchase event, do not appear in reporting.

• If purchaseID is defined, does it match any value in the report suite's back-end table? If so, the image request is considered a duplicate purchase. All conversion variables, including the purchase event, do not appear in reporting.

• If the purchaseID is unique to both the last 5 stored values in the cookie and the report suite's purchaseID table, the image request is unique and included in reporting. For example, if five purchases are already included in the local cookie, the oldest one is overwritten.

Specific server-side code can be used to generate the unique number (alphanumeric value) embedded in the HTML source. Usually the Order ID, or similar alphanumeric value, is used for this purpose. This value should not change if the user refreshes the page. The following is a short example (note the purchaseID code in bold):

Syntax

s.products="Category;ProductName;Qty;total_price [,Category2;ProductName2;Qty;total_price]" s.state="XX" s.zip="00000"

s.purchaseID="<%=getPurchaseID()%>"

s.events="purchase"

Examples

s.products="Footwear;Hiking Boots (1234);1;170.00" s.state="UT" s.zip="84097" s.purchaseID="12341234" s.events="purchase"

Additional Notes

• Be sure to use server-side code to generate the unique identifier for the event. Do not use a JavaScript randomization function to generate a number, which generates unique numbers each time the page is loaded (each

instance/pageview counts).

• The unique identifiers are applicable to all users across all sessions. Therefore, ensure the identifier is unique across users and sessions. For instance, if the Order ID repeats after 30 days, append the date of the order to make the Order ID sufficiently unique.

Implementing Analytics Using JavaScript 242

• The serialization value may be alphanumeric values up to 20 characters in length. This is identical to the limitations of s.purchaseID (replace s. with s_ for G Code).

• The s.purchaseID variable serializes all events passed in the variable s.events, and overrides any serialization value for events. Do not use Event serialization for any events if the s.purchaseID variable is used on the current page (replace s. with s_ for G Code).

Event Serialization

Event serialization is the process of implementing measures to prevent duplicate events from entering Analytics reporting. This can commonly occur when a user refreshes the page multiple times, navigates to a certain page multiple times, or saves the web page to their computer (for example, if a customer saves a purchase confirmation page to their computer, every time they view it orders and revenue would be counted again if event serialization was not in place).

Event serialization is useful in the following instances:

• A page may be reloaded or refreshed and repeatedly send an event. Event serialization prevents events from being recounted by using a serial number for each event.

• The user saves the page to his/her machine for later review. This scenario is quite common on purchase confirmation pages to review purchase receipts. Event serialization prevents the subsequent page reloads from re-counting the events.

Note: Data Sources does not support event serialization or de-duplication.

This document describes the process used to implement Event serialization for conversion and custom events.

To use Event serialization, you must first enable it in Admin > Report Suite > [select report suite] > Edit Settings

> Success Events. Then select which events you want recorded in the Unique Event Recording column.

Default Behavior

The default behavior is to count each instance of an event. An event is set for each pageviewthat is counted, even on page reloads or page refreshes. The s.purchaseID variable is used in order to uniquely identify each order

(purchase). This allows a user to reload the order page without recounting the order, revenue, or products. A similar feature is available for all events. This includes pre-defined events such as prodView and scCheckout, as well as all custom events.

Methods of Event Serialization

There are two methods of keeping events from counting more than once.

To use Event serialization, you must first enable it in Admin > Report Suite > [select report suite] > Edit Settings

> Success Events. Then select which events you want recorded in the Unique Event Recording column. There are three different settings an event can be set to.

Always record event: This is the default behavior of all events when initially enabled. All events included in image requests will be sent directly to Analytics, including page reloads.

Record once per visit: An event with this setting enabled will only track the first instance of that event in a given visit. Once a new visit starts, each event with this setting enabled can be tracked again. This is an effective way to mitigate duplicate events via browser refreshes.

Use event ID: This setting allows the capability to associate each event with a unique ID. If Analytics sees an eventID it has already seen before with that variable, it will not be counted in reporting.

Implementing Analytics Using JavaScript 243

The only event that cannot have event serialization enabled is the purchase event, as this uses the s.purchaseID

variable. All other eCommerce events and custom events can have these settings enabled.

• Use a unique identifier to let an event fire once per unique ID.

• Send multiple events, then use configure Analytics to let an event fire once per visit.

To implement Event serialization, provide a unique ID for the event, for example event1:1234ABCD.

Event Serialization - Once per Unique ID

Once Event serialization is implemented, and Analytics receives a duplicate number, it ignores the event. An event is counted only once per unique value. If the number is unique, another event instance is counted, as shown in the following example:

User Name

John

Description Event Syntax

Analytics Total Event1

Count

Stacy

Jill

Jamie

User views page for the first time.

event1:1000

User reloads the page (a form submit may fail, and cause the page to reload).

event1:1000 event1:1001

User reloads the page (a form submit may fail, and cause the page to reload).

event1:1001

User views page for the first time, enters information correctly, and moves on to next page.

event1:1002

User views page for the first time event1

User forgets to fill in the last name field on the form. The form is displayed again with the missing information highlighted.

event1

s.events Syntax

Use the following syntax for serializing events. In the first example, event1 is serialized, while event2 is not serialized

(an instance is counted for each pageview or page reload).

s.events="[event]:[serial number]"

Samples: s.events="event1:12341234" s.events="event1:12341234,event2" s.events="purchase,event1:12341234"

Serializing a counter event with a value other than 1

Add the serial number after the event value similar to the following: s.events="event1=100:12341234"

Note the following when selecting serialization IDs:

• Serialization IDs must be 20 characters or less.

• Serialization IDs must be alphanumeric characters.

• Serialization IDs are separate for each success event. Therefore, you can use the same ID for multiple success events if needed, just not for the same success event.

Implementing Analytics Using JavaScript 244

• Serialization IDs are tied to the report suite, so if you are using multi-suite tagging to send data to multiple report suites, keep this in mind.

• Serialization IDs never expire, so even if the same ID is used years later, the success event will not be counted again.

• Cookie deletion does not prevent Event ID serialization because serialization IDs are stored on Adobe servers and are not cookie-based.

• The one success event with which it is not possible to use Event ID serialization is the Purchase event, which uses a special s.purchaseID variable for serialization.

Event Serialization - Once per Visit

Analytics offers a feature to let an event only fire once per visit.

This can be enabled from the UI: Admin > Report Suite > Edit Settings > Conversion > Success Events.

Serializing eVars

The same functionality used to keep an event from being fired more than once per visit can be applied to evar instances. When enabled for an evar, click-throughs and instances are only counted once per visit for a specific

evar. This is not counting once per value, but once per evar. This means that if an evar or campaign variable is set to record once per visit, only the first value seen in a visit shows a click-through or instance. However, if the evar is set to allocate credit to the most recent value, then the most recent value still receives credit, even if it does not have an instance. The following example helps to illustrate this point.

If s.campaign is set to Record once per visit, and within a single visit 20, pages are viewed. First, there are 10 pages where s.campaign is set to "abc," then 10 pages are viewed where s_campaign is set to "xyz." On all 20 pages, event1 is fired. The following screen shot illustrates the results. Notice that there are no instances or

Click-throughs associated with "xyz," but it does receive credit for all events fired.

Identifying Unique Visitors

Adobe uses a cookie to track unique browsers/devices.

Analytics Visitor ID Order

Adobe Analytics provides several mechanisms to identify visitors. The following table lists the different ways a visitor can be identified in Analytics (in order of preference):

Order

Used

Query Parameter (collection method)

vid (s.visitorID)

Present When

s.visitorID is set

aid (s_vi cookie)

Visitor had an existing s_vi cookie before you deployed the

Visitor ID service, or you have a visitor ID grace period configured.

Implementing Analytics Using JavaScript 245

Order

Used

Query Parameter (collection method) Present When

mid (AMCV_ cookie set by Marketing Cloud

Visitor ID service)

Visitor's browser accepts cookies (first-party)

fid (fallback cookie on H.25.3 or newer, or

AppMeasurement for JavaScript)

IP Address, User Agent, Gateway IP

Address

Visitor's browser does not accept cookies.

In many scenarios you might see 2 or 3 different IDs on a call, but Analytics will use the first ID present from the previous table as the official visitor ID. For example, if you are setting a custom visitor ID (included in the "vid" query parameter), that ID will be used before other IDs that might be present on that same hit.

Note: Each Analytics visitor ID is associated with a visitor profile on Adobe servers. Visitor profiles are deleted after at least 13 months of inactivity regardless of any visitor ID cookie expiration.

Custom Visitor ID

You can implement a custom method to identify visitors by setting the s.visitorID variable.

A custom Visitor ID can be used on sites where you have unique way to identify visitors. An example of this is an

ID generated when a user logs in to web site using a user name and password.

Should you have the ability to derive and manage the visitor IDs of your users, you can use the following methods to set the ID:

Method

s.visitorID

variable

Query string parameter on the image request

Data Insertion API

Description

If JavaScript is used on the browser, or if you are using any other AppMeasurement library, you can set the visitor ID in a data collection variable.

This lets you pass the visitor ID to Adobe via the vid query string parameter on a hard-coded image request.

URL re-writing and

VISTA

On devices using wireless protocols that don't accept JavaScript, you can send an XML post containing the <visitorid/> XML element to Adobe collection servers from your servers.

Some deployment architectures provide support for using URL re-writing to maintain session state when a cookie cannot be set. In such cases, Adobe engineering services can implement a VISTA rule that would look for the session value in the URL of the page, then format and place into the visid values.

Marketing Cloud ID Service

The Marketing Cloud ID service replaces the legacy Analytics visitor ID mechanism, and is required by heartbeat video measurement, Analytics for Target, and future Marketing Cloud core services and integrations.

See

Marketing Cloud ID Service

for product documentation about this service.

Implementing Analytics Using JavaScript 246

Analytics Visitor ID

When a user visits your site, a persistent cookie is set by the Adobe web server by including it in the HTTP response to the browser. This cookie is set on the specified data collection domain.

When a request is sent to the Adobe data collection server, the header is checked for the visitor ID cookie ( s_vi

If this cookie is in the request, it is used to identify the visitor. If the cookie is not in the request, the server generates a unique visitor ID, sets it as a cookie in the HTTP response header, and sends it back with the request. The cookie is stored in the browser and is sent back to the data collection server during subsequent visits the site, which enables the visitor to be identified across visits.

Third-Party Cookies and CNAME records

Some browsers, such as Apple Safari, no longer store cookies that are set in the HTTP header from domains that do not match the domain of the current website (this is a cookie used in a third-party context, or a third-party cookie).

For example, if you are on mysite.com

and your data collection server is mysite.omtrdc.net

, the cookie that is returned in the HTTP header from mysite.omtrdc.net

might be rejected by the browser.

To avoid this, many customers have implemented CNAME records for their data collection servers as part of a

first-party cookie implementation

. If a CNAME record is configured to map a hostname on the customer's domain to the data collection server (for example, mapping metrics.mysite.com

to mysite.omtrdc.net

), the visitor ID cookie is stored since the data collection domain now matches the domain of the website. This increases the likelihood that the visitor ID cookie will be stored, but it introduces some overhead as you need to configure CNAME records and maintain SSL certificates for data collection servers.

Cookies on Mobile Devices

When mobile devices are tracked using cookies, there are some settings you can use to modify how measurement occurs. Cookie default lifetime is 5 years, but you can use the CL query param variable ( s.cookieLifetime

) to change this default. To set the cookie location for cname implementations, use the CDP query string s.cookieDomainPeriods

. The default is 2 if no value is specified. and the default location is domain.com. For implementations that do not use CNAME, the visitor ID cookie location is at the 207.net domain.

Fallback ID Methods

If other visitor ID methods fail, Adobe sets a fallback cookie or uses a combination of IP address and user agent to identify the visitor.

Fallback Visitor Identification Method

AppMeasurement for JavaScript 1.x and JavaScript H.25.3 (released January 2013) contain a new fallback visitor identification method for visitors whose browser blocks the cookie set by Adobe’s data collection servers (called s_vi

). Previously, if a cookie could not be set, visitors were identified using a combination of the IP address and user agent string during data collection.

With this update, if the standard s_vi

cookie is unavailable, a fallback cookie is created on the domain of the website with a randomly generated unique ID. This cookie, named s_fid

, is set with a 2 year expiration and is used as the fallback identification method going forward. This change should result in increased accuracy in visit and visitor counts in situations where the primary cookie (

AMCV_

or s_vi

) cannot be set.

Visits total includes all visitors that are identified by the s_vi

cookie or by using a fallback method.

Implementing Analytics Using JavaScript 247

IP Address, User Agent, Gateway IP Address

. If the

AMCV_

or s_vi

and the s_fid

cookies cannot be set, visitors are identified using a combination of IP address and User Agent.

Identifying Mobile Devices

Most mobile devices accept browser cookies. However, in cases when devices do not accept cookies, another method is used to uniquely identify wireless devices.

Adobe has identified a number of HTTP

subscriber ID headers

that uniquely identify a majority of mobile devices.

Those headers often include the device phone number (or a hashed version of the number), or other identifiers. The majority of current devices have one or more of the headers that uniquely identify the device, and all Adobe data collection servers automatically use those headers in place of a Visitor ID.

In a typical image request, a '1' in the path (

/b/ss/rsid/1

) causes Adobe servers to return a gif image and to attempt to set a persistent visitor ID cookie (

AMCV_

or s_vi

). However, if the device is recognized as a mobile device based on the HTTP headers, a '5' is passed in place of the '1', which indicates that a wbmp format image should be returned and that our list of recognized wireless headers (not a cookie) should be used to identify the device.

The following table lists out the order of the ID methods used based on the return image type value ('1' or '5') in the path:

Setting

/1/

ID method order

Default:

• Custom visitor ID

• Cookie

• Subscriber ID Header

• IP Address-UserAgent-Gateway IP Address

/5/ /5.1/

/5.5/

Device was identified as a wireless device, or

/5/

was manually sent in the image request:

• Custom visitor ID

• Subscriber ID Header

• Cookie

• IP Address-User Agent-Gateway IP Address

You can also pass a '1' or a '5' in manual image requests, but be aware that these codes are mutually-exclusive, therefore always passing '5' does not leverage a cookie when it is supported.You can incorporate your own mechanism to determine if a device supports cookies, and if so, pass a '1' in the image rather than a '5'. The accuracy improvement in this situation is limited to the number of mobile devices supporting cookies.

Subscriber ID Headers

The subscriber ID method is generally more reliable than a cookie for user identification because of cookie deletion, cookie acceptance issues, and gateway cookie management issues.

You can improve changes of identifying a visitor by being added to the white list for the carrier that your mobile visitors use. To get access to the carrier's visitor ID, contact the carrier to add your domain to their white list. If you are on a carrier's white list, you also have access to subscriber ID headers that you may not otherwise be able to access.

Implementing Analytics Using JavaScript 248

The following list of headers is used to identify wireless devices. The algorithm for processing the headers is to

1. extract the HTTP header key (the name of the header, such as,"X-Up-Calling-Line-ID")

2. trim out all non alpha (A-Z and a-z) characters

3. convert the header key to lowercase

4. compare the end of the key to the ones in the following table to find a match:

Header

callinglineid subno clientid uid clid deviceid forwardedfor msisdn clientip wapipaddr huaweinasip userip ipaddress subscriberinfo

Type

ID or IP Address

IP Address

Example

X-Up-Calling-Line-ID: 8613802423312 x-up-subno: swm_10448371100_vmag.mycingular.net

ClientID: [email protected]

x-jphone-uid: a2V4Uh21XQH9ECNN

X-Hts_clid: 595961714786 rim-device-id: 200522ae

X-Forwarded-For: 127.0.0.1

X-Wap-msisdn: 8032618185

Client-ip: 10.9.41.2

X-WAPIPADDR: 10.48.213.162

x-huawei-NASIP: 211.139.172.70

UserIP: 70.214.81.241

X-Nokia-ipaddress: 212.97.227.125

X-SUBSCRIBER-INFO: IP=10.103.132.128

For example "callinglineid" would match "X-Up-Calling-Line-ID" and "nokia-callinglineid." The header type tells us what to expect in the header. The order of header priority is listed here (if a "callinglineid" header is present it is used instead of "subno").

You can use

Dynamic Variables

to extract specific values from a header.

Cross-Device Visitor Identification

Cross-device visitor identification helps you connect visitors across multiple devices.

This feature works by associating the visitor profiles across each device where a user is uniquely identified. After association, the visitor profile records are merged and visits from each device are considered to be from the same user. This feature allows campaigns from one device, such as a mobile device, to receive credit from conversion events made from another device, such as a desktop. This feature is commonly referred to as 'visitor stitching'.

Important: Cross-Device Visitor Identification fundamentally alters how Adobe Analytics identifies unique visitors and attributes success events. Read this section throughly to fully understand the impacts to determine if this functionality is right for your unique implementation and business requirements.

Benefits of Cross-Device Visitor Identification

• A uniquely identified user is a single visitor profile across each device.

Implementing Analytics Using JavaScript 249

• Attribute success events to first-touch channels cross-device and browsers.

• Gain a more complete, unified view of your customers.

Limitations of Cross-Device Visitor Identification

• Some data is not persisted across authentication from the unauthenticated profile to the authenticated, including:

• eVars or campaign variables with an expiration set to 'Visit'.

• eVars or campaign with longer expirations on a new authentication on a second, third, etc device.

• In some cases marketing channel values, geo-segmentation, and technology reports are affected.

• When initially implemented, Unique Visitor counts are inflated on a visit when authentication first occurs.

• Longer term, Unique Visitor counts will be driven down as users are authenticated across devices.

• Also longer term, Visits will be driven down to a small degree when an authenticated user switches devices within

30 minutes.

How Visitors are Counted without Cross-Device Visitor Identification

With the increasing number of devices used by the same visitor, it can be difficult to accurately gauge unique visitors and correctly attribute first-touch marketing channels. For example, a potential customer clicks a link in a marketing email and views your site for the first time:

This customer is considered a unique visitor and the first-touch email channel is incremented. The next day, this same customer visits your site from a laptop at his office:

Since the device is new, the customer is considered a unique visitor and the first-touch direct channel is incremented.

A few days later, this same customer visits from a mobile device:

Implementing Analytics Using JavaScript 250

The customer is again treated as a unique visitor.

Connecting Users Across Devices

Cross-device visitor identification uses the visitor ID variable, s.visitorID

, to associate a user across devices.

When you provide a visitor ID variable with a hit, the system checks for any other visitor profiles that have a matching

visitor ID. If one exists, the visitor profile that is already in the system is used from that point forward and the previous visitor profile is no longer used.

The visitor ID is typically set after authentication, or after a visitor performs some other action that enables you to uniquely identify them independently of the device that is used. We recommend creating a hash of the username or an internal ID that does not contain any personally identifiable information.

In the

previous example

, after the customer signs on from each device, they are all associated with the same user profile. If the visitor later signs out on a device, stitching continues to work since the visitor IDs that are stored in a cookie on each device are already associated with the same visitor profile. We recommend populating the s.visitorID variable whenever possible in case the visitor ID cookie is deleted.

Unique Visitor and Visits Counts

Consider the following connection sequence for two devices:

Implementing Analytics Using JavaScript 251

On the first data connection

• Visitor de-duplication is not retroactive.

After authentication on the laptop, hits with either visitor ID ( nv1

or cust1

) will be considered the same individual by

Adobe Analytics. However, visitor de-duplication is not retroactive, so 2 unique visitors are counted.

On the first data connection on the mobile device the customer is not recognized so a new unique visitor is counted.

Once the user is authenticated ( cust1

) on the mobile device, Adobe Analytics maps cust1

back to the visitor ID provided on the main site, so no more unique visits are incremented.

Each new device or browser authenticated will add 1 unique visitor.

On subsequent data connections

On subsequent data connections to authenticated devices unique visitors are not incremented.

Data Impact of Cross-Device Visitor Identification

Overview of how enabling cross-device visitor identification affects the data that you see in reports.

Implementing Analytics Using JavaScript 252

To understand how this feature affects data collection, it is useful to understand the visitor data fields in a visitor profile:

Data Field

Visitor ID cookie

Visitor ID variable

Effective Visitor ID

Description

ID generated automatically on the first visit from a device or browser and stored in the s_vi

cookie.

Optional visitor ID that is set using the s.visitorID

variable. This value is populated after a user authenticates and might match an ID that your company uses to track a user across multiple digital marketing channels.

The effective visitor ID is the actual ID for the user profile. This value is set to the visitor ID cookie, or to the visitor ID variable if one is provided.

Example Visit

Example containing a sample of server calls sent in a common customer interaction.

Server Call

2-8

Action

A visitor clicks a link in a marketing email and visits your site from home computer. This visitor has visited your site 7 other times in the past.

Visitor ID

Cookie

Visits 7 additional pages on your site.

Authenticates on home computer.

Visits 1 additional page.

Opens site from laptop at office. This visitor has not visited your site before using this device.

2 -

Visitor ID

Variable

CID1

Effective

Visitor ID

CID1

Visit Page

Number

2-8

Visit Number

Implementing Analytics Using JavaScript

Server Call

Action

Authenticates on laptop.

Views 1 additional page.

Visitor ID

Cookie

Visitor ID

Variable

CID1

Effective

Visitor ID

CID1

253

Visit Page

Number

Visit Number

Visitors

Analytics counts each unique effective visitor ID as a unique visitor.

If you look at the

previous table

, this occurred 3 times: at hits 1, 9, and 10. This occurs because the effective visitor

ID is the same for both server calls, and occurs even though the visits might be several hours apart and on different devices.

This can increase the number of unique visitors you see when cross-device visitor identification is enabled. The visitor might be counted twice on the same visit: once for the initial visit and again after the user is authenticated.

When a new visitor views your site, the s_vi cookie is populated and stored. On the data collection server, a new visitor profile is created for this visitor ID, and the effective visitor ID on the profile is set to match the cookie.

When cross-device visitor identification is enabled, if a visitor ID variable is provided in a subsequent hit (for example, after authentication), the effective visitor ID is updated to match the custom value. This can cause the effective

visitor ID to change directly after authentication, resulting in multiple visitor counts.

After the initial association, visit counts return to normal because the visitor is associated through the visitor ID cookie. If the visitor later views your site and then authenticates, the visitor count is not inflated because the effective

visitor ID doesn't change after authentication.

Implementing Analytics Using JavaScript 254

Visits

Analytics counts a visit each time a server call occurs with a Visit Page Number equal to 1.

If you look at the

previous table

, this occurred 4 times: at hits 1, 9, 11, and 12. Similar to visitors, this value returns

to normal after the initial association because the Visit Page Number is reset back to 1 due to a change in the effective visitor ID.

Create Segments

You can create a segment whenever an association occurs for a given visitor ID cookie.

Based on the

previous table

, if you created a segment where visit number equals 9, it would include server calls 12 and 13. Even through server call 11 was technically part of the same visit, the historical data for that server call is not altered and the visit number remains unchanged.

Geo-Segmentation Data

Geo-Segmentation data is recorded based on the first hit of the visit, and does not change for a single visit regardless of the device used.

If a customer browses your site from his or her home computer, and then from a mobile device within 30 minutes, the Geo-Segmentation data is not changed. If you are using VISTA to populate an eVar with Geo-Segmentation data, it is based on the IP address in each hit. This could result in multiple Geo-Segmentation data values if the IP address changes for the same visit.

Attribution and Persistence

When visitor profiles are merged after being associated with the same visitor ID variable, attribution is not changed in the historical data set.

• When the variable s.visitorID

is set and sent on a hit, the system checks for any other visitor profiles that have a matching visitor ID.

• If a profile exists, the visitor profile that is already in the system is used from that point forward and the previous visitor profile is no longer used.

• If no matching visitor ID is found, a new profile is created.

When an un-authenticated customer first arrives at your site, that customer is assigned a visitor profile by Adobe

Analytics. As shown in

Unique Visitor and Visits Counts

, on authentication a new profile is created. When the new

profile is created, one visit ends and another visit starts.

Implementing Analytics Using JavaScript 255

On the first data connection

The example below is a representation of how data is sent to Adobe Analytics when a customer authenticates for the first time, on the first device:

• eVar16

has an expiration of 1 day and evar17

expires on visit.

• The post_visitor_id

column represents the profile maintained by Adobe Analytics.

• The post_evar16

and post_evar17

columns show shows the persistence of eVars.

• cust_visid

represents a value set in s.visitorID

• Each row is one 'hit', a single request sent to Adobe Analytics data collection servers.

On the first data connection containing a previously unrecognized s.visitorID

value ( u999

above), the new profile is created. Persistent values from the previous profile are transferred to the new profile.

• eVars set to expire on the visit are not copied to the authenticated profile. Note the value car

above is not persisted.

• eVars set to expire by other measures will be copied to the authenticated profile. Note the value apple

is persisted.

• For the eVars that are persisted, no Instance metric is recorded. This means when using cross-device visitor identification, it is possible to see reports where the Unique Visits metric for an eVar value is larger than the Instance metric.

On subsequent data connections

The example below is a representation of how data is sent to Adobe Analytics when a customer authenticates on a new device, after having previously authenticated on a different device:

When the customer authenticates his or her id is matched to the previous 'authenticated' profile -

2947539300

. The profile used at the start of this visit (

5477766334477

) is no longer used and no data persists from the file.

• Geo-Segmentation data is recorded based on the first hit of the visit and does not change for a single visit regardless of the device used. This means on a subsequent data connection on a new device, geo-Segmentation data is generally not included.

• Technology columns such as browser, operating system, and color depth are recorded on the first hit of a visit.

Like Geo-Segmentation values, they will not be copied to the stitched profile.

Implementing Analytics Using JavaScript 256

• A Marketing Channel such as Direct or Internal which is commonly set up to not overwrite another channel will overwrite other channels on a subsequent data connection containing a first authentication for that device, such

as the first authentication shown in

Unique Visitor and Visits Counts

Special cases

In some other cases data is not persisted from the unauthenticated to the authenticated profile.

• If a user is new to your site (has never visited before on this device) AND that user authenticates within approximately

3 minutes of arriving, no values will persist to the authenticated profile.

Visitor Migration

Visitor migration is a process where the visitor ID cookie is migrated from one domain to another.

Visitor migration lets you preserve visitor identification cookies when changing data collection domains. Data collection domains might change for the following reasons:

• Moving from

2o7.net

to omtrdc.net

(

Regional Data Collection

• You are implementing the

Marketing Cloud Visitor ID Service

and are moving from a CNAME/first-party data collection domain to

2o7.net

or omtrdc.net

(

Regional Data Collection

)

• Moving from

2o7.net

or omtrdc.net

to a cname/first-party data collection (

First-Party Cookies)

• Moving from one CNAME to another (changing domains).

After visitor migration is configured, when a user visits the new domain without a visitor ID cookie, the server redirects to the previous data collection hostname, retrieves any available visitor ID cookies, and then redirects back to the new domain. If a Visitor ID is not found on the previous hostname, a new ID is generated. This occurs only once per visitor.

Visitor Migration Process

The following table lists the tasks required for visitor migration:

Task Description

To get started:

Contact Customer Care

with the domain(s) you want to migrate,

Create a list with the exact syntax for the domains you want to migrate to and migrate from.

and the migration period you would like to • example.112.2o7.net > metrics.example.com

enable (30, 60, or 90 days). Make sure you • example.102.112.2o7.net > smetrics.example.com

include the non-secure and secure domains.

The migration host names are configured on Adobe Data collection server. Customer Care will let you know when the change is made so you can plan for the next step.

6+ hours after configuration change:

Update the s.trackingServer

and s.trackingServerSecure

variables in your Analytics JavaScript code to use the new data collection servers.

After you make this change, use a

Packet Analyzer

to verify that the

Analtyics image request is going to the updated data collection server.

Immediately after updating your

Analytics code: Test your site to verify

Use a

Packet Analyzer

to verify that when you access your site for the first time, or after clearing cookies, you see three 302 (redirect) HTTP

Implementing Analytics Using JavaScript 257

Task

that the redirect to the previous data collection domain is occurring.

Description

status codes before the 200 (OK) HTTP status code. If any of these redirects fail, contact Customer Care immediately to ensure that the migration is configured correctly.

For the entire migration period: Keep the DNS record for the previous hostname active.

The previous hostname must resolve through DNS or the cookie migration will not occur.

Deprecated visitorMigrationKey and visitorMigrationServer Variables

As of March 2013, the visitorMigrationKey

, visitorMigrationServer

, and visitorMigrationServerSecure data collection variables are deprecated and no longer used. The data previously contained in these variables are now stored on Adobe servers for increased security.

Using Timestamps Optional

Learn about the benefits and constraints of using Timestamps Optional setting.

Timestamps Optional is the default setting for all new report suites.

• Mix timestamped and non-timestamped data in the same global report suite.

• Send timestamped data from a mobile app to a global report suite.

• Upgrade apps to employ timestamps without having to create a new report suite.

Note: Timestamps Optional is the default setting for all new report suites generated from a template. New report suites copied from an existing report suite will inherit settings from the original.

See

Timestamps Optional

for additional setup information.

Timestamps Optional: Integrating Timestamped and Non-timestamped Data

• Timestamp data. Client-side timestamp data is captured and sent directly with the device data using client-side

timestamp variables: Javascript () on a web page, or using a Mobile SDK call (

offlineEnabled=true

) in a mobile app.

• Non-timestamp data. Adobe sets a timestamp on non-timestamped data in a report suite when the data hits the collection servers.

Implementing Analytics Using JavaScript 258

A report suite can have one of the following timestamp settings:

• Timestamps not allowed (setting visitorID supported)

• Timestamps required (setting visitorID not supported)

• Timestamps optional (setting visitorID supported but not on timestamped hits)

About Timestamps Optional Features

Timestamps Optional allows you to integrate and report across multiple report suites with or without client-side timestamps included. With Timestamps Optional you can update your app to employ timestamps while still using non-timestamped data from the previous app.

In previous releases...

In addition...

Timestamped data could not be sent to a non-timestamped global report suite. Consequently, hit data sent from offline devices was dropped when adding to a non-timestamped report suite.

Updating an app to collect and use timestamps required you to employ a new report suite.

Implementing Analytics Using JavaScript 259

In previous releases...

In addition...

Consequently, hit data sent from offline data was dropped when adding to a non-timestamped report suite.

You could not save to the existing report suite or integrate existing data when updating your app to use timestamps.

With Timestamps Optional, you can integrate non-timestamped data from a live website with offline data from mobile devices, or update your non-timestamped app to a timestamped app.

Combining Data into a Global Report Suite

Combining data into a global report suite can be done in multiple ways, including multi-suite tagging, Vista rules, and imported batch files from offline sources.

Important: Carefully plan the design for each component data set so the combination makes sense in a global report suite.

Implementing Analytics Using JavaScript 260

Best Practices when Employing Timestamps

The following are best practices and a few requirements and restrictions to be aware of when integrating timestamped with non-timestamped data.

• In general, timestamps for a given visitor or visit must arrive at Adobe in the correct chronological order.

Out-of-order data can include late arriving data from offline data collection and late arriving hits, or out-of-sync clocks on offline mobile devices. Out-of-order data can negatively impact time calculations (such as time spent values), attribution (eVar persistence), visit number/visit counts, and pathing reports.

• Using timestamps when setting a

s.visitorID

is not recommended. It can lead to out-of-order data.

• Hybrid apps composed of an app (timestamped, offline data) opening a web browser (non-timestamped, live data) should not use timestamps. It results in inaccurate reporting of the session.

In addition, hybrid apps should not set a visitor ID.

Implementing Analytics Using JavaScript 261

Redirects and Aliases

Redirects point the browser to a new location without user interaction. They are executed at either the web browser

(client-side redirect) or at the web server (server-side redirect).

Because redirects do not require any user interaction, redirects are often executed without the user ever noticing.

The only thing that indicates a redirect has occurred is the browser's address bar. The address bar displays a URL that is different from the link the browser initially requested.

Although there are only two types of redirects, they can be implemented in numerous ways. For example, client-side redirects can occur because the web page to which a user has pointed his or her browser contains scripting or special HTML code that redirects the browser to another URL. Server-side redirects can occur because the page contains server-side scripting or because the web server has been configured to point the user to another URL.

Analytics and Redirects

Analytics gathers some of its data from the browser, and relies upon certain browser properties. Two of those properties, the "Referring URL" (or "referrer") and the "Current URL" can be changed by a server-side redirect.

Because the browser is aware that one URL has been requested, but a different URL has been returned, it clears the Referring URL. The result is the referring URL is blank, and Analytics might report that no referrer existed for the page.

The following examples illustrate how browsing is affected without and with redirects:

•

Example: Browsing Without Redirects

•

Example: Browsing With Redirects

Example: Browsing Without Redirects

Consider the following hypothetical scenario in which the user does not encounter a redirect:

1. User points his or her browser to www.google.com

, and types, "discount airline tickets" into the search field, and then clicks the Search button.

2. The browser displays the search results including a link to your site, http://www.flywithus.com/

. After displaying the search results, the browser's address bar displays the search terms that the user entered in the search field ( http://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets

). Notice that the search terms are included in the URL query string parameters that follow http://www.google.com/search?

3. The user clicks the link to your hypothetical site

http://www.flywithus.com/

. When the user clicks this link and lands on the flywithus.com

website, Analytics uses JavaScript to collect the referring URL

( http://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets

) as well as the current URL ( http://www.flywithus.com/

4. Analytics reports the information collected during this interaction in various reports, such as Referring Domains,

Search Engines, and Search Keywords.

Example: Browsing With Redirects

Redirects can cause the browser to blank out the true referring URL. Consider the following scenario:

1. User points his or her browser to www.google.com

, and types, "discount airline tickets" into the search field, and then clicks the Search button.

Implementing Analytics Using JavaScript 262

2. The browser window's address bar displays the search terms that the user typed into the search field

( http://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets

). Notice that the search terms are included in the URL query string parameters that follow " http://www.google.com/search?

The browser also displays a page that contains the search results including a link to one of your domain names: http://www.flytohawaiiforfree.com/

. This vanity domain is configured to redirect the user to http://www.flywithus.com/

3. The user clicks on the link http://www.flytohawaiiforfree.com/

and is redirected by the server to your main site, http://www.flywithus.com

. When the redirection occurs, the data that is important to Analytics data collection is lost because the browser clears the referring URL. Thus, the original search information used in the Analytics reports (for example, Referring Domains, Search Engines, Search Keywords) is lost.

Implementing Redirects

discusses how to leverage Analytics variables to capture the data lost in the redirect.

Specifically, the section discusses how to fix the "discount airline tickets" situation described above.

Implementing Redirects

In order to capture Analytics data from redirects, four minor alterations need to be made to the code that creates the redirect and the AppMeasurement for JavaScript file.

Completing the following steps will retain the information that the original referrer (for example, http://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets

in the scenario above) passes to your site:

Configure Referrer Override JavaScript Code

Adobe Customer Care can provide you with a JavaScript file that contains code that will override the default functionality Analytics uses to capture the referrer from the HTTP header.

The code snippet below shows two JavaScript variables, s_referrer and s_pageURL. This code is placed on the ultimate landing page of the redirect.

/* You may give each page an identifying name, server, and channel on the next lines. */ s.pageName="" s.server="" s.campaign="" s.referrer="" s.pageURL=""

Important: Set s.referrer only once on the page. Setting it more than once with every tracking call or with every link click that is tracked causes double counting of the referrer and related dimensions, such as search engines and keywords.

Redirects using getQueryParam

While the getQueryParam is an easy way to populate Analytics variables with query string values, it must be implemented in connection with a temporary variable so that legitimate referrers are not overwritten when the query string is empty. The best way to use getQueryParam is in connection with the getValue plug in as outlined with the following pseudo-code.

// AppMeasurement 1.x

var tempVar=s.Util.getQueryParam('origref') if(tempVar)

Implementing Analytics Using JavaScript

s.referrer=tempVar;

// H Code var tempVar=s.getQueryParam('origref') if(tempVar)

s.referrer=tempVar;

263

Modify the Redirect Mechanism

Modify the Redirect Mechanism XE "Redirect Mechanism"

Because the browser strips referring URL, you must configure the mechanism that handles the redirect (for example, the web server, server-side code, client-side code) to pass along the original referrer information. If you would also like to record the alias link URL, this must also be passed along to the ultimate landing page. Use the s_pageURL variable to override the current URL.

Because there are many ways to implement a redirect, you should check with your web operations group or your online advertising partner to identify the specific mechanisms that execute redirects on your website.

Capture the Original Referrer

Capture the Original Referrer XE "Original Referrer"

Normally, Analytics will obtain the referring URL from the browser's document.referrer property, and the current

URL from the document.location property. By passing values to the referrer and pageURL variables, you can override the default processing. By passing a value to the referrer variable, you are telling Analytics to ignore the referrer information in the document.referrer property and to use an alternative value that you define.

Therefore, the final version of the landing page would need to contain the following code to correct the issues introduced in the "discount airline tickets" scenario.

/* You may give each page an identifying name, server, and channel on the next lines. */ s.pageName="" s.server="" s.campaign="" s.referrer="http://www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets"

// Setting the s.pageURL variable is optional.

s.pageURL="http://www.flytohawaiiforfree.com"

Verify the Referrer with the Adobe Debugger

Run a test to verify that the referrer, originating URL (s_server) and campaign variables are being captured.

These variables will be represented as the following parameters in the

tl function. For more information on custom links, see

URL or Query String Value Value as Shown in the DigitalPulse

Debugger

Original Referrer http://www.google.com/search%3F hl%3Den %26ie%3DUTF826q%3

Ddiscount%2Bairline%2Btickets r=http:/ref=www.google.com/search?hl=en&ie=UTF

-8&q=discount+airline+tickets

Page URL http://www.flytohawaiiforfree.com

g=http://www.flytohawaiiforfree.com

Implementing Analytics Using JavaScript 264

Ultimate Landing Page URL

URL or Query String Value

http://www.flywithus.com

Value as Shown in the DigitalPulse

Debugger

This value will appear in the

DigitalPulse Debugger if the pageURL variable is used.

This value will NOT appear in the

DigitalPulse Debugger if the pageURL variable is used.

The text that the debugger displays should correspond to the following example:

Image http://flywithuscom.112.2o7.net/b/ss/flywithuscom/1/JS-1.4/s61944015791667?[AQB] ndh=1 t=4/8/2014 13:34:28 4 360 pageName=Welcome to FlyWithUs.com

r=http://ref=www.google.com/search?hl=en&ie=UTF-8&q=discount+airline+tickets cc=USD g=http://www.flytohawaiiforfree.com

s=1280x1024 c=32 j=1.3

v=Y k=Y bw=1029 bh=716 ct=lan hp=N

[AQE]

After verifying that the Adobe Debugger displays these variables, it is always helpful to confirm that the search terms and the original referring domain (prior to the redirect) are registering traffic in reports.

Testing and Validation

Testing and Validation Process

Use validation and testing to ensure data reporting accuracy.

Validation and testing should always be done on the development report suite.

Identifying the s_account Variable in the DigitalPulse Debugger

When you run the DigitalPulse Debugger, you may want to look for the s_account variable.

The following figure shows the location of the s_account variable.

265

JavaScript JS File

Verify that the

.JS

file is correctly referenced from the page. The path can be specified either relative to the current document, or an absolute path name can be used.

If some pages of the site are loaded in a secure protocol (https:), and reference the AppMeasurement for JavaScript file, ensure that the reference to the file is either secure (via https:) or code the reference as shown below. This example adopts the protocol of the current page and prevents the warning that "some elements are non-secure."

Ensure that the

.JS

file on the web servers have permissions appropriately set so that the file may be downloaded and executed by website visitors. If a different

.JS

file is used on development servers, set the "read only" attribute for the

.JS

file on production servers to avoid an overwrite. If altered, ensure that the following settings are set appropriately at the top of the

.JS

file:

/************************** CONFIG SECTION **************************/

/* You may add or alter any code config here. */

Testing and Validation 266

/* Link Tracking Config */ s.trackDownloadLinks=false /* true for download tracking */ s.trackExternalLinks=false /* true for exit link tracking */ s.trackInlineStats=false /* true for ClickMap support */ s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,doc,pdf,xls" s.linkInternalFilters="javascript:" s.linkLeaveQueryString=false s.linkTrackVars="None" s.linkTrackEvents="None"

If "s_account" is assigned a value at the top of the

.JS

file, ensure that the report suite ID (populated in the s_account variable) is correct. Also ensure that the code in the page is not setting the Report Suite ID (s_account variable).

Examine the image request and variables to ensure that the "fallback method" (the third part of the "split" code in the example above) is not creating the image request instead of the

.JS

file. This can be determined since the

"fallback" method only creates an image request with minimal information.

Code Modifications

Testing any modifications to the

.JS

file or HTML code is the responsibility of the customer. It should be completed prior to publishing the modifications to production websites.

Ensure that the linefeeds/return characters are not stripped or altered from the code that is placed within the HTML, or from within the

.JS

file. Ensure that the JavaScript executes without an error on all pages and page templates

(in Internet Explorer Internet Options, select the Advanced Tab, and click Display a Notification about Every Script

Error.

When testing for errors, paste the code into a default HTML page to determine if the error is occurring because of other page elements/objects.

...paste code here to debug...

</body></html>

Variables and Values

Ensure that the variables that are populated from server scripting or code cannot output any quotation marks that interfere with the values.

For instance: s.pageName="Article: "Article Name"" s.pageName='Company's Information'

Ensure that the values of the variables do not exceed their maximum limits, specified in this document. Additional characters are cropped at the data collection servers. They may interfere with the total length, increase bandwidth unnecessarily, and may cause other issues.

Do not use $,

™

, or commas (,) in the products variable. Generally, these are not useful in any Analytics variables and may interfere with the ability to interpret or export fields. The best practice is to limit characters to the first 127 ASCII characters.

Ensure that the events variable is populated with an appropriate value (prodView, purchase, scAdd, scRemove,

scOpen, or event1-event5) whenever products is populated. Ensure that the case of all Analytics variables and functions are maintained, as shown below.

s.pageName

s.server

s.channel

s.pageType

s.prop1 – s.prop20

Testing and Validation 267 s.campaign

s.state

s.zip

s.events

s.products

s.purchaseID

s.eVar1 – s.eVar20

var s_code=s.t();if(s_code)document.write(s_code)//-->

Page names are case sensitive, and differences create additional page records. "Home" and "home" are two different pages within Analytics.

Note: Multiple page records cannot be combined within reports.

Validate that links are reported in the Custom Links report. Ensure that the correct parameters are passed to the

The s.tl() Function - Link Tracking

Custom Variables

List of custom variables used in Analytics.

Variable

Traffic Variables

Description

Check the value of prop1 - 75. Here is a checklist of items to check.

• Is the correct case used? "ValueA" is a different record than "valueA." You can use all lowercase since a small subset of browsers convert all variables to lower case.

• Are the values less than 100 characters in length? If not, some clipping of the values can occur.

• Are all the values in a single property variable related, or do some values look out of place?

Conversion Variables Econversion variables include eVar 1 - 75. Here is a list of issues to check for the following.

• Is the correct case used? "ValueA" is a different record than "valueA." You can use all lowercase since a small subset of browsers convert all variables to lower case.

• Are the values less than 255 characters in length? If not, some clipping of the values can occur.

• Are all the values in a single eVar related, or do some values look out of place?

Custom Events Events include both standard values (prodView, scOpen, scAdd, scCheckout,

purchase), as well as custom events from event1 to event100. All events are sent in the events variable. Multiple events on the same page should be comma-delimited

(no white space).

• For all the standard conversion events, products should also be populated with the applicable products. For all events except purchase, the qty and price elements are optional.

• The purchase event, must be set only once in a session after the purchase has been completed and confirmed.

Implementation Acceptance

Implementation process steps.

The following steps outline the implementation process.

Testing and Validation 268

1. The Adobe Consultant gathers report requirements and creates a data collection plan based on those requirements.

The data collection plan includes variable definitions, required VISTA rules and custom JavaScript, data correlation, and all settings for each report suite. The client completes the Implementation Questionnaire.

2. Technical resources on the client-side implement the code, site-specific JavaScript, and server-side variables.

3. The Adobe Consultant addresses technical issues during the implementation and assists in devising solutions as required.

4. Technical resources on the client-side unit test the implementation.

Testers log in to Analytics and verifying all variables (page name, channel, server, events, campaign, econversion variables, custom traffic variables, products, and all other variables).

5. The client notifies Adobe that the implementation is complete.

The client provides a validation sample (data sample) to the Adobe Consultant to validate data accuracy.

(VISTA-generated report suites are validated by comparing appropriate metrics. A client-Adobe agreement of the metrics to be validated for such report suites shall be made in advance, at the time of the VISTA rule creation.)

6. The client faxes (or signs online) an Implementation Acceptance and Agreement for the appropriate site(s).

7. After the acceptance has been received, the Adobe Consultant enables the Adobe Best Practices - Implementation

Verification certification within the interface.

8. Optionally, the client can contract with Adobe for monitoring services for key pages of the implemented site

(generally, these are the primary templates, home page, and critical entry pages).

This monitoring software is described in a separate document, but tracks pages by loading and executing the page, then comparing the image request to a baseline stored in a database. If any differences are detected, the software notifies specified Adobe (AM/IE) and client personnel via email.

The following items help to ensure a successful implementation:

• A best practices document, which is client-facing and explains the processes in detail.

• The validation document that the customer uses to unit test the implementation.

• An Implementation Acceptance and Agreement form for the client to sign.

• A monitoring application that continuously validates the tags.

• A relationship with Accenture to help with implementation testing.

• Utilities and/or tools for comparison of page views and/or orders. Those comparisons can get fairly difficult.

• A method or process to quickly obtain the debug log for a given day, by report suite ID.

Data Accuracy Validation

Data accuracy validation is a process of comparing report data with known and verifiable data points.

The validation process should be completed by Adobe personnel, preferably by the Adobe Consultant (the person most familiar with the technical implementation details).

The preferred data points for this validation, in order of preference, are listed as follows:

• (Econversion sites) Comparison of econversion orders for a single day.

• Comparison of known success events, especially logged data where IP address and other browser information generally stored in web server logs can be compared to the data collected.

• Comparison of page views.

Note: Default pages, such as index.html

, often receive automated or monitoring traffic. These pages represent a greater difference to browser-based data collection than other visited pages.

Testing and Validation 269

All three types of validation require a debug log or data feed for the time period in question. This is generally one day or less.

It is expected that orders or success events can be measured to within 2-3% of actual values (sometimes reaching higher accuracy levels) using standard JavaScript-based implementations. This assumes an SSL page, since SSL pages are cached much less frequently, and by definition they should not be cached. An implementation with fully server-side image requests on an SSL page should come within about 0-1% of actual values. Non-secure pages may experience higher differences, but still within 5% of actual values.

When comparing page views for a single time period, it is expected that the page views can be accounted for within

5% of actual values, not including monitoring (such as Keynote or WhatsUpGold) or automated traffic (spiders, bots, and scripts).

Data accuracy comparisons need to take into account the following items:

• QA or other types of internal testing that may be filtered by IP addresses or VISTA rules.

• Smart tags that only generate tags for certain types of orders or traffic.

• Queries for comparison must take into account what is being measured by the website (not including returns, orders placed by customer service personnel, or other special conditions).

• Ensure that the time zone differences between the query and the report suite match.

• Custom Keynote or similar traffic (Keynote Transaction, etc.) that measure the ordering process and may be reflected in tags, but removed from ordering systems.

• Account for the client's de-duping processes.

• Reloads of the order page (Orders are de-duplicated based on purchaseID).

Adobe Debugger

The Adobe Debugger (previously DigitalPulse Debugger) is a free tool provided by Adobe that lets you view the data being collected from your site on any given page.

Note: DigitalPulse debugger was recently moved from digitalpulse.omniture.com

to adobetag.com

. If you are having issues using the debugger, copy the updated code from

Adobe Debugger Installation and

update your bookmarklet.

When executed in your browser, it shows the image requests that transmitted data from that page into Marketing

Cloud solutions, along with any variable values or parameters that were captured. This allows you and your developers to check the validity of your implementation on any page on your site.

The DigitalPulse Debugger is officially supported for use in all recent versions and builds of Mozilla Firefox, Google

Chrome, Microsoft Internet Explorer, and Safari.

Note: Because the Debugger functions by creating a pop-up window when you access a special bookmark in your web browser, certain ad-blocking plug-ins and pop-up blockers might interfere with the loading of the

Debugger.

Adobe Debugger Installation

Adobe Debugger (previously DigitalPulse Debugger) is installed as a bookmarklet in your browser. Copy the provided

JavaScript code to your clipboard and then create a bookmarklet in a supported browser.

Testing and Validation 270

1. Copy the following text to your clipboard (triple-clicking might help in highlighting all the text): javascript:void(window.open("","dp_debugger","width=600,height=600,location=0,menubar=0,status=1,toolbar=0,resizable=1,scrollbars=1").document.write("<script

language='JavaScript' id=dbg src='https://www.adobetag.com/d1/digitalpulsedebugger/live/DPD.js'></"+"script>"));

2. Complete the steps appropriate for the desired browser:

Mozilla Firefox

Instructions to create a bookmark for the Adobe Debugger (previously DigitalPulse Debugger) from within Mozilla

Firefox.

1. Right-click the bookmarks sidebar, then click New Bookmark.

2. In the Name field, specify "Adobe Debugger" as the name for the new bookmark.

3. In the Location field, paste the code that you copied to your clipboard as explained in

Adobe Debugger Installation

4. Select Load the Bookmark in the Sidebar, if desired.

5. Click Add.

Google Chrome

Instructions to create a bookmark for the Adobe Debugger (previously DigitalPulse Debugger) from within Google

Chrome.

1. Right-click the Bookmarks bar (depending on your Chrome settings the Bookmarks bar might be on the New

Tab page), then click Add Page.

2. In the Name field, specify "Adobe Debugger" as the name for the new bookmark.

3. In the URL field, paste the code that you copied to your clipboard as explained in

Adobe Debugger Installation

4. Browse to and specify the location you want to save the bookmark.

5. Click OK.

Microsoft Internet Explorer

Instructions to create a bookmark for the Adobe Debugger (previously DigitalPulse Debugger) from within Microsoft

Internet Explorer.

In the Favorites Bar, click the Add to Favorites Bar icon ( ) icon.

If the Favorites Bar is hidden, right-click the browser header, then click Favorites Bar.

A new bookmark is created.

2. Right-click the bookmark, then click Rename.

3. In the New Name field, specify "Adobe Debugger" as the name, then click OK.

4. Right-click the newly created bookmark again, then click Properties.

5. In the URL field, paste the code that you copied to your clipboard as explained in

Adobe Debugger Installation

6. Click OK.

Launching DigitalPulse Debugger

After installing the DigitalPulse Debugger, you are ready to use it to view the data being collected from your site.

1. From your browser, click the bookmark or bookmarklet to launch the DigitalPulse Debugger in a new window.

Testing and Validation 271

2. View the data.

Packet Analyzers

Packet analyzers let you view the data sent by your implementation to Adobe Data Collection Servers.

Simliar to the DigitalPulse Debugger, a packet monitor shows what data parameters are being passed in an image request; however, packet monitors provide added functionality:

• View custom link tracking image requests

• View image requests using implementation methods other than JavaScript, such as hard-coded image requests or Appmeasurement

To view Analytics requests, filter outgoing requests using "b/ss".

In very rare cases, the debugger will report an image request although no request makes it to Adobe's Analytics processing servers. Using a packet monitor is a great way to be 100% sure that a specific image request is being fired successfully.

While Adobe does not provide an official packet monitor, there are a wide range of them on the internet. The following are some packet monitors others have found useful.

Note: These lists are not meant to be comprehensive, but rather information on frequently used monitors. If you have a packet monitor you successfully use and find useful, feel free to provide feedback using the

Feedback button on the right side of this window.

Testing and Validation 272

Firefox Internet Explorer

Observe Point

(tag viewer)

HttpWatch

HttpFox

Tamper Data

HttpWatch

Firebug

Chrome Standalone Programs

Observe Point

(tag viewer)

Charles

Chrome Developer Tools Fiddler

Firebug Lite Wireshark

Note: Adobe does NOT support or troubleshoot any issues you may experience with these packet monitors.

Consult the packet monitor's originating site for assistance instead.

NS_Binding_Aborted in Packet Monitors

The NS_BINDING_ABORTED message is often seen on custom link tracking image requests with packet sniffers that sit on top of the browser, such as Tamper Data or HTTPFox .

This error occurs because the link tracking image request is designed to let the browser proceed to the next page before waiting for a response from the Adobe data collection servers.

Adobe's response to the image request is simply a blank 1x1 transparent image, which is not relevant to the content of the page. If you see a line item in your packet monitor from Adobe, either with a 200 OK response or an

NS_BINDING_ABORTED response, the data has reached our servers. There is no need to have the page wait any longer.

Packet monitors integrated as a plug-in rarely see the full response. They tend to see the request as aborted because the full response was not received. These monitors also rarely make a distinction between whether it was the request or response that was aborted. A stand alone packet monitor typically has more detailed messages and reports the status more accurately. For example, a user may get a message in Charles saying "Client closed connection before receiving entire response." This means the data did reach our servers, just the browser moved on to the next page before the 1x1 pixel was received.

If an external packet sniffer is reporting that the data collection request is aborted, rather than the response, this is a cause for concern. Adobe Customer Care can provide help in troubleshooting.

Common Syntax Mistakes

A successful implementation means drawing useful data from your website. An unsuccessful implementation can mean spending time looking through your JavaScript code to find errors. In an attempt to save you time and prevent frustration, some of the most common code mistakes users make when implementing are listed in the following sections.

Putting Analytics Code in the Head Tag

Analytics code creates an image object, a non-visible image that does not show up on your page.

Note: This section applies only to the legacy s_code.js implementation.