Share
Som mange nettsteder bruker vi Google Analytics til å spore data om våre besøkende og hva de gjør på våre nettsteder. Tuts + er imidlertid en rettferdig bit større enn mange av disse nettstedene, og i vår størrelse løper vi inn i noen problemer ved å bruke den. Her er hva jeg har lært om å jobbe med Google Analytics i målestokk.
Google Analytics returnerer bare 500 000 rader med data for enhver forespørsel du sender den (med noen få unntak). Hvis du gjør en forespørsel der resultatet dekker mer enn denne mengden data, tar Google Analytics en prøve av 500.000 rader, og multipliser det opp etter behov.
Hvis du for eksempel har fem millioner besøkende i september, og du spør Google Analytics om en rapport om hvor de besøkende kom fra hele måneden, velger Google Analytics 10% av dataene dine om september-besøkende, finne ut hvor de 10% av de besøkende kom fra, og multipliser disse tallene med 10 for å generere rapporten den gir deg.
Denne typen ekstrapolering er en vanlig statistisk teknikk, og en rimelig måte for Google å kutte ned på behandlingstid. Dessverre, i min erfaring, kan de resulterende rapportene være misvisende, eller bare feil.
Løsningen, for å få nøyaktige data, er å be om flere skiver data over kortere datoperioder, og deretter sy dem sammen igjen. Fortsetter med eksempelet ovenfor: Hvis du har fem millioner besøkende i september, har du rundt 500.000 besøkende hver tredje dag. Dette betyr at hvis du foretar ti spørringer, og hver ber om data på tre dager, vil hver tredagers rapport Google Analytics gi deg fullstendig unsampled. Sy dem sammen igjen, og du har usamplet data for hele måneden.
Google Analytics-webgrensesnittet er kraftig og flott for å utforske dataene dine, få en grov ide om tallene, eller raskt dele en rapport med kolleger. Ved å kutte dataene til kortere tidsperioder, laste det ned og sette det sammen igjen via webgrensesnittet, er det en tidkrevende, feilaktig sår i nakken..
Det er mye lettere å gjøre dette via Core Reporting API. Query Explorer er en ganske vennlig måte å komme i gang med å bygge opp spørsmål, og det er greit å gå derfra for å fange data ved hjelp av Python, eller et annet programmeringsspråk.
Siden du må steke disse delene av data sammen igjen lokalt, kan du også lagre dem på et sentralt sted hvor du kan spørre og bruke dem senere. Jeg bruker en klon av Tuts + backend-databasen, endret for å legge til flere tabeller for Google Analytics-data; Dette betyr at jeg kan koble trafikkdataene til den aktuelle artikkelen, i stedet for URL-adressen (som er viktig, ettersom våre kanoniske nettadresser har endret seg gjennom årene).
Det betyr også at jeg kan kjøre komplekse spørsmål som "vise meg de 100 innleggene med de fleste sidevisninger i løpet av den siste måneden innenfor et bestemt sett av kategorier", eller "få det mest populære innlegget fra hver instruktør som har publisert minst fem innlegg" . Det er vanskelig å gjøre dette med Google Analytics alene, siden det ikke forstår våre begreper "kategori" eller "instruktør". En annen fordel å ha alt i en enkelt database er at det er mye lettere å få det inn i eksterne analyse- og visualiseringsverktøy som Tableau.
I Google Analytics har hver rapporteringsvisning en grense på 10 000 API-forespørsler per dag: det er maksimalt antall ganger jeg kan pinge den for å få noen data via APIen. Vi har 18 000 innlegg over Tuts +, så det kan ta to dager å få informasjon for hver enkelt separat fra en enkelt visning.
Ah, men visninger bor i en eiendom, og hver eiendom har en total grense på 50.000 API-forespørsler. Så, vi har vår Tuts + eiendom satt opp med et sett med visninger som inneholder all trafikkinformasjon for et enkelt emne (som kode, webdesign og virksomhet) og en ekstra visning som inneholder all trafikkinformasjon for Tuts + som helhet. På denne måten kan vi spørre Kodevisning når vi ønsker data om Kodeposter, Webdesign-visningen når vi ønsker data om Webdesign-innlegg, og så videre, og utnytter maksimalt 50 000 spørringsgrensen i stedet for å være begrenset til 10 000.
For dette interaktive kartet som viser hvor leserne til våre oversatte opplæringsprogrammer kom fra, måtte jeg laste ned sidevisninger per landsstatistikk for ca 250 innlegg, alt fra helt nytt til seks måneder gammelt (i gjennomsnitt omtrent 100 dager), i dag lang skiver - det er totalt 25.000 dager av data.
Jeg kunne lage 25 000 spørringer til Google Analytics, men jeg vet at:
Så jeg gjorde en enkelt spørring til Google Analytics for hver av de 250 innleggene, og ba om de samlede sidevisninger for hver dag innlegget hadde vært online. Deretter gjorde jeg en ny spørring til Google Analytics for hvert innlegg og for hver dag at innlegget hadde mer enn null sidevisninger, og ber om sidevisninger per land. Dette reduserte massivt antall spørringer jeg måtte gjøre samlet, noe som spedte opp ting og mente at jeg ikke brant gjennom så mye av Google Analytics API-kvoten.
Jeg har funnet ut at det vanligvis tar fem eller flere sekunder for Google Analytics å returnere resultatet av en enkelt spørring. Dette betyr at det å ta en forespørsel for hver av våre 18 000 + innlegg, etter hverandre, tar over 24 timer å behandle! Det er derfor jeg gjør dem parallelt i stedet.
Med Google Analytics kan du sende opptil ti API-forespørsler per sekund, slik at du kan sende inn 50 forespørsler innen de fem sekunder det tar for å behandle den første. Dette betyr at store køer med forespørsler kan behandles 50 ganger raskere enn hvis du har gjort forespørslene i seriell, noe som gjør at en døgn venter på en lunsjpause vente.
Hvis (eller, når når) koden din krasjer, din internettforbindelse faller, bruker du all Google Analytics API-tillatelse, eller noe annet går galt 90% av veien ved å laste ned et stort sett med data, vil du ikke må starte omlastingsprosessen.
Pass på at du lagrer dataene til disken når du laster ned den (i stedet for bare å lagre den i minnet), og sørg for at du kan hoppe over til hvor du dro av når du starter nedlastingen på nytt.
Jeg pleide å bare skrive et helt nytt spesialbygget sett med kode når jeg ønsket å be om data som jeg ikke hadde bedt om før, kopiert og limt inn fra tidligere skript, men dette var begrensende og ufleksibel.
Til slutt kodet jeg en mer generell løsning som tok hensyn til alle leksjonene jeg hadde lært over, og det kunne lese eksterne definisjonsfiler som spesifiserte dataene jeg ønsket å laste ned, som dette eksempelet for nedlasting av sidevisningsdata for alle innleggene våre:
"SQL": "SELECT ID, slug, section, earliest_date_requiring_data Fra innlegg ORDER BY early_date_requiring_data ASC", "Dimensjoner": "ga: dato", "Metrics": "ga: sidevisninger", "Filters": "ga: pagePath = "^ / (artikler | opplæringsprogrammer) / slug", "Slicing": "Hele", "Vis": "section", "OutputTemplate": "id, ga: date : pageviews "," OutputFile ":" all_post_pageviews.csv "," StartDate ":" tidligste_date_requiring_data "," EndDate ":" LastSunday ",
Ok, disse filene er ikke akkurat menneskelige lesbare og brukervennlige, men de er ganske enkle å forstå og skape hvis du har et godt grep om Google Analytics API og måten vår database er strukturert på. Det betyr at jeg kan lage nye sett med instruksjoner uten å berøre den underliggende koden som kjører dem, og jeg kan forbedre den underliggende koden uten å bekymre deg for å slå opp noen av de vanlige data nedlastingene.
Mange av disse tipsene føles som om de beskriver sunn fornuft tilnærming når jeg ser på dem nå, og jeg kan nesten ikke tro at jeg ikke håndterer dataoverføringene på denne måten hele tiden. Men det er tatt mye forsøk og feil og frustrasjon for å nå denne prosessen som virker for oss; Jeg håper at ved å dele den, kan jeg hjelpe noen andre omgå det.
Accentsconagua