PROPOSED METRIC SECTION ***STAFF USE ONLY: PLEASE DO NOT EDIT***
1Metric Description:

Survey of perceived consumer trust in DNS, relative to experiences before the gTLD expansion. Survey could at least measure experiences with:

  • phishing, parking sites, malware and spam; 
  • confusion about new gTLDs;  
  • user experience in reaching meaningful second-level TLDs; 
  • registrant experience in being in a different gTLD; 
  • registrant and Internet User’s experience with regard to cybersquatting.  
2Notes/Comments:
3AoC Category:Consumer Trust (CT)
4SO/AC Originator:GNSO
STAFF INFORMATION/ANALYSIS SECTION
5Staff Team:Online Comm Svcs
6

Metric Currently Measured?

No

7

 

Computation:
(e.g., data elements, formula, numerator, denominator, ratio/percent, periodicity/frequency)
See Q11...
8Data Owner:
(i.e., party responsible for collecting and publishing metric)
Indeterminate
9Data Reference Source:
(i.e., how/where is the data collected, tracked, managed, and published/produced?)
Indeterminate
10Targets: 
SLA:
3-Year:
11Implementation Considerations:
(e.g., what new or additional resources, tasks, activities, systems, et al., whether internal or external, would be needed to develop, capture, and report this metric?) 

A team of SMEs would need to be assembled to:

  • Ensure that such an instrument would satisfy AoC objectives
  • Identify exactly what topic areas the survey should address
  • Determine whether the topics can be handled within a single questionnaire vs. multiple surveys
  • Outline the types of questions that would be instrumentally effective
  • Develop requirements for sucessful development and implementation
  • Discuss prospective survey population, sampling, and other critical parameters

A make vs. buy decision would be needed to determine whether ICANN should develop the survey in house or hire an external firm. If the latter choice is made, an RFP would need to be written, published, and responses analyzed to select a winner. 

A development period would ensue followed by instrument/process testing and analysis of the test. Once a final design is approved for use, the survey would be conducted and monitored by either ICANN or the external firm. A final report, utilizing accepted statistical methods, would then be produced and, after approval by ICANN, published. 

12Degree of Difficulty/Impact:
(i.e., net impact on existing ICANN resources, systems, and capabilities) 
Significant
13Estimated Development Cost ($M):
InternalExternal
< $.1M$.3M - .5M
14Estimated Ongoing Production Costs:
(i.e., incremental to existing funded/budgeted expenditures) 
InternalExternal
$10,000$25,000
15Estimated Net Incremental Staff (FTE):
(Express as a fraction and/or range, e.g., .25 - .50)
.25 - .50 FTE
16

Itemization of Staff Work Effort:
(i.e., list of tasks/activities to support FTE calculation in Q15) 

On the basis that this project is externally developed and administered, Staff tasks/activities include:

  • Support SME team including drafting
  • Public Comments publication?
  • Preparation of RFP
  • Legal review
  • Analysis of bidders and selection of final award winner
  • Coordination with vendor to operate survey
  • Manage approval process of final report and ensure proper publication
17Rough Implementation Timeframe:
(e.g., indicate major steps and months/years to complete each one) 
InternalExternal
WG:6-9 months
RFP:3 months
Total:9-12 months
Devel:2 months
Test:2 months
Implem:2 months
Report:1 month
Total:7 months
18Critical Dependencies:

Dependencies: 

  1. Assigning the appropriate ICANN Staff Department to administer, coordinate, and manage this metric whether collected internally or externally. 
  2. Developing and executing RFP process.
19Anticipated Challenges/Risks:

There are many challenges to be addressed including, but not limited to:

  • Population identification (open vs. invitation, characteristics, demographics, et al.)
  • Sample size to produce statistically reliable estimates
  • Questionnaire bias
  • Survey length, instrumentation, scaling, etc. 
  • Adequate testing to ensure reliability
  • Risk that, after implementation, the results may be inconclusive
METRIC EFFECTIVENESS AND UTILITY SECTION
20Explanation of Metric Effectiveness:
(i.e., how will success/failure enable conclusions to be drawn concerning the relevant AoC definition?) 
Measures related to confidence in registrations and resolutions.
21Metric Effectiveness Assessment:
(i.e., vis a vis AoC definition)
Moderately Effective
22

Overall Feasibility Assessment: 

LEGEND

Poor: Low Effectiveness - High Cost
Weak: Low Effectiveness - Low Cost
Potential: High Effectiveness - High Cost
Optimal: High Effectiveness - Low Cost

Potential
 ======================================= 

DETAILED ITEMIZATION & TRACKING OF ISSUES

Category A:

Metric Questions & Issues

No.Issue DescriptionOriginatorStatusComments

1

It is not clear, from the metric's description, exactly what measurements would derive from performing a survey, e.g., "Percentage of respondents expressing satisfaction with X?" To answer Q3 properly will require considerable development and analysis. KB

Pending

2

Based upon the phrasing in Q1 and considering that survey lengths should be short in duration (15-30 mins), this metric may ultimately sub-divide into several different measurements. KB

Needs Clarification

Category B:

Metric Effectiveness & Utility

No.Issue DescriptionOriginatorStatusComments

1

Suggest a more thorough answer to Q20 which describes how such a metric would impact interpretations of CT.KB

Needs Clarification

Category C:

Technical/Implementation

No.Issue DescriptionOriginatorStatusComments

1

If ICANN expects to utilize survey methods for important questions now and into the future, should it consider developing the capability in house? KB

Deferred

Category D:

Financial/Cost/Budgetary

No.Issue DescriptionOriginatorStatusComments

1

Due to budgeting constraints, work on this metric cannot begin until FY 2015.KB

Under Review

Category E:

Other

No.Issue DescriptionOriginatorStatusComments

  • No labels