Custom Integrations

Overview​

Statlas offers a custom integration to help you streamline business management and gain valuable insights.

This integration enables you to consolidate order data from various channels, including online orders, phone orders, and in-store purchases. It provides the same robust features and metrics for analyzing business performance as integrations with e-commerce platforms like Shopify and Magento.

Data Transfer​

The integration will be based on the order data you provide. You can deliver the data using one of the following methods:

*The data must include the fields required by Statlas. We can provide detailed information or a guideline as needed. Please feel free to contact us for assistance.

Data Alignment​

• In addition to providing the order data, clients need to specify how the data they provide is used to calculate key metrics such as:
  • Order Count and Order Revenue
  • Gross Sales
  • New vs Returning Order Counts and Revenue
  • Returns
  • COGS
  • Variable Costs
  • Shipping
  • Taxes
  • Discounts

General Settings​

Please let us know some general information required by the integration:

• Currency of data:
  If multi-currency is being used, what is the main currency for reporting? Also, please include a currency field in the feed.
• Timezone of data:
  What is the timezone of the data, and in which timezone is the data normally reported? For example, databases often store data in UTC but report it in the business's local time.
• Any order statuses in your feed that need to be excluded:
  For example, some stores might initially include an order in revenue but later cancel it, requiring it to be removed.

Historical Data & Data Updating​

• How much historical data can you provide?:
  Statlas analyzes historical revenue and ad spend data to do forward-looking predictive modeling.
• How far back can order data change? Does your system close orders from editing after X days?:
  We need to know how far back data we need to pull when we try to sync data with your database. This is important for return data if customers can return items months or years later.

Data Quality Control (Critical)​

• To speed up the quality control process, we would like to ensure we can meet certain data points during the integration.
  • What is the source of truth for revenue reporting?
  • During the initial integration development process, please provide the following information to ensure alignment:
    • Revenue broken down for November 2023 and November 2024
      • Gross Sales (before discounts)
      • Discounts
      • Shipping collected
      • Taxes collected
      • Total Returns
      • Total Revenue (as defined by the P&L)
    • Profit & Loss Statement for Nov 2023 and Nov 2024

Historical Data in Predictive Modeling​

• When developing predictive models, it’s essential to consider the store's historical performance to forecast future outcomes. However, certain timeframes may need to be excluded or treated differently due to exceptional circumstances. Below are examples of such cases that may require adjustments during modeling:

  • Inventory Shortages: Events such as the Covid-19 supply chain disruption may have caused significant inventory shortages, which led to stores either halting or significantly reducing sales for extended periods. It’s important to account for these periods when evaluating past performance.

  • System Migrations: Any instances of system migrations that resulted in data loss should be identified and excluded, as they could skew historical data and affect model accuracy.

  • Major Business Changes: Significant strategic shifts, such as a transition to a subscription-based model, could fundamentally alter key metrics like the balance of new versus returning customers. These periods should be treated separately to avoid misleading conclusions about trends.

  • Price Increases: Major price hikes can impact metrics like Average Order Value (AOV) and Cost per Acquisition (CPA). It’s crucial to determine if these changes occurred naturally or as a result of the pricing adjustments, as this could affect the predictive power of the model.

Revenue Definition​

We are flexible in how revenue is defined, though it is typically calculated as:

Revenue = Sales + Shipping + Taxes - Returns

For consistency with marketing spend, we generally define revenue based on the order date rather than the ship date.

Cost of Goods Sold (COGS)​

Statlas offers several options for inputting COGS data. Our goal is to provide a directionally accurate picture of Contribution Margin rather than being precise to the exact penny, as we are not an accounting software. Below are the available methods to feed COGS into Statlas:

1. Line-Item Level COGS (Most Accurate): Include a COGS field at the line-item level in the order data. This option allows us to accurately track changes in costs and prices over time for different products.

2. SKU-Level COGS: Provide a feed of your SKUs with associated COGS information. We track historical SKU-level COGS, so any changes will be captured.

