Resonate Install: Operating the Recurring Refresh

This article describes what to expect, and what to do, on each refresh of your Install after the first delivery. Once your destination is set up, the recurring refresh is a steady-state operation — but a few specifics are worth knowing up front to avoid surprises.

What arrives in each refresh

Each refresh delivers a complete, full-replacement set of files into your destination. The files are structurally identical to your prior delivery — same schema, same ID formats, same companion files. The contents reflect the most recent wave of Resonate consumer data.

Records may be added to or removed from the universe between waves as the underlying identity graph evolves. Attribute predictions for the same ID may shift between waves to reflect updated signal. Your downstream pipelines should treat each refresh as a full reload of the population, not an incremental update against the prior file.

When to expect each delivery

Deliveries arrive on an 8-week cadence, anchored to your first delivery date. If your first delivery is on April 15, subsequent deliveries arrive in mid-June, mid-August, and so on — each within five business days of the corresponding wave release.

If your data operations team schedules pipeline runs against expected delivery dates, plan against the anchor date pattern rather than a fixed calendar date — the actual delivery day-of-month is determined by when your engagement was activated, not by a Resonate-wide refresh date.

The bi-monthly cadence is fixed by Resonate's wave release schedule and is not configurable on a per-customer basis. If your use case requires real-time or near-real-time data — website personalization at high frequency, inbound channel response, or IVR — the right architecture is Resonate's API-based delivery rather than a file Install. Talk to your account team if you're uncertain which is the better fit.

Validating each refresh

Resonate validates every Install delivery internally before it ships. This includes record count, ID format, attribute completeness, sensitive-data suppression, wave consistency, and Key Definitions File alignment. Deliveries that fail internal validation do not ship to customers.

On your side, the Summary Report is the reference for confirming the contents of each delivery. Compare its per-attribute counts and percentages against what your downstream pipeline ingests as part of your standard verification routine. After your first two to three refreshes, you'll have an empirical baseline for what's normal in your engagement; subsequent refreshes can be compared against that baseline.

When something looks different

Some variation between refreshes is expected and reflects the underlying signal — not a problem with the delivery. Here's what's normal:

• Record counts change between waves. The Resonate consumer universe isn't static. IDs are added as new people are detected in the identity graph; IDs are removed as records age out or no longer meet inclusion criteria. Modest wave-over-wave changes in total record count are normal.
• Attribute predictions for the same ID may shift. Each refresh reflects the most recent wave of survey data and updated modeling. A customer scored as "Frequent Traveler = TRUE" in one wave may be scored differently in the next as the underlying behavioral and motivational signal evolves. This is the value of refreshing — your predictions stay current with consumer reality rather than reflecting a static snapshot.
• Attribute fill rates may vary. The percentage of IDs for which a given attribute has a non-null prediction may shift between waves as the underlying model and survey composition evolve.
• The attribute catalog itself may evolve. Attributes are occasionally added, removed, or renamed as Resonate's consumer research expands. The Key Definitions File reflects the current catalog with each delivery.

A delivery that differs substantially from your established baseline — a large drop in record count, a critical attribute appearing as entirely null, or distributions that diverge sharply from what you've come to expect — is worth flagging to your Resonate contact.

If a delivery doesn't arrive on schedule

In the unlikely event a scheduled delivery doesn't arrive within the committed window:

1. Confirm your destination is reachable and that no permissions, credentials, or policies have changed since the prior delivery.
2. Check the delivery location for partial deliveries or files in unexpected locations.
3. Contact your Resonate Customer Success Manager with the wave identifier and your destination details, or email resonatesupport@resonate.com.

Considerations for downstream pipelines

Because each refresh is a full replacement, your downstream pipelines need a strategy for incorporating the new data. Three common patterns:

• Load-staging-swap. Load each refresh into a staging table or schema, validate it, then swap it into the production location and drop the prior version. Most resilient pattern; recommended for warehouses where storage isn't a constraint.
• In-place replacement. Truncate and reload the production table. Simpler; appropriate when consuming pipelines tolerate a brief unavailability window.
• Versioned retention. Retain the prior wave alongside the new one for a defined window. Useful when downstream models or dashboards are validated against a specific wave before cutover.

Whether to retrain downstream models, rebuild segmentation, or re-score audiences on each refresh is a question for your data science and analytics teams. Resonate's recommendation is to align retraining with refresh receipt for any model that uses Install attributes as features, but the right cadence depends on your model's sensitivity to feature drift.

If you have questions about your refresh operations, contact your Customer Success Manager or reach out to resonatesupport@resonate.com.