Adobe Implementation Analytics Implementation Guide

AppMeasurement Plug-in Support

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:

Web and Mobile Measurement Libraries

Step Task Description

Web and Mobile Measurement Libraries 17

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:

•

http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

•

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx?mfr=true

•

http://www.cubicleman.com/2007/04/06/enabling-gzip-compression-with-tomcat-and-flex/

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

Visitor 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

(Optional) Update plug-ins

Where

s_code.js

Description

Some plug-ins are longer supported. See

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

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

Web and Mobile Measurement Libraries

Step Task

Deploy new JavaScript

Where

Your website

Description

and paste it just before the

DO NOT ALTER

ANYTHING BELOW THIS LINE

AppMeasurement.js

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

Utilities

These utilities are supported by the AppMeasurement for JavaScript.

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.

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:

Web and Mobile Measurement Libraries 19

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);

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]) url delim

Note: The syntax for the utility differs from the syntax for the plug-in.

Parameters:

Parameter

key

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");

};

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

JavaScript

Implementation . 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

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

AppMeasurement.js

to get started: s=new AppMeasurement() s.account="INSERT-RSID-HERE"

Web and Mobile Measurement Libraries s.visitorNamespace="INSERT-NAMESPACE-HERE"

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

/************************** 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" @

// http://microsite.omniture.com/t2/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:

/* Get the AppMeasurement instance */ var s=s_gi("INSERT-RSID-HERE")

/* 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 */

Web and Mobile Measurement Libraries 21 s.campaign="" s.state="" 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

JavaScript Implementation

for instructions.

AppMeasurement Plug-in Support

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

Tested Plugins

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

•

appendList

• crossVisitParticipation

• userAgentManager

•

getTimeParting

• join

• split

•

getDaysSinceLastVisit

•

getNewRepeat

• getTimeToComplete

Untested Plugins

The following plugins 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

• getCookiesAccepted

•

getValOnce

Unsupported Plugins

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

• manageVars

• callBack

• channelExtract

• channelManager

•

detectRIA

• deviceOrientationChanges

• DynamicObjectIDs

Web and Mobile Measurement Libraries

• Form Analysis

• getPageName

•

manageQueryParam

•

Cookie Combining Utility

• HTML5Storage

Implementing Analytics without JavaScript

Data collection is usually implemented using an HTML image tag that is created using JavaScript.

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 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.

Web and Mobile Measurement Libraries 23

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…>.2o7.net/b/ss/ reportsuite

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

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

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

Web and Mobile Measurement Libraries

Requirement

URL and Referring URL

Effects of Caching

Description

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.2O7.net/b/ss/ suite1,suite2

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

http:// suite1 .112.2O7.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.

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.

Web and Mobile Measurement Libraries

Requirement

nameSpace Variable

Description

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.2O7.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"

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

</body>

</html>

Web and Mobile Measurement Libraries

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.

Web and Mobile Measurement Libraries 27

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.

Web and Mobile Measurement Libraries 28

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

eVar), Event, Site Traffic, and Pathing reports are supported.

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.

Web and Mobile Measurement Libraries

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>

Tag management 2.0

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

Adobe Tag Manager provides a tag management framework that serves as a tag container, housing the tags that an Adobe customer may require, including Adobe Marketing Cloud tags and third-party tags.This simplicity accelerates time to deployment versus standalone tag management products, which require more significant changes and resources to implement.

The tags within the container are managed through an administrative user interface where the customer can insert or remove tags (from Adobe or other partners) without making changes to a website. The ability to rapidly add and remove tags combined with common techniques to conditionally fire or timeout tags gives advertisers and publishers more control over their valuable data and helps manage pages for fast loading.

Tag management Documentation Revision History

Revision Date

April 18, 2013

Description

Initial tag management 2.0 release.

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.

Web and Mobile Measurement Libraries 30

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:

Web and Mobile Measurement Libraries 31

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:

Web and Mobile Measurement Libraries 32

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.

Web and Mobile Measurement Libraries 33

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

Include the Page Code on Site

Pages

Test and Promote Revisions

Tag management

Copy Environment Bookmarklets

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.

Web and Mobile Measurement Libraries 34

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.

Web and Mobile Measurement Libraries

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.

See

Tag Container Environments

5. On the Edit Tags page, define tags to deploy Marketing Cloud products.

See

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.

Web and Mobile Measurement Libraries 36

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.

Web and Mobile Measurement Libraries 37

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

SiteCatalyst Adobe Analytics

Migration Instructions

Copy all of the code from the 1.0 SiteCatalyst Tag Code section to the 2.0 Analytics Tag Code section.

Web and Mobile Measurement Libraries 38

1.0 Product Code

Tag

2.0 Tag

SiteCatalyst >

Survey

Adobe Analytics > Survey

Migration Instructions

Copy all of the code from the 1.0 Survey Tag Code section to the

2.0 Survey Tag Code section.

SiteCatalyst >

Video Tracking

SiteCatalyst > *

Genesis

Integrations

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.

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

Migration Instructions

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

Web and Mobile Measurement Libraries

1.0 Custom Code

Tag

2.0 Tag

Remote

JavaScript

Remote Script

IFrame IFrame

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:

Web and Mobile Measurement Libraries 40

Attach an Event Handler in tag management

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.

Web and Mobile Measurement Libraries 41

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.

})();

SiteCatalyst

Code

Plugins

Survey

Media Module

Genesis

Integrations var s_account="rs" var s=s_gi(s_account) s.debugTracking=false s.charSet = "UTF-8"

...

s.linkTrackEvents="None" 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:

Web and Mobile Measurement Libraries

Description Current Code Tag

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.

Web and Mobile Measurement Libraries 43

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.

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

Web and Mobile Measurement Libraries 44

• 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

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.

Web and Mobile Measurement Libraries 45

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 Description

tagload tagappend tagignore pageload

Triggered when a tag has been loaded and is ready to use.

Triggered when a tag is appended in the page by tag management.

Triggered when by some unknown reason one tag could not be append in the page.

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

Web and Mobile Measurement Libraries 46

// 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.

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.

Web and Mobile Measurement Libraries 47

Confirm that a tag revision is deployed in the environment you are testing.

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.

Web and Mobile Measurement Libraries 48

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

Web and Mobile Measurement Libraries

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.

Analytics Variables 50

Analytics Variables

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

Variables and Limitations

The JavaScript file used to track Web pages is extremely versatile. However, potential problems and pitfalls may arise with an increased level of flexibility.

The following table lists the available Analytics variables:

Variable

s_account browserHeight browserWidth campaign channel charSet colorDepth connectionType cookieDomainPeriods cookieLifetime cookiesEnabled currencyCode

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 Analytics visitor 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.

Analytics Variables

Variable

dc doPlugins dynamicAccountList dynamicAccountMatch dynamicAccountSelection dynamicVariablePrefix eVarN events fpCookieDomainPeriods hierN homepage javaEnabled javascriptVersion linkDownloadFileTypes linkExternalFilters linkInternalFilters

Description

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.

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 Analytics

Conversion 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.

Analytics Variables

Variable

linkLeaveQueryString linkName linkTrackEvents linkTrackVars linkType mediaLength mediaName mediaPlayer mediaSession

Media.trackEvents

Media.trackVars

mobile s_objectID pageName pageType pageURL

Description

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.

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

Analytics Variables

Variable

plugins products propN purchaseID referrer resolution server state trackDownloadLinks trackExternalLinks trackingServer trackingServerSecure trackInlineStats transactionID s_usePlugins

Description

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 Analytics

Traffic 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.

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

Analytics Variables

Variable

visitorID visitorNamespace zip

Description

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.

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.

Parameters

Max Size Debugger Parameter Reports Populated Default Value

40 Bytes In the URL path N/A 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.

Analytics Variables 55

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

Implementation Plug-ins

http://mycompany.112.2o7.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 ClientCare. 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.

• 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.

browserHeight

The browserHeight variable displays the height of the browser window.

This variable is populated after the page code and before doPlugins is run.

Analytics Variables

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

A positive integer

Example

1179

Reports Affected

Traffic > Technology >

Browser Width

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:

Analytics Variables 57

• 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

• 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.

Examples

s.campaign="112233" s.campaign=s.getQueryParam('cid');

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.

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

Analytics Variables 58

Max Size

N/A

Debugger Parameter

Reports Populated

N/A

Default Value

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.

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

Site Content > Site Sections

Default Value

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. For more information, see the Channels and Hierarchies white paper.

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.

Analytics Variables 59

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.

Query Param

Value

8,16, and 32

Example

Reports Affected

Traffic > Technology >

Monitor Color Depth

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

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.

Analytics Variables 60

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.

cookieLifetime

The cookieLifetime variable is used by both JavaScript and data collection servers in determining the lifespan of a cookie.

Analytics Variables 61

Max Size

N/A

Debugger Parameter

Reports Populated

Traffic > Technology >

Cookies All visitor-related reports

Default Value

If cookieLifetime is set, it overrides any other cookie expirations for both JavaScript and data collection servers, with one exception, described below. The cookieLifetime variable can have one of three values:

• Analytics Cookies

• Cookies

• JavaScript Settings and Plugins

Syntax and Possible Values

s.cookieLifetime="value"

The possible values are listed as follows:

• ""

• "NONE"

• "SESSION"

• An integer representing the number of seconds until expiration

Examples

s.cookieLifetime="SESSION" s.cookieLifetime="86400" // one day in seconds

Configuration Settings

None

Pitfalls, Questions, and Tips

cookieLifetime affects Analytics tracking. If, for example, cookieLifetime is two days, then monthly, quarterly, and yearly unique visitor reports will be incorrect. Use caution when setting cookieLifetime.

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

Analytics Variables 62

currencyCode

The currencyCode variable determines the conversion rate to be applied to revenue.

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 Default Value

Conversion > Purchases >

Revenue

"USD"

All Conversion reports showing Revenue or monetary values

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

string. For more information on products, see

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 ClientCare 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.

Analytics Variables 63

• 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.

dc

(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

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.

Default Value

112

doPlugins

The doPlugins variable is a reference to the s_doPlugins function, and allows the s_doPlugins function to be called at the appropriate location within the JavaScript file.

The s_doPlugins function is called each time any of the following occurs:

• The t() function is called

• The tl() function is called

• An exit or download link is clicked

• Any page element being tracked by visitor click map is clicked

The doPlugins function is used to run customized routines to gather or alter data. If you are using an object name other than "s," make sure that the s_doPlugins is renamed appropriately. For example, if your object name is s_mc, the s_doPlugins function should be called s_mc_doPlugins.

Syntax and Possible Values

The s_doPlugins function should not be in quotes, and doPlugins should always be assigned to the exact name of the s_doPlugins function (if that function is renamed).

s.doPlugins=s_doPlugins;

Examples

s.doPlugins=s_doPlugins; s_mc.doPlugins=s_mc_doPlugins;

Configuration Settings

None

Pitfalls, Questions, and Tips

• The only reason to change the object name (such as from s to s_mc) is if you share content with or pull content from other customers. Renaming the s_doPlugins function to s_mc_doPlugins ensures that another client's

JavaScript file does not overwrite your doPlugins function.

Analytics Variables 64

• If you unexpectedly start pulling in content from another Adobe customer, and your s_doPlugins function is being overwritten, it is possible to simply rename the s_doPlugins function without changing the object name. While the best solution is to use a different object name than other JavaScript files on the same page, doing so is not required.

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.

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 Report Suite to Receive Data

mysuite2=www2.mycompany.com;mysuite1=mycompany.com"

"mysuite1=path4,path1;mysuite2=path2"

"mysuite1=path5"

"myprodsuite=prod_id" window.location.host

window.location.pathname

mysuite1 mysuite1, mysuite2 mysuitecom, mysuite1 window.location.search?window.location.search:"?") 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

Analytics Variables 65

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.

dynamicAccountMatch

The dynamicAccountMatch variable 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.' 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

Analytics Variables 66

Configuration Settings

None

Pitfalls, Questions, and Tips

• Dynamic account selection is not supported by

• 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.

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

populating the events variable with the literal values defined in the

• Always use the DigitalPulse Debugger to determine which report suite is receiving data from each page.

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.

Analytics Variables 67

Max Size

N/A

Debugger Parameter

Reports Populated

Any

Default Value

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.

eVarN

The eVar variables are used for building custom reports.

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

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.

Analytics Variables 68

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.

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).

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.

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.

Analytics Variables 69

Setting

Name

Type

Allocation

Expire After

Reset

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.

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.

events

The 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

Custom Events

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

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

Analytics Variables 70 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) can be enabled by any admin-level user by 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 - event100

Description

Product Views

Reports Populated

Products

Open / Initialize a new shopping cart Carts

Add item(s) to the shopping cart

Remove item(s) from the shopping cart

Cart Additions

Cart Removals

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"

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

Analytics Variables 71

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=";Running Shoes;1;99.99;event1=4.50" s.events="event1,event4" s.products=";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=";Running Shoes;1;69.95,;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.

See

Event Serialization

for more information.

Syntax

s.events="event1:3167fhjkah"

Examples

s.events="scAdd:003717174" s.events="scAdd:user228197,event1:577247280,event7:P7fhF8571"

Analytics Variables 72

fpCookieDomainPeriods

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.

The fpCookieDomainPeriods variable should never be dynamically set . If you use cookieDomainPeriods, it is good practice to specify a value for fpCookieDomainPeriods as well. fpCookieDomainPeriods inherits the

cookieDomainPeriods value. Note that fpCookieDomainPeriods does not affect the domain on which the visitor ID cookie is set, even if your implementation treats this as a first-party cookie.

The name "fpCookieDomainPeriods" refers to the number of periods (".") in the domain when the domain begins with "www." For example, www.mysite.com contains two periods, while www.mysite.co.jp contains three periods.

Another way to describe the variable is the number of sections in the main domain of the site (two for mysite.com

and three for mysite.co.jp).

The AppMeasurement for JavaScript file uses the fpCookieDomainPeriods variable to determine the domain with which to set first-party cookies other than the visitor ID (s_vi) cookie. There are at least two cookies affected by this variable, including s_sq and s_cc (used for visitor click map and cookie checking respectively). Cookies used by plug-ins such as getValOnce are also affected.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

