Forum Replies Created

Viewing 15 replies - 1 through 15 (of 35 total)
  • Sorry, I don’t agree in that point – but that’s the reason I implemented the interval as an option so everybody can use the interval she/he likes to use.

    If a visitor shows up at 9am for 5 minutes and comes back at 7pm for 10 minutes it *is* a revisit/new unique visit in my opinion.

    Unique visit = visitor shows up, does what he wants to do on the blog and leaves.

    Fair and informative: results from the point of view of the admin – what do I want to know from the statistics system. Visits like the ones I described or Visits of a unique IP within the given interval.

    Example: Let’s place some ads on a blog. The sponsor wants to know about the number of unique visits in order to calculate the estimated number of showed ads.

    Say we have 500 different IPs/day, 50 of them come back a second time a day (it’s just an example, not very realistic…).

    Using your algorithm (unique visitors) the sponsor calculates a minimum of 500 ad views.
    Using ‘unique visits‘ the sponsor calculates a minimum of 550 ad views because 50 users come back a second time and the ads are displayed again.

    BUT: The default 5 min interval IS too short and will be changed in the next update.

    By the way – IPs can change (dynamic changing IPs from ISP, re-dial-in, anonymization service – that’s a big problem for statistics systems, besides that 2 people *could* be behind the same PC (or many people behind a network) and independantly visit your blog – they’d use the same IP but the’d be two different visitors. Say my wife and myself are registered to the same discussion board (e.g. photography), at some age my son registers himself, too. Now we have three people visiting the same website from the same IP – are we *one* visitor ?

    *reminder to myself: look into this forum more often, 1 week answering delay is too long, sorry for that.*

    Edit: I don’t like the f-word. Maybe explain your opinion (which is right, too – just another point of view) instead?

    This means that CyStats registered 8 hits (page requests) today, yesterday there were 137 requests counted which makes a diference of of -192 requests (this number is colored red if negative, green if positive).

    ABout the difference – different statistics tools use different algorithms to count visitors, different timeframes for ‘one visit’ (configurable e.g. in Cystats admin panel, defaults to 300sec I think, other tools use 1 day per default,…), some rely on activated javascript, some do not, some require to insert a counting code snippet into the pages to be counted and every other page will not be counted, some do count 404 pages, some do not,… and finally some do good work at sorting out robots and some do not – cystats currently counts robots with a fake user agent like of MSIE as real visitor – so if a bad bot with a user agent like that makes 2000 requests it will be counted as unique visitor according to the timeframe used (300sec default = one unique visit after every 5 minutes).

    This is an issue which I am working on – good robot detection.

    *doublepost*

    This is an very important question (and one of the reasons different statistics tools report different numbers – different interval) and the answer should be adapted to the habits of visitors to your blog. Some blog’s visitors remain for 30 minutes in general, on some blogs the usual visit time is 3 minutes – you should adapt this according to your blog type (long-reading-visitors, searchengine->short-visit->away,…).

    Just tried removing all CyStats data from database (options+tables) using the cystats admin panel after installing and activating DMSGuestbook, checked database table and ‘DMSGuestbook_options’ is still there, no problem here.

    Nevertheless you made me find another bug in the delete-tables-functions (but it does no harm, though):

    CyStats uses:

    $r=$wpdb->query('DROP TABLE '.$wpdb->prefix.TABLE_STATISTICS_RAW);
    $r=$wpdb->query('DROP TABLE '.$wpdb->prefix.TABLE_STATISTICS);

    But the right constants are named CYSTATS_TABLE_STATISTICS / CYSTATS_TABLE_STATISTICS_RAW:

    define('CYSTATS_TABLE_STATISTICS','TABLE_STATISTICS');
    define('CYSTATS_TABLE_STATISTICS_RAW','TABLE_STATISTICS_RAW');

    This does no harm because the undefinded constants TABLE_STATISTICS and TABLE_STATISTICS_RAW will automatically convert to their text aquivalents which results in the correct table naming which might be the reason this bug was not discovered for this long time.
    Nevertheless this has to be fixed in next update.

    $r=$wpdb->query('DELETE FROM '.$wpdb->prefix.'options WHERE option_name LIKE \'cystats_%\'');
    Deletes every database table with name starting with ‘cystats_’ in the WP options table.

    $r=$wpdb->query('DROP TABLE '.$wpdb->prefix.TABLE_STATISTICS_RAW);
    $r=$wpdb->query('DROP TABLE '.$wpdb->prefix.TABLE_STATISTICS);
    Delete the two statistics tables named ‘YourDBPrefixTABLE_STATISTICS/TABLE_STATISTICS_RAW’

    Those are the important lines in the source code for the ‘delete all including otions’ in CyStats admin panel.

    I do not doubt that your mentioned plugins do not work anymore but I cannot see the deletion functions as a cause for this (the other plugins database tables should not be named like the cystats ones).

    Missing-options-problem: Maybe a simple reinstall restores the options?

    On which page did you get this error message? Seems there is a bug with the daily-hits/visits page in the admin area – did anyone else see this message? I was not able to reproduce this over here in two blog systems.

    This should be corrected with version 0.2 uploaded right now, the error was caused by the function preg_match which used a parameter &$matches which causes errors on some PHP versions. Replaced by $matches, should work now.

    Thank you for reporting this issue.

    Sorry, this is not implemented.
    For now I’ll concentrate on improving the robot detection system so this feature won’t be implemented in one of the next versions.
    Implementing a comment feature for the blacklists would decrease the speed of the visitor blocking functions since the plugin would have to parse the commented lines in order to get the ip range to block. As cystats already is not the fastest plugin due to its features implementing this would not be reccomended.

    Thread Starter cywhale

    (@cywhale)

    Yes, thank you – thats what i found out when after deactivating wpsc wordpress still delivered the cached page via the wpsc .htaccess 🙂

    Thread Starter cywhale

    (@cywhale)

    No way, knowing the cache mechanisms now – only an external script would be able to track statistics data. Thank you very much.

    Thread Starter cywhale

    (@cywhale)

    Hm. Thanky you. So there is absolutely no way to use an internal hook?

    Just tested add_action(‘add_cacheaction’,’cystats_logger’); (the hook mentioned at the wp-super-cache additional notes) instead of using ‘init’-hook but did not receive any reaction of cystats.

    Tried to avoid external scripts – does a stylesheet link with parameters like ?pageid=1&bla=blub&blub=bla… validate? Referer-stats wouldn’t be possible, too.

    Which WordPress version do you use? In WP 2.6.1 serializing behaviour seems to have changed again and some errors occur again, bugfix releas of cystats should be online within the next 12 hours.

    Thank you for reporting this issue, it’s a bug in the new bounce rate calculation – forgot to check division by zero. This will be fixed in the next release.

    This issue should be sloved for WordPress 2.6+ with CyStats 0.9.4.
    From this version on CyStats should be used only with WordPress 2.6+, the handling of serialized arrays in wp_options seems to have changed somwhere between 2.5 and 2.6.

    Please report any problems with CyStats 0.9.4 and WordPress 2.6+

Viewing 15 replies - 1 through 15 (of 35 total)