Category: Stats

As of now, it says:

28627 online users

Contributors

Contributors

It's very easy to add manually by editing templates/footer.tpl, it would be nicer to have the _uacct saved in the database with the rest of the settings. Upgrades would be easier for site admins.

Please see:
https://www.google.com/support/analytics/bin/answer.py?answer=55488

This would be similar to gmap.

Related:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=1177


Maybe this feature request could be even more generic to include easy ways to add other services and/or make it easy to use with open source apps like phpOpenTracker or phpMyVisites.

http://www.phpmyvisites.us also recommends putting the code just before /body>


Also, there should be a way to exclude certain or all groups from tracking. If I use 1 Tiki for a public website and and Intranet, I don't want my Intranet traffic to pollute my public site stats. I could just want anonymous users to be tracked.


Also, let's integrate more tightly with the new [http://www.google.com/analytics/GATCmigrationguide.pdf|ga.js] code so we can track downloaded files, and take advantage of other nice stats.

Once upon a time, we had http://sourceforge.net/projects/cvsmonitor/ running on cvs.tikiwiki.org It was taken offline because it needed 4 gigs of RAM to run (!)

This provided some fun and useful stats about CVS activity. It would be nice to have something like this again.

There are some nice demos of what we could have.
http://statcvs.sourceforge.net/
http://statsvn.sourceforge.net/

We could have stats.tikiwiki.org to aggregate all stats from the TikiWiki community.

Any volunteers?


M ;-)

All stats related features/settings/options should be next to one another.

tiki-admin.php?page=features
Stats
Referer Stats

tiki-admin.php?page=general
Count admin pageviews:

This would permit us to have stats about TikiWiki usage.

This idea is from [http://www.phportail.net/|Philippe Gamache] and [http://www.nexen.net/|Damien Séguy]

We could suggest to other cms/forums/wiki engines, etc to use similar headers

More info:
http://www.nextthing.org/archives/2005/08/07/fun-with-http-headers


[11:07:19 AM] Philippe Gamache says: x-cms-engine : tikiwiki 1.9
[11:07:22 AM] Philippe Gamache says: or
[11:07:46 AM] Philippe Gamache says: x-cms-engine :tikiwiki
[11:07:46 AM] Philippe Gamache says: x-cms-version: 1.9

It would be nice to generate periodical stats reports in order to track for example the learning curve

Tested on 1 site.

Banner stats are unreliable. Generally, they count 3 times each click. Needs to be verified on another site.

One one site, (needs to be checked elsewhere), the number of impressions seems to be triple the actual number.

Please comment if banners are reliable for you.

We already have:
* ((doc:PluginTrackerStat))
* ((doc:Computed Tracker Field))

But we would need something additional for the following use case:

We have a tracker with a list of tasks. Each task has typical values:
*Open/Pending/Closed (tracker status field)
*Name (text)
*Description (text area)
*Assigned to (user)
*Assigned by (user)
*Priority (drop-down of 1 to 5)
*Creation date (system generated field)
*Last modification date

This is very similar to:
http://profiles.tikiwiki.org/Simple+Bug+Tracker

((doc:PluginTrackerStat)) could provide some stats on how many tasks are in each priority.


Now, imagine each task has 3 additional values:
*Original estimate (do not change the value of this field)
*Hours spent so far
*Time remaining estimate.

((doc:Computed Tracker Field)) could calculate 2 additional values.

* ''Current estimate'' would calculated by ''Time remaining estimate'' plus ''Hours spent so far''
* ''How on-target are we?'' would calculated by ''Current estimate'' divided by ''Original estimate'' times ''100''

So far, so good!

However, we would like to know:
*The total number of all hours of work remaining.
*The overall ''How on-target are we?''

((doc:PluginTrackerList)) coudl be extented to have a report of the total number of hours, with certain filters.

Then, Tiki could be used to manage a Tiki Sheet:
http://profiles.tikiwiki.org/Time+Sheet

In the future, we could generate ((doc:Graphics and Charts)) from this data, like we do in the ((doc:spreadsheet))

Tiki already handles nicely SSL (With the Yes, No, Automatic choice for HTTPS Server: in tiki-admin.php?page=general). This is for Tiki generated content.

But what about external images or scripts?

Probably no need to code anything. Just better documentation on how to use a variable to use different links.


Example:
{img src=images/code.png}%%% {CODE()}
if($_SERVER['HTTPS'])
{
$google_analytics_url = "https://ssl.google-analytics.com/urchin.js";
}
else
{
$google_analytics_url = "http://www.google-analytics.com/urchin.js";
}
echo "



_uacct = 'ACCT_ID_GOES_HERE';
urchinTracker();

";
{CODE}

Features Classification

Login page increments tiki_pageviews which skews viewing stats, IMHO, especially for sites which require passwords for content viewing, which may be additionally exacerbated if users maintain Tiki's login page as their browsers home page.

Tiki login page wrongfully increments tiki_pageviews hit count

*polls (Could be with trackers)
**need a way to insure people vote only once (more of a voting system than polls).
***Possibly with unique URL sent by email
***Not sure, but probably that votes need to be anonymous (We know who voted but not for whom)
**Need a way to remind people that haven't voted.
***CRM style wiki & tracker merge
****Do a query on trackers (ex. people that haven't voted)
****Cross with a wiki page to create a form letter "Dear XYZ, according to our records, you have not voted. Please click here to vote.


__Related__
{wish id=2388}

Related:
http://drupal.org/project/usage/

[wish1416|Reporting errors (to tikiwiki.org) system (like Firefox Talkback)]

When you try to access a wiki page which doesn't exist, Tiki offers you a list of similarly named pages, to search for that word, to create the page, etc.

__Good.__

When you try to access other contents in Tiki (articles, blog posts, etc.) that don't exist (either have been deleted, moved, not yet published, protected, etc.), you get a Tiki error message.

__Good as well.__


But what if you try an URL which is just not possible?

Ex.: If you migrated from another system to Tiki and you are still getting hits with the previous URLs?

Of course, you could check your access logs and add nice redirects. But how can we make this easier for site admins?


The bundled _htaccess file (which you need to rename .htaccess to make active) has an example line:
{img src=images/code.png}%%% {CODE()}
ErrorDocument 404 /tiki-index.php?page=Page+not+found
{CODE}

__This is good.__

Now, how could we use this to provide the Tiki admin with a top-x error pages? And thus, it would help to detect broken links, etc.

Could .htaccess include some configuration info from Tiki? So a Tiki admin could add configuration information without using FTP, all in Tiki, possibly with a secret "system" wiki page.

Great inspiration:
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess

1- Turn on multilingual
2- restrict to 3 languages
3- go to compile one of the three

Notice crazy stats :-)

With ajax on, the page-top links to sections don't work, on tiki-stats.php, in my Tiki 3.1 installations.

Please see ((WikiBlame)) and ((WikiTrust))