Nieuwe asynchrone google analytics code in externe js file

[Verwijderd]

De nieuwe Asynchrone Google Analytics code moet in de head komen te staan van de pagina. Omdat het in de head staat zou het voor mij handig zijn om het als .js aan te roepen. Weet iemand of het mogelijk is om de nieuwe code als .js aan te roepen in de head? Ik kon er helaas weinig over vinden.

[Bosmonster]

Script in een js zetten en die in je head? Wat is het probleem?

Overigens wil je dit niet ivm caching. Dit is juist iets dat je gewoon in de pagina wil hebben.

[ Voor 44% gewijzigd door Bosmonster op 07-07-2010 10:23 ]

[Verwijderd]

Het zou namelijk heel handig uitkomen om het zo op te lossen ivm de opbouw van de sites op mn werk.

Maar wat is dan precies het probleem met de cache?

[André]

Verwijderd schreef op woensdag 07 juli 2010 @ 09:40:
De nieuwe Asynchrone Google Analytics code moet in de head komen te staan van de pagina. Omdat het in de head staat zou het voor mij handig zijn om het als .js aan te roepen. Weet iemand of het mogelijk is om de nieuwe code als .js aan te roepen in de head? Ik kon er helaas weinig over vinden.

Het script bestaat uit 2 gedeeltes. Eerst de meting die in een array gestopt wordt. En daarna wordt de daadwerkelijke ga.js asynchroon ingeladen.

Het 1e gedeelte kan niet in een externe js, daardoor zal de meting niet lekker lopen. Het 2de gedeelte staat al extern, of wil je daar ook iets anders mee?

Wat is de reden dat het extern moet?

/edit:
Overigens hoeft het helemaal niet in de head te staan, het mag ook in de body

[ Voor 6% gewijzigd door André op 07-07-2010 10:54 ]

[Verwijderd]

Andre, bedankt voor je reactie. Sites hier zijn niet opgebouwd vanuit 1 template. Ik moet op meerdere plekken de code plaatsen. Dus leek het mij handig om het in .js te plaatsen. Maar zoals jij omschrijft is dat dus geen optie.

Ik vind het vreemd dat Google het wel aangeeft dat het in de head moet. Maar volgens jouw kan het dus ook gewoon achter de body tag staan.

[André]

Verwijderd schreef op woensdag 07 juli 2010 @ 11:00:

Ik vind het vreemd dat Google het wel aangeeft dat het in de head moet. Maar volgens jouw kan het dus ook gewoon achter de body tag staan.

Google geeft de meest optimale plek aan waar die code het beste tot zijn recht komt. Dat is dus aan het einde van de head. Maar dat wil niet zeggen dat hij ook prima onder of bovenin de body kan

[Bosmonster]

André schreef op woensdag 07 juli 2010 @ 10:50:
[...]

Het script bestaat uit 2 gedeeltes. Eerst de meting die in een array gestopt wordt. En daarna wordt de daadwerkelijke ga.js asynchroon ingeladen.

De standaard meting snippet kan toch an sich prima in een extern bestand?

http://code.google.com/ap...acking/asyncTracking.html

Niet dat ik het ooit geprobeerd heb, maar ik zie hier niet direct een issue mee.

[André]

Bosmonster schreef op woensdag 07 juli 2010 @ 11:15:
[...]


De standaard meting snippet kan toch an sich prima in een extern bestand?

http://code.google.com/ap...acking/asyncTracking.html

Niet dat ik het ooit geprobeerd heb, maar ik zie hier niet direct een issue mee.

Nee, als je dat doet krijg je rare metingen. Ik kan het niet helemaal verklaren maar het heeft volgens mij met proxies, caching en cookies te maken. Bij de meeste meetscripts wordt geadviseerd het niet extern te zetten.

/edit:
Bij nader inzien: het asynchrone meetscript zou inderdaad extern moeten kunnen. Je moet dat script dan ook asynchroon inladen om niet dat voordeel te verliezen. En caching/cookies/proxies spelen hier geen rol. Toch heb ik situaties gezien waar het inline halen van een extern script de oplossing was voor een meetprobleem.

[ Voor 22% gewijzigd door André op 07-07-2010 11:28 ]

[Verwijderd]

Je zou de "meet-array" wel extern kunnen plaatsen volgens mij, als je in je script-tag forceert dat het bestand elke keer opnieuw wordt geladen, bijvoorbeeld zo:

code:

<script type="text/javascript" src="/analytics.js?t=<?=time()?>"></script>

Doordat je de tijd in seconden toevoegt aan de locatie van het script, is deze elke keer iets anders en wordt deze keer op keer opnieuw opgevraagd van de server. Wel is het zo dat je hiermee geen caching-voordeel hebt (in plaats van extra code in de HTML heb je nu een extra .js-bestand dat opgehaald moet worden) en ook zou de vertraging die het opvragen kost voor problemen kunnen zorgen.

Wat André zegt, het is beter om je aan het advies te houden dat Google aangeeft om meetproblemen te voorkomen.

[Sebazzz]

Wat André zegt, het is beter om je aan het advies te houden dat Google aangeeft om meetproblemen te voorkomen.

Als het anders had gekund had Google dat echt wel uitgevonden

[Tharulerz]

Mogelijk probleem: als 1% van de bezoekers die js niet laadt (door server load, iets fout aan client kant, etc), dan heb je 1% van de bezoekers die je niet registreert maar die toch je html hebben gezien en gedownload.

[Sebazzz]

Tsja, dat probleem is net zo 'groot' als de 2% die alles van Analytics blokkeren.

[André]

Of de 3% die uberhaupt javascript uit hebben staan. Ik meet met GA ook de mensen zonder javascript, en dat zijn er meer dan je denkt.

[Tharulerz]

Sebazzz schreef op woensdag 07 juli 2010 @ 22:12:
Tsja, dat probleem is net zo 'groot' als de 2% die alles van Analytics blokkeren.

Maar die heb je bij beide situaties?

Het klinkt als een stom voorbeeld, maar sommige mensen konden zich er niets bij voorstellen waarom het een verschil kon maken. Negeer het dan ipv er een stomme toespeling op te maken.