Data Policy

Data Classification

The system classifies datasets into four categories based on data age and ingestion requirements:

• Category A: Real-time data received via any integration method. Data falls under this category if the event timestamp is within 12 hours of the current UTC server time.
• Category B: Any dataset that does not qualify as Category A but is less than 14 days old.
• Category C: Historical data older than 14 days but less than 360 days. This data requires activation by the Product Team before ingestion.
• Category D: Data older than 360 days. Ingestion is not permitted, except for Player Registrations.

Data Ingestion Rules

• Category A & B Data

  • Can be sent via any integration method at any time.
  • Category A data is ingested in real-time, ensuring near-instant processing for reporting, analytics, and segments.
  • Category B data is not guaranteed to be ingested in real-time but is included in reporting, analytics and segments.

• Category C Data

  • Can only be sent during the initial onboarding as a historical data upload.
  • Requires prior notification to product@aretonet.com to initiate ingestion, which can take up to 14 days.
  • Any Category C data sent without prior notice will be discarded.

• Category D Data

  • Automatically discarded, except for Player Registrations.

CRM Data Retention Policy

• All data is retained for 24 months.
• After 24 months, data is archived for a period before permanent deletion.
• Lifetime player analytics are not affected by the retention policy.
• A request can be made to product@aretonet.com to increase the retention period. 

⚠️ Additional costs apply for longer data retention periods.

Special Data Considerations

Player Registrations

• Player registration data classified as Category C or D can be ingested during onboarding after informing product@aretonet.com.

Lottery, Bingo & Parimutuel Events

• Category A, B, or C datasets related to lottery, bingo, or parimutuel events must comply with the data policy.
• Non-compliant event example (Category D):
  • If a wager dated today contains a lottery event from 200 days ago, both the wager and event will be discarded.
• Compliant event example (Category A or B):
  • If a payout dated yesterday includes a parimutuel event from 16 days ago, both the wager and event will be ignored.

Sports Events

• Sports-related payout or wager transactions do not need to follow standard data policy, but must not be older than 1 year.
• Non-compliant example (Category D):
  • A wager dated today referencing a sport event from 2 years ago will be discarded.
• Compliant example (Category A or B):
  • A payout dated yesterday referencing a sport event from 16 days ago will be processed.

Event Processing Rules

Event Order & Processing

• Most data-driven operations (BI, campaign analytics, lifecycle stages, reporting, segmentation) do not require events to be processed in chronological order.
• Journeys using event-triggers, however, depend on event order for correct engagement tracking.
• Example issue:
  • If a Journey trigger is based on a Sign-in event, followed by a wager event, and the wager event is processed first, the system may fail to attribute engagement correctly.
  • Recommendation: maintain chronological order where possible.

Event Timestamps

• All transactions must include a timestamp in UTC (Coordinated Universal Time) format:
  • Format: yyyy-MM-dd HH:mm:ss (24-hour format).
• Timestamps must not be set in the future. A 10-minute threshold beyond the current UTC time is permitted to account for server time differences.

Summary of Key Rules