This workspace will be used by the ALAC New gTLD Metrics Task Force for its report.
Second Draft
Background
On February 28 2013, the At-Large Advisory Committee approved a statement in response to the GNSO report on metrics designed to evaluate the performance of ICANN's gTLD expansion program. The statement, which was sent as correspondence by ALAC Chair Olivier Crepin-Leblond to the Chair of the ICANN Board and the Chair of the Board gTLD Working Group, indicated that the GNSO report did not adequately address metrics that would accurately measure end-user benefits and trust resulting from the expansion. In the statement, the ALAC committed to produce recommendations for additional metrics which it believes are required to supplement the GNSO recommendations. The ALAC created a Task Force to create the new metrics, which are listed below.
Scope
The ALAC found the scope of metrics used by the GNSO to be too limiting to be effective in measuring end-user benefit and confidence. To be effective, the metrics must evaluate the gTLD program not only between the different registries, but between the use of domain names and alternate methods to access Internet information. We are concerned about the effect of the expansion program not only on the new gTLDs, but on public confidence in the whole domain name system. It is possible that a reduction in confidence in new gTLDs could spill over to legacy registries which we believe metrics need to track.
The metrics proposed are intended to measure the gTLD expansion program from the point of view of Internet end-users, the ALAC's community as defined in ICANN bylaws. We assume that the needs of domain buyers and sellers are sufficiently addressed by the GNSO in its metrics. The metrics below supplement, not replace, the GNSO recommendations.
Format
In the interest of minimizing complexity and simplifying use, we will maintain the structure used by the GNSO metrics report. The section numbering starts at 4 to avoid confusion with the GNSO metrics.
| # | Measure related to End-User Trust | Source | Anticipated Difficulties in | 3-year target |
|---|---|---|---|---|
End-User Confusion | ||||
| 4.1 | Frequency of success in reaching the intended information supplier through direct entry of domain names | Survey of end-users; SEO research | Note 1 | Neutral or increase |
| 4.2 | Frequency of landing at unintended destinations | Survey of end users, SEO analytics | Note 1 Selective sampling of analytics may help determine the success of typo-squatting or other unintended destinations | Neutral or decrease |
| 4.3 | Frequency of redundant or defensive domains (ie, multiple domains pointing to the same destination) | Survey of registrants | Note 2 | Neutral or decrease |
| 4.4 | Frequency of dead-end domains (registered but do not resolve) | Registry data + automated sampling | Note 3 | Proportion relative to total domains should decrease |
| 4.5 | Numbers of complaints received by ICANN regarding improper use of domains | ICANN | Supplements GNSO metric 1.9 by assessing volume of end-user complaints (which may not come from name owners or result in URS/UDRP action) | |
Growth in use of both domain-based and non-domain-based alternatives for Internet resource access | ||||
| 5.1 | Relative preference of explicit use of domain names versus search engines for end-user general Internet use | Survey of end users; SEO analytics | Note 1 | Note 4 |
| 5.2 | Growth in use of hosted pages for organizations (such as Facebook or Google+) | Market research | Ie, ComScore | Note 4 |
| 5.3 | Growth in use of QR codes | Market research | ie, ScanLife | Note 4 |
| 5.4 | Growth in use of URL shortening services | Market research | Note 4 | |
| 5.5 | Growth in registrations in ccTLDs relative to gTLDs | Registry data | Note 3 | A significant increase in the use of ccTLDs could mean reduced trust in generic TLDs. |
| 5.6 | Growth of Software Defined Networking (SDN) as alternative to the DNS | Market research | Note 4 | |
Complaints to, and action taken by, police, regulatory agencies and advocacy groups | ||||
| 6.1 | Number of consumer complaints to government agencies related to confusing or misleading domain names | Government regulatory agencies | Establishing relationships with consumer protection and regulatory agencies may be difficult to initiate; however ICANN is expected to have such relationships in place anyway, either directly or through GAC representatives | Proportion relative to total domains should decrease |
| 6.2 | Number of complaints to police agencies alleging fraud or misrepresentation based on – or traced to – domain names | Law enforcement agencies | ICANN already has existing communications with LEA groups. Supplements GNSO metrics 1.15 and 1.16 by adding complaints as well as remedial action | |
| 6.3 | Number of fraud investigations where WHOIS information positively assisted investigation and identification of offending parties | Law enforcement agencies | ||
Transparency of contact information and domain-allocation policies for all gTLDs | ||||
| 7.1 | How many gTLD registries have privacy policies which are clearly and easily accessible by end users | Registry websites | Manual auditing | As many as possible |
| 7.2 | How many gTLD registries have allocation policies which are clearly and easily accessible by end users | Registry websites | Manual auditing | As many as possible |
| 7.3 | How many registries disclose end-user information regarding their codes of conduct for sub-domain owner/operators | Registry websites | Manual auditing | As many as possible |
Accuracy of new gTLD promotion to end users | ||||
| 8.1 | How many complaints are received by ICANN related to confusion or misunderstanding of TLD functions | ICANN | ||
| 8.2 | How many registries are subject to Compliance activity based on reported breaches of RAA | ICANN | ||
| 8.3 | How many registries have been the subject of complaints related to their Public Interest Commitments (PICs) | ICANN | ||
| 8.4 | How many registries have lost a dispute resolution process related to their PICs | ICANN | ||
Technical issues encountered (including application support) | ||||
| 9.1 | Are end-user software applications capable of implementing all of the new gTLDs; Can browsers and DNS clients in end-user systems resolve all new gTLDs | Audit | All major browsers and operating systems should have versions capable of resolving all new gTLDs, including IDNs | |
| 9.2 | Which browsers or other end-user applications require plugins or user-installed enhancements in order to use new gTLDs | Audit | Support should preferably be native rather than as an add-in | |
Notes
- As the scope of ALAC and ICANN itself is global, we anticipate and expect that any metrics to be measured by survey (both the ALAC and GNSO metrics) would need to be globally distributed and multi-lingual
- External sources (such as business intelligence publications) can supplement (and reduce the cost of) customized surveys.
- An automated system could sample random second-level domains to perform tests based on lists of domain names supplied by registries. The witholding of source data for metrics by contracted parties, in order to prevent collection of metrics which may be perceived to reflect upon them negatively, could impact the metrics and prevent ICANN from accurately measuring end-user trust
- Significant growth in alternative methods of accessing Internet services may indicate a corresponding reduction in the relative trust of domain names to perform the same function. When possible, statistics should provide comparison with similar statistics for legacy TLDs.
10 Comments
Carlton Samuels
Refer 3.2. Maybe could edit to read "alledging fraud or misrepresentation based on domain names or traced to domian names"
Could we add a 3.3 to measure outcomes of fraud investigations where the WHOIS positively assisted investigation and identification of the offending party?
Carlton
Evan Leibovitch
Both are done, and 3.3 is added.
Thomas Lowenhaupt
What is timing (i.e., expected completion date) on this effort?
Evan Leibovitch
The commitment made in the original statement (referred to in the Background) promised a set of At-Large derived metrics by the Beijing meeting.
Thomas Lowenhaupt
I've been thinking about this question as it relates to city-TLDs, trying to come up with quantitative measurements. An article in today's Wall Street Journal touches on the impact such quantitative metrics have had on the operation of the NYC Police Department. This part of the article might have relevance here:
NEW YORK — Police brass in the Bronx were not concerned with whether patrol officers were saving lives or helping people, they were focused on one thing: numbers, said a New York City police officer testifying in a federal challenge to some street stops.
Adhyl Polanco said his superiors told him that he needed 20 summonses, five street stops and one arrest per month. It didn't matter whether the stops were done properly, he said Tuesday.
"They will never question the quality. They will question the quantity," Polanco said.
His testimony, which will continue Wednesday, was one of three department whistleblowers expected to discuss a culture that revolved around numbers and less around actual policing...
See the full article here: http://online.wsj.com/article/AP24799a6f5dbb4552bae288adbc414ba9.html?mod=WSJ_NY_LEFTAPHeadlines.
I don't offer this to imply anything negative about the above (which I'm using as the start for my city-TLD analysis). But mearly to present a reminder about the possible consequence of an over reliance on the quantitative measures.
Best,
Tom
Evan Leibovitch
Hi Thomas,
Is there something in error about the specific metric this document is proposing to be done? Are there measures we can take, in the design of the metrics, to reduce their potential for abuse Given the short deadline, we don' t have much luxury of time to engage in theory. If you have something in mind that we should add or remove from the above document to address your concerns, now is the time to offer it.
One possible conclusion from your comments is to eliminate the "targets" column, as it attempts to impose value judgements on metrics which are themselves objective (and objectively collected). Personally, I'm not that comfortable with the column on "targets", either in the original GNSO target or in this ALAC response. It suggests imposing value judgements on what are supposed to be impartial measurements. And arguably the indications that targets suggest what "should" happen was the cause of domain industry objections to some metrics that were taken out of the GNSO report but re-instated here.
What does everyone else think?
Thomas Lowenhaupt
Evan,
As I said earlier, fundamentally, I see this as an excellent report. Here are my spruce-up suggestions and a few additional thoughts. Keep in mind as you read them that I’m neither a nethead nor bellhead but a cityhead.
For the heading of column #2, "Measure of End-User Trust" I'd suggest using a more generic term such as Benefit, thus "Measure of End-User Benefit." Or perhaps "Measures Contributing to End-User Trust."
Add to the section 1 heading description "Reduce," thus "Reduce End-User Confusion."
Modify 1.1 metric description to: "Frequency end-users succeed in reaching the intended information supplier by direct entry of domain names." (What I'm getting at is the frequency end users intuit that by logic or familiarity they are able to enter a domain name and reach the target. Thus I look out my window and see Rickys Cafe acroos the street, and type RickysCafe.nyc and reach that restaurant.)
And I suppose 1.2 would be the opposite - the frequency of entering an intuitive name and not getting the target, so maybe "Frequency of landing at unintended destinations."
In 1.3, rather than Volume I'd use Frequency, as volume will depend on the size of the TLD. "How often" would seem to be the concern. Also a typo: same not sam.
Similar in 1.4, "Frequency of reaching dead-end domains." (registered but do not resolve)
In 2.1, I'd change to "Relative preference of entering domain names versus using search engines for reaching a site."
When I look at 2.2 I think about broad Internet usage rather than enhancements from individual TLDs. Were you thinking about people that decide to create their organization sites within Facebook or Google+ rather than a website? If so, perhaps the description should be "Growth in number of freestanding websites created in new TLDs vs. those created under hosted services."
In 2.3 on QR codes, I presume they most often resolve to domain names. So is the measure "Frequency QR codes resolve to new TLDs?"
In 2.4 on URL shortening: I suspect those using .barcelona will more frequently use them than .nyc. And this info might be of interest to a data scientist. But the meaning of a better or worse metric eludes. (As Note 4 says, “growth in alternative methods of accessing Internet services may indicate a corresponding reduction in the relative trust of domain names to perform the same function” but with the instance of .nyc vs. .barcelona, I’m uncertain.)
In 2.5 “Growth in registrations in ccTLDs relative to gTLDs” I’d see this as “Growth in registrations in city-TLDs relative to gTLDs.” and I see city-TLDs as a separate class.
On 3.1, “Number of consumer complaints to government agencies related to confusing or misleading domain names” the Anticipated difficulties column says “ICANN ought to have such relationships in place anyway,” and this ought should be a should or a must. And working through the At Large Structures in city’s with TLDs to establish these standards should be a requirement.
I’d combine 3.1 and 3.2 into 3.1 “Number of complaints to consumer, police, and other local agencies alleging fraud or misrepresentation based on – or traced to – domain names
And I’d add a 3.2 “Number of fraud investigations begun by consumer, police and other local agencies based on complaints received.”
3.3 Number of convictions...
Renumber current 3.3 as 3.4.
I’d have a 4.2b saying “How many gTLD registries (or maybe city-TLD registries) have allocation policies which provide adequate time periods for local organizations and communities to apply for their traditional names.” Here I am looking for enough time to inform the traditional holder of a name “Rickys Cafe” that the opportunity exists to acquire the name, i.e., RickysCafe.nyc.
More specifically on the city-TLDs, I'd think:
"Percentage of local organizations / communities / individuals switching from gTLDs to city-TLDs." might be a useful metric.
“Is there a local oversight process for the PICs?”
“Does the city have an operational At Large Structure?”
“Does the TLD city have a formal relationship with the At Large Structure?”
“Has the TLD city shared standard setting processes with other TLD cities?”
“Is there a multistakeholder governance process for the TLD in the city?”
“Does the TLD city have transparent search and finding systems for local residents?”
“Does the TLD city have processes to encourage a sustainable reuse of domain names?”
Our .NYC Advisory Board is just getting started and I suspect there will be more to add on the city-specific. As well, I am still moving to connect with other city-TLD applicants. I'll pass that info along to the At Large as it arrives.
Best,
Tom
Evan Leibovitch
Hi Thomas,
I would prefer to generalize the CityTLD comments above so that they are more broadly applicable. Some – such as related to ALSs – are out of scope for this specific set of metrics. I will try to incorporate the spirit of what you are asking for in a way that can be more broadly applicable.
Thomas Lowenhaupt
That sounds like a good approach.
Thanks.
Tom
Alan Greenberg
My comments:
2.1 Any stats for new gTLDs must be related to comparable stats for old TLDs.
2.3, 2.4 Not sure how this is relevant without growth history in past. Twitter increases such usage and does advertising growth, so cannot look at in isolation.
2.5 Are you counting the new IDN ccTLDs as ccTLDs?
4.2 Only makes sense to have those statistics for those TLD that DO have allocation policies. For those, it is important to know if they are readily available.
4.3 Similar to 4.2 only makes sense if a TLD does have sub-domain owner/operators.
6.1 Specify if you mean that a browser must have a version or versions that supports all TLDs except those referenced in 6.2
6.2 A given TLD might well be designed to be used with a specific app instead of a browser. Example could be an e-mail TLD, one one tailored to some specific application. Why penalize those who have a different business model?