Slik kan nettmålingene gjøres

Arbeidsgruppa som har jobbet med nettmålinger sender i dag, mandag 7.12.98, ut et høringsnotat på oppfordring fra allmøtet arrangert for to uker siden. digi.no offentliggjør høringsnotatet i sin helhet nedenunder.

Høringsnotatet er også vedlagt som en riktekst-fil, se:


Høringsnotat
Felles nettmålinger for norske nettsteder

0.1 Innholdsoversikt
1. Innledning
2. Kravspesifikasjon
3. Anbefaling av leverandør av teknisk løsning
4. Innspill i forbindelse med valg av institutt og løsning i forbindelse med Internettundersøkelsen
5. Finansiering og organisering

1 Innledning

1.1 Om arbeidsgruppen, mandat og arbeidsform

Siden våren 1998 har en arbeidsgruppe nedsatt av et allmøte arrangert på vårparten 1998 arbeidet med å utarbeide et opplegg for å få en felles målestandard for rangering av trafikk på norske nettsteder.

Arbeidsgruppen, initiert av Norske Avisers Landsforbund (NAL), har bestått av representanter for ledende internettaktører på innholdssiden i Norge samt aktører fra reklamebransjen.

Leder av arbeidsgruppen har vært Niels Røine, i utgangspunktet ansatt i VG, dernest Schibsted, nå Scandinavia Online. Sekretær var inntil oktober Lasse Gimnes, tidligere Scandinavia Online.

Øvrige medlemmer har vært Bjørn Hauge, Annonsørforbundet, Jan Amundsen, Aperitif (representant for fagpressen), Arne-Inge Christophersen, Mediacom (representantn for formidlerne), Knut Ivar Skeid, adm. dir. i Nettavisen, Per Enger, Net2 (representant for kringkastingsorganisasjoner), Arve Stølann, Dagens Telecom senere IT-avisen, Stig Frode Opsvik, Bergens Arbeiderblad (representerer A-pressen), Rolf Brandrud, NRK (representerer kringkastingsorganisasjoner), samt Pål Leveraas, digi.no/Internett Kanal 1 AS.

Utgangspunktet for arbeidet var et ønske om et troverdig rapporteringssystem hvor man på en felles standardisert måte kan sammenligne trafikken på norske nettsteder, med henblikk på antall sidevisninger og antall individuelle besøkende.

Den 23. november 1998 fremla gruppen sine foreløpige anbefalinger for et nytt allmøte. Anbefalingene skisserte

- Teknisk løsning
- Valg av leverandør av teknisk løsning
- Verifisering og verifiseringsmetodikk
- Videre prosedyre for valg av leverandør av verifisering
- Organisering av juridisk instans som kan ivareta felles interesser
Allmøtet ba gruppen lage et høringsnotat og så snart som mulig sende dette notatet ut til berørte parter.

1.2 Høringsinstanser

Høringsnotatet vil i første omgang bli sendt til, foruten utvalgets egne medlemmer, blant andre følgende aktører:
- Norske Avisers Landsforbund
- VG
- Dagbladet
- IDG Communications Norge AS
- Dagens Næringsliv
- Hjemmenett
- Hjemmet-Mortensen
- Norsk Journalistlag
- Hegnar Online

Utsendelsen vil bli gjort via elektronisk post, og eventuelt ved publisering på relevante steder på web.

Utvalget oppfordrer mottakere av dette dokumentet til å videresende det til andre som vil kunne ha innspill og tilbakemeldinger til utvalgets arbeid.

Utvalget ønsker tilbakemeldinger til mail-adressen paulus@digi.no innen 21. desember 1998.

2 Kravspesifikasjon
Kravspesifikasjonen er med visse redigeringsunntak identisk med den som ble sendt ut til aktuelle tekniske leverandører.

Utvikling av system for måling av trafikk på norske nettsteder