3. Order-Level COGS: Include a COGS field at the order level in the order data. Statlas will make its best estimate of the line-item costs based on this.

4. Flat-Rate COGS: For simplicity, you can apply a flat-rate COGS across all models and reports.

Cost of Delivery (COD)​

We are currently in the process of expanding our Cost of Delivery (COD) management capabilities. At present, Statlas offers two basic approaches for handling COD. More advanced options will be developed and made available in the future.

1. Configurable COD Settings
   Statlas allows users to define COD costs using a combination of the following components:
   • Fixed monthly fee (e.g., $15,000/month)
   • Variable cost per order (e.g., $2/order)
   • Percentage of sales (e.g., 3% of sales)
2. Net-Zero Assumption for Shipping
   Alternatively, you may opt to simplify delivery cost accounting by assuming that shipping fees collected and shipping expenses incurred offset each other. Both values are treated as net zero, effectively removing their impact from financial calculations.

Return Data​

Statlas offers two primary methods for managing return data, depending on the quality and consistency of available return information.

1. Return Data Feed Linked to Original Orders
   When return data is reliably available, Statlas can ingest returns that are explicitly tied to the original order. This approach enables detailed customer-level insights, including:
   • What items were originally ordered
   • Which items were returned
   • The time elapsed between the original order and the return
2. Fixed Return Rate Assumption
   For stores where return data is either inconsistent or subject to significant delays, it may be more practical to apply a fixed return rate as an accrual. This simplified approach estimates returns as a flat percentage of sales, helping maintain reporting continuity without relying on complete return feeds.

Optional Data and Reports​

The following data sets are optional, but if they are important to your business operations, we highly encourage you to provide them. They enable more accurate reporting and optimization within the Statlas platform:

1. Inventory Data Used to prevent promotion or analysis of out-of-stock products.

2. Hourly Order Data While the standard order feed includes timestamps, providing an hourly or frequently updated feed enables us to calculate more granular and time-sensitive metrics.

3. Product Details (SKU & Category Mapping) Detailed product information—such as product name, SKU, and category—is essential for comprehensive product-level reporting and analysis.

First-Time vs. Returning Order Definition​

Statlas defines a first-time order as a new-to-file. In other words, the first valid transactional order associated with a customer is treated as their first order. This definition is critical for accurately calculating customer Lifetime Value (LTV) and enabling predictive retention modeling.

To ensure alignment, we would like to understand the following:

• Do you currently track new customers?
• What do you use as a customer identifier? (e.g., email address, unique ID, or a combination of fields)
• Would you have any concerns with adopting Statlas’s definition of a first-time order?

Sales Channels​

In Statlas, the term "Sales Channels" is used broadly to support various use cases. A typical implementation involves categorizing sales by channel type, such as:

• Online Sales
• Point-of-Sale
• Wholesale
• Amazon
• TikTok Shops

This breakdown allows us to analyze each channel independently and, if needed, exclude specific channels from marketing analytics or forecasting models. Another common use case is regional segmentation, such as separating sales data for the U.S. and Canada.

To proceed effectively, we’d like to understand:

• Is there a logical or existing breakdown of revenue that fits your business? (e.g., by channel type, region, brand, etc.)
• Are there any sales channels that should potentially be excluded from analytics or forecasting in the future?

Personally Identifiable Information (PII)​

Statlas uses either email or customer ID to calculate customer-level lifetime value metrics. We don’t need or use any other PII. We can hash customer data on your behalf or you can hash it before sending it to us.

To ensure alignment, please let us know:

• Do you have any concerns or restrictions regarding the handling of PII?

Special Circumstances​

Based on our experience working with hundreds of businesses, we understand that there are often unique edge cases that may not fit standard data models. Some examples include duties/VAT considerations, promotional giveaways, gift cards or other unearned revenue situations, special subscription models, etc

To ensure accurate analysis and reporting, we’d like to ask:

• Are there any special circumstances or business rules we should be aware of when working with your data?

Identifying these early on helps us tailor our approach and avoid misinterpretation of key metrics.