This workspace will be used by the ALAC New gTLD Metrics Task Force for its report. 


Second Draft


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.


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.


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


Anticipated Difficulties in
Obtaining and/or Reporting

3-year target

End-User Confusion
4.1Frequency of success in reaching the intended information supplier through direct entry of domain namesSurvey of end-users; SEO research

Note 1 

Neutral or increase
4.2Frequency of landing at unintended destinationsSurvey of end users, SEO analyticsNote 1
Selective sampling of analytics may help determine the success of typo-squatting or other unintended destinations
Neutral or decrease
4.3Frequency of redundant or defensive domains (ie, multiple domains pointing to the same destination)Survey of registrantsNote 2Neutral or decrease
4.4Frequency of dead-end domains (registered but do not resolve)Registry data + automated samplingNote 3Proportion relative to total domains should decrease
4.5Numbers of complaints received by ICANN regarding improper use of domainsICANNSupplements 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.1Relative preference of explicit use of domain names versus search engines for end-user general Internet useSurvey of end users; SEO analyticsNote 1Note 4
5.2Growth in use of hosted pages for organizations (such as Facebook or Google+)Market researchIe, ComScoreNote 4
5.3Growth in use of QR codesMarket researchie, ScanLifeNote 4
5.4Growth in use of URL shortening servicesMarket research Note 4
5.5Growth in registrations in ccTLDs relative to gTLDsRegistry data Note 3A significant increase in the use of ccTLDs could mean reduced trust in generic TLDs.
5.6Growth of Software Defined Networking (SDN) as alternative to the DNSMarket research Note 4
Complaints to, and action taken by, police, regulatory agencies and advocacy groups
6.1Number of consumer complaints to government agencies related to confusing or misleading domain namesGovernment regulatory agenciesEstablishing 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 representativesProportion relative to total domains should decrease
6.2Number of complaints to police agencies alleging fraud or misrepresentation based on – or traced to – domain namesLaw enforcement agenciesICANN already has existing communications with LEA groups. Supplements GNSO metrics 1.15 and 1.16 by adding complaints as well as remedial action 
6.3Number of fraud investigations where WHOIS information positively assisted investigation and identification of offending partiesLaw enforcement agencies  
Transparency of contact information and domain-allocation policies for all gTLDs
7.1How many gTLD registries have privacy policies which are clearly and easily accessible by end usersRegistry websitesManual auditingAs many as possible

How many gTLD registries have allocation policies which are clearly and easily accessible by end users

Registry websitesManual auditingAs many as possible
7.3How many registries disclose end-user information regarding their codes of conduct for sub-domain owner/operatorsRegistry websitesManual auditingAs many as possible
Accuracy of new gTLD promotion to end users
8.1How many complaints are received by ICANN related to confusion or misunderstanding of TLD functionsICANN  
8.2How many registries are subject to Compliance activity based on reported breaches of RAAICANN  
 8.3How many registries have been the subject of complaints related to their Public Interest Commitments (PICs) ICANN  
 8.4How many registries have lost a dispute resolution process related to their PICs ICANN  
Technical issues encountered (including application support)
9.1Are end-user software applications capable of implementing all of the new gTLDs; Can browsers and DNS clients in end-user systems resolve all new gTLDsAudit All major browsers and operating systems should have versions capable of resolving all new gTLDs, including IDNs
9.2Which browsers or other end-user applications require plugins or user-installed enhancements in order to use new gTLDsAudit Support should preferably be native rather than as an add-in


  1. 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
  2. External sources (such as business intelligence publications) can supplement (and reduce the cost of) customized surveys.
  3. 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
  4. 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.


  • No labels


  1. 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? 



    1. Both are done, and 3.3 is added.

  2. What is timing (i.e., expected completion date) on this effort?

    1. The commitment made in the original statement (referred to in the Background) promised a set of At-Large derived metrics by the Beijing meeting.

  3. 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:

    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. 



    1. 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?

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

    1. 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."

    2. Add to the section 1 heading description "Reduce," thus "Reduce End-User Confusion."

    3. 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 and reach that restaurant.)

    4. 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."

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

    6. Similar in 1.4, "Frequency of reaching dead-end domains." (registered but do not resolve)

    7. In 2.1, I'd change to "Relative preference of entering domain names versus using search engines for reaching a site."

    8. 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."

    9. 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?"

    10. 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.)

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

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

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

    14. And I’d add a 3.2 “Number of fraud investigations begun by consumer, police and other local agencies based on complaints received.”

    15. 3.3 Number of convictions...

    16. Renumber current 3.3 as 3.4.

    17. 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.,

    More specifically on the city-TLDs, I'd think:

    1. "Percentage of local organizations / communities / individuals switching from gTLDs to city-TLDs." might be a useful metric.

    2. “Is there a local oversight process for the PICs?”

    3. “Does the city have an operational At Large Structure?”

    4. “Does the TLD city have a formal relationship with the At Large Structure?”

    5. “Has the TLD city shared standard setting processes with other TLD cities?”

    6. “Is there a multistakeholder governance process for the TLD in the city?”

    7. “Does the TLD city have transparent search and finding systems for local residents?”

    8. “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.



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

  5. That sounds like a good approach.



  6. 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?