# Data Requirements
## **Overview**
The customer will provide Assetario with at least three months of historical data from a specific game as training data. This data will contain anonymized user identifiers, per-user event data, and optionally external marketing (UA) information from the game, as agreed upon by both parties.
The data should not be overwritten for past dates, enabling Assetario to track changes over time. The accuracy of the ML models is expected to increase with more data provided by the customer. Since Assetario does not require any data engineering on the customer’s side, we recommend sharing as much data as possible.
## MAU (Monthly Active Users)
| Monthly Active Users | Minimum Data Required |
| -------------------- | --------------------- |
| < 50k | 6 months |
| 50k - 100k | 5 months |
| 100k - 200k | 4 months |
| 200k+ | 3 months |
## Data Warehouse Integration
Assetario commits to handling all data engineering, data preparation, and integrations for the project's objectives. The customer agrees to grant access to their internal event data storage, such as AWS S3 or BigQuery. A comprehensive list of supported integrations is available upon request.
If the customer desires predictions to be uploaded to their data warehouse, the necessary specifications should be provided to Assetario.
## Data Type Definitions
Each raw data table provided to Assetario should at least include:
* A unique user identifier
* Timestamp of when the event occurred
Assetario generally collects two event types:
1. **Required**
2. **Optional**
## **Required Events**
While we understand not all of these events might currently be collected by the customer, it's essential to provide as many of these events as possible:
**Login / Session Related Events:**
* First-ever login timestamp
* Daily login
* Every session start
* Logout/session end
**Monetization-Related Events:**
* In-app purchase completed/failed (this event must contain the USD price of the purchase)
* View of in-app purchase
* Subscription purchase completed/failed
* Ad viewed/cancelled / failed
* Ad revenue
**Contextual Information:**
* Device model/type/manufacturer / OS type
* User’s country
## **Optional Events**
The following are examples of other potential features. The more data shared with Assetario, the better the expected performance:
* **Activity**: Session start/end, group activity, mission statuses, soft currency purchases, gear transactions.
* **Progress**: Level ups, area unlocks, gear unlocks.
* **Social**: Group interactions, friend interactions, app invites, gift actions.
* **UA (User Acquisition)**: Ad details, cost per install.
## Data Definition Table
If available, Assetario requests the following table, which maps the customer’s identifier to table names:
| Type | Example Name | Meaning | Example Value |
| ---------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------- |
| identifier | user\_id / account\_id / player\_id | The unique user identifier consistent across all event data shared with Assetario. | a3kh-asd3-vjf8-984v |
| identifier | timestamp / time\_stamp | The unique identifier for the timestamp column. Include the format, e.g., YYYY-MM-DDThh:mm:ss+00. | 2021-01-01T12:12:12+00 |
| identifier | payment / USD\_purchase / iap\_purchase | Identifier used by Assetario to compute total spend per player, etc. | 9.99 |
| identifier | offer\_id / product\_id / package\_key | Unique identifier for IAPs. Ideally consistent across related events like IAP purchase event, IAP view event, and IAP offer store. | 1234565 |
| identifier | model\_type | Model name of the device used for user login. | iPhone14,5 |
| identifier | manufacturer\_name | Manufacturer of the user's device. | apple |
| identifier | os\_type / os\_name / os | Operating system name of the device used for user login. | iOS |
| identifier | country / player\_country | ISO2 or ISO3 name of the country from which the user logged in. | US / USA |
| identifier | abtest\_name | Name of an A/B test a user is part of. | new\_ui\_test |
| identifier | abtest\_group | Name of each group in the A/B test. Typically includes a control group and the group being tested with a new treatment during the A/B test. | control / personalized |
| identifier | first\_event | The first event triggered when a new user joins the app. | appsflyer\_install\_complete |
| table | new\_user / first\_login\_table / login\_table | Table used to identify the first login of each user. Enables attribution of installs to specific dates and counting new users over time periods. | - |
| table | payment\_table / af\_payment\_complete / iap\_purchase | Table containing all IAP payment data for all users. | - |
| table | login / session\_start | Table containing all login or session start data for all players. | - |
| table | tests / experiments / abtest\_table | Table with details on all the A/B tests each user participates in. | - |
## Blacklist
Assetario would appreciate a comprehensive list of known tester and hacker user IDs from the customer at the time of data exchange. This enables Assetario to exclude these users from analyses, evaluations, and A/B tests. We request this data be updated and shared regularly, akin to other event data.
| user\_id \[String] | Tester or Hacker \[Bool] |
| ------------------ | ------------------------ |
| 1234556 | True |
| 6666666 | True |
| **user\_id \[String]** | **Tester or Hacker \[Bool]** |
| ---------------------- | ---------------------------- |
| 1234556 | True |
| 6666666 | True
|
---
# Agent Instructions: 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://docs.assetario.com/docs/integration/data-requirements.md?ask=
```
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.