I'm currently running Sharepoint 2013 Enterprise and would like to know the following:
Which pages each user has accessed over the last X Days
How much time each user has spent on each page (can't average, I need to know per user)
It is like a Google Analytics, but at a "user" level. Any clues on how to do that?
I searched a lot stackoverflow and found nothing. Maybe I'm using the wrong terminology.
Under the site collection administration "popularity and search report". You can find some of the information.
According to MSDN blog "Due to less than optimal performance running service at scale in large enterprises, web analytics has been discontinued and is not available in SharePoint 2013."
Web analytics was available in 2010.
If allowed you can choose Google analytics, its just java script reference , add it in your default master page
Definitely not web analytics, but user specific usage reporting based on sessions.
Assuming that this is cleared by your legal department (which at least in the EU most likely would not happen), what you need is a simple database with page views (with session info) and each action time stamped.
This would then be reported per user to contain a list of sessions, that each have a list of pages and calculate the time between first and last interaction per session.
Related
I'm reading the PageSpeed Insights documentation and am wondering if anyone knows how Google is determining what is considered a sufficient number of distinct samples per this FAQ:
Why is the real-world Chrome User Experience Report speed data not available for a URL?
Chrome User Experience Report aggregates real-world speed data from opted-in users and requires that a URL must be public (crawlable and indexable) and have sufficient number of distinct samples that provide a representative, anonymized view of performance of the URL.
I'm building a report centered around Core Web Vitals data and realizing some URLs have few data points with CWV timings, and I'm curious exactly how Google is handling these situations. I've been searching through docs and articles, haven't found anything with a specific reference.
The exact threshold is kept secret, so that's why you won't find it documented anywhere. However, as a site owner there are a few things you can do to work around a URL not having sufficient data:
Use the Core Web Vitals report by Search Console, which groups similar pages together, making them more likely to collectively exceed that threshold.
Look at origin-level aggregations in PSI or the CrUX API. These include user experiences from all pages on the origin, so it's much less granular, but it gives you a sense of typical experiences overall.
Instrument your site with your own first-party Core Web Vitals monitoring. web-vitals.js can be integrated with your existing analytics provider to track vitals on all of your pages. If you're integrating with Google Analytics, you can link your data with the Web Vitals Report to see how your site is doing.
Use your site with the Web Vitals extension enabled to see the Core Web Vitals data for your own experience. Your local experiences may not be representative of most users, but this can be a great tool for validating expectations vs reality.
Use lab data as a proxy. For example, lab data from Lighthouse in PSI can tell you how a mobile user on a slow connection might experience your page. This should really only be used as a last resort when no other field data is available.
I'm the IT Manager at a mid-size manufacturing company. We are getting our feet wet with SharePoint - so far we're got one blog in production use> It's the CEO's.
We have use cases for a couple of list-based "applications" with some simple workflow that will be implemented by one of our developers. We also want to give our users (at least the more tech-savvy ones) the ability to create and work with their own departmental sites.
We're concerned, however, that we might be starting something that could quickly get out of control if it's widely adopted (which would be a good thing). Since we don't really understand all the architectural trade-offs, we could end up with massive amounts of user data in a structure that bites us down the road.
Our biggest question is whether to have multiple sites for each use vs. a single root site from which everything else descends. Multiple sites would give us flexibility to make changes or develop new features without creating problems for all the users. However, multiple sites might be harder to back-up, search, and maintain user profiles/security. A single massive site seems to reverse the cost/benefits.
I'd appreciate any insight on the one vs. many trade-offs, or links to resources that discuss it. Links to general SharePoint "enterprise best practices" (sorry) would also be appreciated.
Thanks.
However, multiple sites might be harder
to back-up, search, and maintain user
profiles/security. A single massive
site seems to reverse the
cost/benefits.
I would consider this as incorrect. First we need to clarify when we say multiple sites, do we mean multiple site collections or multiple sites - they are two entirely different things.
Now even if they are multiple different site collections, in SQL database, they are just one database, since the database is created as web application level and not site level.
That was regarding backup.
Coming to search and user profiles, again your assumption is wrong. Search and User Profiles are Shared SErvices and they work fine as long as they reside in single Shared Services Provider. Both are farm level services.
A single massive site is (if you really mean site here not site collection) is a complete no-no and a bad design.
I would recommend having multiple site collections (something like Overall department in your company like HR, Finance , IT) and then have subistes under it. This way you have one database in SQL to manage and still you can scale by adding content database to existing web application.
Again here, I assume that you are creating your topology at company level. If this is at some lower level it needs to be refined.
Read some articles on taxonomy and site architecture on Technet before going ahead with any one.
Planning worksheets for SharePoint Server 2010
http://technet.microsoft.com/en-us/library/cc262451.aspx
Plan sites and site collections
http://technet.microsoft.com/en-us/library/cc263267.aspx
Sites and site collections overview
http://technet.microsoft.com/en-us/library/cc262410.aspx
Plan site navigation
http://technet.microsoft.com/en-us/library/cc262951.aspx
It purely depends upon your needs and requirements. even having a deferent web applications for deferent site i can provide you one citation taking backup as advantage. You might have few sites where data does not changes frequently like organizational policies, process documents etc. in this case taking regular backups/search crawling does not make sense(although you can opt for differential backup and incremental crawl but still in a week or fortnightly you have to take full backup). hence i would suggest carefully analyze your requirements and then take a decision. Microsoft has provided a good list of checklist and templates for planning purpose. few of the links are provided in madhur's reply and rest you can google upon.
Is there an out of the box solution to check the validity of documents? Let's say when a document has been in a document library for 1 year, the author should get a warning, an e-mail for example, to revise the document.
I didn't find this in SharePoint. So I was thinking of creating my own feature for this:
A timer job which runs every night and check all the documents in the site collection
The timer job can be configured through an admin page in the central admin, for example to configure on which site collections in a web application the job should run.
My concern is, when running this in a heavily used environment, doesn't it burden the servers too much? Let's say for example an environment with 100.000 documents spread out over 5 site collections. And how about looping through all those document libraries in various SPWebs, use an SPSiteDataQuery to retrieve all those documents and loop through that collection? Because opening each document library in each SPWeb in 5 SPSites...
Or is there an other option to accomplish this? With workflows? Because in the end, the owner of the document receives a warning and he needs to confirm if the document is still valid. I haven't touched workflows much to be quite honest.
I would like to hear your thoughts about this.
Maarten.
This SO Question may give you some ideas - workflow/timer jobs/3rd party etc as in essence your requirement for email alerts when documents are 1 year old is basically the same as 'a task is overdue'
Dated reminders in sharepoint calendars
Re: Load - well I can't give you specifics as every situation is different but you've got the ability to run this overnight so I can't imagine that it would really be much of a problem.
Also Remember your not actually retrieving/parsing the documents themselves, just the record containing the documents meta-data such as title, location, modified date, assigne to etc.
this sounds like a job for powershell.
write a little script that queries the document lib's for documents that are older than one year.
then send a email alert or create a task for the user to update the document.
also i would not worry about having 1000's or workflow runing. WFF is an enterprise product. i have had over 60000 running without any problems.
I have the following situation:
MOSS 2007 Server Environment A -> Intranet
MOSS 2007 Server Environment B -> Collaboration Environment (approx. 150 site collections for various issues)
Both environments are on different infrastructures but we use the same Active Directory and the same groups. Now we would like to implement the following 2 things:
An overview page within the intranet with all available site collections on environment b.
An overview page within the intranet with only those site collections the user has access on.
now i'm searching for some good ideas what would be the best way to realise something like this.
thanks in advance for any response.
The main thing to be careful of in a solution like this is performance, particularly for your second requirement. That would require looping through every site collection and retrieving permission data, either using the web services or the object model.
I would recommend writing a custom timer job (or two for each requirement if that makes more sense) to execute at a low-traffic time and aggregate this information for storage in a custom SQL database. If there is never low traffic then delay your requests to reduce impact on the server.
A custom web part (or again, two if more appropriate) can then be deployed to both environments. The web part would query the database for the required information and display it to the user.
If the timer job needs to update this data more frequently then you would need to implement some sort of in-memory caching. Depending on your requirements this may need a lot of memory.
I'm looking at designing some core information systems at a new company I'm working at (described one of my ideas here Workflow system)
I've thought a bit more, and am strongly considering using sharepoint for a lot of the heavy lifting seeing as it comes with so much out of the box.
However, I'm not sure how it will handle the high volume of data we'll be throwing at it. I read the MS whitepaper (http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409), and it says about 2000 items in a list is about the limit using traditional design methods.
But first a bit of info on my plan and data structures :
We have multiple clients. Each client has multiple applications. Each application will have multiple, ongoing jobs (or process runs).
Each application will store significant correspondence and documentation. Each job represents the processing of a data file on a single run, and stores information about the job such as the postscript file, postal manifests, etc.
Job volume will be about 50 - 100 a day. Each job will have a workflow, triggered by external programs. Then, say on a "job scheduler" page, production staff can schedule the jobs and perform custom actions on the job (written as plugins).
I was thinking the jobs would sit outside and accessed via the BDC, but I would still like them represented in sharepoint lists, to add in sharepoint functionality and reporting, and they'd be accessible in multiple places
e.g.
Application portal - see jobs for application
Production scheduler - see lists of upcoming jobs, assign to resources, trigger other functionality (e.g. copy print file to printer, produce mailing machine file)
Invoicing view - view completed but uninvoiced jobs, export to accounting package
Client view - client portal displays jobs, invoices, stock levels (from external warehouse system), documentation, change register / helpdesk
So basic info about the job would sit in the BDC, but then sharepoint would capture additional metadata about each job. Also, down the line we might put in more advanced workflows using WF or something like K2 blackpoint / blackpearl.
Is this feasible? Any resources you'd recommend to read to get up to speed?
To use SharePoint, you should concentrate on what SharePoint is good at and what it is designed for.
SharePoint is a great collaboration portal, it is not so good as a simple high volume database. So...
You can setup a small site for each client and subsites for each job. The goal of the "job site" is to display (using a webpart perhaps) the relevant upcoming jobs, a list of job errors/exceptions and relevant team documentation on each job.
Separate sites can be created to give a particular "view" of the jobs. E.g an "Invoicing" site can be created to give a view again from BDC webparts of what is requiring invoicing.
https://iwsolve.partners.extranet.microsoft.com/SDPS/ may provide some help.
Don't try and store huge amounts of information in a SharePoint list, just because it may be possible to "tag" it with meta data. A database table is perfectly able to include columns supplying additional information if required.
Think about it this way. If you are creating 50-100 jobs a day, putting that data into a list pre-supposes your sites users are going to want to enter metadata on those jobs manually. I thought not, so create systems you need in order to get the metadata stored correctly at source, or store metadata about the "types" of jobs within a SharePoint list and allow SharePoint to match the job type with jobs in the BDC.
SharePoint will help you to integrate all your systems information together, but unfortunately it looks like you have a lot of work to do just planning what information should go where and how each type of use will view it.
Please take a look at this blog post I wrote on managing large SharePoint lists for better performance- it might offer a bit of an explanation for the 2,000 items issue, which is not actually a hard limit on the number of items in a list, as SharePoint will support up to 5 million items per list. One way around this would be to create and maintain different views that filter by an indexed field to show you different items, up to 2,000 at a time. Hope that helps.
Dina Ayoub
Program Manager
Windows SharePoint Services
SharePoint is probably quite a good fit for the UI side of things, though you'll need to think carefully about which parts are stored and modified in SharePoint lists and which parts are stored elsewhere. That's not so much a SharePoint issue as something you always have to deal with when you have multiple data sources.
I'd probably use a SharePoint list as the primary store for jobs, to avoid any sync issues and make editing easier. The volume of data shouldn't be an issue - just make sure you aren't trying to display 2000 items at once - it's the view, not the list itself that runs into performance issues on large numbers of items.
Tough question Dane... I would like to know a little more about your design / vision before giving an opinion.
Based on what I read in your question I would not use SharePoint 2007 as a development platform for this application.
1) Development experience in SharePoint 2007 can be painful and unproductive at times.
Hard to debug
Steep learning curve
2) Easy to get in trouble with performance
Data Layer is complex and can require expert SQL / SharePoint Admin skills to make platform scale.
Content databases should not exceed 100 GB.
3) Deployment can be extremely difficult depending on what you are doing.
4) New version will be released in the next 12 months.
Just my .02.