cookieDomainPeriods

Sample Code for Setting Cookie Domain Variables

s.fpCookieDomainPeriods="2" var d=window.location.hostname

if(d.indexOf('.co.uk')>-1||d.indexOf('.com.au')>-1)

s.fpCookieDomainPeriods="3"

Syntax and Possible Values

The cookieDomainPeriods variable is expected to be a string, as shown below.

s.fpCookieDomainPeriods="3"

Examples

s.fpCookieDomainPeriods="3" s.fpCookieDomainPeriods="2"

Configuration Settings

None

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.

Analytics Variables 73

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 ClientCare. 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 ClientCare 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

Pitfalls, Questions, and Tips

• Before implementing hierarchies, see the Channels and Hierarchies white paper.

• The delimiter may not be changed after the hierarchy is set up. If the delimiter for your hierarchy must be changed, contact Adobe ClientCare.

• 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.

Analytics Variables

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

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

linkDownloadFileTypes

The linkDownloadFileTypes variable is a comma-separated list of file extensions.

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

Downloads report.

Analytics Variables 75

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

Traffic > Site Traffic > File

Downloads

Default Value

"exe,zip,wav,mp3,mov,mpg,avi,wmv, doc,pdf,xls"

The linkDownloadFileTypes variable is only relevant when trackDownloadLinks is set to 'True.'

Only left-mouse-clicks on a link are counted in the File Downloads report. All file downloads that start automatically when a page loads, or that are only downloaded after a redirect, are not counted in the File Downloads report.

When you right-click a file and select the "Save Target As..." option, it is not counted in the File Downloads report.

The linkDownloadFileTypes variable may be used to track clicks to RSS feeds. If you have links to RSS feeds with a .xml or other extension, appending ",xml" to the linkDownloadFileTypes list allows you to see how often each RSS link is clicked.

The following sections contain more information:

•

Syntax and Possible Values

•

Examples

•

Configuration Settings

•

Pitfalls, Questions, and Tips

Syntax and Possible Values

Only include file extensions (no spaces).

s.linkDownloadFileTypes="type1[,type2[,type3[...]]]"

Any file extension may be included in the list. Be careful not to include a common file extension, such as htm or aspx, in linkDownloadFileTypes. Doing so causes an extra image request to be sent for each click, which will be billed as a primary server call.

Examples

s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,wmv,doc,pdf,xls" s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,wmv,doc,pdf,xls,xml"

Configuration Settings

None

Pitfalls, Questions, and Tips

• Only left-clicks on download files cause the URL to appear in the File Downloads report.

• Including a common file extension in linkDownloadFileTypes may significantly increase the total server calls sent to Adobe's servers.

• Links to server-side redirects or HTML pages that automatically begin downloading a file are not counted unless the file extension is in linkDownloadFileTypes.

• Links that use JavaScript (such as javascript:openLink( )) are not counted in file downloads.

linkExternalFilters

If your site contains many links to external sites, and you do not want to track all exit links, use linkExternalFilters to report on a specific subset of exit links.

Analytics Variables 76

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

Paths > Entries & Exits >

Exit Links

Default Value

The linkExternalFilters variable is an optional variable used in conjunction with linkInternalFilters to determine whether a link is an exit link. An exit link is defined as any link that takes a visitor away from your site. Whether the target window of an exit link is a popup or the existing window, it does not affect whether the link appears in the exit links report. Exit links are tracked only if trackExternalLinks is set to 'true.' The filters in linkExternalFilters and

linkInternalFilters are case insensitive.

Note: If you don't want to use linkExternalFilters, delete it or set it to "".

The filters list in linkExternalFilters and linkInternalFilters apply to the domain and path of any link by default. If

linkLeaveQueryString is set to 'true,' the filters apply to the entire URL (domain, path, and query string). These filters are always applied to the absolute path of the URL, even if a relative path is used as the href value.

Most companies find that linkInternalFilters gives them enough control over exit links that they don't need

linkExternalFilters. Using linkExternalFilters simply decreases the likelihood that an exit link is considered external.

If linkExternalFilters has a value, then a link is considered only external if it does not match linkInternalFilters and does match linkExternalFilters.

The following example illustrates how this variable is used. In this example, the URL of the page is http://www.mysite.com/index.html

s.trackExternalLinks=true s.linkInternalFilters="javascript:,mysite.com" s.linkExternalFilters="site1.com,site2.com,site3.com/partners" s.linkLeaveQueryString=false

...

Syntax and Possible Values

The linkExternalFilters variable is a comma-separated list of ASCII characters. No spaces are allowed.

s.linkExternalFilters="site1.com[,site2.com[,site3.net[...]]]"

Any portion of a URL might be included in linkExternalFilters, separated by commas.

Examples

s.linkExternalFilters="partnersite.com,partnertwo.net/path/" s.linkExternalFilters=""

Configuration Settings

None

Pitfalls, Questions, and Tips

• Using linkExternalFilters can result in fewer links on your site being exit links. Do not use this variable in place of

linkInternalFilters to force internal links to become exit links.

Analytics Variables 77

• If linkExternalFilters should be applied to the query string of a link, make sure linkLeaveQueryString is set to 'true.'

See

linkLeaveQueryString

before setting to

"true"

• To disable exit link tracking, set trackExternalLinks to

"false"

linkInternalFilters

The linkInternalFilters variable is used to determine 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.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

Paths > Entries & Exits >

Exit Links

Default Value

"javascript:"

The linkInternalFilters variable is used to determine whether a link is an exit link, which is defined as any link that takes a visitor away from your site. Whether the target window of an exit link is a pop-up, or the existing window, does not affect whether the link appears in the exit links report. Exit links are only tracked if trackExternalLinks is set to

"true"

. The filters in linkInternalFilters are not case-sensitive.

The list of filters in linkInternalFilters applies to the domain and path of any link by default. If linkLeaveQueryString is set to

"true"

, then the filters apply to the entire URL (domain, path, and query string). The filters are always applied to the absolute path of the URL, even if a relative path is used as the href value.

Be careful that all the domains of your site (and any partners who are using your JavaScript file) are included in

linkInternalFilters. If you do not have all domains included in the list, all links on and to those domains are considered exit links, increasing the server calls sent. If you would like multiple domains or companies to use a single

AppMeasurement for JavaScript file, you may consider populating linkInternalFilters on the page, overriding the value specified in the JavaScript file. If you have vanity domains that immediately redirect to your main domain, those vanity domains do not need to be included in the list.

The following example illustrates how this variable is used. In this example, the URL of the page is http://www.mysite.com/index.html

s.trackExternalLinks=true s.linkInternalFilters="javascript:,mysite.com" s.linkExternalFilters="" s.linkLeaveQueryString=false

...

Syntax and Possible Values

The linkInternalFilters variable is a comma-separated list of ASCII characters. No spaces are allowed.

s.linkInternalFilters="javascript:,site1.com[,site2.com[,site3.net[...]]]"

The default value of linkInternalFilters contains

"javascript:"

because any links to a JavaScript function are not usually exit links. If

"javascript:"

were not in the list, then all links to JavaScript functions would be considered external.

Analytics Variables 78

Examples

s.linkInternalFilters="javascript:,mysite.com" s.linkInternalFilters="javascript:,mysite.com,mysite.net,vanity1.com"

Configuration Settings

None

Pitfalls, Questions, and Tips

• Include all domains that the AppMeasurement for JavaScript file may be served under in the filter list.

• Periodically check the Paths > Entries & Exits > Exit Links report to make sure that none of the entries in that report are incorrect.

• Periodically review partner contracts to determine if they contain restrictions on link tracking. For example, you might be prohibited from tracking links that appear in partner display ads. Filter partner links by adding their domain to linkInternalFilters: s.linkInternalFilters="javascript:,mysite.com,mysite.net,mypartner.net/adclick"

linkLeaveQueryString

By default, query strings are excluded from all reports.

For some exit links and download links, the important portion of the URL can be in the query string, as shown in the following sample URL.

http://www.mycompany.com/download.asp?filename=myfile.exe

The download file name can be defined in the query string and, consequently, the query string is necessary to make the File Downloads report more accurate.

The linkLeaveQueryString variable determines whether or not the query string should be included in the Exit Links and File Download reports.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

Exit Links

File Downloads

Default Value

false

Note: Setting linkLeaveQueryString=true includes all query string parameters for all exit links and download links.

Syntax

s.linkLeaveQueryString=[false/true]

Examples

s.linkLeaveQueryString=false

Possible Values

s.linkLeaveQueryString=false s.linkLeaveQueryString=true

Analytics Variables

Configuring the Variable

No configuration is necessary for this variable.

Pitfalls, Questions, and Tips

• Setting s.linkLeaveQueryString=true includes all query string parameters for all exit links and download links.

• The linkLeaveQueryString variable does not affect recorded page URLs, visitor click map, or Path reports.

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).

linkTrackEvents

The linkTrackEvents variable is a comma-separated list of events that are sent with a custom, exit, or download link.

Analytics Variables 80

If an event is not in linkTrackEvents, it is not sent to Analytics, even if it is populated in the onClick event of a link, as shown in the following example: s.linkTrackVars="events" s.events="event1,event2" s.t() // both event1 and event2 are recorded

<a href="help.php" onClick="s=s_gi('rs1');s.tl(this,'o')">event1 is recorded</a>

<a href="test.php" onClick="s=s_gi('rs1');s.events='event2';s.tl(this,'o')">No events are recorded</a>

In the first link to help.php

, notice that the events variable retains the value that was set before the link was clicked,.

This allows event1 to be sent with the custom link. In the second example, the link to test.php

, event2 is not recorded because it is not listed in linkTrackEvents.

To avoid confusion and potential problems, Adobe recommends populating linkTrackVars and linkTrackEvents in the onClick event of a link that is used for link tracking.

The linkTrackEvents variable contains the events that should be sent with custom, download, and exit links. This variable is only considered if linkTrackVars contains "events."

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

Conversion

Default Value

"None"

Syntax and Possible Values

The linkTrackEvents variable is a comma-separated list of events (no spaces).

s.linkTrackEvents="event1[,event2[,event3[...]]]"

Only event names are allowed in linkTrackEvents. These events are listed in

Events

. If a space appears before or after the event name, the event can not be sent with any link image requests.

Examples

s.linkTrackEvents="purchase,event1" s.linkTrackEvents="scAdd,scCheckout,purchase,event14"

Configuration Settings

None

Pitfalls, Questions, and Tips

• The JavaScript file only uses linkTrackEvents if linkTrackVars contains the "events" variable. "events" should be included in linkTrackVars only when linkTrackEvents is defined.

• Beware if an event is fired on a page, and is listed in linkTrackEvents. That event is recorded again with any exit,

download, or custom links unless the events variable is reset prior to that event (in the onClick of a link or after the call to the t() function).

• If linkTrackEvents contains spaces between event names, the events are not recorded.

linkTrackVars

The linkTrackVars variable is a comma-separated list of variables that are sent with custom, exit, and download links.

Analytics Variables 81

If linkTrackVars is set to "", all variables that have values are sent with link data. To avoid inflation of instances or page views associated with other variables, Adobe recommends populating linkTrackVars and linkTrackEvents in the onClick event of a link that is used for link tracking.

All variables that should be sent with link data (custom, exit, and download links) should be listed in linkTrackVars.

If linkTrackEvents is used, linkTrackVars should contain "events."

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

Any

Default Value

"None"

When populating linkTrackVars, do not use the 's.' prefix for variables. For example, instead of populating linkTrackVars with "s.prop1," you should populate it with "prop1." The following example illustrates how linkTrackVars should be used.

s.linkTrackVars="eVar1,events" s.linkTrackEvents="event1" s.events="event1" s.eVar1="value A" s.eVar2="value B" s.t() // eVar1, event1 and event2 are recorded

<a href="http://google.com">event1 and eVar1 are recorded</a>

<a href="test.php" onClick="s=s_gi('rs1');s.eVar1='value C';s.events='';s.tl(this,'o')">eVar1

is recorded</a>

Because the link to google.com is an exit link (unless you are Google), event1 and eVar1 are sent with the exit link data, increasing the instances associated with eVar1 and the number of times event1 is fired. In the link to test.php

eVar1 is sent with a value of 'value C' because that is the current value of eVar1 at the time that tl() is called.

Syntax and Possible Values

The linkTrackVars variable is a case-sensitive, comma-separated list of variable names, without the object name prefix. Use 'eVar1' instead of 's.eVar1.' s.linkTrackVars="variable_name[,variable_name[...]]"

The linkTrackVars variable may contain only variables that are sent to Analytics, namely: events, campaign,

purchaseID, products, eVar1-75, prop1-75, hier1-5, channel, server, state, zip, and pageType.

Examples

s.linkTrackVars="events,prop1,eVar49" s.linkTrackVars="products"

Configuration Settings

None

Pitfalls, Questions, and Tips

• If linkTrackVars is blank, all variables that have values are tracked with all server calls.

• Any variable listed in linkTrackVars that has a value at the time of any download, exit, or custom link, are tracked.

• If linkTrackEvents is used, linkTrackVars must contain "events."

• Do not use the "s." or "s_objectname." prefix for variables.

Analytics Variables 82

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

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 may only contain a single character, namely 'o,' 'e,' or 'd.' s.tl(this,’o’,’Link Name’);

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 Variables 83

• 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.

To change a prop into a list prop, a Supported User must contact ClientCare and provide:

• The Report Suite ID (RSID).

• The traffic variable you wish to become a list prop.

• The list prop delimiter. Popular ones are colons, semi-colons, commas, or pipes. It can technically be any of the first 127 ASCII characters.

List props are not visible in the Admin Console. As such, take note of this setting in either the prop's report or outside of Analytics.

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:

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.

• Each delimited value can contain a maximum of 255 characters (or less if using multi-byte characters).

• 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.

Analytics Variables 84

Configuration

An Adobe representative must enable List Vars. The following customizations are available, which are to be included when requesting to enable one:

• 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.

• 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. The default is unlimited (0).

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 begin using List Vars or enable another List Var, please have one of your organization's supported users contact

ClientCare with the following information:

• The delimiter you want to use to separate each value

• When you want the variable to expire

• Whether to use full or linear allocation

