Introduction to Event Analytics and Logging
The Events panel allows you to get user-centric insights into API usage and user behaviors. Moesif architecture leverages high-cardinality, high-dimension analytics. This means you can filter and aggregate billions of API calls and user actions on pretty much any field even if it’s a high cardinality field like a session token or user id.
If you’re not already familiar with API Analytics, you should first API Analytics: The Ultimate Guide to Grow Your Platform Business eBook
Filters
Events can filtered by Event filters, but also by the performing user and the performing company.
Events consist of both API calls and User Actions. By combing both in the same view, you’re able to understand usage of your platform better regardless if across the API or the website.
| Filter Type | Description |
|---|---|
| Event filters | Enable you to filter by any API call or User Actions fields like the request URI, response status, HTTP headers. Some fields are specific to API calls only such as Status Code, whereas others are specific to User Actions such as Action Name. The property Event Type specifies whether the event is an API Call or User Action |
| User filters | Enable you to filter by user demographics of the user who performed the event. |
| Company filters | Similar to user filters but enables filtering at the account level (Useful for B2B companies) |
All three filters enable filtering on custom metadata such as Event Metadata, User Metadata, and Company Metadata.
Views
You can select different search views such as Event Log, Time Series, Segmentation, and Geo Heatmap via the secondary navigation bar the the top.
Event filters
| Filter | Description |
|---|---|
| Request URI Route | Moesif will detect what your URI route/template is from raw URIs. For example, the URI /widgets/12345 will map to a URI route of /widgets/:id |
| Request HTTP Verb | The HTTP Verb or Method such as GET or POST |
| Request IP Address | At the moment, Moesif supports filtering by IPv4 addresses. |
| Request City, Request Region, Request Country | These filters are for the location of the requesting client via geo ip lookup |
| Request Timezone | Timezone of the requesting client via geo IP lookup |
| API Version | If you set an API version using the SDKs, you can filter on version. |
| User Agent, OS, Device | These filters are for the data in the request’s User-Agent header. |
| Response Code | This is the HTTP status code such as _500_ or 404 |
| request.query.[Header Key] | You can filter on any URL query parameter such as pagination parameters |
| request.headers.[Header Key] | You can filter on any HTTP request header such as Content-Type |
| response.headers.[Header Key] | Like request, can filter on any HTTP response header such as Content-Type |
| Event Type | You can either pick API Call or User Action |
| Action Name | For user actions, this is the name of the action such as “Sign In” or “Purchased Plan” |
| Event Id | Each API call is tagged with an event id. If you know the event id (i.e. you printed it in debug logs), you can enter it here. |
| API Key/Session Token | The API key or session token used when making the API call such as a token in the Authorization request header. View identification of users |
| Elapsed Time (ms) | Range filter for the duration of the API call. |
| Direction | For API Calls only, you can select _Incoming” to show only API calls to your own services you provide, or select “Outgoing” to only show API calls going out to a third party service. |
| metadata.[field key] | Custom fields set in the event metadata |
If your API is a GraphQL API, most will automatically add a secondary set of filters called GraphQL Query Filters, parsed from the GraphQL query.
User fields
| Filter | Description |
|---|---|
| User Id | If you need to bring up API calls for a specific end-user, you can enter the user id here. You should call identifyUser() in the appropriate SDK for this to be accurate. |
| User Name | Filter by associated user’s name after setting it in the user metadata |
| User Phone | Filter by associated user’s phone number after setting it in the user metadata |
| User Email | Filter by associated user’s email after setting it in the user metadata |
| user.campaign.[field key] | Referrer and UTM parameters to track effectiveness of your acquisition channels. Set automatically by moesif-browser-js, but not with server side SDKs |
| user.metadata.[field key] | user demographics or other properties you store in the user metadata |
Company fields
| Filter | Description |
|---|---|
| Company Id | If you need to bring up API calls for a specific end-company, you can enter the company id here. You should call identifyCompany() in the appropriate SDK for this to be accurate. |
| Company DomainName | Filter by associated company’s website domain after setting it in the company metadata |
| company.campaign.[field key] | Referrer and UTM parameters to track effectiveness of your acquisition channels. Set automatically by moesif-browser-js, but not with server side SDKs |
| company.metadata.[field key] | company demographics or other properties you store in the company metadata |
API protocol support
Moesif supports a variety of API protocols including RESTful, GraphQL, and Ethereum Web3 (JSON-RPC) APIs. Please see the documentation for GraphQL Support and JSON-RPC Support for protcol specific features.
Bookmarkable URLs
Moesif persists any active search criteria to the browser window’s URL, so that you can pass your browser tab’s URL to a teammate and they will also see the same filters applied by you without requiring them to re-enter those filter parameters.
Sharing Workspaces
Moesif allows you to select specific data to share with the partners or customers without exposing all your API data. After selecting the relevant data, click on the create shared link button, which will create a new workspace that can be accessed by the publicly accessible link. For more information, view workspace documentation.
