About me
I live in Lund and work, well, at probably the best company in the world
Tag Cloud
Active Directory
AD
ajax
Android
api
app
Apps
ASP.NET
azure
C#
CAML
Chuvash
Client Object Model
codeplex
console
csom
csr
css
css3
database
devtools
extension
git
github
google chrome
html
html5
javascript
jQuery
jQuery tmpl
js
jslink
jsom
json
keyboard
keyboard layout
LINQ
linux
localization
log
masterpage
ModalDialog
monitoring
office365
onet.xml
Performance
Powershel
PowerShell
raspberrypi
REST
rättigheter
script
Serverinstallation
Sharepoint
SharePoint 2010
sharepoint 2013
sharepoint2013
sharepoint apps
sharepoint online
SP.js
spapp
SPField
SPList
SPListItem
spo
SPWeb
subversion
tips
ubuntu
VHD
Visual Studio
webpart
webparts
windows
xml
Top posts
Certiffications


Blog Stats
- 601,819 hits
Recent Comments
Blogs I Follow
- Daniel Chronlund Cloud Tech Blog
- Вула Чăвашла
- Discovering SharePoint
- Bram de Jager - Architect, Speaker, Author
- SharePoint Dev Lab
- GUID(E) To SharePoint
- SharePoint Dragons
- Mai Omar Desouki
- Cameron Dwyer
- paul.tavares
- Share SharePoint Points !
- Simple Stuffs
- Jimmy Janlén "Den Scrummande Konsulten"
- Aryan Nava
- SPJoel
- SharePointRyan
- SharePoint 2020
- Aharoni in Unicode
- ... And All That JS
- blksthl
I wouldn’t use it simply because SharePoint 2010 include extensive tracking, reporting and analytics features of its own that can also track internal data that google analytics would be unaware of. Google analytics also doesn’t work exceptionally well on secured internal traffic.
If you have to use google analytics, you could wrap it into a user control, just be aware that if you disable the feature used to deploy the web part, you will need to gracefully handle disabling it. Knowles implementation is less than ideal because it doesn’t allow for centralized, granular administration. Here’s some rules for that type of implementation:
-Create a web part or user control to deploy the script with optional parameters configured on the web level, preferably per site
-Embed the control into the master page
-Deploy the web part in the same solution and feature as the master page you’re using; pseudo-stapling
-Create an application page to customize two property bag properties representing the tracking account qualifiers and a bool “enabled property” that administrators can configure (i.e. bool isEnabled = Web.AllProperties[“GoogleAnalyticsIsEnabled”];). It’s also a good idea to make this page site collection level so you can manage all subwebs at once and provide a simple interface for doing so. This allows you to individually choose which sites google analytics does and does not track on a granular basis from within SharePoint.
(Note: if GA loses track of the user as they jump around the site collection and enter an untracked site, it may register false entries, dual hits, or incorrect paths in its logic. Using SharePoint statistics avoids this)
-Create a feature receiver that automatically handles installing and retracting the property bag properties when the feature is retracted.
Whilst SharePoint Standard 2010 provides analytics, we found it very high level. Our Internal Communications team was constantly complaining there was no in-page analytics, the statistics were too generic and there was no geographical information, no meaningful dashboards and generally a very unappealing look and feel. Google Analytics provides low level comprehensive reporting couple with engaging dashboards, you would probably page vast amounts of money for an equivalent off the shelf solution.
Btw, check this article: http://www.harepoint.com/Articles/GoogleAnalyticsSharePoint.aspx
WBR, Aleksandr
Thank you for the link.