# Users & Segments Users & Segments section includes: * [Users](#users) * [Segments](#segments) ## Users In the Users report, you can find information about every user and their activity. {% embed url="" %} Users overview {% endembed %} ### Filter user list You can filter users by adding filters to some user properties. Click `Add filters` to set a condition and then `View result` to see a table with users. In the filter, you can set various user properties and parameters, as well as events and performance windows. For example, filter out premium US users who added two friends in the last month and reached a certain level:

{% hint style="info" %} You can also save a custom filter template and then select it when creating a [push campaign](https://docs.devtodev.com/reports-and-functionality/project-related-reports-and-fuctionality/experiments/push-notifications). {% endhint %} ### Export user list Click the `Export to CSV` button to get a table with users (first 1000 lines) or a specific user profile. If no specific user is selected, this will export the users that match the current filters.

You can also select the user profiles in the table and click the `export profiles` button. ### User card Click any row in the table to view user profile details. The User card consists of basic properties, custom properties (any additional parameters added during integration), and statistics on user actions performed in the app.

Use tabs to toggle between basic and custom properties:

You can delete or download user data by clicking the three dots on the user card:

### Cross-platform specifics In [cross-platform type projects](https://docs.devtodev.com/getting-started/cross-platform-application) user has the same devtodev ID on all platforms. In the Basic properties tab you will see a dedicated list of properties for each platform and general information about the user in the General section. For example, *Install date* and device information are platform-specific, so they will be different for each platform section. The General section stores the *Install date* of the first-ever platform and updates the *Last seen* field according to the latest data from any platform.

#### Mark as Cheater or Tester You can flag a cheater or a tester if needed. This action will remove the user's transactions and events for the last 7 days from the reports (the payments will be visible in the [Real-time dashboard](https://docs.devtodev.com/reports-and-functionality/project-related-reports-and-fuctionality/smart-view/real-time-dashboard)). If you lift the Tester/Cheater mark, their previous transactions will not become valid. {% hint style="info" %} Please note: the events will not be excluded from reports immediately. {% endhint %} Cheater/Tester marks are connected to the User card and are **not** platform-specific. If you mark a user for a cheat transaction on one platform, the user becomes a cheater on **all platforms** and their transactions become invalid. ### Last user activity Here you can see user activity days and the events with parameters that they performed in your project during the entire data retention period. * **Filter.** You can specify the events that you want to display in the list of user activities. The rest of the events will be hidden, but you can expand them to view. * **Highlight.** You can specify the events that need to be highlighted so that you can quickly find them in the complete list of events. * **Calendar.** You can select a specific day to see what events the user performed on that particular day. By clicking `Show next` or `Show previous` you can load more recent days of user activity or more of the past actions.

### Payments and Subscriptions #### Payments In the payments section, you can see the goods purchased by the user, as well as the transaction ID, date, and cost of the goods in USD and in original currency. If you use [automatic transaction / refunds tracking](https://docs.devtodev.com/integration/autocapture), you will see a flash icon

next to such transaction.

#### Subscriptions Section with the information related to the subscription purchases. If you use [automatic transaction / refunds tracking](https://docs.devtodev.com/integration/autocapture), you will see a flash icon

next to such transaction.

### Session replays This tab shows all available session replays. Simply click on a session to view the recording. {% content-ref url="users/session-replays" %} [session-replays](https://docs.devtodev.com/reports-and-functionality/project-related-reports-and-fuctionality/users/session-replays) {% endcontent-ref %} ## **Segments** {% embed url="" %} Segments overview {% endembed %} This page shows an overview of created user segments. You can customize them, delete or add new ones. These segments can help you target a specific group of users, separating them by any action they make (e.g. skip tutorial, pay for a subscription) or any property. There are two types of segments: **static** and **dynamic**. \ **Static segment** consists of a specific list of users, who perform a distinct number of events. Moreover, it cannot be supplemented. The static segment can be created using the reports that contain data on the number of users. The user list in a **dynamic segment** is refreshed every time new users perform a certain event or they obtain a property defined in the segment parameters. You can also define the parameters needed for a user to leave the segment and the parameters needed to re-enter the segment. Once segments are identified, they can be used in your reports and dashboards the same way as filters.

Each segment has five parameters: name, type, current audience, date of creation, expiration date. Click on existing segment to adjust it. You can filter your segments in ascending or descending order by any parameter. ### Creating a Static Segment ![](https://2105883905-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LnGcP_ZeRJ1ipj9O8dF%2Fuploads%2FYjnxcOuTaWEEfICEEUe2%2Fimage.png?alt=media\&token=bcebc5ae-d43a-4f62-b208-2eff1363008d) You can upload a CSV file with a list of user identifiers manually. To do that, create a **Static segment** and follow the instructions. * **Conversion funnel report**. After building a user experience funnel, you can add the user list to a static segment. The segment will start from the selected step, e.g. users who installed the app, viewed an offer and made a purchase.

* You can use **SQL** to create a static segment if your query results in a user ID list:

* You have the option to create a static segment using the **Paying status prediction** report:

* You can use **RFM analysis** to create a static segment:

* Or you can open the **Users** section to add the filtered user list to a segment: ![](https://2105883905-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LnGcP_ZeRJ1ipj9O8dF%2Fuploads%2FSdIrPsCZgfCj7ICmteN9%2Fimage.png?alt=media\&token=815edda1-1c16-4556-8e7a-c1af1db376eb) ### Creating a Dynamic Segment You can create a new dynamic segment by clicking **Add segment** button in the upper right corner. Then you should fill in: 1. **Name** 2. **Segment entry condition** Here you can add customized conditions describing in details those users who will be in new segment. You can choose entry conditions for the segment: * **User card parameters**. \ Define the properties and their values that are necessary for a user to enter the segment. Use AND/OR operators to manage the segment entry conditions with more flexibility.\ \ For example, you can select the users who view your ads AND don’t buy anything in the app; an audience that installed version 1 OR version 2 of the app; users acquired through an ad campaign from Facebook AND a certain country, etc.

* **Event conditions**.\ Specify a time frame and events the user has to perform to enter the segment. Here you can also define parameters of the event and/or user properties at the time of the specified event occurrence. Use AND/OR operators to add a new condition or a group of conditions for flexible segmentation. Users enter the segment when devtodev receives specified events at the current stage. All events that conform to conditions must occur within no more than 30 days. The order of events specified at this stage is irrelevant.
For example, you can create a segment of unauthorized users from Brazilia who attempted to complete N levels in 4 days and analyze them later.

3. **Segment exit condition.** \ At this stage, you can specify whether or not the user can exit the segment. \ Open the relevant tab: \ **User can’t leave segment** – users will be accumulated in the segment. \ **Entry condition changed.** If the user does not fit the entry conditions anymore, they are excluded from the segment. You can also set a condition that will trigger users's exit from the segment.\ **Special exit condition.** Here you can specify exit conditions that must be met to exit the dynamic segment: by event conditions or by parameters specified in the user card.

For example, you want to build a segment of users who viewed special offers and opened in-app sore within 30 days but didn’t make a purchase. Then, in the **Segment exit condition** tab you can specify Purchase event and then all the users who did make a purchase will exit the segment. \ \ If at this stage you set up the segment exit conditions, the next stage will open up. 4. **Allow repeated entry.** \ Check the box if you want the users to re-enter the segment in case they conform to conditions listed at stage 2. \ Click **Apply** to create a segment with the specified criteria.

### Copying a segment You can also copy and edit an existing **dynamic** segment. Simply select a segment you would like to edit and cllick on the **Copy** button that will appear in the upper right corner.

A new segment will be created with the same entry/exit conditions, all you need is to give it a new name.

### Limitations You can not use historical data to create **dynamic segments** therefore we recommend you create the segments in advance. In case you want to analyze new features, for example, you can create a dynamic segment right after the release so that there is enough time to add users to it before you start analyzing the metrics that may be affected by new features. The **static segment** is applied to the historical data for the period up to three months from the segment creation. For example, metrics for the past 90 days in the **Basic Metrics** report or any other report where you can use segments as a filter. **Expiration date** – the date when the segment will be terminated.\ The Expiration date of the segment is calculated automatically and cannot be changed manually. If the segment is not used in the reports, then the segment will expire in two months. Otherwise, the Expiration date is prolonged. If the segment expires, the user can restore it within one month but before it’s restored, it can’t be used in the reports.