• (Optional) The maximum number of values that are allowed per image request

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:

Analytics Variables 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

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.

Analytics Variables 86

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:

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

100 Bytes

Debugger Parameter

pev3

Reports Populated Default Value

Videos; Next Video Flow;

Previous Video Flow; Video

Segments Viewed; Time

Spent on Video

None

Analytics Variables 87

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)

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.

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

Analytics Variables 88

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

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

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")

Analytics Variables 89

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.

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”

Analytics Variables

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

/5/ or /1/ in path of image url

Reports Populated

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.

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"

Analytics Variables 91

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 ClientCare 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.

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.

Analytics Variables 92

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 >

plugins

The plugins variable, in Netscape and Mozilla-based browsers, lists the plugins installed 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.

Analytics Variables

Query Param

Value

Recognized plugins

Example Reports Affected

IE Tab Plug-in;QuickTime

Plug-in 7.1.6;Mozilla Default

Plug-in;iTunes Application

Detector;Adobe

Acrobat;ActiveTouch

General Plugin

Container;Shockwave

Flash;Microsoft Office

2003;Java(TM) Platform SE

6 U1;Windows Media

Player Plug-in Dynamic Link

Library;Microsoft

DRM;

Traffic > Technology >

Plugins

products

The products variable is used for tracking products and product categories as well as purchase quantity and purchase price. Products is typically set in conjunction with a cart event or a product view event.

The products variable tracks how users interact with products on your site. For instance, the products variable can track how many times a product is viewed, added to the shopping cart, checked out, and purchased. It can also track the relative effectiveness of merchandising categories on your site. The scenarios below are common for using the products variable.

The products variable should always be set in conjunction with a success event.

Max Size Debugger Parameter

The "Product" and

"Category" sections of products each have a limit of 100 bytes. Adobe does not impose a size limit on products, though most browsers impose a size limit on the total URL length of image requests.

products

Reports Populated

Products

Categories (deprecated)

Revenue (optional)

Units (optional)

Custom Events (optional) eVars (optional)

Default Value

" "

Syntax of the Products Variable

"Category;Product;Quantity;Price;eventN=X[|eventN2=X2];eVarN=merch_category[|eVarN2=merch_category2]"

Field

propN

Property (prop) variables are used for building custom reports within the Traffic Module.

The props variable may be used as counters (to count the number of times a page view is sent), for pathing reports, or in correlation reports.

Analytics Variables 97

Max Size

100 bytes

Debugger Parameter

c1-c75

Reports Populated

Custom Traffic

Default Value

Syntax and Possible Values

s.propN="value"

There are no limitations on property variables outside of the standard variable limitations.

Examples

s.prop2="editorial" s.prop15="toy category"

Configuration Settings

Contact Adobe ClientCare about showing Visit, Visitor, and Path metrics for prop variables.

purchaseID

The purchaseID is used to keep an order from being counted multiple times in reporting.

Whenever the purchase event is used on your site, you should use the purchaseID variable.

Max Size

20 bytes

Debugger Parameter

purchaseID

Reports Populated

Conversion > Purchases >

Revenue Conversion

Default Value

When a visitor purchases an item from your site, purchaseID is populated on the "Thank You" page at the same place the purchase event is fired. If the purchaseID is populated, the products on the "Thank You" page are counted only once per purchaseID. This is critical because many visitors to your site will save the "Thank You" or "Confirmation

Page" for their own purposes. The purchaseID keeps purchases from being counted each time the page is viewed.

In addition to keeping the purchase data from being counted twice, the purchaseID, when used, keeps all conversion data from being double counted in reports.

Syntax and Possible Values

s.purchaseID="unique_id"

The purchaseID must be 20 characters or fewer, and be standard ASCII.

Examples

s.purchaseID="11223344" s.purchaseID="a8g784hjq1mnp3"

Configuration Settings

None

Pitfalls, Questions, and Tips

The purchaseID variable allows all conversion variables on the page to be counted only once in reports.

Analytics Variables 98

referrer

The referrer variable can be used to restore lost referrer information.

Server-side and JavaScript redirects are often used to route visitors to proper locations. However, when a browser is redirected, the original referring URL is lost.

Max Size

255 bytes

Debugger Parameter

Reports Populated

Traffic > Finding Methods

Conversion > Finding

Methods

Default Value

document.referrer

Many companies use redirects in many places throughout their websites. For example, a visitor may be sent through a redirect from a search engine paid search result. When a browser is redirected, the referrer is often lost. The

referrer variable may be used to restore the original referrer value on the first page after a redirect. The referrer may be populated server-side, or via JavaScript from the query string.

For Analytics to record a referrer, it must be "well formed," meaning that it must follow the standard URL format, with a protocol and appropriate location.

Syntax and Possible Values

s.referrer="URL"

Only URL-compatible values should be in the referrer. Make sure the string is URL encoded (no spaces).

Examples

s.referrer="http://www.google.com/search?q=search+string" s.referrer=<%=referrerVar%> // populated server-side if(s.getQueryParam('ref') s.referrer=s.getQueryParam('ref')

Configuration Settings

None

Pitfalls, Questions, and Tips

The referrer must look like a standard URL and include a protocol.

resolution

The resolution variable indicates the monitor resolution of the visitor viewing the web 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.

Analytics Variables

Query Param

Value

WxH

Example

1680x1050

Reports Affected

Traffic > Technology >

Monitor Resolution

s_objectID

The s_objectID variable is 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 either improve visitor click map tracking or use visitor click map to report on a link type or location, rather than the link URL.

Max Size

100 Bytes

Debugger Parameter

OID

Reports Populated

ClickMap

Default Value

The Absolute URL of a

Clicked Link

There are three common reasons to use s_objectID:

• To aggregate clicks on links that change often during a day

• To separate clicks on links that visitor click map combines

• To improve accuracy of visitor click map data reporting

Aggregate Clicks on Highly Dynamic Links

If your site is highly dynamic, and links on some pages change throughout the day, s_objectID may used to identify the location of a link on the page. If s_objectID is set to "top left 1" or "top left 2," which represents the first link in the top left of the page for example, then all links that appear in that location (or that have s_objectID set to the same value) are reported together with visitor click map. If you don't use s_objectID, you see the number of times that a specific link was clicked, but you lose insight into how all the other links in that location were used by visitors to your site.

Separate Clicks Combined

If the pageName variable on your site is used to show the section or template a visitor is viewing, rather than the specific page the visitor is viewing, you may want to use s_objectID to separate links that appear on multiple versions of that page template. For example, if you have a template page for all products on your site, it is likely that there is a link to your home page and to a search box from that template on all pages. If you want to see how those links are used on an individual product basis (rather than a template basis), you can populate s_objectID with a product specific value such as "prod 123789 home page" or "prod 123789 search." Once completed, visitor click map reports on those links at an individual product basis.

Improving visitor click map Accuracy

In some cases, browsers other than Internet Explorer, Firefox, Netscape, Opera, and Safari are not reported. Although this is a small percentage, it accounts for some clicks and other metrics. Using s_objectID within links to uniquely identify the addresses the browser reporting issue. The following is an example of how to update your links to use

s_objectID:

<a href="/art.jsp?id=559" onClick="s_objectID='top left 1'">Article 559</a>

Analytics Variables

Syntax and Possible Values

s_objectID may contain any text identifier.

s_objectID="unique_id"

There are no limitations on s_objectID outside of the standard variable limitations.

Examples

s_objectID="top left 2" s_objectID="prod 123789 search"

Configuration Settings

None

100

server

The server variable is used to show 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).

Max Size

100 bytes

Debugger Parameter

server

Reports Populated

Servers

Default Value

If your site has more than one domain serving the same content, the server variable can be used to track which of those domains visitors are using. The following JavaScript will populate the domain of the page into the server variable.

s.server=window.location.hostname

If you are using the server variable to give a quick guide to load balancing, you could put a server name or number into the server variable. See the following example: s.server="server 14"

While the Most Popular Servers report may be used as a load balancing quick reference, it is not a precise measure of server load. For example, back-button traffic does not increase server load, but is shown in reports. The report does not show which servers are serving images or large downloads.

Syntax and Possible Values

s.server="server_name"

There are no limitations on the server variable outside of the standard variable limitations.

Examples

s.server="server 18" s.server=window.location.hostname

Configuration Settings

None

Analytics Variables 101

Pitfalls, Questions, and Tips

The server variable can be used to show which domains are most popular or which servers are serving the most pages.

state

The state and zip variables are conversion variables.

They are like eVars in that they capture events, but unlike eVars, they don't persist. The zip and state variables are like eVars that expire immediately.

Max Size

50 bytes

Debugger Parameter

state

Reports Populated Default Value

Conversion > Visitor Profile

> States

Because the state and zip variables expire immediately, the only events associated with them are events that are fired on the same page on which they are populated. For example, if you are using state to compare conversion rates by state, you should populate the state variable on every page of the checkout process. For conversion sites,

Adobe recommends using the billing address as the source for the Zip Code, but you may choose to use the shipping address instead (assuming there is only one shipping address for the order). A media site may choose to use zip and state for registration or ad click-through tracking.

Syntax and Possible Values

s.state="state"

The state variable does not impose any special value or format restrictions. There are no limitations on state outside of the standard variable limitations.

Examples

s.state="california" s.state="prince edward island"

Configuration Settings

None

Pitfalls, Questions, and Tips

• Populate state on every page that a relevant event is fired (such as each page of the checkout process).

• The zip and state variables act like eVars that expire on the Page View.

timestamp

This variable lets you customize the timestamp of a hit similar to the AppMeasurement libraries for other platforms.

Max Size

4 bytes

Debugger Parameter

Date/Time

Reports Populated

Not reported directly.

Default Value

Set by data collection servers.

Analytics Variables 102

Syntax

s.timestamp="UNIX or ISO-8601 format timestamp"

The timestamp variable must be in the format explained in the next section.

Important: Your report suite must be timestamp-enabled by Customer Care before you can use the timestamp variable. After timestamp support is enabled, all hits sent to this report suite from JavaScript must have a timestamp manually set (using s.timestamp) or the hits will not be recorded.

Additionally, if you enable timestamp support on a report suite to support offline tracking, all hits sent to this report suite from JavaScript must also have a timestamp manually set (using s.timestamp). You cannot send both time-stamped and non-time-stamped hits to the same report suite.

Timestamp Formats

Timestamps must be in UNIX (seconds since Jan 1st 1970) or ISO-8601 format, with the following restrictions on the accepted ISO-8601 format:

• Both date and time must be provided, separated by "T"

• The date must be a calendar date with full precision (year, month, and day). . Week dates and ordinal dates are not supported.

• The date can be in standard or extended format (

YYYY-MM-DD

YYYYMMDD

), but they must include the hour and minute. Seconds are optional (

HH:MM

HH:MM:SS

HHMM

, or

HHMMSS

). Fractional minutes and seconds can be passed in, but the fractional part is ignored.

• An optional timezone can be specified in standard or extended format (

±HH

±HH:MM

±HH

±HHMM

, or Z)

UNIX timestamps continue to be supported (seconds since Jan 1st 1970).

Examples

s.timestamp=Math.round((new Date()).getTime()/1000); s.timestamp="2012-04-20T12:49:31-0700";

The following list contains examples of valid ISO-8601 format timestamps:

2013-01-01T12:30:05+06:00

2013-01-01T12:30:05Z

2013-01-01T12:30:05

2013-01-01T12:30

Configuration Settings

A report suite must be enabled to accept custom timestamps by ClientCare before you can use this variable. After custom timestamps are enabled, all hits sent to the report suite must contain a timestamp or they are discarded.

Pitfalls, Questions, and Tips

• Timestamps are primarily used to track offline data on mobile platforms. Custom timestamps are typically disabled unless you are collecting both web and offline app data in the same report suite.

trackDownLoadLinks

Set trackDownloadLinks to 'true' if you would like to track links to downloadable files on your site.

If trackDownloadLinks is 'true,' linkDownloadFileTypes is used to determine which links are downloadable files.

Analytics Variables 103

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

True

The trackDownloadLinks variable should only be set to 'false' if there are no links to downloadable files on your site, or you don't care to track the number of clicks on downloadable files. If trackDownloadLinks is 'true,' when a file download link is clicked, data is immediately sent to Analytics. The data that is sent with a download link includes the link download URL, and visitor click map data for that link. If trackDownloadLinks is 'false,' then visitor click map data for links to downloadable files on your site is likely to be under reported.

Syntax and Possible Values

The trackDownloadLinks variable is expected to be either 'true' or 'false.'

Examples

s.trackDownloadLinks=true s.trackDownloadLinks=false

Configuration Settings

None

Pitfalls, Questions, and Tips

• When trackDownloadLinks is 'false,' links that people use to download files on your site are likely to be under reported in visitor click map.

• When trackDownloadLinks is 'true,' data is sent each time a visitor clicks a file download link.

trackExternalLinks

If trackExternalLinks is 'true,' linkInternalFilters and linkExternalFilters are used to determine whether any link clicked is an exit link.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

True

The trackExternalLinks variable should only be set to 'false' if there are no exit links on your site, or if you don't care to track the number of clicks on those exit links. An exit link is any link that takes a visitor off of your site. If

trackExternalLinks is 'true,' then when you click an exit link, tracking data is immediately sent. The data that is sent with an exit link includes the link URL, link name, and visitor click map data for that link. If trackExternalLinks is

'false,' then visitor click map data for exit links on your site is likely to be under reported.

Syntax and Possible Values

The trackExternalLinks variable is expected to be either 'true' or 'false.' s.trackExternalLinks=true|false

Examples

s.trackExternalLinks=true s.trackExternalLinks=false

Analytics Variables

Configuration Settings

None

Pitfalls, Questions, and Tips

• When trackExternalLinks is 'false,' links that take people away from your site are likely to be under reported in visitor click map.

• When trackExternalLinks is 'true,' data is sent each time a visitor clicks on an exit link (before link target loads).

104

trackingServer

The trackingServer variable is used for first-party cookie implementation to specify the domain at which the image request and cookie is written.

Used for non-secure pages. If trackingServer is defined, nothing goes to 2o7.net. If trackingServer is not defined

(and dc is not defined), data goes to 112.2o7.net.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