2.0 Innholdsoversikt

  • Innledning
  • Beskrivelse av ønsket løsning
  • Kravspekk server(e)
  • Kravspekk server software
  • Kravspekk rapportering
  • Kravspekk verifisering
  • Frister

2.1 Innledning

En gruppe norske internettaktører ønsker samlet å utvikle et system for sammenlignende målinger av trafikk på respektive nettsteder.

Idéen er å sette opp et regelverk hvor alle sider som skal telles refererer en (senere flere) grafikk-fil(er) (gif) som hentes fra en sentral server eller server-park.

Ved hjelp av loggen fra den sentrale serveren, genereres rapporter for alle nettsteder samlet, samt for hvert enkelt nettsted.

Gruppen ønsker å sette løsningen ut på anbud, og ber med dette om tilbud på:

  • Utvikling av systemet
  • Drift av systemet, inkludert verifisering

2.2 Beskrivelse av ønsket løsning

Systemet går ut på at alle sider som skal telles inneholder et grafikk-element (en gif) som hentes fra en ekstern webserver. Dette gjør det mulig å få ekstern verifikasjon av tallene.

Grafikk-elementet utstyres med instruksjoner til evt. cachende proxy-servere om at det ikke skal caches. Man vil dermed få telt de oppslagene man normalt mister pga. proxyer. Siden grafikk-elementet normalt vil være en meget liten del av en webside og resten av siden caches på vanlig måte vil dette ikke øke linjebelastningene nevneverdig.

Ved utleveringen av gifen settes en cookie med en unik id hvis ikke denne er satt på forhånd. Vha. denne id-en kan antall unike brukere og antall brukersesjoner måles med meget stor nøyaktighet. Denne cookien vil bare sendes tilbake til teller-webserverne (ikke til det aktuelle nettstedet) og skal ikke kunne kobles til personopplysninger.

Systemet skal utvikles slik at muligheten for manipulering er minimal.

Inngrepene hos hvert enkelt nettsted skal være minimale. Det som må endres er at gifen må inkorporeres på websidene som skal telles.

Det skal ikke være noen sikkerhetsrisiko ved å være med. Selv om det skulle være innbrudd på telle-webserveren vil dette ikke kunne føre til økt fare for innbrudd på nettstedene som er med.

2.3 Kravspekk server(e)

Systemet skal kjøres på en dokumentert stabil plattform. Med dette menes en plattform som er testet og dokumentert stabil i et miljø hvor det kommer titalls millioner forespørsler daglig.

Antall maskiner som bør kjøres avhenger av hvilken redundans man ønsker seg. Et forslag som vil gi relativt god redundans er:

- Webservere 2-4
- Kværnemaskiner 2-3
- Utleveringsmaskin 1

Serverene skal til enhver tid kunne levere ut giffen på under to sekunder forutsatt at det er tilstrekkelig linjekapasitet mellom server og bruker.

Serverene skal kunne levere ut minimum 250 giffer pr. sekund.

Det skal til enhver tid være ledig linjekapasitet mellom server og sentrale knutepunkt på internettet i Norge (NIX).

Serveren skal være tilgjengelig minimum 99% av tiden.


Vi antar at man bør sette opp systemet basert på Round Robin mekanismer. Dvs at når det spørres etter giffen vil spørringene bli fordelt jevnt utover flere maskiner (ill.1).

ill 1:
|
|(1)
|
-------------
| Round Robin |
-------------
/|\
/ | \
/ | \
/ | \
/ | \
----- ----- -----
| (2) | | (3) | | (4) |
----- ----- -----

(1) Spørringer inn
(2) www1.gif.no
(3) www2.gif.no
(4) www3.gif.no

Det er i tillegg ønskelig at Round Robin systemet er såpass logisk at det skjønner hvilke maskiner som virker og hvilke som er døde. På den måten vil man øke redundansen betraktelig.

