Packages and Platforms
Platform | Plan |
Non-platform | All |
Shopify | Add-on |
Salla | Add-on |
Overview
The Data Warehouse Ingestion Module allows you to push selected loyalty data directly into your own data warehouse. This enables you to combine Gameball data with data from other business systems and analyze everything in one centralized analytics environment.
This feature was designed primarily for you if you already rely on internal dashboards and BI tools (such as PowerBI, Metabase, or similar) for daily reporting and decision-making.
Instead of building and maintaining analytics separately inside each tool, businesses can centralize their data in a data warehouse and build unified dashboards across all systems.
Why This Feature Exists
Most large organizations already store their operational data in a data warehouse, which acts as a single source of truth. Data from multiple systems—such as order management, inventory, CRM, and communication tools—is pushed into the warehouse and then consumed by analytics tools.
With the Data Warehouse Ingestion Module, Gameball becomes part of this ecosystem. You can now:
Combine loyalty data with revenue, inventory, and customer communication data
Build cross-system dashboards in one place
Run advanced analysis without relying solely on Gameball’s in-dashboard reports
How You Typically Use It
A common setup looks like this:
Order / POS system (e.g. Microsoft Dynamics) → pushes revenue and order data
Inventory management system → pushes stock and product data
Customer engagement platform (e.g. Braze) → pushes communication and campaign data
Gameball → pushes loyalty and rewards data
All of this data is stored in the data warehouse, and an analytics tool (such as PowerBI or Metabase) reads from it to create dashboards.
This allows you to answer questions like:
How does revenue trend by loyalty tier?
How many points were earned from completed orders?
What is the distribution of customers across tiers?
How do loyalty actions correlate with repeat purchases?
Available Gameball Data Models
Gameball currently provides four built-in data models that can be pushed to a data warehouse. You can choose which models to enable during setup.
1. Customers
Contains customer-level loyalty data, including:
customer_unique_id | Customer identifier from the client's external system, used for integration and mapping between systems. |
display_name | Customer's display name as shown in the loyalty program interface. |
is_migrate | Integer flag indicating if this customer was migrated from another system (1 = migrated, 0 = native). |
referred_by_unique_id | Customer identifier of the person who referred this customer, if applicable. |
referral_activation_date | Date when the customer's referral was activated and confirmed. |
is_referred_customer | Integer flag indicating if this customer was referred by another customer (1 = referred, 0 = not referred). Derived from referral_activation_date. |
current_tier_name | Current loyalty tier/level name the customer belongs to. |
current_tier_order | Current loyalty tier/level order the customer belongs to. |
customer_points | Current number of loyalty points the customer has available for use. |
total_earned_points | The lifetime amount of points that the customer have earned |
total_redeemed_points | The lifetime amount of points that the customer have redeemed |
total_expired_points | The lifetime amount of customer's points that have been expired |
customer_score | Current customer score (frubies) value the customer has accumulated. |
customer_pending_points | Points that have been earned but not yet activated or confirmed for the customer. |
tier_entry_date | Date when the customer entered their current loyalty tier. |
customer_type | Customer lifecycle state: Registered (full customer profile) or Guest (limited profile). |
is_included | Integer flag indicating if the customer is included in active program participation. |
created_at | Date when the customer record was created in the Gameball platform. |
updated_at | Date when the customer record was last updated. |
is_deleted | Is this a deleted row |
This model is useful for segmentation, tier analysis, and customer-level reporting.
2. Transactions
Represents all points and order-related movements, including:
Transaction ID
Points earned from orders
Points redeemed
Points expired
Transaction type
Direction (points added or deducted)
Related transaction details
gameball_transaction_id | Unique identifier for the transaction |
transaction_id | Unique Identifier for the transaction in the client system |
customer_unique_id | Identifier of the customer who did the transaction |
merchant_name | The merchant name where this transaction happened |
branch_name | The branch name where this transaction happened |
transaction_type | The type of the transaction cashback, redemption, expiry, etc. |
direction | The direction of the points transactions + or - |
tier_name | The name of the tier the customer was on when this transaction happened |
tier_order | The order of the tier the customer was on when this transaction happened |
points_amount | The amount of points in the transaction |
points_used_amount | The amount of points that has been used from this transaction (for positive only) |
redemption_factor | The factor used to calculate the value of points (in postivie transactions its the value when the transaction happened but for negative transaction its the actual factor used to calculate the points value when it was used) |
points_value | The value of the points (in postitive transactions its the value of the transaction happened depnding on the redemption factor back then but for the negative transaction its the actual value when the points was used |
transaction_status | The status of the transaction active or pending (for positive only) |
points_expiry_date | The date when the points will expire (for positive only) |
created_at | Timestamp when the transaction record was created in Gameball |
updated_at | Timestamp when the transaction record was last updated in Gameball |
is_deleted | Is this a deleted row |
This model allows customers to analyze how points are earned and spent over time.
3. Achievements
Includes all loyalty events and campaign-related actions, such as:
gameball_achievement_id | Unique identifier for the achievement event |
customer_unique_id | Identifier of the customer who earned the achievement |
achievement_type | Broader grouping of the achievement type (e.g., Level, Campaign, Referral, Transaction, Manual) |
achievement_sub_type | Detailed classification of the achievement type such as Level, Challenge, Milestone, Quest, Referral, Purchase Reward, or Manual action. |
campaign_name | Identifier of the campaign associated with the achievement event |
is_coupon_rewarded | Indicates whether a coupon was issued as part of the achievement |
current_tier_name | Customer’s current tier name at the time of achievement |
current_tier_order | Customer’s current tier order at the time of achievement |
achieved_tier_name | The name of the tier reached by the customer if the achievement type is related to tiering progression |
achieved_tier_order | The order of the tier reached by the customer if the achievement type is related to tiering progression |
achieved_points | Number of points earned from this achievement event |
points_value | Monetary equivalent of the achieved points in the client’s currency |
achieved_score | Score gained from this achievement (if the leveling method is based on score) |
created_at | Timestamp when the achievement record was created in Gameball |
updated_at | Timestamp when the achievement record was last updated in Gameball |
is_deleted | Is this a deleted row |
Each record includes details like campaign name, achievement type, and related metadata. This data closely matches what is available today in Gameball’s activity logs and reports.
4. Coupons
Contains coupon-related data, including:
gameball_unique_id | Unique Identifer for each coupon per customer per assignment |
coupon_code | The actual coupon code that customers use to redeem the offer. |
customer_unique_id | Foreign key identifying the customer who received this coupon assignment. Used as the distribution key for optimal Redshift query performance. |
coupon_type | Coupon discount mechanism: Fixed (fixed amount), Percentage (percentage discount), Free Shipping, Free Product, Store Credit, etc. |
coupon_source | Source usage context: Online, POS (Point of Sale), Permanent, Reward Campaign, or Automation. |
coupon_sub_source | Source or origin of the coupon creation. Campaign, Reaching a Tier, Referral, Automation |
amount | Discount amount - interpretation depends on coupon_type. For fixed types, this is the actual discount amount (e.g., $10). For percentage types, this is the percentage value (e.g., 10 for 10%). |
total_paid_amount | Total monetary value (in client's currency) across all orders where this coupon was applied. Only populated for used coupons (is_used = 1). NULL if the coupon has not been used or was used for non-monetary rewards (e.g., free products). Note: The same coupon can be used across multiple orders by one or multiple customers. |
total_order_count | Total number of orders where this coupon was applied. Only populated for used coupons. 0 or NULL indicates the coupon was either not used or used for non-order rewards. Values > 1 indicate the coupon was used multiple times (if multi-use enabled). |
current_state | Current lifecycle status of this coupon assignment. Possible values (in priority order): 'deleted' = Coupon assignment has been deleted (highest priority), 'expired' = Coupon passed its expiration date without being used, 'used' = Coupon was successfully redeemed by the customer, 'assigned' = Coupon is active and available for use (default state). State priority ensures accurate categorization when multiple conditions could apply. |
created_at | Timestamp when the coupon was originally created. |
updated_at | Timestamp when the coupon was last updated. |
is_deleted | Is this a deleted row |
This model supports reporting on reward redemption and coupon usage.
Example Use Case
You may want to build a dashboard showing:
Revenue from your order management system
Points earned from those same orders (from Gameball)
By joining order data from your POS system with transaction data from Gameball inside the data warehouse, you can create a single dashboard that visualizes both revenue and loyalty performance together.
How to Set Up the Integration
To configure the Data Warehouse Ingestion Module:
Go to Admin Settings in the Gameball dashboard
Navigate to Data Warehouse Integration
Click Set Up Connection
Step 1: Select Data Warehouse Provider
Choose your data warehouse provider (for example, Amazon Redshift), then click Next.
Step 2: Add Connection Details
Enter the required account and connection details, then click Next.
Step 3: Define Data Push Frequency
Choose how often Gameball should push data:
Daily
Weekly
Monthly
You will also define the exact time (for example, daily at midnight). Please note that higher frequencies come with higher costs.
Step 4: Select Data Models
Choose which Gameball data models you want to push (Members, Transactions, Achievements, Coupons).
Step 5: Submit Request
Once submitted, the request is sent to Gameball’s technical team.
What Happens After Submission
The connection is not established automatically.
The setup acts as a configuration and request flow
Gameball’s technical team manually completes the integration
Once ready, the connection status will change to Connected
After the connection is live, each scheduled data push (daily, weekly, or monthly) will appear in the dashboard with its status and details.
Availability & Enablement
The Data Warehouse Ingestion Module is offered as an add-on.
To use it:
The feature must be enabled on your account
You should coordinate with your Customer Success Manager to start the implementation process