trackingServerSecure

The trackingServerSecure variable is used for first-party cookie implementation to specify the domain at which the image request and cookie is written.

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

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

trackInlineStats

The trackInlineStats variable determines whether visitor click map data is gathered.

If trackInlineStats is 'true,' data about the page and link clicked are stored in a cookie called s_sq. If 'false,' s_sq will have a value of "[[B]]," which is considered null.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

ClickMap

Default Value

True

Syntax and Possible Values

s.trackInlineStats=true|false

The trackInlineStats variable is expected to be either 'true' or 'false.'

Examples

s.trackInlineStats=true s.trackInlineStats=false

Analytics Variables

Configuration Settings

None

105

transactionID

Integration Data Sources use a transaction ID to tie 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

Data Sources

Max Size

100 bytes

Debugger Parameter

xact

Reports Populated

n/a

Default Value

Syntax and Possible Values

s.transactionID="unique_id"

The transactionID should contain only alphanumeric characters. If multiple transactionIDs should be recorded in a single hit, you can use a comma to delimit multiple values.

Examples

s.transactionID="11123456" s.transactionID="lead_12345xyz" s.transactionID=s.purchaseID

Configuration Settings

Before transactionID values are recorded, transactionID recording must be enabled by an Adobe representative.

To see whether transactionID recording is enabled for a report suite, go to reporting and analytics > Data Sources

> Manage.

Pitfalls, Questions, and Tips

• If transactionID recording is not enabled, transactionID values will be discarded and unavailable for use with

Integration Data Sources. Make sure to set a conversion variable or event (an eVar or the events variable) on the page where transactionID is set. Otherwise, no data is recorded for the transactionID.

• If you are recording transactionIDs for multiple systems, such as purchases and leads, make sure the value in

transactionID is always unique. This can be accomplished by adding a prefix to the ID, such as lead_1234 and purchase_1234. Integration Data Sources do not function as expected (Data Source data will tie to the wrong data) if a unique transactionID is seen twice.

• By default, transactionID values are remembered for 90 days. If your offline interaction process is longer than 90 days, contact Customer Care to have the limit extended.

Note: The transactionID variable can contain any character other than a comma. It should be in the same location where the character limit (100 bytes) is specified. If multi-byte characters are used, multi-byte character support must be enabled in order to avoid problems with unexpected characters in the transactionID.

Analytics Variables 106

s_usePlugins

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.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

True

Syntax and Possible Values

s.usePlugins=true|false

The usePlugins variable is expected to be either 'true' or 'false.'

Examples

s.usePlugins=true s.usePlugins=false

The usePlugins variable should only be false (or not declared) if the s_doPlugins function is not declared in your

JavaScript file.

Configuration Settings

None

visitorID

Visitors can be identified by the visitorID variable or by IP address/User Agent.

The visitorID can be up to 100 alpha-numeric characters and must not contain a hyphen.

Max Size

100 bytes

Debugger Parameter

vid

Reports Populated

n/a

Default Value

Syntax and Possible Values

s.visitorID="visitor_id"

Note: The visitorID variable should not contain a hyphen.

Examples

s.visitorID="abc123"

Configuration Settings

None

Analytics Variables 107

visitorNamespace

The visitorNamespace variable is used to identify the domain with which cookies are set.

If visitorNamespace is used in your JavaScript file, do not delete or alter it. If visitorNamespace changes, all visitors reported in Analytics may become new visitors. Visitor history becomes disconnected from current and future traffic.

Do not alter this variable without approval from an Adobe representative.

Max Size

N/A

Debugger Parameter

N/A

Reports Populated

N/A

Default Value

Analytics uses a cookie to uniquely identify visitors to your site. If visitorNamespace is not used, the cookie is associated 2o7.net. If visitorNamespace is used, the cookie is associated with a sub-domain of 2o7.net. All visitors to your site should have their cookies associated with the same domain or sub-domain.

The reason for using the visitorNamespace variable is to avoid the possibility of overloading a browser's cookie limit.

Internet Explorer imposes a limit of 20 cookies per domain. By using the visitorNamespace variable, other companies'

Analytics cookies will not conflict with your visitors' cookies.

Syntax and Possible Values

The value of visitorNamespace must be provided by Adobe and is a string of ASCII characters that don't contain commas, periods, spaces, or special characters.

s.visitorNamespace="company_specific_value"

Examples

s.visitorNamespace="company_name" s.visitorNamespace="Adobe"

Configuration Settings

None

Pitfalls, Questions, and Tips

• If you use a CNAME to make Analytics cookies into first-party cookies, the s.visitorNamespace variable may be left blank. It is acceptable to leave it as constituted.

• If your third-party cookie implementation uses the s.trackingServer variable, you may not have an

s.visitorNamespace variable. This is normal. The s.trackingServer variable serves the same purpose as

s.visitorNamespace.

zip

The state and zip variables are conversion variables.

They are like eVars in that they capture events, but unlike eVars, they don't persist. The zip and state variables are like eVars that expire immediately.

Analytics Variables 108

Max Size

50 bytes

Debugger Parameter

zip

Reports Populated Default Value

Conversion > Visitor Profile

> ZIP/Postal Codes

Since the state and zip variables expire immediately, the only events associated with them are events fired on the same page that are populated. For example, if you are using zip to compare conversion rates by Zip Code, you should populate zip on every page of the checkout process. Adobe recommends using the billing address as the source for the Zip Code. You may choose to use the shipping address instead (assuming there is only one shipping address for the order). A media site may choose to use zip and state for registration or ad click-through tracking.

Syntax and Possible Values

s.zip="zip_code"

The zip variable does not impose any value or format restrictions. There are no limitations on zip outside of the standard variable limitations.

Examples

s.zip="92806" s.zip="92806-4115"

Configuration Settings

None

Pitfalls, Questions, and Tips

• Populate zip on every page in which a relevant event is fired (such as each page of the checkout process).

• The zip and state variables act like eVars that expire on the Page View.

Context Data Variables 109

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.

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.

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 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.

URL Limits When using context data variables on the Web, be aware of the URL limits of browsers. For example, IE truncates URLs at 2000 bytes. You can use the

DigitalPulse debugger to determine the size of a URL string.

Supported AppMeasurement version Context data variables require at least H23 code or higher.

Context Data Variables 110

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.

Processing Rules

Processing rules let you make changes to data as it is received.

For more information, see

Processing Rules

in the Analytics Reference.

Dynamic Variables 111

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.

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.

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

Dynamic Variables 112

• 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.

Dynamic Variables 113

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.

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-Agentprefixed by "UA:"

This example searches for a uniqueheader, which in this case is X-TM-ANTID.

Merchandising Variables 114

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:

Before checkout, the customer searches for "winter coat", and then adds a down jacket to the to the cart:

Merchandising Variables 115

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:

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.

Merchandising Variables 116

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

Description

Determines how long merchandising values should persist.

Merchandising

Product Syntax

: The value is set within s.products

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"

Merchandising Variables 117

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"

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.

Instances on Merchandising Variables

Describes how instances are counted on merchandising variables.

Instances are not currently counted for merchandising variables that use Product Syntax. If you have selected

Product Syntax and have implemented according to these directions, you should not see instances for this variable.

If instances are being counted, it indicates that the eVar is being set in some locations outside of the products string, which is unnecessary.

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.

Merchandising Variables 118

• 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 119

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.

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 120

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.

linkType 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

The s.tl() Function - Link Tracking 121

Variable Description

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

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 s.tl() Function - Link Tracking 122

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.

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.

The s.tl() Function - Link Tracking 123

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.

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.

The s.tl() Function - Link Tracking 124

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.

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 s.tl() Function - Link Tracking 125

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.

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,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;

The s.tl() Function - Link Tracking 126

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.

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:

The s.tl() Function - Link Tracking 127

This allows the link to be tracked and the popup to load as expected.

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.

Variable

linkType

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.

linkName

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.

linkURL

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 linkObject

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.

The s.tl() Function - Link Tracking 128

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 129

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.

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 130

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 AppMeasurement for JavaScript , it is not available in H code and previous.

The s_gi() Function 131

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).

132 Data Collection

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 Description

None

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:

Each of these examples result in a context data value of my.a = red

Multiple key-value pairs can be specified.

Data Collection

Parameter

-g c1-c75 cc cdp ce cl ch ct

D events or ev j h1-h5 hp

133

Analytics Variable Report Populated Description

In the query string, this context data variable would appear as c.my.a=red s.prop1-s.prop75

s.currencyCode

s.cookieDomainPeriods

s.charSet

All Custom Traffic reports

None

Traffic variables used in custom traffic reporting

The type of currency used on the site

Indicates the number of periods in a domain for cookie tracking; manually set.

The character encoding of the image request s.cookieLifetime (s_vi cookie lifetime in seconds) s.channel

None The lifetime of the visitor cookie.

Site Content | Site Sections The Site Sections variable used in traffic reporting

None dynamicVariablePrefix

Visitor Profile | Technology

| Connection Types

Connection Type (Modem,

LAN, etc; can only populate in IE browsers)

None

See

Dynamic Variables

s.events

None

None s.hier1-s.hier5

None

Site Traffic | Purchases,

Shopping Cart, Custom

Events

None

The commerce and custom events that occurred on the page; used in conversion reports

The current URL of the page, up to 255 bytes.

None URLs longer than 255 bytes are split, with the first 255 bytes appearing in the g parameter, with the remaining bytes appearing later in the query string in the -g= query parameter.

Hierarchy variables; used in traffic reporting

Site Content | Hierarchy reports

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)

Data Collection

Parameter

k l1-l3 pe pev1 pev2 pev3 pid pidt mid ndh ns oid ot p pageName (or gn) pageType (or gt) pccr

Analytics Variable

None s.list1-s.list3

s.linkType

None

None s.visitorNameSpace

s.objectID

None

None s.pageName

s.pageType

None

134

Report Populated Description

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

Semicolon delimited browser plug-in names

Site Content | Pages 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

Site Content | Links | Exit

Links, File Downloads,

Custom Links

All video reports

URL the custom link hit occurred on

Custom link friendly name

Site Content | Links |

ClickMap

Site Content | Links |

ClickMap

Used to track milestones in legacy video reporting; deprecated with v15

Page identifier for last page; used in ClickMap

Page identifier type for last page; used in ClickMap

v v0 v1-v75 vid vmk

Data Collection

Parameter

products (or pl) purchaseID (or pi) t r s server (or sv) state ts

135

Analytics Variable

s.products

s.purchaseID

s.referrer

None s.server

Report Populated

Products | Products

Description

Products variable used in conversion reporting

None Used to deduplicate purchases, preventing revenue inflation

Referring URL All traffic sources reports

Visitor Profile | Technology

| Monitor Resolutions

