Trading

General Data Requirements

Before preparing your data tables, please review the following universal formatting rules.

The below represents Optimove's required data schema. If you are unable to provide your data in the requested schema, you will be requested to supply a clear mapping from your schema to the Optimove standard schema as part of the onboarding process. This ensures a smooth data integration and avoids delays.

Data Formatting

  • Decimal Precision: All decimal-type attributes must be rounded to a maximum of four decimal places. For example, a value of 4.56789 must be formatted as 4.5679. This applies to all monetary fields and other decimal values.
  • Currency Conversion: All monetary figures must be converted into a single, consistent currency across all tables.

Required Data Tables

The following data tables describe the content, format and labels of the required data.

  1. Customers – Each row describes the attributes of a single customer
  2. Assets – Assets IDs and their associated textual names and category
  3. Trade – Each row describes trading activity made by the customer
  4. Positions – Each row describes a single position
  5. Transactions – Each row describes a financial transaction

Customers

KeyKey FieldData TypeDescription
PKCustomer_ID**String/IntUnique customer identifier
Registration_Date**DateDate the customer registered
Email*StringMandatory when using Optimail or if required by external ESP
Mobile_Number*StringMandatory if required by external service provider
Date_Of_BirthDateCustomer’s date of birth
Is_OptInStringDetermines whether it is acceptable to send promotional messages to the specified player. Should hold the values 'Yes' or 'No'.
Allow_Email*StringDetermines whether it is acceptable to send promotional Email messages to the specified email address. Should hold the values 'Yes' or 'No'.
Allow_SMS*StringDetermines whether it is acceptable to send promotional SMS messages to the specified mobile address. Should hold the values 'Yes' or 'No'.
Allow_Push*StringDetermines whether it is acceptable to send promotional Push messages to the specified mobile number. Should hold the values 'Yes' or 'No'.
Is_Email_VerifiedStringDetermines whether the email address is verified. Should hold the values 'Yes' or 'No'.
Is_SMS_VerifiedStringDetermines whether the mobile number is verified. Should hold the values 'Yes' or 'No'.
Is_BlockedString'No’ = regular customer; 'Yes’ = blocked customer (e.g. fraud)
Is_TestString'No’ = regular customer; 'Yes’ = test customer
GenderStringCustomer’s gender. Must hold values ‘Male’, ‘Female’, ‘Unknown’
CountryStringCustomer’s country
CityStringCustomer’s city
AddressStringCustomer’s address
First_NameStringCustomer’s first name
Last_NameStringCustomer’s last name
LanguageStringCustomer’s language
BalanceDecimal/IntTotal aggregated balance across all related customer accounts
Brand_NameStringWhen multiple brand platforms exist
Number_of_AccountsIntTotal number of accounts associated with the customer
Number_of_Demo_AccountsIntNumber of demo (training) accounts linked to the customer.
Number_of_Live_AccountsIntNumber of real (live trading) accounts linked to the customer.
Account_TypesStringAccount types associated with the customer, defined as a semicolon-separated string (e.g., CFD;Forex;Crypto)
Account_CurrenciesStringAccount currencies associated with the customer, stored as a semicolon-separated string (e.g., USD;EUR)
KYC_stageStringKYC stage of the customer
AliasStringUser name
CurrencyStringCustomer’s currency
Referral_TypeStringThe method the player was referred to your site (e.g. SEO, Affiliate, Advertising, Marketing, etc.)
Affiliate_IDStringAffiliate identifier or name
Registered_PlatformStringThe platform the customer had registered with (e.g. Web, Android App, iOS App, etc.)
Last_Login_DateDateThe date of the customer’s last login to the website
Allow_WhatsappStringDetermines whether it is acceptable to send promotional WhatsApp messages to the specified mobile number. Should hold the values 'Yes' or 'No'.
LastUpdatedDateDate when the record was last modified or added (Mandatory in case of DB to DB connection)
Is_Optin_Email_Time_Stamp*TimestampDetermines from when it is acceptable to send promotional Email messages to the specified email address in case of approval

Notes:

  • IsOptinEmailTimeStamp* - In case Optimove will manage the “unsubscribe” for the Opti-Mail integration please include additional column to describe when the customer opts in \ out, in order to allow perfect sync with the daily batch.
  • *=Mandatory if required for the execution channel integration
  • **=Always mandatory

Assets