Ved et slik maskin oppsett vil softwaren på de ulike www-maskinene være likt. Dette medfører at innsetting av nye maskiner er lite ressurs krevende.

Kværnejobben må lages slik at den enkelt kan fordeles på flere like maskiner. Dette gjør også denne delen lite ressurskrevende å skalere opp.

Plasseringen av serverpark er noe av det viktigste for å sikre at dette blir en suksess. Det beste alternativet i dag er nærmest mulig NIX da dette gir best tilgjengelighet for de aller fleste aktørene i Norge i dag.

2.4 Kravspekk server software

Man setter opp en webserver slik at den kan levere ut en gif. Ved utleveringen av denne gifen settes også en cookie med en unik id hvis ikke denne er satt på forhånd.

Man ser for seg at webserveren manipuleres litt:
- Gif'en beholdes i minnet
- Logisk lagring av loggdata
- Logging av portnummer

Informasjon som skal logges er: ip, portnr, referer felt, kl, browser versjon og operativ system, responskode, header fra eventuelle proxyer samt id-en fra cookien.

Håndtering av spesiell problematikk:

a) Proxy; vil ikke påvirke målingene da giffen ikke caches noe sted. Dette skjer fordi det blir satt utløpsdato i headeren på giffen, det blir sendt med direktiver til proxyer om at den ikke skal caches, og den blir kamuflert som et cgi-script. Sistnevnte er fordi "dumme" proxyer ofte bare ser på om URL-en inneholder /cgi-bin/ eller slutter på .cgi
b) Frames; problematikken løses ved at man definerer hvilke sider giffen skal inn på og hvilke den ikke skal settes inn på.
c) Channels og offline-lesning; sider hentet ned via Microsofts channel-teknologi, eller tilsvarende fra andre leverandører, må behandles spesielt: I så stor grad som mulig skal reelle tall for leste sider benyttes; dvs at antall nedlastede sider i channels sammenholdes mot rapport fra browser over faktisk leste sider, neste gang brukeren går onlinne.
d) "Skrudd av bilder"; de som kjører med denne opsjonen logges ikke. På den annen side kan man spørre seg om man er interessert i disse da de heller ikke får sett annonsene som i 98% av tilfellene er et bilde.
e) "Avbrudd under nedlasting" håndteres gjennom et regelverk som sier hvor man skal plassere gif-en. En side anses ikke som lest dersom gif-en ikke er hentet, og ved å plassere gif-en på slutten av hver side, ignoreres sider som avbrytes midt i.
f) Refresh; Dersom refresh benyttes innfører man en relativt stor feilkilde som egentlig er unødvendig. Dette håndteres ved hjelp av alarmer, triggere i logg-kjøringen, samt menneskelig vurdering av hver enkelt alarm.
g) Agenter/spiders: En rekke søkemotorer og andre tjenester har programmer som henter ned sider og analyserer dem. Disse skal ikke telles med. Dette håndteres ved at det vedlikeholdes en liste over kjente agenter og at disse ekskluderes.
h) DNS oppslag caches slik at man sparer tid i det lange løp. Her er det viktig at man tømmer cachen ved et gitt intervall (eks. 1 måned).
i) Alarmer mot unormaliteter: Dersom en maskin fra samme ip henter en side mange ganger tett etter hverandre må man sjekke om det ligger en refresh på siden eller om det er lagt inn flere giffer på en side.

2.5 Rapportering

Rapporteringen tar utgangspunkt i loggen fra serveren(e). Rapportene skal gi oversikt over:

  • Page impressions (vanlige html-side-oppslag)
  • User sessions (hentes fra id-cookie)
  • Visits (hentes fra id-cookie)
  • Browser stat
  • OS stat
  • Demografiske data basert på IP

alt fordelt pr nettsted.

Den generelle utformingen av rapportene forutsettes gjort i samarbeid med valgt leverandør. Utformingen må kunne endres uten stor innsats.

