> For the complete documentation index, see [llms.txt](https://user.netmera.com/netmera-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://user.netmera.com/netmera-user-guide/reports-and-analytics/analytics/event-insight.md).

# Event Insight

Event Insight is the main workspace for analyzing tracked events. Use it when you want to understand how often an event happened, how many users triggered it, when the pattern changed, and which dimensions help explain that change. It is useful for both quick checks and deeper analysis, because you can start with a simple event count and then break the result down step by step.

For example, you can use Event Insight to see whether a purchase event increased after a campaign, whether an add-to-cart event behaves differently on iOS and Android, or whether a custom event becomes more common in a specific city or store group.

Use this page when you want to answer questions such as:

* How often did an event happen?
* How many users triggered it?
* Which dimension explains the change?

{% @arcade/embed url="<https://app.arcade.software/share/MnHXX793nOdvtPSu45jM>" flowId="MnHXX793nOdvtPSu45jM" %}

### Step 1: Filter the event data

Start with the date range. This determines which event data is included in the analysis, so it shapes every result you see later on the page.

Use a shorter range when you want to inspect a recent release, campaign, or issue. Use a wider range when you want to understand long-term patterns or compare seasonality.

<figure><img src="/files/He3GDOLI0Fvvm8i819Nt" alt="" width="563"><figcaption></figcaption></figure>

Then define who the analysis should include. This lets you decide whether you want to look at the whole user base or only a more specific audience.

Available audience scopes:

* **All Users**
* **Segment**
* **Tag**
* **Profile**

This step is useful when the overall trend hides important differences. For example, a conversion event may look stable across all users, but it may increase strongly inside one loyalty segment or drop within a certain profile group.

<figure><img src="/files/TBaSFm7dXc9Xf8nAtzQJ" alt="" width="563"><figcaption></figcaption></figure>

Select the events you want to analyze. These can be lifecycle, commerce, engagement, or custom events. You can analyze one event for a focused view, or select multiple related events when you want to compare them side by side.

For example, you might compare **Product Viewed**, **Add to Cart**, and **Purchase** to see where the user journey becomes weaker. If you only want to inspect one behavior in detail, select a single event and then use dimensions to break it down.

<figure><img src="/files/qAXrsocbqerYdQjfcpvz" alt="" width="563"><figcaption></figcaption></figure>

Add event properties when needed. Event properties help you narrow the analysis further when the event name alone is too broad.

Common examples include:

* product category,
* city,
* device type,
* payment method,
* or any custom event attribute.

For example, if you track **Purchase** as one event, you can still analyze only purchases from a certain category, a certain payment method, or a certain market by applying the related property.

<figure><img src="/files/6hoK8GD2iz3G4tAO6lpI" alt="" width="375"><figcaption></figcaption></figure>

### Step 2: Choose how to count the data

In **View Data**, you can switch between two core metrics:

* **Total Event Count** counts every event occurrence.
* **Unique User Count** counts distinct users who triggered the event.

Use **Total Event Count** when you want to understand volume. Use **Unique User Count** when you want to understand reach. The difference matters because the same user can trigger the same event many times.

For example, if one user opens the app 12 times and another user opens it once, the total event count is 13, but the unique user count is 2. Looking at both values together helps you see whether growth comes from more users or from the same users acting more often.

<figure><img src="/files/LpLr5zMRmYcamwl1IgOI" alt=""><figcaption></figcaption></figure>

### Step 3: Read the event table

The table breaks event performance down across channels and platforms, so you can compare how the same event behaves in different environments. This is useful when you need to separate overall behavior from platform-specific behavior.

For example, an event may look stable in the total column while Android drops and iOS grows. Without the breakdown, that shift is easy to miss.

Main columns:

* **Events** shows the selected event names.
* **All Total** shows total count across all available sources.
* **Mobile** shows total, iOS, and Android values.
* **Web** shows total and browser-level values.
* **REST / SMS / Email** appear when relevant for the selected event set.

The visible columns depend on the event type and the available data source. If a source does not apply to the selected event, that part of the table may not appear.

<figure><img src="/files/fOxZMbhl0UEABaBTpw2R" alt=""><figcaption></figcaption></figure>

Use **Hidden Fields** to simplify the table and focus only on the columns that matter for your analysis. This is especially helpful when you are presenting the result to another team or when you want to remove channels that are not relevant to the question you are answering.

<figure><img src="/files/Z8aAzZaGYJempQWk2x0T" alt="" width="375"><figcaption></figcaption></figure>

Use **Export** to download the table for offline analysis or reporting. The exported file follows the same filters, counts, and breakdowns that you applied in the report.

<figure><img src="/files/ixlw1MnprqhCEp6joFl4" alt="" width="150"><figcaption></figcaption></figure>

### Step 4: Use dimensions for deeper analysis

Dimensions help explain how the same event changes across time, users, or attributes. They turn a single event total into something more readable by showing where the volume comes from and how it is distributed.

Common dimensions include:

* Month
* Week
* Days of a Week
* Days of a Month
* Hours of a Day
* External ID
* Custom Event Attributes

{% hint style="success" %}
Available event dimensions depend on the event definition. Custom event attributes appear here after they are defined in [Create Custom Events](/netmera-user-guide/customer-data/events/create-custom-events.md).
{% endhint %}

<figure><img src="/files/z8HtY4ZwIlPpYEfJOVj1" alt="" width="563"><figcaption></figcaption></figure>

To add a dimension:

1. Select a dimension from the dropdown.
2. Click **Add to Table**.
3. Review how the event changes across that breakdown.

A good dimension depends on the question you are trying to answer. **Month** helps when you want to see long-term trend. **Day of Week** helps when you want to understand weekly usage rhythm. **External ID** helps when you need a user-level inspection. **Custom Event Attributes** help when your event carries business-specific context, such as category, campaign name, or payment type.

For example, if **Add to Cart** drops unexpectedly, you can first break it down by **Day of Week** to check whether the drop is calendar-related. Then you can add a custom attribute such as category or channel to see whether the issue is concentrated in one part of the business.

<figure><img src="/files/HKzvxsbjwQzw14W83reF" alt="" width="563"><figcaption></figcaption></figure>

You can also show or hide **Total Event Count**, create a **New Breakdown**, or delete a breakdown you no longer need.

These controls make it easier to refine the table as your question becomes more specific. A common workflow is to start with one event and one metric, add a single dimension, review the output, and then create another breakdown only if the first result shows something worth exploring further.

<figure><img src="/files/pintI8LdGGnl7hGGlj0a" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/qfrA7IU1NGxUMRzA5CDI" alt="" width="291"><figcaption></figcaption></figure>

### Why values can change later

You may see values for the same event and the same date range increase over time. This usually happens because of offline event sync. In that case, the event happened earlier, but it reached the system later.

1. a user performs an event while offline,
2. the event is stored locally with the correct timestamp,
3. the device reconnects later,
4. then the event is sent and added to reporting.

This behavior improves completeness and helps prevent data loss during connectivity issues. For example, if a user completes an action in a low-connectivity area and comes back online a few hours later, the event can still appear in the correct historical date range after it syncs. That is why the same report can show a higher value later, even when the selected dates stay the same.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://user.netmera.com/netmera-user-guide/reports-and-analytics/analytics/event-insight.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.