Screen resolution (width × 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; deprecated with v15

(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:

09/23/2013 14:00:00 1

420 timestamp

None s.campaign

s.eVar1-s.eVar75

s.visitorID

s.vmk

None

The custom timestamp calculated and sent in with the hit. Typically used for offline tracking.

Visitor Profile | Technology

| JavaScript

JavaScript enabled (Y or N)

Campaigns | Tracking

Codes

The campaign variable used in conversion reporting

All Custom Conversion reports

Conversion variables used in custom conversion reporting

None

The visitor's unique ID as set in the

visitorID

variable.

Visitor migration key; used to migrate from third-party

Data Collection

Parameter Analytics Variable

vvp xact s.variableProvider

s.transactionID

zip s.zip

/5/ (for mobile protocol) or

/1/ (for non-mobile protocol) in the image request URL.

None

Report Populated

None

Visitor Profile | Visitor

ZIP/Postal Code

None

136

Description

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

X-Bolt-Phone-UA

UA-OS

UA-Pixels

Usage

Reading cookies previously created by our data collection servers. All of these cookies are prefixed by "s_" like our visitor ID cookie "s_vi" except for out opt-out cookie

"omniture_optout".

Used for browser, operating system, and mobile device detection.

User-Agent

X-Device-User-Agent

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.

X-Skyfire-Phone

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.

UA-Color

X-moz

X-Purpose

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.

Data Collection 137

Referrer

X-Forwarded-For

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

Last-Modified

Cache-Control

Pragma

Browser caching control.

ETag

Vary

P3P

Status

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.

Reason

Location

Content-Type

Content-Length

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.

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";

Data Collection 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"

138

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

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

Data Collection 139

Portion

Portion

Host/Domain Name

Path

Query String

Host/Domain and Path

Path and Query String

URL

Example (from above)

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.

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.

Data Collection 140

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.

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.

Data Collection 141

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: Depending on your data center and location, these can greatly vary. Have one of your organization's supported users contact Adobe ClientCare if you are not sure which one to use:

Non-RDC domains

• San Jose:

112.2o7.net

• Dallas: 1

22.2o7.net

RDC domains

• San Jose: d1.sc.omtrdc.net

• Dallas: d2.sc.omtrdc.net

• London: d3.sc.omtrdc.net

Data Collection 142

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";

Data Collection 143

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.

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.

Data Collection 144

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.

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.

Data Collection 145

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:

• 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.

Data Collection 146

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.

• 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 e-mail campaign.

Companies often develop costly e-mail campaigns to market their products. The companies send bulk emails to customers with the expectation that some customers access the site and a conversion results. Analytics can report 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:

Data Collection 147

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

Contact Adobe ClientCare 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 ClientCare 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.

Data Collection 148

• 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).

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 ClientCare 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.

Tracking External Emails

In addition to the external campaigns described in the previous section, you can report campaign analysis data in several additional key metrics with configurations made by Adobe ClientCare.

Campaign Type

Emails Sent

Emails Delivered

Emails Opened

Description

Displays the total number of emails sent by the company. This metric is provided by the email vendor.

Displays the total number of emails delivered to email servers. This metric is provided by the email vendor.

Displays the number of times the visitors opened the email.

For more information on tracking email campaign analysis data, contact Adobe ClientCare. Tracking email campaign analysis data is considered on a case-by-case basis. This is done only through Data Sources.

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.

149

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 150

/* 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 151 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

tl function. For more information on custom links, see

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 152

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 153

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).

DigitalPulse Debugger

The 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

DigitalPulse 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.

DigitalPulse Debugger Installation

DigitalPluse 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 154

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 DigitalPulse Debugger from within Mozilla Firefox.

1. Right-click the bookmarks sidebar, then click New Bookmark.

2. In the Name field, specify "DigitalPulse 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

3. In the URL field, paste the code that you copied to your clipboard as explained in

Installation

4. Select Load the Bookmark in the Sidebar, if desired.

5. Click Add.

Google Chrome

Instructions to create a bookmark for the 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 "DigitalPulse Debugger" as the name for the new bookmark.

DigitalPulse 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 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 labeled "Omniture Help."

2. Right-click the "Omniture Help" bookmark, then click Rename.

3. In the New Name field, specify "DigitalPulse 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

DigitalPulse 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 155

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 156

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 ClientCare 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.

• If you implement Adobe Analytics products with your own first-party cookie, you need to

supports deploying the library and page code in the

<head>

tag.

Testing and Validation 157

Previously, a common implementation practice was to place the Analytics JavaScript code between the <head> and

</head> tags. By placing the code between these tags it prevented the 1×1 pixel image that was returned by the request that sent data into Adobe servers from affecting page layout in any way. Putting code in the document head means the code appears earlier in the code. This lets it execute sooner, which lets you count page views for partial page loads more effectively.

Certain elements of the code require the existence of the body object. Since Web browsers execute code in the order they receive it, if the Analytics JavaScript code is in the document head, it executes before the body object exists. As a result, your implementation does not collect ClickMap data, and automatic tracking of file downloads or exit links are not available. You also do not receive connection type data or visitor home page data. Putting the code in the document head works, but the result is a very limited version of Analytics, and users may wonder why certain reports and tools, including ClickMap, aren't recording data.

The Analytics code can be placed anywhere inside BODY tags ( <BODY></BODY>) of a well-formed HTML page.

Adobe recommends placing the code in a global include file at the top of the page (inside the HTML body tag). The code can be placed anywhere on the page, except as noted below:

• If placed within a table, post the code only within the <td></td> tags. For example, do not place the code between an opening <tr> tag and an opening <td> tag.

• The code that sets the variables must occur after the reference to the s_code.js

file.

• Make certain that the report suite IDs in the s_account variable in the s_code.js

file are set correctly. This variable is typically set correctly when downloading code from the Code Manager for a particular report suite, or as supplied by an Adobe Technical Consultant.

If you want to integrate Analytics with Target, the JavaScript include file must be placed at the bottom of the page.

The following example shows correct placement of the Analytics code:

<html>

<body>

<!-- SiteCatalyst code version: H.20.3.

/* 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="" s.zip="" s.events="" s.products="" s.purchaseID="" s.eVar1="" s.eVar2="" s.eVar3="" s.eVar4="" s.eVar5=""

/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s.t();if(s_code)document.write(s_code)//--></script>

Testing and Validation

</body>

</html>

158

Using s.linkTrackVars and s.linkTrackEvents

The key to a successful link tracking implementation is understanding the s.linkTrackVars and s.linkTrackEvents variables. This lets you pass custom variable values on user actions.

If you are implementing custom link tracking and are setting custom variables and events, make sure that your

s.linkTrackVars variable contains a comma-separated list of all variables that you are passing, including the events variable. Make sure that s.linkTrackEvents includes a comma-separated list of all events that you are passing.

Setting s.linkTrackVars and s.linkTrackEvents does not actually set these variables/events, it only prepares the

Analytics code to do so. You still need to set the variables manually, as shown in the example below:

var s=s_gi('myreportsuite');

s.linkTrackVars="prop1,eVar7,products,events";

s.linkTrackEvents="event5,event9";

s.prop1="Link Click";

s.eVar7="my_page.html";

s.events="event5";

s.tl(true,'o','Custom Link Click');

}

</script>

Notice that events is listed in the s.linkTrackVars variable. The individual events that may be passed are included in the s.linkTrackEvents variable and are also included within s.events later in the function. Each of the variables that are passed are listed in s.linkTrackVars before they are populated later in the function. Also, "event9 has been included in s.linkTrackEvents, but has not been included in s.events. It is not recorded, but could be recorded if the user had chosen to set s.events="event5,event9."

Automatic file download and Exit link tracking work differently. The s.linkTrackVars and s.linkTrackEvents are included in the standard s_code.js

file, and both are set to none. These variables are typically left set to none in the s_code.js

file so that automatic link tracking, unlike custom link tracking, uses the s.linkTrackVars and

s.linkTrackEvents values that you set in the global JavaScript file. They also pass whatever the existing values of those variables are whenever a file download or Exit link is recorded.

Consider the example where s.channel="Home" when the page loads, and where s.linkTrackVars="channel" in your s_code.js

file. If a user clicks to download a file, automatic file download tracking passes data into Analytics, including the value of s.channel that was set on page load. "Home" is passed a second time, leading to inflation in page view data for this value in the Site Sections report.

Adobe strongly recommends leaving the s.linkTrackVars and s.linkTrackEvents set to "none" in the global

JavaScript file and setting them explicitly as necessary with your custom link tracking implementation.

Common Mistakes in the Products Variable

The s.products variable may be the most syntactically complex variable used by data collection.

Commas, semi-colons, pipes, and equals signs all play specific roles in the variable. It has no overall maximum length, but each individual product entry cannot be longer than 100 bytes (including multi-byte characters). Mistakes in implementation of this variable are understandable, but unfortunately for developers, s.products is often a site's most important variable because it makes possible the tracking of revenue, units, product names, and so forth.

Here are a few extremely easy-to-make mistakes that can cause issues on any implementation.

Testing and Validation 159

Make sure that your category, product name, and revenue totals are devoid of commas and semi-colons. The comma is used to separate entries in the s.products string. This happens when you have two products in the same transaction, the semi-colon is used to delimit fields within an entry. If you use a comma or semi-colon in any other way, data collection assumes that you are separating product entries. Consider the following example: s.products="widgets;large widget, 40 x40 ;1;19.99,wugs;tiny wug;2;1,999.98";

In this implementation, the developer probably intended for data collection to read this as shown below:

Category 1: widgets

Product 1: large widget, 40 x40

Units 1: 1

Revenue 1: 19.99

Category 2: wugs

Product 2: tiny wug

Units 2: 2

Revenue 2: 1,999.98

Note the commas in the Product 1 and Revenue 2 entries. These indicate a new product entry. Data collection would interpret the above as:

Category 1: widgets

Product 1: large widget

Category 2: 40'x40'

Product 2: 1

Units 2: 19.99

Category 3: wugs

Product 3: tiny wug

Units 3: 2

Revenue 3: 1

Category 4: 999.98

A mistake like this often results in unexpected numerical values in the Products report, because the units field is recorded as the product name. If you see invalid product names in your Products report, review your s.products variable implementation for misuse of reserved characters, like the comma.

Your product and category names should not contain unsupported characters. This can be especially difficult in the

s.products string, because product names are often likely to contain characters such as

™

, and

. These characters need to be stripped out of the product and category values before they are placed into s.products. You also need to ensure that currency symbols are not included in your revenue values. Supported characters are numbers 1-127 from the ASCII table.

If you are not passing a product category in the product string, make sure to include a semi-colon (;) where the product category is normally displayed, as shown below: s.products=";product name"

Testing and Validation 160

In this case, the semi-colon represents a placeholder for the product category. If the semi-colon is left out of the product string, then "product name" would be counted as the category, the number of units to be counted as the product name, the revenue to be counted as the units, and so on.

Setting the PageType Variable Correctly

The pageType variable is used only to designate a 404 (Page Not Found) error page.

It has only one possible value, which is errorPage.

pageType="errorPage"

On a 404 error page, the pageName variable should not be populated. The pageType variable should be set only on a designated 404 error page. Any page containing content should never have a value in the pageType variable.

For pages containing content, you can set the variable as shown below: pageType=""

It is best to delete the variable completely from pages containing content. This practice is recommended to avoid confusion regarding the purpose of the variable.

Using White Space in Variable Values

In HTML there are several characters that create whitespace.

These include a space, a tab, and a carriage return (or linefeed). Consider the following example:

<head>

<title>

Home Page

</title>

</head>

<body>

s.pageName=document.title

</script>

In this case, document.title populates s.pageName, which should receive a value of "Home Page." Notice the space before "Home Page." Not all browsers interpret this white space in the same way. The result may be either of two examples below: s.pageName="Home Page" s.pageName=" Home Page"

The first value displays correctly, but the second displays white space before the text. Analytics treats these as distinct values for the s.pageName variable. The Analytics interface strips the leading white space from the second value. The result is a report that displays as shown below.

This implementation error causes your variable values to be fragmented across multiple line items. SAINT does not allow leading white space in a key value. This means that it cannot be used to group multiple line items as a

Testing and Validation 161 work-around if this issue is affecting your site. The only way to fix the problem is to pre-process the desired variable value (in this case, the document.title property) to remove any leading (or trailing) white space.

The example above uses the s.pageName variable with the document.title property. Adobe does not recommend using document.title as the page name, nor does this issue only affect the s.pageName variable. Any variable that has leading/trailing white space in its value can be affected.

Using Quotes

When you input values into a variable, there are a few best practices to follow.

You can use single quotes or double quotes, make sure you are consistent. If you are using single quotes, always use single quotes. If you are using double quotes, always use double quotes. Both of the examples below are correct.

s.prop2='test' (single quotes) s.prop2="test" (double quotes)

Make sure that you have smart quotes turned off. If you are using single quotes, and you have an apostrophe in the variable value, JavaScript interprets the apostrophe as a single quote. This means it is the end of the string. Consider the following example: s.pageName='John's Home Page'

In this case, JavaScript would interpret the apostrophe (which is also a single quote) in "John's" to be the end of the string. Since ''s Home Page" has no meaning in JavaScript, it causes an error that prevents the image request from occurring. Either of the following examples would work: s.pageName='John\'s Home Page' s.pageName="John's Home Page"

In the first example, you can escape the apostrophe by inserting a backslash (\) immediately before it. This tells

JavaScript that the apostrophe is not ending the string, but rather is part of it. The string then ends as intended, at the closing single-quote. The second example uses double-quotes around the entire string. In this case, a single-quote cannot indicate the end of the string. The same is true if a double-quote is part of the string. A value of s.pageName="Team Says "We Win!"" would be incorrect because of the use of double-quotes within the string, as well as surrounding it. This would be correct if entered as s.pageName="Team Says \"We Win!\"".

Replacing Your Analytics Code

Adobe offers some best practices for updating your Analytics code.

Frequently, customers use the Adobe Code Manager to replace their code with the most recent version. This practice is good to follow as long as you keep certain things in mind.

Using the Incorrect Data Collection Server ID

Occasionally, generic s_code.js

files that have not been generated from Adobe Code Manager are sent to those implementing the code on your site. As a result, the incorrect data collection server ID (as shown in the s.dc variable) for the account is used. It is best to generate new code directly from the Code Manager for a specific report suite, rather than reusing code from a different report suite. This is the best way to make sure the s.dc variable is populated correctly.

Testing and Validation 162

Plug-ins

Some customers implement plug-ins to enhance their Adobe experience. When you replace your code, do not forget that you have plug-ins as part of that code. The code created in the Code Manager does not have any plug-in code with it, so all plug-ins need to migrate manually to the newer code base. Make a copy of your existing code just in case something happens, and you need to revert to your previous code.

Table of Common Syntax Mistakes

The following table shows the difference between correct and incorrect code mistakes.

Incorrect

prop1 s.evar1

s.pagetype='errorpage'; s.tl(this,o,pageA) s.events='event1'; s.events='event2'; s.pageName="John" (smart quotes on) s.products="shoes,UX4879,1,19.99" s.products=";MacBook Air;1;$1999.99" s.products=";Nikon SB-600 Speedlight Flash for Nikon

Digital SLR Cameras;1;229.9489183" var s_account="rsid1, rsid2" s.events="event1, event2" s.products="product name"

Correct

s.prop1 (uses "s.") s.eVar1 (uses correct capitalization) s.pageType='errorPage'; (uses correct capitalization) s.tl(this,'o','pageA'); (correct usage of single quotes) s.events='event1,event2'; (correct format) s.pageName="John" (smart quotes off) s.products="shoes;UX4879;1;19.99" (uses semicolons, not commas) s.products=";MacBook Air;1;1999.99" (does not use dollar signs) s.products=";Nikon SB-600 Speedlight Flash for Nikon

Digital SLR Cameras;1;229.95" (round or truncate long prices) var s_account="rsid1,rsid2" (no space between report suite IDs when doing multi-suite tagging) s.events="event1,event2" (no space between event IDs when doing multi-event tagging) s.products=";product name" (semicolon used when no product category is listed)

Additional Notes

Keep the closing HTML comment at the very end of the Adobe code (even if you are using the NOSCRIPT part of the script).

Vulnerability Scanner

Whenever users are allowed to input values that are stored in Analytics or any other JavaScript variables, values should be properly escaped or URIEncoded.

We highly recommend using a vulnerability scanning service to avoid injection attacks and other potential exploits that might be present in your code.

Testing and Validation 163

Optimizing your Implementation

Analytics deployment is organized into three major steps.

1. This involves pasting a snippet of HTML code onto each page (or page template) of a website. The HTML code snippet is very small (400 to 1,000 bytes) and contains JavaScript variables and other identifiers that facilitate the data collection process.

2. The code snippet calls a JavaScript library file, which contains JavaScript functions specific to Analytics used during metrics collection. If the Analytics code is implemented correctly, the time required for the browser to execute the JavaScript library file is usually negligible.

3. The library file makes an image request to an Adobe data collection server. The server collects the data being submitted and returns a 1x1 transparent image to the visitor's browser. This third step adds an insignificant increment to the total page download time.

Note: Customers can take additional steps to minimize Analytics overhead.

Page Naming

The pageName variable is used to identify each page that is tracked on the website.

If the pageName variable is not populated with a defined value (such as Home), Analytics uses the URL of the page.

Because the page name is central to your reports, make sure that all parties in your organization agree on a strategy before you implement.

Depending on the content management system your site uses, it is helpful to add content elements to your system that can be used to populate Analytics variables. Many companies find that most Analytics variables can be populated from existing content management elements.

Page Naming Strategies

The pageName variable should be populated with an easy-to-read, intuitive, page identifier.

You can determine the best way of populating the pageName variable by looking at the structure of your website.

The methods listed below outline various ways of populating the pageName variable.

While the pageName variable is central to identifying user behavior, Adobe recommends using multiple variables to indicate page information. The best page naming strategies use a different variable for each level of hierarchy within your site, as shown below:

• The channel variable can be used to indicate the site section.

• The pageName variable can be used to show content type.

• A custom insight variable (prop1) can be used for detailed content.

Levels of detail vary, depending on property, as shown below:

Variable

Channel

Prop1

PageName

Level of Detail

General Section

Sub Section

General Content Description

Example

Electronics

Sports : Local Sports

Loans : Home Mortgage : Rate Comparison

Testing and Validation 164

Variable

Prop2

Level of Detail

Detailed Content Description

Example

Electronics : Notebook PC : Detailed Specs : IBM

Thinkpad T20

The more layered your site, the more variables should be used to identify page content. Companies also find value in allowing for overlap between variables. For example, a more detailed variable may contain information not only about the product being viewed, but also about the site section and sub-section. This is particularly helpful when a product or article appears in more than one section of the site.

The following page naming strategies describe how to populate the pageName variable. While it is tempting to choose the page naming strategy that is easiest to implement, the page naming strategy largely determines the usability of all Path and Page reports. Use good judgment when deciding how pages are named.

Unique Name for Each Page

The most valuable method of naming pages is to give each page a unique identifier that is easily understood by all

Analytics users in your organization. Examples of page names include Home Page, Electronics Department Home, and Sports : Local Sports : High School.

Most Analytics users find that hierarchical page names are useful in both identifying where the page is found on the site and its purpose. The following table shows some sample page names for various industries:

Conversion Media

Home Page

Electronics

Home Page

Technology

Electronics : Notebook PCs Technology : New Gadgets

Electronics : Notebook PCs : Product

Page

Technology : New Gadgets : Article

Page

Finance

Home Page

Home Loans

Home Loans : Rate Compare

Home Loans : Rate Compare : 10

Year Fixed

File Path (Not the Full URL)

For some sites, the file path is clear and easily read. Any business user can read a URL and determine the page to which the file path refers. If this is the case for your site, you can use a server-side variable to populate the path to the file into the pageName variable, as shown below: s.pageName="<%= file_path %>"

Adobe does not recommend leaving the pageName blank, (which results in using the full URL of the page) even though you may be tempted to do so. The following side-effects are caused by leaving the pageName variable blank and using the pageURL as the page identifier.

• The domain and path of a page may not always be displayed identically. For example, the following four URLs return a single page:

• http://www.mysite.com/index.jsp

• http://www.mysite.com

• http://mysite.com/index.jsp

• http://mysite.com/

If the pageName is left blank, each of these page names would occupy a separate entry in reports.

• Some pages (such as forms) post to themselves, thereby erasing any distinction between the original form and the resulting output.

Testing and Validation 165

• When your page is translated into another language by search engines or other online tools, the URL of the page is the URL of the search engine (not the URL of your site).

HTML (document.title)

If you have invested time into making your HTML titles readable and intuitive, you might consider using the same title as the value in the pageName variable. Adobe recommends using a server-side variable to populate the

pageName rather than using JavaScript's document.title

. Some browsers interpret the HTML title differently than others, which may cause Analytics to receive different page names from different browsers.

The best practice for using the HTML title is to copy the existing titles for each page into a separate variable or content management element. When you decide to make changes to the HTML title for search engine optimization or other purposes, the Analytics page names are not affected. If a page name changes in Analytics, it becomes a new page and is not connected with the old page name, regardless of the associated URL.

Variable Length

The length of Analytics variables can impact the size of the HTML code snippet, JavaScript library file, and image request.

If a customer has many variables that are long (60 characters or more) the values can be replaced with shorter identifiers. Data classifications or VISTA rules can be used to translate the identifiers to friendly names.

Note: Most Analytics variables have a maximum of 100 characters (eVars have a maximum of 255). Internet

Explorer allows an overall maximum of 2,048 characters in a GET image request URL. The image request limit applies not only to the variables, but also to information about the browser, operating system, and browser plug-ins (Netscape/Mozilla only).

HTML Code Snippet

Many customers have variables declared, but no value is assigned to the variable.

Removing unused variables helps to reduce the page size.

Javascript Library File

The JavaScript library file is intended to be cached in the user's browser after the initial load, which limits the amount of data that needs to be downloaded.

Page-specific variables should be placed in the HTML snippet. All other variables should be put in the JavaScript library file.

Caching Directives

The JavaScript library file is intended to be cached in the user's browser after the first time the user loads a page.

Adobe customers should ensure that their Web servers are set up to take advantage of this functionality. For example, make sure that the NO-CACHE setting is set to false. Additionally, ensure that the expiration date is sufficiently long.

Make sure any proxy caches are set up with the correct configuration. The customer's Web server documentation provides more information.

Testing and Validation 166

Tables

Many Web browsers do not start displaying the contents of a table until the browser has compiled the entire table.

If the entire contents of the page are inside one big table, the browser must compile the entire contents of the page before anything is displayed.

Placing the call to the JavaScript library file outside table tags ensures that the call to the Analytics servers does not impact the displaying of the page content.

Note: The file should be placed in a legal position for images and must appear between the opening <body> tag and the closing </body> tag.

File Compression

Customers can compress the JavaScript library file by using standards-based encoding (such as gzip).

Typical compression algorithms can reduce the size of the JavaScript file by 40-60% or more.

Note: Not all browsers support all file compression standards or interpret the compressed files in the same manner. Adobe does not guarantee reliable file compression in all environments. Customers should test compression in their supported browsers and configurations before deploying.

Secure Pages

Secure pages (pages loaded under https://) encrypt the image request and add to the total download time.

Secure pages can add as much as 50-75% overhead to the image request. Customers should ensure that https is used only where necessary.

Content Delivery Services/Networks

Content Delivery Services or Content Distribution Networks (CDNs) such as Akamai and Speedera push Web content closer to the edge of the network, keeping frequently-requested documents close to the location where they are accessed.

Typically, this reduces access latency, bandwidth usage, and infrastructure cost.

Your AppMeasurement for JavaScript library file can be delivered via a CDN to enhance performance and delivery of the file to the site visitor. Adobe customers need to ensure they have configured their CDN services correctly.

CDNs are a common reason for fluctuations in download times and should be considered the most probable cause for any changes in download times.

Tag manager stores all JavaScript on a CDN.

JavaScript File Location and Concurrency

Placing the call to the JavaScript library file at the top of the page ensures that the image is among the first elements to be downloaded.

Most Web browsers download images concurrently. Typically three to four images can be downloaded simultaneously.

Testing and Validation 167

Because most Web browsers download elements concurrently, the Status Bar of many common browsers (including

Internet Explorer) does not accurately reflect which element the browser is trying to load. For example, your Status

Bar may report that your browser is waiting for image 1 to download. The network packet tests show your browser has already received image 1 and is currently waiting for image 2.

Note: Because third-party Internet Performance Audit providers (such as Keynote Systems) download page image elements sequentially, not concurrently, they do not mimic the typical user experience.

Peering

Private Network Peering enables data to pass from an ISP's network to the Analytics network more efficiently.

Peering is simply the agreement to interconnect and exchange routing information without the need of the public network. Please contact Adobe Engineering if an ISP is interested in establishing a peering relationship.

Although peering may provide some benefits to Adobe ISP customers, optimizing the HTML snippet and the Web servers caching directives likely have a much greater impact. High-volume ISP customers realize the most benefit from peering.

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 marketing reports & analytics, data warehouse, ad hoc analysis and SearchCenter+)

Adobe offers two types of opt-outs for Adobe Analytics (including marketing reports & analytics, data warehouse, ad hoc analysis and SearchCenter+):

Testing and Validation 168

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

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

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. (Related information: Learn how to set up the

DigitalPulse debugger

.) The collection domain for your website may contain 2o7.net, omtrdc.net or your website domain, such as metrics.example.com or omniture.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://www.d1.sc.omtrdc.net/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

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

Testing and Validation 169

• ko_KR

• zh_CN

• 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

Report to Variable Mapping

The tables below display the report to variable mapping, or the reports and the variables that are used in them.

Conversion Reports

The following table lists the conversion variables that are used to populate each report:

Purchases

Conversions and Averages s.events, s.products, s.purchaseID

Revenue

Orders

Units s.events, s.products, s.purchaseID

s.events, s.products, s.purchaseID

Set s.events to purchase, product detail, order number

Shopping Cart

Conversions and Averages

Cart

Cart Views

Cart Additions

Cart Removals

Checkouts s.events, s.products, s.purchaseID

s.events

Set s.events to scOpen

Set s.events to scView

Set s.events to scAdd

Set s.events to scRemove

Set s.events to scCheckout

Testing and Validation

Custom Events

Custom Event 1

…

Custom Event 100

Products

Conversions and Averages

Products

Cross Sell

Variable to Report Mapping

The table below displays variable to report mapping for the variables used to populate Analytics reports.

Each variable is listed with the reports that use the variable listed next to it.

Variable

s.pageName

Reports Populated

Conversion Reports > Path Reports > Page Value

Conversion Reports > Path Reports > Entry Page

Conversion Reports > Path Reports > Original Entry Pages

Traffic Reports > Site Traffic > Page Views

Traffic Reports > Site Traffic > Hourly Unique Visitors

Traffic Reports > Site Traffic > Daily Unique Visitors

Traffic Reports > Site Traffic > Monthly Unique Visitors

Traffic Reports > Site Traffic > Yearly Unique Visitors

Traffic Reports > Visitor Profile > Pages Viewed by Key Visitors

Traffic Reports > Segmentation > Most Popular Pages

Path Reports > Pages > Page Summary

175

Testing and Validation

Variable

s.server

s.pageType

s.channel

s.prop1 - s.prop20

s.campaign

s.state

s.zip

176

Reports Populated

Path Reports > Pages > Page Value

Path Reports > Pages > Most Popular Pages

Path Reports > Pages > Reloads

Path Reports > Pages > Click to Page

Path Reports > Pages > Time Spent on Page

Path Reports > Entries & Exits > Entry Pages

Path Reports > Entries & Exits > Exit Pages

Path Reports > Entries & Exits > Exit Links

Path Reports > Complete Paths > Full Paths

Path Reports > Complete Paths > Longest Paths

Path Reports > Complete Paths > Path Length

Path Reports > Complete Paths > Time Spent per Visit

Path Reports > Complete Paths > Single-page Visits

Path Reports > Advanced Analysis > Previous Page

Path Reports > Advanced Analysis > Next Page

Path Reports > Advanced Analysis > Previous Page Flow

Path Reports > Advanced Analysis > Next Page Flow

Path Reports > Advanced Analysis > PathFinder

Path Reports > Advanced Analysis > Fall-out

NOTE: In all of the Traffic Reports listed above, with the exception of the

Most Popular Pages Report, if the s.pageName variable is not set, the URL is used.

Traffic Reports > Segmentation > Most Popular Servers

Path Reports > Pages > Pages Not Found

Conversion Reports > Site Path Reports > Site Section

Traffic Reports > Segmentation > Most Popular Site Sections

Traffic Reports > Custom Insight > Custom Insight 1-20

Conversion Reports > Campaigns > Conversion & Averages

Conversion Reports > Campaigns > Tracking Code

Conversion Reports > Visitor Profile > States

Conversion Reports > Visitor Profile > ZIP/ Postal Codes

Testing and Validation

Variable

s.events

s.products

Reports Populated

Conversion Reports > Purchases > Conversion & Averages

Conversion Reports > Purchases > Revenue

Conversion Reports > Purchases > Orders

Conversion Reports > Purchases > Units

Conversion Reports > Shopping Cart > Conversion & Averages

Conversion Reports > Shopping Cart > Carts

Conversion Reports > Shopping Cart > Cart Views

Conversion Reports > Shopping Cart > Cart Additions

Conversion Reports > Shopping Cart > Cart Removals

Conversion Reports > Shopping Cart > Checkouts

Conversion Reports > Custom Events > Custom Event 1-20

Conversion Reports > Products > Conversion & Averages

Conversion Reports > Products > Cross Sell

Conversion Reports > Products > Categories

Conversion Reports > Campaigns > Conversion & Averages

Conversion Reports > Customer Loyalty > Customer Loyalty

Conversion Reports > Sales Cycle > Days Before First Purchase

Conversion Reports > Sales Cycle > Days Since Last Purchase

Conversion Reports > Sales Cycle > Visit Number

Conversion Reports > Sales Cycle > Daily Unique Customers

Conversion Reports > Sales Cycle > Monthly Unique Customers

Conversion Reports > Sales Cycle > Yearly Unique Customers

Conversion Reports > Site Path > Page Value

Conversion Reports > Purchases > Conversion & Averages

Conversion Reports > Purchases > Revenue

Conversion Reports > Purchases > Orders

Conversion Reports > Purchases > Units

Conversion Reports > Shopping Cart > Conversion & Averages

Conversion Reports > Products > Conversion & Averages

Conversion Reports > Products > Cross Sell

Conversion Reports > Products > Categories

177

Testing and Validation

Variable

s.purchaseID

s.eVar1 - s.eVar20

s.linkName

s.hier1 - s.hier5

Reports Populated

Conversion Reports > Campaigns > Conversion & Averages

Conversion Reports > Customer Loyalty > Customer Loyalty

Conversion Reports > Sales Cycle > Days Before First Purchase

Conversion Reports > Sales Cycle > Days Since Last Purchase

Conversion Reports > Sales Cycle > Visit Number

Conversion Reports > Sales Cycle > Daily Unique Customers

Conversion Reports > Sales Cycle > Monthly Unique Customers

Conversion Reports > Sales Cycle > Yearly Unique Customers

Conversion Reports > Site Path > Page Value

Conversion Reports > Purchases > Conversion & Averages

Conversion Reports > Purchases > Revenue

Conversion Reports > Purchases > Orders

Conversion Reports > Purchases > Units

Conversion Reports > Shopping Cart > Conversion & Averages

Conversion Reports > Products > Conversion & Averages

Conversion Reports > Products > Cross Sell

Conversion Reports > Customer Loyalty > Customer Loyalty

Conversion Reports > Sales Cycle > Days Before First Purchase

Conversion Reports > Sales Cycle > Days Since Last Purchase

Conversion Reports > Sales Cycle > Visit Number

Conversion Reports > Sales Cycle > Daily Unique Customers

Conversion Reports > Sales Cycle > Monthly Unique Customers

Conversion Reports > Sales Cycle > Yearly Unique Customers

Conversion Reports > Site Path > Page Value

Conversion Reports > Custom Variables > Customer eVar 1-20

Traffic Reports > Custom Insight > Custom Links

Traffic Reports > Hierarchies > Hierarchy 1-5

178

Implementation Plug-ins 179

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 */

}

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).

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

