After Update too few siteviews

OK, thanks for your feedback. Let’s try to untangle the points…

i can confirm, did this mean that the bot recognition was changed/improved,

Yes, we changed bot detection and replaces the previously fixed list of keywords to a slightly more elaborate library that does the job for us. I personally did not see any noticeable difference on all test sites (running pre-releases for over 6 months), but experience may depend on the actual traffic mix.

or that it was switched to REST-API?

Closed or for whatever reason unavailable REST API should result in 0 views since update (assuming default config, i.e. logged-in users are excluded).

If it’s ~50% it could be bot detection or maybe a caching issue with cached scripts. The JS comes with a cache-breaker (version number), but if optimizing plugins are used that bundle scripts it may be a good idea to flush the caches if it did not happen automatically.

For me, the REST-API is closed for unregistered users …

If blocking the entire API is a good idea depends on the site and plugins used, there are quite a few that make use of it for dynamic content. We hat the very same discussion 6 years ago (v1.7.0) about exposing the admin-ajax endoint that was closed down on some sites as well – but that discussion is probably out of scope here, we won’t go back so some custom hacks to work around “security measures”.

Yes I also miss the update-button

We decided to remove it, because there’s rarely any real benefit. Data is cached for at most 15 minutes. Yes, there are times where an admin is impatient and wants to see “live” data, but after discussion in a small group nobody really seemed to use it outside of tests.

We may re-introduce it in some way or make caching configurable depending on the feedback.

the dashboard widget always starts with the most left stats and not the last stats, as before.

You are talking about the scrollbar, if a “long” time window is selected for the widget, right?
We’ll look into that and most likely fix it with the next update, if that’s the case.

=> https://github.com/pluginkollektiv/statify/issues/348

• This reply was modified 1 week ago by Stefan Kalscheuer.

50% is really a lot to attribute to “just” a new bot detection system. Especially since it’s happening on four different websites.

I agree that a typical website should not have 50% non-user traffic that does not match any of the previously filtered keywords … but you never know for sure until you cross-check with server access logs.

The 1.8.5 filter was rather simple with some keywords to match:
bot, slurp, crawler, spider, curl, facebook, fetch, python, wget, monitor

I do have sites where my WAF filters out >2M bot/crawler requests per hour and I’ve seen others where some monitoring systems query the front page every 5 minutes that identify as Firefox or whatever…

I’m also going to try excluding the Statify script from caching so that it’s no longer bundled.

Should not a big issue in general. Most bundlers I’ve seen know are aware of cache-breakers or sentitive to plugin updates. And the tracking script rarely changes, so minor updates are fine even if cached.

Can you explain that part about the REST API to me? What does it have to do with Statify, and how can you tell if it’s blocked?

Statify 1.x JavaScript tracking sent a POST request to /wp-admin/admin-ajax.php
Statify 2.0 now uses an individual API endpoint at /wp-json/statify/v1/track

You should see such POST request with HTTP status 204 (No Content) in the browser console and the server’s access logs.

If there’s nothing, it’s likely an issue with the JavaScript inclusion.

If the API is blocked for whatever reasons (there are some guides out on the web that suggest disabling if with some custom plugin code for security or whatever reasons) it should fail, i.e. show HTTP error 401, 403 or similar. or maybe some CSRF failures in the browser console.

Update: I always assumed we are talking about JS based tracking here. If it’s the non-JS version (that doesn’t play well with caching), there’s a different issue obviously.

• This reply was modified 1 week ago by Stefan Kalscheuer.