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 info@jicwebs.org. 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 info@abc.org.uk. 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 claims@abc.org.uk 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