KeyKey FieldData TypeDescription
PKAsset_ID**StringUnique asset identifier
Asset_NameStringAsset name
Asset_CategoryStringAsset category (e.g. Currencies, Indices, Commodities, etc.)
Update_AtDateDate when the record was last modified or added (including status changes)

Note:

  • **=Always mandatory

Positions

KeyKey FieldData TypeDescription
PKPosition_ID**StringUnique position identifier
Customer_ID**StringUnique customer identifier
FKAsset_IDStringUnique asset identifier
Position_Open_DateDatePosition open time
Position_Close_DateDatePosition close time
Position_StatusStringIndication of position status (e.g. Open, Closed)
Is_DemoStringIndicates whether the trade was executed in a demo (training) environment or a live account. Should hold the values 'Yes' or 'No'
LeverageDecimalCustomer Leverage. Shouldn’t be negative.

Note:

  • **=Always mandatory

Trade

KeyKey FieldData TypeDescription
PKTrade_ID**StringUnique trade (transaction) identifier. Each record represents a single trade event
Customer_ID**StringUnique customer identifier associated with the trade.
FKAsset_IDStringUnique asset identifier
ActionStringType of trade action performed (e.g., Open, Increase, Close)
DirectionStringTrade direction
Customer_ProfitDecimalProfit or loss realized from this specific trade
Net_Revenue**DecimalNet revenue generated by the customer from this trade. Usually calculated as: Spread + Commission + Swap Revenue – Bonuses – Adjustments
PlatformStringThe platform used to open the position. Should hold ‘Web’, ‘Mobile’
FKPosition_ID**StringUnique identifier linking this trade to the related position
Is_DemoStringIndicates whether the trade was executed in a demo (training) environment or a live account.
Investment_Amount**DecimalThe notional amount or value (in USD or account currency) involved in this trade.
Trade_date**DateThe date when the trade was made
Last_UpdatedDateDate when the record was last modified or added (Mandatory in case of DB to DB connection)

Note:

  • **=Always mandatory

Transactions

KeyKey FieldData TypeDescription
PKTransaction_ID**String/IntUnique transaction identifier
FKCustomer_ID**StringUnique customer identifier
Transaction_Date**DateTransaction date
Transaction_TimestampTimestampTransaction Timestamp
Transaction_Type**StringTransaction type. Should hold values 'DEPOSIT', 'WITHDRAWAL', or 'BONUS'
Transaction_Amount**DecimalMonetary value of the transaction.
PlatformStringPlatform from which the transaction made (e.g. Web, Mobile, Download)
Status**StringTransaction status (e.g. Approved, Rejected, Pending). Must have status ‘Approved’ for approved transactions.
Last_UpdatedDateDate when the record was last modified or added (Mandatory in case of DB to DB connection)

Note:

  • Any other transaction dimension available can be added if needed.
  • **=Always mandatory

Database Schema

Batch-Data Process

Once Optimove successfully receives all historical data, a batch-data update process is required to ensure that Optimove’s data warehouse is updated every day, with the latest available data.

This data extraction process is similar to the method used for the initial historical data delivery, but will include only incremental (new/changed) data.

For additional details about the batch-data process, see Batch data process.

Ensuring Data Integrity

The following points will help ensure the integrity of the data you provide to Optimove:

  1. The primary keys (unique identifiers) that were initially defined for each table must remain present and consistent in files delivered daily, without Null values. Please avoid duplications on the primary key level.
  2. When providing historical data, ensure that data for the entire date range is provided. If this is not possible, inform Optimove in advance of any dates missing from the date ranges provided in each table.
  3. It is important that all identifiers in all transactional tables exist in the relevant DIM table. For example, all game IDs in the Games table must appear in the Game Types and Categories table, or all product IDs in the Orders table must appear in the Catalog table.
  4. It is important that all customer IDs that appear in the transactional and fact tables also appear in the Customers table. Only customer IDs appearing in the Customers table will be included in Optimove.
  5. Every change made to the data schema must be brought to Optimove’s attention in advance. Uncoordinated schema changes will cause the batch-data process to fail.
  6. Do not include any retroactive data (older than initially agreed upon) in the batch-data tables. If you feel it is necessary to do so, coordinate with Optimove in advance.
  7. Do not use any default dates such as ‘1900-01-01,’ instead please use Null (blank in files) as default.

For further explanation see Data QA Processes.

Questions?

We are here to help! Please contact us with any questions, and we will be happy to assist you. Email us at [email protected] or call us (seven days a week from 5:00 am to 8:00 pm GMT) at +972-3-672-4546.