En ønsket videreforedling på sikt er å kunne skille mellom ulike typer sider nedlastet. Dette skal gjøres ved å opprette ulike typer gif-er som plasseres på de ulike kategoriene av sider

Rapporteringen
  • må kunne håndtere innledningvis 15 millioner logg-linjer pr døgn, og disse må behandles i løpet av maksimalt åtte timer, i perioden fra 00:00 til 08:00
  • må kunne skaleres til å håndtere ytterligere trafikk når denne vokser. Det foreligger ikke noen øvre grense
  • skal ha innebygde alarmrutiner som i så stor grad som mulig avslører bevisst eller ubevisst manipulering

Presentasjon
  • Rapportene hentes/presenteres hovedsaklig via web.
  • Excel fil gjøres tilgjengelig
  • Det skal være mulig å skreddersy egne rapporter og spørringer

2.6 Verifisering

Rapportene skal verifiseres og godkjennes av en betrodd tredjepart.

3. Anbefaling av teknisk leverandør til nettmålingssystem
Av Per Sparre Enger og Pål Leveraas

3.1 Innledning

I perioden september-oktober 1998 innhentet nettmålingsgruppen (via Per Sparre Enger og Pål Leveraas) tilbud fra følgende tre leverandører på leveranse av teknisk løsning for måling av trafikk på norske nettsteder:

· Telenor Nextel
· Eunet
· SOL System
Vi forespurte også Telia Norge om å avgi tilbud, men selskapet har ikke respondert.

Leverandørene ble overlevert skisse til kravspesifikasjon som presentert for utvalget tidligere (se vedlegg). Leverandørene ble kontaktet i to runder, hvor siste runde gikk med til å avklare spørsmål, samt forespørre omregning av tilbudet basert på en månedlig nedbetaling.

Vi har vurdert tilbudene utfra følgende kriterier:

· Pris
· Leveringstid
· Antatt kvalitet på løsningen
Nedenfor følger en rask beskrivelse av hvert enkelt tilbud. De komplette tilbudene legges ved denne rapporten. I sammenligningen av tilbudene har vi gitt en karakter for "kvalitet" på en skala fra 1 til 6 hvor 6 er best. Vi gjør oppmerksom på at kvalitetsvurderingen i all hovedsak er basert på saksbehandlernes "magefølelse".

3.2 Telenor Nextel

Nextel har skissert en løsning basert på en hardware-park bestående av tre Unix-baserte Sun Ultra 5 loggservere, to Sun Ultra 4 kvernemaskiner, en Sun Enterprise 250 utleveringsmaskin, et lagringskabinett Sun StorEdge A1000, kapasitet ca 50GB, samt en-to stykk Cisco Load Director for ruting og sikring av trafikk mot systemet.

Nextel foreslår en Apache web-server, hvor det utvikles tilleggsmoduler for logging, kverning og statistikk.

Telenor Nextel har ikke innlevert tilbud om betaling over 18 måneder, men har levert et minstetilbud over 24 måneder. Vi har i regnestykkene i størst mulig grad tatt hensyn til kapitaliseringsfaktoren som er brukt, og har skalert tilbudet slik at det blir sammenlignbart med de andres tilbud fordelt over 18 måneder.

Vi gir Nextels tilbud en kvalitetsrangering på 5, da løsningen synes som svært solid da de kjører på Unix, bruker hardware-kontrollert belastningskontroll samt har en imponerende lagingsløsning.

Leveringstid: 21 uker

Pris: ca 100.000 pr måned

3.3 Eunet

Eunet har skissert en løsning basert på en Windows NT plattform, bestående av tre web-servere, to kverneservere og en rapportserver. Maskinparken baseres på Pentium II 400 MHz maskiner, med 9,1GB disker. Selskapet foreslår en software-plattform på utleveringsserver basert på FreeBSD OS og Apache web-server, men stiller seg åpen i forhold til testing. På kvernemaskinene foreslår de Linux, BeoWulf som OS, og mySQL som databaseløsning.

