Logging Events

After creating your first gate, you want to start logging events in order for the system to understand what you care about. These events are then automatically derived into metrics and used to quantify the impact of your features on the health of the overall product.

How to log events

There are a few ways Statsig can ingest events: via one of our Server/Client SDKs, connecting to a 3rd party like Segment, mParticle, or other Analytics provider listed in our Integrations, or via our metrics import http APIs.

Logging events via SDKs

All our SDKs provide a very simple API to log events. They look like this:

statsig.logEvent(
  event_name, 
  optional_event_value, 
  optional_event_metadata
);

Where event name describes a notable event in your product, like sign_up, achievement_unlocked, add_to_cart, check_out, etc.

These events can optionally take an event value. For instance, you can use this field to specify the type of achievement that was unlocked, or the name of the product that was added to cart, or the price of the item that was purchased.

And finally, the metadata field allows you to specify even more details about the event. Here's an couple examples of how a logEvent call looks like:

statsig.logEvent(
  'add_to_cart', // Name
  19.99, // Price
  { 
    item_id: 'BC22010', 
    cart_size: 2,
    user_segment: 'first_time_purchaser',
  }
);

An example in CSharp

StatsigClient.LogEvent(
  "level_completed", // Event Name
  11, // Level number
  new Dictionary<string, string>()
  { 
    { "score", "452" } 
  }
);

Log as much as you want

We encourage you to log as many events as you can and want. The more events there are, the more holistic picture you will get when you are building and releasing new features.

Size limits on event payload

Note that there are limits to how large each event field can be. Object fields have an overall limit of 4096 on its stringified length. String fields have a limit of 64 on its length.

Best practices

Naming conventions

The most important aspect is consistency - you should pick a convention and stick with it. Your events and metrics catalogue can quickly become messy and difficult to navigate when there are similiar events with different conventions. Technically speaking, Statsig can accept any type of name convention - E.g.; "Page View", "PageView", "Page-view" and "page_view". Practically speaking, we recommend using "page_view" — that is, to avoid spacing, special characters, and to use all lowercase characters. This will ensure there are no duplicate entries with different casing, and ensure other downstream systems connected via integration can accept and process the event properly given this is the most universally-compatible convention.

What to measure

In general, if you're doing normal experimentation/product analytics, you'll want events that correspond to user actions. How you classify them will depend on what you're trying to do. In general, keep the following in mind:

1. Events should not have high cardinality if you don't have a lot of users. Otherwise, experimental/metrics data will be too sparse. E.g.; an eCommerce website should not log a separate event name for every single product page. But instead, should have a generic "product_page_view" event and include contextual page information within the optional_event_metadata object.
2. If you have a well-defined user funnel, you'll want each step to be a separate event.
3. If you have a less defined user journey, you'll want to log generic events (eg. "page_view"), and add more details to either the value field (which should be the primary dimension of interest), or the optional_event_metadata object.

Where do these events end up?

The events you log is aggregated and analyzed by Statsig to give you useful metrics. These can be viewed in the Metrics Tab.

Statsig also provides a view into a set of derived user metrics like DAU, WAU, Stickiness, etc. just based on the events you log. Here's a view of those metrics available in the Charts page in Metrics Tab.

Metrics for Experiments

Metrics will also make their way into your experiment results. When analyzing the impact of one of your experiments, you will need to send Statsig event data to join with the different groups that users were assigned to in an experiment. The experiment results section will then show the difference in metrics between groups, and whether that difference is considered "Statistically Significant" - or Statsig, as we like to say :)