Implementation Plug-ins 180 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=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

*/ 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 ...

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

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)

Implementation Plug-ins 181

Results

Use Case 2

Scenario s.events="scCheckout,event1"

Code

Results

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) s.prop1="Science,History"

history is not added because History is already in the list.

Implementation

Follow these steps to implement the APL plug-in.

1. Request the plug-in code from ClientCare 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

Implementation Plug-ins 182

Plug-in Information Description

list. 2=case-sensitive check, append only if value isn't in list.

original list, with appended value if added Return Value

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

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

Cookie Combining Utility

Utility that reduces the number of cookies set by Adobe code. Data for all cookies are stored within one session cookie and one persistent cookie.

Implementation Plug-ins 183

detectRIA

A plug-in that determines whether users on your site have Adobe Flash or Microsoft Silverlight installed in their browsers. If so, the plug-in sets the version numbers in Analytics variables.

This plug-in is useful to determine the versions of these applications that should be used in developing rich media content on your site. For example, if 46% of site users only have Flash 9 installed (when the current version is Flash

10), you may consider developing for Flash 9 rather than requiring Flash 10 to use your applications.

Note: The following instructions require you to alter the AppMeasurement for JavaScript 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.

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 capturing RIA data. These should be variables that have been enabled using the Admin Console, but which are 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.detectRIA('s_ria','prop1','prop2','10','2','');