Vi har skissert to alternative prismodeller fra Eunet; den ene basert på vedlagt tilbud, hvor trafikkbelastningen styres av software; det andre basert på informasjon innhentet muntlig fra Eunet, hvor trafikkbelastningen, i likhet med Nextels løsning, styres av hardware (2 x Ciso Load Director á 60.000 kroner). Dette innebærer at systemprisen reduseres med 65.000 kroner og hardware-prisen vokser med 120.000 kroner.

Vi gir Eunets løsning alternativ 1 karakteren 3 fordi systemet er basert på en mer labil hardware og OS-plattform (Windows NT) enn Unix, og fordi trafikkbelastningen forutsettes styrt gjennom software og det ikke 100% pålitelige DNS (Domain Name System).

Vi forespurte som nevnt muntlig Eunet om muligheten for å styre belastningen gjennom hardware, og gir denne løsningen alternativ 2 karakteren 4, basert på en bedre belastningskontroll, men fremdeles basert på Windows NT.

Leveringstid: 14 uker

Pris: 55-62.000 pr måned

3.4 SOL System

SOL System foreslår en løsning basert på NetGravity. Plattformen er Sun og Unix-basert, med to til fire telleservere (Sun Ultra 1), en utleveringsserver (Sun Sparcstation) og en rapporteringsserver (Sun Ultra 1).

SOL System har levert et tilbud hvis totalpris vil avhenge av en kombinasjon av hvor mange nettesteder som er tilknyttet samt hvor mye trafikk disse genererer. Vi skisserer derfor i sammendraget en minstepris basert på 25 nettsteder som genererer inntil 50 millioner oppslag, og en maksimalpris basert på 75 nettsteder som genererer 50-100 millioner oppslag. Trappetrinnsskalaen går helt opp til 500 millioner oppslag pr måned.

Hva gjelder leveringstid, tar SOL System forbehold om juleferie. Vi har derfor lagt på to uker på de seks ukene som skisseres i tilbudet.

Løsningen er langt mer komplisert enn den rene, enkle løsningen utvalget tidligere har ytret ønske om. Utvalgets ønske om eierskap til løsningen kan heller ikke ivaretas ved bruk av standard kommersiell programvare som skissert her. Vi gir kvalitetskarakteren 2.

Leveringstid: 8 uker

Pris: 41-55.000 pr måned, avhengig av trafikk

3.4 Vår anbefaling

Vi anbefaler valg av Eunet alt 2 som leverandør av dette systemet gitt at de muntlige forsikringene om at en hardware-kontrollert trafikkbelastningenhet kan implementeres til angitt kostnad er korrekt.

4. Innspill i forbindelse med valg av institutt og løsning i forbindelse med Internettundersøkelsen

Av Arne-Inge Christophersen

4.1 Innledning

Vil med dette notat komme med mine betraktninger og innspill i forbindelse med anbefaling og valg av institutt i forbindelse med verifisering og presentasjon av data for Internett.

Etter siste runde i VG's auditorium sitter jeg igjen med en sterk blandet følelse – en god blanding av irritasjon og like mye frustrasjon.

Skjønner alle egentlig nødvendigheten av å ha valide mediadata ?

Hva har vi i dag:

4.2 Statistikk fra egen server

De fleste i dag burde kunne fremskaffe statistikk som viser besøket på egen server. Problemet er bare det at denne statistikken i dag ikke sendes ut de som har forespurt om dette eller som vil ha en eller annen form for nytteverdi av denne. Grunnen til at de "profesjonelle" plannleggings- og innkjøpsenhetene som store annonsører, medie- og reklamebyråer ikke har "presset på" for å få dette kan nok være mange. Rapportene kan være vanskelig å lese. Man kan ikke automatisk sammenligne mellom de ulike nettstedene grunnet forskjellig klassifisering, kategorisering av innhold, ulike tellemåter, ulike definisjoner med mer.

