Dersom du plasserer en standard Google Analytics sporingskode på et domene med æøå, vil ikke sporingskoden «trigges» dersom brukeren kommer fra en rekke vanlige nettlesere, for eksempel Internet Explorer 7.0 og oppover, samt Firefox 1.0.8 og oppover. Basert på interne målinger, gjelder dette over 80% av alle norske internettbrukere, altså en så stor del av dine besøkende. Rapportene blir da mer eller mindre verdiløse uten tall fra disse besøkende.

Derimot finnes det en enkel og effektiv måte å bøte på dette problemet, nemlig ved bruk av den svært så nyttige funksjonen _setDomainName. _setDomainName brukes pinsipielt til å spore flere domener/subdomener som ett, og for å unngå at en bruker som veksler mellom domener/subdomener ikke skal telles som flere besøk. Det som i realiteten skjer, er at man overskriver hvilket domene man faktisk er på, og lurer Analytics til å tro at man beveger seg på et gitt domene. Vi kan da få Analytics til å overse æøå i domenet, og si at domenet faktisk heter noe annet.

Man kan imidlertid ikke sette et hvilket som helst domenenavn, man må bruke såkalt punycode-ekvivalitenten av domenet. Fremgangsmåten vil bli som følger, dersom vi tar utgangspunkt i domenet jørgen.no

1. Bruk et konverteringsverktøy for punycode, og konverter URLen du ønsker. jørgen.no i punycode er xn--jrgen-vua.no.
2. Opprett en Analytics sporingskode og legg til følgende linje: pageTracker._setDomainName(«.xn--jrgen-vua.no»); (linjen legges under linjen med UA-kode i Analytics-sporingskoden). Husk å bytte ut xn--jrgen-vua.no med ditt eget domenenavn i Punycode.
3. Installer sporingskoden i sin helhet på alle aktuelle sider på ditt nettsted.

Dette er kanskje ikke den mest elegante løsningen, men foreløpige tester ser ut til å vise riktige tall. Videre er det en god workaround frem til Google klarer å bygge inn en mer robust løsning i selve datainnsamlingen til Analytics.

Forøvrig er det en rekke andre utfordringer med bruk av æøå i underkategorier/URIer, noe Kuttisme har vært inne på tidligere. Dette gjelder imidlertid et litt annet tema, og løses ved hjelp av et search and replace filter.

Gøøgle Ænålytics på Metronet

Løsningen fant vi ved å undersøke nærmere hvordan såkalt IDN egentlig fungerer. Det viser seg at domenenavn som inneholder «rare tegn» behandles forskjellig fra vanlige domenenavn.

Når du taster feks metronet.no i nettleseren din, så må domenenavnet metronet.no oversettes til en såkalt IP adresse som datamaskiner bruker for å identifisere seg på nettverket. Dette skjer ved at maskinen din spør en DNS Hvilken IP har metronet.no?, DNSen svarer da 91.207.158.135 og nettleseren henter opp siden den finner på den gitte IP adressen.

Nå er det slik at DNSer kun forstår domenenavn som inneholder tegnene a-z, 0-9 og -, gitt dette hvordan klarer da nettlesere og finne IP adressen til jørgen.no?

Det viser seg at nettleseren oversetter domenenavn med ugyldige tegn til såkalt ACE format før den sender forespørsel til DNSen. Eksempelvis blir jørgen.no oversatt til xn--jrgen-vua.no, som er ACE formatet, og så spør den DNSen Hvilken IP har xn--jrgen-vua.no?.

Dette bringer oss tilbake til WordPress. Når nettleseren ber om å få innhold fra WP så skjer det ved at den kontakter WP installasjonen på IP adressen den fikk fra DNSen og spør ‘kan jeg få innholdet til xn--jrgn-vua.no, siden vi hadde stilt in WP med jørgen.no som domene navn svarer WP Jeg har ikke noe innhold til jørgen.no.

WP er altså ikke smart nok til å skjønne at den må oversette domenenavn med internasjonale tegn til ACE format, svaret er derfor å stille inn WP med ACE formatert domenenavn.

Domenenavn med norske tegn og WordPress på Metronet