Skip to content

Introduction To Tracking

There’s a variety of ways to track custom analytics within the Hoglin SDK. This guide will provide an overview of the different methods available, along with linking to more detailed examples. It will also explain how events are cached and when they are sent to Hoglin.


It’s important to understand how the SDK caches events on the clientside before they’re sent up to the Hoglin.

By default, all tracked events will be added to a queue that gets flushed periodically; this is referred to as “auto-flushing”.

The frequency that Hoglin auto-flushes is set to 15000 ms by default. The frequency can be controlled by setting autoFlushInterval in the SDK builder to the expected interval in milliseconds.

When auto-flushing, the first n events are taken from the queue and sent to Hoglin, where n is the maxBatchSize set in the SDK builder. If there are more events in the queue, they will remain there until the next flush.

Auto-flushing is asynchronous by default and remains platform-agnostic by not hooking into platform-specific schedulers, instead we create our own scheduled thread pool with 8 virtual threads. The executor used can be manually overridden with the executor parameter in the SDK builder.


If you’d like, you can bypass our autoflush strategy and implement your own flushing logic. To do this, set enableAutoFlush to false in the SDK builder. Events will still be cached locally, but you can control when they are sent to Hoglin. To manually flush the queue, call Hoglin#flush. This will send all cached events to Hoglin, regardless of the size of the queue. Manual flush calls are not made asynchronously.


Event parameters with certain names may be treated specially for better integration with the Hoglin dashboard. These are outlined below:

Parameter NameSpecial Treatment
playerUUIDRender player name where applicable, eg: “Tracked {event_name}” -> “{player name} triggered {event_name}“

Once you have your Hoglin instance, you’ll notice you have a couple overloads for Hoglin#track. To remain flexible, we support a variety of inputs here, differing in complexity and features.