Det nærmeste jeg har sett noen komme med å lage oversikter basert på data fra servere er Kapital Datas statistikker. Når jeg snakker med de ulike nettstedene om denne er veldig mange, om ikke de fleste, negativt innstilt til disse.

4.3 Intervjubaserte og postale undersøkelser

Selv om ovennevnte rent metode-teknisk er stor spennvidde mellom de ulike undersøkelsene vil jeg fremholde at det faktisk finnes et vell av data. Dataene samles kontinuerlig – enkelte institutter rapporterer sågar hver måned. Rent statistisk er basene store nok og dermed valide.

Når man også her går i dybden på tallmateriale - sammenligner trafikk på egne servere, fra annonseadministrasjonssystemene NetGravity og Double Click med tallene fra enten MMI eller Gallup - er man igjen skjønt enige om at de presenterte tallene må være "feil". Svaret og konklusjonen her er gal.

Tallene er valide og på lik linje med tall for radio, ukepresse, fagpresse og kino. For disse mediene snakker vi om milliarder i medieomsetning !

Utfordringen er derfor å finne en metode som bedre kan spore opp bruken av internett. Jeg mener og fastholder at det eneste riktige er å finne frem til en måleform og metode som kan gi oss dette grunnlaget. Med meget stor sannsynlighet vil jeg også konkludere at denne måleformen må være elektronisk og virituell. Med andre ord bør den måle reell trafikk.

Slik jeg har oppfattet arbeidet er det akkurat dette arbeidsgruppen har hatt fokus på og ikke minst funnet, ut ifra hva jeg kan se, eminente og sofistikerte løsninger på.

Måling av de ulike nettstedene. Skaffe og presentere sammenlignbare data som viser trafikken på de ulike nettstedene. Dataene skal kunne gis fortløpende og i det presentasjonsformat som mottaker forespør. For eksempel. Nettavisens totale oppslag tirsdag den 1. desember mellom kl. 12:00 og 15:00. Eller Sol's totale oppslag i uke 44, 45 og 46 1998.

Måling av seksjoner og enkelte sider. Skaffe og presentere sammenlignbare data for ulike seksjoner, for eksempel forside, nyheter, sport, økonomi osv. Samme rapporteringsprinsipp som ovennevnte.

Måling av individbruk. Kunne bryte ovennevnte data ned på "individnivå". Dvs individuelle brukere.

Ut ifra ovennevnte kan vi få frem brutto og netto bruk av nettstedene, deres seksjoner og høyst trolig enkle sider. Denne informasjonen kan definitivt nyttes i både et salgs- og markedsføringsarbeide for de ulike nettstedene, og ikke minst nettstedene samlet ( populære lister i de fleste media) og ikke minst i kunders, medie- og reklamebyråers planlegging og innkjøp.

Nettbrukernes "surfevaner". Det burde jo være muligheter for også å kunne måle hvordan folk surfer. Er det de samme personene som samtidig leser VG og Dagbladets førstesider ?

Slik jeg oppfatter det muliggjør vårt forslag mulighetene for måling av alle 4 ovennevnte punkter. Med dette mener jeg at man er sikret kvantitative data for så vel små som store nettsteder.

4.4 Kvalitative data
Videre må man søke etter kvalitative data som viser hvem disse surferne er, hvilke adferd og holdninger de har til annet mediebruk, produkter, tjenester med mer. Dette er et noe mer komplisert oppgave og jeg ser ikke helt den kostnadseffektive løsningen til å kunne finne frem disse dataene – spesielt ikke på de mindre nettstedene. Vil bare for ordens skyld gjøre oppmerksom på at data for dette finnes i Pc-verktøyene til Norsk Gallup (Forbruker & Media) og Markeds- og Mediainstituttets (MMIMS)

Så til min "anbefaling" og "innstilling" i forbindelse med valg av institutt for verifisering og presentasjon av data.