s.detectRIA has six arguments:

1. Name of the cookie that stores values for this plug-in (s_ria above).

2. Variable for use in capturing Flash version information (prop1 above).

3. Variable for use in capturing Silverlight version information (prop2 above).

4. Max Flash version to detect (default, if left blank, is 10; applies to IE only).

5. Max Silverlight version to detect (default, if left blank, is 2; applies to IE only).

6. Flag for detection once per visit. If left blank, the plug-in captures Flash version on every page view. If set to any value, detection occurs only on the first page view of the visit.

Other Examples

/* Does not set version max and uses eVars instead of props */ s.detectRIA('s_ria','eVar6','eVar7','','','');

/* Sets flag to capture version numbers once per visit*/ s.detectRIA('s_ria','prop1','prop2','','','1');

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: detectRIA v0.1 - detect and set Flash, Silverlight versions

*/ s.detectRIA=new Function("cn", "fp", "sp", "mfv", "msv", "sf", ""

+"cn=cn?cn:'s_ria';msv=msv?msv:2;mfv=mfv?mfv:10;var s=this,sv='',fv=-"

+"1,dwi=0,fr='',sr='',w,mt=s.n.mimeTypes,uk=s.c_r(cn),k=s.c_w('s_cc',"

+"'true',0)?'Y':'N';fk=uk.substring(0,uk.indexOf('|'));sk=uk.substrin"

+"g(uk.indexOf('|')+1,uk.length);if(k=='Y'&&s.p_fo('detectRIA')){if(u"

+"k&&!sf){if(fp){s[fp]=fk;}if(sp){s[sp]=sk;}return false;}if(!fk&&fp)"

+"{if(s.pl&&s.pl.length){if(s.pl['Shockwave Flash 2.0'])fv=2;x=s.pl['"

Implementation Plug-ins

+"Shockwave Flash'];if(x){fv=0;z=x.description;if(z)fv=z.substring(16"

+",z.indexOf('.'));}}else if(navigator.plugins&&navigator.plugins.len"

+"gth){x=navigator.plugins['Shockwave Flash'];if(x){fv=0;z=x.descript"

+"ion;if(z)fv=z.substring(16,z.indexOf('.'));}}else if(mt&&mt.length)"

+"{x=mt['application/x-shockwave-flash'];if(x&&x.enabledPlugin)fv=0;}"

+"if(fv<=0)dwi=1;w=s.u.indexOf('Win')!=-1?1:0;if(dwi&&s.isie&&w&&exec"

+"Script){result=false;for(var i=mfv;i>=3&&result!=true;i--){execScri"

+"pt('on error resume next: result = IsObject(CreateObject(\"Shockwav"

+"eFlash.ShockwaveFlash.'+i+'\"))','VBScript');fv=i;}}fr=fv==-1?'flas"

+"h not detected':fv==0?'flash enabled (no version)':'flash '+fv;}if("

+"!sk&&sp&&s.apv>=4.1){var tc='try{x=new ActiveXObject(\"AgControl.A'"

+"+'gControl\");for(var i=msv;i>0;i--){for(var j=9;j>=0;j--){if(x.is'"

+"+'VersionSupported(i+\".\"+j)){sv=i+\".\"+j;break;}}if(sv){break;}'"

+"+'}}catch(e){try{x=navigator.plugins[\"Silverlight Plug-In\"];sv=x'"

+"+'.description.substring(0,x.description.indexOf(\".\")+2);}catch('"

+"+'e){}}';eval(tc);sr=sv==''?'silverlight not detected':'silverlight"

+" '+sv;}if((fr&&fp)||(sr&&sp)){s.c_w(cn,fr+'|'+sr,0);if(fr)s[fp]=fr;"

+"if(sr)s[sp]=sr;}}"); s.p_fo=new Function("n",""

+"var s=this;if(!s.__fo){s.__fo=new Object;}if(!s.__fo[n]){s.__fo[n]="

+"new Object;return 1;}else {return 0;}");

Always test plug-in installations extensively to ensure that data collection is as expected before deploying in a production environment.

184

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

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 */

Implementation Plug-ins 185

// 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.

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.

Note: The following instructions require you to alter the AppMeasurement for JavaScript 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.

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).

Implementation Plug-ins

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.

186

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.

Note: The following instructions require you to alter the AppMeasurement for JavaScript code on your site.

Altering code can affect data collection and should be done only by a developer with experience using and implementing Analytics.

Plug-in Code and Implementation

CONFIG SECTION

No changes required.

Plugin Config

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"

Implementation Plug-ins 187

+"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.

Note: This plugin is intentionally not defined as a method of the s object. Doing so would have added to the calculated page load time.

Plug-in Code and Implementation

Add the function

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();

Implementation Plug-ins 188

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?

Note: The following instructions require you to alter the AppMeasurement for JavaScript 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.

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:

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)

Implementation Plug-ins

*/ 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.

189

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 SAINT to group percentages (such as Less than 25% or Less than 50%) so that you can identify page-viewing trends.

Note: The following instructions require you to alter the AppMeasurement for JavaScript 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.

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.getPercentPageViewed();

Returns

• array[0] contains the previous page identifier

• array[1] contains the total percent viewed

• array[2] contains the percent viewed on initial load

• array[3] contains the total number of vertical pixels viewed

Sample Calls

/* Plugin Example: getPercentPageView v1.4 total percent viewed only*/ s.prop2 = s.getPercentPageViewed();

/* Plugin Example: getPercentPageView v1.4 multiple values*/ var ppvArray = s.getPercentPageViewed(s.pageName); s.prop1 = ppvArray[0] //contains the previous page name s.prop2 = ppvArray[1] //contains the total percent viewed s.prop3 = ppvArray[2] //contains the percent viewed on initial load s.prop4 = ppvArray[3] //contains the total number of vertical pixels

/* To send the hit on an exit link multiple values*/ var url = s.exitLinkHandler() if(url) {

s.linkTrackVars = 'prop1,prop2,prop3,prop4';

var ppvArray = s.getPercentPageViewed(s.pageName);

s.prop1 = ppvArray[0]

Implementation Plug-ins 190

s.prop2 = ppvArray[1]

s.prop3 = ppvArray[2]

s.prop4 = ppvArray[3]

}

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.4

*/ s.handlePPVevents=new Function("",""

+"if(!s.getPPVid)return;var dh=Math.max(Math.max(s.d.body.scrollHeigh"

+"t,s.d.documentElement.scrollHeight),Math.max(s.d.body.offsetHeight,"

+"s.d.documentElement.offsetHeight),Math.max(s.d.body.clientHeight,s."

+"d.documentElement.clientHeight)),vph=s.wd.innerHeight||(s.d.documen"

+"tElement.clientHeight||s.d.body.clientHeight),st=s.wd.pageYOffset||"

+"(s.wd.document.documentElement.scrollTop||s.wd.document.body.scroll"

+"Top),vh=st+vph,pv=Math.min(Math.round(vh/dh*100),100),c=s.c_r('s_pp"

+"v'),a=(c.indexOf(',')>-1)?c.split(',',4):[],id=(a.length>0)?(a[0]):"

+"escape(s.getPPVid),cv=(a.length>1)?parseInt(a[1]):(0),p0=(a.length>"

+"2)?parseInt(a[2]):(pv),cy=(a.length>3)?parseInt(a[3]):(0),cn=(pv>0)"

+"?(id+','+((pv>cv)?pv:cv)+','+p0+','+((vh>cy)?vh:cy)):'';s.c_w('s_pp"

+"v',cn);"); s.getPercentPageViewed=new Function("pid",""

+"pid=pid?pid:'-';var s=this,ist=!s.getPPVid?true:false;if(typeof(s.l"

+"inkType)!='undefined'&&s.linkType!='e')return'';var v=s.c_r('s_ppv'"

+"),a=(v.indexOf(',')>-1)?v.split(',',4):[];if(a.length<4){for(var i="

+"3;i>0;i--){a[i]=(i<a.length)?(a[i-1]):('');}a[0]='';}a[0]=unescape("

+"a[0]);s.getPPVpid=pid;s.c_w('s_ppv',escape(pid));if(ist){s.getPPVid"

+"=(pid)?(pid):(s.pageName?s.pageName:document.location.href);s.c_w('"

+"s_ppv',escape(s.getPPVid));if(s.wd.addEventListener){s.wd.addEventL"

+"istener('load',s.handlePPVevents,false);s.wd.addEventListener('scro"

+"ll',s.handlePPVevents,false);s.wd.addEventListener('resize',s.handl"

+"ePPVevents,false);}else if(s.wd.attachEvent){s.wd.attachEvent('onlo"

+"ad',s.handlePPVevents);s.wd.attachEvent('onscroll',s.handlePPVevent"

+"s);s.wd.attachEvent('onresize',s.handlePPVevents);}}return(pid!='-'"

+")?(a):(a[1]);");

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 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.

Note: The following instructions require you to alter the AppMeasurement for JavaScript 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 Plug-ins 191

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");

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.

Implementation Plug-ins 192

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.

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) 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);

Implementation Plug-ins 193

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.

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

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

Implementation Plug-ins 194

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.

Note: The following instructions require you to alter AppMeasurement for JavaScript code. Altering the code can affect data collection and should be performed by a developer with experience using and implementing

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.

// timeparting config variables s.dstStart="1/1/2008"; // update to the correct Daylight Savings Time start date for the current

year.

s.dstEnd="1/1/2008"; // update to the correct Daylight Savings Time end date for the current year.

s.currentYear="2008"; // update to the current year (can be done programmatically).

Plug-in Config

Place the following code in the s_doPlugins() function, which is located in the s_code.js

file in the Plugin Config section. You can choose three Custom Traffic (s.prop) variables and three Custom Conversion (s.eVar) variables to capture time-parting data. These variables should have been enabled in the Admin Console but are not currently in use. The following is given as an example, and should be updated appropriately based on your needs.

s.prop1=s.getTimeParting('h','-7'); // Set hour s.prop2=s.getTimeParting('d','-7'); // Set day s.prop3=s.getTimeParting('w','-7'); // Set weekday

This plug-in has two arguments:

1. Type of data: h = hour of day, d = day of week, w = weekday/weekend

2. Report suite time zone: Enter the GMT offset for the destination report suite. For example, if your report suite uses U.S. Pacific Time, enter -8 for the second argument. If Eastern European Time, enter +2.

Other Examples

/* Uses GMT time zone and eVars instead of props */ s.eVar7=s.getTimeParting('h','0'); // Set hour

Implementation Plug-ins s.eVar8=s.getTimeParting('d','0'); // Set day s.eVar9=s.getTimeParting('w','0'); // Set weekday

/* Uses GMT +2 time zone */ s.eVar7=s.getTimeParting('h','+2'); // Set hour s.eVar8=s.getTimeParting('d','+2'); // Set day s.eVar9=s.getTimeParting('w','+2'); // Set weekday

PLUGINS SECTION

Add the following code to the PLUGINS SECTION in the s_code.js

file.

* Plugin: getTimeParting 2.0 - Set timeparting values based on time zone

*/ s.getTimeParting=new Function("t","z",""

+"var s=this,cy;dc=new Date('1/1/2000');"

+"if(dc.getDay()!=6||dc.getMonth()!=0){return'Data Not Available'}"

+"else{;z=parseFloat(z);var dsts=new Date(s.dstStart);"

+"var dste=new Date(s.dstEnd);fl=dste;cd=new Date();if(cd>dsts&&cd<fl)"

+"{z=z+1}else{z=z};utc=cd.getTime()+(cd.getTimezoneOffset()*60000);"

+"tz=new Date(utc + (3600000*z));thisy=tz.getFullYear();"

+"var days=['Sunday','Monday','Tuesday','Wednesday','Thursday','Friday',"

+"'Saturday'];if(thisy!=s.currentYear){return'Data Not Available'}else{;"

+"thish=tz.getHours();thismin=tz.getMinutes();thisd=tz.getDay();"

+"var dow=days[thisd];var ap='AM';var dt='Weekday';var mint='00';"

+"if(thismin>30){mint='30'}if(thish>=12){ap='PM';thish=thish-12};"

+"if (thish==0){thish=12};if(thisd==6||thisd==0){dt='Weekend'};"

+"var timestring=thish+':'+mint+ap;if(t=='h'){return timestring}"

+"if(t=='d'){return dow};if(t=='w'){return dt}}};");

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.

