Google Analytics vs. Statify: Different page hits – Reason?

P.S.:

Yes, I know that Statify does not track feeds, trackbacks, searches, previews and error pages. I took the same settings for Google Analytics to have a suitable comparison.

Hi @david181,

just one not recognized bot can ruin your stats. If you really want to know, you need to check your access logs and then count yourself.

Maybe Statify is blocking too much or Google to less …

All the best
Torsten

Hi @zodiac1978,

thanks for your reply.

I would understand the other way around. Because I have no blacklist in place I would expect Statify to count every hit. As Google Analytics has some bot filter algorithms in place, the amount should be lower.

I also checked: The difference is there pretty much each day – so no peak for one or two days only (which might let to a bot attack). Also, I had the same result with two totally independent websites.

I see no explanation for the fact of Google Analytics double the amount of Statify. What do you think? Am I overseeing something?

Another theory: There is a sideeffect with Cachify. Do you know if JavaScript tracking (set right now) or normal tracking is working better in that bundle?

Thanks so much!

I would expect Statify to count every hit.

We have a very basic bot detection:

https://github.com/pluginkollektiv/statify/blob/eab1d2e44f13c6fdbfc8635fe66eba36a4aa25ac/inc/class-statify-frontend.php#L210-L242

I see no explanation for the fact of Google Analytics double the amount of Statify.

Let’s wait for Patrick and Stefan which are much more in the code and can sure help here!

There is a sideeffect with Cachify. Do you know if JavaScript tracking (set right now) or normal tracking is working better in that bundle?

If you use Caching (e.g. Cachify) you need to use the JS tracking. Otherwise you will get no views, because the PHP view is not counted as there is no PHP executed, just the cached HTML page.

All the best
Torsten

Dear @zodiac1978,

thanks for your explanation.

Dear @stklcode / @patrickrobrecht – do you have further ideas where this could come from?

Thanks and best,
David

Dear David,

you may check your logs (Apache/nginx or WordPress plugin, depending on your setup) for 403 errors. We discovered an issue with long caching times. If the caching time is longer than the nonce time, the nonce used for tracking is not valid anymore and the request to the WordPress API endpoint is rejected.

I’ve prepared a bugfix (offer to disable the nonce check at all) for that which is ready for review at GitHub. Feel free to check the version from the branch.

All the best
Patrick

Hi @patrickrobrecht,

thanks so much for the improvement.

My Cachify caching time is set to 48 hours – how can I check my nonce time? I read 24 hours, but I’m not sure if that is dependent on the server config and if so how to check it.

If the nonce time is 24 hours, does it also solve the problem to set the Cachify caching time to 24 hours max. as well?

What are the disadvantages to disable the nonce check in the settings? Could that cause any other side effects?

Thanks!

Hi @david181,

for information about the nonce lifetime, you may have a look at the official documentation. Note that you can adjust the nonce lifetime using the nonce_life filter.

In your setting (assuming the default nonce life time and 48 h caching) Statify will not track views on pages which are cached more than 24 h ago. You have different possibilities to deal with this problem:

• Increase the nonce lifetime such that is greater or equal to the nonce lifetime. Then the nonce in cached pages should not expire during the time the cache is used.
• Decrease the caching time such that is smaller or equal to the nonce lifetime.
• Disable the nonce check by choosing “JavaScript based tracking without nonce check”. This restores the behavior until Statify 1.6.x, as the nonce check was introduced with the switch to WP Ajax in Statify 1.7.0. The difference is whether calls to the WP Ajax endpoints accepts requests with invalid or missing nonce – the nonce makes it more difficult for some attacker who could try to trigger the endpoint via some script to manipulate the view count on your site (as the nonce is in the source code this is not reliable at all).

I hope this helps to decide how to change your settings.

All the best
Patrick

Dear @patrickrobrecht,

thanks for the explanation, which makes it very clear.

I lowered the caching time to 24 hours and see how it will work out – otherwise I will test one of the other approaches.

Thanks a lot!