Først og fremst vil jeg fremholde at jeg ikke har vurdert politiske hensyn til vurdering eller valg av institutt.

Jeg har gjennomgått både Gallups og MMIs forslag. Begge forslagen baserer seg på til dels skreddersydde / tilpassede løsninger – koblet opp mot deres eksisterende verktøy.

Skulle jeg måtte ta et valg ville jeg valgt:

· Gallup på bakgrunn av engasjement og foreløpige investeringer i fagområdet. Gallup viser stor interesse og forståelse. Videre har de kommet opp med bra løsninger. Prisen er dog for høy sammenlignet med MMI.
· MMI foreløpig kun på pris. Deres forslag er meget prisgunstig. Men slik de har presentert løsningen vil "eiendomsretten" være hos MMI.
Dog føler jeg både løsnings- og prismessig det er mer å hente ut av begge. Det burde jo heller ikke være en umulighet at man ga begge muligheten gjennom en periode. Men at instituttene fikk klare oppgaver.

5. Finansiering og organisering

5.1 "Norske Nettsteders Landsforbund"

For å få en felles nettmåling opp og stå er det nødvendig å organisere en juridisk enhet som kan stå som motpart til leverandører og institutter, og som kan stå som eier av målesystemene, metodene og resultatene.

Utvalget har foreslått å etablere en forening – "Norske Nettsteders Landsforbund" – som den organisatoriske enheten som skal håndtere aktiviteter og oppfølgning mot leverandørene. Fordelen ved dette er at man får en – av de ulike nettstedene – uavhengig instans, som dessuten kan ivareta en rekke andre funksjoner som uten tvil vil bli nødvendig å ivareta i tiden fremover. Dette kan være eksempelvis myndighetskontakt, interesse-lobbying i andre fora, ivaretakelse av etiske spilleregler for nettsteder.

Utvalget registrerer en viss skepsis til etablering av en forening, og stiller seg åpne for andre forslag til videre organisering av arbeidet, både hva gjelder etablering og drift.

Vår første oppgave vil imidlertid være å få etablert og igangsatt systemet. Tanken er å finansiere dette ved en kombinasjon av kontingent og en avgift avhengig av trafikken på det enkelte nettsted.

5.2 Overslag – finansieringsbehov

Vi kjenner foreløpig ikke prisen på verifiseringsdelen av systemene. Driften er imidlertid som kjent stipulert til ca. 60.000 kroner pr måned. I tillegg vil man nok måtte regne med noe "manpower", anslagsvis ytterligere 10.000 kroner pr måned i den skisserte 18-månedersperioden.

Følgende innspill fra Knut Ivar Skeid gir et grovt bilde av finansieringsbehovet.

"Jeg skulle beregne pris på deltagelsen i målesystemet. Såvidt jeg forstår, koster selve data-delen 60.000 måneden, mao. 720.000 kroner i året. Det jeg ikke vet, er hva prisen blir på verifiseringen, og alt det andre.

Jeg har jo heller ingen samlet oversikt over hvor mange sidevisninger de forskjellige nettstedene har. Jeg anslår at Nettavisen alene neste år kommer til å ha i området 250-300 millioner visninger. Anslår en at SOL er dobbelt så store som oss, VG er like store som oss, og Dagbladet og Aftenposten samlet er like store som oss og VG, utgjør dette kanskje 1,3 milliarder visninger tilsammen. Tar en så utgangspunkt i at røkla har noen hundre millioner, har vi kanskje et univers på f.eks. 1,7 milliarder visninger blant "medlemmene".

Hvis en videre regner med 20 medlemmer som betaler 5000 kroner året i fastavgift, trenger vi kanskje 900.000 kroner i tillegg. Dette utgjør en variabel avgift på ca. 0,053 øre per vist side. For Nettavisen vil dette anslaget da koste oss 133.000 kroner i året."

Til toppen