Server-Side Tracking & Bot-Filter

General
1

I have a quick question regarding server-side tracking and how it handles bot filtering.

I’m a bit out of date on this topic. IIRC from earlier days that JavaScript-based tracking was preferred because it was better at filtering out annoying bots (likely because they didn’t execute JS).

Today, I’m sure many bots can/do execute JavaScript, but certainly not all of them.

So … with server-side tracking, do I have the same chance of primarily seeing real users and not bots, similar to how it works with JavaScript tracking code?

2

Hi Sebastian,

There is no difference between the JS snippet and our server-side integration when it comes to filtering bots. Both types are going through the same process. Most of the bots these days are running JS as sites have become more interactive. Search engines render the page to see how it would look like to a real visitor. Depending in JS not being run by bots isn’t sufficient any more.

The main difference is, that the client might block the JS snippet, while the server-side integration cannot be blocked. So we recommend using the server-side integration if possible.

3

Marvin, your assistance is greatly appreciated! :folded_hands:

I’ve had a brief look at the PHP SDK (demo.php). From what I can see, the SDK mainly demonstrates how to retrieve data, but I’m unclear about how to send data, such as logging events (like “add to cart” or registration …). There is a “$filter->event_meta_key” but that online is all I can see :slight_smile:

While the API documentation is detailed, the PHP SDK itself doesn’t seem to have much documentation beyond the demo file?
Do you recommend using the REST API over the SDK? Is the REST API more mature/feature-complete?

Many thanks!

4

You should use the SDK :slight_smile:

The relevant parts are right at the beginning of the demo.php:

// Page view
$client->hit();

// Custom event named PHP, with 42 as the duration (the meaning depends on what you use it for), and custom parameters.
$client->event('PHP', 42, ['hello' => 'world']);

And that’s basically it. If you would like to use specific features, like tags, you might want to consider using the API directly. The SDK could definitely use an upgrade, but it should be working just fine for most use-cases.

5

:folded_hands: it was right there. Haven’t seen the second try block :man_facepalming:

:+1: … yeah, at least some comments could help for users first time looking at it to get an impression of it :slight_smile:

1 Like
6

While I like tracking on the server, it is missing some other nice features like tracking outbound, downloads, 404, mailto-clicks etc.

And probably I mix things up, but isn’t PA measuring time on page by polling to get more precise timings, especially for one page visits only?

I perhaps add download tracking myself with some kind of ajax call, but charming thing was pa.js was doing this by default.

7

You can mix the two by disabling page views for the script, so that it only tracks events.

No, we measure the time between page views. That is why a bounced visitors is always displayed with 0s for the session duration. Otherwise we wouldn’t be able to track this metric from the server-side at all :slight_smile: