ADOBE® SITECATALYST® - PJKi

ADOBE® SITECATALYST®

Implementation Training Student Workbook

ADOBE® TRAINING SERVICES

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

ii Adobe® SiteCatalyst® Implementation Training Student Workbook

Adobe® SiteCatalyst® Implementation Training Student Workbook

©1996-2012. Adobe Systems Incorporated. All rights reserved. Adobe, the Adobe logo, Omniture, Adobe SiteCatalyst and other Adobe product names are either regis-tered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

All rights reserved. No part of this work may be reproduced, transcribed, or used in any form or by any means—graphic, photocopying, recording, taping, Web distribu-tion, or information storage and retrieval systems—without the prior and express written permission of the publisher.

Disclaimer

Adobe reserves the right to revise this publication from time to time, changing con-tent without notice.

0212

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

iii

Table of Contents

Introduction ix

SiteCatalyst Implementation ixThe Sitecatalyst Implementation Manual: A Companion Document ixCourse Objectives ixPre-Course Downloads for Implementation xEarn Your Adobe Professional Certification x

SECTION ONE Adobe® SiteCatalyst® Implementation Basics 1-1

Chapter One Adobe® SiteCatalyst® Code 1-3

How Does It Work? 1-4How SiteCatalyst Collects Data 1-4A Few Traffic Metric Definitions 1-6Configuration 1-7SiteCatalyst Code 1-7DigitalPulse Debugger 1-11Packet Analyzers 1-12Exercise 1.1: Reading Image Request Parameters 1-13Setup 1.2: Using Your JJ Esquire Web Site 1-13

Chapter Two

The Adobe® SiteCatalyst® Interface 2-1

SiteCatalyst Reports 2-2Strategic Process 2-5

Chapter Three Key Business Requirements & Solutions Design Reference 3-1

KBRs vs. KPIs 3-2Before You Start Coding 3-2Key Business Requirements & Key Performance Indicators 3-2Focus of the Course 3-3Adobe Fusion Method 3-4Implementation Documents Summary 3-5

SECTION TWO Traffic Variables 4-1

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

iv Adobe® SiteCatalyst® Implementation Training Student Workbook

Exercise for Section Two: Generate Your Own S_code.js File 4-2

Chapter Four Traffic Variables Introduction 4-3Traffic Variable Limitations 4-5

Chapter Five Page Naming 5-1

Laying a Solid Foundation 5-2Key Business Requirements 5-2Naming Strategy: Laying a Solid Foundation 5-2pageName Variable 5-3Page Naming Options 5-5Effective Page Naming 5-7Level of Granularity 5-10Page Naming Strategies 5-13Renaming Pages with the Page Naming Utility 5-16Exercise 5.1: Detailed Page Names 5-17Site Exercise 5.2: Detailed Page Names Practice 5-17

Chapter Six Additional Predefined Traffic Variables 6-1Other Standard Variables 6-2Key Business requirements 6-2The Channel Variable 6-2The Server Variable 6-4The Hierarchy Variable 6-4404 Error Pages (pageType Variable) 6-8Exercise 6.1: Traffic Variable Usage 6-10Site Exercise 6.2: Error Page 6-11Exercise 6.3: Traffic to Content Structure 6-11Site Exercise 6.4: JJ Esquire Pages 6-12

Chapter Seven Custom Traffic Variables 7-1

Using s.props 7-2Key Business Requirements 7-2Understanding the Terms 7-2Two Purposes for Custom Traffic Variables 7-3Site Exercise 7.1: JJ Esquire Pages 7-7Naming Custom Traffic Variables 7-10Custom Traffic Variable Summary 7-10Exercise 7.2: Internal Search Tracking 7-11Site Exercise 7.3: Internal Search Term Tracking 7-12Site Exercise 7.4: Hotel Bookings 7-12Exercise 7.5: Traffic by Membership Type 7-13Site Exercise 7.6: Newsletter Subscription 7-13

Chapter Eight Traffic Variable Features & Functions 8-1

Features and Functions 8-2Traffic Correlations 8-2Optimum Path Engine 8-5Additional Traffic Metrics 8-8Exercise 8.1: Additional Traffic Features 8-9

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Table of Contents v

Exercise 8.2: Analyzing Traffic Flow 8-10Site Exercise 8.3: Internal Search Term Flow 8-11

Traffic Variable Section Review 8-12Putting It All Together 8-12Traffic Variable Summary 8-12Traffic Enhancements Review 8-13Additional Variable Considerations 8-13Review Questions 8-13Traffic Variable Code in Action 8-15

SECTION THREE Conversion Variables 9-1

Chapter Nine Predefined and Custom Events 9-3

Events are Conversion Metrics 9-4Introduction to s.events 9-4Conversion on Your Site 9-5s.events Syntax 9-5Predefined Events (Retail) 9-5Custom Events 9-6Site Exercise 9.1: Custom Events 9-10

Chapter Ten Conversion Variables 10-1

The Purpose of Conversion Variables 10-2The Persistent Variable 10-2

The Product Variable and Events 10-5s.products Syntax 10-5The Category Field 10-5General Use (Non-Purchase) Component 10-6Product Granularity 10-7The Shopping Cart Conversion Funnel 10-9Additional Event Examples 10-10Site Exercise 10.1: The Checkout Process 10-12

Chapter Eleven The Purchase Confirmation Page 11-1

Coding the Purchase 11-2Purchase Component 11-2Multiple Products 11-2Additional Purchase Variables 11-3Event Serialization (Keeping Events Unique) 11-5Visitor Profile Information 11-5Site Exercise 11.1: Multiple Products 11-7Event Incrementor Component 11-8Exercise 11.2: Event Incrementor 11-9Exercise 11.3: Event Incrementor with multiple products 11-9Product String Summary 11-10Products Review 11-10

Chapter Twelve The Campaign Variable 12-1

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

vi Adobe® SiteCatalyst® Implementation Training Student Workbook

It’s All About the Tracking Code 12-2Campaign 101: tracking marketing success 12-2Capturing Tracking Codes 12-3Assigning Conversion Credit Across Visits 12-5Internal vs. External Campaigns 12-7Exercise 12.1: Campaign Tracking 12-7Site Exercise 12.2: Campaign Tracking with getQueryParam 12-8

Chapter Thirteen Custom Conversion Variables 13-1

s.eVars for Custom Tracking 13-2How s.eVars Work 13-2Conversion Variable Use 13-3Internal Search Term 13-4A/B Testing 13-4Three Internal Campaign Tracking Methods 13-4Site Exercise 13.1: Internal Campaign Tracking 13-6Good Navigation Drives Success 13-7Exercise 13.2: JJ Hotel reservation Conversion Tracking 13-8List Variables for Conversion 13-9Cross-Category Merchandising 13-9Merchandising Review 13-12Exercise 13.3: Merchandising Revenue by Channel 13-13Conversion Variables Summary 13-14

Chapter Fourteen Conversion Features and Functions 14-1

Enhance your Analysis 14-2Conversion Breakdowns or “Subrelations” 14-2Additional Conversion Metrics 14-4

Conversion Variable Section Review 14-5Putting It All Together 14-5Conversion Variable Code in Action 14-6Quick Quiz 14.1 14-10Quiz 14.2: A Plethora of Forms 14-10Section Three Review Questions 14-10

SECTION FOUR Enhancements 15-1

Chapter Fifteen Configuration Variables 15-5

Controlling Data Capture 15-6Report Suite IDs (s_account) 15-7Global report suites 15-7Dynamic Account Selection 15-8Character Sets 15-9Multi-Currency Support 15-9Domain Periods 15-12ClickMap Tracking 15-14Track by Subscriber ID with s.mobile 15-15Tracking Links in SiteCatalyst 15-16

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Table of Contents vii

Custom Link Summary 15-20Automatic Variables 15-20SiteCatalyst Variables Summary 15-21Exercise 15.1: Configuration Options 15-22Exercise 15.2: More Configuration Options 15-22Site Exercise 15.3: JJ Esquire charge card application 15-24

Chapter Sixteen Data Manipulation Components 16-1

Client-side and Server-side Data Manipulation 16-2How SiteCatalyst Code Is Read 16-2JavaScript Plug-Ins 16-2Calling Plug-Ins 16-4VISTA 16-8The Tech Perspective 16-11Quick Quiz 16.1: Plug-in Functions 16-11Site Exercise 16.2: Internal Search Term 16-12Site Exercise 16.3: Newsletter Subscriptions 16-12Site Exercise 16.4: Time Parting Plug-in 16-13

Chapter Seventeen Processing Rules 17-1

A Server-side Implementation Solution 17-2Solving Common Implementation Problems 17-2Test Required 17-2Processing Rule Examples 17-3Context Data Variables 17-3Processing Order 17-5Limitations 17-6Values Available to Processing Rules 17-6

Creating Processing Rules 17-8Create a Rule 17-8Conditions 17-8Setting Multiple Conditions 17-9Setting Multiple Actions 17-10Setting Multiple Rules per Report Suite 17-10Rule History 17-11Restoring Rule Sets 17-12Copy Processing Rules 17-12

Common Uses of Processing Rules 17-13Setting a Campaign Tracking Code 17-13Setting a Product View Event 17-13Concatenating Values 17-14Copy an eVar into a Prop 17-14Correct Misspellings 17-15Pull Internal Search from Query String 17-16

Processing Rules Gotchas 17-17Example One: Copying a Page Name into an eVar 17-17Example Two: Fix Campaign with wrong Query Parameter 17-18

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

viii Adobe® SiteCatalyst® Implementation Training Student Workbook

Example Three: Two Sources of Data 17-19

Processing Rules Best Practices 17-21Best Practices 17-21Class Exercise 17.1: Capture a Campaign Tracking Code 17-21Exercise 17.2: Capture Newsletter Subscriptions 17-22Site Exercise 17.3: Coding Context Variables 17-22Exercise 17.4: Using Context Variables 17-22

Chapter Eighteen Mobile Site Tracking 18-1

How Does It Work? 18-2Mobile Site Tracking Considerations 18-3Mobile Report Suite 18-3Anatomy of a SiteCatalyst Mobile Image Request 18-4Web Beacon Placement 18-7Query String Parameters 18-7Site Exercise 18.1: Mobile Site Landing Page 18-9Custom Link Measurement Without JavaScript 18-9Site Exercise 18.2: Mobile Site Charge Card Application 18-10

AppMeasurement Library Option 18-11AppMeasurement Library Code 18-11Server-side Scripts 18-12PHP Page Code Example 18-12Abbreviated Java® Page Code Example 18-13Abbreviated ASP.NET Page Code Example 18-14Important PHP Variables for Mobile Tracking 18-15Site Exercise 18.3: PHP AppMeasurement 18-15Send from Server Variable 18-16Site Exercise 18.4: Enable Send From Server and Debug Tracking 18-18Making It Work 18-18Follow Best Practices 18-19

Chapter Nineteen Light Server Calls 19-1

What is a Light Server Call? 19-2Reasons to Use Them 19-2Limitations 19-2Click-through vs. View-through Tracking 19-3Enabling Light Server Calls 19-4Anatomy of a Light Server Call (Offsite Display Example) 19-4Retrieving Light Server Call Data 19-6Email Light Server Calls 19-6Onsite Display Light Server Calls 19-7

Chapter Twenty Site-based Implementation Considerations 20-1

More Nitty-Gritty Implementation Stuff 20-2Flash Tracking 20-2The ClickMap: Natively Integrated 20-8SiteCatalyst Cookies 101 20-9Regional Data Collection 20-11

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Table of Contents ix

Referrers 20-12Internal URL Filters 20-12Exclude by IP Address 20-12Redirects 20-13Dynamic Variables 20-14Exercise 20.1: Working with Dynamic Variables 20-16

Chapter Twenty-One Data Import and Export Tools 21-1

What are Classifications? 21-2Features of Classifications 21-5

Creating Classifications in the Admin Console 21-9Date Enabled Classifications 21-12

Using SAINT to Upload and Download Classification Data 21-14Steps to Use SAINT 21-14Exercise 22.1: Create Product Classifications 21-26Cleanup Time 21-26Exercise 22.2: Upload Classification Data with SAINT 21-27

Other Data Import Tools 21-28Data Sources 21-28Adobe® Genesis 21-30

Data Export Tools 21-33Data Warehouse 21-33Advanced Segment Insight (ASI) 21-34Data Feed 21-36Adobe Discover 21-37Adobe® Report Builder 21-38Quick Quiz 21.1: Additional Functionality 21-40

Chapter Twenty-Two The Developer Portal and Intro to the SiteCatalyst API 22-1

The Developer Connection 22-2Apps, Plug-ins and Sample Gallery 22-2Adobe Digital Marketing Suite API 22-2Examples of API Use 22-3The API Explorer 22-3Exercise 22.1: Test Calls with the API Explorer 22-7

Chapter Twenty-Three Tag Management 23-1

Using Tag Management 23-2The Tag Management Advantage 23-2Code Processing 23-2Code Environment Stages 23-3Tag Management Usage Steps 23-3Tag Management Summary 23-7

Chapter Twenty-Four Adobe® DigitalPulse™ 24-1

DigitalPulse Configuration 24-2

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

x Adobe® SiteCatalyst® Implementation Training Student Workbook

DigitalPulse Scan Manager 24-2Configure 24-3Masks 24-3Limits 24-4Scheduling 24-4 Forms 24-5

DigitalPulse Reports 24-7Missing Tags Report 24-7Data Errors Report 24-8Tag Location Report 24-8Keyword Distribution Report 24-9Broken Links and JavaScript Errors Reports 24-9Class Exercise 24.1: DigitalPulse Test Scan 24-10

Chapter Twenty-Five Validation and Troubleshooting 25-1

Implementing the Right Way 25-2Deployment Validation 25-3Viewing Reports for Accuracy 25-4Troubleshooting Tools and Considerations 25-6Site Exercise 25.1: Solution Validation 25-13

Chapter Twenty-Six Effective Implementation Practices 26-1

Recommendations and Best Practices 26-2Understanding Terminology 26-2Dos and Don’ts 26-3Asking the Right Questions 26-3Identifying Variable Use 26-4Populating Variable Values 26-5Where to Get Help 26-5Course Summary 26-6Course Wrap-up 26-6

Student Workbook Index Index

Answers to Review Questions Appendix A

Answers to Exercises Appendix BAdobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Introduction xi

Introduction

Adobe® SiteCatalyst® Implementation

Welcome to the Adobe SiteCatalyst Implementation Training Student Workbook. This manual should be used in conjunction with the SiteCatalyst Implementation Training course, not as a standalone training resource. However, after attending a class, returning often to this manual as well as the online training resources will help you become more expert at implementing Adobe SiteCatalyst.

The Sitecatalyst Implementation Manual: A Companion Document This training workbook is not meant to give you information about every last vari-able, implementation option and strategy. Instead, it provides explanations and ex-amples that will best help you best understand how to implement SiteCatalyst code in common situations.

Download and refer to the SiteCatalyst Implementation Manual and manuals on non-JavaScript implementations as companion documents explaining alternate solutions that may be necessary for your site. They are available for download in the SiteCatalyst interface on the Help page.

Course Objectives

• Define your Key Business Requirements (KBRs)• Define your Key Performance Indicators (KPIs)• Map your KPIs to SiteCatalyst variables and metrics• Deploy code• Validate code

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

xii Adobe® SiteCatalyst® Implementation Training Student Workbook

Pre-Course Downloads for Implementation Recommended if coding the hard drive-based JJ Esquire Web site:

• FireFox • Plain text editor (such as Notepad or TextEdit)• Adobe JavaScript Debugger (installed later)

Recommended if coding the web-based JJ Esquire Web site:

• FireFox • FireFTP https://addons.mozilla.org/en-US/firefox/addon/684/) or an FTP client

of your choice• Adobe JavaScript Debugger (installed later)

Optional:

• A Packet Analyzer of your choice such as HTTPFox, WASP, OmniBug, Charles, Fiddler, WireShark or others

Earn Your Adobe Certified Expert ProgramDifferentiate yourself in today’s competitive job market, broaden your employment opportunities by displaying your advanced skills, and put your expertise to the test. You can earn a certification to show your company and industry peers that you are an Adobe Certified Expert in SiteCatalyst Implementation.

This certification is available to the public and to our partners. After you complete this training and implement SiteCatalyst on your own site, you can take the Adobe Certified Professional Implementation exam. This course will assist you in preparing for the ACE: Implementation exam for Adobe SiteCatalyst.

Please visit http://www.omniture.com/education/certification for exam details and registration.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

1-1

Section One

Adobe® SiteCatalyst® Implementation Basics

This first section introduces you to the SiteCatalyst code and shows you how data is collected and sent from the visitor’s Web browser to the SiteCatalyst Data Center. It also briefly explores the SiteCatalyst Interface and how to use the tool. It’s important to be familiar with SiteCatalyst because during the training you will run reports that contain values that you will have coded on the fictitious JJ Esquire Web site.

Last, this section covers Key Business Requirements and how you can translate those into Key Performance Indicators. During the course, you’ll map your Key Performance Indicators to SiteCatalyst variables and metrics. This section should cause you to con-sider the following questions:

• What do the report consumers want me to capture in SiteCatalyst Reports? • Can I justify every piece of data that I capture with a Key Business Requirement

or am I just capturing “interesting” information that may never be used to optimize the Web site?

The chapters in this section are as follows:

Chapter 1: SiteCatalyst CodeChapter 2: The SiteCatalyst InterfaceChapter 3: Key Business Requirements and Solutions Design Reference

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

1-2 Adobe® SiteCatalyst® Implementation Training Student Workbook

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

1-3

Chapter One

Adobe® SiteCatalyst® Code

OverviewChapter One offers a look into how Adobe SiteCatalyst Code works. This chapter in-troduces and defines the three most common Traffic metrics. Finally, you’ll use the JavaScript Debugger to verify that SiteCatalyst Code is executing and correctly send-ing data to the Adobe data center.

Objectives

• Understand how Adobe SiteCatalyst code works• Understand Traffic Metrics• Install the JavaScript Debugger

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


How Does It Work?

Adobe SiteCatalyst is a remotely hosted, subscription-based solution for real- time Web site reporting and analysis. Much more advanced than log file applications that only measure server activity, SiteCatalyst’s next-generation Web analytics captures visitors’ activity directly from their browser. By uncovering the facts about visitor in-teractions with a site, SiteCatalyst users can receive precise answers to unique questions.

SiteCatalyst provides organizations with actionable, real-time intelligence regarding their online strategies and marketing initiatives. It also helps them quickly identify and understand the most profitable paths through their Web sites, where visitors are dropping off, what is driving critical success events, and how various visitor segments interact with the site.

How SiteCatalyst Collects DataEvery page tracked by SiteCatalyst has a small snippet of Adobe-authorized JavaScript. This JavaScript code can be customized for your needs, so that the exact things you want to track end up in your SiteCatalyst reports.

When a visitor to your site launches a Web browser and types in your URL, a request is made to your server (1), your site sends the page code information, and the Web page displays in the browser (2).

sitecatalyst code JavaScript code on

the page and in an include file that sends values that are populated in SiteCatalyst variables to the Adobe data center via an image request

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


As mentioned previously, there is some SiteCatalyst code on the page that executes when the page loads. The following is an example of what the code might look like:

As the page loads and the code on the page executes, it sends an image request (3) to the SiteCatalyst server which returns a transparent pixel image (4). The code collects and sends additional information, included in the image request, to Adobe data cen-ters, such as values for the variables shown above and some automatically collected details (e.g., operating system, browser type, browser height and width, IP address, browser language).

NOTE: Each image request contains a

random number string to prevent browser caching and ensure that subsequent image requests are made by the browser.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The Adobe data centers populate SiteCatalyst Report Suites (5) which populates the SiteCatalyst reports (6) which can then be accessed with a Web browser. This “run” of the SiteCatalyst JavaScript takes place very quickly and does not noticeably affect page load times, even on a dial-up connection. This approach even allows users to count pages that were displayed when a visitor clicked the Reload or Back button to reach a given page, because the JavaScript runs even when the page is pulled out of cache.

Here is an example of what an image request looks like:

Don’t worry about the image request being cached in the browser. A random number precedes the query string in the image request to prevent caching.

A Few Traffic Metric DefinitionsIt might be helpful, right up front, to know a few definitions of Traffic Metrics that your business analysts will see and use in the reports. These are only a few of the met-rics, but many other metrics are built upon them, so it is imperative that they know how these Traffic Metrics work. As you place the code on the page, it may also be helpful for you to understand some basics.

Page View

A page view is just one Web page loading in a visitor’s browser. They saw the page. Simple. Under the hood, a page view is actually one execution of the SiteCatalyst JavaScript for that page. Because of this, Adobe is able to accurately count how many times that page loaded, even if the visitor is refreshing the page over and over. Each page load is a page view. Also, when the visitor hits the Back button in the browser and the page is pulled from cache, the JavaScript still runs and sends the page view to SiteCatalyst.

VisitA visit is just a sequence of page views in one “sitting”. A visit begins when a viewer sees a page on your Web site and ends after 30 minutes of inactivity (in other words, when the visitor hasn’t clicked or typed anything on the site for 30 minutes). A visit can last several hours, as long as the visitor loads at least one page every 30 minutes. A visit is sometimes called a “session,” but it does not necessarily coincide with a “browser session”. This is because a visit ALWAYS ends with the 30-minute time out. That means that if a visitor closes the browser, reopens the browser, and comes to your site five minutes later, it is recognized as a continuation of the same visit (because 30 minutes didn’t pass between page views). This also means that if a visitor stares at one page for 35 minutes, the visit will have closed and processed, and a new visit will start if they click through to another page.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Unique VisitorUnique Visitor reports tell you the number of different people who visit your site during a chosen time period. There are six different Unique Visitors reports in SiteCatalyst: Hourly, Daily, Weekly, Monthly, Quarterly, and Yearly Unique Visitors.

While one person may visit your site any number of times and view any number of pages during a desired time period, the Unique Visitors report records that person as one “unique visitor” so you can tell exactly how many individuals are coming to your site. The key to understanding the Visitor metric is that it is always associated with a time period, because you have to know whether to count a person again or not when they come back to your site. This metric answers the question:How many different people visited my site during...

• this hour?• this day?• this week?• this month?• this quarter?• this year?

Please note that in SiteCatalyst Version 15, Unique Visitors can be requested for any time period even outside of those “bucketed” periods listed above.

When a person visits a site for the first time within the specified time period, he or she is counted as a unique visitor.

ConfigurationThere are six basic steps to configuring SiteCatalyst code on a Web site. This course covers each of the steps in detail. Step 6, the validation step, will be emphasized throughout the other steps.

Step 1: Install the SiteCatalyst codeStep 2: Populate Traffic VariablesStep 3: Populate Conversion VariablesStep 4: Configure any needed plug-insStep 5: Set Configuration VariablesStep 6: Verify that correct variables are being set

SiteCatalyst CodeSiteCatalyst implementation involves adding two components to a site: the SiteCatalyst JavaScript page code and the JavaScript include file. The page-level code contains a few short lines of customizable JavaScript code that should be placed on every page that you want to track. The JavaScript include file (this JS file is commonly named “s_code.js”) contains many global values and the code that ultimately builds and sends the image request. The page-level code calls the Global JS file (or s_code.js) be-fore the page-level variables are read.

NOTE: Visitors to your site cache the Global

JavaScript Include File (s_code.js) after the first request, resulting in virtually no incremental server load for your site.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Page-Level Code (Code to Paste)

<html>

<head>

</head>

<body>



<script language=”JavaScript” type=”text/javascript” src=”http://www.jjesquire.com/

scripts/s_code.js”></script>

<script language=”JavaScript” type=”text/javascript”></script>

<script language=”JavaScript” type=”text/javascript”></script>



...remainder of page code...</body>

</html>

Global JS File (s_code.js)

The Global JavaScript file contains most of the code that the SiteCatalyst page-level code will reference. The following is an abbreviated example of the Global JavaScript file.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


/* SiteCatalyst code version: H.21.


More info available at http://www.omniture.com */

var s_account=”jjesquireprod”

var s=s_gi(s_account)

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

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

s.charSet=”ISO-8859-1”

/* Conversion Config */

s.currencyCode=”USD”

/* Link Tracking Config */

s.trackDownloadLinks=true

s.trackExternalLinks=true

s.trackInlineStats=true

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

s.linkInternalFilters=”javascript:,jjesquire.com”

s.linkLeaveQueryString=false

s.linkTrackVars=”None”

s.linkTrackEvents=”None”

/* 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.visitorNamespace=”jjesquire”

s.trackingServer=”jjesquire.d1.sc.omtrdc.net”

/* Plugin Config */

s.usePlugins=true

function s_doPlugins(s) {

/* getQueryParam v2.0 */

if(!s.campaign)s.campaign=s.getQueryParam(‘cid’)

}

s.doPlugins=s_doPlugins

/*

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

NOTE: For pages that may be loaded either

securely (https:) or insecurely (http:), the reference may be noted as //www.mysite.com/includes/s_code.js, which will use the protocol of the current page. This will avoid the “Do you want to display the insecure elements dialog?” that will otherwise result from loading insecure includes on a secure page. Additionally, Adobe recommends specifying the absolute path to the .js file (e.g., “//www.mysite.com/includes/s_code.js”) instead of specifying the relative path, (e.g., “../../includes/s_code.js”).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


+”rue’:t.substring(i+1);if(p.toLowerCase()==k.toLowerCase())return s.”

+”epa(v)}return ‘’”);

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

var s_code=’’,s_objectID;function s_gi(un,pg,ss){var c=”s._c=’s_c’;s.

wd=window;if(!s.wd.s_c_in){s.wd.s_c_il=new Array;s.wd.s_c_in=0;}s._il=s.wd.s_c_

il;s._in=s.wd.s_c_in;s._il[s._in]=s;s.wd.s_c_in++;s”

+”.an=s_an;s.cls=function(x,c){var i,y=’’;if(!c)c=this.an;for(i=0;i<x.length;i++)

{n=x.substring(i,i+1);

Installing the SiteCatalyst Code

Follow the steps below to install the SiteCatalyst code:

1. Alter the path in the page-level code file on each page to the Global JS file location. Find the following text in the page-level code: “INSERT_DOMAIN_AND_PATH_TO_CODE_HERE,” and replace the text with the domain and path of the location to the Global JS file.

2. Upload the Global JS file. Determine a location on the Web server(s) that is accessible to all site visitors.

3. Customize the page-level code file on each page as directed in the Solutions Design Reference.

4. Insert the modified page-level code file into each page or in a global include file.

Placing the Code

The SiteCatalyst code can be placed anywhere inside the Body tags (<BODY> </BODY>) of a well-formed HTML page. Most browsers do not interpret image re-quests placed inside HEAD tags (<HEAD></HEAD>) correctly, which can cause the code to function erroneously. Adobe recommends placing the code in a global include file at the top of the page (inside the HTML body tag), however the code can be placed anywhere on the page.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


DigitalPulse Debugger• The Adobe DigitalPulse Debugger shows the parameters that are being sent via

an image request. Some of the reasons for using the debugger are listed below:• Allows developers to view data being sent to SiteCatalyst (as well as

Test&Target, Recommendations and Survey).• Proves useful while implementing code.• Can set up as a Favorite/Bookmark in your browser (it will open a window that

shows variables on the current page).• Works on HTTP and HTTPS protocols.• Great even for analysts that need to find the SiteCatalyst page names of pages

on their site (think very large media sites).

DigitalPulse Debugger Automatic install

1. Go to KB ID 534.2. In FireFox or Chrome: Click and hold the green “DigitalPulse Debugger”

button in the KB article, and drag to your bookmarks toolbar, or to the desired location in your Bookmarks menu.

3. In Internet Explorer: Right-click the green “DigitalPulse Debugger” button in the KB article and select “Add to Favorites.” You will be prompted to approve this action because the bookmark contains JavaScript. Choose to accept. You will then need to assign the favorite to a folder or toolbar.

4. If neither work, use the manual install described below.

DigitalPulse Debugger Manual install

1. Create a bookmark in your browser called “DigitalPulse Debugger” or other friend-ly name.2. Change the Bookmark URL in Properties to the Debugger Code. For script, go to: Company>White Papers>JavaScript Debugger(text) on the

JJ Esquire Web site or Knowledge Base Article ID 534.3. Go to Web page and run the DigitalPulse Debugger (click on Bookmark).

DigitalPulse debugger allows you to view data collected from your site on any given page, works for SiteCatalyst, Test&Target, Recommendations and Survey

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Debugger Parameters

The Debugger lists all values at the side of their parameters. Many parameters in the image request are easy to identify such as “pageName.” Others are slightly more cryptic such as “ch” for channel or Site Section and “c1” for Custom Traffic Variable 1 or prop1.

An updated list of parameter definitions is available on the JavaScript Debugger white paper available at Company>White Papers>JavaScript Debugger on your own indi-vidual JJ Esquire Web site.

Packet AnalyzersIn addition to the SiteCatalyst JavaScript Debugger, there are many different third-party packet analyzers that you can use to read image SiteCatalyst image requests. One of the most popular packet analyzers is HTTPFox for FireFox. Other popular packet analyzers, some generic and some specifically made for Web analysts, are Charles, WireShark, HTTPWatch, WASP and Firebug.

For this training, we recommend that you use the SiteCatalyst JavaScript Debugger or HTTPFox. Take note that if you’re using a packet analyzer during the training, quick-ly cut to the SiteCatalyst image request by searching for “/ss/” which stands for “SuperStats”, a former name of Adobe SiteCatalyst. All SiteCatalyst image request URLs contain “/ss/”.

packet analyzer software that can log

traffic over a network, can be used in lieu of the javascript debugger to read data collected by the sitecatalyst code

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 1.1 Reading Image Request Parameters

Estimated Time: 5 minutes

Assignment:

1. Install the SiteCatalyst JavaScript Debugger or a packet analyzer such as HTTPFox (or both).

2. Verify that the Debugger or packet analyzer is functioning properly.

Setup 1.2 Using Your JJ Esquire Web Site


Assignment:

1. View your personal JJ Esquire Web site (familiarize yourself with it)2. If using an FTP account, log in so that you can modify your Web site code3. Log into your SiteCatalyst account and select your Report Suite to start view-

ing reports

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

2-1

Chapter Two

The Adobe® SiteCatalyst® Interface

OverviewIn this chapter, we’ll briefly explore the Adobe SiteCatalyst Interface. During this Implementation Training, you will run reports and become well acquainted with the interface as you validate your code. This chapter will show you some of the options associated with SiteCatalyst reports.

Objectives

• Sign into Adobe SiteCatalyst• Explore the Adobe SiteCatalyst Interface• Understand Data-driven Decision Making in Adobe SiteCatalyst

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


SiteCatalyst Reports

OverviewThe SiteCatalyst interface hosts the data collected from your Web site. As you learn about the SiteCatalyst code throughout this course, you should be able to map the variables to the different reports in SiteCatalyst.

The report organization in SiteCatalyst starts with metric-based reports at the top of the menu, continues with out-of-the-box item-based reports and concludes with cus-tom item-based reports (Custom Traffic and Custom Conversion reports).

There are many reports in SiteCatalyst; far too many to discuss here. However, as a SiteCatalyst implementor, you ought to be familiar with the interface so that you can verify that your code is working correctly and populating the reports with the infor-mation that you intended. This is also helpful so that you can understand questions that you may get from report consumers and analysts.

As you run each report in SiteCatalyst, you will also find information on the left-hand side under the “Knowledge Base” section to help you understand what kind of infor-mation the report is giving you.

Logging in to SiteCatalyst

To log into SiteCatalyst, go to http://my.omniture.com and enter your SiteCatalyst login credentials (Company Name, User Name and Password). From the drop-down menu, select the latest version of SiteCatalyst before logging in.

TiP: In addition to perusing the interface

during training, you can learn more about the SiteCatalyst 14 or 15 Interface by watching the “SiteCatalyst New User Orientation” video available under Help>Training Videos. It’s free!

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Chapter Two The Adobe® SiteCatalyst® Interface 2-3

We will be using SiteCatalyst Version 15 to read most of the reports. The same prin-ciples that we learn from Version 15 apply to Version 14 unless otherwise noted during the training.

Running Reports

Running reports is easy. Select the desired report from the left-hand menu. Metric-based reports are located in the “Site Metrics” folder. All other reports are item-based reports sorted by a metric or calculated metric.

Report Structure

SiteCatalyst reports consist of Report Details and a Graph. In a metric-based report, the Report Details show the metric broken out over a unit of time such as hours or days. In item-based reports (pictured below), the Report Details show the line items of the report (in the example, the line items are products) sorted by a metric (in the ex-ample, products are sorted by Revenue).

The Graph can show a ranked view of the top five values (default) or a trended view of the top five values over a period of time by any applicable metric (for example, trend-ing the top five products by revenue for each day of December).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Each time you run a report, be sure to check out the Configure options that are avail-able. For example, click the “Report” and “Graph” buttons to see what options are available to you. Many options are hidden to keep the interface streamlined. In the Configure section, you can also add metrics, create report breakdowns (called Correlations and Subrelations) and make comparisons between sites.

Change the Report Date using the calendar at the top-right corner. Choose a graph that best displays the data in your report using the graph selector under the calendar. Filter by any value in your line items by using the search field (the advanced filter makes it possible to include or exclude words in your search). The tool bar hosts sev-eral SiteCatalyst features that allow you to download, schedule and bookmark re-ports. Here, you can also create Dashboards, Targets, Alerts, Data Extracts and per-form other actions.

SiteCatalyst Interface Elements

One of the most important elements in the SiteCatalyst interface is the Report Suite se-lector. All of your reports in the left-hand Report Navigation are based on the Report Suite ID that you choose, so make sure it’s the one that you intended. For example, perhaps your Report Suites are organized by country. Image that you work for JJ Esquire Australia and that you need to analyze site conversion for last week. If the Report Suite selected is JJ Esquire Japan, all reports will reflect that data environment. Don’t forget to verify that you’ve chosen the correct Report Suite before running your reports.

At the top of the interface, you should see a short welcome message followed by your name and company name. Moving from left to right across the top of the interface, you should encounter a universal Search/Help field. In this field, you can search the

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Chapter Two The Adobe® SiteCatalyst® Interface 2-5

Knowledge Base and even search for reports in the left-hand Report Navigation (very helpful if you’re still not accustomed to the Report Navigation). The Admin and My Account menus give you options to configure and modify the Report Suite and also make changes to objects that you create in SiteCatalyst (such as Bookmarks, Dashboards, Alerts and Targets). Objects that you create can be found in the drop-down menus on the Publishing Bar (found directly above the Tool Bar on an item-based report as seen in the image below).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Strategic ProcessUsing the data in SiteCatalyst to make positive changes to your site can be broken down into several steps as is shown in the following illustration:

1. Measure: Capture KPIs and other metrics

2. Report: Generate reports on collected data

3. Analyze: Evaluate site performance

4. Optimize: Test and enhance effectiveness (the purpose of gathering this data)

5. Innovate: Experiment with new ideas to drive value

The process shown here should be followed over and over again in order to make posi-tive changes to your site, thus increasing your conversion and reaching your Web site goals. Your job is to make sure that analysts have the reporting data that they need to go through this Web analytics strategic process. If they cannot find the data that they need to make sound analysis, then you may need to do some additional implementation to meet their needs. We’d like you to get it right the first time, so think about what Report Consumers need during this training and as you implement. If you don’t know what they need, schedule a meeting with the Report Consumers in your company to discuss their needs. Review the next chapter on KBRs and KPIs to help you keep them focused on true data needs and not data requests that will never be used to optimize the site.

For more information on this process, contact Adobe Training Services regarding the SiteCatalyst User Training course.

NOTE: Make sure that you know what

Report Consumers need to see in the reports. Don’t skimp when defining the Key Business Requirements of your Report Consumers.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

3-1

Chapter Three

Key Business Requirements & Solutions Design Reference

OverviewThis chapter introduces the concept of Key Business Requirements and Key Performance Indicators. By accurately defining your KBRs and KPIs, your implemen-tation of SiteCatalyst will meet the needs of your Report Consumers. This chapter also introduces the Business Requirement and Solutions Design Reference documents. Use these documents to record the business objectives behind your implementation and SiteCatalyst variable and metric usage (very helpful because you probably won’t remember how you coded the site months from now without this document).

Objectives

• Understand how to derive KPIs from your KBRs• Map KPIs to SiteCatalyst variables• Record variable and metric usage in the Solutions Design Reference

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


KBRs vs. KPIs

Before You Start CodingOne of the most important things you will do during the Implementation Process is work with Report Consumers to define the Key Business Requirements. These KBRs are key objectives for the site. Report Consumers will need to know if these KBRs are being met in order to make accurate and timely site optimization decisions. Before you start coding, make sure that you understand the expectations of your Report Consumers.

Key Business Requirements & Key Performance IndicatorsSo what are KBRs and KPIs? Key Performance Indicators are the measures used to indicate that you are meeting your Key Business Requirements. Other synonyms for KBRs might be business goals or objectives.

KBRs vs. KPIs: Personal Health Example

If your goal is to be healthier, you may wish to define certain requirements that make up this ambiguous goal “to be healthier”. Maybe you want to...

1. Lose weight.2. Lower cholesterol.

These are possible KBRs. You need hard and fast metrics to determine if and when you meet those KBRs. These are the Key Performance Indicators. KPIs in this case would be:

1. Weight in pounds/kilograms/stone (trended over time) 2. Total, HDL and LDL Cholesterol and Triglyceride levels in milligrams per

deciliter of blood (trended over time)

KPIs show if you are meeting those KBRs.

KBRs vs. KPIs: Design Your Ideal Car Example

Let’s suppose that you wish to design your ideal automobile. You want a car that

1. Doesn’t require much gasoline/petrol.2. Easily speeds past other cars.3. Is able to tow a boat.

The requirements above are in fact the Key Business Requirements, but you can re-state them to be a bit more focused so that others can easily understand what you want in an automobile:

key business requirements a kbr is defined as a key objective or site goal

key performance indicators the metrics and measurements that tell report consumers if they are meeting their kbrs or key goalsAdo

be In

terna

l Use

Only

Do Not

Distrib

ute

Chapter Three Key Business Requirements and Solutions Design Reference 3-3

1. Fuel Efficiency2. Speed3. Towing Capacity

At this point, you need to think about the metrics or Key Performance Indicators that can show you if the car of your dreams meets your objectives or Key Business Requirements. From your KBRs, you define the following KPIs:

1. Miles per Gallon / Kilometers per Liter2. Horse Power, Kilowatts, PS or CV @ n RPMs)3. lb. per ft², kg per m² @ n RPMs

Your Key Performance Indicators tell you if you are meeting your goals (fulfilling your Key Business Requirements).

Focus of the CourseBe thinking about what your site goals are and what kind of metrics can best tell you if you’re meeting your objectives. This Implementation Course focuses on Design and Deployment (i.e., mapping your KPIs to SiteCatalyst variables and tagging pages with SiteCatalyst code).

TiP: Be sure to define your KBRs

and KPIs in a thorough Pre-Implementation before designing and deploying code. This course deals with the design and deployment of code and assumes that the Pre-Implementation stage is complete. Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


Your Ideal Implementation is More Than Just Code

The ideal SiteCatalyst Implementation should answer the business questions of your report consumers. Do you know what their questions are? If not, find out before im-plementing. You’ll save yourself a lot of time. Remember the law of Garbage In = Garbage Out. You won’t know what to capture if you don’t know what your report consumers expect.

Ideally, your SiteCatalyst Implementation should be based on Global Standards that you initially set up. Be consistent with names and scripting logic (especially with Page, Site Section, Product and Campaign names).

An ideal SiteCatalyst Implementation should also be scalable. By planning ahead, you can efficiently implement code on your site and stay within the limits of 75 Traffic and 75 Conversion Variables, 20 Custom Events (metrics) and all character limits associ-ated with each variable. What will your needs be next year? How will your implemen-tation need to evolve with your site? Create an implementation that can scale with your site. Always think of the most efficient way to implement using the variables and tools (such as classifications) available to you.

Adobe Fusion MethodWith new customers, Adobe uses an effective implementation process known as “Fusion”. Adobe Fusion incorporates an awareness of a company’s technical needs, Key Business Requirements, and Adobe’s best practices for implementing SiteCatalyst for Web sites in a particular industry.

This course focuses on two phases of the implementation process, namely the Solution Design and the Code Deployment. Involved primarily in these two phases are two specific documents: The Key Business Requirements document and the Solutions Design Reference document. Adobe offers templates for these documents, but there is no obligation to use them. The main purpose of these documents is to ascertain needs from the business owners and to map these needs to SiteCatalyst variables, docu-menting the process along the way. There are some key aspects of the Fusion Method that should be remembered throughout this training:

• Define the steps with inputs and deliverables• Document each step of the process for clarity• Define what is and is not in the project scope• Define roles and responsibilities• Set the expectations of the project time line

Adobe Fusion

Adobe Fusion is the proprietary deployment methodology for all Adobe products. At the core of this methodology is the blending of the customer’s business needs, with Adobe’s industry best practices, and technical deployment expertise.

TiP: Adobe Consulting can help you with

your industry-specific implementation needs through the Adobe Fusion Method.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Chapter Three Key Business Requirements and Solutions Design Reference 3-5

The Adobe Fusion implementation method includes a selection of business optimiza-tion solutions. Each solution begins with Key Business Requirements or questions, recommends Key Performance Indicators and sample reports to visualize results, and Quick-Win actions a company can make to improve business after implementation. Specific deployment instructions guide the site’s team through the implementation process itself and is followed up with a formal Implementation Validation Review. In short, the Adobe Fusion Methodology is designed to enable tangible return on invest-ment (ROI).

Implementation Documents SummaryThere are several documents to help guide you through the implementation process. Some are “owned” and maintained by you, and some are resources to help you along the way.

Your Documents

• A Business Requirements Document is simply information from the business owners in your company that outlines their needs. This class will teach you how to transform these needs into solutions and variables. During this course, the Business Requirements Document is included with the Solutions Design Reference Excel spreadsheet.

• The Solution Design Reference is an Excel spreadsheet that is used to map out and document each variable and function that will be used in the deployment of the SiteCatalyst code. This is either provided to you through the implementa-tion process, or you should create your own. During this course, use the SDR available for download on your own JJ Esquire Web site at Company>White Papers>Solutions Design Reference.

• The SiteCatalyst Data Collection Code is the actual JavaScript code that is placed on your Web site page.

Reference Information

• The SiteCatalyst Implementation Manual is a reference manual for all SiteCatalyst variables and functions.

• Custom materials may be provided by Adobe Consulting to help you get up and going. You then own, maintain and update these materials as your implementa-tion grows and changes over time.

solutions design reference journal of implementation variable and features usage, your future self will thank you for keeping this record

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• The SiteCatalyst Knowledge Base, available in the SiteCatalyst interface, can help you get answers to common questions throughout your SiteCatalyst implementation and use.

The specific implementation steps for a “Configuration” or “Custom” requirement are defined in the Additional Config tab.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

4-1

Section Two

Traffic Variables

This second section introduces you to the SiteCatalyst Traffic Variables and shows you how they behave. You’ll learn about Predefined and Custom Traffic Variables and different ways they can be used to help you track what’s happening on your site. You’ll learn how to tackle the complicated task of naming your pages and site sections. Last, you will learn about additional features and functions that can be enabled on your variables such as correlations and pathing.

Exercises throughout this section are based on your own JJ Esquire Web site. Your instructor will assign you a Web site and FTP credentials so that you can modify the SiteCatalyst code on your JJ Esquire Web site during this training. This will provide you with excellent practical experience.


Chapter 4: Traffic Variables IntroductionChapter 5: Page NamingChapter 6: Additional Predefined Traffic VariablesChapter 7: Custom Traffic VariablesChapter 8: Traffic Variable Features and Functions

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise for Section Two Generate Your Own S_code.js File


Generate file in Admin>Admin Console>Code Manager

1. Code Type: JavaScript2. Report Suite: Choose your assigned Report Suite ID3. Char Encoding: UTF-8 for this Web site4. Currency: USD for this Web site5. Domain Periods: 2 for this Web site6. Don’t select https://

Create s_code.js file

1. Copy code under Core JavaScript File tab2. Paste code into your JJ Esquire s_code.js3. Add Global Report Suite ID “s_account”

Example:

s_account=“mysite,globalsite”

WARNING: Verify that SiteCatalyst code is set

correctly. If you have doubts about the s_code.js file that you’ve generated, contact Adobe ClientCare to get a second opin-ion. This file will determine how data is collected. We’d be happy to help you get it right.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

4-3

Chapter Four

Traffic Variables Introduction

Adobe uses Traffic Variables to collect traffic and pathing data and display it in SiteCatalyst reports. This chapter introduces you to Traffic Variable functions and behavior. Traffic Variables are one of four basic variables used in a SiteCatalyst Implementation. The other variable types are Conversion, Configuration and Automatic variables.

Objectives• Understand predefined Traffic Variable uses• Learn how metrics are applied to Traffic Variables• Learn what Traffic Variables help you know about site activity

IntroductionTraffic variables are the real building blocks of Web analytics. In SiteCatalyst, there are some Predefined Traffic Variables that have specific functions, and there are also Custom Traffic Variables that allow you to measure custom site attributes (your site is different from others and thus you have different tracking needs). Just by having the most basic of code on your site, you can get about 60% of the reports available in SiteCatalyst. However, the remaining 40% of the reports are often considered the most powerful, because they are customized to your needs. These Custom Traffic Variables should be enabled as needed.

Traffic Variables are used to capture traffic and pathing data in SiteCatalyst. They function as counters. They count instances of specific usage on a Web page, e.g., the number of times a user clicks a certain link on a page. Additionally, the Traffic Variables enable you to logically group pages based on a select set of characteristics or conditions to help answer your business questions. Each instance applies only to the page on which the value is set. The available traffic variables are defined as follows:

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Page Name The pageName variable contains the name of each page on your site. It should be populated with a value your Report Consumers will recognize.

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

Site Sections The channel variable is most often used to identify a section of your site. For example, a merchant may have sections like Electronics, Women, or Jewelry. A media site may have sec-tions like News, Sports or Business.

Hierarchies(maximum of 5)

The hierarchy variable is used to determine the location of a page in your site’s hierarchy. This variable is most useful for sites that have many levels in the site structure. For example, a media site may have four levels to the Sports section: Sports, Local Sports, Baseball, Red Sox. If someone visits the Baseball page, then Sports, Local Sports and Baseball will all reflect that visit.

404 Error Page The pageType variable captures the errant URL and refer-ring URL when a 404 Error Page is displayed, which allows SiteCatalyst analysts to quickly find broken links and paths that are no longer valid on the site.

Custom Traffic(maximum of 75)

Custom Traffic (called “Custom Insight Variables” in parts of the interface or “s.props” in the code), are counters that count the number of times each value is sent into SiteCatalyst. For example, property variables can be used to show content type, sub section, or template name. The resultant Custom Insight Reports will show which content type, sub section or template is viewed most often.

Traffic Variable EnhancementsThe following features can be enabled by Adobe Support for most traffic variables:

Pathing While path reports are shown for page names by default, SiteCatalyst offers the ability to enable path reports for other variables. Thus, you can see path reports by site section, sub sec-tion, or detailed content section.

Correlations Correlations are custom report relationships requested by the cli-ent and enabled by Adobe Support. These correlations allow you to break down one traffic report by another.

Classifications Classifications are additional data attributes or properties that are applied to the metric values being collected from your Web site. These additional properties are grouped in metadata reports that will be discussed later on in this training course.

Visits Metric The Visits metric may be enabled for most traffic reports as a column within the report, in addition to the standard SiteCatalyst Visits report.

Unique Visitors Metrics

SiteCatalyst also offers daily, weekly, monthly, and quarterly unique visitors metrics as additional columns within most traffic reports.

NOTE: In the SiteCatalyst code,

Custom Traffic or Custom Insight variables appear as “s.props.”

NOTE: Adobe engineering must be notified so they

can ensure that there is the appropriate amount of hardware to support the Variable Enhancement. Adobe can take up to 48 hours to get the hardware in place prior to the feature being enabled.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Chapter Four Traffic Variables Introduction 4-5

Traffic Goals and ObjectivesTraffic Reports help you know:

• How often people are coming to your site• How they are getting there• What technologies they are using• Traffic answers about your custom visitor segments

Why would you want to see these reports?

• See if content updates drive frequent return visits• See if site partners and SEM/SEO help us acquire more visitors• Design a better site to accommodate various browsers• Tailor your site to important visitor segments• Monitor page view and visitor trends in order to plan resources (such as adding

servers)

Traffic Variable LimitationsMany variables have additional limitations or syntax requirements. These limitations are defined below:

• Values limited to alphanumeric characters (no HTML tags, special chars or symbols)

• Only use characters 0-127 of the ASCII table (do not use ASCII codes above 127 unless multi-byte character support is enabled on your Report Suite and the s.charSet is populated appropriately)

• Non-persistent (scope is one page)• 100 bytes max (not necessarily 100 characters)• All variables are case sensitive (i.e., “Home” is a different record than “home”)

NOTE: A JavaScript function can be used

to ensure all values are lowercase.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Traffic Variables answer traffic questions. For example:

1. How many visits did we get in our Jewelry site section? 2. Which pages do 40- to 44-year-old visitors look at?3. From which city did we get the most visitors?

You’ll soon be coding your own JJ Esquire site and putting the knowledge you gain from this section into practice. As you do so, don’t hesitate to take notes in the mar-gins of this workbook about things that you should track on your own Web site.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

5-1

Chapter Five

Page Naming

OverviewPage Names are the foundation of your implementation. Imagine opening up the SiteCatalyst Pages report and seeing a list of URLs or nonsensical page names. It can frustrate any Web analyst. Use the concepts in this chapter to make reports that in-volve page names as easy to understand as is possible within the context and size of your site.

Objectives

• Learn the Five “C”s of effective page names• Learn how metrics are applied to Traffic Variables• Understand Page Name variable limitations

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Laying a Solid Foundation

The page is the most important unit of measurement on the Web site. Several metrics are based on page data (e.g., pathing metrics). Additionally, many reports display data from the page name. Therefore, deploying a page naming strategy that is helpful to the SiteCatalyst user most often requires forethought and planning. A good page naming strategy will enable your Report Consumers to maximize their use of SiteCatalyst reports.

Key Business RequirementsHere are some of the common business questions and objectives that can be answered though proper use of the s.pageName variable:

• Obtain accurate page view data for baseline metrics• Understand granular page flow to minimize fall-out rate• Increase understanding of visitor behavior throughout Web site• Acquire detailed traffic statistics on Web site

Naming Strategy: Laying a Solid FoundationWithout question, your page naming convention is the most important element you can define in your implementation because so many reports in SiteCatalyst are de-rived from the page name. The important aspect of page naming is determining at what level you need to understand exactly what your visitors are doing and how they are interacting with your site.

The time and effort you initially spend in developing a page naming strategy is a worthwhile investment. Page names impact many other forms of analysis, such as pathing and data correlations. Well-planned page names ensure cleaner, more accu-rate data as well as enhanced and accelerated user-adoption of SiteCatalyst through-out your organization.

s.pageName captures page name, populates the pages report, defaults to URL if not populated, case sensitive, limited to 100 bytes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


pageName VariableSiteCatalyst tracks page names through the s.pageName variable, which is a part of the standard SiteCatalyst code on each Web page. For example, Omniture’s home page has the s.pageName variable set to “Omniture: Homepage”. This is set on every page to identify that page in SiteCatalyst reports.

Page Name Variable goals:

• Show which pages are getting the most traffic• Show which pages are not being properly utilized• Show how people path (move) between pages

Syntaxs.pageName=“page name”

Examples.pageName=“Home Page”

The example above and most examples throughout this workbook employ double quotes in the JavaScript; however, using single quotes, such as in s.pageName=‘Home Page’, is also valid. Just be consistent (always use double quotes or always use single quotes).

Page Naming Examples

Good page names are easy for analysts to understand. Poor page names can frustrate your Report Consumers and decrease the adoption rate of SiteCatalyst. Good page names are clear and user-friendly, concise, easy to filter and search (avoid characters such as “|” in page names) and have a consistent format.

NOTE: Traffic Variables such as

“s.pageName” are case-sensitive and sensitive to diacritical marks such as accents, umlauts and tildes.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Bad page names are unclear and confusing to Report Consumers. They are generally too long (URLs), awkward to filter or search and inconsistent in format. In brief, very frustrating for Report Consumers.

Good Page Naming Bad Page Namingvs.

Clear and user-friendly More concise Easy to filter and search Consistent format

Unclear and confusing Too long (URLs) Awkward to filter and search Inconsistent format

PageName Considerations

Remember the following when working with the pageName variable:

• The pageName variable is case-sensitive, for example: “Home Page” and “home page” are seen as two different pages.

• Sensitive to diacritical markings (e.g., å, à, ç, é, ê, ñ, ø, š, ü). For example, “L’Oréal cosmetics” and “L’Oreal cosmetics” are two different pages. If it’s not possible to be consistent with diacritics, consider not using them.

• Don’t break page name with illegal characters, for example s.pageName=“Samsung 55” LCD TV” will fail (quotes, short for inches in some countries, close the statement prematurely causing the entire image request to fail). Single quotes can cause similar trouble if you’re not careful. For example, s.pageName=‘L’Oréal cosmetics’ with single quotes will fail (apostrophe recog-nized as single quote will prematurely close statement causing the entire image request to fail).

• Page names are limited to 100 bytes.• 100 bytes do not always equal 100 characters. For example, “e” typed 100 times

equals 100 bytes (“e” stored as one byte); however, “é” typed 50 times also equals 100 bytes (“é” stored as two bytes in SiteCatalyst). Other characters with diacritics, Cyrillic characters, Asian characters and other character sets vary between 1 and 4 bytes.

• Only the first 20 to 30 characters of the page name are displayed in most SiteCatalyst graphs or Path reports.

• If a page name changes, historical data cannot be easily re-assigned to the new name. In order to facilitate the measurement of page-related trends over time, it is important to maintain consistent page names in s.pageName.

NOTE: Only the first 20 to 30 characters of

the page name are displayed in most SiteCatalyst graphs or pathing charts.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Page Naming OptionsThe following sections contain the various SiteCatalyst page naming options.

Recommended Options

Server-side

Use server-side logic to populate page name for each Web page.

• Server-side logic can be used to set the s.pageName variable.• Enables you to automate the page naming process and control the schema for

friendly page names.

The following limitations may exist when using server-side logic to populate the page name:

• Only applies to dynamic pages, not static HTML pages.• Flexibility in page naming will depend on your platform.• Requires some ongoing diligence to ensure that the page naming logic doesn’t

break based on changes to the URL structure or new content additions.

Hard-coded

Manually set page name on each Web page.

• Page names can be manually hard-coded into each Web page in the s.pageName variable.

• Allows you to create a friendly page name that isn’t restricted to what’s found in the URL or title tag.

The following limitations may exist when hard-coding the page name:

• Labor-intensive for IT team to implement and maintain if there is a significant number of static HTML pages.

• Dynamic pages (ASP, JSP, CFM, etc.) cannot be hard-coded.• Development team must be careful if using existing pages as boilerplates;

otherwise multiple pages can inadvertently share the same page name.

“Use With Caution” Options

The pageName Plug-in

Adobe Consulting has developed a JavaScript plug-in that strips “http://www.domain.com/” from URL page names. This plug-in shortens the page names and makes them a little more manageable for users. They may be suitable for Web sites with well-de-fined URL structures.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The following limitations may exist when using the pageName plug-in:

• Even though the domain has been stripped from the page names, using URLs for page naming can still lead to long page names (page name is truncated at 100 bytes).

• Will treat different URL variations of the same Web page as separate pages (e.g., http://www.jjesquire.com/index.html and http://www.jjesquire.com/home.html).

• Will aggregate dynamic pages under the same page name because it ignores the query string (e.g., ../storypage.html?storyid=123, and ../storypage.html?storyid=456).

“Not Recommended” Options

Document.title

Uses the title of each page instead of URL.

• s.pageName can be set to each Web page’s TITLE tag; e.g., s.pageName=document.title;

The following limitations may exist when using document.title:

• Page titles aren’t always unique to one page.

• Page titles can contain leading white space which may be interpreted differently by different browsers. Potential to create two page name records from one title (e.g., <title> JJ Esquire|Home|</title>).

• Page titles can be long and contain unnecessary information such as the company’s name.

• SEO initiatives can pack page titles with unnecessary keywords and cause the page titles to change on a regular basis for optimization purposes.

• Translation tools such as Babel Fish can translate the TITLE tag and create other instances of the Web page under different translated names.

Leave Blank

SiteCatalyst defaults to page URL. If the pageName variable is left blank, the page URL will be entered into s.pageName (excluding any query strings).

The following limitations may exist when leaving the s.pageName variable blank:

• URL page names can be very long and unwieldy for users. • Valuable real estate at the beginning of each page name is unnecessarily wasted

on “http://www.domain.com...” (can be difficult to read some graphical SiteCatalyst reports such as the Path reports).

• Different URL variations of a particular Web page will be treated as separate pages instead of aggregated together (e.g., http://www.jjesquire.com/index.html

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


and http://jjesquire.com are both the home page, but will be listed as separate pages).

• Dynamic pages are aggregated under the same page name because query strings are normally excluded (e.g., http://www.jjesquire.com/productpage.php?prodid=123 and http://www.jjesquire.com/productpage.php?prodid=456 are aggregated).

Effective Page Naming

Disadvantages of Using URLs

By default, Adobe displays the page URL in SiteCatalyst reports. URLs are used for Web operation, not Web analytics. Using URLs in Web analytics reports is disadvan-tageous to users who are not familiar with the URL names; they may get confused when they view the reports. For this reason, Adobe makes it possible to apply “friend-ly names” to replace the URLs in the SiteCatalyst reports.

Friendly Page Names

There are five key aspects of effective page naming:

As illustrated above, your page naming strategy must balance the five seemingly dis-parate requirements.

Contextual Context focuses on the URL structure stem, which helps to identify where a page resides. Include directory structure or content hierar-chy in the page name to help users orient the page within the site and simplify report filtering.

Clear Clarity is an overarching concern for the entire page name. Ensure that it is clear and easily identifiable for infrequent users.

Concise Conciseness primarily focuses on making the URL structure stem as short as possible. The specific page name part should also be as concise as possible, but most of the emphasis will be on the stem. Keep the page name as short as possible to maximize limited char-acter space.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Clean Avoid tagging issues which can fragment a single page into mul-tiple variations.

Consistent Maintain a uniform structure across different sections of the site and over time as well.

Structure of a Friendly Page Name

Friendly Page Name Example

1. E-commerce: women:activewear:fur trim ski jacket

• Contextual: Page name includes merchandising category and subcategory.• Clear: Page name identifies the page as the main entry page for this product

group and doesn’t include unnecessary code elements (.aspx, .jsp, .cfm, etc.).• Concise: Instead of using category’s full name, “JJ Esquire Women,” it has been

abbreviated to just “women.” You can only abbreviate directories and subdirec-tories so far before they compromise the Clear rule.

• Clean: A JavaScript function is used to make sure that all of the values going into the reports are in lower case, thus avoiding duplicate values for the same page. (Mixed case is acceptable as long as it’s consistent.)

• Consistent: Processes are put in place (agreed upon and distributed) so that the format of the page naming is the same across all departments, even though the pages are created and managed by different groups.Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


Benefits of Friendly Page Names

The follow list shows some of the common benefits of implementing user-friendly page names:

• Simplifies page analysis and promotes faster adoption of SiteCatalyst reports by business users.

• Focuses on site flow/user experience rather than site operations.• Allows for easier searching and filtering of page reports.• Reduces the impact of URL changes to the page reports.• Enables you to consolidate multiple instances of a single page.• Provides better visibility of pages in the path and fall-out reports.• Facilitates pathing by properties or segments, which requires the concatenation

of the page name with a custom insight variable.• Reduces the number of unique page names.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Level of GranularityEach company needs to determine the page naming granularity required for its site’s low-level pages. Depending on the quantity of low-level pages or specific business needs, a company can choose to aggregate or maintain unique page names. If a Web site exceeds 500,000+ unique pages, response times for page reports in the interface will begin to degrade. To prevent this degradation, Adobe recommends aggregating the pages to ensure that your pages do not exceed the 500,000 limit.

Page data for very large sites can always be accessed through Data Warehouse reports by placing the detailed page name into another variable that does not show in the in-terface, but is sent directly to Data Warehouse.

Traffic metrics are always recorded, but fall under separate line items listed as “Unspecified” for page names not in the first 500,000 page recorded during the month (Version 15). All page names are always available in Data Warehouse.

Examples: Product Details Pages

Here are two ways you could name product detail pages:

1. Aggregate

Product DetailsTools:Screwdrivers:Product Details

• Product ID or product name is not included in the page name.• Product name is passed into SiteCatalyst via the s.products variable and the

prodView event is executed (conversion reports — no pathing).• Allows Path Analysis for aggregate page names

NOTE: SiteCatalyst variables can record

up to 500,000 unique values per month. Once the 500,000 unique value limit is reached, all metrics associated with new values are associated with a line item called “Uniques Exceeded”. All unique values are recorded in their entirety in Data Warehouse.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Reduces page name uniques.

2. Keep Unique

Product DetailsCraftsman:18 pc Screwdriver Set

• Product name included in page name.• No flow within page name — one product page regardless of how page is

generated.• Allows path analysis for specific product pages.• Increases page name uniques.

Article Pages

• Most content sites need visibility into specific article pages, so page names must be unique.

• Many media companies find it beneficial to include the content hierarchy in the page name.

• Some content sites cannot do this because one article can reside in multiple content sections.

• For usability purposes, it is also helpful to include an abbreviated article title.• Full article title, date, and article ID can be placed into prop variables and

correlated with the page name.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


If s.pageName is the Abbreviated Article Title, then

s.pageName=“World News:Wonderful World:Australian Cat

Odyssey”

If s.prop1 is the Date, s.prop2 is the Article ID, and s.prop3 is the Full Article Title (the detailed page name), then

s.prop1=“20090916”

s.prop2=“2344581”

s.prop3=“Australian Cat Strays 2,400 miles, returns home”

Alternate Detailed Page Names

If you have over 500,000 page names, it may make sense to consolidate all of your Product Detail pages into one Page Name and detail those page names in a separate s.prop or Custom Traffic Report. The page name strategy should ensure that your page name is detailed, but not so granular that it becomes cumbersome. By setting a different, more-detailed level of granularity in a Custom Traffic Variable, we create a new report dedicated to product pages. This reduces the number of unique page names for s.pageName. If you wish to path by product pages and you use this type of implementation, be sure to enable pathing for s.prop1.

If s.pageName is the generic page name, then

s.pageName=“Product Detail”

If s.prop1 is the detailed page name, then

s.prop1=“Product:Fur Trim Jacket”

You can specify a friendly name for Custom Traffic Reports in the Admin Console. Go to Admin>Report Suites>Edit Settings>Traffic>Traffic Variables.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Selecting the Appropriate Detail Level

Pages exist at levels of detail. Most sites are dynamic in that the pages are created from global and section templates. The level of detail depends on the granularity of what your business users need to know.

The best page naming strategies utilize a different variable for each level of hierarchy within your site. For example, the channel variable can be used to indicate the site section, the s.pageName variable to show content type, and a custom insight variable for detailed content. The following questions may help you to properly define your page names:

• What site was the user on?• What template served the site content?• In which process was the user involved?• What content did the user see? (if the data is too detailed, but necessary to

record, move it into a separate variable)• What event happened next? (pathing)• What conditions existed within a specific state of the page? (page errors,

alternate versions of the page)

On the fictitious JJ Esquire site, we recommend setting the Page Hierarchy into the page name.

s.pageName=“Women:Activewear:Fur Trim Ski Jacket”

Your implementation consultant may recommend a different page naming conven-tion based on your unique site needs and site constraints.

Page Naming StrategiesA good page naming strategy will enable you to maximize your user’s SiteCatalyst experience. The following practices will help you to create the best page naming strat-egy for your organization:

• Gather all requirements from all business users of reports.

• Create corporate standards.• Include appropriate detail levels.• Target no more than 500,000 unique page names.• Use other variables for details.• Never include visitor-related details in page name.• URLs make the site operate — avoid using as page names if possible.• Consider how page naming strategy affects all reports, including paths and

ClickMap.• When naming pages, consider how they’ll appear in the global report suite.• Document title information is for search engines and use for page names is

strongly discouraged.• Multiple levels are supported.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Pathing By Page Name

Your Page Naming strategy will affect the look and function of your Path reports. For example, the following Next Page Flow report shows hierarchical-type page names.

The following Path report shows aggregate page names. This method consolidates some pages by type such as product pages. In the report below, the analyst can quickly estimate conversion rates, on a certain path, between such buying steps as viewing a product, selecting a size and adding the item to the cart.

Multi-suite Environment

When you use multi-suite tagging or even rollup functionality to create a Global Report Suite, you need to create a page naming strategy that works within a global report suite. Within a multi-suite environment, Adobe recommends that you add a brand and/or region identifier to each page name. This identifier will be most impor-tant in the global report suite because without it users will not be able to discern which pages belong to which Web sites. In order to keep page names concise, you may want to consider using recognizable acronyms for each regional or brand-specific site:

TIP: If you have a Multi-

Suite Environment, be conscientious of how variable values will appear in the Global Report Suite, not just the local Report Suite.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


“US:Home page”, “UK:Home page”, “FR:Home page”

“JJ Clothiers:Home page”, “JJ Travel:Home page”, “JJ

Finance:Home page”

International Sites

The 100-character limit for page names in SiteCatalyst is for languages that rely on single-byte characters (English, French, German, Spanish and others without the use of diacritical marks). Asian languages such as Japanese or Korean rely on multi-byte character sets, which require more space. Depending on the character set — double-byte vs. multi-byte — the page name length limitations in SiteCatalyst can be much tighter and can vary by Asian language.

ClickMap (v14) and the s.pageName Variable

The granularity level chosen for page names will impact ClickMap analysis. ClickMap depends on the s.pageName variable for page link measurement. It will default to the URL to define a page link when the s.pageName variable is not populated. You need to ensure that your chosen granularity level will support the needs of your ClickMap us-ers. Ask yourself if aggregating low-level pages enhances or undermines your page link analysis.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Renaming Pages with the Page Naming UtilityThe purpose of the Name Pages utility is to change page names as they appear in SiteCatalyst, rather than the value of the s.pageName variable. Access this tool in Admin>Name Pages. This name serves as a label over the URL or page name set in the s.pageName variable on the page.

• Ideally, pages should be renamed in s.pageName (in the code)• Administrators can rename pages within the SiteCatalyst interface• Acts as label over page name or URL• You can restore a page to its original name (value captured in s.pageName)• You cannot see what the previous rename value was (only original value)• Cannot combine multiple pages by renaming • Example: two pages that you name “Home” cannot be combined

When using the Page Naming Utility, page names can be reset as needed. Of course, the best practice is to do the best implementation that you can and get it right the first time. This tool can make life a little confusing for analysts that use the debugger and see a different page name being sent from the page than appears in the reports. When you change a page name, think about putting a note in the notes section at the foot of the “Pages” report in SiteCatalyst or possibly keeping an external log.

Additional Considerations

Remember that the s.pageName variable creates a unique record. This means that the URL can change, but the page name remains the same as long as you continue to populate s.pageName with the same friendly name.

For example, let’s suppose that there are multiple URLs leading to the same HTML page, as in the following examples:

• http://jjesquire.com/index.html• http://www.jjesquire.com

If you always populate s.pageName with a friendly name, such as “Home Page”, all instances of the page will fall under “Home Page” in SiteCatalyst reports regardless of the URL. If you fail to populate s.pageName, SiteCatalyst will default to the URL and that would result in two different page names since there are at least two different URLs for the Home Page.

WARNiNG: If you wish to modify the page

name, changing the name in s.pageName will create a new page record. For example, if your wish to rename “Homepage” to “Home Page”, doing so in the code creates a new record with no historical link between the two pages. The page naming util-ity allows you to give the page a new name that appears in the interface (“Home Page”). The page name in the s.pageName code (“Homepage”) should not be changed.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 5.1 Detailed Page Names


Key Business Requirements

• Understand page traffic on Web site• Understand worldwide page use across multiple sites• Ability to filter Page Names by location (hierarchical site structure)

Key Performance Indicators

• Page Views, Visits and Unique Visitors for Page Names with prepended Report Suite ID

• Page Views, Visits and Unique Visitors for Hierarchy Levels

Assignment:

Write the Page Name code for the following pages:

1. The JJ Esquire Home Page on the Germany site2. The Women’s Fur Trim Ski Jacket in Activewear on the JJ Esquire United

States site.3. The Men’s Tuxedo page in Fine Apparel on the JJ Esquire France site.4. The Men’s Tuxedo page in Fine Apparel on the JJ Esquire UK site.

Example (No. 4): s.pageName=“UK:Men:Fine Apparel:Tuxedo”

Solution

1. ________________________________________________________________

2. ________________________________________________________________

3. ________________________________________________________________

4. ________________________________________________________________

Site Exercise 5.2 Detailed Page Names Practice


Assignment:

On your own JJ Esquire Web site, code Page Name based off of the site structure using a colon delimiter. Validate that the code was passed in appropriately.

1. The JJ Esquire Home Page2. The Sequin Dress in Women’s Fine Apparel3. The Hooded Sweater in Men’s Activewear

Note: To differentiate page names on your site from those of other students, prepend a global value such as your initials; e.g., s.pageName=”JG:Men:Fine Apparel:Tuxedo”

s.pageName =“UK:Men:Fine Apparel:Tuxedo”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

6-1

Chapter Six

Additional Predefined Traffic Variables

OverviewIn this chapter, we’ll cover the other predefined Traffic Variables that are available besides s.pageName. These variables, except for the hierarchy and error page variable, function just like s.pageName and have the same limitations.

Objectives

• Understand the purpose of additional predefined Traffic Variables• Understand coding best practices• Learn about variable limitations

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Other Standard Variables

In addition to the s.pageName variable, SiteCatalyst offers several other traffic vari-ables to help you collect and segment Web analysis data from your site.

Key Business requirementsHere are some of the common business questions and objectives that can be answered though these other standard traffic variables:

• Identify how various content categories are utilized by visitors.• Track site usage based on established content hierarchies.• Understand user navigation through Web site sections.

These other standard variables are shown below:Servers.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 refer-ence).

Site Sectionss.channel

The channel variable is most often used to identify a section of your site. For example, a merchant may have sections like Electronics, Toys or Apparel. A media site may have sections like News, Sports or Business.

Hierarchies(maximum of 5)s.hier1-5

The hierarchy variable is used to determine the location of a page in your site’s page structure. This variable is most use-ful for sites that have many levels in the site structure. For example, a media site may have four levels to the Sports sec-tion: Sports, Local Sports, Baseball, Red Sox. If someone vis-its the Baseball page, then Sports, Local Sports and Baseball will all reflect that visit.

404 Error Pagess.pageType

The pageType variable captures the errant URL and referring URL when a 404 Error Page is displayed, which allows users to quickly find broken links and paths that are no longer valid on the site.

Each of these variables is discussed at length in the following sections.

The Channel VariableUse the s.channel variable to define your Site Sections. When developing a page nam-ing strategy, you should define a page grouping strategy at the same time. Page names show the lowest level of granularity while the channel variable shows high-level page groups. Like s.pageName, s.channel is limited to 100 bytes and is case sensitive.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Chapter Six Additional Predefined Traffic Variables 6-3

The following example shows how the channel variable can be used.

Example: s.channel=“Jewelry”

In the case of your “Jewelry” site section, every page within that section should con-tain the s.channel=“Jewelry” code. In the case of the “Electronics” site section, every page within that section should contain the s.channel=“Electronics” code. All Page Views, Visits and Unique Visitor metrics associated with pages within the site section will roll up in the Site Section reports under section names such as “Jewelry” and “ElectronicsAnything that you put into s.channel will show up in the Site Sections report, in the Traffic > Site Content folder. Therefore, “channel” and “site sections” are synonymous.

Once again, we recommend that you populate the channel variable on every page that belongs to a section. You can even make a key page (such as the home page) its own section. When sections have one or more levels of subsections, you can use additional Custom Traffic Variables (s.props) to identify such levels (discussed later in this chapter).

It is usually easy to identify prime values for the channel variable, simply by looking at the main navigation for the site. If you want to know how much traffic goes to these areas of your site, code the channel variable with the associated value.

Note: Classifications can be used in SiteCatalyst Version 15 to group pages into Site Sections as well (with accurate Page View, Visit and Unique Visitor counts); however, pa-thing can only be enabled for s.channel or other Traffic Variables, not classifications.

Examples of channels on the fictitious JJ Esquire site:

s.channel=“Women”

s.channel=“Men”

s.channel=“Jewelry”

s.channel=“Home and Garden”

s.channel captures traffic to high-level page groups such as site sections, populates the site section report, case sensitive, limited to 100 bytes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


s.channel=“Children”

s.channel=“Electronics”

s.channel=“Company”

The Server VariableThe server variable is another predefined Traffic Variable. It is typically 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). It can show either which domains are most popular or which servers are serving the most pages. Frequently, the server variable is not used to measure servers, but is used to measure specific sites, data centers, or vanity domains. The following examples show how the server variable can be used.

s.server=“mainserver.bell.ca”

s.server=“JJ United Kingdom”

s.server=window.location.host

Any value going into the server variable fills the Servers report found in the Traffic > Site Content folder. Like other traffic variables, s.server has a limit of 100 bytes and is case sensitve. The server variable could be used to identify traffic between sites in-stead of putting a site ID into the s.pageName variable. Consider a page populated with the following Page Name and Server name:

s.pageName=“Home Page”

s.server=“JJ United Kingdom”

By correlating these two variables in a Global Report Suite, you can segment page names by domain (country sites in the example above). The use of s.server to indicate site domain is also very useful when creating segments with the Data Warehouse tool and the Advanced Segment Insight (ASI) slots tool.

The Hierarchy VariableThe hierarchy variable is used to determine the location of a page in your site’s hierar-chy or page structure. Hierarchies reflect the natural organization of the site. The hi-erarchy variable is most useful for sites that have many levels in the site structure. For example, a media site may have four levels to the Sports section: Sports, Local Sports, Baseball, Red Sox. If someone visits the Baseball page, then Sports, Local Sports and Baseball will all reflect that visit. The following examples show how the hierarchy variable can be used. In the first example below, hierarchy 1 has four levels: Sports, Local Sports, Baseball and Red Sox.

s.hier1=“Sports,Local Sports,Baseball,Red Sox”;

s.server records web page domain or the server serving the page, populates the server report, case sensitive, 100 bytes

NOTE: You can choose the delimiter that you

want to use with the Hierarchy Variable, but you must notify Adobe ClientCare of your choice. Common delimiters are commas, colons, or vertical lines, also known as pipes (“|“).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


s.hier1=“Electronics|Cameras|Canon EOS-1D Mark IV”

s.hier1=“Men:Fine Apparel:Tuxedo”

s.hier1=s.channel + “|” + s.prop1 + “|” s.prop2

s.hier1=s.pageName

(in some cases, s.pageName can work as a hierarchy value)The JJ Esquire Web site consists of several site sections. In this example, we’ve already coded the hierarchical structure in the Women site section and all subordinate levels. With the Hierarchy report, we can drill down to see Page Views and Daily Unique Visitors for all levels.

Multiple Hierarchies

If you have different ways to cut your site into hierarchical views, you can use more than one hierarchy variable. There are five different hierarchies available in SiteCatalyst, each having its own settings and character length. You simply use the numbers 1-5 with the s.hier variable. For example:

s.hier1=“Women|Activewear|Fur Trim Ski Jacket”;

s.hier2=“Women|Winter|New Items”;

In this case, there might have been two logical ways to cut the site into a hierarchy, including:

1. section | subsection | page name2. section | product seasonality | product newness

Hierarchy 1 matches the site structure. Hierarchy 2 segments the site by seasonality and newness of the product. Additional hierarchies give the analyst multiple ways to drill down into logical page groupings. Using separate hierarchy variables, you can drill down into your site a couple of different ways to see the site usage in different fashions.

Please note, you may find that one hierarchy overlay (using s.hier1) is sufficient even for a very large site. Do not feel obligated to use s.hier2 through s.hier5 if it does not fulfill a Key Business Requirement.

Hierarchy Variable Limitations

The following are Hierarchy variable limitations that you must keep in mind as you plan your implementation.

s.hier1 records site structure and allows the analyst to start from the top of the site hierarchy and drill down through it, populates the hierarchy report, case sensitive, limited to 255 bytes

NOTE: Up to five hierarchies are

available per Report Suite.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• The maximum length of each hierarchy level is 255 bytes.• The total for the entire variable is also 255 bytes.• Be sure to account for the delimiter character between levels .• Maximum number of levels is 98.• The Hierarchy Variable is case sensitive like other Traffic Variables.

The Hierarchy variable allows you to code up to 98 levels on your site. It’s great to know that the Hierarchy variable has that type of flexibility, but keep in mind that 98 levels is provides for some pretty intense and deep reporting. In fact, using just 3-5 levels is common among even large sites. Using more than 10-15 levels is actually less common. We’ll let you come to your own conclusion on that one in case you haven’t yet created the hierarchical architecture of your site.

Hierarchy Gotchas

The following items are limitations or “gotchas” that you need to keep in mind when working with hierarchies.

• The maximum length of each hierarchy level is 255 characters. Each portion is limited to 255 characters, and the total for the entire variable is also 255 characters. The length of any individual level should be clipped to 255 divided by the number of elements plus one (to account for the delimiter character between levels).

• Strip delimiter characters from hierarchy level names. • No blank beginning, middle, or ending levels, which create a “blank” level of

the hierarchy, reported as “Unspecified” in the reports, as shown in the following examples:

s.hier1=“|Level 2|Level 3”

s.hier1=“Level 1|Level 2|Level 3|”

s.hier1=“Level 1| |Level 3”

• Be consistent in spacing (different spacing will cause different entries in the report)

s.hier1=“Level 1 |Level 2”

Hierarchies vs. Site Sections

Hierarchies and Site Sections seem to accomplish the same thing, don’t they? So which do you choose? Well, most large sites actually use both. Although the function is simi-lar, the reports look much different to the analyst. Site Sections (and similar reports) are very horizontal in nature. They show you metrics for groupings of pages at a par-ticular level across your entire site. Hierarchies allow you to drill down from a top-level section. Once you start drilling down, you can’t see other groupings of pages at that same level outside of the hierarchical chain.

Both serve a purpose. Let’s think about this graphically and take a look at the resultant reports. In the following example, we’ve captured the hierarchy of this site in s.hier1 and the same hierarchical information in three Traffic Variables: s.channel, s.prop1 and s.prop2 for Site Section, Subsection and Sub-subsection, respectively.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The Hierarchy report shows Traffic Metrics for the vertical hierarchical chain that shows Women (Level 1), Handbags (Level 2) and Clutches (Level 3). The Sub-subsection report shows a horizontal view of all Level 3 groupings. We can see Traffic Metrics for Clutches, Totes and Dresses.

You may ask yourself the question, “Can’t I opt for the Site Section implementation and then correlate the different levels using the correlation function to drilll down between levels?” The answer is yes. The only drawback is that the Page View metric is the only metric available when breaking one Traffic Report down by another. If you wish to see Visits and Unique Visitor metrics at each level, use the Hierarchy variable.

So when trying to remember the difference between Hierarchies and Site Sections, consider the following:

• Hierarchies deliver a vertical, drill-down view of site traffic.• Hierarchies show traffic subordinate to any superior levels while still showing

all enabled metrics (Page Views, Visits, Unique Visitors).• Hierarchy drill down follows site structure and may be easier for new analysts

to navigate who are not completely familiar with the site.• Hierarchies show traffic to multiple page group levels with one variable

(s.hier1).• Hierarchies can be correlated with other Traffic Segments.• Site Sections deliver a lateral, level by level view of site traffic.• Site Sections show you traffic completely across any single level. • Site Sections can be correlated with other Traffic segments (e.g, show me which

sections 40-44 year olds view).• Site Sections can show segmented traffic to subordinate sections (segment is

based off of a superior level; e.g., the just Subsections in the Women Site Section; Hierarchies can do this too). Page View is only metric available in breakdown.

• Site Sections show traffic to multiple levels with the use of multiple s.props (custom traffic variables) and the s.channel variable.

TiP: Many large clients utilize both Hierarchies

and Site Sections. If both report types offer something that you need, why choose between the two? Try both.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Correctly coding the Hierarchy variable makes it very easy to drill down in your re-ports and see how much traffic, including de-duplicated Unique Visitors, come to a section of your site. This tree-type view of your page structure is available nowhere else in SiteCatalyst.

Many Adobe SiteCatalyst clients employ both Hierarchies and Site Sections.

404 Error Pages (pageType Variable)The s.pageType Variable is only used to designate a “404 Page Not Found Error.” It only has one possible value, which is “errorPage.” Adobe highly recommends imple-menting the s.pageType variable on the error page that your system serves when a visi-tor clicks on a retired link or enters an erroneous URL in the browser address bar. With the s.pageType variable, you can discover broken site links and broken referral links.

404 Error Page Method 1

To populate the s.pageType variable, follow the example below on your 404 error page (remember to never populate s.pageType on any other page besides your error page). Do not deviate; the variable is case-sensitive.

s.pageName=““

s.pageType=”errorPage”

By leaving the s.pageName variable blank, it will default to the URL. This is the one case in which you do want that to happen. Why? Because when you set the s.pageType variable, any URL captured in s.pageName is placed into the Site Content > Pages Not Found report.

This will show you all of the pages that people were looking for that no longer exist so that you can make necessary corrections to retired links on your site. In the “Pages Not Found” report, click the icon to the left of the missing page name to see referring pages so that you can see where any broken links might be hiding on your site or a partner site.

When using this method, you should note that the erroneous URL also appears in the Site Content > Pages report as well. Also, keep in mind that s.pageName can only capture the first 255 characters of the URL. After 255 characters, SiteCatalyst will truncate the URL.

s.pageType coded only on the 404 error page, “errorPage” is the only possible value, s.pageName should be left blank when s.pageType is set, populates the pages not found report

NOTE: You don’t need to set other variables

on 404 pages, and you shouldn’t set the s.pageName variable (URL and Referring URL are set automatically by the .JS file).Ado

be In

terna

l Use

Only

Do Not

Distrib

ute



Remember to only populate s.pageType on your site’s error page. Use the following syntax:

s.pageName=“404 Error:” + document.location

s.pageType=“errorPage”

Using this method, you should prepend “404 Error:” for easy filtering in the Pages report. The erroneous URL will appear in both the Site Content > Pages and the Site Content > Pages Not Found reports. Using this method, SiteCatalyst can only cap-ture up to 100 characters of the erroneous URL.


Once again, remember to use the following code only on your site’s error page. Use the following syntax and be sure to enable a correlation between s.prop1 and s.prop2:

s.pageName=“404 Error Page”

s.prop1=document.location

s.prop2=document.referrer

By using this method, we actually opt not to use the s.pageType variable. The main purpose behind Method 3 is to avoid populating too many erroneous URLs into your Pages report (only one unique page name, “404 Error Page”, will ever be populated into the Pages report when the 404 Error Page is served).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


This can be helpful if you exceed your 500,000 unique page names count each month. In this example, erroneous URLs would appear in Custom Traffic > Custom Traffic 1 and referring pages appear in Custom Traffic > Custom Traffic 2. The URL cap-tured would be limited to 100 characters as it was using the second method.

In general, Method 1 is recommended for most clients, but these alternate methods may be useful based on your site requirements. If you can’t decide, contact Adobe Client Care or your Implementation Consultant.

Exercise 6.1 Traffic Variable Usage



• Need to know content site usage at page and section levels• Determine if there are links to retired content


• Number of Page Views to pages that get traffic• List of links to missing content and number of attempts to access content • Traffic Metrics for the main areas of our site, available in top-level site navigation

Assignment:

What kind of variable(s) should you use to fulfill each business requirement?

Solution

Example

Implementation

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 6.2 Error Page



• Determine if there are links to retired content


• List of retired links and the number of times each link is clicked

Assignment:

Code the “404 Error Page” to automatically record links to retired content (error page can be accessed from the “Site Map”).

Exercise 6.3 Traffic to Content Structure



• Track visitor traffic to multiple levels of page structure on the site• Understand consolidated site traffic across multiple sites• Ability to segment by site at the Global Report Suite level


• Traffic Metrics for Site Sections, Sub-Sections, Sub-Sub-Sections, etc...

Assignment:

What kind of variable(s) should you use to fulfill the business requirements?

Solution

Example

Implementation

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 6.4 JJ Esquire Pages


Assignment:

On your own JJ Esquire Web site, code the following pages:1. Home Page 2. Women Site Section page3. Women’s Activewear subsection page4. The Fur Trim Ski Jacket page in Women’s Activewear

With the following values where applicable:1. Page Name2. Server3. Site Section5. Hierarchy

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

7-1

Chapter Seven

Custom Traffic Variables

OverviewAs you implement SiteCatalyst code, you may need to capture certain values that are custom to your site. If SiteCatalyst does not have a Predefined Traffic Variable to cap-ture the data that you’d like to record (examples of predefined variables are s.pageName, s.channel, s.server, s.hier1), you should use a Custom Traffic Variable..

As an implementor, you have the option to enable and use up to 75 Custom Traffic Variables. These variables are calls s.prop in the code and are numbered from s.prop1 to s.prop75. These variables haven’t been pre-named since custom variable usage dif-fers between each SiteCatalyst client. You can name them in the interface and use them for whatever purpose that best serves your analytical needs. This chapter will introduce some common usage situations for Custom Traffic Variables.

Objectives• Capture segments using Custom Traffic variables• Understand when to use Custom Traffic variables• Use List props to capture multiple values

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Using s.props

Key Business RequirementsBecause Custom Traffic variables (also known as “s.props” in the code and “Custom Insight Variables” in the interface before they are renamed) are in fact custom, there are endless business questions that can be answered though the Custom Traffic Variables, depending on what you are capturing from your Web site. The following list contains a few common goals and objectives:

• Count values on a given page or function on the site.• Understand user navigation through the Web site. • Understand internal user search behavior.• Segment visitor traffic by navigation or category.• Segment visitor traffic by demographics.

Understanding the TermsThere are several terms that might be used when you are talking about these variables. These include:

• Custom Traffic Variables• Custom Insight Variables• Property variables • “s.props”

s.prop custom traffic variable, custom insight variable, property variable, each s.prop populates a custom traffic report, is case sensitive, limited to 100 bytes, up to 75 available

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


These terms all mean exactly the same thing. For example, in the code whatever goes into s.prop1 shows up in the Custom Insight 1 report (which can be renamed) which is the first Custom Traffic Variable. Makes sense, right? In this workbook, all these terms will be used at different times, just to keep you on your toes. Just remember that these terms all represent the same thing. The following are examples of coding the Custom Traffic Variables:

s.prop2=“internal search term”

s.prop15=“Flash Version 10”

s.prop16=“Registered User”

s.prop17=“German Page”

Looking at these examples, you can now see why they are called “s.props.” That is how they look in the code. They are also sometimes called “props” for short, or “property variables” for long.

In the interface, the menus call the reports “Custom Insight” reports. These Custom Insight reports are based on traffic variables that behave the same as the predefined variables such as s.pageName, s,channel, and s.server. For example, they are limited to 100 bytes of data, are case sensitive and they do not persist from page to page. There are 75 Custom Traffic Variables available for your use and enjoyment (s.prop1 through s.prop75). You can enable and name these Custom Traffic Variables in the Admin Console under Admin>Report Suites>Edit Settings>Traffic>Traffic Variables.

Two Purposes for Custom Traffic VariablesThere are two main purposes for populating a custom traffic variable:

1. Counting instances of a specific value 2. Measuring traffic for a specific segment

Purpose 1: Counting Instances of a Specific Value

Examples of this use of an s.prop are:

• Internal search terms• Internal search type or scope• Flash version• Media player version• Item selected

In all of these cases, you are not really asking how much traffic (how many page views) happened with a specific value. You are simply asking how many times a value was recorded.

Internal Search Example

For example, how many times did someone search on the term “blue hat” on an inter-nal search? You are not asking how many pages were seen by people after they searched for this term. In the resultant report, the Page Views metric would signify the number of searches or instances of that value (internal search term) being set. The search term should be populated into s.prop2 as follows:

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


s.prop2=“blue hat”

By the way, it is ALWAYS a good idea to push values to a specific case when the user has a chance to type something in. As has already been stated, Traffic Variables are case sensitive, so in the case of an internal search field, “hat,” “Hat,” and “HAT” would all be separate entries in SiteCatalyst reports if not forced to lowercase or uppercase. The most common and recommended solution is to push all user-inputted data to lower case.

To force an internal search term to lower case, use the following code:

s.prop2=“USB Memory”

s.prop2=s.prop2.toLowerCase()

How do I populate the Internal Search Term?

The question may also arise “How do I initially populate the internal search term into s.prop2?” The answer is that it depends on your site. The focus of this course is to help you know how to code, but there are many methods to actually populate the variables. We leave that up to you.

Two common methods:

• Pull the internal search term value from a session variable and populating into s.prop2.

• Use the free SiteCatalyst getQueryParam plug-in to pull the search term from the query string (if present in the query string) to populate s.prop2.

Multiple Search CriteriaWhen sites have multiple search criteria, you can put each item into a separate s.prop to understand which values are selected the most in each case. For example:

s.prop2=“Internal Search Term”

s.prop3=“Scope of Search” (searched entire site or just a portion)

s.prop4=“Number of Results”

An alternate, but less common option, would be to capture all terms in one variable and use SAINT Classifications to create the three separate reports (saves variables, but requires more maintenance).

TiP: Force all user-inputted values

to lower case to prevent duplicate values of different cases in Traffic Reports. Values can be forced to lower case through a JavaScript function.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


As you will see in the next chapter, you will then be able to relate these reports to each other and see how they break down by each other (e.g., “When the scope of the search is just the “Home and Garden” section of my site, what were the search terms?”).

Purpose 2: Measuring Traffic for a Specific Segment

The other purpose of setting an s.prop is to see how much traffic comes from a spe-cific segment. This entails placing a value on EVERY page that belongs to a segment. Some segment examples include:

• Page groupings (sections, subsections, etc.)• Logged in traffic• Registered users• Language pages

Language Page Example

If your site attracts people who speak different languages, you may have several ver-sions of pages that have been translated for their convenience. You may then want to know which language pages have the most traffic. In the following example, a visitor might start at a “choose your language” page and then go to different English and French pages (which may actually be unlikely in one visit, but illustrates the point well).

Consider the image that shows the visitor’s behavior and ask yourself the following: What will SiteCatalyst report?

NOTE: If an s.prop value is omitted, it

isn’t counted. Page View, Visit and Visitor metrics in certain Custom Traffic Reports may differ from Site Metrics because a specific s.prop value may not occur on every page.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The property variable s.prop17 (we’ve renamed it “Page Language” in the interface) is set on every page that belongs to a language segment. The visitor didn’t visit a specific language page on Page 1, but did on subsequent pages.

SiteCatalyst would report the following:

In the example, the visitor viewed six pages, but only five Page Views appear in this Page Language report. Why? If a value is omitted (as it was on Page 1 since nothing was populated into s.prop17 on that page), it isn’t counted. Nevertheless, our site still received six Page Views. In which report would we be able to see all six Page Views? You could see those Page Views in either the Site Metrics > Page Views report or the Site Content > Pages report in SiteCatalyst.

Additional Levels of Page GroupingAs discussed previously, the s.channel variable is used to show traffic to major sec-tions of the site, and the s.channel values show up in the Site Content > Site Sections report. But what if you have multiple levels of groupings, such as subsections and sub-subsections? This is a perfect case for the use of s.props. If you use one s.prop for each level of page groupings, you will be able to see how much traffic goes to the different sections and subsections at each level. This is similar to the hierarchies function, but with some key differences:

• With hierarchies, you drill down through the structure to lower levels.• With s.props, you could see ALL of the lower level groupings across the entire

site in one report.• With hierarchies, you get de-duplicated metrics to sub-levels.• With s.props, if you want to break reports down by each other, you will only see

the Page Views metric.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Grouping by Kinds of Pages

The s.prop can be placed and populated on any page. Let’s suppose that you want to see traffic to each level of your site in one report. For example, on your Retail site, you want to see traffic to the Home Page, Product Category, Product Subcategory and Product pages all in one report. This can be accomplished with one s.prop to show different “kinds” of pages that span levels. Page Views, Visits and Unique Visitors can be counted for pages at all levels throughout your site. To accomplish this, the s.prop, let’s say s.prop22, must be placed on every page and populated with that page’s “kind” such as Product Page or Category Page.

Please note that classifications can be used in SiteCatalyst Version 15 to group pages without the use of s.props while still maintaining accurate Page View, Visit and Unique Visitor metrics. Pathing is not available for classifications.

Site Exercise 7.1 JJ Esquire PagesEstimated Time: 5 minutes

Assignment:

Code the following pages:

1. Home Page 2. Women Site Section3. Women’s Activewear subsection page4. The Fur Trim Ski Jacket page in Women’s Activewear

With the following value where applicable (not all pages may be part of a subsection):

5. Sub Section

Registration Status Example

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In this example, you might want to know how much traffic comes from your regis-tered users versus people who are not yet registered. In cases like this you might hard code the s.prop to “Not Registered” unless you determine that they are in fact regis-tered through your own server-side logic, at which time you change the value to “Registered.” This report will show how much traffic comes from both segments.

s.prop3=“Registered”

s.prop3=“Unregistered”

The key here is that you must set the s.prop on every page, so you need to make sure that you have access to the information (in this case Registration Status) on every page so that you can set it into the s.prop. This may entail accessing a session variable or reading a cookie, etc.

Membership Types

This same principle could apply to other kinds of segments, such as membership type. If you have Platinum, Gold, Silver and Bronze members on your site, you could have them log in, and then populate the s.prop on every page that the member touches so that you know how much traffic is attributed to different membership types. In the next chapter, you will also see that with Correlations (Traffic Report breakdowns), you can know not only how much traffic is coming from these segments, but also what content each segment consumes

s.prop18=“Platinum Member”

s.prop18=“Silver Member”

List Prop/Delimited Prop

Suppose that you want to capture many separate values from a single page. A regular s.prop can accept many values at the same time, but the resultant report will probably be a little confusing. The List Prop allows you to capture multiple values, but breaks the values up so that they appear as separate line items in the report.

The list prop is most commonly employed with pages that contain user-selectable values such as listed items with check boxes or radio buttons. With the List Prop, each selected item will increment as a separate line item. Problem solved! Pass in multiple values at the same time that appear in the same report, but on separate line items!

List Prop ExampleIn this example, we’ve made a simple home-made survey asking our visitors which Adobe products they own. Three visitors come to our site and choose fill out the survey.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


If we used a “regular” s.prop to record the survey submissions of the three visitors, the report might look like this:

This is not helpful, because each line item shows combinations of software products owned by each visitor. With only three line items, we could do some quick mental calculations to determine how many own Photoshop, but imagine if we received one thousand survey submissions. Now, if we had used a List Prop-enabled s.prop, the resultant report would look like this instead:

This report is much more useful because it splits the individual values out into sepa-rate line items instead of the jumble of combinations we saw in the previous report.

Enable List Props via Adobe Client Care

In order for an s.prop to have List Variable functionality, it has to be enabled on the back end by Adobe Client Care. When you request that it be enabled, indicate the de-limiter that you would like to use. Once the s.prop of your choice has been enabled, multiple values can be set in the variable as shown in the following examples:

With pipe delimiter s.prop11=“Flex|Illustrator|Photoshop”;

With comma delimiter s.prop11=“Cold Fusion,Flash Pro,Photoshop”

Caveats

When a Custom Traffic Variable has been enabled by Adobe Client Care as a List Prop, some additional Traffic Variable features are not supported. These features are discussed in detail later. Here is the overview of their supported status:

Not supported for list props:

• Visits metric• Unique Visitors metrics

list prop captures multiple values concurrently from the same page (through the same image request), values are passed into the same prop and appear as separate line items in reports, case sensitive, limited to 100 bytes including delimiter, delimiter is chosen by the client and enabled by Adobe ClientCare

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Correlations• Pathing

Supported for list props:

• Page Views metric• Classifications

Since a List Prop-enabled s.prop is still a Traffic Variable (besides possessing its magi-cal List Prop properties), it is subject to Traffic Variable limitations. List Props are limited to 100 bytes of data and they are also case sensitive.

Naming Custom Traffic VariablesCustom Traffic reports display metrics related to the values added to a specific prop-erty variable. For example, data collected for Custom Traffic Variable 1 (i.e., s.prop1) will display in the interface as “Custom Insight 1” report, which is the default name for that report. However, it is highly recommended that you change the report title to be more user-friendly. Your analysts will thank you.

To change the name of a Custom Traffic Variable, follow the steps below.

1. Log in to SiteCatalyst.2. Click the Admin tab and select Report Suites from the drop-down menu.3. Select the report suite(s) that contain the Traffic Variable in question.4. Under Edit Settings, select Traffic > Traffic Variables.5. Select the Traffic Variables in question and rename6. Don’t forget to click Save at the bottom.

The name you give to each Custom Traffic Variable will show up in the SiteCatalyst Report menus in the interface.

Custom Traffic Variable SummaryUse Custom Traffic Variables to record custom values that are specific to your com-pany. Each variable populates a different report in SiteCatalyst (s.prop1 populates the

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Custom Insight 1 report). Custom Traffic Variables are case sensitive and limited to 100 bytes of data.

Be sure to populate segment identifiers on every appropriate page. For example, if you’re trying to record each internal search term, that should only be populated one time. The Page View metric, when applied to this Internal Search Term report, repre-sents the number of times each term was searched. The same applies for other values such as recording the Flash version of a browser. Remember, populate the value just once for simple value counting.

If you’re trying to determine the traffic activity of a segment, then the segment value, once identified, should be populated on every page. Examples of this are Groups of Pages, Membership Types and Login Status. Groups of Pages, whether we’re grouping by Page Language or Site Section, can be theoretically hard coded. User-related values such as Membership Type and Login Status, must be determined through your own scripting and subsequently populated into the appropriate Traffic Variable. By popu-lating the value onto every page, you can see how much traffic you get from each segment.

Remember, whatever you pass in is counted and recorded exactly as it was populated into the s.prop. Whatever you omit does not get passed in.

Exercise 7.2 Internal Search TrackingEstimated Time: 3 minutes


• Understand internal user search behavior


• The number of searches for every internal search term • The number of results per search term including zero search results• The number of times a search scope is used in conjunction with the search term

Assignment:


Solution

Example

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Implementation

Site Exercise 7.3 Internal Search Term TrackingEstimated Time: 5 minutes

Assignment:

Record the following search activity on the appropriate page and force user-inputted values to lowercase using JavaScript:

A visitor searches for “Wall Decor” in the “Home & Garden” section and gets “78” search results.

Note: Make sure that the search term is set to lowercase via JavaScript.

Site Exercise 7.4 Hotel BookingsEstimated Time: 7 minutes


• Understand visitor behavior and choices throughout the online booking process• Track all hotel booking options within the selection process• Track by Hotel ID, Rooms Booked, Length of Hotel Stay, Days to Arrival and

Rate Code


• Number of reservations by Hotel ID, Rooms Booked, Length of Hotel Stay, Days to Arrival and Rate Code

Assignment:

Record the visitor’s actions on the appropriate JJ Travel page:

A visitor to the JJ Travel site books a stay at the “JJ Esquire Park City, Utah” (Hotel ID) with “2 rooms” (Rooms Booked) for “7 days” (Length of Hotel Stay) “21 days in advance” (Days to Arrival) at the “0759” rate (Rate Code).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 7.5 Traffic by Membership TypeEstimated Time: 3 minutes


• Understand how much traffic is associated with different membership types on your site, based on your existing Gold, Silver, Bronze members and public traffic


• How much traffic is coming from members who log in (Gold, Silver, Bronze members) and those who don’t (public traffic)?

Assignment:


Solution

Example

Implementation

Site Exercise 7.6 Newsletter SubscriptionEstimated Time: 5 minutes


• Understand which JJ Newsletters subscriptions are favored by JJ Esquire site visitors


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Record the newsletter name and subscription count of JJ Newsletters for all visitors

Assignment:

JJ Esquire offers various weekly newsletters. Code to record the following using s.prop(s):

A visitor signs up for the following newsletters: “JJ Living”, “JJ Foreign Policy”, “JJ Special Offers” and “Random Spam”.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

8-1

Chapter Eight

Traffic Variable Features & Functions

OverviewThe Traffic Variables discussed in the previous chapters offer a powerful means by which you can capture and analyze your traffic data. In addition to the variables, SiteCatalyst offers several features and functions that you can use to break down and further analyze your traffic data. These features and functions apply to predefined Traffic Variables (s.pageName, s.channel, and s.server) as well as Custom Traffic Variables (s.props). The features are:

• Correlations — Break down traffic reports by other traffic reports to see key traffic relationships.

• Pathing — See high-level navigation flow or how people move between values.• Additional Metrics — Enable additional traffic metrics to give you insight into

traffic patterns.

We will discuss each of these and how they work.

Objectives

• Understand the purpose of Correlations and Paths• Learn how to enable Correlations and Paths• Learn about the benefits of additional Traffic Metrics for s.props

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Features and Functions

Traffic Correlations“Correlations” are custom report relationships requested by you, the client, and en-abled by either you (for “2-item” correlations, or just linking 2 reports together) or by Adobe Client Care (for “5-item” or “20-item” correlations, or linking 5 to 20 reports to each other).

Our Data Collection Module removes data relationships to optimize SiteCatalyst re-ports. By creating a correlation, you tell SiteCatalyst which data relationships should remain intact so that you can break down one traffic report by another. This allows you to understand the unique relationships between different line item combinations.

Almost all traffic reports can be correlated with one another, including Custom Traffic Variables (s.props). As mentioned, these reports can be correlated in groups of 2, 5, or 20. Two-item correlations can be created in the Admin console in SiteCatalyst under Admin>Report Suites>Edit Settings>Traffic>Data Correlations. Call Client Care for corelations greater than 2.

When creating a correlation, consider the following:

• Consider scalability: you cannot port data from a 2-item table to a 20-item table.• Consider speed: 20-item tables are best accessed through Data Extract versus

the SiteCatalyst interface.

correlation a breakdown of one traffic report by another, correlate from 2 to 20 reports

TiP: How do you decide which reports

to correlate? Go back to your KBRs and determine what kind of data your Report Consumers need.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Chapter Eight Traffic Variable Features and Functions 8-3

A very common example of a correlation would be to break down a site section by pages so that you can see which pages within a certain section received the most traf-fic. In the example below, the Women site section is being broken down by pages.

For values to correlate, they must be set on a single page. This creates the correlating link between the data points. For instance, if the s.channel value of “Women” is set on the same page as the s.pageName of “Women:Activewear:Wasatch Mountain Ski Coat”, they would correlate and show in the same report.

NOTE: Correlated reports can only

support the Page View (instance) metric.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Conversely, if a Custom Traffic Report (s.prop1) is populated with the value “User ID 1234” on the Home Page, and if Custom Traffic Report 2 (s.prop2) is populated on a different page with “Category 4500,” there is no correlation between the two and they would not show in the same correlation report.

For more information on correlations, refer to the online Implementation Manual or SiteCatalyst User Manual in the Help section.

Correlating a Report

Whenever a Traffic Report has line items that can be correlated with other Traffic Reports, the analyst will see a small green magnifying glass to the left of each line item.

To correlate a report:

1. Click the breakdown icon next to the line item that you wish to break down.2. Select the correlation report to run (e.g., analyze traffic to the Home Page by

visitor’s city).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In the previous example, we broke down the Home Page by Cities (the Pages report by the GeoSegmentation Cities report). The resultant report of such a breakdown ap-pears below. Notice that the filter value, in this case the Home Page, appears in the “Filters Applied (Correlation)” section. Also note that the report name changes to “Correlation Report”.

Optimum Path EngineThe Optimum Path engine records the entire path of your online visitors and custom-ers and allows you to dissect these paths to reveal hidden behavior patterns. Clear, graphical representations let you view site traffic as it flows from one page or item to the next, understand high-level navigation and see visitor fallout.

The Path Reports in SiteCatalyst use the value of s.pageName (or the URL if s.pageName is blank) to show the paths that people take through your site. In the in-terest of concision, Path reports do not show repeated values such as page reloads. While path reports are shown for page names by default in the Paths > Pages report, SiteCatalyst offers the ability to enable “pathing” for other Traffic Variables giving you 16 Path reports for each enabled variable. Since the majority of Traffic Variables can be enabled for pathing, you could see Path reports that show you how visitors move between site sections, subsections, or detailed content sections.

pathing the change from one value to another over time, the order in which values are recorded in a prop, enabled by clientcare

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Understanding What Pathing Is

In order to really take advantage of this cool feature, you need to really understand what pathing is. In normal Web analytics thought, “pathing” probably makes you think of people moving from page to page. This is true, but ONLY if each page has a different page name. Think about that for a moment and let it sink in. Pathing in SiteCatalyst is not really moving from page to page, but from “page name to page name.” If you were to send SiteCatalyst the same page name for two different pages, it would not be a path, but would be recorded as a reload of the same page.

Therefore, here’s a better definition of Pathing:

Pathing is really defined as changing from one value to another value.

When you enable pathing for the s.channel variable, it allows you to track how site visitors move between Site Sections (as the value changes).

This is then available in the various paths reports, including the Next Site Section Flow Report:

Pathing shows us what the next changed value is. If you need to know the order in which values are collected, then you need to enable pathing for the variable collecting those values.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Another Pathing Example

This same concept of going from one value to another value applies to other traffic variables as well, including s.props. For example, if you enable pathing for your Internal Search Term s.prop, you could see how people “path” through search terms.

In this example, you could see how people refine their search as they try to find your products. You could use that information to make products or groups of products that people are searching on more readily available.

Once you turn pathing on for any Traffic Variable, such as a custom s.prop that cap-tures your Internal Search Terms, you can see reports like the Internal Search Terms Flow report seen above.

Page Pathing “per Something”As a last note here regarding pathing at all levels, there is a difference between pathing an item and “page pathing per an item.” For example, many people want to know how people path through their site when they are logged in vs. not logged in. To see this information you would NOT look at the pathing reports for login status, because they would show you how people changed values in that report, or how they might have changed from logged in to not logged in. You will quickly find that there is nothing in that report that you need.

Instead, what you really want in this situation is page pathing per login status. To get this information in SiteCatalyst, you can concatenate the segment value with the s.pageName variable, and then path that resultant variable. Here is some sample code for “page pathing per member status:”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


s.pageName=“Home Page”;

s.prop18=“Gold”; // Member Status

s.prop19=s.prop18 + “:” + s.pageName;

Then enable pathing for s.prop19 to see how members path through pages.

The Next Membership Status Page Flow report shows you, in the case of the graphic below, how members with Gold Status path through the site.

Additional Traffic MetricsA basic SiteCatalyst Version 15 implementation offers a Page Views, Visits and Unique Visitors in nearly all Traffic Reports. If you’re using SiteCatalyst Version 14, these metrics are enabled on a per report basis.

NOTE: Adobe Discover gives you the ability to

segment page paths without the need to concatenate segment values, and with the ability to apply ANY segment to pathing reports. It’s really quite amazing. Check it out today!

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 8.1 Additional Traffic Features



• Understand how visitors move from Site to Site and Site Section to Site Section• Track site traffic by visit and unique visitor metrics• Analyze the relationship between Site-, Site Section- and Page-level information


• Traffic metrics for all corporate domains in a single report • Paths between Sites, Site Sections and Pages• Visit and Unique Visitors (Daily, Weekly, Monthly) for each level (Site, Site

Section, Page) • Page Views for break downs by Site, Site Section, and Pages by each other in any

combination

Assignment:

What kind of variable(s) and feature(s) should you use to fulfill the business requirements?

Solution

Example

Implementation

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 8.2 Analyzing Traffic FlowEstimated Time: 3 minutes


• Understand the paths of registered users versus guest users• Understand how visitors move between groups of pages


• Page Views per registration status (registered/guest user)• Path Views of paths by registration type• Path Views of paths between Site Sections

Assignment:


Solution

Example

Implementation

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 8.3 Internal Search Term FlowEstimated Time: 5 minutes


• Understand what terms come before and after a specific internal search term• Understand the path a visitor traverses by internal search term• Don’t inflate the regular Internal Search Term report (double counting searches

in s.prop2)


• Path Views of keyword paths (When someone searches by “watch”, what do they search next?)

• Path Views of page paths by keyword (When someone searches by “watch”, which pages does he or she view next?)

Assignment:

Code the “Search Results” page with the proper variable(s) and enable the proper feature(s) to fulfill the business requirements for the following scenario:

A visitors searches by “watch”.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Traffic Variable Section Review

Putting It All TogetherAs discussed in this section, one of the first steps you should take prior to implement-ing SiteCatalyst is to develop a good page naming strategy for your Web site. By doing so, your reporting will be more user friendly.

Another important step as you decide on values for ANY of your reports in SiteCatalyst (including Traffic Reports) is to incorporate all of the needs of the entire enterprise. Talk with all of the people involved, especially the Report Consumers. If you are going to roll values up into a Global Report Suite, you will want to ensure that everyone is putting the same kinds of values into the same Traffic Variables. For example, if you use s.prop2 to capture Internal Search Terms on the US site, make sure that the UK, German, Japanese and all other sites are using s.prop2 for the same purpose.

In any case, the Predefined and Custom Traffic Variables can be used to collect traf-fic-related data from all visitors to your Web site and display it in SiteCatalyst to an-swer the questions you have about the general populous coming to your site. The cus-tom variables can also be used to count the number of times a value is sent into SiteCatalyst, whether simply counting values (like Internal Search Terms) or counting traffic to a segment (like Traffic by User Type).

Finally, SiteCatalyst offers additional features and functions to segment data and dis-sect paths to reveal hidden behavior patterns.

Traffic Variable Summary

• Decide on a good Page Naming schema that is Clear, Clean, Contextual, Concise and Consistent.

• Set global standards for all variables (especially if you will push data from multiple Report Suites into a Global Report Suite).

• String length limitations: Hierarchy has 255 chars each level/total. All others Traffic Variables have a max of 100 bytes.

• Values limited to alphanumeric (ASCII text).• No HTML tags, special chars or symbols.• Set Report Suite to multibyte for UTF-8 and extended ASCII characters and

make sure that s.charSet is appropriately set (note the 100 byte character limit for multibyte characters).

• All Traffic Variables are sensitive to Case and Diacritical Marks (Home Page ≠ home page and L’Oréal ≠ L’Oreal).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• URL of image request cannot exceed 2,083 (IE limitation).

Traffic Enhancements Review

• Traffic Variables may be correlated to other Traffic Variables (enabled by you for 2-item data tables and by Client Care for 5- and 20-item data tables)

• Pathing may be enabled for Traffic Variables*.• Visits metric may be enabled*.• Unique Visitors metrics may be enabled* (Daily, weekly, monthly, quarterly).

* Each of these enhancements must be enabled by Adobe Client Care.

Additional Variable ConsiderationsThe following information may be helpful in determining how to use traffic variables.

• Variables can be set on the page or in the Global JavaScript file (s_code.js).• Not all reports or metrics are automatically enabled.• Enable features that answer your Key Business Questions• Possible cost implications for enabling metrics, reports and correlations (for

questions on this, contact Client Care).• Extraneous correlations only slow down SiteCatalyst.• Separate object name for multiple instances of code on the page (variables

usually begin with “s.”)• If multiple clients “own” a page, they must use different object names (“s” and

“s1”, for example) to populate their own code.

Review QuestionsChoose the best answers for the following questions from Chapters 1 and 2:

1. How does SiteCatalyst collect traffic data for your site?

A. Reading server logs that are passed to SiteCatalystB. The Adobe Crawling Engine crawls the Web site and logs all traffic dataC. Code is placed on each page of your site, and information is sent to Adobe

when pages load and the code is executedD. Customers opt in to be part of the tracking community, at which time code is

placed on their machines to watch Web movement

2. What are the different types of SiteCatalyst variables?

A. Conversion, Traffic, and Paths variablesB. Persistent , non-persistent, and list variablesC. Traffic, Conversion, Configuration, and Automatic variablesD. Traffic, Conversion, Configuration, and ClickMap variables

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


3. What is the default page name value (if the s.pageName variable is not populated)?A. There is no default; the page name variable must be populated for the page

information to be recorded in SiteCatalystB. The HTML page title tagC. The page URLD. The page URI

4. When selecting the appropriate level of page naming detail, you should be sure to include the User ID or Session ID within the page name.A. TrueB. False

5. What is the maximum character (byte) length for the s.server variable?A. 20B. 100C. 255D. 2083

6. Custom Traffic Variables (s.props) must be set on every page that you want the value reported.

A. TrueB. False

7. Where can you give a user-friendly name to your Custom Traffic Variable reports?

A. On the Tools page in SiteCatalyst.B. In the Admin console in SiteCatalyst.C. It has to be set in the variable string along with the specific value.D. It must be done by Adobe ClientCare.

8. Match the Traffic Variable to its function (some functions will not match). Write the number of the correct function next to the variable.

Variable

A. _____ s.pageNameB. _____ s.channelC. _____ s.serverD. _____ s.hierN E. _____ s.propN

Functions1. This is a special variable type used for cascading views of content categories.2. This is used for site conversion numbers and provides conversion visits and

visitors.3. This is a Predefined Traffic Variable, traditionally used for high-level content

categories.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


4. This provides customization and segment reporting based on Page Views, Visits, or Visitors.

5. This is used for tracking external campaigns.6. This controls the value displayed in all page-related reports, including Path

reports.7. This provides customization and segment reporting based on Conversion

Metrics such as Revenue and Orders.8. This is a Predefined Traffic Variable sometimes used to show balance

between multiple Web sites in a global environment.

Traffic Variable Code in ActionLet’s see how Traffic Variables work by going through a scenario with a visitor that comes to our JJ Esquire site. Throughout this scenario, keep in mind that we’re speak-ing about a company, JJ Esquire, that uses SiteCatalyst to track visitors. The scenario explains how a company that uses SiteCatalyst might track a visitor, not how Adobe tracks visitors to the Adobe Digital Marketing Site.

Scenario

Let’s imagine that this person has been to our JJ Esquire site before and filled out a survey capturing his age. He’s now returning to the site. Let’s see how we’d use Traffic Variables to record his behavior. Please note that each variable and its value should be contained on one line. Because of space limitations in this example, some variables and their values are displayed over two lines instead of one.

As the visitors arrives to the site, we identify the visitor and populate his Age Group value into s.prop20. Page Name and Site Section can either be hard coded or popu-lated dynamically through our own scripting. We’ve concatenated the Age Group and Page Name and enabled pathing for s.prop.21 so that we can path by Age Group.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Traffic Variables don’t persist. They are the visitor’s footprint and must be repopu-lated on every page. We’ve done that here Page 2.

Traffic Metrics such as Page Views, Visits and Unique Visitors are calculated automatically. No need to send Traffic Metrics through the code. We take care of those calculations for you automatically on the traffic side.

Our visitor has reached the fourth page. That’s the end of the visit. Take a look at the Traffic Variable values that have been populated. How will these values appear in the reports?

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Let’s take a look at the reports now. The Pages report, populated by the s.pageName variable would look like the report below.

Every page receives a Page View since each page name was submitted one time through the s.pageName variable. Page Views are really a representation of Instances of values being set in a Traffic Variable.

How would the Site Section Report look? This report, populated by s.channel, would look like the report below.

Since the Site Section name “Electronics” was passed in on both Page 2 and 3, it receives two Page Views on line item 1.

The next report, Age Group, populated by s.prop20, the s.prop that we chose to capture Age Group during the implementation stage of JJ Esquire, shows us Traffic by Segment. So how many Page Views did we get from 40-44-year-olds? See the report below.

Finally, we concatenated s.prop20 and s.pageName to create a report that shows us Paths by Age Group. What would this Next Age Group Flow report look like? See the report below.Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

9-1

This third section introduces you to the SiteCatalyst Conversion Variables and shows you how they behave. We’ll learn about Predefined and Custom Conversion Variables and different ways they can be used to help you track what’s happening on your site. We’ll learn what s.eVars and Custom Events are. We’ll find out how to use the persis-tence functionality of Conversion Variables to our advantage to get all sorts of great analytical information about visitor activity on our Web site.

Exercises throughout this section are also based on your own JJ Esquire Web site. This will provide you with excellent practical experience.


Chapter 9: Predefined and Custom EventsChapter 10: Conversion VariablesChapter 11: The Purchase Confirmation PageChapter 12: The Campaign VariableChapter 13: Custom Conversion VariablesChapter 14: Conversion Features and Functions

Section Three

Conversion Variables

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

9-2

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

9-3

Chapter Nine

Predefined and Custom Events

Objectives

• Define the purpose and use of Conversion Events• Learn how to code predefined SiteCatalyst events or metrics• Learn how to create and code your own custom events

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Events are Conversion Metrics

Introduction to s.eventsThe s.events variable differs from all of the other Conversion Variables (discussed in the next chapter). While the other Conversion Variables often hold text strings in the same way that Traffic Variables do, the s.events variable just counts the number of times that an event happens (e.g., a purchase, registration or other conversion). These events are simple counters designed to measure the number of times a Success Event (conversion) happens on your site.

The s.events code is placed on the page on your site where the Success Event or Conversion “thing” happens or on the confirmation page of the action. Remember, events are really just Conversion Metrics that tell us how many “things” or conver-sions happened on your site.

There are many kinds of success events, depending on your Web site type. Several examples are listed below.

• Retail: Product View, Checkout, Purchase• Media: Subscription, Contest Sign-up, Page View, Video View• Finance: Application Submission, Login, Self-Service Tools Usage• Travel: Booking (purchase), Internal Campaign (click-through), Search (pricing

itinerary)• Telecommunications: Purchase, Leads, Self-Service Tools Usage• High Tech: White Paper download, RFP, Form Completion, Support Requests• Automotive: Lead Submission, Request a Quote, Brochure Download

When we were dealing with Traffic Metrics, we didn’t have to worry about coding them into the site. Page Views, Visits and Unique Visitors were instantly calculated based on the number of times a Traffic Variable value was set. So why do I have to set Conversion Metrics in the code with s.events? Because we don’t know where conversions occur on

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


your site or what you even deem a conversion. That’s why it must be coded into the im-plementation. It’s pretty simple and also a lot of fun in our opinion!

Conversion on Your SiteAn event, also called a Success Event, is defined as a point on your Web site in which a successful conversion occurs. For example, if a product is added to the customer’s shopping cart, the scAdd event is used to capture that Success Event. Just think of events as Conversion Metrics.

Adobe offers both Predefined and Custom Events. The Predefined Events are related to Retail conversions and have specific names (discussed later in the chapter). The Custom Events can be used for any purpose and are commonly used for conversion activities such as registrations, subscriptions, downloads, form completions, sign-ups, etc. They can even be used in a Retail solution to fill in any gaps in the checkout process that go beyond what is provided with the Predefined Events.

s.events SyntaxThe general syntax for the s.events variable is as follows:

s.events=“[SiteCatalyst event name]”;

This variable cannot accept just any value, but must be filled with either a Predefined Event name or a Custom Event name, as described in the following sections.

Predefined Events (Retail)Each of the Predefined Retail Success Events is defined in the table below with sug-gested use:

prodView Success event occurs any time a visitor views a product de-tail page.

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

scView Success event occurs any time a shopping cart is viewed.

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

scRemove Success event occurs any time a product is removed from a shopping cart.

scCheckout Success event occurs on the first page of a checkout.

purchase Success event occurs on final page of checkout, includes the Revenue, Orders, and Units metrics.

When any of the Predefined Events above occurs, an instance of the event is incre-mented, and you can view the Conversion Metrics related to the event in several dif-ferent SiteCatalyst reports. The steps used to code these are similar to the steps dis-cussed in the custom events area:

s.events the variable that captures success events (aka custom events, conversion events, conversion metrics), can be serialized to prevent duplicates, populates custom event reports

NOTE: Predefined Retail Events can

be repurposed for other site types. Event names in the code do not change, but reports that the events populate can be renamed in the Admin Console.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


1. Decide which events apply to your Retail site.2. Place code on the page where the event happens/is completed (when the prod-

uct is viewed, after the checkout button is clicked, on the purchase confirma-tion page, etc.).

The following is an example of the code used to configure Predefined Events. (In regular page code, the s.events variable only appears one time. If you need to add multiple events on one page, follow the middle example and delimit the events by a comma.)

s.events=”prodView”

s.events=”scOpen,scAdd”

s.events=”purchase”

In the first example above, “prodView” is the value set in the s.events variable. Any time a product detail page is viewed, the event is incremented by one. In the second example, two values are captured at the same time. When multiple success events oc-cur on the same page, each event is incremented.

Custom EventsCustom Events enable you to define the conversion event that you want to track. For example, if your site has a newsletter, your success event might be “Newsletter Subscription.” This event is not one of the Predefined Retail Events, but by using a Custom Event, you can track the number of times that visitors subscribe to your newsletter.

Custom Events follow the standard syntax shown below.

s.events=“event1[,event2]” The basic steps that you go through to assign and code a Custom Event are:

1. Decide which events to use for site goals.2. Put code on the page where the event is completed (Confirmation Page,

Thank You Page, etc.).

Regardless of what you decide to use the event for, the syntax will stay the same. This is apparent in the following examples:

• Custom Event 3 = Registration s.events=”event3”

• Custom Event 7 = News Letter Sign-up s.events=”event7“

• Custom Event 15 = Form Completion s.events=”event15”

• Set integers greater than one in custom counter events s.events=”event17=5”

This greatly necessitates documenting the purpose of your Custom Events. If you don’t document what the event is being used for, it may be difficult later to determine exactly why you coded an event onto a page. Make sure to document everything in the Solutions Design Document.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Naming Success Events

Because the code only uses the Custom Event name (event1, event2, etc.), you need to provide the friendly name for that event to SiteCatalyst so that it can show up in the re-port menus, reports and metric interface. Counting events is kind of like delivering a letter to a mailbox. The “event3” code is the mailbox address, and “Registration” is the family name. Make sure to write the correct address (event3) in the code so that we de-liver the correct count to the correct mailbox, but put a friendly name on the mailbox so we don’t have to remember the address.

Naming events is done through the SiteCatalyst Admin console. To name your success event, click into the Admin console, select your report suite(s) in question, and select Success Events under the Conversion menu.

Here you will be able to give a friendly name for each event. In fact, in this same menu, you can rename the Predefined Retail Events if you need to repurpose them.

This can be helpful if Retail conversions on your site have different names than the default Success Event names. For example, a travel site might want to change the “Orders” metric to “bookings” and the “Units” metric to “nights booked”.

Always Use Event Name in Code

Even though you can rename the event (remember, it’s a metric), always use the cor-rect event code. Think of the renamed event as a family name on a mailbox. The fam-ily name on a mail box makes it easier for you to identify the owner, but the Postal

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Service doesn’t deliver mail based on the name on the mailbox. In fact, a letter without an address will never arrive, but it certainly will even if it’s missing the addressee’s name.

When you rename a metric, it works in the same way. The event code is the address. It must be present in the JavaScript page code in order for SiteCatalyst to increment the even properly in the correct report. When you rename an event, you’re renaming the Conversion Event Report that you can see in the interface, but you’ll never use this friendly name in the code. Remember, SiteCatalyst only recognizes addresses, not friendly names.

Correct syntax for events:

s.events=“event3”

Incorrect syntax events:

s.events=“Registration Completions”

Custom Event Types

When you use a SiteCatalyst event to count conversions on your site, you can set the events to either increment one at a time, increment by any value or accept a currency value.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In the SiteCatalyst Admin console, in the same place described above where you can name your events, you can set the correct event type.

The event types are:

• Counter – Increment one or more (integers only). This is the most common type of event, and would include such events as registrations, subscriptions, form completions, leads, etc.

• Currency – Increment by any amount. This type also performs currency exchange if necessary, which will be discussed in later in this workbook.

• Numeric – Increment by any amount, but does not use currency conversion.

You will also notice in this list a choice for each type of event that says “(no subrela-tions)”. Subrelations functionality gives you the ability to apply the event (remember, an event is a metric) when you are breaking down one Conversion Report by another. In almost every case, you should choose the event type that does not have the “No Subrelations” limiter.

The Conversion Funnel

Conversion ratios usually measure conversion between the starting, ending and mile-stone events or points of a conversion process. Once you have coded the Success Events onto the site, SiteCatalyst will create the ratios between these different Success Events and show them in a Conversion Funnel Report. There are several of these re-ports under such names as the Products, Campaign, Purchase, Cart and Custom Events Conversion Funnel.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


This report is also customizable so that you can add Custom Conversion Events to this Conversion Funnel to see if visitors to your site make it from one step to the next.

Generally, Success Events are good candidates for this type of Conversion Funnel Analysis if they almost always occur linearly, i.e., in a specific order. For example, on a Retail site, Success Events generally occur in this order: Product Views, Cart Additions, Checkouts, Purchases. If you have a linear conversion processes on your site, try out the Conversion Funnel.

Site Exercise 9.1 Custom Events



• Understand the JJ Newsletter Sign Up conversion rate


• Number of Newsletter Subscription Starts• Number of Newsletter Subscription Completions

Assignment:

Code the “JJ Newsletter Subscription” pages in the Company Site Section with the proper custom event(s) to count all Newsletter Subscription Starts and Completions.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

10-1

Chapter Ten

Conversion Variables

Objectives

• Learn about how Conversion Variables work• Apply SiteCatalyst events to the products variable• Understand how Conversion Metrics are applied to Conversion Variables• Learn the names of Predefined and Custom Conversion Variables

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The Purpose of Conversion Variables

The Persistent VariableConversion Variables are one of four variable types in SiteCatalyst (Traffic, Conversion, Configuration and Automatic Variables). Conversion Variables are used to capture conversion data in SiteCatalyst. They are persistent variables and thus can hold values between pages and visits.

There are two main types of Conversion Variables:

1. The s.events variable (used to capture Conversion Metrics).2. All other conversion variables (used to capture values).

As we learned from the last chapter, s.events is a Conversion Variable.; however, from here on, “Conversion Variables” will refer to any of the available Conversion Variables except the s.events variable. We’ll refer to the s.events variable and any accepted val-ues or metrics as “Success Events” or “Conversion Metrics.”

Following is a list of the basic purposes of all of the conversion variables, including the events variable.

The available conversion variables are defined as follows:Predefined Eventss.events

Adobe offers predefined events that you can use in con-junction with your products and shopping cart to create eight metrics. For example, the predefined events track products as they move through the check-out process.

Custom Eventss.events

SiteCatalyst enables you to track any custom success event that you want to measure. For example, shipping is not part of the predefined check-out process, but you can add it as a custom event.

Productss.products

The products variable is used for tracking products and product categories as well as purchase quantity and pur-chase price.

Purchase IDs.purchaseID

The purchaseID is used to keep an order from being counted twice by SiteCatalyst. Whenever the purchase event is used on your site, you should use the purchaseID variable.

Transaction IDs.transactionID

Data Sources utilize a transaction ID to tie offline data (like loan approval or product return) to an online trans-action (like a lead or purchase generated online).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Statess.state

The state variable enables you to determine the amount of conversion your site generates from a particular U.S. state or province.

Zip/Postal Codes.zip

The zip variable enables you to determine the amount of conversion your site generates from a particular U.S. zip/postal code.

Tracking Codes.campaign

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

Custom eVarss.eVar1-75

s.eVars (or Custom Conversion Variables) are used to identify how well specific attributes or actions contribute to success events on your site.

What Can Conversion Variables Do For My Reporting?

Conversion Variables are either Predefined or Custom Conversion Variables describ-ing what led to the conversion. They contain the “who, which, or what” actually con-verted (i.e., performed the conversion event). Consider the following examples:

In the first example, the Success Event is the Order. It is the desired conversion activ-ity. The Campaign is the Conversion Variable, or the “who, which or what” that af-fected success. For example, my campaign may have been the “Get 50% off today” sale. We tie Conversion Variables values to the Success Event or Conversion Metric (in this case “Orders”) so that you can see that one of the Orders came from someone that clicked through one of our online campaigns called “Get 50% off today.” Looks like that campaign is giving us some return on our investment!

In the second example, the Success Event is the Form Completion, and the Conversion Variable is the User Type (populated into the variable by your site’s own scripting logic that determines what kind of user the visitor happens to be).

Right now, this may make sense. “Right, I get it”, you might be thinking, “the Conversion Variable is the Line Item value in the report and the Event is the Conversion Metric by which I sort my report.” If you said that, you’d be right; however, you may soon forget and mix up the two. Perhaps, to use a grammatical metaphor, an easier way to remem-ber this concept is to think of the Conversion Variable as the noun (the “who, which

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


or what” such as Campaign Name or User Type) and the Event as the verb (the thing that happened, the action or conversion such as Purchase or Form Completion).

As you can see from this scenario, Conversion Variables persist with your visitor so that they can be tied to conversions (Conversion Metrics) so that you and your analysts can know what was responsible for the conversion. Pretty cool, eh? Keep in mind that each Conversion Variable can have a different expiration period.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The Product Variable and Events

With each Retail event, you must specify the product that is viewed, the product that is checked out, or the product that is purchased, etc. You will do so through the Conversion Variable called the Products Variable. If you tell SiteCatalyst that you are making a purchase, it only makes sense that you should state which product(s) you are purchasing (the same goes for products being viewed or which are in the cart when you start the check out process).

The Retail Predefined Event must be specified on the same page as the Products Variable. The Products Variable does not persist across pages. You may also specify a product when you set a Custom Event, but it is not required.

s.products SyntaxThe following is the full syntax for the products variable:

s.products=”Category;Product;Qty;TotalPrice;Incrementor;

Merchandising”

Not all fields are used for all events, and each usage is discussed in the following sec-tion. The Product Variable itself can contain many products, but the Category Field and the Product Name Field each have a limit of 100 bytes. The delimiter between fields is the semicolon (“;”) and the delimiter between two or more products is the comma (“,”).

If somebody buys 100 products, there is certainly no limit on the number of charac-ters that can be pushed into the product string as long as none of the previous limita-tions are broken; however, most browsers such as Internet Explorer have a URL limit of 2083 characters for the SiteCatalyst image request. If you feel there are cases where your implementation may exceed such limits, contact Client Care or Adobe Consulting to discuss alternatives.

The Category FieldThe Category Field is the first field in the Products Variable. This field is deprecated, or no longer used in most implementations. This is because a new feature that eclipses the category solution has been created. This feature is called “Classifications” and gives you the opportunity to report on products in any kind of groups that you want (you can even change your categories retroactively with Classifications). You can cre-ate product hierarchies, so that you can understand which product groups are selling best on your site. This feature is not only for products, but is very often used for

s.products capture multiple products on the same page (in one image request), capture revenue, units, incrementor and merchandising values, a retail event should be coded on the same page, product field limited to 100 bytes, populates the products report

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


products, so it deserves a mention here. This feature will be discussed more in Section Four of this workbook.

The examples show in this course will sometimes use a category in the product string and sometimes will not. Either of these use cases is legitimate.

When using the Products Variable, different events and situations warrant usage of different fields. These situations can be broken down into the following:

• General Use• Purchase• Event Incrementor• Merchandising

The relationship between these scenarios and the products string fields is illustrated in the following image.

General Use (Non-Purchase) ComponentThe previous example shows that the semicolon (;) is the standard separator between each of the components. The same general format is used for non-purchase use as shown below.

s.events=“prodView”

s.products=“;Running Shoe”

In this case, the category and product are added to the product string (Category Field is left blank), and prodView event is added to the Events Variable. Each time the prod-uct name is set into the s.products variable with the prodView event, the Product View metric will be incremented for that product.

Similarly, if you want to track a product, but not the category, you can leave that field blank. Don’t forget to include the semicolon as a placeholder denoting the blank cat-egory, as shown below.


s.products=“;Running Shoe”

The most common events populated with a product name are:

• prodView• scAdd

NOTE: Product attributes (fields) are

separated by semicolons. Multiple products are separated by commas. Make sure that your product names contain neither semicolons nor commas.

WARNING: Although Adobe does not impose

a size limit on s.products, some browsers like IE impose a size limit on the URL of the SiteCatalyst image request. The limit is 2083 characters. Additionally, the “Product” and “Category” fields of s.products each have a limit of 100 bytes.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• scCheckout

Just as valid, but lesser used events include:

• scOpen• scView• scRemove

Product GranularityAs you start putting products into SiteCatalyst, the question will often come up, “Should I track every single product, including size, color, etc.?” This question of product granu-larity is usually only an issue for Retail sites, especially when speaking of parent and child SKU, but it can also apply to other site types that use the products variable.

The general rule for this situation is that you should track products at the most granu-lar level that you will ever want to analyze in SiteCatalyst reports, without going over the unique values limit of 500,000 different products per month. If you have more than 500,000 products that could be purchased on your site, please contact an Adobe Consulting representative to discuss options.

As discussed earlier, you will be able to use a feature called “Classifications” to put the products into groups, so that you can retrieve higher-level product data from SiteCatalyst, such as whether men’s shoes typically sell as well as women’s shoes (not likely).

Since we recommend using “Classifications” to group your products, we also recom-mend that you set the product SKU in the Product Name Field. Using “Classifications”, you can rename your products. We recommend using the SKU since product names can change or even your CMS can change the names of products even just slightly.

s.events=“prodView

s.products=“;24353234”

The following example touches on the steps through which the visitor passes during the shopping cart process (final purchase not included, since it hasn’t been covered yet). The Product Variable is used for tracking products and product categories. A Success Event should always be set in conjunction with the Products Variable.

Example 1

Detailed Product View Page


s.products=“activewear;ski jacket(54321)”

TIP: Use product SKU or ID, then upload

meta data using SAINT Classifications. For example, for SKU 24353234 you could upload “Ski Jacket”, “XL” and “Blue” for three Clasification reports like Product Name, Product Size and Product Color, respectively.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Shopping Cart page (scOpen, scView, scAdd, scRemove)

s.events=“scOpen,scAdd”


First Checkout page

s.events=“scCheckout”


Example 2

Detailed Product View Page



Shopping Cart page (scOpen, scView, scAdd, scRemove)

s.events=“scOpen,scAdd”


First Checkout page

s.events=“scCheckout”


Note: Going forward, use the SKU and leave the Category blank as shown here in Example 2. It’s already been said, but note how each page in our example couples an event with a product. A product should always be accompanied by an event (the met-ric). If you populate s.products with a value, but forget to set an event in s.events, SiteCatalyst automatically fires off a prodView event for you. Best practice: associate correct metrics with your products by coding properly to begin with (and don’t let us fire off the default prodView metric).

Retail Events Challenges

Some Retail events are infrequently used because some Adobe clients, because of site functionality, have no way to implement these events.

• scOpen — Sometimes the scOpen event is not used on a Retail site because it can be difficult to track a “new” cart especially since carts may be held between sessions; however, please implement this if it applies to your site.

• scRemove — The scRemove event can be difficult to implement with scAdd if the visitor can update the cart for multiple products at once (add and remove products at the same time). Events that are set in s.events apply to all products set into s.products. So if you add product A and remove product B on the same page, and then throw an scAdd and an scRemove event on the same page, both events would apply to both products. There are other ways to work with situations like this, using what is called an event “incrementor.” This will be discussed later in the chapter.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The Shopping Cart Conversion FunnelJust as with the Custom Events, SiteCatalyst will automatically calculate the conver-sion ratios between the Predefined Retail Events. Again, this is shown in a customiz-able funnel-type report in SiteCatalyst.

In addition to the Conversion Metrics based off of Retail events, you can now see these numbers PER PRODUCT, because the products were sent into SiteCatalyst on the same page as the Retail event. Running a Products Report in SiteCatalyst and adding the appropriate Conversion Metrics gives you the ability to see product-specific con-version data.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Additional Event ExamplesHere are some additional examples of using Custom Events and Predefined Retail Events on multiple site types.

Step 1: Identify Conversion Events

Example 1: Travel and Hotel Industry• View Destination (Hotel) Packages > Enter Travel Dates > Review Order >

Confirm Order

Example 2: Banking Industry• View Banking Products > Online Banking Form > Form Confirmation

Example 3: Auto Industry• View Model > Complete Dealer Request Info Page > Request Info Confirmation

Example 4: Lead Generation• Request for Information > Form Confirmation

Example 5: Subscription Service• View Subscription Options > Subscription Form Start > Form Completion

Step 2: Assign Events to Pages

Example 1: Travel and Hotel industry, using the standard shopping cart events.• View Destination (Hotel) Packages = prodView• Enter Travel Dates = scAdd• Review Order = checkout• Confirm Order = purchase

Example 2: Banking industry, using a combination of predefined eCommerce events and custom events.

• View Banking Products = prodView• Complete Online Banking Form = event1• Success Confirmation = event2

Example 3: Auto industry, using a combination of predefined eCommerce events and custom events.

• View Model = prodView• Complete Dealer Request Info Page = event1• Success Confirmation = event2

Example 4: General content site where the user can register for access or complete an interest form, using just custom events.

• Request for Information = event1• Success Confirmation = event2

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Example 5: Media site where the user can request different email newsletters that cater to the visitor’s interests.

• View Subscription Options = prodView• Subscription Form Start = event1• Form Complete = event2

Step 3: Tag Pages with Events

Example 1: Travel and Hotel industry, using the standard shopping cart events.

• View Destination (Hotel) Packages page s.events=“prodView”;

• Enter Travel Dates page s.events=“scAdd”;

• Review Order page s.events=“scCheckout”;

• Confirm Order page s.events=“purchase”;

Example 2: Banking industry, using a combination of predefined eCommerce events and custom events.

• View Banking page s.events=“prodView”;

• Complete Online Banking page s.events=“event1”;

• Success Confirmation page s.events=“event2”;

Example 3: Auto industry, using a combination of predefined eCommerce events and custom events.

• View Model page s.events=“prodView”;

• Complete Dealer Request Info Page s.events=“event1”;

• Success Confirmation s.events=“event2”;

Example 4: General content site where the user can register for access or complete an interest form, using just custom events.

• Request for Information page s.events=“event1”;

• Success Confirmation page s.events=“event2”;

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Example 5: Media site where the user can request different email newsletters that cater to the visitor’s interests.

• Newsletter Subscription pages s.events=“prodView”;

• Newsletter Subscription Form Start Pages.events=“event1”;

• Newsletter Subscription Form Completion Page s.events=“event2”;

Site Exercise 10.1 The Checkout Process



• Understand and improve purchase behavior at each step of Checkout• Maximize checkout process conversion


• Record “Product Views” by product• Record “Cart Adds” by product• Record “Checkouts” by product• Record “Shipping Info” form completion by product • Record “Payment Info” form completion by product

Assignment:

Code for the following scenario on the JJ Esquire Web site:

A visitor views the “Military Jacket” in Men’s Activewear, adds it to the Cart, Checks out and completes the shipping and payment information pages.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

11-1

Chapter Eleven

The Purchase Confirmation Page

Objectives

• Learn how to set the Products Variable for one or more purchases• Use additional predefined variables in conjunction with s.products• Properly set the incrementor value in s.products

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Coding the Purchase

OverviewThe Confirmation Page is located at the end of the order process. Its primary purpose is to confirm the purchase you have made. Even though you can use the Products Variable on any page of your Web site, the Confirmation Page is the page where the most of the fields of the product string are used. These fields are discussed in this section.

Purchase Component

The Purchase Event should be set on the Final Confirmation (“Thank You”) Page of the order process after the order has been finalized. On this page, the product name, category (optional), quantity and price are all captured in the Products Variable, as shown below.

s.products=”Category;Product;Qty;TotalPrice”

As you have possibly noticed, the previous examples have not used the quantity and price fields of the product string. These two fields are specified only at purchase. If it is easier to implement Quantity and Total Price with all events, the s.products values will still be accepted, but the Quantity and Total Price fields will be ignored with all events except for the Purchase Event. For a Retail site, the Purchase Event is the most important because Revenue, Orders and Units come from this event. All other re-ports, like Campaigns, Traffic Sources and Custom Segments get credited with Revenue, Orders and Units because of the Purchase Event.

Multiple ProductsIf a customer on your site purchased multiple products, you can submit them all through the Products Variable by using a comma separator, as shown in the example below.

Example syntax:

s.events=”purchase“

s.products=“Cat;Prod;Qty;Price[,Cat;Prod;Qty;Price]”

s.events=”purchase“

s.products=“;100240;1;1849.99,;100233;1;650”

Please note that you MUST use a period (“.”) as the Decimal Separator when you pass in currency, even if it is customary to use a comma in your country. You can display

NOTE: An event should accompany

s.products each time it is set on a page.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


the currencies with alternate Decimal and Thousands Separators by adjusting My Account>Report Settings.

Example syntax for price in the Product Variable:

• Good: 1849.99 • Bad: 1849,99 • Bad: 1,849.99 • Bad: 1.849,99

Using the multiple products syntax also applies to other events, such as the general usage events discussed earlier in the chapter. For example, if you have a checkout with the two products listed above, you could populate the variables as follows:

s.events=”scCheckout”

s.products=“;100240,;100233”

Additional Purchase VariablesThe Purchase Event populates Orders, Units, and Revenue metrics. When you set the Purchase Event, the following variables can be or should be set (depending on wheth-er or not they are required, highly recommended or optional).

• s.events (Required)• s.products (Required)• s.purchaseID (Highly Recommended)• s.state (Optional)• s.zip (Optional)• s.transactionID (Optional)

The first two variables (s.events and s.products) were discussed earlier in this chapter. The purchaseID, state, zip and transactionID variables are discussed next. For more information on these or other variables, refer to the online Implementation Manual.

The s.purchaseID Variable

The s.purchaseID variable is used to keep an order from being counted twice by SiteCatalyst. It is the method used to serialize the Purchase Event. Every time the Purchase Event is set on your site, you should use the s.purchaseID variable. If the s.purchaseID is populated, the products on the “Thank You” page will only be count-ed once per s.purchaseID. Setting it is critical because visitors to your site may save the “Thank You” or “Confirmation” page and refer to it later thus re-executing the Purchase Event. If you do not use the s.purchaseID variable, when the visitor returns to the page, another Purchase Event will be sent to SiteCatalyst via an image request giving your analysts erroneous data. Although the s.purchaseID variable is not required, it is strongly recommended in order to prevent duplicate orders on the purchase page. The s.purchaseID is most commonly set to the order ID already on your site (set s.purchaseID to a unique val-ue). Using the order ID makes sense since most are unique thus you don’t have to manage two different IDs.

s.purchaseiD serializes the purchase event, limited to 20 bytes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


If your order ID is longer than the s.purchaseID size limit (20 bytes), you should fig-ure out a way to shorten it while still keeping it unique to the order.

s.purchaseID Variable Limitations

The s.purchaseID variable has a different size limitation than most of the other vari-ables. While most of the variables in SiteCatalyst can accept 100 bytes, the s.purchaseID variable is limited to 20 bytes or less, and must be standard ASCII. The following code shows examples of the s.purchaseID variable.

s.purchaseID=”11223344”

s.purchaseID=”a8g784hjq1mnp3”

s.transaction ID

The s.transactionID variable makes it possible to tie offline data to online transac-tions. Let’s suppose that someone applies for a loan today, but we can’t approve it for a couple of days. Once we approve it, we can upload the Approval data (offline data) to the Loan Submission data (online data) via a tool called Data Sources (discussed in Section Four).

Why go through all this work? Well, there are other values associated with the origi-nal online Loan Submission such as a Campaign and Campaign costs that influenced the visitor to apply for the loan. The s.transactionID makes it possible to tie the entire conversion process together.

The same goes for a Retail site. Let’s suppose that someone clicks through a Google Text Ad that cost us $2.00 per click and then bought an item for $10.00 (online). Later, we find out they returned the item (offline) two weeks later. If we have set a transac-tion ID on the original online purchase, we can deduct credit two weeks later from the original purchase to understand the true cost of our Campaign (it didn’t give us the Return on Investment we’d previously calculated before the return). This s.transactionID stuff is pretty cool and important because it, as said before, ties to-gether the whole conversion process.

s.transactionID Variable Limitations

The s.transactionID variable, like s.purchaseID, is limited to alphanumeric ASCII text. It can be up to 100 bytes in size. The variable must be enabled by Adobe Client Care. If it hasn’t been enabled, contact Client Care to turn it on. You can see if the variable has already been enabled through the Admin>Data Sources>Manage section.

Example syntax:

s.transactionID=“1234abcd”

s.transactionID=s.purchaseID

s.transactionID optional identifier used to tie offline data to online transactions, limited to 100 bytes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Event Serialization (Keeping Events Unique)While on the subject of keeping events from being falsely duplicated, you also need to know how to keep the Custom Events from being duplicated. This is called “event se-rialization.” As discussed above, the Purchase Event has its own variable for serializa-tion. Custom Events use a slightly different, but easy, method to prevent unwanted duplication. Event serialization is very useful in the following instances.

• A page may be reloaded or refreshed, which repeatedly sends an event to SiteCatalyst. Event serialization prevents events from being recounted by using a “serial number” for each event.

• The user saves the page to his or her machine for later review—a scenario that is quite common on purchase confirmation pages to review purchase receipts. Event serialization prevents the subsequent page reloads from re-counting the events.

The following code example shows how to implement event serialization.

s.events=“event1:1234abcd”

Syntax for three simultaneous events (one of which is serialized):

s.events=“event2,event1:1234abcd,purchase”

In this case, the value of “1234abcd” causes the event to only be counted once. Any other attempts to pass in “event1” with the same serial number will not be recognized and not counted in the reports to prevent duplication. If s.events only contains a value of “event1,” the value could be passed multiple times and falsely inflate the numbers in the reports.

This Event Serialization is not always used as often as it is for the Purchase Event be-cause you have to create and maintain a unique list of IDs to be used for this purpose. The cost and hassle of doing this may override your need to avoid a few extra registra-tions being counted by reloads (for example).

Event Serialization must be enabled by Adobe Client Care for the event of your choice. The “serial number” must not be more than 20 bytes and is alphanumeric standard ASCII text. Client Care can also set the event, configured on the back end, to record only once per visit without using a Unique ID (use with caution for events that can occur more than once per visit such as purchase, form submission, etc.).

Visitor Profile InformationThe State and Zip Variables are Conversion Variables. They are similar to s.eVars in that they capture events, but unlike s.eVars, they don’t persist for more than a page.

Since 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 ex-ample, if you are using s.state to compare conversion rates by state, you should popu-late the s.state variable on every event page of the checkout process.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


For Retail sites, Adobe recommends using the billing address as the source for the Postal Code, but you may choose to use the shipping address instead (assuming there is only one shipping address for the order).

The s.state and s.zip variables are each limited to 50 bytes of alphanumeric ASCII text. Multi-byte characters are acceptable if the Report Suite and s.charSet have both been properly configured. Examples of the state and zip variables are shown here:

s.states.state=“California”

s.state=“Surrey,UK”

s.state=“Paraná”

s.state=“Sector 7”

s.zips.zip=“84097”

s.zip=“C1A 7J6”

s.zip=“TW20 9AW”

s.zip=“95082-380”

As you can see, even though these variables are called “s.state” and “s.zip,” their origi-nally United States-centric names do not preclude you from populating local geo-graphic data. You can place ANY value in them, and those values will tie to any event that was coded on the same page. In theory, they could be completely repurposed and even renamed in the interface.

The values that you populate into the Zip report will show in the Visitor Profile > Visitor Zip/Postal Code report, as in the following example:

s.state and s.zip geographic identifiers populated during checkout process, limited to 50 bytes each

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Likewise, the values that go into the s.state variable will show in the Visitor Profile > Visitor States Report. Without populating these variables, the associated reports will be left empty (they are not populated automatically like the Traffic Geosegmentation reports that calculate location from the visitor’s IP address).

Option to Automatically Populate s.zip

You can request that Adobe ClientCare enable s.zip to be populated automatically with a Postal Code using Adobe GeoSegmentation data. You can request that GeoSegmentation data always populate s.zip or only populate s.zip when s.zip is emp-ty. Contact Adobe ClientCare for more information.

Site Exercise 11.1 Multiple Products



• Ability to track multiple item orders at the product level from browsing to final purchase

• Track shopping cart conversion• Ensure that orders are only counted once• Make it possible to later link offline data to this online transaction• Ability to track orders and revenue by state and zip


• Cart Adds, Checkouts, Shipping Complete, Payment Complete, Orders, Revenue and Units by Product, State and Zip

Assignment:

Code for the following scenario for the Final Confirmation Page:

• Visitor purchases one (1) Black Dress and two (2) Red Dresses from “Women:Fine Apparel”

• Order number is 123456789• Billing state is California and zip is 92121Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


Event Incrementor ComponentThe Event Incrementor feature allows you to specify a custom number or currency for specific products (only applies to one product even if many are being purchased at the same time). The incrementor is most often used for tax or postage fees.

The Event Incrementor is the 5th field in the product string. An example of settin the incrementor appears below.

s.products=”Cat;Prod;Qty;Price;eventN=Increment Amount”

By default, Success Events are configured as “Counter” type events (as discussed ear-lier). Counter Events simply count the number of times a Success Event is set. When using the Event Incrementor field, you will generally need to increment the event by some custom amount (more than the Counter default of one).

To accomplish this, you should change the Event Type to either “Numeric” or “Currency” when incrementing via the product string (done in the Admin Console as previously discussed). Because the incremented amount is set in the product string, the incrementor only applies to individual products. This means, in the case of sales tax, that you could apply a different sales tax value to each product even if 5 products were being purchased at the same time.

Common Uses

Some of the most common uses for incrementors include:

• Tax per product• Postage per product• Cart revenue (to calculate lost revenue by abandons)

Examples

The following examples show different uses of the Event Incrementor, including with multiple events or products.

Single Products Example

s.events=”purchase,event5”

s.products=”;Product;1;9.99;event5=1.86”

Multiple Events example

s.events=”purchase,event5,event6”

s.products=”;Product;1;9.99;event5=1.86|event6=2.50”

Multiple Products example

s.events=”purchase,event5”

s.products=”;Product1;1;9.99;event5=1.86,;Product2;2;19.98;

event5=4.25”

When adding multiple Event Incrementors to one product, as seen in the Multiple Events example, delimit the Event Incrementor values with a pipe character (“|”).

NOTE: When you enable an event, set

the Event Type based on the kind of Conversion Event that you are defining. The three possible Event Types are Counter, Currency and Numeric.Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


Exercise 11.2 Event Incrementor



• Track Postage and Sales Tax for products purchased

Key Performance Indicators• Postage and Sales Tax by product and all other associated conversion variables

Assignment:

Assume that you are coding on the JJ Esquire Germany site. Code for the following scenario on the Order Confirmation page:

• Visitors purchases Red Dress (SKU 101341) for 3.499,99 € • Postage cost = 4,50 € and tax (VAT) = 6,19 €• Order ID is 987654321• Billing state is Nordrhein-Westfalen and postal code is 40547

Note: Assume that the Euro has already been set as the Report Suite default currency.

Exercise 11.3 Event Incrementor with multiple products



• Track product sales on the site by SKU, including customer location, postage costs and sales tax


• Revenue for multiple item orders by product SKU, State and Zip• Postage and tax by product

Note: Where applicable, use the same events from the previous exercise.

Assignment:

Assume you are coding on the JJ Esquire Japan site. Code for the following scenario on the Order Confirmation page:

• Visitor purchases two (2) Sport Jackets (SKU 200244) for ¥22,000• Postage is ¥400 and Sales Tax is ¥1,100 for each unit• Visitor purchases one (1) Hooded Sweater (SKU 200233) for ¥42,500• Postage is ¥250 and Sales Tax is ¥2,100• Order ID is 1234abcd• Billing prefecture is Kansai and city is Osaka (use s.state and s.zip, respectively)

Note: Assume that the Yen has already been set as the Report Suite default currency.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Product String SummarySo far you have learned about all of the events, and almost all of the components of the products variable. As a reminder, here is the total product string syntax:

s.products=”Category;Product;Qty;TotalPrice;

Incrementor;Merchandising”

You have learned that different fields of the product string are used at different times, including general use, purchases, and custom incremented events. The only one left to discuss is the Merchandising component. This will be discussed later in this section. Don’t worry, you’ll get there!

Products ReviewHere are some additional points to remember as you work with products:

• If a value is not used, keep the semi-colon ( ; ) as a placeholder.• Remove commas, semicolons, special characters from category and product

name.• Category field in product string has been deprecated (use “Classifications” for

grouping - coming up later).• Tax, Postage, other numbers can be increased via the incrementor field.• Use product SKU number if not too granular (500,000 SiteCatalyst limit).• Always use s.purchaseID with Purchase Event to ensure the most correct

numbers.• Use s.transactionID if you need to tie post-transaction data to the online

transaction (call Client Care to enable transactionID).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

12-1

Chapter Twelve

The Campaign Variable

Objectives

• Learn how to measure Campaign effectiveness• Understand how to set Campaign expiration and allocation• Install the getQueryParam Plug-in

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


It’s All About the Tracking Code

OverviewA campaign is a marketing effort that is used to accomplish the following objectives:

• Drive more qualified traffic to the site. • Improve campaign effectiveness (spend less per conversion).• Track Return on Ad Spend on all paid advertising.• Track a key segment’s interaction with campaigns.

Campaign 101: tracking marketing successHow do we get people do the site? Through one of many different marketing strate-gies. Perhaps we have Text Ads, Partner Referrals, Banners, Emails, Direct Mail or Viral Marketing working in our favor to bring new qualified traffic to our site. Once visitors land on one of our entry pages, we hope that our site leads them to peruse our offerings and eventual complete a Success Event of some type. These conversions on our site could be such things as a purchase, subscription, registration, download or submitting a lead.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Why do we track our campaigns? Because we want to know how much conversion we get from certain campaigns. By knowing this, we can make better judgments about how to spend our marketing funds on future campaigns. In order to tie the Success Events on your site to the Tracking Codes of all of your creatives, we first have to cap-ture the Tracking Code.

Capturing Tracking CodesThe first step in campaign management is to identify and capture each unique Campaign ID, also called a Tracking Code. There are two basic ways to capture the Tracking Codes. The first (and less common) way is to hard-code the Tracking Code to a specific landing page as shown in the following example.

s.campaign=“tracking code”

s.campaign=“radio_spot_xyz”

In the example above, the Tracking Code “radio_spot_xyz” is set directly into the s.campaign variable. In this case, any time a visitor accesses the radio_spot_xyz cam-paign landing page, a click-through will be reported by SiteCatalyst. However, this method is really only recommended for offline ads (such as radio or print ads that ask visitors to go to a vanity URL of some type that leads them to the landing page).

For online ads, the most common method to track a campaign click-through is to ac-cess the “Tracking Code” in the query string of the URL. This Tracking Code value is set by you when creating the campaign’s destination link. The following two examples show how that could be set.

The getQueryParam Plug-In

When someone lands on your site with this “Tracking Code” in the URL, you can dynamically extract it and place it into the s.campaign variable. You can create a script to do this yourself if you want to, but SiteCatalyst provides a JavaScript function espe-cially for this purpose. This function is one of many functions referred to as “plug-ins.” For your reference, the plug-in that extracts the Tracking Code from the query string and sets it into s.campaign is called getQueryParam and is available on your fictitious JJ Esquire Web site in the Company>White Papers section as well as in the Adobe SiteCatalyst Help section.

s.campaign populates the tracking code report, expiration and allocation set in the admin console, limited to 255 bytes

getQueryParam Set in the Global JS file

(s_code.js), it automatically checks the query string for a specific field parameter and automatically populates the value of the parameter into s.campaign. The plug-in can be used with other SiteCatalyst variables.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Within the query string of one of your campaign creatives you will find two things: a Query String Parameter and the Tracking Code. The Query String Parameter, such as “cid”, is an arbitrary value that tells the getQueryParam plug-in that a Tracking Code is present in the query string. If you’ve never set Tracking Codes before, we suggest choosing one Query String Parameter for your external campaigns. You don’t need to choose more than one in most cases. It can be applied to your email, search engine and display campaigns.

Assume that you have decided to use “cid” as the Query String Parameter name. Your campaign link to your site then might look like this:

If that is the case, then the call to the JavaScript plug-in would look for the “cid” pa-rameter and populate the s.campaign variable with its value (in this case, it’s the “ab1234” value.

This is set in the Global JavaScript File (s_code.js) so that you don’t have to set it on every campaign landing page:

s.campaign=s.getQueryParam(‘cid’);

The resultant code would look like this, although you won’t see this on any page:s.campaign=“ab1234”

The getQueryParam code is actually set in the Plug-ins area of the Global JavaScript File. This one line of code will cover situations where people land on any page of your

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


site. Just make sure that Tracking Codes in destination URLs are preceded by the Query String Parameter. That’s it! Simple implementation!

s.campaign Limitations

The s.campaign variable is a Predefined Custom Conversion Variable. It has the fol-lowing limitations:

1. It is limited to 255 bytes of data.2. It is “first time case sensitive.” This means it stores the initial case, but are

then case insensitive. (Initially, you send in “aBc”, and afterward it is credited for any versions of abc, ABC, Abc, aBc, etc.)

All Custom Conversion Variables possess these same limitations. We’ll talk about those (s.eVars) in the next chapter.

Assigning Conversion Credit Across VisitsAlthough this part has less to do with what you will be doing as a technical consultant, it is good for you to know how these variables work. The s.campaign has a persistence and allocation value that can be adjusted in the Admin Console (and just so you know, the Custom Conversion Variables behave in the same manner and have the same functionality).

For example, when someone lands on your site after having clicked on a banner, SiteCatalyst will assign credit to the banner when they convert; however, the conver-sion may not happen on the same visit. Therefore, you need to be able to assign this credit across visits. SiteCatalyst can do this. Here is an example of the value flow in a situation like the one just described.

As you can see here, when someone lands on the page, you DON’T have to worry about persisting that value across pages. SiteCatalyst will hold it for a given period of

TiP: Proper expiration and allocation settings

greatly depend on your site’s Conversion Cycle. Discuss this with the Business Analysts if in doubt. The Tracking Code can be set into multiple Conversion Variables if multiple expiration periods or allocations are required for optimum analysis.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


time that you set to give credit for the purchase (or other conversion activity) to the banner that was originally clicked.

The SiteCatalyst Admin at your company will usually decide on and set the proper settings. The settings are easily accessible in the Admin console, and credit can be given for any period of time (visit, page view, never, week, month, 9 days, etc). Credit allocation can be set to the most recent campaign clicked or the first one that was clicked (in the case that a visitor clicks through more than one campaign).

eVars expire based on the time they were set, to the second (minute, hour, day, month, etc).

• MINUTE=60 seconds• HOUR=3600 seconds (60 minutes)• DAY=86400 seconds (24 hours)• WEEK=604800 seconds (7 days)• MONTH=2678400 seconds (31 days)• QUARTER=8035200 seconds (93 days - 3 months of 31 days)• YEAR=31536000 seconds (365 days)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


If a visit starts at 7:00 AM on Monday and an eVar is set within that visit at 7:15 AM, expiration is as shown below.

• Day expiration - expires at 7:15 AM on Tuesday.• Week expiration - expires on the following Monday at 7:15 AM.• Month expiration - expires 31 days from Monday at 7:15 AM.

Internal vs. External CampaignsThe difference between an Internal Campaign (or promotion) and an External Campaign is placement of the campaign. An Internal Campaign drives traffic to one part of your Web site from another part of your Web site, or is a “call to action” of some kind. An External Campaign drives traffic from another source completely outside of your Web site.

Though Internal and External Campaigns are similar, they should be tracked differ-ently. Internal Campaigns should be tracked with a Custom Conversion Variable (dis-cussed in the next chapter), and External promotions should be tracked with the Campaign Variable. If you were to assign both to the Campaign Variable, the internal value would overwrite the external value when it is passed if Campaign Allocation were set to always give credit to the most recent value. By coding them into different variables, the internal and external values will be tracked separately, and won’t com-pete for the conversion (compete for allocation or credit).

Exercise 12.1 Campaign Tracking



• Track Return on Ad Spend on all online paid advertising including online efforts (banners, emails, paid search, affiliates)

• Track Return on Ad Spend for offline campaigns (radio)


• Click-throughs and Conversion Events for online external campaigns • Click-throughs and Conversion Events for offline radio ads with special landing

page

Assignment:


Solution

TiP: Set Internal and External Tracking

Codes into separate Conversion Variables so that they don’t fight for allocation (credit for conversions).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Example

Implementation

Site Exercise 12.2 Campaign Tracking with getQueryParam





• Click throughs and Conversion Events for online external campaigns

Assignment:

Install the getQueryParam plug-in in your s_code.js file and verify that Tracking Codes are populating s.campaign (getQueryParam available in “Company:White Papers”).

To verify that Tracking Codes are populating, go to the “Search Engine Page” (link available on the “Site Map”) and click through the “JJ Esquire Ski Sale” add. The Tracking Code is “jj_ski_sale”.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

13-1

Chapter Thirteen

Custom Conversion Variables

Objectives

• Revisit how Custom Conversion variables work• Learn about common uses for Custom Conversion variables• Use the getQueryParam plug-in to capture internal tracking codes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


s.eVars for Custom Tracking

OverviewOften as people learn SiteCatalyst, they confuse s.eVars with Conversion Events or they don’t understand when to use an s.prop and when to use an s.eVar.

First of all, the only thing that s.eVars really have in common with s.props is that they are both Custom Variables. Just as s.props are Custom Traffic Variables, s.eVars are Custom Conversion Variables. That’s about where the similarities end, however, as they really are two completely different animals in terms of what kinds of information they provide and in how they behave.

But the fact remains, just as with Custom Traffic Variables, that these Custom Conversion Variables give you custom information, allowing you to answer your cus-tom questions for your chosen segments.

This is very important when considering segmentation because it allows you to seg-ment your key visitors and understand conversion by these key segments (and not just conversion for your site visitors as a whole).

“s.Evars” or “s.eVars”?

In our literature, we use eVar or s.eVar. In some of our older literature or perhaps on SiteCatalyst blogs out on the net, you might see users write “Evar”. In the code, you should always use the latter capitalization: s.eVar (if not, the SiteCatalyst code will fail). You will see code that looks like this:

s.eVar1=“x”; In the SiteCatalyst menu navigation, you will see the folders entitled “Custom Conversion 1-10” and reports called “Custom eVar 9” as an example. These reports can be renamed by you in the same way that you can rename your Custom Traffic Reports.

How s.eVars WorkUnlike a Traffic Variable that must set it on every page, Conversion Variables are per-sistent variables and hold their value for longer than one page. You decide how long they hold their value by configuring the Conversion Variable settings in the Admin Console. Generally, the expiration period that you set for any one of your Custom Conversion Variables depends on the Conversion Cycle. Each Success Event complet-ed (or conversion) is credited to all Conversion Variable values that are still associated

s.eVar populates custom conversion reports, also called a custom conversion variable, expiration and allocation set in admin console, limited to 255 bytes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


(or stuck to) the visitor. Think back to our example at the beginning of the section with the bespectacled visitor that purchased some sensible shoes.

Conversion Reports are used to answer questions about what led to conversion on the site. For example, if I’d like to see what type of Internal Campaigns on my Home Page may spawn purchases, I’ll need to first capture the Internal Tracking Codes and set persistence to a period of one visit for the s.eVar that captures the Internal Campaigns. When a Success Event is completed (like purchase), the credit for that success is given to any Conversion Variables that are still “stuck” to the visitor such as Internal Campaign ID. By running the Internal Campaign report, we can see which campaign generated the most onsite conversion.

In the example above, you can see that on Page 2 a person logs in. That value of “Logged In” can be held indefinitely, to see if there is ultimately a conversion. When there is (as seen on Page 4), the “Logged In” status receives credit for one conversion. Remember, this conversion can be any Success Event. What kind of reporting could we get from this? Things like Registrations for logged in or not logged in status, Form Completions by people who were logged in or not, or Revenue generated by people who were logged in or not.

Conversion Variable UseMeasure how conversion values relate to conversion metrics:

• Conversion Events measure how many conversions (think of them as the Metric, an action or the Verb)

• s.eVars give you the who, which or what information (think of them as the Line Item or the Noun)

Some of the common uses for s.eVars include:

• Internal Search Terms• A/B Testing • Campaign/Promotion tracking• Merchandising Categories• User Types

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Internal Search TermTo learn which Internal Search Terms drove the most conversion on your site, you can set the search term into an s.eVar, and then simply wait and see how many conversion were attributed to each search term.

Although the s.eVar is set only once, it persists across multiple pages and is credited for the conversion, or in the example above, an order and $100 revenue.

A/B TestingIt is very common to use an s.eVar for A/B testing. Simply assign a value to the s.eVar for each different page to see which page drove more conversion or success. Steps for using s.eVars for A/B testing:

1. Choose a Conversion Variable to store A/B/n identifiers.2. Code the identifiers into the s.eVar on each test Home Page:

s.eVar30=“Home page A” s.eVar30=“Home page B”

3. Randomize traffic to each version of the Home Page.4. SiteCatalyst will hold the value and show conversion metrics for each page

based on the visitor’s actions after landing on either A or B.

The resultant report would hold information similar to this:

Three Internal Campaign Tracking MethodsUsers often have “calls to action” on sites, or links that point the users toward conver-sion. These may be text links, buttons, pop-ups, etc. To find out which calls to action drive the most conversion, you can assign each one an s.eVar value and see how much conversion results.

Method 1

Track your Internal Campaigns by using the getQueryParam plug-in. This means that you should place an Internal Campaign Tracking Code into the query string of the destination URL of each creative on your site. This method is recommended as long as placing values in query strings in links on your site is acceptable.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In the External Campaign example, we used “cid” as our Query String Parameter. In the case of Internal Campaigns, you must use a different Query String Parameter. In the following example, we use “intcmp.” Any parameter will do, but for the sake of simplicity, choose just one Internal Campaign parameter and stick with it.

Method 2

The second method is quite simple: hard code the landing page. As long as there is no other link that leads to the same landing page then this method will work fine for of-fline creatives such as radio or print ads. Only use this method if alternate methods are not available or will simply not work.

Method 3

The third method involves the use of Custom Link Tracking. We’ll cover this in depth in a later chapter, but basically this method sends the Tracking Code through the JavaScript onClick event instead of waiting to send it on the destination page. The getQueryParam plug-in isn’t necessary for this method to work (it is necessary for

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Method 1). This method can take a bit more time, but if you are averse to query string values within links on your site, this may be your ticket!

No matter how you choose to set your Internal Campaign Tracking Codes, once they’re set, the persistence of the values is determine through the settings that you’ve configured in the Admin Console. Any conversion that is completed while the visitor has the Internal Campaign “stuck” to them is credited to the Internal Campaign.

Site Exercise 13.1 Internal Campaign TrackingEstimated Time: 5 minutes


• Understand how the home page Charge Card promotion affects Charge Card application conversions


• Internal Campaign Clicks by Charge Card campaign• Charge Card application completions by Charge Card campaign

Assignment:The home page Charge Card promotion’s link contains the tracking code “homepage-cc-advert” preceded by the trigger “intcmp”.

Using the getQueryParam function in the s_code.js, set s.eVar1 to capture all Internal Campaigns that contain the “intcmp” query string parameter.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Good Navigation Drives SuccessThis Internal Campaign concept actually applies to ANY link on your site allowing you to determine a link’s effect on conversion. You can do A/B tests measuring the worth of different kinds of links too (think location, size, copy, etc.)

Adobe Example

Of course, Adobe uses its own tools to better its site. Those responsible constantly test page designs and calls to action to determine which ones drive the most desired re-sults. In one example, tests were done to determine which Download button was working the best.

Several button types were tested, and it was found that the “winning” button had a 300% lift in success over the control button. These kinds of tests can provide valuable results as you optimize both your site and marketing. Who knew that a button could have such influence over conversion?

TIP: Use s.eVars to perform your own

A/B and Multivariate tests to scientifically prove the value of your optimization efforts.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 13.2 JJ Hotel reservation Conversion Tracking



• Understand how search options affect conversion.• Determine best promotional links on site.


• Number of bookings for each hotel• Number of bookings by internal search options: destination city, travel date,

and number of guests (to find which options resulted in the most bookings)• Number of bookings by Internal Promotional links

Assignment:

What kind of variable(s) and feature(s) could you use to fulfill the business require-ments in this travel site scenario?

Solution

Example

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Implementation

List Variables for ConversionSiteCatalyst Version 15 makes it possible to use up to three special List Variables to gather multiple data points within one image request. List Variables work in a similar way to List Props (covered previously in Traffic). The difference is that you can apply Conversion Metrics to List Variables.

Code Example (with pipe delimiter): s.list1=“Flex|Illustrator|Photoshop”


Code Example (with comma delimiter): s.list2=“JJ Fashion,JJ Travel,JJ Business”

s.events=“event1=10”

List Variables do not have a byte limit, but they do have a limit per delimited field of 255 bytes. Remember, the no-byte limit doesn’t mean limitless because of certain browser restrictions such as 2083 maximum characters in image requests through Internet Explorer.

Cross-Category MerchandisingOften the same product is available in multiple areas on the site. We want to know if the “diamond ring” sold better in the “Jewelry/Ring” area or in the “Women/Accessories” area. With Merchandising Categories, we can get that kind of information.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Merchandising variables are used to compare the relative effectiveness of merchandis-ing channels on your site. The typical SiteCatalyst implementation populates a value into an s.eVar, and SiteCatalyst can track Revenue by the values passed into the s.eVar. The problem is that SiteCatalyst s.eVars are configured to only hold a single value at a time.

For example, your Web site contains different sections (e.g., Electronics, Clothing, Jewelry, etc.) and you want to analyze Revenue broken down by category. However, if a user enters the Electronics section, adds a stereo to the shopping cart, and then navi-gates back to the Jewelry section, but decides not to buy any Jewelry, but goes directly to the shopping cart and makes a purchase, the initial value of “Electronics” that has been passed to the s.eVar would have been replaced by the “Jewelry” value. The reve-nue is credited to the wrong value site section value.

If you need multiple products to have different values for the same s.eVar at the time of an event such as a purchase, use a merchandising eVar

A Merchandising AnalogyA good analogy for understanding merchandising is simply thinking about walking through a store, looking for a roll of tape. You might pick that tape up on the regular aisle location. You might also have found the same tape in an end-cap promotion area. In addition, the tape is available right before checkout in the last-minute-items area.

When the employee is pulling that tape over the scanner, there is no way to know where you picked up the tape. Instead, you must place a “where I got it” value on the tape as you pick it up. This is merchandising. If you have multiple areas where a prod-uct is available, where was it seen or added to the cart?

Merchandising Settings

The first thing to know about the Merchandising settings is that they will not show up for you in the Admin Console until Adobe Client Care enables merchandising for a particular s.eVar. Thereafter, you will be able to enter the Admin Console and see (and

merchandising cross-category merchandising allows you to compare the relative effectiveness of multiple product categories, i.e., if one product sells better under one category than another

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


set) the Merchandising settings in the Conversion Variables settings area. Throughout these examples, you’ll see the Merchandising value set with many different Conversion Events; however, the recommended event with which to set the Merchandising s.eVar is prodView.

There are two settings for Merchandising:

1. Product Syntax2. Conversion Variable Syntax

Merchandising: Product Syntax

This method is probably the safest, as long as you can grab the Merchandising value when you are looking at the product. Then you use the Merchandising field of the product string to assign the value to the product:

s.products=”Category;Product;Qty;TotalPrice;

Incrementor;Merchandising”

Syntax Examples

Example 1: Finding a tennis racquet in the sporting goods section.

s.events=“prodView”;

s.products=“;Tennis Racquet;;;;eVar6=Sporting Goods”;

Example 2: Adding some batteries in the checkout area

s.events=“scAdd”;

s.products=“;AA Batteries;;;;eVar6=Checkout”;

You will also notice that since you are setting this variable with the prodView or scAdd events, you do not need to set the quantity or price fields of the product string. You do, however, have to keep the placeholders in the variable, so that SiteCatalyst knows how to process the data. So you can usually just remember that there are four semicolons between the product name and the Merchandising value.

Merchandising – Conversion Variable Syntax

Based on the structure of your site, it might be easier to capture a Merchandising value before you are actually looking at the product, like when you enter that section of the site. In this case, you can use Conversion Variable Syntax for Merchandising.

In the settings, you will also need to tell SiteCatalyst which “binding” event to watch for.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In other words, you will set the value into the s.eVar, and then when the binding event happens, it “sticks” the Merchandising value to the product. This image shows ex-amples of the pages and how the code would be set.

Be careful, though. This value will apply to all of the products that have that binding event until the value has been replaced with another value. Be sure to test your results in a development report suite.

Merchandising Example

A basketball is available in multiple areas on a Retail Web site: Sporting Goods, Toys, Gifts for Dad and New Items.

When found in the “New Items” area, code on the Product Detail Page would be set like this for Product Syntax:


s.products=“;Basketball;;;;eVar6=New Items”

Merchandising ReviewOnce again, here are the steps to take when using Merchandising:

Step 1: Enable Merchandising

• Done by Adobe Support

Step 2: Configure Merchandising Settings

• Product or Conversion syntax

Step 3: Set JavaScript Merchandising Variables

• Code syntax on page

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 13.3 Merchandising Revenue by ChannelEstimated Time: 4 minutes


• Segment sales by merchandising category.


• Product Revenue by cross-category merchandisingScenario

Assignment:

Scenario: Tissot Aviator Watch (SKU 300720) is available for sale in two sections of the Web site: “Men:Accessories” and “Jewelry:Watches”.

One visitors viewed the watch in the “Men: Accessories” category. Another visitor viewed the w atch through the “Jewelry:Watches” category.

How would you code the Merchandising Category in each circumstance on the Product Page, using s.eVar6, and following Product Syntax?

Solution

Example

Implementation

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Conversion Variables SummaryHere are some points to remember as you work with Conversion Variables, including Predefined Conversion Variables (like s.campaign) and Custom Conversion Variables (s.eVars):

• Persistent Custom Variables track what, which or who affected conversion on your site.

• 75 eVars are available.• Only enable those in use for optimal reporting speed in SiteCatalyst.• “s.eVar” is proper capitalization.• Keep variables under the 255 byte limit.• No byte limit for List Variables, but a limit of 255 bytes per delimited field.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

14-1

Chapter Fourteen

Conversion Features and Functions

Objectives

• Understand the difference between Basic and Full Subrelations• Learn about additional metrics available for Conversion variables• Review Conversion Variable concepts

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Enhance your Analysis

OverviewAdobe offers additional features and functions to increase your ability to track your online conversion data. These are listed as follows:

• Break down Conversion Reports by other Conversion Reports to cross-segment Conversion Metrics.

• Add Visits and Visitors metrics to Conversion Reports for additional insight.

These features and functions are described in this chapter.

Conversion Breakdowns or “Subrelations”Adobe uses the word “subrelation” to describe the ability to break down Conversion Reports by other Conversion Reports. A Subrelation is synonymous with Conversion Report breakdown.

In functionality, Subrelations are almost identical to Traffic Report breakdowns called “Correlations,” so many people get these two features mixed up. In fact, both breakdown types are accessed the same way: by clicking on the green magnifying glass to the left of the line item in question.

“Correlations” and “Subrelations”, however, do work differently behind the scenes. Breakdown functionality is not something you code into your site implementation, so your involvement may be limited, but it is still good for you, as the technical advisor, to know about this functionality.

subrelation a break down of one conversion report by another, all conversion metrics can be applied to subrelation reports

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Super-Breakdowns (v14)

So how do Conversion breakdowns work? Simply put, they are either in a “super-breakdown” list, or they are not. The reports in the super-breakdown list can be bro-ken down by ANY other conversion report. These out-of-the-box super-breakdown reports are:

• Campaigns reports• Products reports• Customer Loyalty report

“Everything Else” can obviously be broken down by these super-breakdown reports, but not the two reports from the “Everything Else” can’t be broken down by each other. For example, you cannot break down one s.eVar report by another s.eVar report.

Please note that Full Subrelations or Super Breakdowns are enabled for all Conversion Reports in SiteCatalyst Version 15.

As this image suggests, you can have a “regular” report upgraded to the super-break-down list, but since it requires a high amount of processing and data storage, it is likely to have a cost associated with it. Please contact your Adobe Account Manager for more details if you’re using SiteCatalyst Version 14 and you’d like this upgrade..

The result of being able to break down reports is that you will be able to see relation-ships between various segments and their effect on conversion. For example, if you break down Campaign Name (a Classification report based on the Tracking Code or s.campaign report) by Products (to see what users buy when the enter through the “Show Style, JJ Esquire” campaign), you would get the following report.

full subrelation also known as a “super breakdown”, is a fully-subrelated conversion variable that can break down all other conversion variables, two normally-subrelated conversion variables cannot break down each other

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


You can also break down at the Report Title level to break down all items within a Conversion Report (shows top five items per breakdown in this breakdown summary report).

Additional Conversion MetricsIn addition to the basic Conversion Metrics, you can have Adobe Client Care enable Visits and Visitors in the Conversion Reports (Version 14). This can be helpful so that you can understand not only how much conversion came from a particular segment, but how many visits or visitors (traffic) there were that completed that conversion. This is especially helpful when you have a conversion event that one visitor may per-form several times. It might not be sufficient to know how many conversions there were, but might also be important to know how many different people converted.

Visits and Visitor metrics are enabled for Conversion Reports automatically in SiteCatalyst Version 15.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Conversion Variable Section Review

Putting It All TogetherHere are some points to remember as you work with Conversion Variables and Conversion Events, including Predefined Conversion Variables (like s.campaign) and Custom Conversion Variables (s.eVars):

• Persistent Custom Conversion Variables track what, which or who affected conversion on your site.

• 75 eVars and 20 events available for site use (+ 80 integration events for use with Data Sources or Genesis).

• Only enable those in use for optimal reporting speed in SiteCatalyst.• “s.eVar” is proper capitalization.• s.campaign and s.eVar1-75: 255 byte limit.• Product variable: 100 bytes per field (category; product) with no variable limit.• purchaseID variable: 20 bytes.• transactionID variable: 100 bytes.• Custom event serialization: 20 bytes.• s.zip and s.state: 50 bytes each.• s.listN: 255 bytes per field with no variable limit.• In all cases, beware of browser limitations (2083 characters)• It is “first time case sensitive.” This means it stores the initial case, but are then

case insensitive. (Initially, you send in “aBc”, and afterward it is credited for any versions of abc, ABC, Abc, aBc, etc.)

Other important points to remember when working with Conversion Variables:

• Conversion: Measure How Many Conversions and What Led to Conversion › Events measure how many conversions happen (Verb or action) › Conversion Variables measure who, which or what performed the success

event (Noun or thing)• Populate the s.events variable when “the thing” happens

› Where?: Product detail page, purchase confirmation page, registration thank you page, form completion page, etc.

• Populate s.campaign and s.eVars once and they persist › Where?: Campaign landing page, login page, search results page, etc.

• Populate s.products on every Retail event page › Where?: Product detail page, add to cart page, purchase confirmation

page, etc.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Conversion Variable Code in ActionIn the last chapter, we reviewed the entire Traffic Variable section by showing an ex-ample of how we would code the site to capture a visitor’s traffic activity. This seems like the appropriate time to show the same type of example, but instead show Conversion Variables in action. Even though you haven’t yet learned about the func-tions of all Conversion Variables, this example should serve as a good introduction and you’re obviously encouraged to review it again in the future.

In this scenario, we are examining a visitor to the fictitious JJ Esquire Web that has undergone a SiteCatalyst implementation.

Our visitor has returned to the JJ Esquire site through a Google Text Ad. The s.campaign variable, used to capture Tracking Codes, is automatically populated with the Tracking Code “google_ad_7” and this value is then “stuck” to our visitor (Conversion Variables can persist with visitors between pages and visits).

The value “google_ad_7” is actually inside a virtual cookie which means that it’s a value stored on SiteCatalyst servers tied to the SiteCatalyst Visitor ID value stored on the visitor’s computer. We use this method so that the SiteCatalyst cookie set on the visitor’s computer doesn’t get too large.

How long is this value in s.campaign stuck to our visitor? It’s all up to you! (An impor-tant marketing decision.) It depends on how long you want to allow the value “google_ad_7” to get credit for things he does like purchase, subscribe, or any other conversion.

We’ve identified this visitor (he’s been to our site before) and we’ve chosen to input his Age and User ID into custom Conversion Variables (s.eVar3 and s.eVar4, respectively).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


On the site’s home page (Page 1), our visitor searches for some “sensible shoes.” On the Search Results page (Page 2), the internal search term is populated into another conversion variable (s.eVar5) and stuck to our visitor.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


On the product page (Page 3), our visitor clicks on purchase...

...and on the purchase page (Page 4), our visitor triggers a Success Event (a Conversion Metric) called “purchase.”

Purchase credit (the metric “Order” in SiteCatalyst) is awarded to all values still stuck to our visitor at the time of the purchase.

Thinking back to our grammatical metaphor that was previously mentioned, Purchase is the verb and all the values stuck to the visitor like Campaign ID, Age Group, User ID and Internal Search Term, are the nouns.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


So what does this all mean? Well, let’s take a look at the reports. First, through the Tracking Code Report (s.campaign), we know that we got a purchase when someone came in through the Google paid search Text Ad called “google_ad_7”

By looking at the Age Group Report (s.eVar3), we know that we received a purchase from someone in the “40- to 44-year-old” demographic.

By viewing the User ID Report (s.eVar4), we know that the visitor with User ID “123456” bought from us.

And finally, through the Internal Search Term Report (s.eVar5), we can see that there was a purchase from someone that searched by “sensible shoes.”

NOTE: The Conversion Event used in the

example on this page is “Purchase” (the metric “Order”), but the example applies to all Success Events. To demonstrate, if the Conversion Metric were “Newsletter Sign Up”, that metric would be credited to all s.eVar values currently stuck to the visitor in the same way “Purchase” was credited in the example.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Quick Quiz 14.1 Estimated Time: 5 minutes

Question 1

You need to identify the number of Orders you get from people that search by “Sport Jacket” on your site. What variable type should you use to capture Internal Search Term?

Question 2

You need to identify the number of Page Views you get from people that search by “Sport Jacket” on your site. What variable type should you use to capture Internal Search Term?

Question 3

You want to create a report that shows which products 40-44 year olds purchase. What variable type should you use to capture Age Group?

Question 4

You want to create a report that shows which pages 40-44 year olds view on your site. What variable type should you use to capture Age Group?

Quiz 14.2 A Plethora of FormsEstimated Time: 7 minutes

Assignment:

Divide into two teams.

You have 10 different Forms on your site. You need to track Form Starts and Completions for each Form.

Figure out three different ways to code the 10 Form Starts and Completions using:

1. Only s.prop(s)2. Only s.events3. A combination of s.eVar(s) and s.events4. Determine which method you think is best for your purposes.

Remember, you only have 75 props, 75 eVars and 20 events.

Extra credit: Is it possible to code 20 forms and record form starts and form comple-tions without using more than the SiteCatalyst limit of 75 props, 75 eVars or 20 events? What if you had 100,000 different forms?

Section Three Review QuestionsChoose the best answers for the following questions from Section Three.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


1. The purpose of Conversion reports is to:

a. Track the revenue, units, and orders of standard shopping cart Web sites.b. Track the conversion of any type of Retail (revenue generating) Web site.c. Track visitor success or conversion of any events that occur on a Web site.d. Track pages relating to conversion transactions.

2. Out of the following list, chose the Predefined Retail Success Events (circle all that apply).

a. scOpen f. prodView

b. scAdd g. scOrder

c. revenue h. scUnits

d. scRemove i. scCheckout

e. scView j. purchase

3. What are the four most common pages to be coded in order to capture basic shopping cart success?

a. Product detail page, shopping cart page, shipping page, checkout pageb. Product detail page, shopping cart page, billing page, order confirmation

pagec. Product detail page, shopping cart page, checkout page, order confirmation

paged. Home page, shopping cart page, checkout page, order confirmation page

4. Which of the following are correct syntax for the product variable on a product detail page? Circle all that are correct.

a. s.products=”prodView”b. s.products=”category;product”c. s.products=”product;category”d. s.products=”category,product”e. s.products=”;product”

5. What is the most correct statement regarding eVars?

a. An eVar tracks success events.b. An eVar tracks data related to products only.c. An eVar tracks custom segments and data and is stored in a virtual cookie.d. An eVar tracks conversion metrics for custom segments and data and is

populated on each page.

6. Enabling “full subrelations” (super-breakdowns) for an eVar will provide essentially the same breakdown options as the s.campaign variable.

a. Trueb. False

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


7. eVars are persistent and will expire:

a. when the visit has ended.b. when the visitor reaches the predefined success event.c. when the expiration time or event is reached as defined in the Admin console.d. on each page load.

8. Which is true of the SiteCatalyst cross-category Merchandising functionality?

a. It allows products to be tied to a dynamic merchandising channel rather than a static parent channel.

b. Allows a 1:1 relationship between a product and an eVar value.c. Merchandising values can be set in the product string or on the page, depend-

ing on the settings chosen.d. All of the above.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

15-1

This fourth section introduces you to SiteCatalyst Configuration and Automatic Variables. By modifying SiteCatalyst Configuration Variables, you can control how SiteCatalyst records data. We’ll learn about SiteCatalyst features and functions that will help you to modify your data such as SiteCatalyst Plug-ins and VISTA. We’ll show you how to import data to and export data from SiteCatalyst. Finally, we’ll cover some important site-based implementation considerations such as non-JavaScript imple-mentation options.

As the technical lead, you may not personally use some of the tools that we’ll cover during this section, but it’s important to know how they work so that when your Report Consumers make demands for certain reporting, you know what is available to you in your SiteCatalyst tool kit.

Many exercises throughout this section are also based on your own JJ Esquire Web site. This will provide you with excellent practical experience.


Chapter 15: Configuration VariablesChapter 16: Data Manipulation ComponentsChapter 17: Processing RulesChapter 18: Mobile Site TrackingChapter 19: Light Server CallsChapter 20: Site-Based Implementation ConsiderationsChapter 21: Data Import and Export ToolsChapter 22: The Developer Portal and Intro to the SiteCatalyst APIChapter 23: Tag ManagementChapter 24: DigitalPulseChapter 25: Validation and TroubleshootingChapter 26: Effective Implementation Practices

Section Four

Enhancements

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


IntroductionUp to this point, this course has reviewed the basic variables and functions for collect-ing both Traffic and Conversion data. The power of SiteCatalyst is that the collected data can be modified with additional global variables, features and tools. The addi-tional features are defined in the following tables.

This first table provides a list and explanation of the Configuration Variables that can be set in the Global JavaScript file on your site.

s_account The s_account variable determines the report suite where data will be stored and reported in SiteCatalyst.

s.currencyCode The currencyCode variable is used to identify the cur-rency type that you are passing in through the code to SiteCatalyst.

s.charSet SiteCatalyst uses the charSet variable to translate the character set of the Web page into UTF-8.

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

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

s.trackInlineStats The trackInlineStats variable determines whether ClickMap data is gathered or not.

s.linkDownloadFileTypes The linkDownloadFileTypes variable is a comma-sep-arated 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.

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

s.linkLeaveQueryString By default, query strings are excluded from all SiteCatalyst reports. The linkLeaveQueryString vari-able determines whether or not the query string should be included on Exit Links and Download Links.

s.linkTrackVars linkTrackVars is a comma-separated list of variables that will be set with custom, exit and download links. If linkTrackVars is set to “” all variables that have values will be sent with link data.

s.linkTrackEvents linkTrackEvents is a comma-separated list of events that may be sent with a custom, exit, or download link. If an event is not in linkTrackEvents, then it will not be sent to SiteCatalyst, even if it is populated in the onClick event of a link.

NOTE: The variables are contained within

the Global JS file (s_code.js). Additionally, for H code, all of the variables listed use “s.” to denote the object, with the exception of account, which uses “s_” as a prefix.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In addition to these and other Configuration Variables, Adobe offers other tools and features for modifying and customizing data. Some of these options are offered directly through the SiteCatalyst interface, while others require input from Adobe.

JavaScript Plug-ins

JavaScript plug-ins and utilities are small programs or functions that are added to your Global JavaScript file (s_code.js). Their primary purpose is to modify or add to the existing functional-ity. These plug-ins extend the capabilities of your JavaScript file to give you functionality that is not originally included. Plug-ins may be used to retrieve query string parameter values, detect Flash, write cookies to store session data, or meet other busi-ness requirements.

VISTA SiteCatalyst’s Visitor Identification, Segmentation and Transformation Architecture (VISTA) is a real-time server-side data modification and segmentation solution. If you can’t pop-ulate a variable client-side, try VISTA. These rules can really help you out when you’re in a coding fix.

Classifications Classifications are attributes or properties (metadata) that are applied to a key such as a Tracking Code. New reports are created in SiteCatalyst by grouping these keys. Each key uses a unique alphanumeric entry in a table (template). The clas-sifications are contained next to the key in the template. With classifications you can gain an even deeper understanding of elements driving your success.

SAINT SAINT (SiteCatalyst Attribute Importing and Naming Tool) allows you to quickly configure SiteCatalyst classifications. Using a simple tab-delimited data file format, SAINT enables you to bulk upload classification data values.

ClickMap ClickMap is an Internet Explorer and FireFox plug-in—and a module of SiteCatalyst™—that allows SiteCatalyst clients to visually measure traffic, conversion and success metrics within the pages of a Web site.

Data Sources With Data Sources, data may be easily imported, and imme-diately made available to users worldwide. Even better, the graphical features of SiteCatalyst may be used to analyze this data either separate from, or in addition to, SiteCatalyst data collected directly from the Web site.

Data Warehouse Data Warehouse refers to both the storage of raw, unprocessed data collected by Adobe and to the custom reports a user can create by filtering data. Data Warehouse enables you to request reports to display advanced data relationships from raw data based on your unique questions.

ASI ASI stands for Advanced Segment Insight. This tool is used to segment data retroactively from the Data Warehouse and cre-ate a new custom segment in a new SiteCatalyst Report Suite without the need to add implementation code.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Data Feed SiteCatalyst users frequently use a data feed to take data from SiteCatalyst and populate another corporate Data Warehouse. The user’s corporate Data Warehouse may contain data relat-ing to sales, marketing, accounting, etc., from other sources. The SiteCatalyst data from the data feed adds Web analytics data to the client’s Data Warehouse, and enables them to obtain a view of their overall organization.

Excel Client and Report Builder

The Excel Integration Client and Report Builder tools are effective tools used to extract data from SiteCatalyst reports and post them to an Excel worksheet. The posted data is referred to as a data block. You can use the functionality of Microsoft Excel to modify the data in the data block as neces-sary. Additionally, you can save any worksheets to the Excel Workbook Library for later use.

Discover Adobe Discover is an extension of Adobe SiteCatalyst that combines the speed and flexibility of Adobe SiteCatalyst with the granularity and power of Adobe Data Warehouse. It allows experienced Web analytics professionals to go beyond the scope of traditional Web analysis by creating an unlimited number of on-the-fly visitor segments and applying those seg-ments to any report, across any time period, and at any level of detail. Discover helps to optimize the Web site and site marketing by giving the analyst the ability to segment every report. In brief, Discover is a segmentation tool.

Flash Tracking Frequently, companies develop applications in Flash, and they would like to use SiteCatalyst to track certain events that occur. You can track Flash events by using Adobe’s ActionSource tools, thereby understanding the Flash-based activity on your site.

In addition, this section covers several other topics of interest, including cookies, re-ferrers and redirects. Adobe uses cookies to differentiate requests from different browsers and to store helpful information that can be used by the application at a later time. A referrer is the Web page location your visitors were viewing before coming to your site. A redirect occurs when a Web page or a Web server directs a browser to some other URL without any user interaction.

These topics are discussed at length in the following chapters. For more information, refer to the online Implementation Manual available for download in the SiteCatalyst Help section.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

15-5

Chapter Fifteen

Configuration Variables

Objectives

• Learn the purpose of SiteCatalyst Configuration Variables• Set Configuration Variables based on site locale and requirements• Learn how to implement Custom Link Tracking

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Controlling Data Capture

The Configuration Variables control the wa that data is captured and processed by SiteCatalyst. The list below shows some of the more-common Configuration Variables that are typically set in the main Global JavaScript (s_code.js). These variables can be set within the SiteCatalyst page-level code and links when appropriate.

Not all of these variables appear in the code by default when you generate code through the Admin Console’s Code Manager. Some of these Configuration Variables may not be applicable to your site’s implementation needs.

• s_account › s_dynamicAccountSelection › s_dynamicAccountList › s.dynamicAccountMatch

• s.charSet • s.currencyCode• s.cookieDomainPeriods• s.fpCookieDomainPeriods• s.cookieLifetime• s.doPlugins• s.trackDownloadLinks• s.trackExternalLinks• s.trackInlineStats• s.linkDownloadFileTypes• s.linkInternalFilters• s.linkLeaveQueryString• s.linkTrackVars• s.linkTrackEvents• s.linkExternalFilters• s.usePlugins

Some of the goals and objectives of using these configuration variables are:

• Track multiple sites/domains• Use any currency on purchases• Capture data in different languages• Link Tracking

› Track the number of downloaded files › Track links to external sites › Track custom links for unique purposes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The most commonly used Configuration Variables are described in the following pages.

Report Suite IDs (s_account)A “Report Suite” (your data container or environment) holds all information for a specific group of pages (usually one actual Web site). Adobe Client Care creates Report Suite names and IDs. The Report Suite ID is the value added to the s_account variable. When data is sent to the collection servers, the Report Suite IDs are used to determine where to populate the data in the collection tables. The Report Suite name is basically the user-friendly name that displays in the SiteCatalyst interface.

The Report Suite can be specified by server code on page, but usually is contained in the .JS file (s_account). The following sample code gives a good example of how the s_account variable is used.

var s_account=“jjesquireuk”

In this case, the Report Suite ID is “jjesquireuk”. These IDs are created by Adobe, but then applied to the JS file by the client.

Global report suitesVery large sites or companies with multiple sites like local country sites, generally employee multiple Report Suites. Each Report Suite is independent from the others. Analysts that analyze the JJ Esquire Germany site and JJ Esquire Japan site may prefer to keep site data separate. This can be done by feeding each site’s data into its own Report Suite.

While analysts may analyze sites separately, they may also want a global view of worldwide site activity. There are two methods to combine multiple Report Suites into a Global Report Suite.

Multi-Suite Tagging

If you have several Web entities, a “Global” Report Suite can be created to give you global totals for Traffic and Conversion Metrics and event Paths.

NOTE: Verify that data from local Report

Suites will roll up as intended when combing multiple Report Suites. Using this workbook’s example, s.prop1 in the Global Report Suite will contain the contents of s.prop1 from the UK, German and Australian sites.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


To capture multiple Report Suites, set the multiple IDs into the s_account variable delimited by commas.

Code examples:s_account=“jjesquireuk,Global”

s_account=“jjesquirede,Global”

s_account=“jjesquireau,Global”

Rollup Report Suites

Rollup Report Suites can be created without the need to add any code to your imple-mentation. Rollup Report Suites are created in the Admin Console. These “Global” Rollups sum the values of the Report Suites of your choice.

Global Report Suite Creation Comparison

Multi-Suite Tagging Rollup Report SuitePathing Across Report Suites No Pathing

De-duplication of Unique Visitors and Visits

No de-duplication of Unique Visitors and Visits

Live Date Processed Nightly

50% additional CPM Cheap or Free

Dynamic Account SelectionYou have the option to dynamically set the Report Suite ID based on the URL of the page. The s_account variable can be set dynamically by using the following steps and configuration variables:

1. Turn on the functionality: s.dynamicAccountSelection=true

2. What part of the URL should make the decision? a. Match on domain, path, query string, or combination: s.dynamicAccountMatch=window.location.host (domain by default)

TIP: Assess your Report Consumers’

Global Report Suite needs and expectations if you are trying to decide between the Multi-Suite Tagging and Rollup Report Suite options. Both are popular among SiteCatalyst clients.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


3. Map the [domain] value to the report suite ID. a. If none match, default to s_account: s.dynamicAccountList=“mysuite2=www2.mycompany.com; mysuite1=mycompany.com”

More information about using these variables is available in the SiteCatalyst Implementation Manual.

Character SetsCharacter sets determine how data is displayed in the interface. Adobe supports two different character set types including ISO-8859-1 and UTF-8. Languages with latin character sets such as English, Spanish, and French use ISO-8859-1 (with no diacrit-ics). Languages that use other characters must enable a multi-byte Report Suite for use with the UTF-8 character set. Any languages that are not in ISO-8859-1 or UTF-8 can be captured as long as the appropriate value is set into s.charSet, but since Adobe does not support the other character sets, SiteCatalyst uses the s.charSet variable to convert any characters in for example, Shift_JIS, Big5,ISO-8859-5 and other formats to UTF-8. The following sample code shows an example of how the s.charSet variable is populated.

s.charSet=“ISO-8859-1”

If the s.charSet variable contains an incorrect value, the data in all other variables will be translated incorrectly. The s.charSet variable should match the charset value that is set in the headers of your Web site.

Multi-Currency SupportSiteCatalyst supports multiple currencies, so you can provide multi-currency func-tionality to your end user and know that it will report correctly in the reports. There are three times that you need to consider when working with currency in SiteCatalyst:

1. Passing currency in (set in page or JS file)2. Storing currency (report suite level)3. Viewing currency (in reports)

NOTE: The s.charSet variable should be set

to match the charset value set in the head tags of your Web site.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Passing Currency In

In the JS file, you can set the s.currencyCode variable to denote the currency that you provide on your site, telling SiteCatalyst how to understand the revenue that enters through the product string. Example code:

s.currencyCode = “DKK”

If you allow people to purchase items on your site in different currencies, you will want to set this variable dynamically, usually at the page level.

Storing Currency

When you set up a Report Suite, you have to choose a currency in which all numbers will be stored. You can, however, still allow people to purchase items in multiple cur-rencies on your site. The Report Suite currency by you or Adobe Client Care when you initially create the Report Suite. If the currency being passed in does not match the stored currency type, a currency exchange will take place as it flows into the database. This exchange rate is updated daily. In the rare case that you need to change the Report Suite default currency, contact Client Care.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Viewing Currency

SiteCatalyst Report Consumers can choose the desired currency for revenue-based reports. If the chosen currency does not match the type being stored in the database, a currency exchange will occur at the report run time. Because currency exchange rates fluctuate, the most accurate data will be available if all three currency types are the same (i.e., site currency passed in, Report Suite stored currency and Report view-ing currency).

Change your Viewing Currency in Favorites>Report Settings>Language/Currency/Encoding.

So how does this all work? Let’s imagine that a buyer makes a purchase on the JJ Esquire Denmark site. The Report Suite default currency is the Danish Krone, but the visitor chooses to purchase using Pounds Sterling. How would this work?

Currency Format

Currencies that do not use a period (.) as the decimal separator will have to be modi-fied to use the period instead of alternate decimal separators. For example, the Swedish Krona, which uses a comma, will have to be modified to use a period instead of the comma for the decimal separator. SiteCatalyst uses the comma to separate different products in the product string, and if there is a comma inside of the product string’s revenue field, SiteCatalyst will interpret the comma as the start of a new product and

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


the data will not be passed in correctly. Also, avoid using a thousands, millions or bil-lions separator of any type in the code

Domain PeriodsWithin the Global JavaScript File (s_code.js), you may find two curious variables: s.cookieDomainPeriods and s.fpCookieDomainPeriods. For “.com” sites, you may never deail with these variables, but if you have a site that, counting from the right to the left, has more than two periods in the domain (like .jjequire.co.uk), you may deal with these variables.

s.cookieDomainPeriods

The s.cookieDomainPeriods should be created automatically in the Admin Console Code Generator as long as you indicate three or more periods in your domain name in the Code Generator menu.

This variable tells the SiteCatalyst code where to set the s_vi[ID] cookie. This cookie ties together all of the visitor’s activity on your site. If a visitor visits www.jjesquire.co.uk (three periods), but s.cookieDomainPeriods is set to two (it defaults to two if not set), then SiteCatalyst will attempt to set the cookie to “.co.uk” which the browser rejects. If this is not set properly, we will not set cookies correctly.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Example code:

s.cookieDomainPeriods=“3”

s.cookieDomainPeriods=”2”

var d=window.location.hostname

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

s.cookieDomainPeriods=”3”

s.fpCookieDomainPeriods

This variable is used for cookies that are inherently first party cookies such as the SiteCatlayst plug-in cookies and cookies set by the SiteCatalyst code (s_sq and s_cc, discussed later). It does not affect how the s_vi[ID] cookie is set. That is only con-trolled by s.cookieDomainPeriods. This variable inherits the s.cookieDomainPeriods value and its default value is 2. It shouldn’t be dynamically set. It’s a best practice to set this variable if you’re setting s.cookieDomainPeriods. If you don’t know if you should use this variable, contact you Implementation Consultant to discuss.

Example code:s.fpCookieDomainPeriods=“3”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


ClickMap TrackingClickMap is a SiteCatalyst browser tool that allows Adobe’s clients to visually measure Traffic, Conversion and Success Metrics within the pages of a Web site. These metrics are overlaid on top of the page’s links. A visual display highlights the most relevant links on your Web page and calculates the overall value of that page to your site’s success.

The s.trackInlineStats variable determines whether ClickMap data is gathered. If ClickMap is being used, s.trackInlineStats must be set to “true”. If s.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 essentially null.

Tracking Dynamic Pages with Clickmap

Since ClickMap is a tool showing how many times a given link was clicked on your page, it is sometimes considered less effective for highly dynamic sites. Iff the link changes the destination or link type, ClickMap will start the click count over from

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


zero because the changed link is read as a new link. In this case, you may implement “objectID’s,” which gives your link a handle and allows SiteCatalyst to roll up the numbers even if the URL changes.

Example Code:

<a href=”http://www.asite.com/somepage.htm” onclick=”s_

objectID=’SS1234’;”>Some Site Link</a>

This ID then overrides the href, and the numbers can roll up. One common use of this is to track “real estate” value on your site instead of specific link value. If you assign an objectID to a link location, no matter what link shows up there, you will be able to see how many people clicked on links in that spot.

Archiving Key Pages with ClickMap

In some cases, you might want to save versions of pages with ClickMap data, and then be able to compare them later to current versions of the page. This will work fine. Simply save the key pages to your hard drive or shared drive, and then later you can load them back into the browser. The ClickMap data is stored right along with the Web page.

The only gotcha here is that the page will need to be able to find your JS file to make the ClickMap popups work, so you will need to double-check the path to the JS file. If you were using a relative link on the site, you will probably now have to change the path to an absolute path, in order to really find the JS file.

Track by Subscriber ID with s.mobileUsing the s.mobile variable, you can now utilize the Subscriber ID of a mobile handset to identify your mobile visitor in place of cookies. This can be done for mobile visits to a non-mobile site. Non-mobile users will not be affected by the inclusion of this variable.

The s.mobile variable controls the order in which cookies and mobile Subscriber IDs are used to identify visitors. When s.mobile is enabled, the SiteCatalyst JavaScript code checks the HTTP headers for the Subscriber ID. If it’s present, it’s used to iden-tify the visitor in lieu of cookies. If it’s not available, SiteCatalyst will default to the cookie tracking method.

Setting this variable is very simple. Simply set s.mobile equal to any string in the Configuration Variables section of the s_code.js file and SiteCatalyst enables its functionality.

Example:

s.mobile=“yes”

When s.mobile is populated with a value, a “/5/” value appears in the path of the image URL and the Subscriber ID is used first if present. When s.mobile is not included, a “/1/” appears in the path of the image and cookies are used first for identification.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Tracking Links in SiteCatalystSo far you have been placing code on the pages of your site. When that page comes up, the code runs and sends information to SiteCatalyst. Even when someone clicks a but-ton, such as a checkout button, you can code the event (and any other variables) on the page that comes up as a result of the click. But what about the times when the click does not bring up a page? Or what about the times when it brings up a page that is outside of your site on which you cannot put SiteCatalyst code?

In these cases, you will want to send information (send the image request) to SiteCatalyst in an “onClick” event in the link instead of during the page load. Remember, if you send information to SiteCatalyst, even if it is on a link click, you are still paying for that server call, just as if it were a page view. So again, if the click des-tination is one of your pages, it’s best to put the code on the destination page instead. If the link click doesn’t load a page you can code, then you have to code the link. This is referred to as Custom Link Tracking.

Here are some examples of when you would want to use link tracking:

• Download link opens a PDF• External link on your site to advertiser site• Link opens a Java application• Link plays a media file• Shopping portal link sends buyers to other sites for purchase

There are really three kinds of link tracking that SiteCatalyst supports:

1. Download links2. Exit links (External links)3. Custom links (everything else)

With Download and Exit links, you have a choice between an easy configuration and a custom configuration. If you need to use a custom configuration for Download or Exit links, you can use the Custom link format. The following sections will outline how to set up the easy configuration for downloads and exits, and then cover custom link tracking.

Download Link Configuration

Download links are links on your Web site that a visitor would use to download a non-HTML type of file, like .pdf, .doc, and .mp3. There are three variables that are used to configure download links.

s.trackDownloadLinks (true/false)

• This variable denotes whether or not to track download links. Set to true if you want to track Download links with the easy configuration settings.

s.linkDownloadFileTypes (exe,zip,wav,mp3,etc.)

• If trackDownloadLinks is set to true, SiteCatalyst looks to this variable to see what kinds of links to track, based on extension.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• If you don’t include a value, it will be treated as a wild card and all filetypes will be recorded as long as s.trackDownloadLinks is set to true. s.linkLeaveQueryString (true/false)

• This variable decides whether to leave or strip URL query string in the URL that shows up in the reports. The default value is false.

Download Link Results

This quick and easy way to configure and capture download links will provide you with a report that shows you the URL of the link that people clicked on. The Downloads report is in the Site Content > Links folder in SiteCatalyst.

The value is only captured if the visitor does a regular left-click with the mouse, not if they do a right-click. If you want to have a friendlier name show up in the Downloads report, you must use Custom Link Tracking.

Exit Link Configuration

SiteCatalyst enables you to track the destination of a visitor if they leave your site. This is done by telling SiteCatalyst which kinds of links are internal (are destinations to sites you own). Everything other link outside of the domains that belong to your site are considered “exit links.” There are three variables which control this easy setup of exit link tracking.

s.trackExternalLinks (true/false)

• This variable denotes whether or not to track exit links. Set to true if you want to track external links on your site with the easy configuration settings.

s.linkInternalFilters (mysite1.com,mysite2.com)

• This variable identifies internal domains, or more technically said, a string of characters that can be found in the link’s URL. Every other link is considered external to the site.

s.linkLeaveQueryString (true/false)

• This is the same variable used with download links. It controls whether to leave or strip URL query string.

NOTE: File Downloads, Exit Links, and Custom

Links are additional server calls that are billed at the standard CPM rate.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exit Link Results

This quick and easy way to configure and capture external links off of your site will provide you with a report that shows the URL of the link that people clicked on. The Exit Links report is in the Site Content > Links folder in SiteCatalyst.If you want to give friendlier names to links in the Exit Links report, you must use Custom Link Tracking.

s.linkExternalFilters (Optional)

For sites with lots of exit links that don’t wish to track every exit, the s.linkExternalFilters can save you some time. It’s used for less common implementations. You specify which domains should be treated as exit links. An exit link is recorded if the domain is NOT INCLUDED in the s.linkInternalFilter list and IS INCLUDED in the s.linkExternalFilters list. Remember, this variable does not need to be set if s.linkInternalFilters provides sufficient control for your implementation.

Custom Link Tracking

Custom link code allows custom file downloads, custom exit links, and all other cus-tom links to be tracked in situations where page load tracking is not sufficient or ap-plicable. Custom link code is typically implemented by adding an onClick event to a link; however, it can be implemented from essentially any JavaScript event handler or function.

Custom links are link tags that have been implemented with code that is inserted in each link. This code identifies the link, and then calls a function that sends the image request to the Adobe Data Center in order to track the link. Additionally, if there are any s.props, s.eVars, or events set in the link, the variables and events must be included in the following configuration variables, set either in the link or in the .JS file (s_code.js).

Example Configuration Variables:

s.linkTrackVars=”prop15,eVar9,events”

s.linkTrackEvents=”purchase,event8”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Like other Configuration Variables, you can put these in the Global JS file. However, you can instead include the configuration settings within the onClick event of the link itself. This is very common, because you are adding stuff to the link anyway, and it keeps all of the appropriate code together in one place. Please talk to an Adobe Consulting representative to discuss the best option for you.

The following shows the custom link syntax:

Here are some notes regarding this syntax:

• In the s_gi function, you need to include the Report Suite ID that you want to capture this data. This can be provided to you by your Account Manager.

• The s.linkTrackVars and s.linkTrackEvents can be set in the link or in the JS file, as stated earlier.

• If you are going to set an event with the custom link, you need to put “events” in the s.linkTrackVars variable, and then which event you are tracking (like “event1” in the s.linkTrackEvents variable).

• You can then set any s.props or s.eVars that you want, separating them with a semicolon (assuming you have included the appropriate references in s.linkTrackVars and s.linkTrackEvents)

• The s.tl function creates the image request and sends this data into SiteCatalyst telling it which “kind” of a custom link it is through the second parameter

› “o” pushes the Friendly Name into the Custom Links report (“o” means “other”)

› “e” pushes the Friendly Name into the Exit Links report › “d” pushes the Friendly Name into the Downloads report

Custom Link Example

The following is an example of setting s.linkTrackVars and s.linkTrackEvents in the JS file for a site that has many Java-based games. In this scenario, the visitor launches a Tetris game.

JS Configuration: s.linkTrackVars=“prop1”

s.linkTrackEvents=“None”

Link code: <a href=“index.html” onClick=“var s=s_gi(‘mysiteid’);

s.prop15=‘Tetris’;

s.tl(this,‘o’,‘Game’); // “Game” into Custom Links

report”>Launch Game</a>

The following is an example of a shopping portal link that sends buyers to partner sites to complete their transactions. The report suite ID is “mysiteid.” Event 8 is

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


defined to represent this “Referral” action, eVar9 to hold the product, and eVar10 to hold the partner name. The value “Vendor Link” will go into the Custom Links re-port, so you can also see there how many times this action was performed, and even correlate it to other traffic variables (such as GeoSegmentation).

<a href=”index.html” onClick=”var s=s_gi(‘mysiteid’);

s.linkTrackVars=‘eVar9,eVar10,events’;

s.linkTrackEvents=‘event8’;

s.eVar9=‘Blue Hat’;

s.eVar10=‘Hats R Us’;

s.events=‘event8’;

s.tl(this,’o’,‘Vendor Link’);

”>Go Purchase Product</a>

Custom Link Summary

• Use when result of a link is not “code-able” (e.g., button leads to another site not owned by you)

• Use to give downloads and exit links custom names and values• Set the type of link• e = exit link• d = download link• o = custom link (o is for “other”)• Config vars can go in JS file or in the link• Commonly placed in link instead of in JS file

Automatic VariablesIn addition to the Configuration Variables, SiteCatalyst uses some variables that are automatically set. These variables do not require any configuration, and they cannot be configured in any way. They are read-only variables. Any time the .JS file is set, the

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Automatic Variables are, by default, also set. The Automatic Variables are listed as follows:

• Link information• Browser height, width, type, version • Referring URL (can be overwritten)• Current URL (can be overwritten)• Netscape plug-ins• Screen width/height• Color depth• JavaScript version• Java enabled• OS

SiteCatalyst Variables Summary• Traffic Variables (s.prop)

› Basic value counters; page specific › Common Uses; segmentation, internal search, etc.

• Conversion Variables (s.eVar) › Persistent variables; set in virtual cookie › Track what affected conversion

• Events (s.events) › Counts instances of various conversion events (success on your site)

• Configuration Variables & Automatic Variables › May change how data is collected, may collect http header data, etc.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 15.1 Configuration Options



• Ability to record Great Britain Pound currency (GBP)• Set the s_vi[ID] cookie to the correct domain (jjesquire.co.uk)• Track data in appropriate Report Suite (jjesquireuk)


• Revenue in Pounds Sterling• All Metrics by Report Suite segment

Assignment:

How would you set the Configuration Variables to comply with our KBRs and KPIs?

Solution

________________________________________________________________

________________________________________________________________

________________________________________________________________

Example

________________________________________________________________

________________________________________________________________

________________________________________________________________

Implementation

________________________________________________________________

________________________________________________________________

________________________________________________________________

Exercise 15.2 More Configuration Options



• Track global retail Web sites• Track links to affiliate sites• Be able to track specific unique links within site• Ability to record Japanese characters and Japanese Yen currency (JPY)• Ability to track exit links and custom links• Ensure that data is being tracked in appropriate report suite within SiteCatalyst• Track mobile visitors to our web site using the device Subscriber ID in lieu of

cookies

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Key Performance Indicator

• Exit Clicks to external sites

Scenario:

• Japanese Web site is encoded in SHIFT_JIS• Adobe assigned report suite ID of “yoursitejp”• URL of your site is www.jjesquire.co.jp• Custom links use s.prop5, s.prop6, and event3• Track exit links, but not file download links• Track mobile visitors using the Subscriber ID if available

Assignment:

How should the configuration variables be set in the JavaScript file (assuming that you are setting custom link configuration variables in the JS file instead of in the links)? Please fill in the blanks.

Solution

Fill in the blanks:

Implementation

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 15.3 JJ Esquire charge card application


Key Business Requirement

• Understand Charge Card Application Conversion


• Application Starts (event9) and Completions (event10) for Charge Card Application (s.eVar7)

Note: The application is completed on a third-party site called Passport Charge Card. For this exercise, we want to know if the visitor has completed the parts of the applica-tion contained on our web site (we cannot place SiteCatalyst code on a third-party site that we do not own). “Completion” should be recorded each time a visitor completes Step 2 of the application.

Assignment:

Code the JJ Charge Card Application fulfilling the KBR and KPIs listed above.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

16-1

Chapter Sixteen

Data Manipulation Components

Objectives

• Learn the order in which SiteCatalyst Code is read• Learn how SiteCatalyst Plug-ins can manipulate client-side data• Understand how VISTA can make server-side data modifications

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Client-side and Server-side Data Manipulation

How SiteCatalyst Code Is ReadAfter all of the experience you’ve had with SiteCatalyst Code thus far, you’ve probably already figured out how the code is read, but if there is any doubt, let’s take care of that right now. Let’s break down this process into six steps.

1. Page Code calls the external s_code.js file2. The entire s_code.js file is read3. Page Code is read (can overwrite s_code.js variables)4. s.t() function on page executes to start creating the image request5. The Plug-ins execute and contribute values to the image request (can over-

write Page Code)6. Finally, the Image Request is made

JavaScript Plug-InsPlug-ins are small programs that work together with the Global JS file (s_code.js) to increase functionality and add special features that are otherwise unavailable in SiteCatalyst. Plug-ins are added to the Global .JS file. The plug-ins are typically called from the s_doPlugins function. Adobe does not include all the plug-ins by default.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Instead, the plug-ins are added on an as-needed basis. The plug-ins are one means by which you can manipulate your data.

There are several free standard plug-ins available in the SiteCatlyst Help section (Help>Supporting Docs>Implementation>Plug-ins) and the list is constantly growing as new functionality is created. Please contact your Adobe Account Manager to dis-cuss other available plug-ins if you have an implementation need that isn’t satisfied by the plug-ins offered in the Help section. There may even be some plug-ins that are commonly used by other Adobe clients in your vertical.

These following plug-ins are available free of charge, and more information can be found by looking in the Help section of the Adobe Digital Marketing Suite. Other free plug-ins are available in the Help menu.

getQueryP-aram

Returns the value of a specified query string parameter, if found in the current page URL. Since important data (such as campaign tracking codes, internal search keywords, etc.) is often available in the query string on a page, getQueryParam is a powerful tool to help capture these data into SiteCatalyst variables.

getValOnce Used to force a variable to be populated only once within a single session or time period. The most common reason for doing this is to keep campaign click-throughs from being inflated.

APL (appendList)

Provides a simple mechanism to append a value to any delimited lists, with the option of a case-sensitive or case-insensitive check to ensure the value doesn’t already exist in the list.

getPercent-PageViewed

Captures the percentage of the previous page that the user viewed. Use to determine how much of your content users are seeing on average so that you can optimize your page lengths and layouts based on real user behaviors.

Time Parting Populates SiteCatalyst reports with hour of day, day of week and weekend/weekday values. Use to understand when you get the most Traffic and Conversion.

detectRIA Determines whether users on your site have Adobe Flash and/or Microsoft Silverlight installed in their browsers and, if so, the ver-sion numbers of these plug-ins.

getAndPer-sistValue

Obtains a value of your choosing and causes it to be populated into a SiteCatalyst variable for a determined period of time. For exam-ple, you might use this plug-in to set a campaign tracking code from the s.campaign variable into a Custom Traffic (s.prop) variable on each page view made by the user for the next 30 days in order to determine how many page views the tracking code ultimately gen-erated as a result of the original click-through.

getNewRe-peat

Determines whether a user on your site is a new visitor or a repeat visitor.

daysSinceL-astVisit

Determines the number of days since a user last visited your site

getVisitNum-ber

Determines how many visits a user has made to your site.

TIP: Free SiteCatalyst plug-ins are available

in the Knowledge Base at Help>Supporting Docs> Implementation>Plug-ins.

Plug-ins Client-side approach

to populate SiteCatalyst variables. Plug-ins are small JavaScript programs placed in the Global JS file (s_code.js).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


getPrevious-Value

Captures the value of a SiteCatalyst 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.

The following plug-ins are not free of charge, but are available through Adobe Consulting as part of solution packages. Please contact your Adobe Consultant or Account Manager to get nformation about implementing these plug-ins. Other plug-ins may be available. Adobe Consulting can be contracted to help you build a plug-in to complete your implementation.

Form Analysis Used to track the use of forms on your site. Possible outcomes of form usage include abandonment, success, or error. Examples of form elements: text boxes, radio buttons, drop-down boxes, etc.

dynamicOb-jectID

Provides an automated way of assigning and customizing IDs. This is especially useful when your link URLs exceed 255 characters

getTimeto-Complete

Tracks the time it takes a user to complete a process on your site. The “clock” begins when you call the plug-in with the “start” value and stops with the “stop” value.

linkHandler (Suite)

Contains the linkHandler, downloadLinkHandler, and exitLinkHan-dler plug-ins. The linkHandler plug-in was created to automate custom link tracking. Instead of adding functionality to the onClick event of a link, the linkHandler plug-in may be used to identify links, set a link type, set variables or fire events whenever a link is clicked. The downloadLinkHandler plug-in returns the URL of a link clicked if that URL is considered an exit link. The exit-LinkHandler plug-in allows you to fire an event when an exit link is clicked. It also returns the URL of the link, which can be parsed to populate JavaScript variables.

getVisitStart Used to determine first page of a visit. It returns “1” on the first plug-in call of the visit, otherwise returns “0.” It uses a 30 minute cookie if possible, otherwise reverts to a session cookie. Finally, it always returns “0” if 30 minute or session cookie can’t be set.

Calling Plug-InsJavaScript plug-ins are typically called by the doPlugins function in the Global JS file which is executed when the s.t() function is called in the Page-Level Code. Because the s.t() function is placed at the bottom of the Page-Level Code, if you set a variable in the doPlugins function, you may overwrite a variable you have set on the HTML page.

The only time the doPlugins function is not called is when the usePlugins variable is set to “false.” The doPlugins function appears as seen below (assuming you have H code) in your SiteCatalyst Global .JS file (s_code.js).

/* Plugin Config */

s.usePlugins=true


/* Add calls to plugins here */

}


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The doPlugins function provides an easy way to give default values to variables, ma-nipulate data, or to take values from query string parameters on any page of the site. Using doPlugins is often easier than populating the values in the HTML page because only one file needs to be updated. Multiple plug-ins can be called using the doPlugins function.

/* Plugin Config */

s.usePlugins=true


/* Add calls to plugins here */

s.prop1=s.myPluginExample(‘param’);

s.eVar1=s.myOtherPluginExample(‘param’);

}


/* Plugins Here */

Keep in mind, however, that changes to the JavaScript file are not always immediate. Return visitors to your site are often using cached versions of the JavaScript file, mean-ing that updates to the file may not be applied to all visitors for up to one month after the change is made. A possible remedy for this is to change the name of your Global .JS file when you make updates (only do so if you can easily update all of your SiteCatalyst Page-Level Code with the new address of your s_code.js file).

Let’s briefly cover three popular plug-ins. (Many of the other plug-ins are very popular too, so don’t forget to read up on them and see if they can improve your implementation.)

1. getQueryParam2. getValOnce3. APL Append List

These are three commonly used plug-ins.

The getQueryParam Plug-in

This plug-in should be familiar to you since you installed it when we were learning about the Campaign Variable (s.campaign). The getQueryParam plug-in is important for campaigns because its primary purpose is to return the value of the Query String Parameter (Tracking Code) found in the current URL. When a tracking code is as-signed to a campaign, the getQueryParam plug-in reads the Tracking Code value from the Query String Parameter in the URL. The getQueryParam code is displayed below:


In this case, the getQueryParam Plug-in will populate the s.campaign variable with the value contained in the “cid” name-value pair in the query string of the URL.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


If no query string parameter is found with that value, an empty string is returned. If you only want to populate the s.campaign variable if it is empty (if you haven’t hard-coded a value into it), you can check to see if there is a value and populate it only if indeed it is empty, as shown in the following example:

/* Only run getQueryParam if s.campaign is empty */

if(!s.campaign)


Additionally, the getQueryParam plug-in may specify more than one parameter; all values are returned in a delimited list, as shown below.

s.eVar1=s.getQueryParam(‘cid,src’,‘:’,f);

Arguments (2nd and 3rd are optional): s.getQueryParam(Comma-separated list of parameters, delimiter for list of values, where to search for value)

In this case, getQueryParam will look for values from “cid” and from “src” and use the colon as a separator as it pushes the value into eVar1. The “f” value indicates that it should search for the query string parameter in the parent frame (3rd argument is not commonly used).

If one query string parameter should take precedence over another when both are found, use an “if” statement as shown below.


if(!s.campaign)

s.campaign=s.getQueryParam(‘src’);

In this case, “cid” takes precedence over “src” if both exist in the query string.

As you can see, there is much you can do to manipulate or make needed changes to your data as it comes off of the query string and is set into s.campaign. This plug-in, as stated, is most commonly used to place Tracking Codes into the s.campaign vari-able, but can be used freely to pull a value from the URL query string and populate ANY variable.

The getValOnce Plug-in

The getValOnce plug-in is used to force a variable to be populated only once within a single session or time period. The most common reason for doing this is to keep cam-paign click-throughs from being inflated. We have a way to serialize Conversion Events—think of this plug-in as the way to serialize Conversion variables.

Inflated click-throughs can be caused by visitors that click back to the campaign landing page on the site. The URL of the campaign landing page contains the Tracking Code in the query string. This value is sent into SiteCatalyst each time the page is viewed with the Tracking Code in the Query String Parameter. For example, when visitors click to your site from a campaign ad, the landing URL usually contains a Query String Parameter that is used to populate the s.campaign variable (Tracking Code).

TIP: Is it possible that a visitor could refresh

a campaign landing page on your site? If it is (which it likely is), that means that Tracking Code click-throughs could be counted more than once. Prevent duplication with the getValOnce plug-in.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


When visitors leave the landing page and use the Back button to return to it (or refresh the landing page), the s.campaign variable will again be populated from the query string on the landing page. Each time the s.campaign variable contains a value, a click-through is counted in SiteCatalyst. Using getValOnce will keep campaign click-throughs from being over-counted. The syntax, using the campaign variable as an example, is as follows:

s.campaign=s.getValOnce(s.campaign,‘cmp_cookie’,0)

Arguments: s.getValOnce(input value, name of cookie, days to expiration);

You can name the cookie anything you like, but it should be something specific to this purpose so that you don’t conflict with other site functionality. The time frame pa-rameter controls how long this cookie should live before it expires. The value “0” de-notes the browser session, which is the most common setting.

APL Append List Plug-in

The APL Append List Plug-in is used to add a value to a list variable without duplicat-ing a value already in that variable or overwriting any values. For example, a media site may wish to add a Conversion Page View event to all pages. This can easily be set with this plug-in. If s.events is ever populated with “purchase”, the Conversion Page View event will simply be appended instead of overwriting the “purchase” event. The variable can also be used to add values to s.products or parameters like s.linkTrackVars or s.linkTrackEvents.

s.events=s.apl(s.events,“event1”,“,”,1);

Arguments: s.apl(source list,“Value to Append”,“Delimiter”,Unique Value Check);

APL Plug-in Example 1

Scenario: Add “event1” to the current events variable while ensuring that the event isn’t duplicated.

Before Plugin: s.events=“scCheckout”;

Code:

s.events=s.apl(s.events,“event1”,“,”,1);

(0=no unique check, 1=case-insensitive check, append only if value isn’t in list 2=case-sensitive check, append only if value isn’t in list)

Result:

s.events=“scCheckout,event1”;

APL Plug-in Example 2

Scenario: Add the value “business” to the list variable s.prop1, with “business” and “Business” considered the same value.

Before Plugin: s.prop1=“Travel,Business”;

TIP: Need to set an event on every page

without accidentally erasing other events? Then the APL Append List Plug-in may be the ticket for you! A media site could use this plug-in to set a Page View Conversion event on every site page.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Code:

s.prop1=s.apl(s.prop1,“business”,“,”,1);

(0=no unique check, 1=case-insensitive check, append only if value isn’t in list 2=case-sensitive check, append only if value isn’t in list)

Result:

s.prop1=“Travel,Business”;

(“business” not added because it’s already in s.prop1)

VISTASiteCatalyst’s Visitor Identification, Segmentation and Transformation Architecture (VISTA) is a server-side approach to populating SiteCatalyst Variables. VISTA server-side data manipulation is done live as the data comes in through the image request. An unlimited number of visitor segmentation rules can be defined with VISTA. To gain a new understanding of how behavior differs from segment to segment, and bring valu-able new insight to your site development efforts, VISTA can be leveraged for significant improvements in site performance and profitability.

To sum up VISTA’s main purpose, it is to act as a real-time data manipulation en-gine, so that you can change, add or delete any variable before it actually goes into the SiteCatalyst reports. After analyzing your company’s needs, the Adobe team creates VISTA “rules” for you. An unlimited number of rules can be created on each report suite.

Because VISTA is a real-time solution, any rules that are created have to act on the data as it is coming in and cannot act on data that is already in the SiteCatalyst data-base. However, these rules can act on data in the HTTP header as well as any data ele-ment sent in the SiteCatalyst code.

Where VISTA Fits In

The following diagram illustrates the process of data collection. The SiteCatalyst JavaScript collects data that is embedded in Web pages, and transmits the data to SiteCatalyst data collection servers. The data is processed into SiteCatalyst reports.

viSTA Server-side approach

to populating SiteCatalyst variables through real-time data manipulation. Rules are defined by you and then written and tested by Adobe Engineering Services.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


VISTA rules are written, tested, and deployed on SiteCatalyst servers. Since VISTA rules interact only at the point of data collection, there is no maintenance or effort required by Adobe clients. Your Implementation Consultant will work with you to define the VISTA rule and create a specification from which the rule will be pro-grammed, review the requirements with you, test the rule in a development environ-ment, and deploy the validated rule into production.

VISTA rules require time to design, approve, test, and deploy. Since VISTA rules modify the data collected by SiteCatalyst, new rules as well as changes to existing rules are made carefully, and both tested extensively. In most cases, the data of affected report suite(s) are duplicated onto a separate server, and the VISTA rules applied to this test data. Once the data has been validated and the performance verified, the rule can then be promoted to production servers. Contact your Adobe Account Manager to discuss the time frame needed to create the VISTA rule that you need in place.

VISTA Segmentation Example

In this example, we want to know what our employees do on our public Web site, but we want their visitor activity to be kept separate from our public visitors. Adobe Engineering Services wrote a rule that reads the IP addresses of each visitor and de-termines if the IP address is within the company range. If it is, the visitor’s activity goes to the Employee Report Suite. If it isn’t, the visitor’s activity goes to the Public Report Suite.

This simple rule was created using VISTA because it was too difficult for our techni-cal lead to program this client-side. JavaScript plug-ins can be used to manipulate all sorts of data, but if it’s too difficult to make a client-side change to your data, see if

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


VISTA server-side data manipulation can get you what you need (and perhaps relieve you of a lot of stress!).

Common VISTA Rules

• Grabber — VISTA can grab a value from the URL, the HTTP header or a variable, and set it into another variable or manipulate it and set it into a variable.

• Exploder — VISTA can take an incoming value from a variable, and break it out into several different variables. This can be very helpful when you have a long string of concatenated values that you want to push into different reports.

• Concatenator — VISTA can take any number of values from variables, the URL, or the HTTP header and concatenate them into one variable. This can be quite helpful when the separate variables are dynamic and could come into SiteCatalyst in many different combinations.

• Traffic Cop — Basically acting as a filter, VISTA can watch for specific values in the HTTP header, variables, or URL and segment that data. You could use this to allow only “good” values into a report, to watch for IP ranges, or even watch for specific page names and populate appropriate events on them.

• Database Lookup—Securely push values into props, eVars and metrics into events through a lookup of proprietary data on your servers, (e.g., Cost of Goods Sold)

VISTA Benefits

The benefits of using VISTA include the following:

• It is a Server-side approach to populating SiteCatalyst variables, so you could use it to keep the code on the page at a minimum.

• It can set variables for you when you can’t change the code on the page. This may be because you need the results now and there is a code freeze on the site. VISTA can be the stopgap in this situation.

• VISTA can access the HTTP header (which is more difficult to do client-side).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• VISTA has access to the live data going into SiteCatalyst as well as to the Data Warehouse data.

The Tech PerspectiveAs technical lead, what will most likely be your involvement with VISTA?

• Justify the need to change server-side data (what KPIs and KBRs does this satisfy?)

• Determine if it is best to manipulate data client side (plugins) or server side (VISTA)

• Help define what VISTA rules should do• Work with Adobe Engineering Services while the rule is written

Quick Quiz 16.1 Plug-in Functions

1. What would be the Adobe-recommended way to capture internal promotion click throughs?

a. Use the s.campaign variable to capture the valuesb. Use an eVar on the landing page to capture the valuec. Use the getQueryParam plug-in to capture the valued. Use custom link tracking to capture the value

2. What would be the Adobe-recommended way to segment employee site traffic from visitor traffic?

a. Use login IDs to segment employees from visitorsb. Duplicate domain on your intranet for employees and create a second report

suitec. Create an employee landing page that drops a cookie; use a prop and pathing

to segment d. Use a VISTA rule to separate internal and external traffic into two report suites

3. How can you ensure that the tracking code click-throughs metric is not inflated?

a. Hardcode the campaign value (tracking code) on the landing pageb. Use the getValOnce plug-in to ensure no Click-through duplicationc. There will be no recounting; Pathing de-duplicates reloadsd. Use a VISTA rule to prevent over counting of click throughs

4. How could you quickly add a Page View event to every page on your site?

a. Use the getQueryParam plug-in to pull page views from query stringb. Use the APL plug-in to append a Page View event to s.eventsc. Use getValOnce to add but not over count Page View events

d. Use VISTA to add the Page View event each time a page is viewed

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 16.2 Internal Search Term



• Track Internal Search Terms to understand which keywords lead to conversion


• Internal Search Term Searches• Conversion by Internal Search Term

Assignment:

Capture Internal Search Term (Internal Search Term appears in query string after the “q” parameter) with the getQueryParam plug-in.

Site Exercise 16.3 Newsletter Subscriptions



• Understand which Newsletters are most popular• Create a single report that shows Newsletter subscriptions

Key Performance Indicator

• The number of times a Newsletter was selected during the subscription process

Assignment:

Code the Newsletter Subscription process to capture Newsletter names (a visitor can sign up for multiple Newsletters at the same time). Record the number of subscription instances per Newsletter.

Hint: Selected newsletter subscriptions appear on subsequent page in the query string under parameters “n1” through “n9”.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 16.4 Time Parting Plug-in



Understand Traffic and Conversion by time period


Traffic and Conversion metrics by hour, day and weekday/weekend

Assignment

Install the getTimeParting Plug-in (ask your Instructor and colleagues for assistance if necessary). Use props and eVars 16, 17 and 18 for hour, day and weekday/weekend, respectively.

The Plug-in is available in Company>White Papers on the fictitious JJ Esquire Web site or in Help>Supporting Docs>Implementation>Plug-ins in SiteCatalyst.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

17-1

Chapter Seventeen

Processing Rules

Objectives

• Understand how Processing Rules work• Code Context Variables on your site• Create Processing Rules in the Admin Console

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


A Server-side Implementation Solution

Solving Common Implementation ProblemsIf you’ve implemented before, you may have experienced an array of different prob-lems. For example:

• IT schedules that don’t align with marketing and analytics timelines• Technical Lead spending too much time training developers and documenting

implementation requirements• SiteCatalyst degrading over time without proper IT support

These implementation problems can be solved through the Processing Rules tool. Processing Rules are a server-side solution that allow you to modify your data without IT assistance. Non-IT users can easily modify and manipulate implementation data within an easy-to-use interface.

Test RequiredIn order for you to use, create and modify Processing Rules, you must pass the Processing Rules test. Processing Rules are enabled per user by Adobe, so even if you’re a full administrator within SiteCatalyst, you will only have access to Processing Rules after you pass the test. Non-certified admins can still view active Processing Rules so that you are aware of how your implementation data is changed by them. Contact your Account Manager for more information.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Processing Rule ExamplesNow that you’re thinking about the time- and headache-saving possibilities of this tool, let’s explore the types of data that Processing Rules can modify. Processing Rules can modify all data that is processed or compiled before it. This means that all AppMeasurement (JavaScript, Flash, Android, iOS, Blackberry, Java, .NET, PHP or in other words any of the coding implementation methods you use on your sites), Data Insertion API and Data Sources (Full Processing and Log File) can be modified by Processing Rules (other Data Sources besides Full Processing and Log File cannot be modified by Processing Rules).

So once you’ve determined what data you can manipulate with Processing Rules, think about the types of things that you do with them. Here are some examples:

• Set a Product View on every product page• Populate variables with values from the query string parameter without the

getQueryParam plug-in• Concatenate category and page name in a prop for easier reporting• Copy an eVar into a prop to see paths• Clean up misspelled Site Sections• Map values from Context Variables to props and eVars or trigger an event

Context Data VariablesContext Data Variables are special variables for use with Processing Rules. These vari-ables are set within AppMeasurement (such as JavaScript page code) like other SiteCatalyst variables.

Context Data Variables contain a “key value” that you provide (names your Context Variable, since you can have more than one of them, similar to how props are named s.prop1 or s.prop2).

Example:

s.context[‘key_value’]=“value”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Using Context Data Variables

To use Context Data Variables, programmers set data into them through AppMeasurement. The technical lead uses Processing Rules to map Context Data Variables to props and eVars or to trigger an event. This can make implementation easier for programmers since they won’t need to learn how SiteCatalyst variables work (the technical lead can map data to props and eVars later with Processing Rules).

Context Data Examples

Context Data Variables are written in code as “s.contextData[‘key_value’]”. The Key Value is something that you create that makes sense to you. Key Values or variable names are anything that you’d like them to be. For example, “book” is used as a Key Value in the code example below.

The technical lead could later use Processing Rules to map the Key Value of “book” to, let’s say, s.eVar7 (which would forever hold the name of the book). The value set equal to the Context Data Variable with Key Value of “book” would then go into s.eVar7 (effectively, we’d be setting s.eVar7=“America’s Favorite Game Show Host” with this combination of Context Data Variables and Processing Rules).

<script language=”JavaScript” type=”text/

javascript” src=”http://www.ou-training.com/jjsite/include/

outraining/s_code.js”></script><script language=”JavaScript”

type=”text/javascript”></script><script language=”JavaScript” type=”text/

javascript”></

script><noscript><img src=”http://dcrookston.d1.sc.omtrdc.

net/b/ss/outrainingcom/1/H.22.1--NS/0”height=”1” width=”1”

border=”0” alt=”” /></noscript>

Processing OrderAs you set Processing Rules, you should be aware of what can be modified by Processing Rules and also what data could still be modified even after they are touched by Processing Rules.

Before Processing Rules, the following data is processed and therefore could be modi-fied by Processing Rules:

• Regular AppMeasurement data collection• Dynamic Variable Lookup (“D=” values)• Data Insertion API• User Agent and Referrer (read-only, can be read by Processing Rules)

After Processing Rules, the following data is processed and therefore cannot be modi-fied by Processing Rules. These data processes could modify data already modified by Processing Rules since they occur after:

• Data added by Vista• Visit Page Number (Processing Rules are only aware of data in current hit)• Clean URL added (if s.pageName is not set)• Marketing Channel Processing Rules (you can use Processing Rules to prepare

data for Marketing Channel Processing Rules)• Geo Lookup (this includes Visitor State and ZIP/Postcal codes)• eVar persistence (if set in a previous hit to persist, they are not available during

the current hit for Processing Rules – only eVars set on the current hit being processed are available)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


LimitationsProcessing Rules do have some limitations that you should keep in mind. First of all, they’re not retroactive so Processing Rules must be set up before Context Data Variables is sent. If IT set up your Context Data Variables three months ago, but you just barely created your Processing Rules this week, you’ll only have data from those Context Data Variables for this week going forward.

Other limitations include:

• Limited to 50 rules with 30 conditions each for each Company• Query String Parameters cannot be read beyond the first 255 characters of a

URL (consider using the getQueryParam plug-in instead if you have very long URLs)

• Query String values must be encoded in Unicode or UTF-8 to be read by Processing Rules

• Rules apply to only one Report Suite (but rules can be copied)• Hits cannot be excluded with this tool (use VISTA instead)

Values Available to Processing RulesMost SiteCatalyst variables are available for Processing Rules to manipulate, but not all of them. For example, the Products Variable and Classifications are a few of the variables that cannot be accessed. Others may be read only such as the Report Suite ID (so if you wish to employ multi-suite tagging, s_account must still be populated with-in the s_code.js file).

Available Values:

• Custom Values › Custom Value (commonly used withevents, accepts alphanumeric values) › Concatenated Value

• Traffic Variables › s.props1-75 › s.server › s.channel › s.hier1-5

• Conversion Variables › s.eVar1-75 › s.campaign › s.list1-3 › s.state › s.zip › s.purchaseID › s.transactionID › s.currencyCode

• Conversion Events › events1-100 › purchase, scCheckout, prodView, scView, scAdd and other cart events

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Hit Attributes › Report Suite ID (read-only) › s.pageName › Page URL › Query String Parameter (e.g., “cid”) › Page Domain › Page Root Domain › Page URL Path › Page Query String (e.g., “cid=bn_2&src=int_bn_47”) › Referrer (read-only) › Referring Domain (read-only) › (e.g., subdomain.jjesquire.com) › Referring Root Domain (read-only) (e.g., jjesquire.com) › Referring Path (read-only) › Referring Query String (ready-only) › IP Address (read-only) › User Agent (read-only) › AppMeasurement Code Version (read-only, e.g., H.23.1)

• Values that cannot be changed by Processing Rules: › Product Variable › User Agent › Referrer › Mobile device attributes › Classifications

Handle With Care

As you use Processing Rules, be sure to use a Development Report Suite to first test their effects. Processing Rules permanently change your implementation. Make sure that they work as you intend them to work before switching them over to a production Report Suite. If something isn’t working as you thought that it would in your dev Suite, go through the Rule Set logic to see where you might have gotten something wrong. That little bit of learning will be very beneficial in the future as you create new rules.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Creating Processing Rules

Creating Processing Rules is a fairly easy process, but you must pay special attention to the logic of each Rule Set that you create. To access the Processing Rules Manager, go to Admin > Report Suites > Edit Settings > General > Processing Rules. Processing Rules are specifc to a Report Suite, so make sure that you’ve selected the Report Suite to which you’d like to apply the rules.

Create a RuleOnce you are inside the Processing Rules Manager, click “Add Rule” in the Rule Sets column to create a rule.

ConditionsRules consist of Conditions and Actions. A rule action will not run if it does not pass the condition that you’ve set. It is a best practice to set a condition in nearly all of your rules. At the very least, you should check if a value that you are about to overwrite has already been set. If it has been set, a Processing Rule that does not do this check could overwrite it (if a Processing Rule has nothing to set into a variable, a blank value would still thus overwriting any value set into a variable previously by other means (for example, JavaScript AppMeasurement).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


To set a Condition, click “Add Condition.”

You can set one or more Conditions based on Hit Attributes, Traffic or Conversion Variables or Conversion Events. Limit of 30 values per condition (place one value per line).

Setting Multiple ConditionsYou can set “AND” or “OR” statements for multiple conditions by selecting “All” or “Any” from the highlighted drop-down menu.

In this example, the conditions are: “If a 40- to 45-year-old female, then…”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Setting Multiple ActionsClick “Add Action” if you wish to execute more than one action in a Rule Set.In this example, the Internal Searches event is fired off and the search term from the query string (value set equal to “q”) is populated into the Conversion Internal Search Terms report.

Setting Multiple Rules per Report SuiteProcessing Order matters (drag and drop to change rule order) so make sure to review rule order so that you can determine how the rules affect each other.

In this example, Rule Set 1 values could potentially be changed by subsequent Rule Sets.

Setting a Context Variable

When creating a “Condition” or “Action”, you can select the Context Variable from rule drop-down menus.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


If the Context Variable hasn’t yet been created, type in the name of the “Key” of the Context Variable and add it.

Rule HistoryClick “View History” if you wish to see any changes made to your Processing Rules. Click “View” of a past Rule Set within the View History section to see any old Rule Sets.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Restoring Rule SetsWhile viewing an old Rule Set, you can click “Copy to Current Ruleset” to restore the old Rule Set (overwrite the current Rule Set). This essentially restores past settings if current settings are causing problems. Yes, there is an undo button, but the undo but-ton is just for the Rule Sets, not for any data that has already been processed by Processing Rules that processed your data in a way that you didn’t expect. Remember to always test your Processing Rules on a development Report Suite first!

Copy Processing RulesIf you’d like to apply Processing Rules from your current Report Suite to others, you can easily copy rules with the “Copy Processing Rules” function. Within the Processing Rules manager, click “Copy Processing Rules.” Select the Report Suites to copy Processing Rules to (copies rules from present Report Suite - click “Expand” in Selected Report Suites if unsure of your present Report Suite). Click “Copy” and you’re done.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Common Uses of Processing Rules

Processing Rules have all sorts of uses. You will probably find that this becomes an integral part of your implementation. In some cases, IT may never again be setting props or eVars. This can now all be done by the technical lead! This makes it much easier for you to make changes to your implementation when you need them. Let’s explore some examples of Processing Rules.

Setting a Campaign Tracking CodeYou can set s.campaign with Processing Rules. Notice that the Campaign Variable isn’t set unless the Condition is met (s.campaign shouldn’t be set and the Query String Parameter “cid” should be set). Never set an action without a condition (e.g., “If Campaign is not set, then…”).

Keep in mind that Query String must occur within the first 255 characters of the URL (if you have extremely long URLs, consider the getQueryParam plug-in).

Setting a Product View EventThis can be done as part of an original implementation or to fix an omission in the page code. In this example, the Condition states that the Page Name must contain the phrase “Product Overview”. Every product page on this site contains that phrase.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Concatenating ValuesYou can combine multiple values together. This is especially useful if you intend to push these values into a List Prop or List Var. In this example, it’s been used to create a Page Name with the hierarchy of the page built into its name.

When selecting this option, you’ll need to indicate a delimiter for concatenated val-ues. The colon has been chose in this example for aesthetic purposes (the implementer wishes to delimit by “:”), but remember that you’ll need to choose the proper delimiter that ClientCare seet for you when you set List Props and List Vars (commonly, the delimiter is “|” called the pipe - double check with ClientCare first).

Copy an eVar into a PropLet’s suppose that you would like to see the order in which a visitor clicks through Internal Campaigns on your site (e.g., if a visitor first clicked on the “Spring Sale” campaign and then on the “20% off” campaign, you’d be able to see the order in which

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


the visitor clicked, i.e., “Spring Campaign” first and “20% off” second). If you were capturing the Internal Campaign codes in an s.eVar, you can easily copy them into a s.prop to see paths. You will need to contact ClientCare and have Pathing enabled on the prop that receives this data.

Even though this is a fairly simple rule, please make sure to document the reason for the rule. Do this with all of your rules. It’s just as important as filling out the Solutions Design Reference document (which you should also fill out).

Correct MisspellingsLet’s suppose that you can’t make a change to your code for a couple of months, but one of your Site Sections has been misspelled. Do you have to stand for that? No!

Simple set conditions to search for the offending Site Section name, e.g., “shoppping” , “Shop ping”, “shoping”, etc. Conditions are case insensitive, so that means that “shopping” and “Shopping” would be recognized as the same value.

In the example, the rule checks for any misspellings and if present, populates the cus-tom value “Shopping” so that the Site Section is appropriately named. This can all be done without having to involve IT! You’ll probably want to involve them later to cor-rect the misspelling. I mean, isn’t it going to bug you that it’s not set correctly in the code? Yes, it’s going to bug you; we know your personality type). :)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Pull Internal Search from Query StringYou can pull values from the Query String with Processing Rules. Let’s suppose that you’d like to capture Internal Search Term which is set in the “q” Query String Parameter. Use a Condition to check if it’s been set and then set it into your Internal Search Term variable (eVar or prop) with an Action. Processing Rules only looks at the first 255 characters of the URL so make sure that the parameter always occurs within those first 255 characters of the URL. If you have extremely long URLs, consider using the getQueryParam plug-in which is available for free (but does mean that you’ll have to work with IT to change your code in s_code.js).

If you’re working with multibyte characters, they must be Unicode or UTF-8 encoded.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Processing Rules Gotchas

There are a couple of catches or “gotchas” associated with Processing Rules, so let’s review those so that you never get any unexpected results with your Rule Sets. These aren’t bugs or errors within the tool. They’re just elements within the rules that you may not catch the first time around.

Example One: Copying a Page Name into an eVarScenario:

• You have Events that fire on link clicks (s.events set with Custom Link Tracking)

• You want the Events associated to the page on which they were fired (Page Name isn’t included in the link click)

• You set the Page Name into an eVar with Most-Recent (last-touch) Allocation and Visit Expiration

• Events fired will be attributed back to the active Page Name that persists in the eVar

What’s the gotcha?

• If s.pageName is empty, the eVar won’t be set (an empty s.pageName variable defaults to the clean URL after , but the eVar will NOT be set to the URL)

• Not a problem if every page has a Page Name

Solution

• Use a second rule to rectify the potential problems with rule one (example on next slide)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Example Two: Fix Campaign with wrong Query ParameterScenario

• A new marketer used “camp_id” instead of “cid” in the query string of the destination URL of 1,000 campaign creatives

• The JS file is set to capture “cid”• An analyst uses processing rules to fix the problem


• If “camp_id” is not present in the query string, s.campaign will be left blank• You will lose ALL tracking codes (if “cid” is present in the query string,

associated tracking codes will be overwritten with nothing)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Solution

• Set a condition to first check and see if “camp_id” has been set in the query string

Example Three: Two Sources of DataScenario

• Two web sites feed Internal Search Terms data into one Report Suite• Developer for Web Site X uses a Context Variable called “search_keyword”• Developer for Web Site Y uses a Context Variable called “search_term”• We want to populate s.eVar1 with either of these Context Variables


• The “search_term” Contextual Variable will always overwrite “search_keyword”

• Values from “search_keyword” will never be recorded

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Solution

.Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Processing Rules Best Practices

As you start using Processing Rules, you’ll likely be impressed with how easy they are to use and how flexible your implementation can be when you have server-side control over how SiteCatalyst records visitor activity on your Web site.

Best PracticesAt this point, you should be aware that Processing Rules are very powerful and useful, but also potentially dangerous if you do not use caution and good sense when using them. When you set a Processing Rule, you are permanently changing your imple-mentation during the period in which the rule runs.

Here are some helpful best practices to keep in mind as you use Processing Rules:• Always test new rules in a Development Report Suite (you can easily create a

new Report Suite for this purpose in the Admin console)• Use conditions to check for empty values (if not, you may unintentionally

overwrite a value already set in a variable)• Keep Processing Order in mind (what is set before and after Processing Rules)

because whatever is processed after can affect what was set before• Take advantage of Contextual Variables so that IT doesn’t have to learn how

SiteCatalyst variables work

Class Exercise 17.1 Capture a Campaign Tracking Code


Assignment

Capture a Campaign Tracking code from Query String Parameter “cid”

1. What condition should we set in our Processing Rule?2. What Action should we set?3. Any caveats with this rule?

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 17.2 Capture Newsletter Subscriptions


Assignment

As you’ve done by using JavaScript AppMeasurement and plug-ins in previous exer-cises, use Processing Rules to:

1. Capture Newsletter Subscription names in Prop 11 (already enabled as a List Prop)

2. Capture Query String Parameters of n1, n2, n3, n4, n5, n6, n7, n8 and n9 in Prop 11

3. Use the Pipe (“|”) as the delimiter between values4. Do not Save the Processing Rule5. Ask your instructor to check your work

Site Exercise 17.3 Coding Context Variables


Assignment

1. Set Page Code on the Corduroy Blazer page in Men’s Activewear:

s.contextData[‘page’]=“Men:Activewear:Corduroy Blazer”

s.contextData[‘section’]=“Men”

s.contextData[‘subsection’]=“Activewear”

2. Use the debugger to verify that variables have been passed in3. Ask your instructor to check your work

Note: Remember that Context Data is only processed and recorded if Processing Rules have been configured previously for such data. In this example, nothing will be recorded since no Processing Rules have been set up yet for this Context Data.

Exercise 17.4 Using Context Variables


Assignment

1. In the Processing Rules Manager, create Processing Rules to: › Push the value of s.contextData[‘page’] into s.pageName › Push the value of s.contextData[‘section’] into s.channel › Push the value of s.contextData[‘subsection’] into s.prop1

2. Do not Save the Processing Rule3. Ask your instructor to check your work

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

18-1

Chapter Eighteen

Mobile Site Tracking

Objectives

• Learn how Mobile Site Tracking works• Write image requests and HTTP requests to pass data into SiteCatalyst• Use the AppMeasurement Library to dynamically create image requests

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


How Does It Work?

If you’re like me, as you look up at the stars at night and stare into the infinite, you ask yourself, “How does mobile site tracking work?” You’re in good company. Let’s take a look and understand how you can send image requests from your mobile site when JavaScript isn’t an option.

Here’s what’s happening:

1. The Mobile Device makes a request for a Web page to the Tower2. The Tower forwards the mobile request to the Gateway3. The Gateway converts the mobile request into an HTTP request4. The Web Server responds to the HTTP request with a page built for the

Mobile Device5. The Gateway sends the page back through to the Tower6. The Tower sends the data for this page to the Mobile Device (there is a hard-

coded image request built into the page)7. The image request is made from the Mobile Device’s browser to the

SiteCatalyst Data Center8. SiteCatalyst records analytics data for the Mobile Site in question

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Mobile Site Tracking Considerations

• How many mobile site visitors might I not be able to track with our current JavaScript implementation?

› See the JavaScript report in Technology• How many mobile site visitors use a device that runs JavaScript by default?

› See the Device types in the Mobile reports › If you choose the JavaScript method you may miss out on tracking many

other devices such as Blackberry that do not have JavaScript enabled by default

› It is perfectly acceptable to track your mobile site using JavaScript if you’re capturing all user activity (most of your visitors use a JavaScript-enabled browser)

• Should I hard code image requests or use the PHP, Java or .NET AppMeasurement libraries to dynamically create an image request?

› The server-side AppMeasurement libraries are a great idea and ease implementation

Mobile Report SuiteIt’s best to capture mobile site traffic on your Mobile Site in a separate Report Suite so that it can be analyzed separately. Consider pushing mobile data into a Global Report Suite as well.

Think about how you wish to analyze your data and then make your move. It’s easy to create new Report Suites to keep your data segmented at a very high level although you can create a segment to view just your Mobile Site data in SiteCatalyst Version 15. If you did combine data from two sites into one Report Suite, consider how Page Names and other values would mesh in non-segmented reports.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Anatomy of a SiteCatalyst Mobile Image Request <img src=”<requesting domain>/b/ss/<Mobile RSID>/<Image

Type and visitorID>/

<code version>/

<random_number>?gn=<Query String>”<Image Attributes>/>

Requesting Domain

The Domain through which the image request is sent (CNAME or Adobe domain)Example:

<img src=”http://jjesquire.d1.sc.omtrdc.net/b/ss/

jjesquireapac/5/WAP/65793524981?gn=Mobile%20Home%20

Page&v0=spring_campaign&c2=handbag&ce=UTF-8&cc=USD” width=“5”

height=“5” alt=“” border=“0” />

Note: You can find the Requesting Domain by running the Debugger on a page with SiteCatalyst JavaScript Code. This is the same as the s.trackingServer value if that value is populated.

Legacy Code

The “ss” stands for “SuperStats”, a former name of Adobe SiteCatalystExample:





Mobile RSID

The SiteCatalyst Report Suite ID that receives mobile site measurement dataExample:





Multiple RSIDs Example:

/jjesquireapac,jjesquireemea,jjesquirelatam/

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Note: You can find the RSIDs by running the Debugger on a page with SiteCatalyst JavaScript Code. You can also see a list of your RSIDs by going to Admin > Admin Console > Report Suites.

Image Type

Image Type (“/5/” indicates a mobile request):

• 5 = returns the default image type (most common value used)• 5.1 = always returns a GIF image• 5.5 = always returns a WBMP image

If you manage your own Visitor IDs (less common), the ID goes here as well. Example:





Code Version

This value can be anything you want, but we’ve set it to “WAP” to indicate that this image request is from our mobile site. In a JavaScript request, you would see a value such as “H.23.4” in this field. This field is very useful for debugging purposes.

AppMeasurement Code Version can be accessed via Processing Rules in v15.Example:





Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Random Number

This prevents Web browser and carrier image caching (Adobe also instructs mobile browsers not to cache images)Example:

<img src=”http://jjesquire.d1.sc.omtrdc.net/b/ss/jjesquireapac/

WAP/5/65793524981?gn=Mobile%20Home%20Page&v0=spring_

campaign&c2=handbag&ce=UTF-8&cc=USD” width=“5” height=“5”

alt=“” border=“0” />

Query String

Predefined and Custom Variables and their values piggyback on the image request that is sent into the SiteCatalyst data center.

Example:





Note: You must URL encode the link. For example, “%2F” for “/”, “%3a” for “:”, “%20” for a space, etc.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Image Attributes

Specifies the image settings – the image beacon should be set to a 5x5 pixel to ensure support for all mobile devices (by default, it’s 2x2).

Example:





Web Beacon PlacementThe Web Beacon must be placed inside the <body> tags of your page whether you hard code your image request or use JavaScript code or other AppMeasurement code to create the web beacon.

Example:

<body>





</body>

Query String ParametersIn order to make image requests or web beacons, you’ll need a complete list of the Query String Parameters used in image request by SiteCatalyst. Each variable has a short Query String Parameter name. In cases where you may need to hard code an image request, keep these tables of Query String Parameters handy.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Viewing Query String Parameters in the Debugger

To view these parameters in the image request, you’ll need to deselect the “Friendly Names” option in the Digital Pulse debugger.

Query String Parameter Usage Example

Let’s take a look at an example of a full-populated image request.


jjesquireapac/5/WAP/65793524981?ce=UTF-8&cc=USD&gn=Mobile%20

Home%20Page&ch=Home&c2=handbag&v5=handbag&v0=spring_

campaign&ev=event7” width=“5” height=“5” alt=“” border=“0” />

Notice the values that are being passed into SiteCatalyst via the query string? The fol-lowing table shows each of the query string parameters, their values and the

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


equivalent JavaScript AppMeasurement code (if you were to populate this values us-ing JavaScript App Measurement instead of hard coding - remember that JavaScript AppMeasurement is used to automate the creation of an image request).

Site Exercise 18.1 Mobile Site Landing Page



• Understand Campaign landing page activity, subsequent traffic and conversion


• Page Views, Visits, Unique Visitors and Campaign instances and Conversion metrics

Assignment

1. Hard code the image request for the Kitchen Essentials Campaign Landing Page using the same variables that you would use on the regular site (access from Mobile Home Page – the partially completed image request is at the bot-tom of the page code)

2. Page Name is “Kitchen Essentials Sale Landing Page”3. Site Section is “Home and Garden”4. Subsection is “Kitchen”5. Campaign is “kitchen_sale”

Custom Link Measurement Without JavaScriptIn certain cases, if you can’t use JavaScript, you may need to hard code image requests for Custom Link Measurement. If you are using a server-side AppMeasurement solu-tion such as PHP, this can still come in handy if that library does not support Custom Link Measurement.

So how in is this done? It’s done by implementing a redirect. SiteCatalyst variables are coded into this HTTP request.

<a href=”<requesting domain>/b/ss/<Mobile RSID>/4/REDIR/

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


?url=<destination_URL>&pe=<link_type>&pev1=<linkURL>

&pev2=<link_name>” >Viewable Link Name</a>

Example:

<a href=”http://jjesquire.d1.sc.omtrdc.net/b/ss/

jjesquirelatam/4/REDIR/?url=http%3A%2F%2Fwww.jjesquire.

com%2Fsize_chart.pdf&pe=lnk_d&pev1=D=url&pev2=size_

chart&ev=event7&v8=Size%20Chart&ce=UTF-8&cc=USD” />Download the

Clothing Size Chart</a>

The pe value or Link Type should be set to one of these three values:

• lnk_d = Download Link• lnk_e = Exit Link• lnk_o = Custom Link

In the previous example, pev1 employs a Dynamic Variable (D=url) to populate the URL (stated earlier in the string) into pev1 in order to shorten the image request (Dynamic Variables are discussed later). pev2 holds link name.

Note: You must URL encode the link. For example, “%2F” for “/”, “%3a” for “:”, “%20” for a space, etc.

Site Exercise 18.2 Mobile Site Charge Card Application



• Understand Charge Card Application Conversion on our mobile Web site (find out if applicants submit the application on our site and continue on to the third-party credit card site)


• Application Completions (event10) for Charge Card Application (s.eVar7)

Assignment

1. Hard code the image request for the Mobile Site JJ Charge Card Application exit link button on the final application page (siteN/mobile/chargecard/jjcard_app2.php).

2. Recording the Application Completion event and the name of the Form (link is at the bottom of the final application page – it’s called “Proceed to Apply”)

3. Some of the values in the request have been filled in for you – double check to make sure all necessary values have been recorded and test your results

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


AppMeasurement Library Option

If you don’t wish to hard code image requests, you can use server-side AppMeasurement Library code to build the image request dynamically for you. JavaScript is part of the AppMeasurement Library, but it is a client-side code (executes on the browser).

If you’ve already decided that JavaScript won’t capture the majority of users that visit your mobile site because they use browsers that do not have JavaScript enabled, you should stick with a server-side AppMeasurement solution to dynamically build your image requests if you do not wish to hard code them.

AppMeasurement Library CodeYou can use PHP, Java or .NET to dynamically build the image request for your Mobile Site (we will train on PHP code in this chapter). To do so go to Admin > Admin Console > Code Manager.

Choose code type

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Access Page Code and Component File

Look closely at the PHP Config Text and you’ll notice that not all variables are in-cluded by default in the page code generated by the Code Manager (similar to the JavaScript code not including s.hier or s.transactionID by default). Some of those vari-ables you’ll need to write in yourself. Review the appropriate documentation on the KB for information on all possible variables for the AppMeasurement Library that you’ve chosen to use.

Server-side ScriptsPHP, Java and ASP.NET are server-side scripts. SiteCatalyst Code implemented through one of these methods do not appear client-side (within the source code of the Web page) as JavaScript appears (being a code that executes client-side). These scripts dynamically create the image request which, by default, does appear in the source code of the Web page and can be read by the Digital Pulse debugger.

PHP Page Code Example<?php

require_once ’OmnitureMeasurement.class.php’;

$s = new OmnitureMeasurement();

/* Specify the Report Suite ID(s) to track here */

$s->account = ‘outrainjjscit04site01’;

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

$s->pageName = ’Men:Accessories:Blue Tie’;

$s->pageURL = ‘http://www.jjesquire.com/men/accessories/blue_

tie.php’;

$s->server = ‘United Kingdom’;

$s->channel = ‘Women’;

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


$s->prop1 = ‘Accessories’;

$s->prop2 = $_GET[‘q’];

$s->products = ‘;Blue Tie’;

$s->events = ‘prodView’;

$s->campaign = $_GET[‘cid’];

$s->eVar1 = $_GET[‘intcmp’];

$s->eVar5 = $_GET[‘q’];

$s->currencyCode = ‘USD’;

$s->cookieDomainPeriods = 2;

$s->mobile = ‘true’;

/* Turn on and configure debugging here */

$s->debugTracking = false;

$s->sendFromServer = false;

/* 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 = ‘dcrookston.d1.sc.omtrdc.net’;

?>

<?php $s->track(); ?>

Note: You must also place the “OmnitureMeasurement.class.php” component file on your server and link to it from your Page Code (similar to the s_code.js file).

Abbreviated Java® Page Code Examplemport com.omniture.AppMeasurement;

AppMeasurement s;

s = new AppMeasurement(); // For Java EE use: s = new AppMeasu

rement(request,response);


s.account = “outrainjjscit04site01”;


s.pageName = “”;

s.pageURL = “”;

s.currencyCode = “USD”;

s.cookieDomainPeriods = “2”;

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute



s.debugTracking = true;

/* WARNING: Changing any of the below variables will cause

drastic changes

to how your visitor data is collected. Changes should only be

made


s.trackingServer = “dcrookston.d1.sc.omtrdc.net”;

Note: You must also place one of the Java component files on your server and use it in conjunction with your Page Code (similar to the s_code.js file). See the “Java® SE and EE AppMeasurement” implementation guide.

Abbreviated ASP.NET Page Code Exampleusing com.omniture;

namespace AppMeasurementExample {

public partial class Page : UserControl {

AppMeasurement s;

public Page() {

InitializeComponent();

s = new AppMeasurement();


s.account = “outrainjjscit04site01”;


s.debugTracking = true;


s.pageName = “”;

s.pageURL = “”;

s.charSet = “UTF-8”;

s.currencyCode = “USD”;

/* WARNING: Changing any of the below variables

will cause drastic changes

to how your visitor data is collected. Changes

should only be made


s.visitorNamespace = “dcrookston”;

s.trackingServer = “dcrookston.d1.sc.omtrdc.net”;

}

}

}

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Note: You must also place one of the .NET or Silverlight component files on your server and use it in conjunction with your Page Code (similar to the s_code.js file). See the “Windows Phone, Silverlight and .NET AppMeasurement” implementation guide.

Important PHP Variables for Mobile TrackingThe “mobile” variable, when set to true:

• Uses the mobile device’s Subscriber ID first before cookies to identify visitors• Sets the image beacon to 5x5 pixels (defaults the “imageDimensions” variable to

5x5)• Measurement library automatically shortens the Adobe image request when

enabled

Example:

$s->mobile = ‘true’;

The “track” variable makes the image request. Example:

$s->track();

Web Beacon Placement for PHP

The Web Beacon should be placed inside the <body> tags of your page (best practice) just as you currently do with JavaScript AppMeasurement code.Example:

<body>


</body>

Site Exercise 18.3 PHP AppMeasurement


Use the PHP AppMeasurement Library to Dynamically Create an Image Request.


• Accurately track Conversion and Traffic site activity on the JJ Esquire Mobile Site using the PHP AppMeasurement Library


• Page Views, Visits, Visitors, Product Views, Page Name, Product Name, Site Section, Subsection

Assignment

• Go to the Women:Activewear:Tie-Waist Puffer Jacket page on the Mobile Site

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Populate Page Name, Site Section, Subsection, Product Name and any pertinent events

Send from Server Variable By default, image requests built dynamically by the PHP AppMeasurement code make their requests through a client’s browser (JavaScript also makes image requests from the browser). This is because the sendFromServer variable is set to “False” by default.

Example:


JavaScript creates the image request by executing code within the browser (client side) while PHP and other SiteCatalyst AppMeasurement languages create the image re-quest server-side and populate the completed image request into the page source code.

JThere is an option to send data directly to the Adobe Data Center from your own serv-ers. To do this, set the sendFromServer variable to “True”.

Example:

$s->sendFromServer = true;

A direct HTTP request with SiteCatalyst variable data is made from the company’s server to the SiteCatalyst server.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


You cannot use the DigitalPulse debugger to debug requests (no image code appears in the source code and the request cannot be viewed with a packet analyzer since it is not passed in client-side).

If you need to debug, set $s->debugTracking = true; to see debugging information on the Web page when sending requests from server (do not leave on outside of develop-ment – it’s not pretty). Debugging info includes request, request headers, response and errors.

.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 18.4 Enable Send From Server and Debug Tracking


Assignment

1. On the Mobile Site Home Page (siteN/mobile/index.php), enable $s->debugTracking and $s->sendFromServer by setting both to true;

2. Check the debug information to verify that variables have been passed in correctly

3. If you run the DigitalPulse Debugger or check the source code, you will notice that there is no client-side indication that the page is being tracked

4. Disable Send From Server and Debug Tracking

Note: It is only possible to see the effects of this exercise on the PHP JJ Esquire site. The HTML version of the site does not reside on a Web server and cannot process PHP.

Making It WorkWhen you need an alternative to JavaScript when tracking your site properties, the AppMeasurement Library has you covered. Keep in mind that not every option that is available ot you in JavaScript may be available to you in, for example, the PHP AppMeasurement Library.

Plug-in Architecture is supported for your own custom plug-ins in Java and PHP (see the AppMeasurement for Java or PHP white paper for more information). You may need to use your own PHP, Java or .NET expertise to replicate some of the plug-in functionality provided to you by Adobe for JavaScript implementations.

Remember that server-side Context Variables can simplify implementation for mobile sites (available for Java and .NET, not available for PHP).

“Plug-in” Solutions in PHP

Let’s go through a couple of examples of how you might replicate some of the things that you do in JavaScript. It’s not difficult; however, it’s much easier with JavaScript AppMeasurement because the code has already been built for you in the form of JavaScript plug-ins that you use in the s_code.js file.

getQueryParam “Plug-in” Example

In PHP, use the $_GET function to pull values from the query string (examples shown are not tested for your site nor approved by Adobe – use as a reference only).

Examples (from the Mobile Site):

$s->campaign = $_GET[‘cid’]; //campaign tracking code

$s->eVar5 = $_GET[‘q’]; //internal search term

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Two campaign parameters with priority for “cid”:

if($_GET[‘cid’]){


} else if($_GET[‘cmp’]){

$s->campaign = $_GET[‘cmp’];

}

getQueryParam “Plug-in” With Delimiter Example

In PHP, use the $_GET to pull values from the query string (examples shown are not tested for your site nor approved by Adobe – use as a reference only, there may be more efficient ways for you to populate certain values).

Example (from the Mobile Site):

$n1 = $_GET[‘n1’];

$n2 = $_GET[‘n2’];

$n3 = $_GET[‘n3’];

$n4 = $_GET[‘n4’];

$n5 = $_GET[‘n5’];

$n6 = $_GET[‘n6’];

$n7 = $_GET[‘n7’];

$n8 = $_GET[‘n8’];

$n9 = $_GET[‘n9’];

$param_array = array($n1,$n2,$n3,$n4,$n5,$n6,$n7,$n8,$n9);

$without_nulls = array_filter($param_array, ‘strlen’);

$delimited_array = implode(‘|’,$without_nulls);

$s->prop11 = $delimited_array;

Note: Use $_POST to grab values sent through a form using the POST method.

Follow Best PracticesRegardless of the AppMeasurement that you choose to employ to track visitor activity on your site properties, you should always follow best practices. Best practices that you’ve learned in the JavaScript implementation are applicable to non-JavaScript im-plementation methods.

Example (force user input to lowercase):

$s->prop2 = $_GET[‘q’]; //internal search term

$s->prop2 = strtolower($s->prop2); // force to lowercase

Example (page names that make sense to analysts):

$s->pageName = ‘Home & Garden:Floor Clocks:Grandfather

Clock’;

$s->server = ‘Mobile Site’;

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Example (avoid illegal characters):

$s->pageName = ‘L’Oréal Cosmetics’; //prematurely closes

statement

$s->products = ‘;205382;1;54,99€’//prematurely starts new

product, illegal use of currency symbol

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

19-1

Chapter Nineteen

Light Server Calls

Objectives

• Understand when to use Light Server Calls• Learn how to create Light Server Calls

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


What is a Light Server Call?

Light Server Calls let you track high-level events (and even eVars) without using a full server call. They are more economical for events that don’t require segmentation or in-depth analysis because they’re priced cheaper than a full server call. You can use Light Server Calls with Version 14 and 15 of SiteCatalyst.

Reasons to Use ThemWhen might you use Light Server Calls? It may make sense to employ them when you need to measure something that is high in volume, when you just need a few metrics about the item in question or when you don’t wish to inflate Visits and Visitors.

Some usages examples are:

• Onsite Ad Impressions• Email open and view through tracking• Offsite Ad Impressions and View-Through Tracking• Rich Internet Applications

LimitationsLight Server Calls are excellent for the aforementioned reasons, but they do have some limitations. They shouldn’t be used in place of full server calls for your Web pages. Some of the limitations are:

• Pathing and Fallout reports are not available• Breakdowns are not available• A segment applied to a report filters out any events set by Light Server Calls• They receive minimal processing by the server

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Click-through vs. View-through TrackingLight Server Calls allow you to start measuring View-through Tracking. Even though visitors may not always click through to your site via your ad creatives, they may still be influenced by viewing (impressions) your ads. This can be measured with View-through Tracking.

What is Click-through Tracking Again?

Click-through Tracking shows you when a visitor clicks the display ad to visit your site (and potentially convert). It’s tracked because the destination URL of the ad creative (a display ad in the example) contains a tracking code which is accessed by SiteCatalyst code on the landing page. This tracking code is then populated into s.campaign.

View-through Tracking

View-through Tracking shows you when a visitor visits your site (and potentially con-verts) after seeing your display ad, but doesn’t click on it. For example, let’s suppose that a visitor sees a display ad to JJ Esquire’s Ski Sale on Monday, but doesn’t click on the ad.

A Light Server Call made from the Web site hosting the display ad will place a cookie on the visitor’s browser with the ad data to record that the visitor saw the display ad (an ad impression).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Later, let’s suppose that the visitor, remembering the display ad that he or she on Monday, goes directly to the Web site on Wednesday. The Web site’s SiteCatalyst code will then look for any Light Server Call ad data, collect it and submit it with the page’s normal image request (full server call).

Through the Light Server Call data captured in this example, the analyst will be able to see that the display ad, although not responsible for a Click-through, was still an influence in the visitor’s purchase based on the View-through recorded. The display ad is certainly a winner (got us a conversion) and so View-through Tracking will en-sure that these ads continue to be purchased by analysts.

If the visitor in this scenario had chosen to click through, special code on the landing page (or in the s_code.js file) can cancel out any Light Server Call profile data (in other words, you should set your code so that Click-throughs win or cancel out View-throughs - Adobe provides appropriate code to ensure that this occurs).

Enabling Light Server CallsTo enable Light Server Calls, contact Adobe® ClientCare to. Together you will need to select a Custom Event to track the Light Server Call, choose additional Events and/or eVars to track (optional), and select a Profile ID to associate with the call (the Profile ID is like the RSID of the Light Server Call).

Anatomy of a Light Server Call (Offsite Display Example)Let’s briefly take a look at each part of a Light Server Call. We learned how to create an image request in the Mobile Site Tracking chapter. Please make sure that you’re already family with that chapter’s concepts.

Code Version

This can be any value, but it must contain some value (e.g., email, display, etc.). In a standard server call, code version would be something such as “H.24”. Remember that AppMeasurement Code Version can be accessed via Processing Rules in v15

Example: <img src=“http://jjesquire.d1.sc.omtrdc.net/b/ss/

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


jjesquire/1/display/s23409583?mtp=ad1&mtss=86400&ns=dcrooks

ton&cdp=2&v1=ad1&v2=campaign_34&ce=UTF-8” />

mtp

Set this value to the Profile ID that you’ve set up with ClientCare (Profile ID is like the RSID of the Light Server Call). The Profile ID will trigger an ad event.



ton&cdp=2&cl=86400&v1=ad1&v2=campaign_34&ce=UTF-8” />

mti

This is the amount that you would like to increment your events (if not included, events are only incremented by one). You don’t need to use this if you’re only incre-menting events by one (basic counter).

mtss

This stores Light Server Call values in a cookie which expires after the number of seconds set in this variable (e.g., 86400 = 1 day).




Note: If the image request is made from a third-party site (not within your Internal URL Filters), you need to include the following to prevent the call from being filtered:

• ns=visitor namespace• cdp=cookie domain periods

These values can be found in your s_code.js or by contacting Adobe ClientCare.




Variable Data

Use the same Query String Parameters that we learned about in the Mobile Site Tracking to populate eVar values.




Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The Rest

Remember to include the other vital parts of the image request that we learned about previously. These include the Request Domain, Legacy Code, Report Suite ID, Image Type, Random Number, Character Set.


jjesquire/1/display/s23409583?mtp=ad1&mtss=86400&ns=dcrookst

on&cdp=2&v1=ad1&v2=campaign_34&ce=UTF-8” />

In the case of this example of a Display Ad, remember that the Light Server Call should be placed on the page on which the ad appears.

Retrieving Light Server Call DataWhen a visitor has interacted with a page that contains a Light Server Call (offsite display, email, etc.), that data is only collected by Adobe when and if the visitor arrives at your site. To collect this data, verify that you include the following code in your s_code.js to retrieve Light Server Call data (or similar code - this is just an example).

You can remove unnecessary “if” statements if necessary (again, the following code is just an example). This code is set to delete any Light Server Call profiles if a “cid” value is detected in the Query String (in the case of this client, a “cid” value detected in the Query String denotes a Click-through negating the need to record any View-through activity):

if(campaign landing page or product) {

if(query string parameter) /* check to see if there

is a direct referral (e.g., check for “cid”). If there is,

discard view through */

s.deleteLightProfiles=”ad1”

else

s.retrieveLightProfiles = “ad1”

}

s.t()

The retrieval code for the previous example would:

• Populate eVar1 with “ad1”• Populate eVar2 with “campaign_34”• Trigger the display ad event (associated with the Profile ID)

Email Light Server CallsEmail Light Server Calls track Opens and View-throughs with email using the same method described for Offsite Display. Opens are counted accurately for all email cli-ents using Light Server Calls; however, View-throughs are only counted for web-based email clients (cookie generally cannot be set for hard drive-based email clients such as Outlook). Remember that Email Click-throughs are still counted using Tracking Codes recorded by SiteCatalyst and function independently of Light Server Calls.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Onsite Display Light Server CallsYou can Track Onsite Display using the standard JavaScript Code (your own code on your own site). You won’t need to hard code image requests since Light Server Calls will utilize the SiteCatalyst code already on you site to build out the Light Server Call.

When might you want to use a Light Server Call on your own Web site? Let’s suppose that you wanted to track visitor impressions for rotating display ads on your home page. If a visitor were to see 10 ads during the rotation, this could be easily recorded with Light Server Calls. This is a much more sensible and cheaper alternative than sending in 10 full server calls to SiteCatalyst.

The code in this example shows a Light Server Call that increments an event for each ad display with an associated eVar with the ad ID:

s.eVar20 = “adID”;

s.lightTrackVars = “eVar20”;

s.trackLight(“ad1”);

The trackLight variable in the previous examples contains the following arguments: s.trackLight(profileID, storeForSeconds = 0, incrementBy =

0, variableOverrides = null)

As you can see from the previous example, you don’t need to populate values in each field/argument of the s.trackLight variable; however, you should always populate the profileID.

In this onsite example, a Light Server Call has been made sending data for two eVars: s.evar1 = “myAdID”;

s.eVar2 = “myCampaignID”;

s.lightTrackVars = “eVar1,eVar2”;

s.trackLight(“ad1”, (60 * 60 * 24 * 5));

/* cookie expiration has been set for 5 days, no

incrementor and no variable overrides */

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

20-1

Chapter Twenty

Site-based Implementation Considerations

Objectives

• Learn about available non-JavaScript Implementation methods• Understand how SiteCatalyst cookies work• Learn how to avoid data loss with redirects

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


More Nitty-Gritty Implementation Stuff

OverviewThis chapter discusses Site-based implementation topics, or in other words, those top-ics that affect your whole site and how and if data is collected (as opposed to specific variables). There are several site-based implementation concerns that you should have including the following. Ask yourself, “Does my site deal with any of the following?”

• Flash or non-JavaScript sites• Cookies• Referrers• Redirects

Each of these topics will be covered in this chapter.

When JavaScript is not an option

Again, for more information about implementing SiteCatalyst with Flash or doing any other non-JavaScript implementation, please refer to the App Measurement whitepapers and the online Implementation Manual.

• Flash & Flex App Measurement• Mobile (WAP) App Measurement• iPhone App Measurement• Android App Measurement• Blackberry App Measurement• Symbian App Measurement• Facebook App Measurement• Java App Measurement• PHP App Measurement

Note: User guides for non-JavaScript implementations available at: Help>Supporting Docs>Manuals>Implementation Guides

SiteCatalyst Cookies 101A cookie is a small piece of data that is set by a Web site to a Web browser. The browser stores this piece of data for as long as indicated in the cookie (expiration). The Web site that originally set the cookie can read the cookie and modify it as needed. Each browser that visits a SiteCatalyst client is set with a special s_vi[ID] SiteCatalyst cook-ie that anonymously differentiates one browser from another.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


This cookie is the basis for counting visitors and conversions on your site. SiteCatalyst uses cookies to identify new visitors, help analyze click-stream data, and track histori-cal activity on the Web site such responses to campaigns, days since last purchase or time passed since the visitor’s last visit.

Cookies set by the SiteCatalyst application are secure and only available to SiteCatalyst. The data is unavailable to any third parties. Since customer privacy is a top priority with Adobe, SiteCatalyst cookies contain no Personally Identifiable Information (PII). Cookie data is completely anonymous.

SiteCatalyst’s Cookie Use

The SiteCatalyst data collection method is more accurate than older, Web log-based solutions for various reasons. First, SiteCatalyst overcomes issues with both proxy and browser caching of pages (which Web logs do not measure). Second, SiteCatalyst mea-sures only pages loaded within a Web browser and not automated traffic such as spi-ders and bots. Third, SiteCatalyst uses cookies to measure visitors, whereas most log file-based solutions rely upon IP addresses; thus visitors are counted more accurately.

This cookie-based system allows SiteCatalyst to know when a person (a unique browser, really) comes back to your site. This gives SiteCatalyst the ability to give you informa-tion like return frequency, visit number, time between first visit and first purchase, etc.

First-Party vs. Third-Party Cookies

Adobe clients can implement either first- or third-party cookies. If implementing with third-party cookies, the domain of 2o7.net or omtrdc.net is used on the cookie. Third-party cookies are more likely to be blocked by security software these days. Therefore, it is much more common to implement with first-party cookies. Implementing this way will use the customer’s domain and just add a subdomain that is specific to the SiteCatalyst tracking, for example, “stats.mycompany.com.” Work with Adobe Consulting to verify that first-party cookies are right for you and how you can correctly configure them.

The following are some technical aspects about cookies being set:

1. Cookies set on the customer’s domain, set by the JavaScript:• s _ cc — cookie check to see if the browser cookis are enabled, contains

the value “true”• s _ sq — ClickMap data, stores ClickMap data from previous page,

100-200 bytes

2. If 3rd party cookies — On the omtrdc.net or 2o7.net domain:• s _ vi[ID] — where "[ID]" is the encoded unique visitor ID

There is a Cookie redirect / handshake if s_cc is true. If s_cc is not true, it means that cookies have been disabled, and that they cannot be used to denote uniqueness of the visitor. In this case, the fallback method, IP/User Agent is used to attempt to track uniqueness of the visitor (although it is not as accurate).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In this case there will be differences in Visit and Visitor calculations, because Visits are ONLY counted when cookies are enabled, but the Visitor count will use the fall-back method of IP/User Agent. Adobe does not engage in the practice of “cross-company” tracking. To ensure the privacy and security of customer’s data, SiteCatalyst uses a separate set of cookies for each site tracked. Additionally, Adobe also offers customers the ability to use their own domain name as the owner of the cookie (stats.yahoo.com for example). This practice creates an extra layer of privacy and security, as it makes all SiteCatalyst cookies “first party cookies,” as discussed above.

One possible downside to First-Party Cookies is that they are domain specific and cannot cross domains. Third-Party cookies can cross domains and in some cases they may be the best solution for you.

Regional Data CollectionRegional Data Collection can reduce image request latency for site visitors that are geographically distant from Adobe servers. The RDC can decrease the chance that cookies will not be set because of long-distance image requests. RDC migration is available for 1st and 3rd party implementations. Those using the 2O7.net domain will switch to the omtrdc.net domain. When a visitor visits a site tracked by SiteCatalyst with RDC-enabled code, image requests are sent to the RDC closest to visitor’s loca-tion and then later forwarded to the San Jose or Dallas servers.

regional data collection option that captures image requests at local data centers and later forwards them to Adobe data centers (san jose or dallas), can reduce latency associated with long-distance image requests

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In the example above, we see a visitor in Germany, visiting a site tracked by SiteCatalyst that has been enabled for Regional Data Collection. This site’s data is collected on the Adobe San Jose server; however, the image request from the visitor’s browser is made to the local RDC in London and the London RDC responds back with the appropriate pixel and cookie.

Data is subsequently forwarded from the RDC to the San Jose or Dallas servers. Latency, if any was experienced before RDC migration, is greatly reduced for the visitor.

ReferrersA Referrer is a third-party domain that has a page with a link to your site which at least one visitor has clicked to access your site. This referring link to your site is count-ed each time it is clicked regardless of whether it begins a session or not.

SiteCatalyst uses the referrers from the Referrer report to calculate Referring Domains, Search Engines and Search Keywords. The Search Engines Report is created from the recorded Referrers based on a built-in list of all worldwide recognized search engines.

Internal URL FiltersNo coding is necessary in order to instruct SiteCatalyst on how to know whether a link is a Referrer (external third-party link to your site) or just a clicked internal link from another page on your site. Setting up the tracking for Referrers is all done through the Admin Console through a feature called “Internal URL Filters” in Edit Settings>General>Internal URL Filters.

In the Internal URL Filters, simply indicate the domain(s) that belong to you. Those domains will not be reported as referrers. For example, for JJ Esquire, we would report jjesquire.com, jjesquire.co.uk, jjesquire.de and all other properties that we don’t wish to count as referrers (keep in mind that from a local Report Suite level, Report Consumers may wish to recognize their own foreign country sites as referrers to the local country site.) Before setting your Internal URL Filters, be sure that you know what Report Consumers expect to see in affected reports.

referrer third-party domain with a link to your site, recorded by sitecatalyst using the document.referrer browser document property

In this case there will be differences in Visit and Visitor calculations, because Visits are ONLY counted when cookies are enabled, but the Visitor count will use the fall-back method of IP/User Agent. Adobe does not engage in the practice of “cross-company” tracking. To ensure the privacy and security of customer’s data, SiteCatalyst uses a separate set of cookies for each site tracked. Additionally, Adobe also offers customers the ability to use their own domain name as the owner of the cookie (stats.yahoo.com for example). This practice creates an extra layer of privacy and security, as it makes all SiteCatalyst cookies “first party cookies,” as discussed above.

One possible downside to First-Party Cookies is that they are domain specific and cannot cross domains. Third-Party cookies can cross domains and in some cases they may be the best solution for you.

Regional Data CollectionRegional Data Collection can reduce image request latency for site visitors that are geographically distant from Adobe servers. The RDC can decrease the chance that cookies will not be set because of long-distance image requests. RDC migration is available for 1st and 3rd party implementations. Those using the 2O7.net domain will switch to the omtrdc.net domain. When a visitor visits a site tracked by SiteCatalyst with RDC-enabled code, image requests are sent to the RDC closest to visitor’s loca-tion and then later forwarded to the San Jose or Dallas servers.

regional data collection option that captures image requests at local data centers and later forwards them to Adobe data centers (san jose or dallas), can reduce latency associated with long-distance image requests

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exclude by IP AddressIn order to not skew the metrics in your own SiteCatalyst reports, you may wish to exclude your employees’ site activity on your site. Through the Admin>Exclude by IP menu, you can exclude up to five IP addresses. You may use wildcards to exclude a range of IP addresses in your company. If you need to exclude more than five IP ad-dress ranges, talk to Client Care about creating a special VISTA rule for IP exclusion.

RedirectsRedirects point the browser to a new location without user interaction. They are exe-cuted at either the Web browser (client-side redirect) or at the Web server (server-side redirect). Since redirects do not require any user interaction, they are often executed without the user ever noticing. The only thing that indicates that a redirect has oc-curred is the browser’s address bar. The address bar displays a URL that is different from the link the browser initially requested.

Server-Side RedirectsServer-side redirects, which are more common than client-side redirects, normally strip the original referring URL. This makes it hard to properly analyze where traffic comes from as it flows to your site.

To rectify this situation, you can send the original referrer along via the query string and then set it into the s.referrer variable, which will override the referrer on the land-ing page. This is shown in the following two steps:

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


1. Capture referrer and include it in query string: www.mysite.com/mypage.htm?origref=www.google.com/pageX

2. Place value into the referrer variable on the eventual landing page:

s.referrer=s.getQueryParam(‘origref’);

3. Also, if any other code is in the destination URL (cid=1234), it must also be forwarded on to the eventual landing page

Note: See the “Redirects and Aliases” white paper Answer ID 543

Client-Side Redirects

These redirects (although less common) can use the same steps as the server-side re-directs, which capture the actual referrer from the header, send it along in the URL, and then push it into the s.referrer variable.

The other option (which is not great but still possible) is that you let the page load long enough to run SiteCatalyst code and then forward the visitor to the eventual landing page. This could be confusing to the end user, as they see the browser move to the new page. Most of the time you want it to happen without notifying the end user.

Dynamic VariablesDynamic variables are shortened identifiers that correspond to SiteCatalyst variables, and which allow you to “copy” values from one variable to another without writing out the full values multiple times in the SiteCatalyst image requests on your site.

Because some browsers limit the maximum length of HTTP GET requests (of which the Adobe image request is one), using dynamic variables can help ensure that all de-sired data is captured by reducing the length of the request to Adobe servers in cases where data is duplicated across several variables. The variable abbreviation used must match the variable parameter name passed in the image request.

Common uses:

• Shorten the length of image requests when populating the same value into multiple variables on the same page

• Use the same parameter that occurs in the current image request

NOTE: If the meta redirect is on another

domain, leave the domain name out of Internal URL Filter list; it will be captured via normal referrer reports.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Populate SiteCatalyst variables from your own site cookies to drastically reduce image request length (available for first-party cookie SiteCatalyst implementations)

Values set directly by the SiteCatalyst JavaScript can be set into Custom Traffic or Conversion Variables using Dynamic Variables.

Examples:s.prop16=s.getTimeParting(‘h’,‘-7’);

s.eVar16=“D=c16” /* D means Dynamic Variable, c16 is the

parameter for prop16 */

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


s.pageName=“Home Page”

s.prop12=“Silver Member”

s.prop13=‘D=c12+“:”+gn’ /* Concatenate segment and Page Name

for pathing */

s.campaign=“goog_ad_7”

s.eVar20=“D=v0” /* captures the tracking code in eVar20 (the

client could set different allocation and expiration for

eVar20) */

s.prop20=“D=User-Agent” //captures the user agent string

s.transactionID=“D=pi” //captures the Purchase ID in

Transaction ID

s.prop21=“D=User-Agent” //captures the user agent string

s.prop32=“D=cc7” /* captures value in cookie named “cc7”

(possible in first-party SiteCatalyst implementations –

useful for sending campaign names, user IDs or any other

values that you set into a cookie) */

Help with Dynamic Variables

Keep in mind the limitations of variables before copying from one to the other (e.g., passing and eVar value to a prop, don’t forget that props are case sensitive and only accept up to 100 bytes of data). For more information on Dynamic Variables, see Knowledge Base Article 10099.

Exercise 20.1: Working with Dynamic Variables

Effeciently code for the following scenario using Dynamic Variables. Write the an-swer in your workbook.

1. Page Name is “Womens:Accessories:Hand Bag”2. Section is “Womens”3. Subsection is “Accessories”4. Hierarchy is “Womens:Accessories:Hand Bag”5. Search term is “Hand bag” and should be captured in a prop and eVar6. Campaign Name is “Spring Accessories”7. Effeciently code to capture Page Path by Campaign Name in s.prop20

Solution

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


________________________________________________________________

________________________________________________________________

________________________________________________________________ ________________________________________________________________

________________________________________________________________

________________________________________________________________ ________________________________________________________________

________________________________________________________________

________________________________________________________________

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

21-1

Chapter Twenty-One

Data Import and Export Tools

Objectives

• Learn about creating new reports called Classifications• Learn how to insert off-platform data into SiteCatalyst• Learn various ways to extract data from SiteCatalyst

We’re almost done. You can do it! (And this chapter is pretty interesting too!)

OverviewSiteCatalyst is flexible enough that you can import data into it and export data from it. In order to import or export data, Adobe offers the following tools:

Importing

• SAINT Classifications• Data Sources• Adobe Genesis

Exporting

• Data Warehouse• Data Feed• Adobe Discover• Adobe Report Builder

Each of these import/export options is explained in detail in this chapter.Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


What are Classifications?

Classifications is the process of grouping granular data in your SiteCatalyst reports to make analysis a whole lot easier. You group things in everyday life already, so we hope this concept isn’t to much of a leap.

For example, you may group foods in your refrigerator (vegetables go in the veggie drawer, meats in the meat drawer, condiments in the fridge door shelves and every-thing else goes by the milk). You may group your songs on your computer with pro-grams like iTunes or others (the Beatles’ song “Strawberry Fields Forever” belongs to the group “1967” in the “Year Column”, “Rock” in the “Genre Column”, “The Beatles” in the “Artist Column”, “Magical Mystery Tour” in the “Album Column”, and “Five Stars” in the “Rating Column”).

So why would I want to group values in my reports? Have you ever looked at a report with thousands of values and thought to yourself, “How can I ever make sense of so much data?” If you haven’t, our guess is that you will.

What Should I Group?

Since we just finished discussing Campaigns in the last chapter, imagine that you’re looking at the Tracking Code report surveying your success. You’re trying to glean information from these reports so that you can speak intelligently to your marketing team and decide how to reallocate funds to optimize your marketing efforts.

Where do you start? You’d like to analyze display/banner ads, but they’re mixed in with email, partner, text ad and social media campaigns. How do you make sense of the masses? The answer is by creating groups you wish to analyze so you can study them separately. If you wish to analyze your display, text ad, partner, social media and email campaigns separately, let’s create a report called Media Type that devotes one line item to each of the aforementioned campaign media types that you employ

Wish to delve a little deeper? We could create a report called Display Color, another called Display Size, others called Campaign Name, Email Send Date, Campaign Time Period, and the list could potentially go on and on. And we’ve only spoken about Campaigns. What about grouping your Products reports? Imagine being able to see how the Electronics products did in comparison with the Home & Garden products?

Which groups should you create? That’s dictated by the values that you wish to group. This is going to require you to think about what your analytical needs are. Think back

classifications new reports created by grouping very granular data from a source report

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


to any frustration you’ve experience while perusing reports. Does any of that frustra-tion stem from reports that are a bit too granular? Then Classifications are probably the solution.

It’s Retroactive and Easy

Adobe SiteCatalyst doesn’t analyze the data for you, that’s your job, but we want to deliver it in forms that facilitate your analysis. With Classifications, you have com-plete control over the groups. In fact, if you collected data a year ago, but you just thought of new groups to create, you can retroactively group. No need to plan ahead. Classifications is a pretty forgiving tool.

If uploading data to SiteCatalyst sounds scary, you’ll upload your own Classifications before this chapter is over so that you can experience first-hand the ease of the pro-cess. Even if you make a mistake, it can always be overwritten with a new Classification (just make sure that you know you’ve made an error so that it can be corrected).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


A Few ExamplesClassification Example 1: Products

Let’s imagine that you run the prestigious JJ Esquire Web site. You have thousands of amazingly expensive products, and when someone purchases a product on your site, you have the proper code in place to capture the purchase information and send it to SiteCatalyst. By running a Products report in SiteCatalyst, you can see which prod-ucts sold (or are selling) the best for the chosen time period.

You are, however, a victim of your own success. And I’m not talking about tripping over gold bricks carelessly stacked in the south wing of your home on your way to your underground horse track. You have thousands of products, and although you can see the top 50 pretty easily and identify your top sellers, you may have a group of other products that are not top sellers, but collectively they may be supporting your whole business. How do you learn about them? Classify!

While analyzing this product data, you might already be asking questions like these:

1. How are different brands performing?2. How are different product departments performing?

To answer the first question, you may want to find out if Swiss Rocks products are outperforming Charrel or D&B products. For the second question, you may want to compare Gifts & Home product sales to Womens and Jewelry & Accessories products sales. Technically (if you want to get crazy) you could look through every line item in the report and add up the numbers every time you asked these questions. However, Classifications allow you to group these line items automatically. So instead of guess-timating, do yourself a favor and set up your Classifications as soon as possible!

For example, after going through the classification process (discussed next), you could run the Brand report to show all revenue for all of the products, grouped by Brand, in real time. Now that’s convenience!

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In addition to the Brand report, you could create any other Classification reports that would help you understand the products on your site, like Category, Sub-Category, Style, Size, etc.

As you will see later in this chapter, to create these new reports, you simply need to create the Classification and upload the grouping or meta data. You can think of it as a simple grid, as the following image shows.

In this example, if you capture SKU numbers in the site code when someone buys something, you can later group the SKUs by any of the group values listed in the head-ers of this grid. For example, in the Manufacturer column, you will assign each SKU (Key) a manufacture name. You will also fill in data for all of the other cells in each column of this lookup table and upload them to SiteCatalyst.

Features of ClassificationsBefore we view more classification examples, take note of a few of the awesome advan-tages of using classifications:

• Free custom reports—There is no cost associated with creating and using classifications. This might be your favorite thing about them, right?

• Unlimited —You can have as many classification reports as you want that help you get good information about your “key” or classified data.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• No coding needed— When you create the classification reports and apply the data, no coding is needed. This means that you won’t have to beg IT for resources to get all of the extra reports that you need. Beauty, eh?

• Retroactive data— Because the metrics belong to the key (the value actually being passed into the site, like the SKU number in the example above), you don’t have to panic about thinking about all of the classifications that you might ever need. The classification reports are retroactive, and so you can build them only when you need them, and then run the reports for times in the past, as long as you were capturing the key.

• Breakdowns— Since all of the classifications are in the same lookup table, you can break down all of the reports by each other. In addition to that, the classifications inherit all of the breakdowns that the parent (key) report has, so you can break them down by other reports as well. For example, since you can break down the Campaign Tracking Codes report by the Products report (to see which campaigns sold which products), you will also be able to break down the Tracking Codes report by classifications, such as product group. This means you can see which kinds of products are being sold by different campaigns, or even campaign types.

• Metrics— Like the breakdowns, the metrics in classification reports are also inherited by the parent (key) report. So when you place a Product Views metric into the Products report, you will also have that metric available in all of the classification reports. This means you will be able to see which kinds of products people are looking at the most, adding to their cart the most, buying the most, etc.

Seriously, it really doesn’t get any better than this. It is probably the coolest and most powerful segmentation tool out there, and it’s especially cool that it is free.

Classification Example 2: Tracking Code

Classifications were mentioned at the end of the last chapter, and a lot of Tracking Code examples were given at the beginning of this chapter, but let’s talk about Tracking Codes again. This is probably the most commonly classified report of any of the Reports in SiteCatalyst.

• What You Have When a visitor clicks through to your site through a campaign creative such as an email link, a text ad, a display ad or any other type of campaign, each link contains a tracking code that you or someone else in your company has appended. The free plug-in called “getQueryParam” has been installed on your site and is not automatically grabbing the tracking code and setting it into the s.campaign variable. You now have conversion for each and every Tracking Code.

• Wouldn’t It Be Nice ...to be able to know the Campaign Name, Campaign Dates, Media Channel, Search Keyword, Banner Size or even the Creative Owner?

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Classification Example 3: User Login

In the third example, imagine that you are in charge of a company Intranet, and you are trying to determine which departments are using your Intranet to its fullest potential.

• What You Have When employees log into the Intranet, you have their network login credentials, so you can take their login name and place it in a custom variable in SiteCatalyst. This will allow you to see which employees are using the Intranet. The only problem is that you have thousands of employees, and you don’t even know the people, let alone which department they are in.

• Wouldn’t It Be Nice... ...if you could create reports according to Department, Location, Level, etc.? You could see which groups of people are using the Intranet most often and do all of this retroactively. Since you’ve always captured employee login names, you can apply the Department, Location and Level of each employee by using Classifications. Since the Classification data is tied to the Key value (employee login), your new reports will go back as far as the original report (the Key value). So if you’ve been capturing employee logins for two years, your new Department, Location and Level reports will also go back two years!

Classification Example 4: Time Codes

For this next example, imagine that you decide to populate a custom variable with a code that represents the exact minute of the year (you may have written a script to ac-complish this or requested help from Adobe Engineering Services to write a VISTA rule for you). You could then classify that time code to gain more insight into traffic and conversion for various time periods throughout the year, over and above what the SiteCatalyst built-in calendar can give you.

• What You Have The time code would get credit for the traffic or the conversion. For example, 8:47 a.m. on December 19, 2008, might be represented this way: 200812190847 This would populate a report with codes that would be very difficult to decipher in real time, especially because there would be only one available for every minute of the year.

• Wouldn’t It Be Nice . . . . . . to be able to put the codes into groups so that you could analyze chunks of time (groups of minutes) and see when conversion occurred on your site by grouped time periods? By classifying the minutes into the day of the week, weekend vs. weekday, hours, half-hours and even quarter-hours, you would be able to know which products sell the best on certain days of the week, which campaigns drive the most traffic during a certain hour of any day, which hour of the weekend was responsible for the most traffic and even which quarter-hour saw the most conversions on Mondays. This is very powerful data!

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Classification Example 5: Page Names (use with Version 15)

For this last example, suppose that you’d like to group all of your Pages by Site Section, Subsection or maybe by the type of page content or author (very useful for media sites). This can be done in both SiteCatalyst 14 and 15, but is best used with Version 15 because the latter version will give you accurate Visit and Unique Visitor metrics (Version 14 and 15 both provide accurate Page Views for these classification groups).

• What You Have A visitor comes to your media site and reads stories in the Economics and Sports sections by various authors. You record the Page Name of each page viewed by the visitor.

• Wouldn’t It Be Nice . . . . . . to be able to know which article content types are most popular on your site? Wouldn’t it be great to group these articles by their position within the site hierarchy such as Site Sections and Subsections? Wouldn’t it be nice to know how many Unique Visitors one of the content authors attracts each month to his or her articles?

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Creating Classifications in the Admin Console

Now that you’ve seen the power in the concept of Classifications, let’s talk nuts and bolts.

The first step to create Classifications is to add the Classifications report names in the Admin Console. Go to Admin>Report Suites>Edit Settings>Conversion>Conversion Classifications. You’ll need to select a Report Suite at the Report Suite level. Traffic Classifications are available at Admin>Report Suites>Edit Settings>Traffic>Traffic Classifications.

These two areas exist because Traffic and Conversion variables (and by extension re-ports) function and behave differently. We’ll learn more about custom variables in the next chapter.

Next, select the variable that you wish to classify. You should see a list of all of your Conversion Variables in Conversion Classifications and Traffic Variables in Traffic Classifications. Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


After selecting a variable (meaning report) to classify in Select Classification Type sec-tion, you will automatically see all of the Classifications currently assigned to the vari-able. By default, there shouldn’t be any Classifications for any variable except for Campaigns. By default, the Campaigns variable comes with two Classifications avail-able for your optional use: Creative Element and Campaign.

Add classifications by mousing over the icon next to the variable name, and selecting Add Classification. Always add Classifications to the root (the variable) never to other Classifications. You can also edit and delete classifications in this section.

After clicking Add Classification, select a Classification type (Text is the default), name the Classification and click Save. Do not populate drop-down list (used with a legacy tool called Campaign Management).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Each Classification that you create is a new report that will hold your data. Each of these reports appears in the Adobe SiteCatalyst interface. When you create the new report, it’s empty initially. Later in this chapter we’ll discuss how to push data to these new reports.

Once the classifications are added, new reports appear with the same classification name in the data set’s report section. This is where you will generate your classified reports.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Date Enabled ClassificationsAny Text Classification can be Date Enabled. This allows you to assign a date range to your Classification values and view the values in a Gantt Chart.

If you do not wish to view your values in a Gantt Chart in SiteCatalyst, then you are not required to use this option. If you simply wish to create a Classification that shows the date ranges of your campaigns in a line-item report, you can use the default Text Classification without selecting the “Date Enabled” option.

One Final Reminder on Classification Creation

Classifications should always be created from the root value, i.e., the variable (think report) that you are classifying. Let’s suppose that I’d like to add another Classification report to Campaigns called “Target Audience.”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


This new Classification should be added directly to the “Campaign” variable or root. You should not add the Classification to another Classification. Adding Classifications to other Classifications is a legacy option that is not recommend by Adobe Training Services. Even if one classification is subordinate to another in your mind, both should still be based off of the root value. Your classifications should be siblings with just one parent.

In this section, we’ve mostly focused on creating Classifications for Campaigns, but this can be done for Products and other Traffic and Conversion Variables including all Custom Variables as discussed in the beginning of the chapter.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Using SAINT to Upload and Download Classification Data

“SAINT”, or the SiteCatalyst Attribute Importing and Naming Tool, is, simply put, the upload and download tool for your Classification data.

How to Access SAINTTo find the SAINT interface, go again to the Admin menu at the top of the Adobe Digital Marketing Suite interface. Then click on SAINT Classifications. This is the entry point into SAINT for any Classification type, including Products, Campaigns, Custom Traffic and Custom Conversion Variables.

Steps to Use SAINTThe main steps for using SAINT for classification data upload are as follows:

1. Download a SAINT template OR Export SAINT data.2. Fill out the SAINT data file (add or modify classification data).3. Upload the SAINT file into SiteCatalyst.4. Enjoy your new reports.

SAINT Step 1 (Option A): Download a blank SAINT Template

You can download a blank SAINT template (it contains Classification headers, just no data) from the Download Template tab of the main SAINT page. Downloading a SAINT template gives you a SAINT file that contains only column headers, including a Key header (the original report data) and one header for each classification (your new reports tied to the original key report). Download this blank file to view the

SAINT The bulk upload

tool used to populate classification reports.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


SAINT headers and data. It’s best to be familiar with a file that has no data so you know what to not erase when you do have a file full of data.

OR

SAINT Step 1 (Option B): Exporting a populated SAINT Template

If you are classifying existing data (data that has already been captured on your site by SiteCatalyst), then this option may be a little bit easier since captured data will appear in the key column for the period that you’re downloading.

Still, use this option with mild caution because if you wish to classify a Tracking Code that belongs to a creative that’s never been touched by any visitor, then that tracking code won’t appear in the SAINT export file (if a text ad on a search engine that links to your site has never been clicked by a visitor, then the Tracking Code that identifies that text ad has never been passed into SiteCatalyst).

It’s not going to destroy your data if it isn’t classified, but when that rogue tracking code finally does get captured by SiteCatalyst, it won’t belong to any groups in your classification reports. Of course you can always go back and classify it later when it does appear. Ideally, if you have your own in-house list of Tracking Codes (which you should since you created them), you can copy and paste that into the SAINT Template instead. You decide what is easiest for you.

When exporting data from SiteCatalyst via SAINT, you do not have to export and work with the entire data set. In the export dialog, there are filter options that allow you to limit the data that you are exporting.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


These filters can be very helpful, because you might have thousands, tens of thou-sands, or potentially hundreds of thousands of rows in the data set. The filters allow you to quickly download specific rows and add or update data.

FTP Export Option

In addition to the Browser Export option, you have an FTP Export option as well. This can be crucial if you need to retrieve a large number of rows. Sometimes browsers can time out when retrieving a large file. If you suspect your file may be larger than 1 MB in size, you should use the FTP option.

Would You Like Data With That?

Remember, each time that you download a SAINT Template, you can use the “Download Template” option to get a blank template (with SAINT data headers) or the “Export File” option to retrieve a template that contains previous Classification data and new site information.

SAINT Step 2: Add or Modify Classification Data

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Once you have exported your data file, you can modify your classification data within the SAINT file. It is important to remember that SAINT data files are tab-delimited text files.

Analysts frequently use a spreadsheet application such as Microsoft Excel to open, add data to and modify SAINT files. Regardless of the editor you choose, files must be saved in tab-delimited (.tab) format (or .txt extension, but still in tab delimited for-mat). Comments can be placed anywhere in a SAINT file and are distinguished by “#” at the beginning of the line.

If SAINT encounters “#” at the beginning of a line, all data in that line will be ignored by SAINT. Any lines that begin with “## SC” are SiteCatalyst headers and can be ig-nored. If you are going to copy and paste a SAINT file into another file, don’t forget to add the header information at the top of the file. It includes information indicating into which Report Suite the data should be imported.

The image below shows an exported SAINT file in Microsoft Excel. This contains classification data. If we had downloaded a blank template, rows 5-26 would be blank. Rows 1-3 contain the file headers. Row 4 contains the Key in Column A (the original report) and each Classification report title appears in Columns B through I in this example.

There is always a Key column header in a SAINT file. The line items under the Key column header are the unique items to be classified. In the Campaign example above, the Key column contains Tracking Codes. Each Tracking Code is assigned to a differ-ent group in each of the Classification Reports. In review, if you download a SAINT template, the Key will be empty. If you export a SAINT file, the Key will be populated with data that SiteCatalyst has already captured.

To modify or add your Classification data, simply add the data value that belongs to the original report under the Key header (again, if you have exported the SAINT

NOTE: Remember to save the file in tab-

delimited (.tab) format (or .txt files). SAINT does not process native Excel (.xls) files.

NOTE: You cannot create new

Classifications in the SAINT Template. You must first create them in the Admin Console, as we did earlier in the chapter, and download the SAINT Template again..

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Template, values captured by SiteCatalyst should already be populated). Then fill out the correct classification data across for each data set item.

Campaign Example

Below is an example of a Campaign Classification reprinted again on this page for our examination. Let’s take a look at the Tracking Code “bing_3” on row 21. In the new Campaigns report (a Classification in Column C), we’ve assigned “bing_3” to the “Fall Suits” campaign. Any conversion (purchase, subscription, registration, etc.) as-sociated with “bing_3” will now be grouped into the “Fall Suits” line item value in the “Campaigns” report. Pretty nifty, don’t you think?

This same Tracking Code has been assigned to the “PPC Keyword” group in the “Channel” report (Column E). In the SiteCatalyst interface, when you later run the “Campaigns>Tracking Code>Channel” report, all conversion associated with “bing_3” will be grouped into the line item value “PPC Keyword” in that “Channel” report. Remember, you’re really just building a big lookup table with SAINT.

It really is one of the most useful tools you’ll use extensively in SiteCatalyst.

Once you’ve filled out all of the Classification values to your satisfaction, the next step is to upload the data into SiteCatalyst for processing and storage.

Reality Check

The reality is that you will not want to (or have the time to) type all of the classifica-tion data into the SAINT file by hand. Instead, you will want to somehow automate the system to create the file for you. At the very least, you will want to copy and paste values into the SAINT file, unless you are working with a very small and new data set every week or so (then maybe you could type it in). Otherwise, look for ways to auto-mate this process. In fact, for some clients, the types of data and availability of data help them determine which classifications they choose to implement in the first place.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


SAINT Step 3 (Option A): Using Browser Import to Upload the SAINT File

After you have completely populated the SAINT file, you are ready to upload. Go to the SAINT interface at Admin>SAINT Classifications.

1. Save the SAINT file in tab-delimited format2. In the SAINT interface, select the “Import File” tab and “Browser Import”3. Select the correct “Report Suite” and “Data Set to be Classified”4. Locate the SAINT file on your hard drive5. Select your “Import Options”6. Click “Import File”

If your file is over about 1 MB, use the FTP Import option (discussed later) instead of the Browser Import option.

Overwriting Data on Conflicts

There is one very important option on import that you should consider. In the “Browser Import” interface, notice the “Overwrite data on conflicts” in the “Import Options” section near the bottom.

This option sounds scarier than it is. The data that is going to be overwritten is the classification data, which you DO want to overwrite. It’s basically asking if you want to put new data in, or if it should ignore the data if the key is already in the system. You will almost always want to check this box. One exception would be when it is simply easier to upload a large data set and you wish to push new data in and com-pletely ignore the data rows that are already in the system. This is not a common scenario. Bottom line: go ahead and check that box. If you make a mistake, you can do it again and change the Classification data.

One exception: If you put Classification data into a field and upload it and then decide that it’s incorrect, you cannot currently overwrite the data in the system by uploading an empty string. You would have to overwrite it with some new value (a blank field means that the Classification is not modified).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


How Do I Reset a Classification to “Empty” Through SAINT?

You may then ask, “Can I just delete the value instead of overwriting?” This is helpful if you accidentally set a Classification that never should have been set. For example, suppose that you indicate that text ad “bing_3” has a Banner Size of 728x90 in the “Banner Size” report. You likely only intended to group Banner Tracking Codes in that report and not Text Ad Tracking Codes.

Adobe offers several ways for you to “blank out” SAINT Classification values, de-pending on the scope of data that you want to remove. Each of these ways is described below.

If there are specific classification values that you intend to remove (and others that you intend to keep), you can enter a value of “~empty~” (a tilde, followed by the word “empty,” followed by another tilde with no quotation marks) in the field being re-moved. For instance, if you are working with Campaigns and want to clear out the Banner Size value for the Tracking Code (Key value) of “bing_3”, then you would lo-cate this tracking code in the Key column, move over to the “Banner Size” column and type ~empty~. You would then upload the file, and the Banner Size value would be removed.

You can also contact Adobe ClientCare and request to have the Classification flushed. There is no charge for this service, but it takes time to arrange and should not be used frequently.

Our Campaign Example

Once you have downloaded the SAINT file and filled it in with the classification data (probably programmatically), you are ready to upload. As stated above, if it is a big file, FTP it to Adobe instead of using the Browser Import. Make sure that you set the cor-rect “Data Set to Be Classified” when uploading. The default is Campaigns, but if you try to upload Product Classifications and you forget to change the “Data Set to Be Classified” to products, your upload will fail.

SAINT Step 3 (Option B): Using FTP Import to Upload the SAINT File

As stated previously, you can use the FTP Import option to upload SAINT files that are greater than 1 MB. Using the FTP Import option, you can upload up to 50 MB of data. The SAINT FTP limits you to 30 MB files, so you can break 50 MB of data into a 30 MB SAINT file and a 20 MB data file satisfying both the limits of the SAINT file (30 MB or less) and of the FTP server (50 MB). Now that’s a pizza!

Processing Time for large SAINT files varies by file size, but in general almost all files of allowable size will be processed within 72 hours

Creating a SAINT FTP Account

In preparation for a SAINT file upload using the FTP Import option, you must first create a SAINT FTP account. It’s not difficult, we promise. To do so:

1. Select “Import File” in the SAINT Classifications menu

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


2. Click “FTP Import”3. Click “Add New”4. Name the FTP Account (this is important if you’re using FTP Import for sev-

eral different Classifications, so make it descriptive)5. Set the proper “Data Set to be Classified”6. Indicate which Report Suites should be classified (you can apply your

Classifications to multiple Report Suites!)7. Select your “Import Options” (remember, “Overwrite data on conflicts”

should generally be selected)8. Provide an email so that we can notify you when processing is complete9. Authorize the Classification as you’ve configured it10. Click “Save”

Sign into the your SAINT FTP Account

After you’ve created your SAINT FTP account, use the FTP Account credentials pro-vided to you to sign into the FTP server.Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


To upload your SAINT file, you can manually upload the Classifications using the FTP client of your choice such as FireFTP for FireFox, FileZilla or others. You or your IT developers may wish to write a script to automate uploads as well.

The .fin File

When you upload using the FTP Import option, you always need to follow up your SAINT file upload with a “.fin” file of the same name. This tells SAINT that you’re FINished with the upload. You do not need to do this with the Browser Import option. It’s only done with the FTP Import.

The “.fin” file needs to be a blank file with the EXACT same name as the tab-delimit-ed SAINT file. The only difference is that it must have a true “.fin” extension (no quotes). In other words, if I upload “classifications.tab” via FTP Import, I’ll need to later upload a blank file called “classifications.fin” to tell SAINT to start processing the first file. Be sure that you truly give the second file a “.fin” extension and that you don’t just push “.fin” into name of the file resulting in “classifications.fin.txt” or some-thing similar.

Remember that you must:

1. First upload the tab-delimited SAINT Classifications file2. Then you must upload a blank “.fin” file with the same name as the tab-

delimited file in order for SAINT to start processing your Classifications

In the following image, the SAINT file and “.fin” file are being uploaded using FireFTP, a FireFox Web browser plug-in.

NOTE: If you choose

to submit your SAINT Classifications file via FTP, don’t forget the .fin file (the .tab file isn’t processed until the .fin file is received). The empty .fin file should have the same name as your .tab classification file, the only difference being the extension (.fin). Example: upload myclass.tab first, then myclass.fin second.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


SAINT Step 4: Enjoy Your New Reports

The following examples show Classification reports for Campaign Tracking Code (Campaign Name and Delivery Tool) and also for Products (Product Department and Brand).

All of the values in these reports came from a SAINT file. If you want to change any of the values, you can simply go back into the SAINT file (export), make changes and then upload the new version (remember, you’ll need to overwrite on data conflicts). Classification data is completely retroactive going back as far as the original report values (the Key values), so you can create a Classification today that groups data from the distant past whether that’s last month or last year.

What is This “None” Value?

Keep an eye out for the “None” value in Classification reports. This generally means that certain values haven’t been properly classified. It can also be a completely legiti-mate value in your reports.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


For example, in the “Delivery Tool” report, the “None” value makes sense because some of our Revenue comes from visitors that don’t click through our Campaigns (which have been rolled up and grouped into “Delivery Tools” in this report). Some visitors come directly to the site and purchase. In the Campaign report and any of its Classification reports, that Revenue shows up on the “None” line.

However, in a Product Classification, the “None” value may not make sense unless you have any other Revenue generating Success Events (conversion actions) that are not associated with any type of Product. If Revenue is always assigned to a Product on your site and a “None” value appears in a Product Classification report, it probably means that you have new Products that have not yet been assigned to a classification group.

When in doubt about how your site was implemented, speak with your Adobe SiteCatalyst developers (likely your IT group or an agency that you work with).

Classification Hierarchies

As an experience Adobe SiteCatalyst analyst, you’re familiar with the concept of re-port breakdowns. You may remember that Conversion Reports in SiteCatalyst have a limit of two breakdown levels. This means that you can break down the Products re-port by the Campaigns report (two reports), but that you cannot break down the Products report by both the Campaigns report and the Custom Loyalty report at the same time (three reports are a no go).

This limitation of two reports for Conversion Breakdowns (also called Subrelations) is also enforced for Classifications that are based off of the same parent report. For ex-ample, let’s suppose that you have Product Classifications called “Product Department”, “Product Category” and “Product Subcategory”. Even though these three reports are based off of the same report, only two of these three Classifications reports can be broken down by each other at the same time.

The way to get around this (and you may be saying to yourself, “But isn’t this just one report? It’s not even two.”) is to use Classification Hierarchies. With this tool, you simply indicate the hierarchical relationship between different reports. Once you’ve done this, line items within a report that has been enabled with Classification Hieararchies will contain a drill down icon in the shape of a “+”. Simply click the icon to drill down into the next subordinate report.

Click on the “+” to drill down

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Classification Hierarchies in a Products Report

In this example, we’ve drilled down from the “Womens” line item value (in the “Product Department” report) to the “Handbags” line item (a value subordinate to the “Womens Product Department” in the “Product Category” report. From there, we’ve chosen to view just the Hobo Handbags by select “Hobos” (in the “Product SubCategory” report) and now we can see all products along with their Conversion Metrics in Womens>Handbags>Hobos.

We’ve essentially broken down four reports by each other using this method! This also makes analyzing data groups much simpler for the analyst. This can be done with any value that, in your minds eye, has a hierarchical structure in the reports.

All SiteCatalyst reports that have been enabled with Classification Hierarchies will display a Classification Hierarchy symbol next to the Report Name in the interface.

Symbol indicates the presence of Classification Hierarchies in the report

Creating Classification Hierarchies

Classification Hierarchies are created in Admin>Report Suites>Edit Settings> Conversion>Classification Hierarchies.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


In the Manage Classification Hierarchies section, select the report for which you wish to build a hierarchy. “Product” is selected in the example below. Current Product Classifications appear on the right side of the “Classification Hierarchy” field. Drag and drop desired Product Classifications into the Classification Hierarchy field in the order of hierarchy.

In our example, not all of the Classifications will work in our Classification Hierarchy such as “Brand” and “Country of Origin” so we’ve left them out.

After a long chapter, it’s time to put our knowledge to the test. Let’s try to classify the Products report. Keep in mind that the concepts that we learned about with the Campaign Classifications apply to Product Classifications as well.

Exercise 22.1: Create Product Classifications

1. Under the direction of the Instructor, create a Product Classifications of your choice (prepend your initials to your classification):

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Manufacturer• Brand• Product Category• Product Color• Make up some great new grouping to help you gain insight into your products

Hint: Product Classifications can be found in the Admin Console under Report Suites >Edit Settings>Conversion>Conversion Classifications.

Note: Make sure to create each classification from the Product root, NOT from other classifications. See the Instructor for more details.

Cleanup Time

2. Once the instructor has checked your work, delete the classification(s) that you created. Be sure to not disturb any of the other classifications.

Exercise 22.2: Upload Classification Data with SAINT

Under the direction of the instructor, upload Brand classifications for Products.

1. Go to the SAINT Classifications interface under Admin>SAINT Classifications

2. Under “Export File”, export the Product data set and view in Excel3. Populate the “Brand – Student Use” classification (your instructor will assign

you specific product rows to classify – invent your own brand names)4. In the SAINT Classifications interface, select the “Import File” option and

then the “Browser Import” option5. Set the appropriate “Report Suite” and “Data Set to be classified” 6. Select the SAINT file to import from your hard drive7. Check the “Overwrite data on conflicts” option8. Click “Import File”9. Run the Product “Brand – Student Use” classification report to see the new

data

The Tech Perspective

This tool, along with some of the other tools described in this chapter, might be uti-lized more by a SiteCatalyst Admin, a marketing person, or perhaps an analyst within your company. However, as Technical Lead, you could be involved in helping define and automating this process. Here are a few things that you might be involved in when it comes to Classifications and SAINT:

• Capturing unique values in the code from a page that will later be classified• Automating the creation of the classification file, pulling information from

other systems• Automating the upload of SAINT files via FTP

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Other Data Import Tools

Data SourcesSometimes conversion and other important events take place offline. There is cer-tainly important activity that occurs before a visitor hits your site and after a visitor leaves your site. Data Sources makes it possible to upload new metrics and data that come from offline sources. The purpose of this is to give you a 360 degree view of your conversion process.

Bank Loan Scenario

Let’s think about a bank. Before a visitor lands on the bank site, he or she may do searches on a search engine. Let’s suppose that the visitors clicks through a Paid Search Ad leading the visitor to the bank. The visitor started down the conversion path before even landing on the bank’s site. SiteCatalyst records the name of the Campaign Creative that led the visitor to the banking site.

Once the visitor has landed on the bank site, let’s assume that the visitor applies for a loan. SiteCatalyst can record that the Loan Application was submitted by the visitor, but Loan Approval occurs days later offline.

Ideally, the banking site would like to know what kind of Return on Ad Spend they’re getting for all of their marketing efforts. SiteCatalyst can record campaign activity, but SiteCatalyst doesn’t know how much each click costs on a search engine like

Data Sources Upload offline data

into SiteCatalyst to combine it with online data.

WARNiNG: Data Sources are

permanent and cannot be erased. Before uploading Data Sources for the first time, perform a test upload to a development Report Suite. If you have any questions, do not hesitate to contact Client Care.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Google. That varies by the day. That is also information that we can get from the Search Engine. Check! There’s our first Data Source (campaign cost).

Next, we know that the visitor applied for the loan onine, but we don’t know if the visi-tor was approved for the loan, nor do we know if the loan amount was modified before everything was finalized because all of the post-application approval stuff takes place offline. Once the approval and final loan information is available, we can use that data as our second Data Source (loan approval and loan value).

By uploading this data, the bank can get a better understanding about how much they spent to market their product, how many final buys they got and then finally a Revenue by Cost ratio to tell them whether they’re doing things right or not.

Online and Offline Metrics Together

Data Sources makes it possible to view online and offline metrics in the same report. This functionality allows you to add powerful offline Custom Metrics such as “Ad Impressions,” “Offline Revenue,” or “Returns” to your standard set of reports. The Data Sources page (Data Sources Manager) has a wizard that guides you through the creation process. It also displays all currently activated Data Sources for your account.

Examples of Data to Integrate with Data Sources

There are many different uses for Data Sources. The most common uses include:

• Ad server impression data• Offline order fulfillment / call center data• Product returns• Customer support metrics• Survey data• In-store kiosk• Standard web server log file• Page Views, Visits, Visitors, eVars and props

IT’S ALL RIGHT: Even though Data

Sources come with the above warning accompanied by the scary bomb with a lit fuse, don’t let that keep you from using Data Sources. They’re really awesome and useful! Now go and get that 360° view of your conversion process!

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Unlike Classifications which can be retroactively modified, Data Sources data is per-manent. Whereas Classifications generally deals with grouping line item values in reports, Data Sources generally deals with the upload of new metrics, tied to a specific date, by which line item values will be sorted. These are the major differences between these two tools. At first glance, they may appear similar, but they are used for very different purposes.


You may leave it up to the SiteCatalst Admin at your company to create and upload all Data Sources, but you will likely, at least initially, play a part in Data Sources. As Technical Lead, what will most likely be your involvement with Data Sources?

• Receiving data from third-party vendors (search engines, ad serving partners, etc.).

• Creating the tab-delimited data file.• Testing the upload in a development report suite.• Automating the upload process of the data file.

Adobe® GenesisSo what is Genesis? It looks like it’s one of the major tools offered by Adobe. So what does it do? Genesis is essentially the automated version of Data Sources. We’ve created integrations between certain partners and SiteCatalyst. This doesn’t mean that you’re obligated to use Genesis instead of Data Sources, but if the time savings is worth more than the Genesis fees then using Genesis is a no-brainer.

Genesis The automated version

of Data Sources.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Genesis features include:

• Bi-Directional Information Exchange• Drag and Drop Interface to configure integrations• Accredited Application Partner Network• Accredited Partner data is automatically fed into SiteCatalyst (available in

reports and Dashboards)

Genesis employs a simple wizard-based integration interface.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Use the interactive drag and drop interface to configure an integration.

PPC Integration with Adobe® SearchCenter

Adobe® SearchCenter is a separate tool that is an offshoot of the Genesis family in the sense that one of its major functions is integration. The tool automatically pulls Cost, Clicks, Average Position and Impressions on a daily basis for all supported Search Engines. If you’d like to know more about available partners that offer a Genesis Integration such as Salesforce, Double Click, Responsys, Silverpop, Endeca, Forsee and many others, click on the Genesis button in the SiteCatalyst interface. Call your Account Manager if you don’t see the integration that you need listed in the Genesis interface.


As Technical Lead, what will most likely be your involvement with Genesis?

• Activating a Genesis Integration• Signing off on associated fees• In some cases, working with Adobe to complete integration

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Data Export Tools

Data WarehouseData Warehouse is the repository of raw, unprocessed, data. This raw data is also re-ferred to as “unnormalized” data, whereas data in SiteCatalyst reports have been “normalized” into summary tables for quicker querying. Data Warehouse enables you to request reports showing extremely advanced data relationships. This is possible because data relationships, generally severed when the image request is broken out into the different SiteCatalyst reports, is completely preserved in Data Warehouse. How? By pushing each string of data from each image request into this raw repository of data before any SiteCatalyst data normalization occurs.

The data in a Data Warehouse report is recorded pre-VISTA (any VISTA rules that modify SiteCatalyst data will not modify Data Warehouse data). The queries are easy to construct and the Data Warehouse interface is very easy to use. The queries are automated, run in a queue and return to the analyst via email or FTP in CSV (comma-separated value) format. Data Warehouse turnaround depends on the quantity of data, but is generally within hours (80 percent of requests are returned on the same day). Adobe generally requires 12 to 48 hours to process the request before the data is accessible.

The Data Warehouse interface must be enabled in order for analysts to access and use Data Warehouse. Data Warehouse is accessible in SiteCatalyst via the drop-down but-ton at the right-side end of the product suite bar. For more information on how to make a report request, refer to the Data Warehouse white paper.

Data Warehouse The raw repository

of all SiteCatalyst data used to examine complex data relationships.

NOTE: Data is sent to the

Data Warehouse at the end of the day. It may take up to 12 hours after the final visit is closed before Adobe writes off and compresses the file.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Common uses for Data Warehouse include:

• Request advanced data relationships such as Traffic Reports broken down by Conversion Reports

• Pull historical data and relationships• Extract data for use in other applications• Remarket to Key Visitors


As technical lead, what will most likely be your involvement with Data Warehouse?

• Enabling Data Warehouse.• Defining segments as needed.

Advanced Segment Insight (ASI)ASI allows customers subscribed to Data Warehouse to create a new Report Suite, based on a complex segment which the analyst defines, without any coding. This Report Suite can be created retroactively and even erased and rebuilt based off of a new segment. Once this new Report Suite is selected, all SiteCatalyst reports are based off of the new segment.

ASi Slots Creates a new Report

Suite retroactively without code. The new Report Suite is based on a user-defined segment.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Examples of ASI custom segments might include visits of 15 or more page views with no purchase, or visitors that purchased over $200 in merchandise in the last three months or only visitors from France. Once the segment is defined and saved, SiteCatalyst will build out a Report Suite based on segment criteria.

This means that every Conversion, Traffic and Path Report and every Predefined and Custom Metric will be based off of that segment. If there is a new segment that you’d like to analyze in depth for a couple of weeks or months, we recommend ASI slots.

Segmentation Tool

SiteCatalyst 15 Users can use the SiteCatalyst Segmentation Tool in lieu of ASI. Segments are created in the same way as they’re created in the ASI tool and they can be applied to all reports instantly (no processing time).


As technical lead, what will most likely be your involvement with ASI?

• Enabling ASI slots.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Defining segments as needed.

Please note that ASI is not available in SiteCatalyst Version 15.

Data FeedThis option feeds your raw data directly to your own servers for additional data min-ing. Data Feed is popular among some clients because it gives the analyst the ability to marry offline user-level data and SiteCatalyst aggregate data. It makes extremely complex data sets (it’s raw data) readily available for frequent queries.

SiteCatalyst users frequently use a Data Feed to take data from SiteCatalyst and populate another corporate data warehouse. The user’s corporate data warehouse may contain data relating to sales, marketing, accounting, etc., from other sources. The SiteCatalyst data from the Data Feed adds Web analytics data to the client’s data warehouse and enables them to obtain a view of their overall organization.

Because the Data Warehouse and a Data Feed both provide raw data, one might think of a Data Feed simply as the process of sending a copy of the Data Warehouse data to the client so that further custom analysis can be done.

Important facts that you should know about Data Feed:

• Consists of granular data, transferred to client.• Reoccurring schedule set up – once daily.• Pre-VISTA, unprocessed data (default).• Client FTP location preferred.• Allocate appropriate space for data (often overlooked).• Requires client resources to manage and run reports.• 12 to 48 hours after request to process data before transferred.• Adobe does not store the data.

Adobe prefers to push data to a client-managed FTP location. However, if that is not possible, Adobe can set up an FTP site if necessary. Additionally, be sure to allocate ap-propriate internal space for the Data Feed data. Running a Data Feed is an automated process at Adobe. Contact Adobe Client Care to request a Data Feed.

The Tech PerspectiveSomebody at your site will need to manage the data on your servers, make sure that there is enough space for the data that is coming from Adobe and make sure that the

NOTE: Receiving Data Feed data on your

servers requires resources on your end to store, manage, and analyze the data. Once you have the data, it is no longer supported by Adobe.

Data Feed Raw data sent directly

to your own servers.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


hardware is updated as needed. As technical lead, what will most likely be your in-volvement with the Data Feed?

• Manage data storage and backup.• Data mining / data querying.

Adobe DiscoverThis tool allows you to slice and dice your data to the Nth degree on the fly with the convenience and speed of SiteCatalyst, but the data flexibility of Data Warehouse. Using Discover, you can create any segment on the fly and apply it to any SiteCatalyst report, even path reports and instantly see results.

As opposed to ASI which takes days or more to build out and Data Warehouse which may take more than a day to process reports, Adobe Discover’s fast processing engine makes it possible to switch segments in an out at will. That is its greatest advantage: speedy at segmentation. After you answer one question, you can go get the answer to another and so forth. It really is an impressive data discovery tool.

Adobe Discover data is hosted on Adobe servers just like your SiteCatalyst and Data Warehouse data. No extra coding is required to use this tool. If you’ve already been using SiteCatalyst for a while and wish for Adobe to back fill data into Discover, you must have had Data Warehouse during the period from which you wish to back fill.

Adobe® Insight

The Adobe Insight tool offers even greater flexibility since almost any data value can be fed into this system. Adobe Insight data is typically hosted on your own servers instead of Adobe servers. Clients that use insight require multi-channel analysis. For example, you could use Insight to feed in data from your web channel, your brick-and-mortar channel and call center channel and analyze all data points together in the same system.

Discover Adobe’s premier

segmentation tool that allows you to view multiple segments side by side in your reports..

Adobe insight A multichannel

segmentation and analysis tool. Able to combine SiteCatalyst data with data from other channels, such as retail POS and call centers, enabling businesses to better understand their customers and make informed strategic business decisions.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Insight also offers different visualizations of your data using 2D graphs and the world globe.


So what will be your involvement with Discover? Well, it’s likely to be pretty limited if your job is limited to the technical aspect of the site, coding the pages. As technical lead, your involvement with Discover will most likely be:

• Recommend Discover usage.• Recommend and implement variables that will be useful in Discover analysis.

Adobe® Report BuilderAdobe Report Builder make it possible to log into SiteCatalyst and download reports through the Excel application instead of a Web browser. SiteCatalyst can already send reports in Excel format, but Report Builder essentially create a “live link” between SiteCatalyst and your spread sheet.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe Report Builder

Adobe Report Builder gives you the ability to create and distribute reports on a peri-odic basis.

It gives you the ability to combine Report Suites into one document, upload data from other sources to create advanced calculations and distribute this information across your global environment.


As Technical Lead, what will most likely be your involvement with Excel Client or Report Builder?

• Determine analyst demand for this reporting capability.• Enable licenses through Adobe Client Care.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Quick Quiz 21.1 Additional Functionality

1. How would you upload descriptive information for your campaign tracking codes?

a. Data Sourcesb. SAINTc. VISTAd. Send the file to [email protected]

2. You can’t get code onto the page until the next code review, but you want to start tracking a custom success event. What can you do?

a. Use SAINT to upload the page into SiteCatalystb. Have Adobe create a VISTA rule to add the event in the mean timec. Create a classification for the event in the Admin tool.d. Beg and plead with your IT team to allow the change.

3. Which tool(s) provides a graphical overlay on your Web page to show you which links are the most popular?

a. Adobe ClickMapb. Adobe SearchCenter+c. Adobe Discoverd. Adobe ReportBuilder

4. Which export method(s) give the client “raw data?”

a. Data Warehouseb. SAINTc. Adobe ReportBuilderd. Data Feed

5. Which export method(s) allows you to download SiteCatalyst data into a spreadsheet and refresh the metrics at the click of a button?

a. Data Warehouse Requestb. SAINTc. Report Builderd. Data Feed

6. Which tool(s) can be used to upload offline data, such as orders, email send and open data, etc.?

a. Adobe Genesisb. VISTAc. Data Sources

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


d. SAINTe. Adobe ReportBuilder

7. Which tool(s) are used for data segmentation?a. Adobe Discoverb. Data Warehouse Requestc. Adobe SiteCatalystd. All of the above

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

22-1

Chapter Twenty-Two

The Developer Portal and Intro to the SiteCatalyst API

Objectives

• Explore the Developer Portal• Learn about the possibilities of the SiteCatalyst API

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


The Developer Connection

Do you have any questions on these tools that we’ve learned about so far? Do you have questions about SiteCatalyst code and implementation strategies? Maybe questions about plug-ins, our API or some other Web analysis question? Try the Developer Community. The Developer Community is accessible to you as long as you have a SiteCatalyst log in.

Go to: http://developer.omniture.com

The Developer Community offers API Docs, Web Services Docs, a Code Gallery, Blogs, Forums, a Sandbox and much more. Try it out!

Apps, Plug-ins and Sample GalleryYou can try out Apps, Plug-ins and Samples of code that make your life a little easier all within the Developer Connection. Code in this area is experimental or in beta and so it’s not guaranteed, but it is a lot of fun. Test it out on a development Report Suite on your site before using any code.

A few examples of cool things to try out are (you can search for them on the Dev site):

• SAINT Bernard (Adobe Air app for SAINT Classification creation/manipula-tion on your computer)

• WordPress Plugin for SiteCatalyst tracking• TweetCatalyst• YouTube Player Tracking Plug-in• Omniture for Rails• GeoMoney (conversion event by location)• MiniSurvey• Enhance SiteCatalyst with Alexa Statistics

Adobe Digital Marketing Suite APIThe Adobe Digital Marketing Suite API makes it possible for you to easily communi-cate with all of the tools within the Digital Marketing Suite. The Web Services API is

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


built on the SOAP platform. You can built custom applications, tools and services that augment the functionality of the Adobe Digital Marketing Suite.

This Enterprise API makes it possible to both import and export data.

Common data imports using the Enterprise API are Data Sources and SAINT Classifications. This makes it possible to communicate directly with SiteCatalyst and submit this type of data as an alternative to the browser or FTP import required by these tools. You can also export data such as SiteCatalyst reports for use in your own tools.

Examples of API Use

• Download Report Data (view in your own client application)• Upload Classifications and Data Sources• Permissions

› Add Login › Delete Group

• Report Suite › Add Correlations › Add Internal URL Filters

• Company › Get Token Usage › Get Token Count

The API ExplorerThe API Explorer allows you to test calls without having to write a full client applica-tion. This tool provides you with a great way to learn about API functionality before you build out a serious application.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Using the API Explorer

To use the API Explorer, you’ll need your User Name (your login appended by “:” and company name) and your Shared Secret.

Both of these values can be accessed at Admin > User Management. Once within User Management, locate and click your User ID. In the Access Section, look for the “Web Service Credentials” field to find your User Name and Shared Secret. You must be part of the “Web Service Access” group to use this tool.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


To make a call through the API Explorer, set your Post URL, Environment and Method. Depending on the method, you may need to fill out some additional code. Review the documentation for more information on specific methods.

Once this is done, click “Get Response” and data will populate the Response field. Remember, this tool is designed for you to test calls without building out a full client application, but it is not a replacement for a full client application.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Trended (Overtime) Report Sample Request

Request to SiteCatalyst (do not use this code – example only):

// This is the object that you pass to the API call - API

calls are described in Report Definition.

reportDescription = {

reportSuiteID = “myrsid”,

dateFrom = “2008-01-01”,

dateTo = “2008-01-03”,

dateGranularity = “day”,

metrics = [

{

id = “pageViews”

},

{

id = “visits”

}

]

}

Trended (Overtime) Report Sample Response

Response to the preceding request:

report = {

reportSuite = {

id = “myrsid”,

name = “My Report Suite”

},

period = “Mon. 1 Jan. 2008- Wed. 3 Jan. 2008”,

elements = [

{

id = “datetime”,

name = “Date”

}

],

metrics = [

{

id = “pageViews”,

name = “Page Views”,

type = “number”

},

{

id = “visits”,

name = “Visits”,

type = “number”

},

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


],

type = “overtime”,

data = [

{

name = “Mon. 1 Jan. 2008”,

year = 2008,

month = 1,

day = 1,

counts = [2,2]

},

{

name = “Tue. 2 Jan. 2008”,

year = 2008,

month = 1,

day = 2,

counts = [1143,131]

},

{

name = “Wed. 3 Jan. 2008”,

year = 2008,

month = 1,

day = 3,

counts = [1212,146],

}

],

totals = [2357,276]

}

Exercise 22.1: Test Calls with the API Explorer

1. Go to https://developer.omniture.com/en_US/get-started/api-explorer2. Populate Username and Shared Secret (go to Admin > User Management >

Your ID to find this information)3. SOAP should already be selected, Post URL should already be set, and the

Environment should already be set to ”San Jose – Production”4. Set Method to “Company.GetTokenCount”5. Click the “Get Response” button

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

23-1

Chapter Twenty-Three

Tag Management

Objectives

• Understand the purpose of Tag Management• Explore the Tag Management interface

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Using Tag Management

Have you ever needed to update your s_code.js file during a code freeze? With Tag Management, that’s no longer a problem.

The Tag Management AdvantageAdobe can store your s_code.js on a CDN (Content Delivery Network). This makes it possible for you to be able to change your s_code.js through the Tag Management in-terface at any time without the assistance of IT (add tag, plug-ins, Genesis integra-tions, other code, etc.).

Besides Adobe Digital Marketing Suite-specific code, you can even deploy third-party tags. Your site will still employ a JavaScript your s_code.js file hosted on your Web server, but it will act as a loader file for the remotely stored s_code.js file on Adobe servers. Any changes to your s_code.js file can also be rolled back easily to previous versions of code because old versions are stored within the Tag Management tool.

Code ProcessingThe following diagram shows how Tag Management processes data. It optimizes loading through asynchronous code processing (some code is run simultaneously such as Page Code and Product Code to increase loading efficiency).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Code Environment StagesDevelopers can simultaneously test and maintain a Dev, Stage and Live s_code.js en-vironments. A special browser cookie, accessed through “Bookmarklets”, allows de-velopers to test and interact with the Dev Code without affecting the Live Code (visi-tors still see site with Live Code).

Tag Management Usage StepsTo activate Tag Management, contact Adobe ClientCare for more information. Once the tool has been activated, access is available through Admin > Admin Console > Tag Manager.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


1. Create a New Container

The first step to Tag Management is the creation of a container to hold all of your code (SiteCatalyst product code, third-party SiteCatalyst integration code and other third-party code). Simply provide the container with a name and description.

2. Define Tags

Choose tag code in the Define Tags step (Core JavaScript, Product Code, Custom Code). All of your code will be inserted in this step (all parts of the basic s_code.js file and all plug-ins, third-party integration code, etc.).Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


3. Copy Environment Bookmarklets

Once you’ve set up your code, drag the Bookmarklets to your bookmarks tool bar to save each Bookmarklet as a favorite. This allows you to test each version of your code(Live, Stage, Dev) while the public continues to experience the Live Code. Bookmarklets set a cookie in your browser that tells Tag Management which Code Environment to serve up.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


4. Copy the Tag Loader to your Web Site

The Tag Loader is used to asynchronously load the tag container with the remotely stored Tag Management code. It’s saved to your Web server and referenced on every page on your site. The Tag Loader code goes into your s_code.js file.

5. Include the Loader on your Site Pages

Pages on your site should include a reference to the JavaScript loader page. Variables are set on page using the same process used with a standard implementation.

Example:



<script type=”text/javascript” src=”s_code.js”></script>

<script type=”text/javascript”>//<![CDATA[

if(s){

s.pageName = “”

s.server = “”

s.channel = “”

s.t()

}

//]]></script>



Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


6. Test and Promote Revisions

Copy revisions from Dev to Stage to Live Environments as needed. File revisions, login that created the files, revision number, deployment date and status of files are all recorded by Tag Management for you and viewable within the interface. This sure makes dealing with your s_code.js a lot easier!

Tag Management SummaryTag Management:

• Hosts s_code.js on a CDN• Ability to modify s_code.js without the aid of IT• Three code environments for testing and deployment• Asynchronous loading

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

24-1

Chapter Twenty-Four

Adobe® DigitalPulse™

Objectives

• Understand the purpose of DigitalPulse• Learn how to set up a scan• View a sampling of available reports

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


DigitalPulse Configuration

If you’ve ever wondered if your SiteCatalyst tracking code on your Web pages is work-ing properly or if you’re actually tracking all of your pages, DigitalPulse can help you answer those questions.

DigitalPulse provides automated validation and audit of your SiteCatalyst data collec-tion. The DigitalPulse digital spider crawls your Web site (you specify the entry point)and scans for the following:

• Missing SiteCatalyst tags (also find HBX tagged pages)• Pages with or without Adobe® Test&Target™ Mboxes• Mbox distribution• Improperly configured script variables• Broken links, JavaScript errors and data errors• Tag location and length• Keyword distribution, placement and duplicate keywords• Missing ALT text for images• Missing page properties and HTML structure• Form data privacy concerns especially with data that could be viewed by a third

party

DigitalPulse Scan ManagerThe DigitalPulse scan manager is your control dashboard that shows you every scan and their results. It lists scans by Name, Creator, Status, Last Scan, Pages Scanned, Missing Tags and Data Errors. There is an option to create new scans or rescan your site. Since your site is always changing, you should scan your site on a regular basis.Ado

be In

terna

l Use

Only

Do Not

Distrib

ute

Chapter Twenty-Four DigitalPulse 24-3

ConfigureStart your scans in the Configure section. Here you indicate start points for scanning (DigitalPulse crawls your site). Indicate other start URLs when there are pages inac-cessible from the primary start URL (orphan pages or site sections).

MasksIn the Masks section, you can exclude or include URLs with URL masks (accepts wildcards and regular expressions) so that DigitalPulse doesn’t scan pages or groups of pages that you don’t need to be scanned. There is also an option to scan all pages including those pages that disallow bots or spiders (DigitalPulse can ignore “no in-dex” tags and other restrictions that your site places on bot or spider activity.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


LimitsYou can control maximum pages scanned and depth (if you only wish to sample a number of high-level pages and not your entire site). You can also control scan rate by pages per minute if you do not wish DigitalPulse to crawl your site too quickly.

SchedulingAfter setting your Time Zone, program DigitalPulse to scan at the times that make the most sense for your site. In fact, you can even set blackout times. Any scans that overlap with blackout times will pause during and then resume after the blackout period.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


FormsDigitalPulse can check your site forms and submit test data through them. Think about all of the forms on your site. This not only saves you time, but it can potentially save you from lost conversion due to form errors.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Other OptionsYou can change the User Agent String that DigitalPulse should use if your site content changes for specific browsers or devices. You also have the option to use Regular Expressions for use with the Tag reports.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


DigitalPulse Reports

DigitalPulse offers full reporting to keep you on your site tags and technological health.

Missing Tags ReportThis report allows you to quickly locate all pages that aren’t being tracked by SiteCatalyst so that you can place tag on them immediately. You can filter pages by URL, Title, Content, Keywords and Description. This the report that you will want to be sure to check every time you sign into DigitalPulse.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Data Errors ReportThis report shows tag errors such as illegal characters or character counts that exceed variable limits (e.g., more than 100 characters in s.pageName). This allows you to make changes to the type and quantity of characters that you populate into each variable.

Tag Location ReportThis report shows you if your tags are at the top or bottom of the page (remember to be consistent with tag placement on your pages). You can filter your pages by Tag Location (or by no Tag found) so you can quickly make changes.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Keyword Distribution ReportThis report identifies the use of keywords throughout the Web site. Click on a key-word to see on which pages it is used.

Broken Links and JavaScript Errors ReportsThis report allows you to locate broken links in your Web site so that you can quickly correct them. It also shows you any JavaScript errors not necessarily related to SiteCatalyst tag within your Web site so that you can quickly make fixes. This reports help you take preventative measures to mitigate conversion loss due to technological errors.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Class Exercise 24.1: DigitalPulse Test Scan

DigitalPulse Test Scan on JJ Esquire

1. One student should volunteer his or her JJ Esquire site for a scan (if using the online PHP version). If no version is available, scan the Adobe Training Services Web site.

2. The instructor will set up the scan.3. Once the scan is complete, determine how many pages haven’t been tagged.4. Optional: Find pages with images that lack ALT text (ALT text helps our

images show up in some search engines).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

25-1

Chapter Twenty-Five

Validation and Troubleshooting

Objectives

• Learn the steps to validate your code• Learn about popular debugging tools• Review common Implementation mistakes

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Implementing the Right Way

OverviewValidation and troubleshooting are important parts of the implementation process because they ensure that you have properly configured and implemented SiteCatalyst. You can use Adobe’s processes to solve any implementation issues.

IntroductionThis chapter discusses SiteCatalyst deployment validation process and offers some troubleshooting tools and considerations.

The validation process is part of a larger process and is made up of several action items, including the following:

1. Corporate Standards: It is very important that you think globally when you start to implement SiteCatalyst. Even if you are only a small part of a global environment, you must communicate with the right people from other departments to create an implementation plan that can be mirrored through-out the enterprise. For example, if your company plans on having multiple Report Suites and you plan on using Rollups or Multi-suite Tagging to obtain totals (to combine Report Suites), make sure that everyone puts the same kind of data in the same variables (e.g., if you use s.prop2 to capture “Internal Search Terms”, make sure that every local Report Suite uses s.prop2 for the same purpose). This will keep global reports meaningful and clear rather than a hodgepodge of disparate data.

2. Deployment Validation: You must ensure that data is coming through and populating SiteCatalyst reports as you originally intended.

3. Implementation Acceptance: You also need to compare SiteCatalyst reports with your own back-end system metrics (such as conversion numbers for Revenue, Orders, Registrations, etc.) to make sure that everything is working properly. If there is a substantial difference between what SiteCatalyst reports and what you expect, then troubleshooting is in order. In addition, you can also audit your site code using Adobe Digital Pulse. This tool allows you to identify missing or incorrectly configured tags and broken links.

Adobe offers the JavaScript Debugger as the primary tool to check the code for errors. By now, you should be familiar with the JavaScript Debugger. You can find more in-formation in the SiteCatalyst Knowledge Base or on the JJ Esquire site under

TiP: Establish Corporate Standards

before implementing. Other coders throughout the organization should have instructions that tell them how and when to code new pages. Data formats should match between Report Suites if you plan on combining them into a Global Report Suite.Ado

be In

terna

l Use

Only

Do Not

Distrib

ute


Company>White Papers. There are other tools such as HTTPFox, FireBug, WASP, Charles and others that you can use in lieu of the debugger if you prefer.

Deployment ValidationSiteCatalyst provides the metrics needed for all types of users within the organization to fulfill their reporting needs. In order to get the most value at a specific department and an enterprise-wide level, customers should take the time to determine a standard set of configuration settings to which all implementations should adhere.

Validating your SiteCatalyst installation is performed in the following steps:

1. Check for code accuracy.2. Validate the parameters in the image request3. View reports for value and metric accuracy

Checking Code Accuracy

By checking the code accuracy, you ensure that the code is located in the correct place and it is being called in the right order. Also check the following:

Configuration

Make sure that the Configuration Variables have been set correctly for your business needs (the majority of these are set in the Global JS file or s_code.js). For example, one small Configuration Variable determines if ClickMap Data should be collected. Another Configuration Variable determines the currency type of all recorded Revenue (this can make an enormous difference).

Page Templates

Many clients’ site architecture uses page templates to create site pages dynamically, populating content possibly pulled from a database or a content management system. If this applies to your site, you most likely place the basic Page-Level Code in those templates so that each and every page that uses the template contains the proper code. Some page template types might include:

• Product pages• Department or Category pages• Campaign landing pages• Article pages• Checkout pages

Code Exceptions

Even if you use page templates that create pages on your site, you will still need to populate certain variables just once or so on specific pages. These could include the 404 Error Page and Conversion Event pages or whenever you need to pass in a special value on just one page. Pay special attention to pages that employ Custom Link Tracking. Don’t forget to check any global values that you may have set in the s_code.js file. Make sure that these pages are correctly coded.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Validating Parameters

To validate that correct values parameters are being sent through the image request, use the SiteCatalyst Debugger tool or another packet analyzer of your choice. Don’t trust the page code (just because a variable has been set in the code doesn’t guarantee that it’s being passed in correctly). Even though the Page-Level Code may look right, if the Debugger or another packet analyzer doesn’t show it, then data isn’t being captured.

Use the Debugger to find any missing variable values. For example, if the code says s.pageName=“Home” and pageName=Home is not in the Debugger, there’s a problem. Use the tables provided in the Debugger white paper (available in the SiteCatalyst Knowledge Base) to translate the Debugger variables.

To recognize code errors, watch for any of the following:

• Variables with the wrong values• Variables set on the page that don’t show in the Debugger

Code validation ensures that variable configuration for the following variables actu-ally supports business requirements.

• Configuration Variables• Traffic Variables• Conversion Variables• Custom Links

Viewing Reports for AccuracyVerifying report accuracy is generally done by the business manager or analyst, but can also be done by the technical consultant. As the technical consultant, you’ll need to be familiar with the SiteCatalyst interface so that you can run the correct reports to verify report accuracy.

To check reporting accuracy, log into SiteCatalyst and run the report that captures the data of the variable in question. For example, s.pageName populates the Pages report, prop1 populates Custom Insight 1, eVar1 populates Custom Conversion 1. Some of the more important and “telling” reports would include:

1. Conversion Events (Orders, Revenue, Custom Events)2. Products (where applicable)3. Tracking Codes4. Referrers (verify only external sites and pages)5. Custom Conversion and Custom Traffic reports6. Pages and Site Sections7. “Other” pages = check domains in internal URL filters

NOTE: A blank Debugger may indicate

that the page was tagged incorrectly or the page cannot load the Global JavaScript file (s_code.js).

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Also check the following data points and make sure that they measure to within 2-3% of what your in-house systems report:

• Data points• Orders• Events• Page views

Adobe expects minor loss of data (1-3%) for reasons such as the image request does not reaching our servers due to Internet latency, visitors having JavaScript disabled, and because the Internet is not a guaranteed delivery medium. Page weight can also be an issue so image request placed higher on the page will be the more accurate. The fol-lowing issues may affect accuracy:

• Privacy utilities (see white paper) — generally only affect third-party cookie implementations.

• Dial-up slows load times.• Inconsistency with code placement throughout the site (code that is placed

higher on the page will measure more data while code that is placed lower on the page will measure visitors who loaded the whole page).

• Implementation problems or issues: bad chars or formatting, other JavaScript errors, page or .JS file doesn’t load.

• Excluded IP addresses placing orders (internal IP addresses or employee activity). Check to ensure that none of the orders are related to any excluded IP addresses.

• “Special” products (may be ordered through a different process).• Alternate order processes (customer service site, etc.).• Internal testing, such as test orders, is included in comparison data, but not in

SiteCatalyst’s data due to internal IP exclusion.• Order numbers are not unique, and therefore new Orders are being excluded by

SiteCatalyst (we remove duplicate orders when properly using the s.purchaseID variable).

• s.purchaseID exceeds 20 characters (first 20 may not be unique between s.purchaseID values)

• Unique Order Numbers are generated every time the Order Confirmation page is reloaded by the customer.

• Time zone difference between SiteCatalyst Report Suite data and client back-end system data.

• Order page failure (the order recorded by the back-end system, but the order confirmation/thank you page is not loading, and therefore not being recorded in SiteCatalyst).

• Duplicate orders are removed in back-end system, but not in SiteCatalyst.• If you have a lot of Mac-based users, there may be issues with character line-end-

ings that are causing problems with any dynamically included variables put into the ‘code to paste’ area of the page—like s.purchaseID, s.events, s.products, etc.

Consult Client Care for advice on how to best check and verify metrics on your site. You may also run into discrepancies with the Conversion Reports. If this occurs, check any of the following:

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Troubleshooting Tools and Considerations

JavaScript Debugger

The JavaScript-based Debugger allows you to view the parameters sent in an image request. It supports most common browsers. For more information on installing and using the JavaScript Debugger, refer to the JavaScript Debugger whitepaper, available in the SiteCatalyst Knowledge Base.

Other Debugging Techniques

As stated earlier in the course, you can use any other packet analyzer of your choice in lieu of the JavaScript Debugger. If you choose to use a packet analyzer, you will still need to know the parameter names, as they appear in the Debugger. Keep the Debugger white paper nearby with the parameter name reference table.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


A few examples of packet sniffers are:

• HTTPFox (FireFox plug-in)• FireBug (FireFox plug-in)• WASP (FireFox plug-in)• Charles (http://www.charlesproxy.com)• Wireshark (www.wireshark.org, formerly Ethereal)• Fiddler (http://www.fiddlertool.com)

These tools are especially useful for debugging Flash and Custom Link tags, because Flash and links may occasionally not show up in the SiteCatalyst Debugger tool (al-though the debugger is designed to capture these image requests). They can also be used to catch multiple image requests, in the case when a page is double-tagged (dif-ferent from Multi-suite Tagging). The image request is a GET request using HTTP as the protocol and is displayed as the following (if using third-party cookies):

• “http://reportSuiteID.d2.sc.omtrdc.net...”

or

• “http://reportSuiteID.112.2o7.net...”

Adobe® Digital Pulse™

Adobe DigitalPulse provides monitoring capabilities that allow businesses to detect and quickly resolve issues that can negatively impact how consumers interact with their Web sites.

DigitalPulse helps analysts identify missing or incorrectly configured tags and bro-ken links—ensuring that online analytics and reporting are complete and accurate, leading to a more optimized customer experience, increased engagement and im-proved SEO rankings.

Contact your Account Manager for more information about this solution.

Adobe® DigitalPulse™

Monitors site for missing or incorrectly configured SiteCatalyst tags.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Troubleshooting Considerations

In most cases, if the image request is sent to SiteCatalyst, basic Traffic Metrics (Page Views, Visitors) are captured. You should be most concerned with custom implemen-tation issues such as conversion tracking, flash tracking and campaign tracking.

Problems are typically caused by the following:

• Variables and Values syntax: Lack of knowledge regarding how to use specific variables and functions

• New pages on site: Process not in place to include SiteCatalyst code on new pages

• Code Modifications: Sudden change of implementation—someone changes the page without considering the SiteCatalyst tag

• JavaScript .JS File: referenced incorrectly or nonexistent

Common Problem Countdown

The following problems are some of the most frequently encountered during the im-plementation process, starting with number 11 and working down to number 1:

11. Strange characters from your text editor

What It Is• Instead of editing in Notepad, you edit your code in Microsoft Word or another

program inappropriate for coding. • After copying from Word and pasting code into the Web page, strange charac-

ters appear causing problems with the code and perhaps the site.

How to Prevent It• Make sure that you use a Text Editor that doesn’t introduce hidden characters

into your code such as Notepad or another appropriate editor.

10. Use of Single and Double Quotes

What It Is• Use of Single Quotes and Apostrophes could produce illegal code that would

cause the ENTIRE image request to fail

Example:

s.pageName=‘L’Oréal Home Page‘

s.pageName= “Samsung 55” LED LCD TV”

How to Prevent It• Choose to use Single or Double Quotes and be consistent• Watch out for any (‘) or (“) that could break the code• Turn off “SMART QUOTES” in your code editor

Possible solutions:

s.pageName=“L’Oréal Home Page”

s.pageName=‘L\‘Oréal Home Page’

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


9. Misuse of s.pageType

What It Is• Populating s.pageType with a value on any page besides the 404 error page • Misuse of s.pageType fills the “Pages Not Found” report with useless

information

How to Prevent It• s.pageType should only be populated on the 404 error page with the value

“errorPage”s.pageType=“errorPage”

8. Misuse of Comma (,) and semicolon (;) in s.products

What It Is• Using a comma or semicolon in product names• Product name is “Ski Coat, size medium” contains a comma

Example:

s.products=“;Ski Coat, size medium;1;295.50”

How to Prevent It• Strip all characters such as semicolon (;) and comma (,) from product names• Best option: just use the SKU as the product name• Only use semicolons to delimit the product string fields and the comma to

separate one product from another in the product string

7. Using s.linkTrackVars and s.linkTrackEvents

What It Is• The custom link doesn’t pass in any data because s.linkTrackVars and

s.linkTrackEvents were not populated

How to Prevent It• All variables that you are passing (including the event variable if applicable)

must be listed in s.linkTrackVars and all events in s.linkTrackEvents (separated by commas)<a href=“index.html” onClick=“var s=s_gi(‘mysiteid’); s.linkT

rackVars=‘eVar1,eVar2,events’;


s.eVar1=‘Blue Hat’;

s.eVar2=‘Hats R Us’;


s.tl(this,‘o’,‘Vendor Link’);

”>Go Purchase Product</a>

Note: If these variables are set in the JS file or anywhere else on the page, the values will be pulled in when the link is clicked.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


6. s.cookieDomainPeriods is set incorrectly

What It Is• If s.cookieDomainPeriods is not set, the default is two periods• For a site like www.jjesquire.com.au (with three periods), SiteCatalyst by default

will attempt to set cookies to the “.com.au” domain• Tracking is adversely affected because cookies cannot be set

How to Prevent It• Make sure that s.cookieDomainPeriods is set correctly (if you don’t set it, the

default is two periods)• Select the number of periods in your domain when you generate code in the

Admin Console• Check Visitor Profile>Technology>Cookies

5. Variables not set correctly — using wrong syntax

What It Is• Essentially the client needs to avoid things such as:s.prop27=“document.location” (shouldn’t use quotes)

s.pageName=Home; (should use quotes)

• Case sensitivity issues, i.e., s.evar should be s.eVar

How to Prevent It• Use the debugger to check that all variable values are passed in correctly• An error such as this will cause the image request to fail

4. Purchase and Revenue Duplication

What It Is• s.purchaseID not used on the purchase confirmation page

How to Prevent It• Always set this variable for purchases

s.events=“purchase”

s.products=“;ski coat;1;850.25”

s.purchaseID=“239sd913kf8”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


4. Global JavaScript file nonexistent or referenced wrong

What It Is• The JavaScript include file does not exist or the reference to it is incorrect • The code will not execute and variables will not be sent to SiteCatalyst

How to Prevent It• Ensure that the JavaScript include file is accessible to ALL tagged pages• Make sure to test your code after you modify you s_code.js file or the page code• Consider using an absolute link to the s_code.js file

2. Wrong Report Suite ID – no data in expected Report Suite

What It Is• Setting the wrong Report Suite ID in the Global JS file

How to Prevent It• Check your list of Report Suite ID’s and ensure the s_account variable is set

correctly• Monitor traffic after going live to ensure the page names are correct• Use the Debugger to read the RSID in the image request

1. Placing “Page-Level Code” in the <head> tag

What It Is• Incorrect location of Page-Level Code• The image request fails (can’t be made from the head tags in most browsers)

How to Prevent It• Ensure that Page-Level Code is between <body> tags• Recommend automating code placement via a global header or footer (still

between <body> tags)

Some Final Problems

INCORRECT CORRECT

prop1 s.prop1(uses “s.”)

s.tl(this,o,PageA) s.tl(this,‘o’,‘PageA’) (correct usage of single quotes)

s.events=“event1, event2” s.events=“event1,event2”(no spaces between events)

s.events=“event1”; s.events=“event2”;

s.events=“event1,event2”(correct format)

s.products= “;JJ Camper Tent;1;$300.00”

s.products= “;JJ Camper Tent;1;300.00”(does not use a currency symbol)

s.products=“;Corduroy Blazer;1;709.986633

s.products=“;Corduroy Blazer;1;709.99(round or truncate long prices)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


And One More Thing…

Occasionally you will notice values in reports that don’t make sense, values whose ori-gin is a mystery. This could be strange page names, site section names, values in cus-tom reports, etc.

These values could be a result of strange browsers that don’t understand the logic on your page that is populating variables. They could also be a result of values replaced by parental software, or any other software, including viruses on the visitor’s com-puter, etc.

The point of this is that you need to decide if it is worth your time to figure it out. If the numbers are very low for this strange value, do you really need to spend your time running it down, just so you can get it out of your report? Maybe it would be better to ignore it, since you are not going to change anything on your site based on the strange value.

However, if the strange and unexpected values represent a sufficient percentage to throw off your numbers, or if you just need them out of your reports, you can use the Debugger to troubleshoot your site, testing different pages and checking values. You can also contact Adobe Client Care and discuss options for tracking down these val-ues such as Adobe Digital Pulse.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 25.1 Solution Validation


The goal of this exercise is to validate that the pages below have been correctly imple-mented and if not, make the necessary corrections to the code.

Goal: Validate Implementation

1. Check the four error pages very closely for code problems 2. Use debugger to check/validate variables 3. List errors on an Error Log in your book 4. Correct errors in page code (.php files) 5. Rerun debugger to ensure the solution works

Check the following pages:

Men:Fine Apparel:Two-Button Suit (errors with 2 variables)Men:Fine Apparel:Blue Shirt (errors with 1 variable)Men:Fine Apparel:French Cuff Shirt (custom link code errors)Men:Fine Apparel:Tuxedo (error with 1 variable, error with page code)

Error Log

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

26-1

Chapter Twenty-Six

Effective Implementation Practices

Objectives

• Understand common terminology used during the Implementation process• Learn how to ask the right questions to Report Consumers before implementing• Find out where to get help once you’re implementing on your own

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Recommendations and Best Practices

OverviewAdobe offers some best practices defined here as a tool to help you successfully imple-ment SiteCatalyst as quickly and effectively as possible. The following topics will be discussed:

• Understanding terminology• Dos and don’ts • Asking the right questions• Considering all options• Identifying variable use• Populating variable values• Where to get help• Design Solution Project

Understanding TerminologyThe Glossary in the SiteCatalyst User Guide and the offer terms that are commonly used both in SiteCatalyst and in Web analytics in general. Both the technical and business teams at your organization should become well-versed in the nomenclature used by Adobe and throughout the Web analytics industry so that they can commu-nicate effectively, not only with each other, but also with Adobe. We want to make sure that everyone is talking about the same thing.

The terminology could be grouped into three areas:

1. Roles—This one is probably pretty easy, because it mirrors what you already have in place, but some of the roles involved with SiteCatalyst could be

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Executive Sponsor, Project Manager, Business Lead, Technical Lead, and Analyst.

2. Metrics and Reports—You should also be familiar with the names of the metrics and reports used in SiteCatalyst and in the industry, and know how they are best used. These include Visit, Unique Visitor, Page View, Exits (Exit Pages), Time Spent per Visit, etc. Think about an executive asking a simple, but ambiguous, question such as, “How many people did this?” Think to yourself, “Does that mean ‘visits’ or ‘visitors’ or even ‘page views’ or a ‘custom conversion event’ of some type to some executives or business analysts?

3. Features and Functions—It is helpful to be familiar with the different features and functions that are available in SiteCatalyst and other Adobe products. These include pathing, Data Warehouse, ASI, Data Sources, Genesis, Discover, SearchCenter, Test&Target, Insight, Merchandising, etc.).

Dos and Don’tsHere are some helpful hints as you implement SiteCatalyst:

Do…• Make sure your page names are well planned and discussed.• Call things in the right order—especially with H code.• Verify the outcome with the Debugger tool or packet analyzer.• Establish global standards for incorporation across the enterprise. • Do your investigation in the Knowledge Base prior to calling Adobe (it makes

things go faster). Understand the Troubleshooting section. Document what you’ve tried so that you can explain that to Client Care.

Don’t…• Deploy SiteCatalyst code without talking to the Report Consumers. • In order to get ANY value from the SiteCatalyst implementation:

› Values in reports must be understandable to those running reports. › Business issues must be solved by collecting the right data.

Asking the Right QuestionsIt is very important that you understand the Key Business Requirements before at-tempting to map them to variables. Make sure that you clarify any business needs. This is the old “measure twice, cut once” rule. It is much better to verify multiple times what the business user needs before coding the page. This will help avoid a “use-less” report later that doesn’t contain the requested information.

For example, if a business requirement came through simply to “track content chan-nels,” you would need to verify exactly what the users need to know. Some clarifying questions might include:

• Do you need page views, visits or visitors for those content channels?• Do you need to know how people path between those content channels?

TIP: Verify your Report Consumers’ needs by

restating their needs. They should acknowledge that your understanding of their needs is correct. Never assume that you know what they mean without follow-up questions.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Can you give me examples on our site of the content channels you are thinking of?

• How granular are these content channels? Do they follow our site navigation?

In addition, make sure that you align your terminology with the person who requests the information. For example, make sure that “visitor” means the same thing to you as it does him or her. Don’t ever assume that you know what they mean. Ask questions!

Considering All Options

Once the Key Business Requirements are clear, you can take those requirements and associated Key Performance Indicators and map them to Adobe products, features, functions, variables, etc. Be sure to explore all the different options, understand the differences in those options, and choose the best solution for your site. There are often multiple ways to get the same kind of information, but there are sometimes subtle dif-ferences in the outcome.

Some example questions you can ask yourself in this regard include:

• Is this a Traffic-based objective? › Can we answer it using s.props? › If not, what else do we need? (VISTA, ASI, Discover, Excel, etc.)

• Is this a Conversion-based objective? › Can we answer it using eVars? › If not, what else do we need? (Classifications & SAINT, full conversion

subrelations, etc.)

Identifying Variable UseThe next step is to identify your variable use. By understanding what the Adobe vari-ables do, you can more easily implement them (and conserve them by choosing an efficient and scalable implementation method).

You should map out and DOCUMENT (ALWAYS DOCUMENT) your variable use. Document variable usage in the Solutions Design Reference document.Example:

• s.channel = Parent content category (page groupings)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• s.prop1 = Page subcategory• s.prop2 = Internal search terms• s.eVar1 = Merchandising category • s.eVar2 = Internal search terms (mirror of s.prop2)• Event 1 = New Subscription

Another important question to ask when you are mapping the variables out is:

• Can these values be referenced when needed?

This could be broken down into specific questions, such as these examples:

• At the page level do I know the content category and sub-category?• For any given visitor can I determine the segment such as registered vs.

non-registered?• Based on our site architecture, how best can I put events onto the appropriate

pages?

For example, it doesn’t do any good to map a variable to be the “Age” variable if you don’t ascertain the age of site visitors. So make sure that you can get the information that you are planning to put into the variable.

Populating Variable ValuesNext, determine how to get the values that you need into the code on the page. Common solutions include:

1. Server-side scripting (PHP,JSP,ASP) 2. Client side scripting (JS) 3. Hard coded values4. Put code in an include file for automatic inclusion on new pages

Although the architecture of your site will dictate how you will likely code your SiteCatalyst variables, it is also sometimes a variable-by-variable decision. For exam-ple, you might be able to pull a value from the URL for one variable, while you need to query a database for another variable’s value.

Keep in mind that SiteCatalyst records whatever is passed in exactly as it is sent in the image request. Don’t forget the “garbage in/garbage out” rule. If the Report Consumers can’t use the information, then it’s likely an implementation problem.

In any case, the onus is, of course, on you to provide quality values into the variables. You may contact Adobe Consulting for some suggestions and best practices in this regard.

Where to Get HelpAdobe provides several options for self-help. Those that can help you the most during your implementation process include:

• This Adobe SiteCatalyst Implementation Manual (put in safe deposit box)• Online Implementation Manuals (Help>Documentation)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Adobe Training Services Training Videos (Help>Training Videos)• Online Knowledge Base (Help>Knowledge Base)

› Whitepapers › Common questions

• The Adobe Digital Marketing Suite Blog (blogs.omniture.com)• The Adobe Digital Marketing Suite Community (Help>Community)• The Link (Help>Link)• Customers Page (Help>Customers)• Adobe ClientCare / Account Manager• Your Implementation Consultant

You should have (at least) two users at your company that are set up as “supported us-ers” and can call or email for help from Adobe Client Care. If you would like more help implementing SiteCatalyst, you may also engage an Adobe Technical Consultant. Please contact your Account Manager for more information.

Course Summary

1. Define your KBRs based on site goals with Report Consumers2. Translate your KBRs into KPIs with Report Consumers3. Map your KPIs to SiteCatalyst variables and metrics4. Deploy code5. Validate code6. Repeat and modify as needed (the site will change and the implementation

will need to keep up)

Course Wrap-upThank you for taking this course. We hope that you have enjoyed it. For information regarding additional courses, please visit http://www.omniture.com/education/.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Student Workbook Index Index-1

Index

Student Workbook Index

IndexSymbols

404 error pages variable 6-8–6-9404 error page variable 4-4

A

ace implementation exam xiiadobe blog for omniture technology 26-5–26-6adobe certified expert program xiiadobe developer community 22-2–22-3adobe digitalpulse 24-2–24-10, 25-7adobe discover 21-37–21-38adobe fusion deployment methodology 3-4adobe genesis 21-30–21-31adobe insight 21-37adobe reportbuilder 21-38allocation 12-5api 22-3api explorer 22-3apl append list plug-in 16-7appmeasurement for actionsource 20-2–20-8appmeasurement library code 18-11asi (advanced segment insight) 21-34asynchronous tag container processing 23-2automatic variables 15-20–15-21

B

bookmarklets 23-3brd 3-5breakdowns

subrelations 14-2–14-3traffic correlations 8-2–8-4

business requirements document 3-5

C

campaign variable 10-3, 12-2–12-7certification exam for sitecatalyst implementation xiichannel variable 4-4, 6-2–6-3classifications 21-2–21-4code

global javascript file (s_code.js) 1-8how sitecatalyst code is read 16-2page-level code 1-8

configuration variabless_account 15-7s.charSet 15-9s.cookieDomainPeriods 15-12s.currencyCode 15-9–15-11s.dynamicAccountSelection 15-8s.fpCookieDomainPeriods 15-13s.linkDownloadFileTypes 15-16s.linkExternalFilters 15-18s.linkInternalFilters 15-17s.linkLeaveQueryString 15-17s.linkTrackEvents 15-18s.linkTrackVars 15-18s.mobile 15-15s_objectID 15-14s.trackDownloadLinks 15-16s.trackExternalLinks 15-17s.trackInlineStats 15-14

context data variables 17-3conversion allocation 12-5

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Index-2 Adobe® SiteCatalyst® Implementation Training Student Workbook

conversion funnel report 9-9–9-10conversion variable enhancements

classifications 21-2–21-4conversion visitors metric 14-4conversion visits metric 14-4subrelations 14-2–14-3

conversion variables 13-14conversion variable limitations 14-5custom conversion variables 10-3, 13-2–13-12predefined conversion variables 10-2usage example 14-6–14-9

cookies in sitecatalyst 20-9–20-10correlations 8-2–8-4cross-category merchandising 13-9–13-12custom events 9-6custom event types 9-8custom insight variables 4-4, 7-2–7-11custom link tracking 15-18–15-20

without javascript 18-9custom traffic variables 4-4, 7-2–7-11

D

data feed 21-36data sources 21-28–21-30data warehouse 21-33–21-34debugger 1-10, 25-6delimited prop 7-8developer community 22-2–22-3digitalpulse 24-2–24-10, 25-7

configuration 24-3form checker 24-5masks 24-3reports 24-7–24-9scan limits 24-4scan manager 24-2scan scheduler 24-4

discover 21-37–21-38doPlugins function 16-4–16-5dynamic variables 20-14–20-16

E

enterprise api 22-3eVars 13-2–13-12

usage example 14-6–14-9events 9-4–9-10

custom events 9-6

custom event types 9-8events variable 10-2incrementor 11-8naming events 9-7predefined events 9-5purchase 11-2–11-3scOpen 10-8scRemove 10-8serialization 11-5

F

first-party cookies 20-10flash tracking 20-2–20-8fusion deployment methodology 3-4

G

genesis 21-30–21-31getQueryParam plug-in 12-3, 16-5–16-6getValOnce plug-in 16-6global javascript file (s_code.js) 1-8

H

hierarchy variable 4-4, 6-4–6-7

I

incrementor 11-8insight 21-37internal campaigns 12-7, 13-4–13-5internal url filters 20-12ip address 20-12ip address, exclude by 20-12

J

javascript debugger 1-10–1-11, 25-6

K

key business requirements 2-5, 3-2–3-3key performance indicators 2-5, 3-2–3-3knowledge base 26-5–26-6

L

link tracking 15-16–15-20list prop 7-8list variables 13-9

M

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


merchandising variable 13-9–13-12metrics

conversion visits and visitors 14-4page views 1-6prodView 10-6purchase 11-2–11-3scAdd 10-6scCheckout 10-7scOpen 10-8scRemove 10-8scView 10-7traffic metric availability by report 8-8–8-9visits 1-6

mobile device subscriber id 15-15mobile image request 18-4–18-7mobile report suite 18-3mobile site tracking 18-2multi-currency support 15-9–15-11multi-suite tagging 15-8

N

naming conversion events 9-7naming traffic variables 7-10

O

optimum path engine 8-5

P

packet analyzers 1-12, 25-6–25-7page grouping 7-6–7-7page-level code 1-8page name variable 4-4, 5-2–5-18page naming strategy 5-2–5-13page naming utility 5-16page views 1-6paths 8-5–8-8php appmeasurement 18-12–18-20plug-ins 16-2–16-8

apl append list plug-in 16-7doPlugins function 16-4–16-5getQueryParam 12-3getQueryParam plug-in 16-5–16-6getValOnce plug-in 16-6

predefined events 9-5processing rules 17-1–17-22

common use examples 17-13–17-16

context data variables 17-3copy processing rules 17-12creating a rule 17-8limitations 17-6processing order 17-5restoring rule sets 17-12rule conditions 17-8–17-9rule history 17-11setting actions 17-10setting context variables 17-10

process of using web analytics 2-5products variable 10-2, 10-5–10-12, 11-10prodView event 10-6props 4-4–4-6, 7-2–7-11

usage example 8-15–8-17purchase event 11-2–11-3purchase id variable 10-2, 11-3

Q

query string parameters 18-7

R

rdc 20-11redirects 20-13referrers 20-12regional data collection 20-11report builder 21-38reports

conversion funnel report 9-9–9-10products 10-9referrers 20-12shopping cart conversion funnel 10-9

report suitesmobile site 18-3multi-suite environment 5-14multi-suite tagging 15-8rollup report suite 15-8

retail events 9-5rollup report suite 15-8

S

s_account 15-7SAINT (sitecatalyst attribute importing and naming

tool) 21-14scAdd event 10-6s.campaign 10-3, 12-2–12-7

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


scCheckout event 10-7s.channel 4-4, 6-2–6-3s.charSet 15-9s_code.js 1-8s.cookieDomainPeriods 15-12s.currencyCode 15-9–15-11scView event 10-7sdr 3-5s.dynamicAccountSelection 15-8serialization 11-5server variable 4-4, 6-4s.eVarN 13-2–13-12

usage example 14-6–14-9s.events 10-2–10-12s.fpCookieDomainPeriods 15-13s.hierN 4-4, 6-4–6-7shopping cart conversion funnel 10-9sitecatalyst

asi (advanced segment insight) 21-34code 1-8–1-10cookies 20-9–20-10data warehouse 21-33–21-34exclude by ip address 20-12interface elements 2-4internal url filters 20-12report structure 2-3

site section variable 4-4s.linkDownloadFileTypes 15-16s.linkExternalFilters 15-18s.linkInternalFilters 15-17s.linkLeaveQueryString 15-17s.linkTrackEvents 15-18s.linkTrackVars 15-18s.mobile 15-15s_objectID 15-14solution design reference 3-5s.pageName 4-4, 5-2–5-18s.pageType 4-4, 6-8–6-9s.products 10-2, 10-5–10-12, 11-10s.propN 4-4–4-6, 7-2–7-11

usage example 8-15–8-17s.purchaseID 10-2, 11-3s.server 4-4, 6-4s.state 10-3, 11-5–11-6states variable 10-3, 11-5–11-6s.track 20-7

s.trackDownloadLinks 15-16s.trackExternalLinks 15-17s.trackInlineStats 15-14s.trackLink 20-7s.transactionID 10-2, 11-4subrelations 14-2–14-3subsections 7-6–7-7s.zip 10-3, 11-5–11-6

T

tag management 23-2third-party cookies 20-10tracking code variable 10-3, 12-2–12-7traffic breakdowns 8-2–8-4traffic variable enhancements

classifications 4-4, 21-2–21-4correlations 4-4pathing 4-4unique visitors metric 4-4visits metric 4-4

traffic variable limitations 4-5traffic variables 4-3–4-6

naming 7-10usage example 8-15–8-17

training videos 26-5–26-6transaction id variable 10-2, 11-4

U

uniques exceeded 5-10

V

variablescontext data variables 17-3conversion allocation 12-5custom conversion variable 10-3delimited prop 7-8list prop 7-8list variables 13-9s.campaign 10-3, 12-2–12-7s.channel 4-4, 6-2–6-3s.eVarN 10-3, 13-2–13-12

usage example 14-6–14-9s.events 10-2s.hierN 4-4, 6-4–6-7s.pageName 4-4, 5-2–5-18s.pageType 4-4, 6-8–6-9

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


s.products 10-2, 10-5–10-12, 11-10s.propN 4-4, 7-2–7-11

usage example 8-15–8-17s.purchaseID 10-2, 11-3s.server 4-4, 6-4s.state 10-3, 11-5–11-6s.transactionID 10-2, 11-4s.zip 10-3, 11-5–11-6

visits 1-6vista (visitor identification, segmentation and transfor-

mation architecture) 16-8–16-11

W

web analyticsstrategic process 2-5

Z

zip/postal code variable 10-3, 11-5–11-6

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

A-1

Appendix A

Answers to Review Questions

Traffic Section 2: Answers to Review Questions

1. How does SiteCatalyst collect traffic data for your site?

a. Reading server logs that are passed to SiteCatalyst

b. The Adobe Crawling Engine crawls the Web site and logs all traffic data

c. Code is placed on each page of your site, and information is sent to Adobe when pages load and the code is executed

d. Customers opt in to be part of the tracking community, at which time code is placed on their machines to watch Web movement

2. What are the different types of SiteCatalyst variables?

a. Conversion, Traffic, and Paths variables

b. Persistent , non-persistent, and list variables

c. Traffic, Conversion, Configuration, and Automatic variables

d. Traffic, Conversion, Configuration, and ClickMap variables

3. What is the default page naming value (if the pageName variable is not populated)?

a. There is no default; the page name variable must be populated for the page information to be recorded in SiteCatalyst

b. The HTML page title tag

c. The page URL

d. The page URI

4. When selecting the appropriate level of page naming detail, you should be sure to include the User ID or Session ID within the page name.

a. True

b. False

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

A-2 Adobe® SiteCatalyst® Implementation Training Student Workbook

5. What is the maximum character (byte) length for the server variable?

a. 20

b. 100

c. 255

d. 2083

6. Custom Insight Variables (props) must be set on every page that you want the value reported.

a. True

b. False

7. Where can you give a user-friendly name to your Custom Insight Variable reports?

a. On the Tools page in SiteCatalyst.

b. In the Admin console in SiteCatalyst.

c. It has to be set in the variable string along with the specific value.

d. It must be done by Adobe ClientCare.

8. Match the Traffic variable to its function (some functions will not match). Write the number of the correct function next to the variable.

Variable

a. pageName 6

b. channel 3

c. server 8

d. hierN 1

e. propN 4

Functions

1. This is a special variable type used for cascading views of content categories.

2. This is used for site conversion numbers and provides conversion visits and visitors.

3. This is a predefined traffic variable, traditionally used for high-level content categories.

4. This provides customization and segment reporting based on page views, visits or visitors.

5. This is used for tracking external campaigns.

6. This controls the value displayed in all page-related reports, including Path reports.

7. This provides customization and segment reporting based on conversion metrics such as revenue and orders.

8. This is a predefined traffic variable sometimes used to show balance between multiple Web sites in a global environment.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Appendix A Answers to Review Questions A-3

Conversion Section 3: Answers to Review Questions

1. The purpose of Conversion reports is to:

a. Track the revenue, units, and orders of standard shopping cart Web sites.

b. Track the conversion of any type of retail (revenue generating) Web site.

c. Track visitor success or conversion of any events that occur on a Web site.

d. Track pages relating to conversion transactions.

2. Out of the following list, chose the predefined retail success events (circle all that apply).

a. scOpen f. prodView

b. scAdd g. scOrder

c. revenue h. scUnits

d. scRemove i. scCheckout

e. scView j. purchase

3. What are the four most common pages to be coded in order to capture basic shopping cart success?

a. Product detail page, shopping cart page, shipping page, checkout page

b. Product detail page, shopping cart page, billing page, order confirma-tion page

c. Product detail page, shopping cart page, checkout page, order con-firmation page

d. Home page, shopping cart page, checkout page, order confirmation page

4. Which of the following are correct syntax for the product variable on a product detail page? Circle all that are correct.

a. s.products=”prodView”

b. s.products=”category;product”

c. s.products=”product;category”

d. s.products=”category,product”

e. s.products=”;product”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

A-4 Adobe® SiteCatalyst® Implementation Training Student Workbook

5. What is the most correct statement regarding eVars?

a. An eVar tracks success events.

b. An eVar tracks data related to products only.

c. An eVar tracks custom segments and data and is stored in a virtual cookie.

d. An eVar tracks conversion metrics for custom segments and data and is populated on each page.

6. Enabling “full subrelations” (super-breakdowns) for an eVar will provide essentially the same breakdown options as the s.campaign variable.

a. True

b. False

7. eVars are persistent and will expire:

a. when the visit has ended.

b. when the visitor reaches the predefined success event.

c. when the expiration time or event is reached as defined in the Admin console.

d. on each page load.

8. Which is true of the SiteCatalyst cross-category Merchandising functionality?

a. It allows products to be tied to a dynamic merchandising channel rather than a static parent channel.

b. Allows a 1:1 relationship between a product and an eVar value.

c. Merchandising values can be set in the product string or on the page, depending on the settings chosen.

d. All of the above.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

B-1

Appendix B

Answers to Exercises

NOTE: The exact variable that you use will be specific to your implementation (the exercise example may use s.prop2 to capture “Internal Search Term”, but you may use s.prop2 for a different purpose in your implementation). Please contact your Account Manager or Implementation specialist for more information about your solution.

CHAPTER 5

Exercise 5.1: Page Names

Key Business Requirements• Understand page traffic on Web site • Understand worldwide page use across multiple sites• Ability to filter Page Names by location (hierarchical site structure)

Key Performance Indicators• Page Views, Visits and Unique Visitors to Page Names with prepended

Report Suite ID• Page Views, Visits and Unique Visitors to Hierarchy Levels

AssignmentIn your book, write the Page Name code for the following pages:

1. The JJ Esquire Home Page on the Germany site2. The Women’s Fur Trim Ski Jacket in Activewear on the JJ Esquire United

States site.3. The Men’s Tuxedo page in Fine Apparel on the JJ Esquire France site4. The Men’s Tuxedo page in Fine Apparel on the JJ Esquire United Kingdom

site

Solution1. s.pageName=“DE:Home Page”;

2. s.pageName=“US:Women:Activewear:Fur Trim Ski Jacket”;

3. s.pageName=“FR:Men:Fine Apparel:Tuxedo”;

4. s.pageName=“UK:Men:Fine Apparel:Tuxedo”;

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

B-2 Adobe® SiteCatalyst® Implementation Training Student Workbook

Site Exercise 5.2: Detailed Page Names

AssignmentOn your own JJ Esquire Web site, code Page Name based off of site structure using a colon as a delimiter. Validate that code was passed in appropriately.

1. The JJ Esquire Home Page 2. The Sequin Dress in Women’s Fine Apparel3. The Hooded Sweater in Men’s Activewear

Note: To differentiate page names on your site from those of other students, prepend a global value such as your initials, e.g., s.pageName=“JG:Men:Fine Apparel:Tuxedo”.

Solution• Use s.pageName to record basic user-friendly hierarchical page names

Examples Code the page name

s.pageName=“Home Page”;

s.pageName=“Women:Fine Apparel:Sequin Dress”;

s.pageName=“Men:Activewear:Hooded Sweater”;

Implementation• Document the variable in SDR (if you haven’t already): s.pageName• Deploy code & Validate: PageName plug-in, Dynamic script, etc.

CHAPTER 6

Exercise 6.1: Traffic Variable Usage

Key Business Requirements• Need to know content site usage at page and levels • Determine if there are links to retired content

Key Performance Indicators• Number of Page Views to pages that get traffic• List of links to missing content and number of attempts to access content • Traffic Metrics for the main areas of our site, available in top-level site navi-

gation

AssignmentWhat kind of variable(s) should you use to fulfill each business requirement?

Solution• Use s.pageName for user-friendly page names• Use s.pageType to track 404 Error page • Use s.channel for major/top level site sections

Example s.pageName=“Jewelry:Rings:Diamond Ring”


s.channel=“Jewelry”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute

Appendix B Answers to Exercises B-3

Implementation• Assign variables in SDR: s.pageName, s.channel and s.pageType• Deploy code and validate• Do not set s.pageName on 404 Error Page

Site Exercise 6.2: Error Page

Key Business Requirement• Determine if there are links to retired content.

Key Performance Indicators• List of retired links and the number of times each link is clicked

AssignmentCode the “404 Error Page” to automatically record links to retired content (error page can be accessed from the “Site Map”).

Solution• Code the s.pageType variable appropriately on the 404 Error Page

Examples.pageName=“”


Implementation• Assign variables in SDR: s.pageType• Deploy code & Validate• Do not populate s.pageName

Exercise 6.3: Traffic to Content Structure

Key Business Requirements• Track visitor traffic to multiple levels of page structure on the site• Understand consolidated site traffic across multiple sites• Ability to segment by site at the Global Report Suite level

Key Performance Indicators • Traffic Metrics for Site Sections, Sub-Sections, Sub-Sub-Sections, etc...

Assignment:What kind of variable(s) should you use to fulfill the business requirements?

Solution• Use s.hier1 to track visitor traffic on multiple site levels and enable desired

metrics• Use s.server to identify the site name (use a Global Report Suite to consoli-

date metrics from multiple sites)(Alternate: Use s.channel and multiple s.props for each level of hierarchy - enable metrics as needed for each variable - Page Views is the only available metric when drilling down.)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Examples:s.hier1=“Jewelry|Rings|Diamond Ring Page”

s.server=“Site 07” or s.server=“UK Site”

Implementation• Assign variable in SDR: s.hier1• Deploy code & Validate• Verify that hierarchy is being recorded correctly in SiteCatalyst reports

Site Exercise 6.4: JJ Esquire Pages

AssignmentCode the following pages:

1. Home Page2. Women Site Section page3. Women’s Activewear subsection page4. The Fur Trim Ski Jacket in Women’s Activewear

With the following values where applicable:

1. Page Name2. Server3. Site Section4. Hierarchy

Solution:• use s.pageName for all page names• use s.server to indicate site name on all pages• use s.channel for all Site Sections• use s.hier1 for hierarchies

Product Page Example:s.pageName=“Women:Activewear:Fur Trim Ski Jacket”

s.server=“JJ Esquire United States”


s.hier1=“Women|Activewear|Fur Trim Ski Jacket”

or s.hier1=s.pageName (if you set “:” as your delimiter)

Women Site Section Page Example:s.pageName=“Women”



s.hier1=“Women”

Women’s Activewear Subsection Page Example:s.pageName=“Women:Activewear”



s.hier1=“Women|Activewear”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Home Page Example:s.pageName=“Home Page”


s.channel=“Home Page”

s.hier1=“Home Page”

CHAPTER 7

Site Exercise 7.1: JJ Esquire Pages

AssignmentCode the following pages:

1. Home Page2. Women Site Section page3. Women’s Activewear subsection page4. The Fur Trim Ski Jacket in Women’s Activewear

With the following value where applicable (not all pages may be part of a subsection):

1. Subsection

Solution:• use s.prop1 for all subsections

Product Page Example:s.hier1=“Activewear”

(or “Women’s Activewear” if you don’t wish to combine Traffic Metrics with Men’s Activewear, but be consistent)

Women Site Section Page Example:No subsection

Women’s Activewear Subsection Page Example:s.prop1=”Activewear”

(or “Women’s Activewear” if you don’t wish to combine Traffic Metrics with Men’s Activewear, but be consistent)

Home Page Example:s.prop1=”Home Page” (optional)

Discussion:Do I need to give my Home Page a subsection name? What kind of reporting does it give me? If I enable Paths for s.prop1, what kind of path reports can I see?

Generally, placing the home page into a subsection report is done so that you can see the home page in subsection Path Reports. Additionally, if you wish to see traffic for subsections and the home page in the same report, the home page must be included as a subsection in the Subsection Report.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 7.2: Internal Search Tracking

Key Business Requirement• Understand internal user search behavior

Key Performance Indicators • The number of searches for every internal search term • The number of results per search term including zero search results• The number of times a search scope is used in conjunction with the search

term

Assignment:What kind of variable(s) should you use to fulfill the business requirements?

Solution• s.prop2 for search term (force lower case)• s.prop3 for the scope of the search• s.prop4 for the number of search results(Alternate: Capture all values in one prop and use classifications to break values out into separate reports - more work, but less props used)

Example s.prop2=“Laptop Computers”


s.prop3=“Computers”

s.prop4=“125”

Implementation• Assign variables in SD: s.prop2, s.prop3, s.prop4• Deploy code & Validate: Dynamic script or getQueryParam • Specify report name: Internal Search Term, Internal Search Success

Hint: Always force case with user input to avoid multiple entries

Site Exercise 7.3: Internal Search Term Tracking

AssignmentRecord the following search activity on the appropriate page and force user-inputted values to lowercase using JavaScript:

A visitor searches for “Wall Decor” in the “Home & Garden” section and gets “78” search results.

Note: Make sure that the search term is set to lowercase via JavaScript.

Solution• s.prop2 for search term (force lower case)• s.prop3 for the scope of the search• s.prop4 for the number of search results

Example s.prop2=“Wall Decor”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute



s.prop3=“Home & Garden”

s.prop4=“78”

Implementation• Assign variables in SD: s.prop2, s.prop3• Deploy code & Validate: Dynamic script or getQueryParam • Specify report name: Internal Search Term, Internal Search Success

Hint: Always force case with user input to avoid multiple entries

Site Exercise 7.4: Hotel Bookings

Key Business Requirements• Understand visitor behavior and choices throughout the online booking

process• Track all hotel booking options within the selection process• Track by Hotel ID, Rooms Booked, Length of Hotel Stay, Days to Arrival and

Rate Code

Key Performance Indicators• Number of reservations by Hotel ID, Rooms Booked, Length of Hotel Stay,

Days to Arrival and Rate Code

AssignmentRecord the visitor’s actions on the appropriate JJ Travel page:

A visitor to the JJ Travel site books a stay at the “JJ Esquire Park City, Utah” (Hotel ID) with “2 rooms” (Rooms Booked) for “7 days” (Length of Hotel Stay) “21 days in advance” (Days to Arrival) at the “0759” rate (Rate Code).

Solution• Code the props on the confirmation page “Company:JJ Travel Completion”• s.prop5 for Hotel ID• s.prop6 for Rooms Booked• s.prop7 for Length of Hotel Stay• s.prop8 for Days to Arrival• s.prop9 for Rate Code

Example s.prop5=“JJ Esquire Park City, Utah”

s.prop6=“2”

s.prop7=“7 Nights”

s.prop8=“21 Days”

s.prop9=“0759”

Implementation• Assign variables in SDR: s.prop5 - 9 • Deploy code & Validate: Dynamic script• Specify report names in the Admin Console

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Exercise 7.5: Traffic by Membership Type

Key Business Requirements• Understand how much traffic is associated with different membership types

on your site, based on your existing Gold, Silver, Bronze members and public traffic

Key Performance Indicators • How much traffic is coming from members who log in (Gold, Silver, Bronze

members) and those who don’t (public traffic)?

AssignmentWhat kind of variable(s) should you use to fulfill the business requirements?

Solution• Set s.prop10 as “Public User” on every page if not logged into site• Set s.prop10 as user type (“Silver Member”) on every page after logging in

Example s.prop10=“Public User”;

s.prop10=“Silver Member”;

Implementation• Assign variable in SDR: s.prop10• Deploy code & Validate: Dynamic script pulling user type• Specify report name in the Admin Console

Site Exercise 7.6: Newsletter Subscriptions

Key Business Requirement• Understand which JJ Newsletters subscriptions are favored by JJ Esquire site

visitors

Key Performance Indicators • Record the newsletter name and subscription count of JJ Newsletters for all

visitors

AssignmentJJ Esquire offers various weekly newsletters. Code to record the following using s.prop(s):

A visitor signs up for the following newsletters: “JJ Living”, “JJ Foreign Policy”, “JJ Special Offers” and “Random Spam”.

Solution• Enable List Prop functionality for s.prop11 with pipe (“|”) as delimiter and

set all survey responses from a visitor into the prop

Example s.prop11=“JJ Living|JJ Foreign Policy|JJ Special

Offers|Random Spam”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Note: Remember to not exceed the 100 bytes allowed by the prop. May require abbreviation in the <value> name of the form if pulling from query string.

Implementation• Assign variable in SDR: s.prop11 (ask ClientCare to enable as List Prop) • Deploy code & Validate: Dynamic script or getQueryParam to pull responses

submitted• Specify report name in the Admin Console

CHAPTER 8

Exercise 8.1: Additional Traffic Features

Key Business Goals• Understand how visitors move from Site to Site and Site Section to Site

Section• Track site traffic by visit and unique visitor metrics• Analyze the relationship between Site-, Site Section- and Page-level informa-

tion

Key Performance Indicators • Traffic metrics for all corporate domains in a single report • Paths between Sites, Site Sections and Pages• Visit and Unique Visitors (Daily, Weekly, Monthly) for each level (Site, Site

Section, Page) • Page Views for break downs by Site, Site Section, and Pages by each other in

any combination

AssignmentWhat kind of variable(s) and feature(s) should you use to fulfill the business require-ments?

Solution• Use s.server for domain names and s.channel for site sections in a global

report suite• Enable Visits and Unique Visitors (Daily, Weekly, and Monthly) for Server,

Site Section (channel), and Page Name• Enable correlations for Server, Site Section, and Page Name

Example Code s.server=“JJ Esquire Spain”;

s.channel=“Company”;

s.pageName=“Company:Newsletter Subscription Start”;

Implementation• Assign variables in SDR: s.server, s.channel, s.pageName• Deploy code & Validate• Adobe ClientCare enables the following:

› Paths for s.server and s.channel (paths enabled by default for s.pageName)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


› Correlation for s.server, s.channel, and s.pageName › Visits, Daily, Weekly and Monthly UVs for s.server, s.channel, and

s.pageName

Exercise 8.2: Analyzing Trafffic Flow

Key Business Requirements• Understand the paths of registered users versus guest users• Understand how visitors move between groups of pages

Key Performance Indicators• Page Views per registration status (registered/guest user)• Path Views of paths by registration type• Path Views of paths between Site Sections


Solution• Set s.prop12 to record registration status. Persist that value across all pages

with a cookie or the Persist Value plug-in. Set an additional Custom Traffic Variable, s.prop13, that concatenates first s.prop value with s.pageName.

• Enable pathing for s.prop13• Enable pathing for Site Sections

Examples.prop12=“Registered”

s.prop13=s.prop12 + “:”+ s.pageName

Result is visitor type with page names.prop13=“Registered: Jewelry:Watches:Tissot Titanium

Aviator Watch”

Implementation• Assign variables in SDR: s.prop12 and s.prop13• Adobe ClientCare enables the following:

› Pathing for s.prop13 › Pathing for Site Sections › Deploy code & Validate: Dynamic script or getAndPersistValue plug-in

for s.prop12 & s.prop13• Specify report names:

› Signed-in Status › Pages by Signed-in Status

Site Exercise 8.3: Internal Search Term Flow

Key Business Requirements• Understand what terms come before and after a specific internal search term• Understand the path a visitor traverses by internal search term• Don’t inflate the regular search term report (double count searches)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Key Performance Indicators• Path Views of keyword paths (When someone searches by “watch”, what do

they search next?)• Path Views of page paths by keyword (When someone searches by “watch”,

which pages does he or she view next?)

AssignmentCode the “Search Results” page with the proper variable(s) and enable the proper feature(s) to fulfill the business requirements for the following scenario:

A visitors searches by “watch”.

Solution• Capture internal search term in s.prop2 and force to lowercase• Set the term into s.prop14 on every page using the getAndPersistValue plug-

in or your own server-side scripting and concatenate Page Name (hard code for this practice exercise)

• Enable pathing for s.prop2 and s.prop14

Examples.prop2=“watch”


s.prop14=s.getAndPersistValue(s.prop2,‘s_getval’)+“>”+s.pageName

End result example: s.prop14=“watch>Men:Accessories:Watches”

Note: the “>” sign was arbitrarily used as a delimiter between Internal Search Term and Page Name in this example. The implementer used it to visually separate Terms from Page Names.

Implementation• Assign variables in SDR: s.prop2 and s.prop14• Specify report names in the Admin Console• Adobe ClientCare enables the following:

› Pathing for s.prop2 and s.prop14• Deploy code & Validate: Dynamic script or getAndPersistValue plug-in for

s.prop14

CHAPTER 9

Site Exercise 9.1: Custom Events

Key Business Requirements• Understand the JJ Newsletter Sign Up conversion rate

Key Performance Indicators • Number of Newsletter Subscription Starts• Number of Newsletter Subscription Completions

Assignment

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Code the “JJ Newsletter Subscription” pages in the Company Site Section with the proper custom event(s) to count all Newsletter Subscription Starts and Completions.

Solution• Use Event 1 and Event 2 to track Starts and Completions, respectively• View automatically created conversion rate reports in SiteCatalyst

Example s.pageName=“Company:Newsletter Subscription Start”


s.hier1=“Company|Newsletter Subscription Start”


s.pageName=“Company:Newsletter Subscription Completion”


s.hier1=“Company|Newsletter Subscription Completion”


Implementation• Assign variable in SDR: Event 1 and Event 2• Specify report names in the Admin Console • Deploy code & Validate

CHAPTER 10

Site Exercise 10.1: The Checkout Process

Key Business Requirements• Understand and improve purchase behavior at each step of Checkout• Maximize checkout process conversion

Key Performance Indicators• Record “Product Views” by product• Record “Cart Adds” by product• Record “Checkouts” by product• Record “Shipping Info” form completion by product • Record “Payment Info” form completion by product

AssignmentCode for the following scenario:A visitor views the “Military Jacket” in Men’s Activewear, adds it to the cart, checks out and completes the shipping and payment information pages.

Solution – Step 1Identify the conversion events:

• View product (prodView)• Add product to cart (scAdd)• Proceed to checkout (scCheckout)• Input Shipping information (event3)• Input Payment Info (event4)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Solution – Step 2Code the events on appropriate pages:

• prodView Product detail page• scAdd After adding product to cart• scCheckout After clicking “Checkout”• event3 After Shipping Info page • event4 After Payment Info page

Solution – Step 3“Men:Activewear:Military Jacket” page



After “Add to Cart” button “Checkout:Shopping Cart” pages.events=“scAdd”


After “Checkout” button “Checkout:Shipping Step 1” pages.events=“scCheckout”


After Shipping Information page “Checkout:Payment Step 2”s.events=“event3” //Shipping complete


After Payment Information page “Checkout:Order Review Step 3”s.events=“event4” //Payment info complete


Implementation• Assign variables in SDR: prodView, scAdd, scCheckout, event3, event4 • Deploy code & Validate: each event on the appropriate page• Specify report name for custom event3 (Shipping Info complete) and event4

(Payment Info complete) in Admin Console

CHAPTER 11

Site Exercise 11.1: Multiple Products

Key Business Requirements• Ability to track multiple item orders at the product level from browsing to

final purchase• Track shopping cart conversion• Ensure that orders are only counted once• Make it possible to later link offline data to this online transaction• Ability to track orders and revenue by state and zip

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Key Performance Indicators• Cart Adds, Checkouts, Shipping Complete, Payment Complete, Orders,

Revenue and Units by Product, State and Zip

Assignment• Code for the following scenario for the Final Confirmation Page:• Visitor purchases one (1) Black Dress and two (2) Red Dresses from

“Women:Fine Apparel”• Order number is 123456789• Billing state is California and zip is 92121

Solution Order Confirmation Step 4 (Purchase button clicked on Order Review Step 3)


s.products=“;101340;1;3290.00,;101341;2;9440.00”

s.purchaseID=“123456789”


s.state=“California”

s.zip=“92121”

Note: s.zip is alphanumeric. If “San Diego” is more meaningful to the analyst than “92121”, then the city name can be used (the analyst could also classify postal codes).

Implementation• Assign variables in SDR: predefined and custom variables and events• Deploy code & Validate: Dynamic script• Name custom reports through Admin Console

Site Exercise 11.2: Event Incrementor

Key Business Requirements• Track Postage and Sales Tax for products purchased

Key Performance Indicators • Postage and Sales Tax by product and all other associated conversion vari-

ables

AssignmentAssume that you are coding on the JJ Esquire Germany site. Code for the following scenario on the Order Confirmation page:

• Visitors purchases Red Dress (SKU 101341) for 3.499,99 € • Postage cost = 4,50 € and tax (VAT) = 6,19 €• Order ID is 987654321• Billing state is Nordrhein-Westfalen and postal code is 40547

Note: Assume that the Euro has already been set as the Report Suite default currency.

Solution• Use the purchase event to track the order• Use events 5 and 6 to track postage cost and sales tax

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Examples.events=“purchase,event5,event6”;

s.products=“;101341;1;3449.99;event5=4.50|event6=6.19”;

s.purchaseID=“987654321”


s.state=“Nordrhein-Westfalen”

s.zip=“40547”

Note 1: Only use (“.”) as decimal separator and do not use a thousands separator.

Note 2: s.zip is alphanumeric. If “Düsseldorf ” is more meaningful to the analyst than “40547”, then the city name can be used (the analyst could also classify postal codes).

Implementation• Assign variable in SDR: predefined events, event5 & event6• Deploy code & Validate: Dynamic script• Enable events 5 & 6 as currency types in Admin tab• Specify event names: Postage Cost, Sales Tax

Site Exercise 11.3: Event Incrementor with Multiple Products

Key Business Requirements• Track product sales on the site by SKU, including customer location, postage

costs and sales tax

Key Performance Indicators • Revenue for multiple item orders by product SKU, State and Zip• Postage and tax by product

Note: Where applicable, use the same events from the previous exercise.

AssignmentAssume you are coding on the JJ Esquire Japan site. Code for the following scenario on the Order Confirmation page:

• Visitor purchases two (2) Sport Jackets (SKU 200244) for ¥22,000• Postage is ¥400 and Sales Tax is ¥1,100 for each unit• Visitor purchases one (1) Hooded Sweater (SKU 200233) for ¥42,500• Postage is ¥250 and Sales Tax is ¥2,100• Order ID is 1234abcd• Billing prefecture is Kansai and city is Osaka (use s.state and s.zip, respec-

tively)

Note: Assume that the Yen has already been set as the Report Suite default currency.

Solution• Use the purchase event on page after order is finalized (Order Confirmation

Step 4)• Use event5 for Postage and event6 for Sales Tax• Include the purchaseID, transactionID, state, and zip variables on the pur-

chase event page

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Examples.events=“purchase,event5,event6”

s.products=“;200244;2;44000;event5=800|event6=2200,

;200233;1;42500;event5=250|event6=2100”

s.purchaseID=“1234abcd”


s.state=“Kansai”

s.zip=“Osaka”

Note 1: Do not use a thousands separator in Revenue.

Note 2: s.products should be written on one line (written on two lines in example).

Implementation• Assign variables in SD: purchase, event5, event6, products, purchaseID,

transactionID, state, zip• Enable event5 and event6 as currency event type• Deploy code & Validate: Dynamic script • Specify event and variable names in Admin Console: Postage Costs (event5),

Sales Tax (event6), Prefecture (s.state), City (s.zip)

CHAPTER 12

Exercise 12.1: Campaign Tracking

Key Business Requirements• Track Return on Ad Spend on all online paid advertising including • online efforts (banners, emails, paid search, affiliates) • Track Return on Ad Spend for offline campaigns (radio)

Key Performance Indicators • Click throughs and Conversion Events for online external campaigns • Click throughs and Conversion Events for offline radio ads with special

landing page


Solution• Use s.campaign to record all external campaign traffic• Capture query string parameter with getQueryParam (set in s_code.js)• Create special landing page for radio ad

Example

Captured with Plug-In (any landing page):s.campaign=s.getQueryParam(‘cid’)

•

Hard coded on specific landing page:s.campaign=“radio ad:1”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Implementation• Assign variables in SDR: s.campaign• Deploy code & Validate: Dynamic script, getQueryParam, landing page for

radio ad with hard coded s.campaign

Site Exercise 12.2: Campaign Tracking with getQueryParam




• Click throughs and Conversion Events for online external campaigns

AssignmentInstall the getQueryParam plug-in in your s_code.js file and verify that Tracking Codes are populating s.campaign (getQueryParam available in “Company:White Papers”).

To verify that Tracking Codes are populating, go to the “Search Engine Page” (link available on the “Site Map”) and click through the “JJ Esquire Ski Sale” add. The Tracking Code is “jj_ski_sale”.

SolutionCopy and paste in the code from the “Company:White Papers” section. This code includes the s_doPlugins function. Notice that the call to the getQueryParam plug-in is placed in the doPlugins function. You should also place calls to any future plug ins within doPlugins.

Example

/* PLUGIN CONFIG */

s.usePlugins=true



}


/* PLUGIN MODULES */

/*

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

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


+”.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 ‘’”);

CHAPTER 13

Site Exercise 13.1: Internal Campaign Tracking

Key Business Requirements• Understand how the home page Charge Card promotion affects Charge Card

application conversions

Key Performance Indicators • Internal Campaign Clicks by Charge Card campaign• Charge Card application completions by Charge Card campaign

AssignmentThe home page Charge Card promotion’s link contains the tracking code “homepage-cc-advert” preceded by the trigger “intcmp”.

Using the getQueryParam function in the s_code.js, set s.eVar1 to capture all Internal Campaigns that contain the “intcmp” query string parameter.

Solution• Use the getQueryParam function to capture Internal Campaign Tracking

Code• Set s.eVar1=s.getQueryParam(‘intcmp’) in the doPlugins function

Example Codes.usePlugins=true


s.eVar1=s.getQueryParam(‘intcmp’)

}


Implementation• Assign variable in SDR: s.eVar1 • Specify variable name in Admin Console: Internal Campaign Tracking Code

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


• Deploy code & Validate: Dynamic script, getQueryParam

Site Excercise 13.2: JJ Hotel Reservation Conversion Tracking

Key Business Requirements• Understand how search options affect conversion• Determine best promotional links on site

Key Performance Indicators • Number of bookings for each hotel• Number of bookings by internal search options: destination city, travel date,

and number of guests (to find which options resulted in the most bookings)• Number of bookings by Internal Promotional links

AssignmentWhat kind of variable(s) and feature(s) could you use to fulfill the business requirements in this travel site scenario?

Solution• Use purchase event for bookings and product string for the hotel name, num-

ber of nights and total revenue for stay (alternate: an eVar could be used for hotel name and three custom events for bookings, number of nights and total revenue)

• Use eVar1 for internal promotions (getQueryParam to capture internal promo codes)

• Use eVar2 for travel date• Use eVar3 for number of guests• Use eVar4 for destination city

Example Codes.events=“purchase”;

s.products=“;JJ Esquire Park City;1;349.00”;

s.eVar1=s.getQueryParam(‘intcmp’)

s.eVar2=“20 July”

s.eVar3=“2”

s.eVar4=“Park City”

Implementation• Assign event in SDR: purchase• Assign variables in SDR: eVars 1-4• Deploy code & Validate: Dynamic script and getQueryParam()• Specify report names in Admin console for each eVar report• Change “Orders” metric name to “Bookings” in Admin console (also possibly

change Units to “Nights Booked”)

Exercise 13.3: Merchandising by Revenue Channel

Key Business Requirements• Segment sales by merchandising category

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Key Performance Indicators • Product Revenue by cross-category merchandising

AssignmentScenario: Tissot Aviator Watch (SKU 300720) is available for sale in two sections of the Web site: “Men:Accessories” and “Jewelry:Watches”.

One visitors viewed the watch in the “Men: Accessories” category. Another visitor viewed the watch through the “Jewelry:Watches” category.

How would you cod e the Merchandising Category in each circumstance on the Product Page, using s.eVar6, and following Product Syntax?

Solution• Set an eVar to record merchandising category on the Product Page

Examples Product viewed from the “Men:Accessories” category:


s.products=“;300720;;;;eVar6=Men:Accessories”

s.pageName=“Men:Accessories:Tissot Aviator Watch”

Product viewed from the “Jewelry:Watches” category:s.events=“prodView”

s.products=“;300720;;;;eVar6=Jewelry:Watches”

s.pageName=“Jewelry:Watches:Tissot Aviator Watch”

Results: When the item is purchased, the revenue will be allocated to the category in which the product was viewed.

Implementation• Assign variable in SDR: s.eVar6• Adobe ClientCare enables Merchandising for eVar6• Configure Merchandising settings• Deploy code & Validate: specific products • Specify report name: Merchandising Category

CHAPTER 14

Quick Quiz 14.1

Question 1You need to identify the number of Orders you get from people that search by “Sport Jacket” on your site. What variable type should you use to capture Internal Search Term?

AnswerA Converion Variable (s.eVar)

s.eVar5=“sport jacket”


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Question 2You need to identify the number of Page Views you get from people that search by “Sport Jacket” on your site. What variable type should you use to capture Internal Search Term?

AnswerA Traffic Variable (s.prop).

s.prop2=“sport jacket”

(Page View counted each time a prop is set)

Question 3You want to create a report that shows which products 40-44 year olds purchase. What variable type should you use to capture Age Group?

AnswerA Conversion Variable (s.eVar)

s.eVar20=“40-44”

s.products=“;101333;1;4250”


(s.eVar20 and s.products are subrelatable with common metric “Orders”)

Question 4You want to create a report that shows which pages 40-44 year olds view on your site. What variable type should you use to capture Age Group?

AnswerA Traffic Variable (s.prop).

s.prop20=“40-44”

s.pageName=“Women:Fine Apparel:Sequin Dress”

(set up a correlation between s.pageName and s.prop4)

Exercise 14.2: A Plethora of Forms

AssignmentDivide into two teams.

You have 10 different Forms on your site. You need to track Form Starts and Completions for each Form.

Figure out three different ways to code the 10 Form Starts and Completions using:1. Only s.prop(s)2. Only s.events3. A combination of s.eVar(s) and s.events4. Determine which method you think is best for your purposes.

Remember, you only have 75 props, 75 eVars and 20 events.

Extra credit: Is it possible to code 20 forms and record form starts and form completions without using more than the SiteCatalyst limit of 75 props, 75 eVars or 20 events? What if you had 100,000 different forms?

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Solution for s.propsUse one s.prop to capture form name and start or completion status. Using this method you can record as many forms as needed, but the reporting can get a little unwieldy as the number of forms increases. The sort metric for all forms and form statuses is “Page View”.

Example

s.prop30=“Customer Service Form Start” //Form Name and Status

s.pageName=“Customer Service Form Start”

s.prop30=“Customer Service Form Completion”//Form Name and Status

s.pageName=“Customer Service Form Completion”

Solution for s.events

Use event1 for the Start and event2 for the Completion of the First Form. Use event3 for the Start and event4 for the Completion of the Second Form and so forth until all 10 forms are coded (exhausting our 20 events). The result is 20 different reports.

Works for this example, but it doesn’t work for 20 forms. On top of that, we no longer have any events to use for other purposes!

Example

s.events=“event1” //Form Start Metric


s.events=“event2” //Form Completion Metric


Solution for the s.events and s.eVar comboUse s.eVar7 to capture form name and set with event7 or event8 for Form Start and Form Completion, respectively. Use s.eVar3 to capture as many form names as needed.

Examples.eVar7=“Customer Service Form” //Form Name

s.events=“event7” //Form Start Metric


s.eVar7=“Customer Service Form” //Form Name

s.events=“event8” //Form Completion Metric


Which method is best?Generally speaking, the s.events and s.eVar combo is the best method Burning all of your events is not a good option for this exercise.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Using s.props is a valid alternative, but it can make reporting a bit of a headache for analysts (imagine tracking 100,000 forms using the s.events and s.eVar combo vs. using the s.prop method).

CHAPTER 15

Exercise 15.1: Configuration Options

Key Business Requirements• Ability to record Great Britain Pound currency (GBP)• Set the s_vi[ID] cookie to the correct domain (jjesquire.co.uk)• Track data in appropriate Report Suite (jjesquireuk)

Key Performance Indicators• Revenue in Pounds Sterling• All Metrics by Report Suite segment

AssignmentHow would you set the Configuration Variables to comply with our KBRs and KPIs?

Solution• Set s.currencyCode for Great Britain Pounds• Set s.cookieDomainPeriods for “3”• Verify that s_account is populated with the correct Report Suite

Examples.currencyCode=“GBP”

(All currencies are converted to the default Report Suite currency which is set dur-ing Report Suite creation. If USD was originally set as the default, all new currency values, including Pounds Sterling, would be converted to US Dollars. Each Report Suite has its own default currency.)s.cookieDomainPeriods=“3”

s_account=“jjequireuk”

Exercise 15.2: Configuration Options

Key Business Requirements• Track global retail Web sites• Track links to affiliate sites• Be able to track specific unique links within site• Ability to record Japanese characters and Japanese Yen currency (JPY)• Ability to track exit links and custom links• Ensure that data is being tracked in appropriate report suite within SiteCatalyst• Track mobile visitors to our web site using the device Subscriber ID in lieu of

cookies

Key Performance Indicator • Exit Clicks to external sites

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Scenario• Japanese Web site is encoded in SHIFT_JIS• Adobe assigned report suite ID of “yoursitejp”• URL of your site is www.jjesquire.co.jp• Custom links use s.prop5, s.prop6, and event3• Track exit links, but not file download links• Track mobile visitors using the Subscriber ID if available

AssignmentHow should the configuration variables be set in the JavaScript file?

Solution

Implementation• Assign variable in SD: s.prop5, s.prop6, event3• Deploy code & Validate: set configuration settings• Specify report names: Specific custom link usage names for reports prop5,

prop6, and event3

Site Exercise 15.3: Charge Card Application

Key Business Requirement• Understand Charge Card Application Conversion

Key Performance Indicators• Application Starts (event9) and Completions (event10) for Charge Card

Application (s.eVar7)Note: The application is completed on a third-party site called Passport Charge Card. For this exercise, we want to know if the visitor has completed the parts of the application contained on our web site (we cannot place SiteCatalyst code on a third-party site that we do not own). “Completion” should be recorded each time a visitor completes Step 2 of the application.

AssignmentCode the JJ Charge Card Application fulfilling the KBR and KPIs listed above.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Solution• Use event9 for Form Starts, event10 for Form Completions and s.eVar7 for

Form Name• Use Custom Link Tracking to code the Form Completion event into the

“Proceed to Apply” link (subsequent page is third-party site)

Example for Application Step 1 Page (Start of Application)s.eVar7=“Charge Card Application”


s.pageName=“Company:JJ Charge Card Step 1”


Example for Application Page Step 2 (last page on the JJ site)<a href=“exit_site.php” onClick=“var s=s_gi(‘your-rsid’);

s.linkTrackVars=‘eVar7,events’;


s.eVar7=‘Charge Card Application’;


s.tl(this,‘o’,‘JJ Charge Card:Proceed to Apply’);

”>Proceed to Apply</a>

Note: Even though s.eVar7 persists from the App Start Page, it should be set here again in the case that a visitor started a different application in another window while still in the middle of this one (which would change the value set in s.eVar7 with last-touch application).

Implementation• Assign variable in SDR: s.eVar7, event9, event10• Deploy code & Validate: verify custom link code• Specify report names: s.eVar7, event9, event10

CHAPTER 16

Quick Quiz 16.1

Question 1What would be the Adobe-recommended way(s) to capture internal promotion click-throughs?

a. Use the s.campaign variable to capture the valuesb. Use an eVar on the landing page to capture the valuec. Use the getQueryParam plug-in to capture the valued. Use custom link tracking to capture the value

AnswerC or D. B is also technically valid, but not recommended for internal promotions.

Question 2What would be the Adobe-recommended way to segment employee site traffic from visitor traffic?

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


a. Use login IDs to segment employees from visitorsb. Duplicate domain on your intranet for employees and create a second report suitec. Create an employee landing page that drops a cookie; use a prop and pathing to segment d. Use a VISTA rule to separate internal and external traffic into two report suites

AnswerD. It’s a lot easier and much more realistic.

Question 3How could you ensure that the tracking code click-throughs metric is not inflated?

a. Hardcode the campaign value (tracking code) on the landing pageb. Use the getValOnce plug-in to ensure no Click-through duplicationc. There will be no recounting; Pathing de-duplicates reloadsd. Use a VISTA rule to prevent overcounting click throughs

AnswerB. getValOnce keeps you from counting twice!

Question 4How could you quickly add a Page View event to every page on your site?

a. Use the getQueryParam plug-in to pull page views from query stringb. Use the APL plug-in to append a Page View event to s.eventsc. Use getValOnce to add but not over count Page View eventsd. Use VISTA to add the Page View event each time a page is viewed

AnswerB and D. B is a client-side solution (preferred because the plug-in is free). D is a server-side solution.

Site Exercise 16.2: Internal Search Term

Key Business Requirement• Track Internal Search Terms to understand which keywords lead • to conversion

Key Performance Indicators• Internal Search Term Searches• Conversion by Internal Search Term

AssignmentCapture Internal Search Term (Internal Search Term appears in query string after the “q” parameter)

Solution• Use the getQueryParam function to capture Internal Search Term on the

search results page• Designate “q” as the parameter in the getQueryParam function

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Examples.eVar5=getQueryParam(‘q’) //Set in s_code.js

s.eVar5=s.eVar5.toLowerCase() //Best practice

s.prop2=s.eVar5; //Good chance to code this

Implementation:• Assign variable in SDR: s.eVar5• Deploy code & Validate: verify with debugger• Place getQueryParam in JS file• Specify report name in Admin Console: Internal Search Term

Site Exercise 16.3: Newsletter Subscriptions

Key Business Requirements• Understand which Newsletters are most popular• Create a single report that shows Newsletter subscriptions

Key Performance Indicator• The number of times a Newsletter was selected during the subscription pro-

cess

AssignmentCode the Newsletter Subscription process to capture Newsletter names (a visitor can sign up for multiple Newsletters at the same time). Record the number of subscription instances per Newsletter.

Hint: Selected newsletter subscriptions appear on subsequent page in the query string under parameters “n1” through “n9”.

Solution• Enable getQueryParam in s_code.js and call plugins inside doPlugins• Set n1-n9 as parameters and the pipe (“|”) as the delimiter• Use s.prop11, a ClientCare-enabled List Prop with “|” as delimiter

Examples.prop11=s.getQueryParam(‘n1,n2,n3,n4,n5,n6,n7,n8,n9’,‘|’)

Implementation• Assign variable in SDR: s.prop11 (enabled as a List Prop)• Deploy code & Validate: verify with debugger• Places getQueryParam plug-ins in JS file• Specify report name: Newsletter Subscriptions

Site Exercise 16.4: Time Parting Plug-In


Understand Traffic and Conversion by time period


Traffic and Conversion metrics by hour, day and weekday/weekend

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Assignment:

Install the getTimeParting Plug-in (ask your Instructor and colleagues for assistance if necessary). Use props and eVars 16, 17 and 18 for hour, day and weekday, respectively.

The Plug-in is available in Company>White Papers on the fictitious JJ Esquire Web site or in Help>Supporting Docs>Implementation>Plug-ins in SiteCatalyst.

SolutionInstall the getTimeParting Plug-in. Set the each eVar equal to its corresponding prop.

Example/* timeparting daylight savings info is placed in the

configuration variables area, before doPlugins. Set your daylight savings time according to local custom. */

s.dstStart=”3/14/2010”;

s.dstEnd=”11/7/2010”;

s.currentYear=”2010”;

/* Here, in doPlugins, we set the calls to the plug-in for each prop and also populate the data into eVars for Conversion by Hour, Day and Weekday or Weekend. Your doPlugins function will already have calls to other plug-ins such as the getQueryParam plug-in. Those other values have been omitted in this example.*/

s.usePlugins=true


s.prop16=s.getTimeParting(‘h’,’-7’); // Set hour

s.prop17=s.getTimeParting(‘d’,’-7’); // Set day

s.prop18=s.getTimeParting(‘w’,’-7’); // Set weekday

s.eVar16=s.prop16;

s.eVar17=s.prop17;

s.eVar18=s.prop18;

}


/* Below doPlugins, paste in the getTimeParting code. This can go above or below preexisting plug-ins such as getQueryParam or others.

/*

* 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’);”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


+”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}}};”);

CHAPTER 17

Class Exercise 17.1: Capture a Campaign Tracking Code


Assignment

Capture a Campaign Tracking code from Query String Parameter “cid”

1. What condition should we set in our Processing Rule?

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


2. What Action should we set?

3. Any caveats with this rule? › Processing Rules can only capture Tracking Codes within the first 255

characters of the URL › If you have extremely long URLs, use the getQueryParam JavaScript

plug-in

Exercise 17.2: Capture Newsletter Subscriptions


Assignment

As you’ve done by using JavaScript AppMeasurement and plug-ins in previous exer-cises, use Processing Rules to:

1. Capture Newsletter Subscription names in Prop 11 (already enabled as a List Prop)

2. Capture Query String Parameters of n1, n2, n3, n4, n5, n6, n7, n8 and n9 in Prop 11

3. Use the Pipe (“|”) as the delimiter between values4. Do not Save the Processing Rule5. Ask your instructor to check your work

Solution

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Site Exercise 17.3: Coding Context Variables


Assignment

1. Set Page Code on the Corduroy Blazer page in Men’s Activewear:

s.contextData[‘page’]=“Men:Activewear:Corduroy Blazer”

s.contextData[‘section’]=“Men”

s.contextData[‘subsection’]=“Activewear”

2. Use the debugger to verify that variables have been passed in3. Ask your instructor to check your work

Note: Remember that Context Data is only processed and recorded if Processing Rules have been configured previously for such data. In this example, nothing will be recorded since no Processing Rules have been set up yet for this Context Data.

Solution

Exercise 17.4: Using Context Variables


Assignment

1. In the Processing Rules Manager, create Processing Rules to: › Push the value of s.contextData[‘page’] into s.pageName

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


› Push the value of s.contextData[‘section’] into s.channel › Push the value of s.contextData[‘subsection’] into s.prop1

2. Do not Save the Processing Rule3. Ask your instructor to check your work

Solution

CHAPTER 18

Site Exercise 18.1: Mobile Site Landing Page


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute



• Understand Campaign landing page activity, subsequent traffic and conversion


• Page Views, Visits, Unique Visitors and Campaign instances and Conversion metrics

Assignment

1. Hard code the image request for the Kitchen Essentials Campaign Landing Page using the same variables that you would use on the regular site (access from Mobile Home Page – the partially completed image request is at the bot-tom of the page code)

2. Page Name is “Kitchen Essentials Sale Landing Page”3. Site Section is “Home and Garden”4. Subsection is “Kitchen”5. Campaign is “kitchen_sale”

SolutionFill in the proper Request Domain, Mobile RSID, Image Type, Random Number and Query String. Set the Image Beacon to 5x5. Place Web beacon inside the <body> tags.

Example <img src=”http://omnituretraining4.d1.sc.omtrdc.

net/b/ss/train04scit01/5/WAP/38713482753?ce=UTF-8&cc=USD&gn=Kitchen%20Essentials%20Sale%20Landing%20Page&ch=Home%20and%20Garden&c1=Kitchen&v0=kitchen_sale” width=“5” height=“5” alt=“” border=“0” />

Implementation

1. Assign variables Page Name, Site Section, Subsection and Campaign in Mobile Site SDR

2. Deploy code & Validate3. Verify that the variables are being recorded correctly in SiteCatalyst reports

Site Exercise 18.2: Mobile Site Landing Page



• Understand Charge Card Application Conversion on our mobile Web site (find out if applicants submit the application on our site and continue on to the third-party credit card site)


• Application Completions (event10) for Charge Card Application (s.eVar7)

Assignment

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


1. Hard code the image request for the Mobile Site JJ Charge Card Application exit link button on the final application page (siteN/mobile/chargecard/jjcard_app2.php).

2. Recording the Application Completion event and the name of the Form (link is at the bottom of the final application page – it’s called “Proceed to Apply”)

3. Some of the values in the request have been filled in for you – double check to make sure all necessary values have been recorded and test your results

Solution

• Use event10 for Form Completions and s.eVar7 for Form Name• Use a hard-coded image request with a redirect to the final destination URL to

code the Application Completion event into the “Proceed to Apply” link (subsequent page is third-party site)

• Fill in appropriate Requesting Domain, RSID and Query String values

Example <a class=”button” href=”http://dcrookston.

d1.sc.omtrdc.net/b/ss/outrainjjscitsite01/4/REDIR/?url=http%3A%2F%2Fwww.ou-training.com%2Fjjsite%2Finclude%2Finclude%2Fcharge_card_site.php&pe=lnk_e&pev1=D=url&pev2=Charge%20Card%20Application%20Completion&ev=event10&v7=Charge%20Card%20Application&ce=UTF-8&cc=USD”>Proceed to Apply</a>

Implementation

• Assign variable eVar7 and event Event10 in Mobile Site SDR• Deploy code & Validate• Verify that the Form Names and Application Completion event is being

recorded correctly in SiteCatalyst reports

Site Exercise 18.3: PHP AppMeasurement


Use the PHP AppMeasurement Library to Dynamically Create an Image Request.


• Accurately track Conversion and Traffic site activity on the JJ Esquire Mobile Site using the PHP AppMeasurement Library


• Page Views, Visits, Visitors, Product Views, Page Name, Product Name, Site Section, Subsection

Assignment

• Go to the Women:Activewear:Tie-Waist Puffer Jacket page on the Mobile Site

• Populate Page Name, Site Section, Subsection, Product Name and any pertinent events

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Solution<?php

require_once ‘../OmnitureMeasurement.class.php’;

$s = new OmnitureMeasurement();


$s->account = ‘your_RSID_here’;


$s->pageName = ‘Women:Activewear:Tie-Waist Puffer Jacket’;

$s->pageURL = getCurrentUrl();

$s->server = ‘Mobile Site’;

$s->channel = ‘Women’;

$s->pageType = ‘’;

$s->prop1 = ‘Activewear’;

$s->prop2 = ‘’;


$s->state = ‘’;

$s->zip = ‘’;

$s->events = ‘prodView’;

$s->products = ‘;100240’;

$s->purchaseID = ‘’;

$s->transactionID = $s->purchaseID;

$s->eVar1 = $_GET[‘intcmp’];

$s->eVar2 = ‘’;

$s->manageVisitorID();

$s->currencyCode = ‘USD’;

$s->cookieDomainPeriods = 2;

$s->mobile = true;

$s->botDetection = true;


$s->debugTracking = false;


/* WARNING: Changing any of the below variables will cause drastic changes

to how your visitor data is collected. Changes should only be made


$s->trackingServer = ‘dcrookston.d1.sc.omtrdc.net’;

?>


Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Note: It is only possible to see the image request of this exercise in the Debugger on the PHP JJ Esquire site. The HTML version of the site does not reside on a Web server and cannot process PHP.

Implementation

• Assign variables and events in the Mobile Site SDR• Deploy code & Validate• Verify that the variables and events are being recorded correctly in

SiteCatalyst reports

CHAPTER 20

Exercise 20.1: Working with Dynamic Variables

AssignmentEffeciently code for the following scenario using Dynamic Variables. Write the answer in your workbook.

1. Page Name is “Womens:Accessories:Hand Bag”2. Section is “Womens”3. Subsection is “Accessories”4. Hierarchy is “Womens:Accessories:Hand Bag”5. Search term is “Hand bag” and should be captured in a prop and eVar6. Campaign Name is “Spring Accessories”7. Effeciently code to capture Page Path by Campaign Name in s.prop20

SolutionDynamic Variables can occur before the original or source variable has been stated in the code (unlike JavaScript) as long as it’s in the same image request as the original or source variable.

s.pageName=“Womens:Accessories:Hand Bag”;

s.channel=“Womens”;

s.prop1=“Accessories”;

s.hier1=“D=gn”;

s.prop2=“Hand bag”;

s.eVar5=“D=c2”;

s.campaign=“Spring Accessories”;

s.prop20=‘D=v0+“:”+gn’;

CHAPTER 21

Quick Quiz 21.1

Question 1How would you upload descriptive information for your campaign tracking codes?

a. Data Sources

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


b. SAINTc. VISTAd. Send the file to [email protected]

AnswerB. Group data to create new reports with SAINT.

Question 2You can’t get code onto the page until the next code review, but you want to start track-ing a custom success event. What can you do?

a. Use SAINT to upload the page into SiteCatalystb. Have Adobe create a VISTA rule to add the event in the mean timec. Create a classification for the event in the Admin toold. Beg and plead with your IT team to allow the change

AnswerB. If you can’t make a change on your side, make the change server-side. Oh yeah!

Question 3Which tool(s) provides a graphical overlay on your Web page to show you which links are the most popular?

a. Adobe ClickMapb. SearchCenter+c. Adobe Discoverd. Adobe ReportBuilder

AnswerA. It’s ClickMap!

Question 4Which export method(s) give the client “raw data?”

a. Data Warehouse b. SAINTc. Adobe ReportBuilderd. Data Feed

AnswersA and D. Raw and uncut! (Data Feed is unprocessed pre-VISTA data.)

Question 5Which export method(s) provides an active link that allows you to download SiteCatalyst data into a spreadsheet and refresh the metrics at the click of a button?

a. Data Warehouse Requestb. SAINTc. Adobe ReportBuilderd. Data Feed

AnswerC.

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Question 6Which tool(s) can be used to upload offline data, such as orders, email send and open data, etc.?

a. Adobe Genesisb. VISTAc. Data Sourcesd. SAINTe. Adobe ReportBuilder

AnswersA and C.

Question 7Which tool(s) are used for data segmentation?

a. Adobe Discoverb. Data Warehouse Requestc. Adobe SiteCatalyst d. All of the above

AnswerD. Create and analyze segments with all three!

CHAPTER 25

Site Exercise 25.1: Solution ValidationGoal: Validate Implementation

1. Check the four error pages very closely for code problems2. Use debugger to check/validate variables3. List errors on an Error Log in your book4. Correct errors in page code (.php files) 5. Rerun debugger to ensure the solution works

Check the following pages:Men:Fine Apparel:Two-Button SuitMen:Fine Apparel:Blue ShirtMen:Fine Apparel:French Cuff ShirtMen:Fine Apparel:Tuxedo

Solution Error LogsMen:Fine Apparel:Two-Button Suite1. Missing quotes on s.pageNameWas:

s.pageName=Men:Fine Apparel:Two-Button Suit”

Change to: s.pageName=“Men:Fine Apparel:Two-Button Suit”

2. Event “prodview” needs a capital “v” to be recognizedWas:

s.events=“prodview”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


Change to: s.events=“prodView”

Men:Fine Apparel:Blue Shirt1. s.prop13: Remove quotes from variables, place the colon in quotes and capitalize “N” in s.pagenameWas:

s.prop13=“s.prop12+:+s.pagename”

Change to: s.prop13=s.prop12+“:”+s.pageName

Men:Fine Apparel:French Cuff Shirt1. Populate the correct Report Suite ID 2. Missing s.linkTrackVars (populate with “eVar8” and “events”)3. Change the “e” value (for Exit Link) to “d” (for File Download)

Was:<a href=”http://www.ou-training.com/jjsite/include/

downloads/mens_shirt_size_conversion.pdf”

onClick=”var s=s_gi(‘rsid’);

s.linkTrackVars=’eVar,events’;

s.eVar8=’Shirt Size Conversion Chart’;

s.events=’event7’;

s.tl(this,’e’,’Shirt Size Conversion Chart’);”

>Download the <br />Shirt Size Conversion Chart</a>

Change to:<a href=”http://www.ou-training.com/jjsite/include/

downloads/mens_shirt_size_conversion.pdf”

onClick=”var s=s_gi(‘yourReportSuiteName’);

s.linkTrackVars=’eVar8,events’;

s.linkTrackEvents=’event7’;

s.eVar8=’Shirt Size Conversion Chart’;

s.events=’event7’;

s.tl(this,’d’,’Shirt Size Conversion Chart’);”

>Download the <br />Shirt Size Conversion Chart</a>

Men:Fine Apparel:Tuxedo1. JS file location is wrongWas:

src=“another/folder/s_code.js”

Change to: src=“../../s_code.js”

(we recommend that you use absolute links on your site)

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute


2. s.pageType is being used for Subsection (should only be used for error pages)Was:

s.pageType=“Fine Apparel”

Change to: s.prop1=“Fine Apparel”

Adobe

Inter

nal U

se O

nly

Do Not

Distrib

ute