Website Traffic Audit Rules/Guidance Notes. (Incorporating JICWEBS Reporting Standards)

Transcription

1 Website Traffic Audit Rules/Guidance Notes (Incorporating JICWEBS Reporting Standards) Version Issued March 2013

2 TABLE OF CONTENTS A1 THE ROLE AND PURPOSE OF ABC 5 A2 BENEFITS OF ABC CERTIFICATION 5 A3 USING THIS GUIDEBOOK 5 A4 HOW THE STANDARDS ARE DEVELOPED AND CHANGED 5 A5 YOUR RESPONSIBILITIES AS AN ABC MEMBER 5 A6 FURTHER INFORMATION 5 B1 DATA LOGGING 6 B1.1 Log Format Required Fields 6 B1.2 Consistency of Log Format 6 B1.3 Log Format Required Fields (Applications) 6 B2 DATA FILTERING AND EXCLUSIONS 6 B2.1 Exclusions 6 B2.1.1 Invalid Filetypes 7 B2.1.2 Pushed traffic 7 B2.1.3 Invalid User-Agents 7 B2.1.4 Invalid IP Addresses 7 B2.1.5 Invalid HTTP transactions 7 B2.1.6 Invalid URLs 8 B3 CERTIFICATION 8 B3.1 Minimum Reporting Standards 8 B3.1.1 Reporting Periods for Unique Browsers 8 B3.1.2 Certifying App Traffic 8 B3.2 Continuous Reporting 9 B3.2.1 Continuous Reporting - Certifying Metrics 9 B3.2.2 Continuous Reporting Publicity 9 B3.3 Ensuring Comparability in Metrics 9 B3.4 Transparency 9 B3.4.1 Reporting App Traffic 10 B3.4.2 Syndicated Content 10 B3.4.3 Syndicated Content Framework 10 B3.5 Breakouts of Inventory 10 B3.6 Breakouts of Page Impression Types 10 B3.7 Averages 10 B3.8 Account Metrics 10 B3.9 Certificate Release and Layout 10 B4 AV METRICS - IPTV (BMWG) 10 B4.1 Measuring Simulcast 10 Filtering 11 Graph Preparation 11 B4.2 Measuring VOD Engagement 11 C1 INTRODUCTION 12 C1.1 Guiding Principles of Audit 12 C2 OVERVIEW OF THE AUDIT PROCESS 12 C2.1 Initial Registration (New Sites Only) 12 C2.2 Pre-Audit Preparatory Work (New Sites Only) 12 C2.3 The Audit 12 C3 FILTERING 12 C3.1 Why Filtering is Necessary 12 C3.2 ABC Filtering Guidance 13 C3.2.1 Default Exclusion of Filetypes 13 C3.2.2 Exclusion of Robotic User-Agents 13 C3.2.3 Additional Exclusions 13 C3.2.4 Derivation of Breakouts 14 C3.2.5 Claiming Paid Subscriber Accounts 14 C3.3 Audit Completion 14 C4 DATA STORAGE, SUPPLY AND DELIVERY14 C4.1 Data Storage 14 C4.2 Data Supply and Delivery 14 C4.2.1 Why a BrowserID+Date file? 14 C4.2.2 Methods of Data Delivery 14 C5 CERTIFICATION AND PUBLICITY 14 C5.1 Certificate Issue and Release 14 C5.1.1 Declaration of Inventory 15 C5.1.2 Media Owner Statement 15 C5.1.3 Media Owner s Logo 15 C5.1.4 Calculating Average Visit Duration 15 C5.2 Publicity and use of ABC Logo 15 C5.2.1 Quoting and Sourcing Figures and using the ABC Logo 15 C6 COMPLAINTS 15 C6.1 Publicity 15 C6.2 Appeals against an ABC decision 15 D1 INTRODUCTION 16 D2 GENERAL ISSUES 16 D2.1 Proxies and Caching 16 D2.2 Page Tagging 16 D2.3 Comparing Server-Side and Browser-Side Measurement 16 D3 UNIQUE BROWSERS 16 D3.1 What is a Unique Browser? 16 D3.2 Unique Browsers from Pushed Traffic 17 D3.3 User-Agent Considerations 17 D3.3.1 Mixed Logging 17 D3.3.2 Media Player User-Agent Identifiers 17 D3.4 BrowserID+Date File 17 D3.4.1 Alternative to the BrowserID+Date File 17 D3.5 Cookies 17 D3.5.1 Counting Cookies 19 D3.5.2 First v Third-Party Cookies 19 D3.5.3 Interactive TV Cookies 19 D3.6 Automated Content (Web Feed and Podcast) 19 D3.7 Compound Unique Browser Identifiers 19 D4 PAGE IMPRESSIONS 21 D4.1 Breakout of Page Impression Subtypes 21 D4.2 Identifying Automated Page Impressions 21 Page 2 of 39

3 TABLE OF CONTENTS D4.3 Identifying Interactive TV Traffic 21 D4.4 Identifying Page Impressions within Rich Media 21 D4.4.1 Guidance 21 D4.4.2 Examples 22 D4.5 Identifying Mobile Format Traffic 22 D4.5.1 Mobile Format URLs 22 D4.5.2 WAP Impressions 22 D4.6 Identifying HTML Chat Traffic 22 D4.7 Searches 22 D4.7.1 Query Parameter 22 D4.7.2 Unique Identifier for each Search Event 22 D5 AUDIO AND VIDEO (AV) CONTENT 22 D5.1 Measuring AV Plays 22 D5.2 Live and On-Demand AV Plays 22 D6 VISITS 23 D6.1 Calculating and Claiming Visit Duration 23 D6.2 Measuring Visits and Visit Duration in Rich Media Content 23 D7 REFERRALS IN 23 D8 NON-BROWSER TRAFFIC 23 D8.1 Measuring PDA Traffic 23 D8.2 Measuring Web Feed Aggregators and other Automated Content Syndication Agents 23 D8.3 Measuring Apps 24 D9 MEASURING CHAT (IRC) TRAFFIC 24 D10 MEASURING CLICKS AND CLICKOUTS 24 D11 MEASURING PODCASTS 24 D12 GEOGRAPHICAL IP ANALYSIS 24 D13 RECRUITMENT CONVERSION FUNNEL 24 E1 INTRODUCTION 25 E2 TECHNICAL REQUIREMENTS 25 E2.1 Data Sampling (Fieldwork) 25 E2.1.1 Overlays 25 E2.1.2 Fieldwork Period and Sample Size 25 E2.2 Data Reconciliation 25 E2.3 ABC seeding of survey completions 26 E3 CERTIFICATION 26 E4 SECTOR-SPECIFIC REQUIREMENTS 26 E4.1 Consumer 26 E4.2 B2B 26 X1.0 INTRODUCTION 28 Note on Averages 28 X1.1 BROWSER METRICS (Reach) 28 Unique Browser 28 Repeat Unique Browser 28 Single Unique Browser 28 Monthly Unique Browser 28 Weekly Unique Browser 28 Daily Unique Browser 28 Interactive TV Unique Browser 28 AV Unique Browser 28 Search Unique Browser 28 Mobile Unique Browser 28 WAP Unique Browser 28 Chat Unique Browser (HTML Chat ONLY) 28 Web Feed Referral In Unique Browser 28 Web Feed Unique Browser 29 Web Feed Article Impression Unique Browser 29 Requested Podcast Unique Browser 29 Completed Podcast Unique Browser 29 Registered User Account 29 Active Registered User Account 29 Paid Registered User Account 29 Active Paid Registered User Account 29 Subscriber Account 29 Active Subscriber Account 29 Paid Subscriber Account 29 Active Paid Subscriber Account 29 Unique CV Registrant 29 Active CV Registrant 29 Podcast Subscriber 29 Unique Host 29 X1.2 IMPRESSION METRICS (Volume) 30 Page Impression 30 Automated Page Impression 30 WAP Impression 30 Mobile Format Impression 30 Chat Impression (HTML) 30 Interactive TV Impression 31 PDF Impression 31 Job Exposure Page Impression 31 Job Details Page Impression 31 CV Details Page Impression 31 Proprietary Page Impression 31 Online Property Details Page Impression 31 X1.3 OTHER INVENTORY METRICS (Volume) 31 Search 31 Job Search 31 AV Play 31 AV Play Event 31 Page 3 of 39

4 TABLE OF CONTENTS AV Request 31 Automated AV Play 31 AV Content Play 31 AV Content Play Event 31 AV Content Play Request 32 Web Feed Article Impression 32 Web Feed Ad Impression 32 PDA Synch 32 Requested Download 32 Automated Requested Download 32 Completed Download 32 Automated Completed Download 32 Requested Podcast 32 Completed Podcast 32 Online Job Application 32 New CV Registration 32 Job Application Requested Download 32 Online Property Referral 33 Publication Opened 33 User-Initiated Logged Event 33 Section 33 X1.4 VISIT AND DURATION METRICS (Frequency) 33 Visit 33 Visit Duration 33 Unique Browser Duration 33 Chat Duration (HTML ONLY) 33 AV Play Duration 33 AV Play Completion Rate 34 Total AV Play Duration 34 Unique AV Play Duration 34 Unique AV Play Percentage 34 X1.5 CLICK METRICS (Interaction) 34 Click 34 Search Click 34 Clickout 34 Job Clickout 34 Click Visit 34 Online Job Referral 34 Referral In 34 Web Feed Referral In 34 Web Feed Job Referral In 34 Referral In 34 Job Referral 34 X1.6 CHAT METRICS (non-html) 34 Unique Chat Host 34 Unique Chat User 34 Unique Active Chat User 35 Unique Chat User Duration 35 X1.7 Geographical IP-based metrics 35 Page Impressions By Country 35 Unique Browsers By Country 35 Ad Impressions By Country 35 X1.8 APPLICATION METRICS 35 App (Application) 35 App Unique Browser 35 App Page Impression 35 App Event 35 App Visit 35 App Visit Duration 35 App Ad Impression 35 X1.9 AD METRICS 35 X1.10 SMS METRICS 36 X1.11 METRICS 36 X2.0 INTRODUCTION 37 X2.1 INDEX OF DEFINED TERMS 37 Page 4 of 39

