Audience Snapshotting
Learn how Snapshotting keeps a history of your audiences with every export
Overview
Do you know how GrowthLoop helps keep track of your audience changes over time? Itβs all thanks to Snapshotting.
Every time you export an audience, GrowthLoop writes a set of snapshot tables to your data warehouse creating a complete history you can query, compare, and use to power insights like Audience Overlap and Audience Evaluation. With Snapshotting, you can:
- Track when users are added or removed from an audience
- Compare audience composition between exports
- Unlock GrowthLoop features like Audience Overlap and Audience Evaluation
Here are a few key things to know about how it works and whatβs required to use it effectively.
Things to know
- Export triggers snapshotting: When you export an audience, GrowthLoop writes four snapshot tables to the system schema defined in your source connection configuration (commonly named
flywheel_system
, but this may vary based on your setup):- Metadata: General info about the snapshot run
- Snapshot History: Full audience state at the time of export
- Delta History: Adds/removes since the last export
- Unloaded Deltas: Log of runs written to cloud storage
- Full or Incremental updates: For any destination, you can choose whether to:
- Export the full audience every time
- Export only incremental changes (adds/removes) since the last export
- Pre-snapshot checks: Before writing to your warehouse, GrowthLoop runs data integrity checks to ensure there are no duplicates or null values in your primary key.
- Exports only: Snapshots are only created when an audience is exported. If you save or update an audience without exporting it, no snapshot tables will be written. This helps control data warehousing costs by avoiding unnecessary storage.
- Warehouse requirements: Snapshotting requires that your data warehouse connection is active and properly configured, with a system schema defined and GrowthLoop having read/write access. This applies to all supported data warehouses.
Now that you know the key details about how Snapshotting works, letβs take a closer look at each of the snapshot tables and what data they contain.
Snapshotting Table Reference
When Snapshotting runs, it doesnβt just create one table - it gives you four, each with its own job. Think of them as different βanglesβ on your audienceβs history: one for the big picture, one for the fine details, one for just the changes, and one for where things are stored. Let's dive into each one:
Metadata Table
A quick reference sheet for the snapshot run. It tells you when it happened, what audience it was for, the primary keys used, and other high-level details.
Naming Pattern:
snapshotting_audience_id_metadata
Example:
snapshotting_audience_535_metadata
Schema:
Field Name | Data Type | Description |
---|---|---|
_created_at | Timestamp | Timestamp when the record was created |
_external_run_id | String | Unique identifier generated by the client initiating the snapshot |
_snapshot_run_id | String | Unique identifier for the snapshot run |
_key_fields | String | Primary key field |
_key_fields_hashed | String | Hashed primary key field |
_export_ids | String | The ID for the request that triggered the node evaluation |
_control_percentage | Float | Percentage of the audience assigned to the control group |
_base_query_json_hashed | String | Hash of the audienceβs base query in JSON format |
Snapshot History Table
A full record of the audience at the moment it was exported. Every member, every attribute - this is the complete βfrozen in timeβ view.
Naming Pattern:
snapshotting_audience_id_snapshot_history
Example:
snapshotting_audience_535_snapshot_history
Schema:
Field Name | Data Type | Description |
---|---|---|
_created_at | Timestamp | Timestamp for record creation |
_external_run_id | String | A unique identifier generated by the client that initiated the snapshot request |
_snapshot_run_id | String | A unique identifier for each snapshot run |
_snap_hash | String | Internal hash of the snapshot |
_row_hash | String | Internal hash of the row |
_json_row | String | JSON representation of the row |
_is_control | Boolean | Whether customer is assigned to control group |
customer_id | String | Customer ID |
audience_name | String | Name of the audience |
audience_id | Integer | ID of the audience |
flywheel_export_run_id | String | GrowthLoop export run ID |
client_customer_id | String | Client-provided customer ID |
external_id | String | External ID |
customer_attribute | String | Custom attribute value |
_export_id | String | Export ID |
Delta History Table
The βwhatβs newβ file. It only shows the changes since the last export like who was added, who was removed - so you can focus on just the updates without scanning the whole audience.
Naming Pattern:
snapshotting_audience_id_delta_history
Example:
snapshotting_audience_535_delta_history
Schema:
Field Name | Data Type | Description |
---|---|---|
_created_at | Timestamp | Timestamp for record creation |
_external_run_id | String | A unique identifier generated by the client that initiated the snapshot request |
_snapshot_run_id | String | A unique identifier for each snapshot run |
_previous_external_run_id | String | External run ID for the previous snapshot |
_snap_hash | String | Internal hash of the snapshot |
_json_row | String | JSON representation of the row |
_is_control | Boolean | Whether customer is assigned to control group |
_export_id | String | Export ID |
customer_id | String | Customer ID |
audience_name | String | Name of the audience |
audience_id | Integer | ID of the audience |
flywheel_export_run_id | String | GrowthLoop export run ID |
client_customer_id | String | Client-provided customer ID |
external_id | String | External ID |
customer_attribute | String | Custom attribute value |
_export_id | String | Export ID |
Unloaded Deltas Table
A log of export runs that were written out to your cloud storage. If you ever need to track exactly where a snapshot landed, this is where to look.
Naming Pattern:
snapshotting_audience_[AUDIENCE_ID]_unloaded_deltas
Example:
snapshotting_audience_535_unloaded_deltas
Schema:
Field Name | Data Type | Description |
---|---|---|
_created_at | Timestamp | Timestamp when the record was created |
_external_run_id | String | Unique identifier generated by the client initiating the snapshot |
_snapshot_run_id | String | Unique identifier for the snapshot run |
_cloud_storage_uri | String | Location in cloud storage where the data was written |
_export_id | String | Export ID |
Next Steps
Youβve now got the full picture of what each snapshot table does and how they work together. The best way to get comfortable with them? Start exploring.
- Kick off an export and watch the snapshot tables appear in your
flywheel_system
schema. - Take a peek at the data in each table to see how the
Metadata
,History
, andDelta
views connect. - Try a few quick queries to spot changes, track growth, or confirm that exports ran as expected.
Over time, your snapshot history becomes a powerful record, one you can rely on to answer βwhat changed, when, and whyβ for any audience.
Have questions or feedback?
Weβd love to hear from you! Reach out to us at [email protected] and weβll be in touch shortly to help resolve the matter!
Updated about 17 hours ago