Data 360: Understanding Credit Consumption for Data Federation

Acceleration Enabled

When Acceleration is enabled, Data 360 performs batch ingestion by caching data from the external source into a data lake object. This means that records are periodically ingested into Data 360 based on your configured refresh settings.

Usage Type: (External) Batch Data Pipeline

Important Considerations:

• Enabling Acceleration automatically turns on caching, as documented in the Caching in Data Federation article:

Caching retrieves data from the external source and temporarily stores it as a data lake object in Data 360. When you enable acceleration while creating a data stream, you turn on caching. 

• To optimize consumption, configure incremental refreshes by:

  • Editing the data stream post-deployment.

  • Selecting a record modified field (timestamp).

  • Setting an appropriate refresh frequency.

Acceleration Disabled (Zero Copy Federation)

When Acceleration is not enabled, Data 360 uses a Zero Copy model where data is queried live from the external source and not ingested.

Usage Type: Data Federation or Sharing Rows Accessed

Key Notes:

• Data is retrieved only when queried through dashboards, data streams, the query editor, Data Explorer, or similar components. There is no persistent storage of this data within Data 360 itself — it is displayed on demand, directly from the external source.

• Since the data isn’t ingested into Data 360, it’s not stored — instead, it remains in the source system (like Snowflake) and is accessed live when needed.

• Charges are applied based on the number of records accessed. “Accessed” records include any rows scanned or touched by the query on the external system 

• Accessed data is only for Zero Copy federation, meaning data is queried directly from the source and rendered on the page or component. In this case, charges are based on rows "Accessed" by the query.

Example: Understanding Credit Consumption Using Segments with BYOL Sources

To illustrate how credit consumption differs based on whether Federation data is Accelerated or not, let’s walk through two segment scenarios.

Non-Accelerated (Zero Copy) Federation Example:

Imagine you’ve built a segment called “High-Value Repeat Customers” using the following filters:

• Customers who made more than 5 purchases in the last 6 months

• Customers with a lifetime value above $1,000

If this data comes from a BYOL external source without Acceleration, it means:

• The segment relies on live queries to the external object (e.g., Snowflake)

• Each time the segment is previewed, refreshed, or activated, a query is executed live

• All rows that are scanned or touched by the query (even if later filtered out) are counted as “Accessed”

• You are billed based on the total number of rows accessed in the external system

This setup provides real-time data access, but may result in higher credit usage if segment queries are frequent or data volumes are large.

Accelerated Federation Example:

Now let’s say you have another segment: “Recent App Installers in California”, with filters for:

• Users who installed the app in the last 30 days

• Users located in California

If this external data source is Accelerated, here’s how things change:

• Data is ingested into Data 360 at a scheduled interval

• Segment queries are executed on the cached Data Lake Object

• There are no live queries sent to the external source during segment refresh or activation

• You are charged only during the ingestion, based on the number of rows processed. However, when evaluating Segments, Segmentation credits will still apply, as the system needs to process records from this table to evaluate the population count.

To optimize credit usage with Acceleration, make sure to include a modified date or timestamp in your Data Stream setup. This allows for incremental refreshes, avoiding full ingests every time.