5 SECTION A: ABOUT THIS GUIDEBOOK A1 THE ROLE AND PURPOSE OF ABC ABC is the industry owned, tri-partite, non-profitdistributing organisation that works with and for media owners, advertisers and media buyers to help them better understand and gain confidence in the data they use. ABC works in confidence with its clients to help them understand and implement industry-compliant processes to measure their electronic media. A2 BENEFITS OF ABC CERTIFICATION An ABC Certificate is full of valuable information for media buyers and media owners. For media buyers, it offers accurate, comparable data to be used when making buying decisions. For media owners it is an effective sales tool for attracting advertising, because it provides the added credibility that their claims have been independently audited to industryagreed standards. This document details the standards and rules to which all ABC audited websites must adhere, in order to achieve ABC certification. These are divided into Section B, the JICWEBS industry-agreed standards to which ABC reports audited website data and Section C, the requirements of the ABC audit process that you must comply with in order for us to audit your data. Section D contains technical guidance that ABC can offer you as a result of its audit experience. A3 USING THIS GUIDEBOOK The terms you and we should be read as follows: You = The ABC member media owner or their staff We = ABC A4 HOW THE STANDARDS ARE DEVELOPED AND CHANGED The needs of ABC members, and the industry as a whole, change constantly. In order to meet those needs and stay abreast of industry developments, the industry-agreed standards are continuously evolving. It is the industry itself, via JICWEBS (the Joint Industry Committee for Web Standards) fed into by the ITG (the Internet Technical Group) that sets these standards. JICWEBS ( is a body created by the UK and Ireland media industry. Its purpose is to ensure independent development and ownership of standards for measuring on a site-centric, census basis audience reach, frequency and activity levels including the use of advertising on electronic media. If you would like JICWEBS to consider any aspect of these rules (particularly Section B and Appendix 1) please contact them at [email protected]. Changes to the industry standards must be approved by JICWEBS. We will inform you of changes and update this guidebook, downloadable from the Technical Area of our website ( We advise you to check our website regularly to ensure you are using the latest version. A5 YOUR RESPONSIBILITIES AS AN ABC MEMBER As a member of ABC you must comply with the ABC Audit Requirements laid out in Section C when we are carrying out an audit on your behalf. It is important you read and understand these. If you have any questions, please contact your Account Manager or contact [email protected]. A6 FURTHER INFORMATION You can find more information about ABC on our website Here you will find: details of changes to the industry standards or our requirements downloadable forms and reference material the ABC/IAB global Robots List the standard IP exclusions list for UK and Irish traffic marketing support material. Page 5 of 39

6 SECTION B: JICWEBS REPORTING STANDARDS This section details the industry-agreed standards and requirements set out by JICWEBS for all website audits. B1 DATA LOGGING An audit trail back to the original logged records must be established for all the valid traffic records used to support the claim. These logged records may be generated by: Web servers Page tag servers (typically collecting graphic requests generated by browser-side measurement tools) Packet sniffers Whatever their nature, data collection servers must be date and time synchronised, preferably to GMT, so that their log files date and time stamping is aligned. The raw log provides the specific data regarding each file or transaction processed by the server. Appropriate log file archiving procedures must be in place to substantiate your claims for the certification period. The original (raw) log files must be retained for at least the current, and preferably for the prior, Certification Periods. B1.1 Log Format Required Fields Each raw log record should contain at least the following data fields: Date and time stamp of the request, including any adjustment to the time IP Address of the originating user (NB Dottedquad format aa.bbb.cc.ddd, NOT the hostname) Full request-uri, including: o o o Domain (Host) Requested URL Any applicable query parameters Full unmodified User-Agent string Referrer URL Unique Browser Identifier (e.g. Cookie) if not logged in other fields Additionally, for web server logs: HTTP Status code (200, 302, 404 etc) HTTP method of the request (GET, POST etc.) IP Address (or name) of the server Bytes transferred Other fields (e.g. Site-ID, Protocol, Screen Resolution etc.) may be logged if desired. Fields may be logged in any order as long as the minimum standards above are met. Note that the W3C CLF (common log format) does not include fields essential to the accurate counting and auditing of web site activity, such as User-Agent, and as such is NOT suitable audit evidence. Also, some proxy log types (e.g. Squid) do not contain the minimum required fields. Any anonymisation techniques applied to the logs must be agreed in advance with the audit company (e.g. ABC). B1.2 Consistency of Log Format You must not change the format of your log files during the audit period. You must ensure that any third parties managing your log files for you are also aware of these requirements. If you operate a mixed logging format (e.g. some domains on Apache servers, others on IIS), you may fail to exclude robots, and miscount Users and hence Visits, unless you ensure that the User-Agent strings are normalised to the same format throughout before the claimed metrics are calculated. B1.3 Log Format Required Fields (Applications) In order for Application metrics to be certified, the media owner must be able to identify app data (e.g. via URL, domain, separate tag or account ID). These metrics are all subject to appropriate auditable data being provided that contains at least the following fields: Device identifier Event Date Event Time Application Name Application Version Event Description (or Ad URL for Mobile App Ad Impression) IP address User-Agent In certain circumstances, the IP and User-Agent fields may not be present in the data supplied for audit. The auditor retains final discretion over whether any data supplied without these fields is auditable. B2 DATA FILTERING AND EXCLUSIONS B2.1 Exclusions You must filter your traffic to exclude: Invalid filetypes (e.g. graphics) Invalid pushed traffic (e.g. subsiting) Invalid User-Agents (e.g. robots) Invalid IP addresses (e.g. internal addresses) Invalid HTTP transactions (e.g. 302 redirects) And, if certifying Page Impressions, Invalid URLs (e.g. framesets) Page 6 of 39

7 SECTION B: JICWEBS REPORTING STANDARDS B2.1.1 Invalid Filetypes Any filetype that can never represent, or is always served in conjunction with, a valid Page Impression (e.g. graphics, stylesheets) must be excluded from counts. B2.1.2 Pushed traffic There are three main types of pushed traffic subsiting, contextual linking and ISP page replacement. In all cases, Page Impressions, and other metrics such as Unique Browsers and Visits, are generated from content that has been "pushed" into the user s browser. Subsited traffic occurs when, upon a user requesting a page, a new browser window opens automatically on the user s PC (most often as a pop-under) which carries a different page, usually from another site. This second browser window therefore generates a Page Impression for a page (and usually a site) different to that which was intended by the user s action. Contextual linking occurs when the activity of a user in a non-browser application (such as an Instant Messenger client) is analysed and a new browser window is opened (usually as a pop-under) containing a site considered relevant to the subject of the user s activity. Some ISPs serve a page from their own site containing their own content when the ISP s customer enters an invalid URL in their browser which would otherwise produce a standard DNS error page (e.g. Server not found ). This is different to the return of a standard 404 error page; in the 404 s case, the server (domain) the user wanted has been found, but the page has not. Since the user has not requested these pages, nor even a page from the site they requested, such ISP page replacement is considered to be pushed traffic and therefore invalid. Pushed traffic is different in nature from Automated Page Impressions, which are valid under the current industry standards and, when material, declared separately on the certificate. In all cases, Automated Page Impressions result from an intentional user request (at least for the first Page Impression). Pushed traffic cannot ever be the result of an intentional user request. Hence, under the industry-agreed standards, pushed traffic is NOT valid and hence must be excluded from all certified figures. B2.1.3 Invalid User-Agents Sites must exclude material robotic activity from their claimed statistics. By material is meant activity accounting for more than 5% of Page Impressions. It is recommended best practice to use the industry-standard ABC/IAB Global Robots and Spiders List ( ABC/IAB Robots List ) in the exclusion process. The following types of robotic user-agents are included in the standard exclusion process: Personal spiders and offline browsers can have significant and material effects on site traffic. Their activity levels are highly unpredictable over time and across sites. Hence, their User-Agents are NOT included in the standard ABC/IAB Robots List. Sites may need to justify the inclusion of such spiders or other proxy and caching activity to an auditor if the total impact on the site s traffic exceeds 5% of the Page Impressions audited. PDA devices, web feed aggregators and other automated syndication agents are included in the ABC/IAB Robots List. The Page Impressions certified for your site should NOT include any PDA or web feed (e.g. RSS) aggregator traffic. Records with unidentifiable User-Agents (usually nulls, "-") are also deemed invalid, since there is a risk that the activity was not made by a robot. Therefore, any record with a null User- Agent must be excluded along with the robots, unless the site can provide adequate justification for their inclusion. B2.1.4 Invalid IP Addresses All non-mobile traffic generated by internal activity must be excluded (usually by excluding particular IP addresses or URLs). Internal activity is defined as traffic generated by users paid (directly or indirectly) to maintain, develop or author the site. This includes activity such as web site development, performance monitoring, or automated broken link detection. If any of this activity is performed by outside agencies on the site s behalf, this traffic is also deemed to be internal and must be excluded. Traffic generated by non-technical and nondevelopment staff may be included if the site can demonstrate in an auditable manner that it can differentiate such activity from disallowed internal traffic. The standard internal network IP addresses (127.*, 10.*, * to *, and *) listed in RFC 1918 ( as well as the IP addresses used by known automated site monitoring tools, must be excluded. A current list of invalid IP addresses is always available from the Technical Area of Mobile traffic generated by internal activity does not need to be excluded. B2.1.5 Invalid HTTP transactions Only log records with the following HTTP Status Codes may be counted: 200, 201, 202, 203, 204, 205 and 304. HTTP response errors, i.e. all records that do not have a good status code, must be excluded. Status code 206 indicates a partial fulfilment of a request and will always be preceded by a 200; hence, it is not valid for counting of Page Impressions. The HTTP commands "GET" and "POST" are the only two under which information is sent to a user as a result of a valid page request. Therefore, all other HTTP method requests are deemed invalid. NB: The above requirements apply to data logs for browser-side page tagging tools by default; the page Page 7 of 39

8 SECTION B: JICWEBS REPORTING STANDARDS must be rendered successfully in order for the tag code to run. B2.1.6 Invalid URLs When Page Impressions or derived metrics are to be certified, the following additional filters must be applied: Concurrently Served or User-Invisible Content such as framesets and pop-ups are not valid Page Impressions, and therefore must be excluded from certified activity. However, if the user requests that a panel within a frameset, or a pop-up, is refreshed, then serving the refreshed panel may be counted as a Page Impression since it has been requested. Frameset exclusion can be complicated by the difficulty of distinguishing between wanted and unwanted records. The URLs associated with frames will all have valid file extensions. So, unlike the straightforward elimination of unwanted.gif or.jpeg records, it will not be possible to filter records for inclusion or exclusion simply on the basis of their file extension. Pop-ups are deemed invalid wherever they are served concurrently with other content requested by a valid user. Departure pages (bounce-through pages, goto pages) are pages to which the user is redirected without their knowledge before leaving the site. These are deemed invalid unless they contain visible content that is delivered to the user. However, they can be used to count Referrals In or Clickouts, and so the site may wish to process them to count these metrics. Automatically Refreshed Content is valid (if otherwise compliant), since the user is deemed to have requested the refresh by staying on that URL. However, such automated traffic must be broken out if greater than 5% of the total Page Impressions. See the Automated Page Impressions definition in Appendix 1. Splash pages do not need to be excluded from audited figures. The industry has agreed that they offer advertisers a genuine opportunity to see. However, any page automatically refreshed from a splash page becomes refresh traffic, as above, and therefore must be broken out if greater than 5% of the total Page Impressions. Sites may wish to distinguish the homepage URL from the URL to which the splash page automatically sends the user, so as to avoid all homepage Page Impressions being recorded as automated. Initial requests for PDF files (those with an HTTP status code of 200) may contribute to the Page Impression total. PDF content may instead be certified as Downloads; however, any record counted as a Download cannot also be counted as a Page Impression. Traffic from anonymous proxies is not by default invalid. However, if the behaviour of such traffic does not appear human upon analysis, it may be excluded. Finally, the following types of URL may affect certified numbers; if detected in material quantities, they may result in exclusions or adjustments being made: Pages with incomplete information not allowing clear attribution of the page to the site s traffic; Locally cached pages; Pages retrieved via translation services or other third-party tools. B3 CERTIFICATION B3.1 Minimum Reporting Standards These are as follows: A minimum certification period of a calendar month; Certification of the Daily Unique Browser metric totals for each day in the month; Certification of the derived Average Daily Unique Browser metric (calculated as per B3.7, Averages). JICWEBS recommend that at least 2 audits are completed annually, each with a minimum certification period of one calendar month. Any longer audit periods must be in units of calendar months. B3.1.1 Reporting Periods for Unique Browsers Where stated, Monthly Unique Browser figures are obtained by deduplicating all the valid Unique Browser identifiers found in activity during a calendar month. Weekly Unique Browsers are obtained by deduplicating all the valid Unique Browser identifiers found in activity for whole weeks (Monday-Sunday) within the period audited. Hence the number of Weekly Unique Browser totals certified will vary depending on the amount of such whole weeks within the certification period. B3.1.2 Certifying App Traffic For App traffic to be certified, the App must either be: A "web-based" App, which does not work without a connection (e.g. search Apps) or A "hybrid" App, which can work offline but does need to update to get new content (e.g. digital edition Apps). If the activity of any web-based or hybrid App is measured using a consistent, persistent identifier of that App, then the activity may be measured as web traffic (either Unique Browsers or App Unique Browsers). The type of App must be known in advance of any certification. Other types of App are: Button Apps: these are simply a button that launches the standard device browser with an embedded link that opens the media owner s web site. Effectively, they act as simple bookmarks and are therefore not subject to App Page 8 of 39

9 SECTION B: JICWEBS REPORTING STANDARDS certification. The traffic generated by such Apps is web traffic, not App traffic. Pure Apps: these Apps are entirely selfcontained and the App is the content. Once you have downloaded the App you need no further connection (other than for software updates) these can count as a download but do not generate further traffic, so cannot be certified as web traffic. The logged traffic substantiating the claimed metric(s) must carry values within the Domain and URL fields of the data submitted for audit that allow identification of the App(s) and of events within the App(s). These values may be actual website Domains and URLs or equivalent indicators. Pushed traffic If updates to the content of hybrid Apps are pushed to the device (e.g. via automated XML feeds), as opposed to pulled by user initiated action (including automated App Impressions), the activity is not web traffic but Web Feed traffic. Hence, while (App) Unique Browsers can be certified, other traffic metrics such as App Page Impressions, Visits and Visit Duration cannot. Offline traffic [not applicable from 1 st August 2012] The media owner must identify and remove offline traffic from data to be certified as Web traffic. This rule may change in future when a clearer understanding of the tests required to guard against the clear risk of material overstatement is achieved. However, offline traffic may be reported on a separate App certificate. B3.2 Continuous Reporting If the media owner opts to report every month on a continuous basis, the certification period will be 6 calendar months (January to June and July to December). This methodology is known as Continuous Reporting. B3.2.1 Continuous Reporting - Certifying Metrics Where certification is continuous: Average Daily and Daily Unique Browsers must be reported. Monthly Unique Browser figures and Weekly Unique Browser figures can also be reported. Monthly Unique Browsers are obtained by deduplicating valid Unique Browser identifiers found in activity during each calendar month. Where Monthly Unique Browser figures are reported, as indicated by clause B3.7, the Derived Monthly Average Unique Browsers certified will be the sum of each month s traffic divided by the total number of months in the reporting period certified. The Monthly Unique Browsers are not deduplicated between months. If the media owner opts to report Page Impressions, then these must be reported for each month and the derived average across all months, as for Unique Browser figures detailed above. Where Weekly Unique Browser figures are reported, these are obtained by deduplicating all the valid Unique Browser identifiers found in activity for whole weeks (Monday-Sunday) within the period audited (i.e. based on standard ABC reporting weeks). The weekly figures may not reconcile to the monthly figures on the certificate due to the ABC standard reporting weeks not coinciding with calendar months. The Average Weekly Unique Browser figures will also be reported. As indicated by clause B3.7, the Derived Weekly Average Unique Browser figures certified will be the sum of each whole week s traffic divided by the total number of whole weeks in the reporting period certified. The Weekly Unique Browsers are not deduplicated between weeks. B3.2.2 Continuous Reporting Publicity Any figure from an optional six month certificate quoted by a media owner must be accompanied by the period of certification and the derived average of the six individual months Unique Browser figures. This average can be shown as a footnote. Comparisons between different audited web figures involving a six month certificate must be on a like-for-like basis and must include the derived average of the six individual months Unique Browser figures for any site being compared that has a six month certificate. For example, a media owner can compare March 2010 Unique Browsers for website A which reports web data every month against the March 2010 Unique Browser figure for website B (which reports every six months), providing the derived average of the six individual months Unique Browser figures for website B accompanies the comparison. B3.3 Ensuring Comparability in Metrics Different totals for your metrics may result from using different Unique Browser identifiers (e.g. Cookie versus IP+User-Agent). Averages of totals derived from different calculation methods cannot be certified; neither can Duration metrics if the means of counting them differs from the means of counting the Page Impressions (or AV Plays) from which they are derived. B3.4 Transparency Sites may obtain certification for any web inventory they choose. Consequently, the inventory that is certified can include third-party authored or syndicated content. Clients may specify the site name they wish to appear on their audit certificate. If this name is a domain name or URL, then that domain name (or URL) MUST be present in the inventory being certified. Furthermore, those top level domains (or in specific cases URLs) covering at least 95% of the audited Page Impressions MUST be stated on the certificate. Additional information such as site logos or further data analysis (e.g. averages, ratios) derived from the metrics Page 9 of 39

10 SECTION B: JICWEBS REPORTING STANDARDS certified may be included on the certificate at the site s discretion and with the agreement of the auditor. B3.4.1 Reporting App Traffic Members may choose to report App Traffic at their option. If App Traffic is certified then the following must also be reported: Any Domain(s), URLs or content identifiers used by the App(s) if they form 5% or more of the total traffic. The name and version number of the App(s) certified. Optionally whether the certified App(s) and/or its content is paid or free at the time of audit. B3.4.2 Syndicated Content Syndicated content can be included in the certified inventory subject to clause B3.4.2 below, since a caveat emptor statement is included on all certificates. This statement is worded as follows: Syndicated content may or may not be included in the traffic certified. B3.4.3 Syndicated Content Framework However, it is not meaningful for a media owner to put a logo into someone else s site and count the requests for it, so inflating certified figures since there is no opportunity to see site content presented on the syndicated page. Syndicated content can be counted towards a media owner s audited web inventory if the following questions can all be answered: The user can have an opportunity to see, and interact with, self-contained content presenting information; The content makes sense (to a reasonable user, such as an auditor) in and of itself; The content is not simply a logo, search box or similar. It is always up to the media owner to make the case that their syndicated content meets the above three requirements. B3.5 Breakouts of Inventory Where a subset of inventory is broken out from the overall audited totals and declared as pertaining either to a specific site area (a domain or set of domains) or a specific vertical section, all such inventory MUST either: be of the selected domain(s) or have relevance (typically associated editorial or listings content) to that vertical section. B3.6 Breakouts of Page Impression Types If Page Impressions are certified, specific types of Page Impression must be broken out (stated separately) on the certificate. These are as follows: Automated Page Impressions if they form 5% or more of the overall Page Impression count. B3.7 Averages PDF Impressions (if they are not certified separately as Downloads) if they form 5% or more of the overall Page Impression count. The metric averages shown on the certificate are the sum of all daily totals for a given metric over a given period, divided by the number of days in that period. B3.8 Account Metrics Any User Account or Subscriber Account metrics stated on a web traffic certificate for a defined period of activity must have the Active number for that period stated (e.g. Active Paid Subscriber Accounts for March 2011) and may optionally state additional non-active parent metrics (e.g. Subscriber Accounts) provided an Active number is stated. Subscriber Accounts have a maximum term of expiry of three years. B3.9 Certificate Release and Layout At least the following information must appear on all web certificates released into the public domain: Property Name and URL; Property Inventory Domains/URLs, or Property Inventory Domain if one only (see Appendix 2, Definitions); The period covered by the certificate; A description of the content of the property - the Media Owner s Statement; If the property is declaring that it operates a registration policy, a breakdown of Page Impressions generated by registered and nonregistered traffic; Contact details for the Media Owner; The average daily Unique Browsers and daily Unique Browsers by day for the Certification Period; Definitions of all metrics cited in Section 3 of the certificate and any from which they may derive, to assist users of the certificate; The Counting (web analytics) system used; A caveat that the traffic certified may or may not have been in focus where in focus means the content in the browser window that is uppermost (typically the foreground tab). A statement of auditor s opinion. B4 AV METRICS - IPTV (BMWG) The BMWG (Broadband Measurement Working Group), a committee comprising UK TV broadcasters, has agreed two methodologies a simulcast methodology and a rights metric (Unique Play Percentage) - for online media consumption. B4.1 Measuring Simulcast This document sets out the methodology for preparing the graphs which illustrate the key rights metric agreed by the BMWG for Stage 1 of their work simulcast streaming of AV content. The graphs show the number of Page 10 of 39

11 SECTION B: JICWEBS REPORTING STANDARDS simultaneous stream connections active during every minute of a particular period as in the example shown :00 AM 2:00 AM 4:00 AM ITV-1 Streams Connected, 1st July :00 AM 8:00 AM 10:00 AM 12:00 PM 2:00 PM It is anticipated that for continuous reporting of simulcast channels, one graph (with the underlying table of data) per channel, per day is produced. However, for particular one-off events, the schedule provided by the broadcaster in other words, the length of time over which the event is broadcast defines the extent of the graph. 4:00 PM 6:00 PM 8:00 PM 10:00 PM The data provided must contain the following fields: The URL of the simulcast stream IP address of the Internet application (browser or media player) requesting the stream Identifier (User-Agent) of the browser or media player requesting the stream An indicator of date and time A way in which Duration (in seconds) can be derived An HTTP-standard status code (e.g. 200, 404, 501) denoting success or failure of the stream request Once the start time and end time of each stream has been calculated, these times must be expressed as absolute seconds values either Unix (epoch) seconds or seconds since the start of the month. In both cases, clearly, the date must be taken into account. This is to cater for differences in log format as noted above and to ensure that the graph can be prepared in a standard manner. For clarity, these values will be called StartSecs and EndSecs below. Filtering The filtering process should now remove: all requests from invalid IP addresses (e.g. those internal to the broadcaster); all requests from invalid (robotic) User-Agents; all requests for other simulcast channels (or content items, if looking at an individual content item) present in the log; all requests with invalid status codes (so not ); all requests which do not EITHER: o o have an EndSecs value greater than the absolute seconds value of the first second of the period (typically 00:00:00 on any given day) for which the graph is being produced so ended within the period, OR have a StartSecs value less than the absolute seconds value of the last second of the period (typically 23:59:59 on any given day) for which the graph is being produced so started within the period. Following these steps will produce a filtered data set from which the graph can be prepared. Graph Preparation There are (24 x 60 x 60) seconds in every day. Any logged line of data for which StartSecs is less than a given second and EndSecs is greater counts towards the simultaneous connections for that second. For example, a stream that starts on second and ends on second 00061, and a stream that starts on second and ends on second 03201, both count towards the total streams connected in second 60. Consequently a table will be created which has, as a minimum, rows (one per second) each showing the total streams connected in that second. This table must then be filtered to show only absolute seconds values within the day or period being measured. A graph can now be compiled of concurrent connections (y-axis) against seconds (x-axis). To get a minute-byminute graph, simply extract every 60 th record. Analysis and comparison of data produced shows that this continues to give a representative picture of the activity being graphed. B4.2 Measuring VOD Engagement This metric is derived from the number of times a piece of content is played during the period, and covers only content played online through the Broadcaster s own environment (e.g. iplayer, ITV Player) and not via other players or encoding mechanisms (e.g. YouTube). The measurement tool must be embedded in the media player and must be able to report each play of a content item, together with its start time and total duration in other words, the point at which the play started, and how long the item was playing for. Therefore the total number of plays can easily be counted. The measurement tool must also be able to count Unique Browsers in compliance with the JICWEBS industryagreed reporting standard. Once these numbers are obtained, the following key metrics (defined in X1.4 below) can be determined for any content item over a given period: Total AV Play Duration Unique AV Play Duration Total Play Duration per AV Unique Browser This is a derived average. Unique AV Play Percentage This methodology is consistent with the current industryagreed AV Play metrics since it is based on AV Play Events and Unique Browsers. There are additional requirements for the BMWG, notably identification of individual content items and need to capture the end of the play. However, the base on which the methodology is built is consistent with the general JICWEBS AV metrics. Page 11 of 39

12 SECTION C: ABC AUDIT REQUIREMENTS This section is intended to provide an overview of the steps undertaken in a typical ABC website audit. It is not intended as an exhaustive manual. C1 INTRODUCTION All audits are conducted following this general plan, but individual web sites may require specific modifications or enhancements to the audit plan. The website audit is intended to certify that the reported statistics submitted by the media owner comply with the JICWEBS Reporting Standards for website traffic measurement (Section B and the metric definitions in Appendix 1). While every effort is made to ensure that all traffic certified is valid and fairly stated, ABC expressly does not audit for fraud or negligence. An audit trail must be established for all the metrics claimed by the client back to the original log(s) generated by the data collection server(s). Please note that site below should be understood to mean site or network and that all documents mentioned below are available electronically. Please check the Technical Area of the ABC website ( or contact your Account Manager. C1.1 Guiding Principles of Audit Adherence to the following requirements is necessary to meet the basic objectives of independent, impartial thirdparty auditing. The following principles underpin all audits that ABC undertakes. Ethical and quality principles Quality and objectivity controls Confidentiality Audit testing standards principles Independence of sampling process Ability to carry out testing Standardised results framework The ABC audit programme seeks to test businesses compliance with the JICWEBS reporting standards in accordance with these key principles, and ABC will apply them to all audits it undertakes. C2 OVERVIEW OF THE AUDIT PROCESS C2.1 Initial Registration (New Sites Only) The media owner: registers with ABC; completes a registration form; pays a one-off registration fee; and agrees to pay the annual ABC Website Certification subscription. The assigned Account Manager: contacts the media owner to arrange any necessary pre-audit consultancy. C2.2 Pre-Audit Preparatory Work (New Sites Only) After registration, the media owner may, if required, go through a pre-audit meeting. This meeting is designed to explain the audit processes, and provide ABC with a general understanding of the media owner s business delivery processes. It will also help the audit team develop the specific audit plan. The media owner s sales and marketing teams, as well as the technical management, should be involved to make sure that the audit proceeds as smoothly as possible and that the resultant certificate reflects both the needs of the business in the market place and the industry-agreed standards. ABC will need to confirm arrangements for access to data and technical staff. C2.3 The Audit ABC s audit seeks to establish that all statistics claimed by the media owner are supported by underlying data. Before the Certification Period, the media owner: commits in writing to an agreed Certification Period by completing, signing and returning a Confirmation of Audit form, agreeing the audit scope of work outlined therein so that both parties are aware of each other's responsibilities. Upon receipt, ABC will raise an invoice to cover the minimum fee for the audit, based on the scope of work agreed. takes steps to archive all supporting logged data for the audit period, which will be made available to ABC upon request. The Confirmation of Audit, Audit Filtering Rules Statement and certificate copy should be sent electronically to [email protected] with all appropriate signatures. Immediately after the Certification Period, the media owner: notifies ABC of the filtering rules that should be applied to the site s traffic in the Audit Filtering Rules Statement. If the site uses cookies to identify Users, the media owner should also describe its cookie regime on that form and confirm that ABC may verify the regime's consistency and persistence by regular tests and sampling. makes a claim for the metric totals it wishes ABC to verify. These totals are established by the client or by a third party employed by the client, e.g. an ABC Associate. The results of the filtering (counting) process should be provided to ABC electronically (usually in spreadsheet form). C3 FILTERING C3.1 Why Filtering is Necessary Page 12 of 39

13 SECTION C: ABC AUDIT REQUIREMENTS In order for ABC to audit site traffic, the media owner must ensure that compliant log files containing only data records deemed to be of valid traffic can be created by filtering the raw log files for the certification period. Raw data tag log or web server log file(s) Industry Filter Rules Compliant log file(s) Daily claim per metric If the media owner wishes to supply unfiltered data, then additional charges for processing may be applied at ABC s discretion depending on the scope and scale of the task. All the required fields listed in Section B1.1 must be included in the log data to be audited. The site must make available any or all of the raw log file data from which the statistics have been derived, and must provide technical assistance to the audit team when they seek to confirm counts and examine the underlying raw log file data. If Page Impressions are being certified, the number of records in a day's compliant log file data should equal the number of Page Impressions claimed by the site for that day. C3.2 ABC Filtering Guidance The following graphic sums up the basic filtering methodology: Note that additional steps such as removal of invalid HTTP Method and/or Status codes may be needed depending on the type of data captured. C3.2.1 Default Exclusion of Filetypes In our experience, the following file types, usually bearing textual content, are likely to be served in response to valid requests from valid users. Any URL terminating in a slash or with no file suffix (e.g. ).htm.html.stm.shtml.shtm.h4.asp.aspx.cfm.cgi.jsp.mspx.php.php3.php4.do Conversely, we consider files of the following types to be invalid, and require their exclusion from claimed figures unless the site can prove, in an auditable manner, that these are the only files served in response to the user s request. Graphics:.art.bin.bmp.cdf.cgm.cls.con.emf.fpx.gif.hqx.ief.iff.image.jfif.jpe.jpeg.jpg.lwf.pbm.pgm.pct.pic.pict.png.rgb.tga.tif.tiff.wbmp.xbm.xpm.xwd Formatting and Page Information:.css.ico.inc.xsl On-Page Scripting:.beans.class.dll.java.js We will exclude every filetype listed here as a matter of course unless the site explicitly tells us to include it, and gives valid reasons why. Files not on this list may also be deemed invalid at our discretion especially if they are sound and media files such as.aiff,.mov or.ram which the site does not count as AV Plays. Note also that Flash Player/Shockwave Flash sequences (.swf) may represent the entire content of a particular page, and in such cases represent valid traffic. If certifying Page Impressions, the client must indicate to ABC any pages holding graphical content only in order to include traffic to such pages in the audit. Furthermore, we recommend that URLs intended to be visited by web feed aggregators only typically with the filetypes.rss,.rdf or.xml be excluded from counts. C3.2.2 Exclusion of Robotic User-Agents To aid in the exclusion process, the ABC/IAB Global Spider and Robot List contains a list of those robots found to be material in audits. It is updated monthly, and is available from the members Area on the ABC website This list is subject to alteration without notice, and the date of alteration will be shown. The list to be used in a given month is generally published by the 25th of the previous month. ABC always makes the latest list available within the members Area as robots_current.txt. The site should apply the list by matching case insensitive strings anywhere in the User-Agent field in the logged data. A simple match of the start of the string is not adequate. The site must ensure that the User-Agent field is logged. Sites may wish to ensure rigour in robot exclusion by adopting the dual-pass approach recommended by the IAB. The first stage includes only records matching the User-Agents on the Include list only; the second then excludes records from the remaining data based on matching the robotic User-Agents in the separate Exclude List. C3.2.3 Additional Exclusions ABC reserves the right to exclude site traffic for other reasons than stated in Section B2 if we consider such Page 13 of 39

14 SECTION C: ABC AUDIT REQUIREMENTS exclusions to meet the overall principles, logic, purpose or spirit of the Audit. ABC will at all times keep you informed of the reasons for such exclusions. C3.2.4 Derivation of Breakouts ABC must be provided with all rules that a client has used for determining the relevance or otherwise of the inventory that the media owner has given a stated purpose (e.g. jobs breakout ), and will in the course of its audit check samples from the set of URLs provided to ensure that they meet this over-arching principle of relevance. For the avoidance of doubt, search boxes do NOT in themselves constitute such content. For example, a jobs breakout could have the following rules for inclusion of pages: Any of the strings "job","cv","career" or "recruit" exist in the Domain or URL (e.g. Other pages containing detailed job listings (at least a job title and one other parameter such as location or salary) or jobs/career related editorial. C3.2.5 Claiming Paid Subscriber Accounts Media owners may claim unpaid subscriptions or renewals of current orders as Paid Subscriber Accounts as long as they consider them to be live, good and collectable. Note: As a guide Media Owners should only claim copies if they fall within their normal credit or grace periods; Media Owners must report to ABC any subscriptions which remain unpaid 3 months after the start of a subscription period that are included in their claim. C3.3 Audit Completion When an audit has been completed, ABC may communicate specific audit findings of concern or hold an exit meeting with the client to discuss issues arising from the audit and possible improvement areas for future audits. C4 DATA STORAGE, SUPPLY AND DELIVERY C4.1 Data Storage The media owner must: make available any or all of the raw log file data from which the statistics have been derived provide technical assistance to the audit team when they seek to confirm counts and examine the underlying raw log file data communicate these requirements to any third party managing the data flows on behalf of the media owner. We advise sites to do this well in advance. We suggest that all raw data is retained indefinitely. As a minimum, the raw data should be retained for one year or until a further audit has been successfully completed and certified, whichever is the longer. C4.2 Data Supply and Delivery ABC will always request Filtering Rules from the media owner. Where the data submitted for audit contains fewer than 20 million records for the whole month, ABC will typically request the entire month s data. In other cases ABC will typically request 3 sample days and a BrowserID+Date file. Media owners choosing to have continuous certification must submit monthly claims for all metrics to be certified, including any whole weeks that can be reported on, together with supporting data, within 5 working days following the month claimed. For those media owners wishing to be included in a Concurrent Release, this deadline is critical - otherwise inclusion cannot be assured. C4.2.1 Why a BrowserID+Date file? When conducting an audit of Monthly or Weekly Unique Browsers based on samples, the work done on the sampled days provides no arithmetical basis for gaining confidence in the claimed monthly Unique Browsers total. The site should substantiate this total by making available a file containing every unique combination of User identifier and Date present in the filtered data and claimed as a Unique Browser. The number of different User identifiers in the BrowserID+Date file should hence be certifiable as the total Unique Browsers for the month. When separate breakouts are required for different (combinations of) domains, ABC requires a BrowserID+Date+Domain file in order to be able to certify the figure of Total Unique Browsers for each broken-out domain. In other words, the BrowserID+Date file requires the additional Domain field. C4.2.2 Methods of Data Delivery ABC maintains both an FTP site, ftp.abc.org.uk, and an SFTP site. ABC can allocate media owners passwordprotected accounts upon request. Other alternative options are: supplying the data on appropriately secured and delivered CD or DVD media supplying the data on an external hard drive. C5 CERTIFICATION AND PUBLICITY C5.1 Certificate Issue and Release At the end of the Audit Period, ABC will confirm any metric totals that are certifiable, and the site confirms the statistics it wants to appear on the certificate. The client should, by this point, have supplied a content description of words to be incorporated into the certificate. Upon receipt of all relevant certificate content information, ABC will produce a draft certificate for approval by the client (see section B3.8 for more information). When the Page 14 of 39

15 SECTION C: ABC AUDIT REQUIREMENTS client has approved this, ABC will issue the final certificate. ALL ABC services are carried out in confidence. No information is therefore made public unless the member instructs ABC to do so. C5.1.1 Declaration of Inventory The certificate will define the perimeter of the inventory certified by stating material domains (e.g. and sub-domains (e.g. These must cover at least 95% of the inventory certified (by Page Impressions) but may cover more at the media owner s request. In the interests of transparency, certificates may be required to state the domains into which any syndicated content has been served. C5.1.2 Media Owner Statement The media owner statement for the certificate should be no more than 150 words long. The statement should help the certificate reader understand the purpose of the site. Statements must be restricted to a reasonable description of the site itself and must not include other information or claims unsubstantiated by the audit. The following types of claim must not be made within the statement: Claims that use numbers or percentages not appearing elsewhere on the certificate, e.g. 70% of users are male ; Quotes; Comparative claims in relation to the market or other websites (e.g. The No. 1 website ). The accuracy of media owner statements is not audited. However, ABC will review the statements to ensure they are reasonable and meet the above requirements. ABC s decision is final. C5.1.3 Media Owner s Logo The media owner s logo can be added to certificates. However, ABC reserves the right to prohibit or amend a logo if it includes any statements or claims prohibited by C5.1.2 above (e.g. a strapline saying The UK s No. 1 [something] website ). The logo must be provided at a resolution of at least 300 dpi, and must be in either JPEG or TIFF format. C5.2 Publicity and use of ABC Logo Media owners may choose to make some or all of any certified information public. However, where the media owner chooses to limit what they make public, this must include at least the total certified for the mandatory minimum metric. In the case of websites, this is the Average Daily Unique Browsers, and Daily Unique Browsers by day for the Audit Period. Media owners can only disseminate information from an ABC certificate, or the certificate itself, into the public domain after the certificate has been made public by ABC. ABC will post a copy of such public-domain certificates to C5.2.1 Quoting and Sourcing Figures and using the ABC Logo The ABC Publicity Byelaws specify how members may promote data, their ABC membership and use the ABC Logo. The ABC Byelaws are published on the ABC website. C6 COMPLAINTS C6.1 Publicity If a member believes another member has infringed the ABC Publicity Byelaws they may submit a complaint under the ABC Complaints Procedure, detailed in the ABC Byelaws. The ABC Byelaws are published on the ABC website. C6.2 Appeals against an ABC decision If a member believes a decision made by ABC has not been made in accordance with the ABC/other relevant Reporting Standards they may submit an appeal under the ABC Review Procedure, detailed in the ABC Byelaws. The ABC Byelaws are published on the ABC website.. C5.1.4 Calculating Average Visit Duration The period across which the Visit Duration is calculated will be stated on certificates. For example, Visit Duration (Monthly Average) is calculated as the sum of the total time in seconds for all Visits of two or more Page Impressions in month, divided by the sum of the multipage Visits in that month. Hence, the stated Monthly Average Visit Duration is NOT the average of the Daily Average Visit Durations but a simple average of (Total Time in Seconds in Month) (Multi-Page Visits in Month). Page 15 of 39

16 SECTION D: ABC TECHNICAL GUIDANCE This section deals with the application of specific areas of the industry rules, and with technical considerations which may affect audits generally. D1 INTRODUCTION Any client technical staff involved in preparing for an audit should read the parts of this section which apply to the metrics they wish to claim, as well as the general technical remarks. D2 GENERAL ISSUES D2.1 Proxies and Caching The caching of your website content by third parties such as ISPs or search engines can have an adverse impact on what requests are logged by your web servers, and hence (if using web server logs) what is certified as your traffic. It is, however, possible to prevent the caching of your site content by time-expiring elements of it. There will be a consequent increase in the load on your server(s). D2.2 Page Tagging One method of reducing the impact of caching upon your traffic analysis is to insert tags into the source code of each page. When rendered by a Web browser, these tags cause calls to an external data log to be made. Logs containing information written by page tag code are auditable provided they conform to the JICWEBS minimum logging standards set out in section B1. Note that tagging methods reduce, but do not completely eliminate, robotic activity; sites who use tags are still required to comply with all industry rules regarding exclusion of invalid data such as robots, IP addresses and URLs. In particular, since the HTTP Status code is not usually reported by tags, sites must ensure that any invalid pages such as redirect pages, admin pages or errors are not counted as valid Page Impressions. Audits based on tagging require us to substantiate the integrity of the tagging method and of the data collected, and take appropriate steps to authenticate this data. Hence, additional meetings and consultancy with our Technical Department may be required. Where the tag is an ABC-accredited 2-star Associate product, this additional consultancy process should not be necessary; however, media owners must still ensure that the product is configured correctly. Only if the media owner implements the tagging solution fully and properly will we be able to certify the site s traffic. Media owners must also make clear to ABC the product name and version number (not just the provider) of the page tag solution they are using for the intended audit. It is the media owner s responsibility to notify the web analytics solution provider that all appropriate audit data must be captured, stored and made available to ABC prior to the Certification Period. Note that the solution provider may charge the media owner for this service. D2.3 Comparing Server-Side and Browser-Side Measurement Server-side measurement counts records of the requests that have been fulfilled by your website's content servers; browser-side measurement counts records of the requests that have been fulfilled by your website s page tag servers. Server-side measurement can be affected by the caching of website content by a user s own machine or by third parties such as ISPs, corporate proxies or search engines, so that not all requests from valid browsers reach a site's servers. Browser-side measurement ("page tagging"), used by most commercial analytics tools (e.g. Omniture SiteCatalyst, WebTrends On Demand, NedStat SiteStat, Google Analytics) counts a Page Impression only when the page tag code embedded in a webpage has been rendered in a browser and has caused a successful delivery (typically of a 1x1 invisible gif) by a tag server. If page tag code is not embedded in a webpage, no count will result. Since the JICWEBS reporting standard requires that to be counted a Unique Browser must have made a valid Page Impression, any Page Impression differences may affect the Unique Browser counts. The JICWEBS reporting standards specify what must be excluded from counts but not the data source from which the count is taken, in order to deliver open standards to the market. Browser-side measurement requires the implementation of specific technology, while server-side measurement does not. Hence, the point of measurement needs to be taken into account when looking at differences in reported totals for site traffic measured using these different data sources. D3 UNIQUE BROWSERS D3.1 What is a Unique Browser? A Unique Browser is defined as The total number of unique combinations of a valid identifier. Sites may use IP+User-Agent and/or Cookie (and/or any other agreed valid identifier). Hence, the minimum acceptable Unique Browser definition is IP address+user-agent, e.g Mozilla/4.0; (compatible) MSIE 5.5 Unique Browsers are the unique device configurations that made the page requests, and the JICWEBS reporting standards allow the use of alternate device identifiers e.g. first-party cookie, third-party cookie, IP+User-Agent, or combinations of the above. As stated in the JICWEBS definition of the metric, "[Unique Browsers] may overstate or understate the real number of individual devices concerned due to factors such as dynamic IP address allocation, significant levels of uniformity in IP and browser configurations operating through a proxy, cookie blocking and cookie deletion." Most commercial web analytic products use some form of cookie-based measurement; companies using content server logs only may only be able to count using IP+User-Agent as cookies require separate implementation. Page 16 of 39

17 SECTION D: ABC TECHNICAL GUIDANCE D3.2 Unique Browsers from Pushed Traffic If the site wishes to measure pushed traffic (subsiting or contextual linking), then technical staff must be aware that such traffic is invalid with regard to ALL the industrystandard metrics. Therefore, it is incumbent upon the site to filter this traffic out and hence make it easily identifiable. The ABC audit sets out to detect undeclared pushed traffic; if material pushed traffic is found, then the claimed metric totals will not be certified. ABC suggests that a set of naming conventions should be used for any pushed URLs such that they can easily be excluded from the log files or differentiated from non pushed requests for the same URL. The recommended approach is therefore very similar to that used for identification of automated traffic when certifying Page Impressions (see D4.2 below). If the log files cannot adequately distinguish between pushed and non-pushed requests for a particular URL (i.e. a specific naming convention was not used), then the auditor will have to assume the worst case scenario and exclude all requests for the URL in question. D3.3 User-Agent Considerations D3.3.1 Mixed Logging Where the site to be audited wishes to use IP+User-Agent as a user identifier, the site MUST ensure that the User- Agent is the same format throughout. Microsoft IIS products substitute a plus for the normal space in any User-Agent (e.g. "Mozilla/4.0;+(compatible)+ " rather than "Mozilla/4.0; (compatible) ". Hence, sites with mixed logs containing IIS and other data MUST take steps either to record User-Agent strings UNIFORMLY in the compliant logs or to normalise them prior to processing. Otherwise, the user claim will be wrong. D3.3.2 Media Player User-Agent Identifiers Where the site to be audited includes any media files, the user will typically open them using media player software, whether or not this is embedded in the browser. Much of this software appends its own sub-string to the User- Agent value. Hence, when counting Unique Browsers using IP+User-Agent, all such media player User-Agents must be discounted. The material majority of such User- Agents can be identified by the following strings within the User-Agent: play32 plus32 mplayer nsplayer D3.4 BrowserID+Date File realplayer realproxy wmfsdk realoneplayer If we carry out an audit on a sample basis, we can certify daily figures for Unique Browsers, Page Impressions (and Visits etc.) simply by carrying out our audit tests on the compliant logs for the requested sample days. However, since there is an aggregation and deduplication process involved in certifying weekly and monthly Unique Browsers, daily totals do not tell us anything about the weekly or monthly numbers. Hence the need for the BrowserID and Date file (BDF) if the media owner wishes to certify Weekly or Monthly Unique Browsers. This file contains all unique combinations of Date and the fields used to generate the BrowserID (typically Cookie and/or IP+User-Agent) found in the filtered records. It gives us a very efficient and very sound audit proof of the weekly or monthly Unique Browsers figure. The number of different identifiers in the BDF is hence proved to be certifiable as the weekly or monthly Unique Browser total. When the client requires separate breakouts of Unique Browsers depending on domain, the Domain field should also be present in the BDF in other words, it should contain all unique combinations of Date, BrowserID and Domain. ABC recommends separation of all fields in this file by a delimiter, ideally tab (Field1>> Field2) or else comma with quotes ( Field1, Field2 ). Effectively, this file is a record of all distinct combinations of BrowserID and Date (and Domain if applicable). Fig. D-1 Typical BrowserID+Date+Domain file (Cookie) This is an example of a BrowserID+Date+Domain file where Cookie Only is being used as the Unique Browser identifier and the regime is Compliant (see D3.5.1). Date Domain Cookie AAABBB AAABBC ie.mysite.com AAABBC uk.mysite.com Ie.mysite.com AAABBC uk.mysite.com AAABDD uk.mysite.com AAABDE ie.mysite.com AAABDE etc Please Note: Where you wish to use alternative identifiers to gain additional Unique Browsers, e.g. Cookie + Unmatched or Singleton Cookie, the BrowserID+Date file MUST contain all identifiers for all Unique Browsers. In this example, the BrowserID+Date file would have to contain the IP+User-Agent combination of all cookied Unique Browsers. D3.4.1 Alternative to the BrowserID+Date File Instead of carrying out the extra processing required to generate a BDF, sites may wish to supply the total filtered data for the month. If there are more than 20 million such records, this option may be subject to additional charges and will require agreement with ABC. D3.5 Cookies If you wish to count Unique Browsers, in whole or in part, by Cookie, your cookie regime must satisfy the conditions below: 1. Persistence Page 17 of 39

18 SECTION D: ABC TECHNICAL GUIDANCE Cookies must be persistent, permanent cookies (not temporary, session cookies). Furthermore, cookie expiry dates must be set distant. Where the cookie has a fixed expiry date, cookies should always be configured such that the expiry is a minimum of 1 year since last accessed (the absolute minimum is 1 day longer than the required audit period) or (if this is not practical) should expire at least 25 months after the cookie is set. 2. Consistency The same cookie regime must apply across the entire site, across ALL domains of the traffic being audited with the same cookie recognised throughout on the same basis. The cookie cannot be a first-party cookie in some parts of the site and a third-party cookie elsewhere. Note, however, that clients gathering data across multiple sets of log files for a network of sites (e.g. main site 1, main site 2, mobile site, sponsored microsite) may still wish to use a single Cookie as a Unique Browser identifier. This is possible with the following provisos: only one such cookie is used; the cookie used is consistent and persistent within all domains to be certified; the cookie is used as the primary identifier of Unique Browsers; all additional identifiers used (typically IP+User- Agent) must be unmatched. In other words, any additional identifier seen with a valid Cookie can never be counted elsewhere. Figures D-2, D-3 and D-4 below should enable you to identify which type of cookie regime you have out of the multiple variants possible. Fig. D-2 Identifying your Cookie Regime Find out from the following table what your cookie regime is classed as. Figure D-2 will show how you may count Unique Browsers and what defaults you may apply to cookie-rejecting or non-cookied Unique Browsers. The Netscape cookie protocol and RFCs 2109 and 2965 explain request header and response header. Some cases outlined above (especially Singleton+Test, where trusted cookies persist from one month to the next) illustrate circumstances which cannot be proven by auditing data for a single month here, additional audit tests may be required. What cookie value do you log? Outgoing cookies (from a server; HTTP Set- Cookie: response header) Incoming cookies (from the browser s HTTP Cookie: request header) What additional tests are done to check cookie integrity or acceptance? None Redirect to check whether cookie sent the first time is logged again Cookie given special non-trusted marker until it is logged again None (first request for a file from a new virgin browser has no cookie) Redirect to check whether the browser accepts cookies Cookie sent to a new virgin browser is logged as a query parameter and treated as the cookie if present. Your regime is of the following type: SINGLETON SINGLETON + REDIRECT SINGLETON + TEST COMPLIANT COMPLIANT + REDIRECT COMPLIANT (NO VIRGINS) Fig. D-3 Acceptable Defaults For Rejected Cookies Regime Is: 1. SINGLETON 2. SINGLETON + REDIRECT 3. SINGLETON + TEST 4. COMPLIANT 5. COMPLIANT + REDIRECT 6. COMPLIANT NO VIRGINS Acceptable BrowserID defaults: IP+USER-AGENT for cookies which made one Page Impression ONLY in the period; any record with a null Cookie field cannot identify Unique Browsers. IP+USER-AGENT for all Page Impressions which show rejected cookies; any record with a null Cookie field cannot identify Unique Browsers. IP+USER-AGENT for all Page Impressions with non-trusted cookies; any record with a null Cookie field cannot identify Unique Browsers. IP+USER-AGENT UNMATCHED in the period for all Page Impressions with a null Cookie field. IP+USER-AGENT for all Page Impressions with a null Cookie field. IP+USER-AGENT for all Page Impressions with a null Cookie field. Notes to Figure D-3: a. Unmatched IP+User-Agents are those which were NEVER seen with a cookie in the period being audited. b. The period for defaulting to additional identifiers is: a month for Monthly Unique Browsers, a week for Weekly Unique Browsers, and a day for daily Unique Browsers. Page 18 of 39

19 SECTION D: ABC TECHNICAL GUIDANCE c. You may claim additional Unique Browsers by a process of ascription if (and only if): your cookie regime is a Compliant type your audit data is gathered from the browser side (e.g. via a page tagging solution), and a material majority of the Page Impressions in your compliant data have a valid cookie. To apply the ascription approach, count the number of Page Impressions which carry a cookie and the number of unique cookies present in these Page Impressions. This allows you to establish the ratio of Page Impressions per cookied Unique Browser. Applying this ratio to the number of Page Impressions whose cookie is null gives an industry-acceptable estimate of the Unique Browsers that created such Page Impressions. This method can also be applied to Visits with the above provisos. D3.5.1 Counting Cookies D Singletons Unique singleton cookies (cookies only ever present in one record in the audit period) are NOT automatically deemed invalid for the identification of Unique Browsers. However, sites must be able to demonstrate, in an auditable manner, appropriate interpretation. This must be agreed in advance with ABC as part of the audit plan and may require auditing of Unique Browsers at a Page Impression level. D BrowserID+Date File Requirements If the cookie logged is that sent by the server (part of the Set-Cookie: header) regardless of whether or not the browser has accepted it, and the site wishes to certify a monthly Unique Browser figure, the site must send ABC a list of the potential Unique Browser identifiers (Date, Cookie, and additionally IP+User-Agent if used as a default) present in each Page Impression made during the audit period (as per BrowserID+Date file requirements). If the cookie logged is that set by the browser (part of the Cookie: header) and the site wishes to certify a weekly or monthly Unique Browser figure, then the site need only send the BrowserID+Date file i.e. an appended list of all unique cookies (and any additional identifiers used to calculate non-cookied Unique Browsers) found per day in the Audit Period. The industry-agreed standards require cookies to be persistent, and P3P non-compliance may lead to overcounting of Unique Browsers. D3.5.3 Interactive TV Cookies Sites may have material amounts of Interactive TV Impressions because they have a sizable audience using Interactive TV devices ( set-top boxes ). Any such site choosing to use Cookie as a Unique Browser identifier should be aware that most current set-top boxes lose their cookies whenever completely powered off (as opposed to being put on standby). This may lead to these cookies becoming non-persistent, and hence to material overstatement of totals. Therefore, ABC may need to investigate the behaviour of such cookies, and apply adjustments to claimed Unique Browser figures if necessary. D3.6 Automated Content (Web Feed and Podcast) If a site wishes to measure Unique Web Feed Browsers or Podcast Subscribers, then the web feed traffic or podcast notifications must be broken out into a separate inventory, and the Cookies within this inventory counted appropriately (following the rules in D3.5) to provide the claimed metric totals. Note that as stated under Web Feed Aggregators, this traffic is NOT considered valid for Page Impression measurement. The Cookies used for measurement must comply with all the standard rules on persistence, consistency and distant expiry. D3.7 Compound Unique Browser Identifiers If it is wished to use Registration ID within a compound measurement of Unique Browsers (e.g. attributing multiple Cookies or IP+User-Agents to the same Registration ID), then the media owner should be aware that this will produce a lower number than could be certified. D3.5.2 First v Third-Party Cookies Some browsers are set to reject third-party cookies by default. Hence, ABC recommends that wherever possible any cookie used to identify a Unique Browser should be first-party in other words, sent from the same domain. Furthermore, some Web browsers may not accept any cookie from a domain that does not have a compliant Compact Privacy Policy (P3P). More dangerously, they may turn such a cookie into a temporary "session" one. Third parties must be even more careful when serving cookies to browsers visiting a site. Page 19 of 39

20 Fig D-4 Example of Various Cookie Behaviours This table shows what happens to the Cookie when four Page Impressions are made under each of the Regime Types described in Figure D-3. The variables to consider are: What is the cookie regime? Does the browser accept or reject cookies? What is in the cookie folder prior to the browser s first Page Impression? How many Page Impressions have been made? One only, or a series (here 4)? ABC Web Audit Rules and Guidance Notes 2013 Version 2 SECTION D: ABC TECHNICAL GUIDANCE Page 20 of 39

21 SECTION D: ABC TECHNICAL GUIDANCE D4 PAGE IMPRESSIONS D4.1 Breakout of Page Impression Subtypes There are a number of Page Impression subtypes which, regardless of whether they are separately stated on the certificate, can form part of the overall Page Impression total. In all such cases, the simplest way of identifying special pages is to use a filter based on the URL name, directory, or special query parameter. Other approaches may be possible upon discussion with ABC. Where Automated Page Impressions form 5% or more of the Page Impression count, these must be separately stated on the certificate. Alternatively, media owners may remove any such Page Impression subtype totals from the overall Page Impression claim. Other Page Impression subtypes may be stated at the site s discretion regardless of their percentage of total Page Impressions certified. Consider a site with 3,000,000 Page Impressions. This site has 750,000 Automated Page Impressions, 30,000 Mobile Format Impressions and 20,000 PDF Impressions, as shown in Figure D-5. Fig. D-5 Example Site with Page Impression Subtypes 3,000,000 Page Impressions and so identifiable. With this approach, the counting solution used can easily find any refresh by matching the chosen marker in the URI, and thus break out automated traffic. If this URI were updated every 5 seconds, the following log file entries would appear in an Apache ELF-type log: [27/Oct/2009:17:22: ] "GET /Test/thispage.html HTTP/1.0" "-" "Mozilla/3.75 [en] (WinNT; U)" "-" [27/Oct/2009:17:22: ] "GET /Test/ thispage.html?refresh=1 HTTP/1.0" "-" "Mozilla/3.75 [en] (WinNT; U)" "-" [27/Oct/2009:17:22: ] "GET /Test/ thispage.html?refresh=1 HTTP/1.0" "-" "Mozilla/3.75 [en] (WinNT; U)" "-" D4.3 Identifying Interactive TV Traffic Interactive TV traffic (Interactive TV Impressions) can be broken out from the overall Page Impression total if required. Normally it is possible to identify such traffic from dedicated URL trees such as /tv/ or /interactive/. However, where the directory naming convention is ambiguous, or other files are contained in the Interactive TV directory, the site may choose to use a combination of URL and User-Agent to identify their Interactive TV Impressions. Mobile, 30,000 Automated, 750,000 PDF, 20,000 D4.4 Identifying Page Impressions within Rich Media In June 2008, the Page Impression definition was revised to state that directly attributable user-initiated logged events for content (mouse clicks) can be used to count Page Impressions, whether served in HTML, Ajax, Flash or other environments. This however is open to varying interpretations. ABC therefore offers the following framework of overarching principles for establishing what is, or is not, a valid Page Impression. Standard, 2,200,000 The Page Impression total is still 3,000,000; however, each Page Impression subtype forms separate and specific totals within the overall number. Only the Automated Page Impression total (shown in white in Figure D-5) for this site must be stated on the certificate, since this is over 5% of the total or a claim could be made for 2,250,000 Page Impressions by excluding the Automated Page Impressions. D4.2 Identifying Automated Page Impressions One approved methodology for identification is to construct a refresh for a page (say thispage.html) that gives any refreshed page a specific query parameter (e.g. &refresh=1 ) as follows: <META HTTP-EQUIV="refresh" CONTENT="5; URI=thispage.html?user=fred&refresh=1"> Sites may change the name of the refresh marker ("refresh=1"), as long as the name chosen is consistent D4.4.1 Guidance If a Yes answer can be given to all the following questions within a rich media application, then Page Impressions should be able to be certified: Does site content in the user s browser change as a result of a user s mouse click? Is a certain type of log record only ever logged as a direct result of the mouse click? Can this record be disaggregated from other logged events within the rich media application and from anything which may be concurrently served with it? Would you be able to make a page constructed purely in HTML behave in a similar way? Is the average interval between mouse clicks greater than 5 seconds? Is the event different (distinct)? Page 21 of 39

22 SECTION D: ABC TECHNICAL GUIDANCE D4.4.2 Examples Online magazine built in Flash which turns a page when a user clicks the edge of the page they are on valid as Page Impressions Match scorecard pages built in Flash which update automatically with the latest score valid as Automated Page Impressions Balloon popping game requiring a mouse-click to pop each balloon each pop is NOT a Page Impression. The above guidance and examples provide a simple framework for decision-making. Nevertheless, in case of doubt, media owners should agree what is valid with ABC before the audit period commences otherwise ABC may not be able to certify the claim. D4.5 Identifying Mobile Format Traffic D4.5.1 Mobile Format URLs Mobile Format URLs are those created by the media owner specifically to fulfil requests from mobile devices. These URLs will often have naming conventions such as /mobile/, /pda etc. or be situated in separate domains. D4.5.2 WAP Impressions WAP traffic (WAP Impressions) can be broken out from the overall Page Impression total if required. This should be possible by looking at either the filetype (.wml), or where the filetype is a standard content-bearing one (such as.asp or.xml) at the URL tree. D4.6 Identifying HTML Chat Traffic HTML Chat traffic (see Chat Impression in Appendix 1) can be broken out from the overall Page Impression total if required, typically by URL tree such as /chat/. D4.7 Searches Searches are a subset of Page Impressions, and therefore count towards the certified Page Impression total. A Search is defined as The first Page Impression sent to a valid Unique Browser as a result of that browser s search request being received by the server. The objective is to measure completed search events, where a website serves a results page in response to a user's search request, whether the outcome of that request is positive or not. The two methodologies for measuring Searches below have both been accepted as practicable by the industry. Sites wishing to use alternative methodologies may do so only upon prior agreement with ABC. D4.7.1 Query Parameter This is the simplest approach. The site merely adds a parameter to the search query to denote which page in the particular search has been selected. For example: erts&resultspage=1 erts&resultspage=2 erts&resultspage=3 Only the first of these (resultspage=1) counts as a Search. Note that this may lead to over- or under-statement of the true Search total depending on whether or not the page is cached when the Back button is used; the industry has, however, accepted that this risk is low and therefore that the methodology is acceptable. D4.7.2 Unique Identifier for each Search Event In this approach, each Search is assigned a unique identification number (GUID), and the count of such unique IDs is submitted as the Search claim. Consider a website where a search for doly parton produces a set of results (a first results Page Impression) and generates a GUID, but will also produce the suggestion for a further search Did you mean Dolly Parton? If the user is looking for information on the famous country singer, they will click this second link, and so request another set of results. A second GUID is then generated by the site. Two Searches have therefore been completed, since the user made two distinct submissions of search requests. D5 AUDIO AND VIDEO (AV) CONTENT AV content has distinct characteristics. In many cases, engagement with AV content does not require the user to interact with the HTML pages of the media owner s website; in others, AV content such as video clips of news stories may act as optional enhancements embedded into HTML pages. D5.1 Measuring AV Plays Sites may wish to certify their websites AV inventory, whether live or on demand, as well as their Page Impressions. AV Plays are not Page Impressions, and must be counted separately from this inventory. AV content can start to play automatically when a user loads a page of HTML. Such Automated AV Plays must be broken out where these form more than 5% of the total AV Plays. D5.2 Live and On-Demand AV Plays Live AV Plays are those which follow a true broadcast model in other words, by requesting the file, a user "tunes in" to the available live content. This is in contrast to On-Demand AV Plays, which can be thought of as clips (though their duration may be quite long). JICWEBS endorses the ability of sites to present their streamed content in a manner that reflects current broadcast industry practice, assuming that the fields required to do this have been logged. So, for example, online radio can be measured using the RAJAR framework. RAJAR defines a listener as a user who has been engaged with the content for 5 minutes or more. Other aspects of RAJAR methodology, e.g. average audience per quarter hour, are clearly also valuable to media owners and buyers and therefore can be calculated. ABC can discuss with interested clients ways in which this can be achieved. Page 22 of 39

23 SECTION D: ABC TECHNICAL GUIDANCE Hence, a site might choose to report 100,000 Unique Browsers, of which 70,000 were listeners using the RAJAR definition. Similarly, the BARB approach could be supported for video and broadcast offerings. Certificates reporting the above must carry a warning that audited measurement of AV content is census-based as opposed to panel-based and, as such, should NOT be added to totals derived from panel-based research. D6 VISITS If you wish ABC to certify Visits across multiple domains or servers, you must ensure that this data is all timesynchronised. A true picture of Visits will only emerge if the timestamps of Page Impressions correspond across all logged data. Please note when claiming Visits (and working out Visit Duration) that the effective maximum length of a Visit is assumed to be a day (00:00:00 to 23:59:59), since sites claim traffic figures on a daily basis. Sites that can show in an auditable manner that individual Visits last longer than a day may claim on this basis upon agreement with ABC. An alternative acceptable method of calculating and claiming Visits is to use a permanent (non-session) cookie, distinct from any cookie used to identify Unique Browsers, which expires 30 minutes after the last page is accessed. This should provide comparable figures to the standard methodology. Note, however, that when verifying totals derived using this methodology, ABC will continue to use the traditional method of sorting by Unique Browser identifier and Timestamp. D6.1 Calculating and Claiming Visit Duration Since this is essentially a mathematical calculation, ABC appreciates seeing the working on the Audit Filtering Rules Statement. Please ensure when calculating Visit Duration that you supply us on a daily basis with the number of multi-page Visits (which therefore have an interval) on that day and the total of all intervals in such multi-page Visits. For example, a site might give Visit Duration information for the 7th of August 2007 by declaring seconds total time and multi-page Visits (out of Visits) on the Audit Filtering Rules Statement. This would give an Average Visit Duration for that day of seconds. We can then check the claimed Visit Duration figures from the daily samples supplied to us. D6.2 Measuring Visits and Visit Duration in Rich Media Content Sites based on rich media technology (Flash, AJAX, JSON and similar applications) may wish to measure Unique Browsers, Visits, Visit Duration and Unique Browser Duration from a dataset which includes auditable user-initiated logged events representing interactions between browser and server that are not Page Impressions, such as requests launched asynchronously from within the rich media application or events captured by Javascript. ABC may be able to support this upon confirmation from the site of the events being measured and substantiation through ABC s own tests. D7 REFERRALS IN If you wish ABC to certify Referrals In, you must list on the Audit Filtering Rules Statement ALL referrers which are native in other words, internal to the domain or domains whose traffic is to be certified. Should we find other referrers which appear to be native to your site, we may need to apply adjustment or reiteration to your Referrals In claim. Where the audit is based on passive tagged data, Referrals In cannot be certified. However, if the technology used captures the referrer of the tagged page (active tagging), then Referrals In may be certified. D8 NON-BROWSER TRAFFIC D8.1 Measuring PDA Traffic Where a site wishes to measure the PDA Synchs metric, it must count the pages served to PDA devices by creating a log of PDA traffic. To create this log, the site must filter on the PDA User-Agent list made available from the member s Area on and apply all applicable traffic validity rules for date, HTTP status, method etc. before filtering for robotic activity. Note that these PDA User-Agents are normally counted as robotic, and are therefore part of the ABC/IAB Robots List, available from the Technical Area on used in the filtering process for Page Impressions. PDA traffic should not be included in the headline Page Impression figure, and should only be analysed when the PDA Synch measure is to be audited. D8.2 Measuring Web Feed Aggregators and other Automated Content Syndication Agents Agents for automated content syndication such as RSS readers and aggregators are deemed to be robotic, and are therefore part of the ABC/IAB Robots List used in the filtering process for Page Impressions, since they are automated tools. Web feed traffic is therefore not valid for the counting of Page Impressions. We recommend that URLs intended to be visited by web feed aggregators only typically with the filetypes.rss,.rdf or.xml be excluded from Page Impression counts. Also, it is strongly recommended that all sites serve web feeds with the.rss, not.xml, file type to aid filtering in compliance with the industry-agreed standards. Fig D-6 Web Feed Traffic (In this example RSS is used) Page 23 of 39

24 Conversion Engagement Exposure ABC Web Audit Rules and Guidance Notes 2013 Version 2 SECTION D: ABC TECHNICAL GUIDANCE Any page on which web feeds are displayed (the Website in the above diagram) is valid if requested by a valid browser; such pages can be certified as Page Impressions. D8.3 Measuring Apps A number of Application metrics have now been defined by JICWEBS (see Section X1.8 below for the metric definitions and B1.3 above for logging requirements). These rely on the premise that an Application is A standalone program installed on a mobile device to help perform a dedicated task. In the context of measurement, this task is typically the presentation of a media owner s content in a channel (or channels) that is different to a website, even though the content accessed may come from the same source. D9 MEASURING CHAT (IRC) TRAFFIC A minimum requirement in order to audit is that the chat logs provided must contain all IP addresses, nicknames, time in and time out of users necessary to support the site's claims. D10 MEASURING CLICKS AND CLICKOUTS The site must have a clearly auditable method of logging Clicks and Clickouts, such as departure or bouncethrough pages. Clicks are subject to the same validity rules as Page Impressions. In other words, the record must have a valid User-Agent and IP address. Note that it is possible for a Unique Browser to make a Click or Clickout without making a Page Impression (e.g. by clicking on a link in a locally cached page). D11 MEASURING PODCASTS To enable certification of Requested or Completed Podcasts, sites must adopt a naming convention for their download files that shows a clear distinction between Downloads made through podcast subscription services and those which have been individually requested with no such prior notification. Such individually requested files count only as Downloads. Any audit will include tests to gain confidence that this naming convention has been applied in accordance with the above requirements. D12 GEOGRAPHICAL IP ANALYSIS Results for certification of Page Impressions by Country and Unique Browsers by Country may be obtained by standard open-source tools such as DNS reverse lookup or by the use of proprietary solutions. JICWEBS endorses certification at Country level only. D13 RECRUITMENT CONVERSION FUNNEL JICWEBS has now agreed a hierarchy of Click and Page Impression events for the recruitment sector which media owners may choose to use (in whole or in part) on an optional basis to help show the efficiency of a site s conversion. The following metrics represent various stages in a valid user s journey and so can be considered a conversion funnel. Event Type Metric Name Job Clickout Web Feed Job Referral In Job Exposure Page Impression Job Search Job Details Page Impression Online Job Referral Job Referral Online Job Application Description User sees description of job on another site and clicks out to the recruitment site Job details are shown on a web feed; user clicks out to the recruitment site Page on a site contains details of one or many jobs User searches for jobs by submitting criteria (which may be provided implicitly, so without direct form completion) to an onsite search facility User requests a page about a single job User clicks on a link to go to a recruiter s site User clicks on a mailto link to launch their application User completes application process on recruitment site Similar conversion processes exist on other types of website, and offer scope for measurement if this is desired either on an individual website or across a sector. Contact your Account Manager if this is of interest. Page 24 of 39

25 SECTION E: ABC ONLINE PROFILES This section is intended to provide an overview of the additional requirements for publishing an ABC Online Profile on a media owner s website traffic audit certificate. E1 INTRODUCTION Standard ABC traffic audits certify data on the number of site Unique Browsers, Page Impressions and other census-based information. The ABC Online Profile provides an industry-agreed survey methodology for complementing standard ABC audited traffic data with visitor profile data captured on a consistent and hence comparable basis. A full ABC Audit (of Unique Browsers and Page Impressions) is required for an ABC Online Profile Certificate. E2 TECHNICAL REQUIREMENTS E2.1 Data Sampling (Fieldwork) A standard sampling approach is required to ensure reliable and comparable ABC Online Profile Certificate results. Key elements of the sampling approach are as follows: E2.1.1 Overlays Overlay solicitations (not pop-ups) must be served randomly run of site across all material domains and sub-domains in the audited web traffic. The survey reporting must correspond to the scope of the ABC web traffic audit (i.e. aggregate results must be collected representatively to the activity levels across the audited domains). Overlay solicitations should be served at an interval that can be expected to produce the target number of survey completions, based on the anticipated level of site traffic. For example, if there are expected to be 1 million Page Impressions during the fieldwork period, and if we assume that all respondents complete the survey, then the overlay should be served with every thousandth Page Impression or thereabouts. In practice the serving may need to be more frequent. The overlay interval should be uniform across all locations. Overlays should be capped to appear to each visitor once only (for each domain covered by the ABC audit) during the fieldwork period. Note that banner solicitations may be used instead of overlays but are not recommended due to substantially reduced response levels. E2.1.2 Fieldwork Period and Sample Size Fieldwork must be completed during the ABC web traffic audit period and run for a minimum of 14 consecutive days. The minimum sample is 1, completions (minimum 400 for smaller sites or sections, which are those with <100k Unique Browsers per month). Only completed survey responses qualify for analysis (partial completions where respondents have dropped out mid survey should be removed). Fieldwork may be extended beyond 14 days within the audit month to achieve minimum samples if required. Media owners must ask the respondent s age as the first question. Results for Online Profiles will only be reported for respondents aged 15 or over, as this is the standard minimum age used by UK media currencies. Therefore respondents below 15 years old should not be asked further questions. All survey respondents, including international, should be allowed to complete the survey. If the site owner wishes to report on a specific geographical audience (e.g. UK and Northern Ireland aged 15+) a split of respondents by country must be shown. E2.2 Data Reconciliation A unique record of each survey completion must be inserted into the web data audited by ABC. Depending on the method of tracking employed by the site publisher, this can be achieved as follows: If the media owner is providing audit data to ABC via a page tagging solution: 1. Insert one of the tags used for tracking across the client site into the last page of the survey. The tag call should pass a unique survey respondent ID to the analytics data; this ID should be logged as part of the Page Impression for the survey s last page. 2. Post the unique survey respondent ID logged in step 1 into the survey response data, to allow matching of the survey completion to the tag call logged by the analytics solution. This method is shown in Figure E-1 below. Figure E-1 Survey data collection If the media owner is not using page tagging, they must: 1. Create a dummy page whose serving is logged in the source of web audit data 2. Insert that dummy page into an IFRAME on the last page of the survey, and append a unique respondent Page 25 of 39

26 SECTION E: ABC ONLINE PROFILES ID into the IFRAME source address every time it is called by a respondent 3. Post the unique survey respondent ID logged in 2) into the survey response data, such that a link may be established between a particular call to the dummy page within the IFRAME logged by the site publisher and a particular survey completion. The survey data set should collect at least the following information to enable certification: URL of the page from which the respondent was solicited Date and time of survey completion Respondent s IP address Respondent s User-Agent Respondent s answers to the survey questions NB: ABC will not certify that the survey responses are correct or complete, but will simply state (if the reconciliation is successful) that, in ABC s opinion, the respondents to the survey were Unique Browsers generating traffic in the same period across the certified web property or network (see ABC Certification below) to an acceptable, representative level. E2.3 ABC seeding of survey completions A URL must be provided to enable ABC to add anonymous completions to the survey. These will be identified during the audit to ensure that the survey data has not been manipulated post fieldwork. A small number of completions will be added and will include standard responses to core questions. E3 CERTIFICATION Once the fieldwork is complete, the media owner must submit the following data to ABC: Raw survey data for reconciliation with website traffic data; Data for the website traffic audit, including records of survey completions per E2.2 above; Indication of whether a Consumer or B2B Online Profile is required; Aggregate tabulations of results and any guides required to interpret them. Upon receipt of this data, ABC will attempt to reconcile it and so verify that the following certification parameters have been met: Survey respondents were recruited over at least 14 consecutive days within the ABC Audit period Solicitations are distributed randomly across the audited domain(s) Solicitation URLs are representative of the web property Minimum sample size of 1, completions has been met (minimum 400 completions for smaller sites) All survey responses represent Unique Browsers who generated traffic on the site during the ABC audit period Seeded survey completions are all present with no duplicates and include correct survey response data Core aggregate reporting tabulations are correct If these requirements are met, ABC will issue an Online Profile Certificate. E4 SECTOR-SPECIFIC REQUIREMENTS E4.1 Consumer The following core standard demographics are a mandatory component for all Consumer Online Profile Certificates: Country of residency Age* Gender* Social grade* * Reported for core audience as defined by client (e.g. UK and Northern Ireland respondents aged 15+). The standard approved question formats are available on request from ABC. Optional demographics, lifestyle and media profiling can be reported on the Consumer Online Profile, based on standard JICPOPS question formats. Media owners may include their own bespoke questions in their Consumer Online Profile surveys; however, results from non standard format questions will not be certified by ABC. The mandatory survey information required for certification is as follows: Aggregate tabulations of results including cross break for core audience defined by client (e.g. UK and Northern Ireland respondents aged 15+) Standard JICPOPS age breaks to be used (15, 16-17, 18-19, 20-24, 25-34, 35-44, 45-54, 55-59, 60-64, 65-74, 75+) If a media owner chooses to make their survey results public as part of a published Consumer Online Profile, the core standard demographics stated in Survey Content represent the mandatory minimum that must be published for the audit period. Additional standard question based information collected by the survey may be reported at the discretion of the media owner based on their particular needs. The survey reporting must correspond to the scope of the ABC web traffic audit (i.e. aggregate results must be collected representatively to the activity levels across the audited domains). E4.2 B2B The following core standard demographics are mandatory for all B2B Online Profile Certificate: Job title or function Geographical location Area of industry served The categories within each question are specified by the site owner. An other category must be used to catch any respondents not specified within the question structure. If a media owner chooses to make their survey results public, as part of a published ABC B2B Online Profile, the core standard demographics represent the mandatory minimum that must be published for the audit period. Page 26 of 39

27 SECTION E: ABC ONLINE PROFILES Additional question based information collected by the survey may be reported at the discretion of the media owner based on their particular needs. Page 27 of 39

28 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS X1.0 INTRODUCTION ABC, working with the IFABC (International Federation of Audit Bureaux, international standards working group, has developed a set of definitions that are the effective world-wide standard for Web traffic audits. Definitions for metrics specific to the internet industry in the UK and Ireland are controlled and developed by JICWEBS, the Joint Industry Committee for Web Standards. The metrics seek to give measurements of reach, volume, frequency and level of interaction. Each set of metrics below falls into one of these general categories. IMPORTANT: These definitions can change from time to time. Please check that you have the latest version of this document by checking the version number and date against those of the version published on the ABC website. The JICWEBS standard definitions are given in bold. Note on Averages The DAILY AVERAGE is the sum of each day s traffic divided by the total number of days. Unique Browsers are not deduplicated between days. The WEEKLY AVERAGE is the sum of each week s traffic divided by the total number of weeks. Unique Browsers are not deduplicated between weeks. The MONTHLY AVERAGE (DERIVED) is the sum of each month s traffic divided by the total number of months. Unique Browsers are not deduplicated between months. X1.1 BROWSER METRICS (Reach) Unique Browser A unique and valid identifier. Sites may use (i) IP+User-Agent and/or (ii) Cookie. This metric measures each browser; it does not measure a person. Counting of Unique Browsers may overstate or understate the real number of individual devices concerned due to factors such as dynamic IP address allocation, significant levels of uniformity in IP and browser configurations operating through a proxy, cookie blocking and cookie deletion. Other device identifiers may be allowed as Unique Browser identifiers when they can be proved in an auditable manner to be persistent and consistent across the domains being measured. Unless otherwise stated, the Unique Browser data refers to worldwide Unique Browsers. This metric can also be known as a (Unique) Visitor or Unique. Repeat Unique Browser A Unique Browser that has made more than one Visit. This metric should be expressed as a percentage of the total Unique Browser figure when shown on certificates. Single Unique Browsers+Repeat Unique Browsers = TOTAL Unique Browsers. Single Unique Browser A Unique Browser that has made only a single Visit. This metric should be expressed as a percentage of the total Unique Browser figure when shown on certificates. Single Unique Browsers+Repeat Unique Browsers = TOTAL Unique Browsers. Monthly Unique Browser The deduplicated net number of Unique Browsers for a month. Weekly Unique Browser The deduplicated net number of Unique Browsers for a week. A week is Monday-Sunday. Only Weekly Unique Browser figures for whole weeks within the audit period will be reported unless certification is continuous. In this case, some weeks reported may include days outside a nominal calendar month. Daily Unique Browser The deduplicated net number of Unique Browsers for a day. Interactive TV Unique Browser A Unique Browser that has made at least one Interactive TV Impression. AV Unique Browser A Unique Browser that has made at least one AV Play. Search Unique Browser A Unique Browser that has made at least one Search. Mobile Unique Browser A Unique Browser that has requested a Mobile Format Impression. WAP Unique Browser A Unique Browser that has made at least one WAP Impression. Due to the lack of variation in WAP proxy IP+User- Agent combinations, this metric must be calculated using cookies. Chat Unique Browser (HTML Chat ONLY) A Unique Browser that has made one or more Chat Impressions. This is typically each Unique Browser that has contributed to the total Chat Impressions. Web Feed Referral In Unique Browser A Unique Browser that has made a Web Feed Referral In. Page 28 of 39

29 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS Web Feed Unique Browser A valid Unique Browser (measured by Cookie) that has requested a web feed from the source site. This produces a count of the total Unique Browsers who request web feeds (e.g. RSS, Atom) through browsers. The Cookie identifier is agreed to be the only identifier that provides the required level of granularity. No defaults are currently acceptable. The simple number of web feeds requested is not considered meaningful, since the number of requests relies so much on automated processes. Web Feed Article Impression Unique Browser A Unique Browser generating at least one Web Feed Article Impression. Note that this can be measured by IP+User-Agent and/or Cookie, as per the Web Unique Browser definition. Requested Podcast Unique Browser Any valid Unique Browser that has made a Requested Podcast. Completed Podcast Unique Browser Any valid Unique Browser that has made a Completed Podcast. Registered User Account An account set up for a user to request to receive access to a website, service or network. All such Registered User Accounts should be contactable for audit purposes. Active Registered User Account A Registered User Account that has accessed the website, service or network in the certification period. Auditable evidence of activity in the audit period for ALL Active Registered User Accounts is required. Contactability is not mandatory where such evidence of activity is available. Paid Registered User Account A Registered User Account set up for a user upon payment by that user to request to receive access to a website, service or network. All such Paid Registered User Accounts should be contactable for audit purposes. Auditable evidence of payment and identifiers of the account must be provided. Active Paid Registered User Account A Paid Registered User Account that has accessed the website, service or network in the certification period. Auditable evidence of payment, account identifiers and activity in the audit period is required for ALL Active Paid Registered User Accounts. Contactability is not mandatory where such evidence of activity is available. Subscriber Account An account set up for a user to request to receive access to a website, service or network for a fixed period of time. All such Subscriber Accounts should be contactable for audit purposes. The site owner must provide the expiry (renewal) date of the account. Active Subscriber Account A Subscriber Account that has accessed the website, service or network in the certification period. Auditable evidence of activity in the audit period for ALL Active Subscriber Accounts is required. Contactability is not mandatory where such evidence of activity is available. Paid Subscriber Account A Subscriber Account set up for a user upon payment by that user to request to receive access to a website, service or network for a fixed period of time. All such Paid Subscriber Accounts should be contactable for audit purposes. Auditable evidence of payment, expiry (renewal) dates and identifiers of the account must be provided. Active Paid Subscriber Account A Paid Subscriber Account that has accessed the website, service or network in the certification period. Auditable evidence of payment, account identifiers and activity in the audit period is required for ALL Active Paid Subscriber Accounts. Contactability is not mandatory where such evidence of activity is available. Unique CV Registrant A Registered User Account that has made at least one New CV Registration. Active CV Registrant A Registered User Account that has either made at least one New CV Registration or updated an existing CV in the month. Podcast Subscriber A valid Unique Browser (measured by Cookie) that has requested a notification of podcast availability from the source site. Unique Host A unique IP address. Page 29 of 39

30 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS X1.2 IMPRESSION METRICS (Volume) Page Impression A file, or combination of files, sent to a valid browser as a result of that browser s request being received by the server. In effect, one request by a valid browser should result in one Page Impression being claimed. The counted Page Impression may not necessarily be in focus and all content may not be fully visible in the browser window. In most cases, a single request from a browser causes the server to send several files to satisfy the request. For example, the server may send an HTML file followed by several associated graphic images, audio files and other files such as stylesheets. A single request from a browser may also cause the server to send several additional HTML files to build a frameset. The site must ensure that all additional files are excluded when counting the claimed number of Page Impressions. Generally, subject to the guidance principles issued by the auditor, directly attributable user-initiated logged events for content (typically mouse clicks) can be used to count Page Impressions, whether served in HTML, Ajax, Flash or other environments. This metric can also be known as a Page View or Page Request. Please note that files that contain specific types of advertising creative, such as banners or skyscrapers, and files that represent Streams are not valid for the counting of Page Impressions but should be used separately to identify Ad Impressions or AV Plays (defined in Section 2.6 below). Page Impressions must contain textual content beyond simple advertising. Automated Page Impression A Page Impression sent to a valid browser as a result of an automatic process enabled by the site. If a valid browser (i.e. a connection to the site from a valid browser) requests a page and subsequently the page is refreshed, or another content-bearing page is sent, at a time interval set by the site to that same browser, then both the original page request and all subsequent refreshed pages are deemed to be valid Page Impressions but the later are known as Automated Page Impressions. The fact that the subsequent pages result from an automated process does NOT make those pages invalid. The browser has, by default, made a valid request for all subsequent pages. Hence, the resulting Page Impressions are deemed to be valid and can therefore be claimed. Automated Page Impressions are therefore valid logged records that represent pages normally requested automatically by the browser, without the need for human action - for example automated price/news/score updates, text tickers, slide-show sequences or automated tours. All Audit Certificates must carry a breakdown of the totals of Automated Page Impressions from the overall Page Impression total where such traffic forms 5% or more of the overall Page Impression count. WAP Impression A file, or combination of files, intended for a WAP device, sent to a valid browser as a result of that browser s request being received by the server. In effect, one request by a valid browser should result in one WAP Impression being claimed. Certain WAP traffic can be excluded on the basis of information derived from the server log files. In most cases, a single request from a browser causes one or more WML files (a so-called "WAP deck") to be sent by the server. The site must therefore ensure that any additional, non-requested files are excluded from the claimed WAP Impression total. A WAP Impression does not guarantee that a user actually viewed a page of WML; it only measures the opportunity for the user to view such content. This means that a WAP Impression recorded as valid by the server will be valid even if the content does not load to completion. WAP Impressions can be included within the headline Page Impression total on a certificate; they may be broken out if desired. Mobile Format Impression A Page Impression delivered in a format optimised for use on a smartphone or similarly capable handheld device. These impressions must be distinguishable from standard desktop formatted Page Impressions by URL, by Domain or else by another field that specifically records whether a requested Page Impression was delivered in a mobile format. Note that User-Agent, screen size and screen resolution are not acceptable fields for identification of Mobile Format Impressions. Chat Impression (HTML) A file, or combination of files, sent to a valid browser while the browser is involved in an interactive Chat session (i.e. a Page Impression generated by a Chat URL.). Chat URLs show the input of one or more concurrent Users, visible to each other, updated frequently, so as to enable a text based conversation. In effect, one request by a valid browser should result in one Chat Impression being claimed. This metric is not applicable to Forums, where concurrent users are not typically visible to each other. The metrics available to a site to measure Chat depend on the technology employed by the site to support Chat. Chat based technologies include HTML, IRC, Java and proprietary applications. The Chat Impression metric is only available for HTMLbased chat. Chat Impressions can be included within the headline Page Impression total on a certificate; they may be broken out if desired. Page 30 of 39

31 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS Interactive TV Impression A file, or combination of files, intended for an Interactive TV device, sent to a valid browser as a result of that browser s request being received by the server. In effect, one request by a valid browser should result in one Interactive TV Impression being claimed. Certain Interactive TV traffic can be excluded on the basis of information derived from the server log files. The site must therefore ensure that any additional, non-requested files, such as graphics, audio files or frames, are excluded from the claimed Interactive TV Impression total. An Interactive TV Impression does not guarantee that a user actually viewed the page requested; it only measures the opportunity for the user to view such content. This means that an Interactive TV Impression recorded as valid by the server will be valid even if the content does not load to completion. Interactive TV Impressions can be included within the headline Page Impression total on a certificate; they may be broken out if desired. PDF Impression A file, or combination of files, containing PDF content, sent to a valid browser as a result of that browser s request being received by the server. This metric allows the measurement of the total number of PDFs sent to a user within the Page Impression total. Job Exposure Page Impression A valid Page Impression that contains headline details of job vacancies including, as a minimum, the job title and at least one other relevant parameter e.g. location or salary. Job Details Page Impression A valid Page Impression that contains the particulars for a single vacancy only. CV Details Page Impression A valid Page Impression that contains the particulars for a single CV only. Proprietary Page Impression A valid Page Impression on a recruitment site where the Site Owner (which may be different to the Site Publisher) is materially the same as the Site Advertiser. Where such Page Impressions represent more than 5% of the total Page Impressions in the audit period, these MUST be broken out. Online Property Details Page Impression A valid Page Impression that contains the particulars for a single property listing only. Note that a single property can have multiple listings, that the presence of a listing identifier does not guarantee that the listing is current and that the listing may not be for a genuine property. X1.3 OTHER INVENTORY METRICS (Volume) Search The first Page Impression sent to a valid browser as a result of that browser s search request being received by the server. In effect, one search request by a valid browser should result in one Search being claimed. This requires that the site, and hence the audit, can identify the first Page Impression served in response to a search request from a valid browser and differentiate this first results page from any others. The Search total for a site is distinct from its Page Impression total Searches are a subset of valid Page Impressions. Job Search The first valid Page Impression sent to a valid browser as a result of that browser s search request from a dedicated job search form being received by the server. AV Play A file request by a valid browser for an AV playlist. This can be measured in either of the following ways: AV Play Event A client-side play event representing the start of data processing made by a valid browser, which is not recorded concurrently with an event of the same type. AV Request A server-side indicator of a media file successfully served to a valid browser. (Success is defined as transfer of content, so where the bytes sent are greater than zero). Note: The media owner must be able to demonstrate in an auditable manner that content is included in the playlist as well as advertising. To record a valid AV Play the duration must equal greater than zero and a new AV Play should be recorded in the event of the content restarting automatically. Automated AV Play An AV Play started by a valid browser as a result of an automatic process. Where Automated AV Plays form more than 5% of the total AV Play number, they MUST be broken out. AV Content Play A file request by a valid browser for AV content. This can be measured in either of the following ways: (AV Content Play Event, AV Content Play Request) AV Content Play Event A client-side play event representing the start of data processing for AV content made by a valid browser, which is not recorded concurrently with an event of the same type. Page 31 of 39

32 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS AV Content Play Request A server-side indicator of an AV Content media file successfully served to a valid browser. (Success is defined as transfer of content, so where the bytes sent are greater than zero). Note: Where the consumption of specific content items is to be reported, a unique content identifier must be logged Web Feed Article Impression A web feed article requested by a valid browser within their browser or web feed reader. This measurement requires the counting of a serving of a 1x1 tracking pixel within the <description> element of each article in a given web feed. These pixels will only be shown as a result of a definite user action to view the feed article. Since each article request will be counted, more than one article (and pixel) may be requested at once in a reader or Web browser. This metric should therefore not be considered to be comparable with a Page Impression. Web Feed Ad Impression A file sent to a valid browser as an individual advertisement as a result of that browser's clientinitiated request for a Web Feed Article Impression being received by the server. Any client-initiated method of counting Ad Impressions (per the IAB v6.0b standard) is acceptable. PDA Synch A synch by a PDA device with the site (or channel). This is measured by requiring one URL per site (or channel) to be non-cacheable. This then acts as the identifier for counting PDA Synchs. Measuring how many times this URL was requested in the Audit Period will therefore allow a count of total PDA Synchs. Break-outs by channel can also be supported by this approach. This creates a comparable and indicative measure of a site s PDA audience. The agreed metric is not PDA Users, as we are not identifying the receiving device. This may become possible in future. Requested Download A request for a non-html file executable offline. This typically includes audio files, video files, games and document files (e.g..doc,.xls,.mp3,.ppt,.pdf). By definition, this excludes Streams, since they require a live connection to a server in order to execute (see Stream definition above). Automated Requested Download A request for a non-html file executable offline as a result of an automated process. This must be broken out where it forms at least 5% of the total of Requested Downloads. Completed Download A completed request for a non-html file executable offline, shown by the number of bytes transferred being at least 95% of the stated size of the file. When counting Completed Downloads, sites offering progressive download facilities need to demonstrate auditable adherence to this 95% rule over the course of the progressive download to a single browser. Automated Completed Download A completed request for a non-html file executable offline, shown by the number of bytes transferred being at least 95% of the stated size of the file, as a result of an automated process. This must be broken out where it forms at least 5% of the total of Completed Downloads. Requested Podcast A Requested Audio or Video Download made by a valid browser following receipt of an automated notification of availability. These are assumed to be automatically requested (i.e. Automated) unless the site can provide auditable evidence to the contrary. Completed Podcast A Completed Audio or Video Download made by a valid browser following receipt of an automated notification of availability. These are assumed to be automatically requested (i.e. Automated) unless the site can provide auditable evidence to the contrary. Online Job Application The submission to a server of an application form or a CV by a valid browser. The content of the application form or CV submitted is NOT reviewed as part of the audit. The site must provide auditable evidence of submission, such as a "thank you" Page Impression or a redirect to a success URL. New CV Registration A Page Impression served upon submission of a new CV into the database of a recruitment site from a valid browser active on that site. The site must provide auditable evidence of submission, such as a "thank you" Page Impression or a redirect to a specific success URL reachable by no other means. This metric is a count of activity on the site and measures CV uploads only, not updates. One user account may upload more than one CV at a time. Job Application Requested Download A Requested Download of a job-related document. Page 32 of 39

33 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS Online Property Referral A Page Impression served after a valid browser has requested property details from an estate agent. Such Property Details Requests are represented by a "thank you" page after the users have completed the form, just as for Online Job Applications, and must have a specific URL reachable by no other means. Publication Opened A file, or combination of files, that represents the Page Impression for the first (arrival) page of an online publication served in response to a valid request by a valid browser. This metric applies only to properties which present themselves online in a print-style format typically built in rich media and requiring the user to turn virtual pages. User-Initiated Logged Event Any logged event that can be attributed to a particular Unique Browser. Such events are typically captured by browser-side measurement. Examples include mouse-overs, link views, menu selections or filling out of form fields. The use of such events allows more granularity in the measurement of Visit and Duration metrics. To be clear, the number of such events captured is not a certifiable metric itself. Section A specific set of domains, Sub-domains or URLs, with a common type of content that a media owner has applied to the certified property/network and where any one URL can only ever belong to one Section. This definition explicitly states that the collection is under the media owner s control and so there is some degree of subjectivity. However, an element of comparability is maintained by requiring there to be a common type of content which will be audited for as reasonable by ABC. During the audit of any Section, commonality of content will therefore be verified as well as the principle that one URL can only belong to one Section. In addition, ABC will verify that claimed numbers for a Section can be substantiated when applying the same perimeter to the Section. X1.4 VISIT AND DURATION METRICS (Frequency) Visit A series of one or more Page Impressions, served to one valid browser, which ends when that browser has not made a Page Impression for a 30-minute period. A Visit is effectively a near-continuous burst of activity by a valid browser. Note that, in addition to Page Impressions, the media owner can use User-Initiated Logged Events to calculate this metric if desired. Visit Duration The total time in seconds for all Visits of two or more Page Impressions, divided by the total number of Visits of two or more Page Impressions. In order to measure Visit Duration, a first and last Page Impression record must exist for each Visit. Therefore, Visits of only one page are excluded, since no interval can be established. Note that, in addition to Page Impressions, the media owner can use User-Initiated Logged Events to calculate this metric if desired. This would enable Visit Duration to allow for the last page of every Visit (and so measure single-page Visits). Unique Browser Duration The total time in seconds for all Visits of two or more Page Impressions, divided by the number of Unique Browsers making such Visits. In order to measure Unique Browser Duration, a first and last Page Impression record (or other auditable logged event) must exist for each Visit. Therefore, Unique Browsers only making Visits consisting of only one Page Impression are excluded, since no interval can be established. Note that, in addition to Page Impressions, the media owner can use User-Initiated Logged Events to calculate this metric if desired. Chat Duration (HTML ONLY) The total elapsed time in seconds between the first and last time stamp recorded for each valid browser's Chat Impressions. In order to measure Chat Duration, a first and last Chat Impression record must exist for each Unique Browser. Therefore, Users making single-record Chat Impressions, and any such Chat Impressions, are excluded. This metric should be used alongside the Chat Impression and Unique Chat User metrics. AV Play Duration The number of seconds of content served to a valid browser in an AV Play. Client-side, this would be calculated by measuring end events terminating the AV Play Event (such as Pause, Fast Forward or Stop) and calculating the gap between the Play event and the end event. Hence, AV Duration can only be measured when there is such an end event. Server-side, the Duration field should be used. Where this is not available, an approximation can be calculated from valid AV Requests by dividing the bytes sent to the user by the average bit-rate per second. Ideally, buffering time should be excluded from AV Play Duration calculations, but this may not always be practical. Page 33 of 39

34 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS AV Play Completion Rate The percentage of AV Plays that consumed at least 95% of the on-demand AV content requested. For AV Play Events, the AV content item must have both a start and a corresponding end event, and the measured AV Play Duration between the two must equal the total duration of that content item. For AV Play Requests, the start of the request must be on or before the defined start time, and the duration of the request must equal or exceed the length of the defined content item (and so go beyond the content item s defined end point). In both cases, the total length of the content item must therefore be known. Total AV Play Duration The aggregate total number of seconds of all plays of a content item in the period. Note that a content item here means an AV playlist or any part thereof. Unique AV Play Duration The total length of distinct content played by each AV Unique Browser. Note that content here means an AV playlist or any part thereof. Unique AV Play Percentage The percentage of the total content of each content item played by each Unique Browser. Note that a content item here means an AV playlist or any part thereof. X1.5 CLICK METRICS (Interaction) Click The activation of a hypertext link by a valid browser. Note that the site must have an auditable way of logging Clicks. The User must be a valid (non-robotic, non-internal) User. Search Click A Click originating from a set of Search results. Clickout A Click to an external (non-native) destination. This metric can also be known as Referral or Departure. Job Clickout A Click to a job listing on another recruitment site. Click Visit A series of one or more Clicks, served to one valid browser, which ends when that browser has not made a Click for a 30-minute period. Online Job Referral A Click on a link within a job listing to a URL specified by a Recruiter. Referral In A Page Impression representing an arrival at a property by a valid browser from another identifiable property. Effectively, the event that needs to be detected is the arrival at the identified property by a user who has come from another property. To do this requires testing whether this Page Impression has a Referrer field that is native to the property or is Null; any nonnull, non-native values may be counted as Referrals In. This metric can also be known as a Clickin. Web Feed Referral In The first Page Impression served to a valid browser as a result of redirection from a link in a web feed clicked on by that browser. Web Feed Job Referral In A Page Impression to a URL specified by a Recruiter served to a valid browser as a result of redirection from a link in a web feed job listing clicked on by that browser. Referral In A Page Impression representing an arrival at the property by a valid browser from a hyperlink embedded in an . The destination property must be able to present auditable evidence of such arrivals. Job Referral A Click on a mailto link within a job listing intended for the submission of applicant information and/or a CV to a recruiter. X1.6 CHAT METRICS (non-html) Note that it is NOT currently technically possible to introduce a meaningful Chat Impressions metric. Unique Chat Host A unique IP address found within the valid chat log records. Unique Chat User A unique combination of an IP address + a Nick name + a 5 second minimum stay (logged time in minus logged time out). Page 34 of 39

35 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS Sites are also required to show a break out from the above headline total, for Active Chat Users (Chat Users who log on and participate by contributing to the discussion) and Non-Active Chat Users (Chat Users who log on but do not actively participate, also known in the sector as lurkers ). Unique Active Chat User A unique combination of an IP address + a Nick name + a 5 second minimum stay (logged time-in minus logged time-out) + 1 or more logged lines. Unique Chat User Duration The total duration in seconds (measured by taking time joined from time left) of all valid Unique Chat Users, divided by the total valid Unique Chat Users. X1.7 Geographical IP-based metrics Page Impressions By Country The percentages by country of all Page Impressions produced by all resolved IP addresses during the Certification Period. Note: These results were correct at the time of testing. Due to the constant changes in IP address ranges and registration, repeating the tests at a different time may not give exactly the same result. These results may appear in a tabular or pie-chart format e.g % UK, 6.36% US, x% unresolved. Unique Browsers By Country The percentages by country of all valid Unique Browsers identified during the Certification Period. Note: This requires calculation of an IP address recorded in all Page Impressions made by each valid Unique Browser. These results were correct at the time of testing. Due to the constant changes in IP address ranges and registration, repeating the tests at a different time may not give exactly the same result. These results may appear in a tabular or pie-chart format e.g % UK, 6.36% US, x% unresolved. Ad Impressions By Country The percentages by country of all Ad Impressions produced by all resolved IP addresses during the Certification Period. Note: These results were correct at the time of testing. Due to the constant changes in IP address ranges and registration, repeating the tests at a different time may not give exactly the same result. These results may appear in a tabular or pie-chart format e.g % UK, 6.36% US, x% unresolved. X1.8 APPLICATION METRICS App (Application) A stand-alone program installed on a device to help perform a dedicated task. The name and version of the application form the perimeter of measurement, which must be specified on any certification. App Unique Browser Any Unique Browser that has made an App Page Impression. Note: App Unique Browsers may use consistent, persistent identifiers of an application that are wholly or partially based on identifiers (e.g. UID) passed to the App by the device. The media owner should be aware that using the unmodified device identifier may lead to privacy issues. App Page Impression A file, or combination of files, equivalent to a page of content sent to an App in response to a valid request from a valid (App) Unique Browser. Note: The validity of a Page Impression event is subject to the standard ABC framework for rich media measurement. App Event Any logged event that takes place within an App that can be attributed to a valid Unique App Device. Note: App Events are not in themselves a certifiable metric because meaningful comparisons cannot be made App Visit A series of one or more App Page Impressions, served to a single valid (App) Unique Browser, which ends when that (App) Unique Browser has not made an App Page Impression for a 30-minute period. Note: A logged event that takes place within an App which may not be a valid (App) Unique Browser may be used. App Visit Duration The total time in seconds for all App Visits containing two or more App Page Impressions, divided by the total number of Visits of two or more App Page Impressions. App Ad Impression An Ad Impression requested by a valid App Unique Browser. Note: The App Ad Impression represents the serving of a banner or similar creative from a separate ad server into the App environment. This does NOT cover the advertising that appears on digital editions as part of the same content (e.g. a PDF of a print copy). X1.9 AD METRICS See the ABC Guidance Notes for Ad Audits. Page 35 of 39

36 APPENDIX 1: JICWEBS STANDARD WEB TRAFFIC METRICS X1.10 SMS METRICS See the ABC Guidance Notes for SMS Audits. X1.11 METRICS See the ABC Guidance Notes for Audits. Page 36 of 39

37 APPENDIX 2: ABC DEFINED TERMS USED IN THIS DOCUMENT X2.0 INTRODUCTION The terms defined below are used in this document and in other ABC documentation and can change at any time. Please check that you have the latest version of this document by checking the Revision Number and Date in the header. X2.1 INDEX OF DEFINED TERMS ACCESS LOG See Raw Log. AUDIT PERIOD (also CERTIFICATION PERIOD) The period during which the Auditor examines raw log files for traffic validity. The minimum Certification Period is a calendar month. BROWSERID+DATE FILE A data file listing either all dates on which each Unique Browser identifier (BrowserID) has visited the website during the certification period, or all identifiers present on the website during each day of the certification period. BROWSERID+DATE+DOMAIN FILE As per the BrowserID+Date file but also including the separate domains visited by each Unique Browser identifier. BROWSERID+VISIT FILE Text or data file listing the total Visits made by each User to the property during the audit period. CERTIFICATION PERIOD See Audit Period. COMPLIANT LOG (also FILTERED FILE) A file of valid records that support the traffic claim for the certification period. COOKIE A small text file automatically sent to the user's browser upon visiting a page, which then continues to reside on the user s computer. Cookies must be persistent if they are to be used as Unique Browser identifiers. COUNTING (also WEB ANALYTICS) The process of analysing log file data to establish web site traffic statistics preparatory to making a claim. DOMAIN A name that represents one or more IP addresses (typically web servers) owned by the media owner or its agents. FAITHFUL EXTRACTION The reporting process for unauthenticated raw data. ABC undertakes only to confirm that all metrics have been faithfully extracted from this data, and makes no claim as to the provenance of such data. FILTERED FILE See Compliant Log. FIRST-PARTY COOKIE A cookie set by the domain currently being visited by the user. GEOGRAPHICAL IP ANALYSIS Process used to determine as far as possible the country of origin of each Unique Browser or Page Impression. Typically involves, as a minimum, carrying out reverse DNS and Whois lookups to determine provenance. INTERACTIVE TV The receipt of Internet-compatible content via a set-top box or other such interpreting device for viewing on a standard television. JICWEBS The Joint Industry Committee for Web Standards the UK industry body which regulates the evolution of web measurement. Members of this body are drawn from associations that represent the new media, publishing and advertising industries. The website is INVENTORY DOMAIN (also INVENTORY URL where applicable) An Inventory Domain is any domain, subdomain, URL tree or alias which is included in the traffic being audited, whether owned by the media owner or a third party. Inventory Domains must be stated on the certificate to provide transparency and meaning for certificate users. PAGE TAGGING The embedding of an asset (typically Java, Javascript, CGI or a simple pixel) on a site, the rendering of which sends data to a collection point (e.g. a log file) every time a page is loaded into a browser, such that one execution of code is intended to equal one Page Impression. PROPERTY The inventory, consisting of a domain or set of domains, defined by the media owner for the purposes of an ABC web audit. PROPERTY NAME The brand or trademark used by a network of properties, or property, for marketing purposes. PROPERTY URL A property s top-level or brand identifying URL stated on the certificate, typically a homepage URL. RAW LOG (also known as ACCESS LOG) The original text-based record maintained by a web server(s) of all traffic which involves it. Page 37 of 39

38 APPENDIX 2: ABC DEFINED TERMS USED IN THIS DOCUMENT REFERRER The fully-qualified URL of the page from which, via a direct hyperlink, a user reached the current requested URL. It is typically logged including the string. RSS Really Simple Syndication the most popular web feed technology which allows headline or headline-andshort-summary feeds syndicated from other sites to be incorporated into a web page or read by a web feed reader. SUBSITED TRAFFIC Any Page Impression served for a site within a separate browser window (typically a pop-under) automatically generated by another site as a result of a request by a valid browser for the content of the other site. SYNDICATED CONTENT (also THIRD-PARTY HOSTED CONTENT) Content served by a third party into the certified site s Page Impressions, or content served by the certified site into a third party s Page Impressions. THIRD-PARTY AUTHORED CONTENT Any content which is not authored by employees of the media owner. THIRD-PARTY COOKIE A cookie set by any domain other than that currently being visited by the user. URL A string of characters identifying where a networked content resource is available and the mechanism for retrieving it. USER A human interacting with the Internet and leaving an audit trail of logged data. It is assumed that all compliantly filtered metric totals derive from valid browsers, who are not robotic or internal. Note that this is expressly not the same as a Unique Browser. UNIQUE HOST The unique IP address that can form a part of the user identifier. VALID TRAFFIC Traffic which is not excluded according to the JICWEBS rules in Section C. WEB ANALYTICS See COUNTING. Page 38 of 39

39 Contact us ABC, Saxon House, 211 High Street, Berkhamsted, Hertfordshire, HP4 1AD +44 (0)