Traffic Reporting and Analytics

How Reblaze reports on the requests it receives

Metrics

The Reblaze Dashboard and Events Log provide intuitive yet powerful ways of viewing your traffic.

Data is reported in terms of several statistics:

Statistic	Comment
Hits	Total incoming requests
Humans	Requests originating from humans.
Bots	Requests originating from traffic sources not (yet) verified to be human. Most of the requestors will be bots, but some will not be. More on this below.
Passed	Requests accepted by Reblaze and passed upstream to the origin (i.e., the web server, API endpoint, etc.).
Blocked	Requests deemed to be hostile, and blocked.
Challenges	Requests that were challenged. The challenge process is an important part of Reblaze's traffic processing, as seen below.

The Dashboard provides a variety of ways to view your traffic. Some of them include all of the above metrics in the same view, while others include a subset.

This graph shows Hits, Blocked, Passed, and Bots

The Countries view shows all the metrics

The Challenge Process

Reblaze includes a multi-layered mechanism for distinguishing between human users and bots.

In the interface, this mechanism is summarized as "challenges." Requests from non-authenticated users will be challenged, i.e., they will undergo a process through which Reblaze ascertains if the traffic source can be verified as a human user or not.

When a traffic source successfully passes the challenge, it will not be challenged again for the remainder of the session. For legitimate users, this entire process happens quickly (in a few milliseconds), and is invisible to the user. Users will perceive no impediment or latency in their access to the requested resources.

For more details on this mechanism, see Hostile bot detection.

As noted above, this is the "typical" process that occurs in normal use. There are a variety of situations in which it might not be followed. For example, sometimes Reblaze is configured to allowlist certain IP addresses, and not to challenge them.

The discussion below will be based on the typical process described above.

How Requests Are Reflected in Reblaze's Statistics

The process described above will result in the following statistics being incremented.

For each challenge that was not passed:

• Hits

• Challenge

• Bots

If the challenge was passed:

• Hits

• Challenge

• Bots (see explanation below)

• Hits (incremented a second time for the post-challenge resubmission of the request)

• Passed

• Humans

Counting Bots

Within Reblaze, a request that does not have authenticating cookies is counted as a bot.

As a result, the Bot count can sometimes be incremented even when the visitors are humans. Examples:

• When a human user visits a Reblaze-protected site for the first time, the first request does not yet have the authenticating cookies.

• Static files (images, etc.) are often exempted from challenges for performance reasons. Direct requests for those URLs from a new visitor will not have cookies.

• Sometimes, trusted IPs are whitelisted and exempted from challenges. They never receive authenticating cookies.

Therefore, although most of the Bot count represents non-human requests to your web application, the Bot metric is not an exact count of this.

Relationships of Traffic Metrics

When working with Reblaze's traffic statistics, the following relationships can be helpful.

Hits = Passed + Blocked + Challenges

Hits = Humans + Bots

Active Challenges versus Passive Challenges

The process described on this page is the active challenge process. Out of the box, this is the challenge process that Reblaze uses.

We recommend that whenever possible, customers also enable passive challenges.

Passive challenges still include Environmental detection and browser verification, while adding three additional benefits:

• They enable biometric behavioral verification: a much more powerful means of identifying automated traffic, and an important part of Reblaze's behavioral analysis.

• In some situations, active challenges can interfere with certain metrics such as those provided by Google Analytics. (The initial referrer information is lost.) If this is a problem, active challenges can be disabled. In this situation, passive challenges can provide effective bot protection instead.

• When caching is being done by a CDN, active challenges will not occur for pages being served from the cache. Passive challenges are necessary for Reblaze to perform bot detection in this situation.

If possible, we recommend that customers use both active and passive challenges.

To learn more about passive challenges, go here: Enabling passive challenges.