• Format for config variables is MM/DD/YYYY.

• s.dstStart is the start day, month and year for Daylight Savings Time.

• s.dstEnd is the end day, month and year for Daylight Savings Time.

• s.CurrentYear is the current year. If not set, will assume year of browser.

• If country has no DST, set dstStart, dstEnd to default (1/1/2009).

• If DST crosses into new year, set dstStart to month, day, year of previous year.

195

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.

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

Implementation Plug-ins 196

• 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.

Implementation

To implement this plug-in, place the following code within your s_code.js

file

* Plugin: getValOnce_v1.1

*/ 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');

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

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

Implementation Plug-ins 197 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();

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

• 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.

Implementation Plug-ins

manageQueryParam

Manages query string parameters by either encoding, swapping, or both encoding and swapping a value. For

SearchCenter use only.

trackTNT

Collects the information for the Target to Analytics integration.

198

Offline Tracking 199

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:

• If trackOffline

is true: hits are stored until measurement is online.

Offline Tracking

Property or Method Description

• If trackOffline

is false: hits are discarded.

Examples:

s.forceOffline(); s.forceOnline();

200

Traffic props and Conversion eVars 201

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.

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.

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.

Using props vs. eVars

Props are non-persistent variables that are used to tie "traffic" data to your custom variable.

Traffic data includes visits, visitors, and page views. eVars, on the other hand, are persistent variables that are used to tie "success" events to your custom variable. Custom events include revenue, orders, leads, bookings, registrations, logins, and so forth. If you want to tie your data to traffic metrics, use a prop. If you want to tie your data to your site's custom success events, use an eVar.

Using props as Counters

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

Traffic props and Conversion eVars 202

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.

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, pre-defined 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:

Correlations

Pathing

Page View

Unique Visitors

Classifications x x x x

Props

Hierarchy

x x x

Traffic props and Conversion eVars 203

What is a Predefined Event?

List of predefined events.

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 any 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 semi-colon. 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. In order to have the maximum flexibility in your reporting, it is best to leave this blank and use Classifications to set up categories.

Traffic props and Conversion eVars 204

Shopping Cart Page (scOpen, scAdd, scRemove)

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

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.

Email Campaign Tracking

Companies can use Analytics to determine the success of an email campaign.

Companies often develop costly email campaigns to market their products. Companies send bulk emails to customers with the expectation that some customers will access the site and a conversion will result. Analytics can report campaign analysis data in several key metrics, including the following:

Metric

Click-throughs

Purchases

Description

Displays the number of click-throughs tracked from the email to the landing page.

Displays the number of purchases resulting from the email.

Traffic props and Conversion eVars 205

Metric

Segmentation by Subcategory

Description

Displays comparison data between different types of users.

Modifications to the HTML email body and the JavaScript library are required to capture the key metrics shown above.

Implementing Email Campaign Tracking

There are several steps to follow in order to successfully display email campaign analysis data in reports.

The steps are listed and described as follows:

1. Create unique tracking codes.

Though each tracking code must be unique, it does not need to be more than a number. The list below shows examples of unique tracking codes.

• Email Opens: 112233A

• Promo Link 1: 112233B

• Promo Link 2: 112233C

2. Add query string parameters to HTML email links.

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 may 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 should be added to the link above:

<a href= "http://www.mycompany.com/index.asp?sc_cid=112233B&sc_v1=SUBCATEGORY">Visit our home page</a>

3. Update the JavaScript library.

Altering AppMeasurement for JavaScript code, s_code.js

, allows you to 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.

1. 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 that 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('sc_cid')

} s.doPlugins=s_doPlugins

Traffic props and Conversion eVars 206

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 and sc_v1 is copied into

eVar1.

Note: Only the first call to getQueryParam is required to capture click-throughs. Contact your Adobe

Implementation engineer to implement this function and to ensure that your version of the JavaScript file contains the getQueryParam plug-in.

2. 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:

• The query string parameters "sc_cid" and "sc_v1" must be visible in the URL on the final landing page, otherwise no click-through conversion are recorded.

• Examples of query string parameters are "sc_cid" and "sc_v1." Any query string parameter can be used and captured by the getQueryParam plugin. 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 and eVar1.

4. Use classifications to classify campaign tracking codes (optional).

The Classifications can be used to convert tracking codes into user-friendly names. It can also be used to summarize the success of each email campaign. The following steps outline the process required to set up an email campaign. For more information, see the

Classifications Guide

5. See pathing by email campaign (optional).

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 will display as shown below: s.prop1="Home Page : Spring Promo Email"

When pathing is enabled for the custom traffic variable, you can use Path reports (Next Page Flow, Fallout, etc.) to see visitor navigation from the landing page.

Tracking External Email

Analytics can report campaign analysis data in several additional key metrics with configurations made by Adobe

ClientCare.

Campaign Type

Emails Sent

Emails Delivered

Emails Opened

Description

Displays the total number of emails sent by the company.

This metric is provided by the email vendor.

Displays the total number of emails delivered to email servers. This metric is provided by the email vendor.

Displays the number of times the visitors opened the email.

Traffic props and Conversion eVars 207

For more information on tracking email campaign analysis data, contact Adobe ClientCare. Tracking email campaign analysis data is considered on a case-by-case basis.

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.

208

Enabling Pathing on a prop

Though pathing reports are available out-of-the-box for pages, pathing can also be enabled for prop variables which are custom traffic variables.

Enabling pathing on a prop can be done in the Admin Console.

You first need to clearly understand the business questions that are being asked. Enabling pathing for a custom prop may be necessary to answer that question.

Below are a few examples of a business question that can be solved by turning on 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?

You are trying to segment your pathing reports by various dimensions (campaigns, user type, and so forth). In the following sections, we provide examples of how to use pathing on props to answer these business questions.

It is important to note that though this data can be achieved by enabling pathing on props and structuring the data in a specific way as outlined below, that the optimal way to segment pathing reports is using Adobe ad hoc analysis.

Ad hoc analysis has been specifically designed to provide 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.

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;

Pathing 209

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”

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 ClientCare 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

ClientCare 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.

Pathing 210

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”

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."

Event Serialization 211

Event Serialization

Event serialization is the process of removing duplicate events on each page view of the site.

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.

This document describes the process to implement Event serialization for conversion and custom events. To use Event serialization, you must first contact Adobe Live Support to have it enabled.

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.

• 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 Description Event Syntax

John

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

User views page for the first time.

event1:1001

User reloads the page (a form submit may fail, and cause the page to reload).

event1:1001 event1:1002 User views page for the first time, enters information correctly, and moves on to next page.

User views page for the first time event1

Event Serialization 212

User Name Description Event Syntax Analytics Total Event1

Count

5 Jamie 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"

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.

• 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. Give the name of the report suite and event name to Adobe Live Support to enable the event.

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.

Event Serialization 213

Purchase Events 214

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 purchaseID s on the other hand are sent to a backend 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, two 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 backend 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. 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.

• 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).

Identifying Unique Visitors 215

Identifying Unique Visitors

Adobe uses a cookie to track unique browsers/devices.

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 Description

s.visitorID

variable

Query string parameter on the image request

This lets you pass the visitor ID to Adobe via the vid query string parameter on a hard-coded image request.

Data Insertion API 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.

URL re-writing and VISTA

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.

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.

Visitor ID Service

The visitor ID service replaces the legacy Analytics visitor ID mechanism, and is required by heartbeat video measurement and future Marketing Cloud integrations.

The visitor ID service provides the following benefits:

• A CNAME for your Analytics server and the associated SSL certificates are no longer required to use first party cookies. The Visitor ID services sets a first party cookie using JavaScript.

• Current visitors are migrated automatically. The visitor ID service checks for an existing s_vi

cookie, and if found, migrates the value to the new visitor ID cookie.

Note: The visitor ID server requires AppMeasurement for JavaScript

, it is not supported by H code and previous.

How does the Visitor ID service identify visitors?

The Visitor ID service uses JavaScript to store a unique visitor ID in an

AMCV_[namespace]

cookie on the domain of the current website. This cookie is set with a 2 year expiration and is refreshed on each visit.

When a customer visits your site, the visitor ID service first checks for an existing

AMCV_[namespace]

visitor ID cookie. If present, the ID from the cookie is used. If the cookie is not present, the visitor ID service makes a request

Identifying Unique Visitors 216 to your data collection server for a unique visitor ID. If the s_vi

cookie (explained below) is present in the image request, that value is returned and used by the visitor ID service so that visitor data is preserved. Otherwise a new unique identifier is generated and returned.

Note that there are no charges for the calls to the data collection server to request a visitor ID.

How does AppMeasurement use the visitor ID service?

When AppMeasurement loads, the visitor ID value is requested from the visitor ID service. AppMeasurement passes this value in the aid

query parameter with each server call. Since the visitor ID service determines the visitor ID and simply passes it to AppMeasurement, the visitor ID service must be included and implemented on each page before your AppMeasurement JavaScript file.You can perform a phased rollout of the Visitor ID service JavaScript, however, the visitor ID service must be enabled on all pages on your site at the same time.

What has changed in the Visitor ID process?

The primary change is that the visitor ID cookie is now set using JavaScript, instead of in the HTTP header that is returned from the data collection web server. To understand this change, the following sections describe how cookies are set using these two methods.

HTTP Header

Cookies are set by a web server by including them in the HTTP response, which is how the s_vi

cookie that is used to identify Analytics visitors is set. After a cookie is set, it is sent with all subsequent HTTP requests to that server.

When a request is sent to the Adobe data collection server, the header is checked for the s_vi

cookie. 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.

However, 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. 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.

JavaScript

JavaScript can read and write cookies on the domain of the current website. The new visitor ID service uses this method to set the

AMCV_[namespace]

cookie, so the domain of the tracking server no longer needs to match the domain of the website in order for the visitor ID cookie to be stored. For most customers this is a preferred way to set the visitor ID cookie since it eliminates the overhead of CNAME records and SSL certificates, which allows customers to migrate away from using CNAME records for data collection servers.

However, there are a few situations where setting the cookie in the HTTP header is beneficial for cross-domain tracking, which is described in the next section.

Identifying Unique Visitors 217

Should I migrate away from CNAME?

If you are tracking visitors on a single domain, there is no advantage to using CNAME in conjunction with the visitor

ID service. Migration is recommended in this case as you no longer need to maintain the SSL certificates required for secure tracking.

If you are tracking visitors across multiple domains, there is an advantage for some customers to maintain a CNAME.

This advantage is due to the way first-party cookies can be used in a third-party context in Apple Safari and some other browsers.

For example, you have a primary site at mymainsite.com

. You configured the following two CNAME records to point to your non-secure and secure data collection servers:

• metrics.mymainsite.com

• smetrics.mymainsite.com

When a user visits mymainsite.com

, the visitor ID cookie is set by the data collection server. This is allowed since the domain of the data collection server matches the domain of the website, and is what is known as using a cookie in a "first-party context", or just a "first-party cookie".

If you are also using these same data collection servers on other sites (for example, myothersiteA.com

, and myothersiteB.com

), if a visitor later visits these sites, the cookie that was set during the visit to mymainsite.com

is sent in the HTTP request to the data collection server (remember that browsers send all cookies for a domain with all HTTP requests to that domain, even if the domain doesn't match the domain of the current website). This is what is known as using a cookie in a "third-party context, or just a "third-party cookie", and it enables the same visitor

ID to be used on these other domains.

Note that this functionality may be seen in all major browsers, even those such as Safari that block third party cookies by default. When a cookie has been used in a first-party context during the visit to mymainsite.com

, Safari continues to use it in a third-party context (during the visit to the other domains). Be aware that if a visitor visits myothersiteA.com

before visiting mymainsite.com

, Safari will block the mymainsite.com

cookie because it hasn't ever been used in a first-party context. As a result, your collection domain should be a domain that people commonly visit in order for a visitor to be identified across domains. If there is no “common” domain to use for the data collection domain, there is no cross-domain benefit to maintaining a CNAME for the data collection domain.

Migrating to the Visitor ID Service

This section contains instructions to migrate an existing Analytics implementation to the visitor ID service. It also contains instructions to optionally migrate from a data collection server CNAME back to omtrdc.net or 2o7.net.

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

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

This process outlines the typical process to deploy the visitor ID service using a separate file.

Step Description Task

Configure the Visitor ID service

VisitorAPI.js

, add the following visitor ID initialization code at the beginning of the file: var visitor = new Visitor("namespace"); // same as s.visitorNamespace

visitor.trackingServer = "INSERT-TRACKING-SERVER-HERE"; // same as s.trackingServer

Identifying Unique Visitors

Step

218

Task Description

visitor.trackingServerSecure =

"INSERT-SECURE-TRACKING-SERVER-HERE"; //same as s.trackingServerSecure

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

============

Distribute

VisitorAPI.js

This file should be deployed to your site and then referenced in the

<head> tag of each page.

VisitorAPI.js

must execute before appMeasurement for JavaScript and other Adobe Marketing Cloud libraries and page code, so place it higher on the page.

Can I add VisitorAPI.js to my AppMeasurement.js file?

Set a custom prop in

AppMeasurement.js

measure coverage

Enable the Visitor ID service in AppMeasurement

AppMeasurement.js

, add the following code to start using the new

Visitor ID service: s.visitor = Visitor.getInstance("INSERT-NAMESPACE-HERE");

This line can be inserted anywhere above the core AppMeasurement code before any tracking calls are made.You might want to include it near the s.visitorNamespace

line since this value must match the namespace set by

Visitor.getInstance()

. (For an example, see

Example Page

Code and Global Configuration

Test the visitor ID service

(Recommended) Add the following to a custom prop in your implementation: s.prop1 = (typeof(Visitor) != "undefined" ? "VisitorAPI

Present" : "VisitorAPI Missing");

You can then view the prop report to see what percentage of your pages are referencing

VisitorAPI.js

. After you have the correct coverage, continue to the next step.

You can verify that the visitor ID service is in use by checking for the aid

parameter using