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.

Sample table with new_user event, which is sent at the time of the first-ever user login.

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