Impact Radius has performance metrics — impressions, clicks, and other cost — that live only inside their reports rather than the standard API endpoints we already extract. Merchants who want those metrics flowing into Daasity for vendor performance reporting, cross-channel marketing analysis, or custom dashboards can now opt in to a new report extraction.

Added opt-in extraction of the report from Impact Radius using their asynchronous ReportExport API. For enabled integrations, Daasity requests the report per campaign (via the parameter) on a rolling 30-day window, polls until Impact Radius finishes generating it, then downloads the paginated results, transforms them, and loads them into your warehouse. Existing Impact Radius extraction is unaffected.

No change for merchants not opted in. For merchants who want this enabled, contact support to turn it on — the new report data will populate alongside your existing Impact Radius tables and unlocks impressions, clicks, and other-cost metrics for ad-level performance analysis by partner and date.

The Google Ads Product Performance report has been restructured to correct a data accuracy issue at the original grain and to better align with how performance is attributed at the campaign + product level. In the same release, Google Ads admins can now choose which of the five Google Ads report types they want extracted, bringing the integration in line with our newer integrations.

The previous table has been renamed to and preserved as-is. A new table replaces it at the corrected grain (campaign + product + date), with the , , , and dimensions removed — those dimensions were the source of the duplication and inflation issues. The sync key has been simplified to . A three-year history load was kicked off for all active Google Ads integrations following release. Separately, the Google Ads integration edit page now exposes a resource picker where admins can select which of the five report types (ads,

Klaviyo can capture a wide range of custom metric events beyond standard email engagement — Back in Stock subscriptions, Loop Returns activity, Okendo events, Wonderment delivery events, and more — but historically those events weren't flowing into Daasity. We've added a self-serve way for merchants to select which additional Klaviyo metrics they want extracted, with a one-click historical backfill when new metrics are added.

On the Klaviyo V2 integration edit page, merchants can now select additional metrics to extract alongside the standard email engagement events. Selected events flow into a new table, with the field stored as a raw JSON blob to handle the arbitrary field shapes of custom metrics. When new metrics are added to the integration, a modal prompts the user to load historical data for all of them in a single click.

Existing event extraction is unaffected — the standard email engagement events continue to flow into as before. To bring in custom events, edit your Klaviyo V2 integration, select the metrics you want, and confirm the backfill prompt. Custom events will populate the table, where analysts can parse the JSON field downstream based on the specific metric. No action is required if you don't need custom event extraction.

Klaviyo's regular campaigns endpoint now supports push notification campaigns — a capability that didn't exist when our Klaviyo V2 integration was first built. We've extended the integration to extract push campaigns alongside email and SMS, with the same field coverage. The Klaviyo API has also been advanced to the 2026-01 version in the same release.

The Klaviyo V2 extractor now pulls push campaign metadata into the campaigns table with the same attributes captured for email and SMS — closing a gap where push performance data was available in Summary Statistics but with fewer fields. The integration has also been moved to Klaviyo's 2026-01 API version.

Push campaigns will appear in your Klaviyo V2 campaigns reporting alongside email and SMS once the capability is enabled on your account. Enablement is currently a manual step handled by a Daasity engineer — contact support if you'd like push extraction turned on. Existing email and SMS campaign extraction is unaffected by either change.

The free-text comment customers leave when initiating a return through Loop is now available in your warehouse. Previously this data was visible only inside Loop's UI — with this release it flows into Daasity for analysis alongside the rest of your returns data.

We added the return_comment field to the loop_returns.return_lines table. The field captures the comment a customer submits at the return-line level — the qualitative "why" behind each returned item, in their own words.

The new field will populate on the next workflow run and is immediately available for analysis — useful for surfacing common return reasons, flagging product quality issues, or feeding customer service follow-up workflows. Existing return metrics and tables are unaffected. No action is required — the update rolls out automatically.

Shopify is rolling out a platform-wide Markets update that becomes mandatory on April 1, 2026, and the market field on is being deprecated as part of it. To keep market-level analytics intact for Shopify B2B merchants, we've added a dedicated Markets extraction so the data continues to flow once Shopify removes the field. This release applies to Shopify B2B merchants only.

Market data is now extracted into two new tables in your warehouse: and . Analysts can join markets to company locations by country code ( → → ). Each market also carries an flag, which replaces Shopify's deprecated "primary market" concept and gives analysts a defined fallback when a shipping address doesn't match any market region. The extraction uses Shopify's current, non-deprecated API path, and is now enabled by default for all Shopify B2B merchants, including Shopify Plus.

Two new tables will populate on the next workflow run and be available for use in reporting. Your existing data is unaffected. No action is required — the update rolls out automatically.

Two base scripts were producing duplicate records on each refresh, affecting reporting accuracy. The first fix applies to BigQuery merchants using GA4 data. The second applies to all Snowflake and Redshift merchants, as well as BigQuery merchants with the Retail workflow enabled.

The GA4 shopping stage script had outdated logic that no longer matched its Snowflake/Redshift counterpart, generating duplicate rows on every refresh. Separately, the Omni time period mappings script had an incorrect configuration that caused records to multiply across daily refreshes on both BigQuery and Snowflake/Redshift.

The GA4 shopping stage script has been corrected to align with the current Snowflake/Redshift logic. The Omni time period mappings scripts have been corrected on both BigQuery and Snowflake/Redshift to eliminate the duplicate records.

You may see slight adjustments in reports referencing GA4 shopping data or time period mappings as duplicates are removed — this is expected and reflects accurate data. BigQuery merchants may also see modest efficiency improvements in their workflow runs. No action is required — the update applies automatically.

When the same item on the same order had been returned more than once, our deduplication step could keep the wrong record if any return event came in from Loop without a timestamp. We've corrected the logic so the legitimate, most recent return is always retained.

For items returned more than once on the same order, Daasity uses a deduplication step to keep only the most recent return record. If one of those return events arrived from Loop without a timestamp populated, the timestamp-less record could incorrectly win the dedup and replace the legitimate, more recent record — leading to slightly inaccurate historical return metrics for those orders.

We corrected the deduplication logic so legitimate, timestamped records are always retained over records missing timestamps. Historical data recalculates automatically with the release on May 5th.

If any of your returns fit the pattern — same item, same order, returned more than once, with at least one return missing a timestamp from Loop — your historical return metrics may shift slightly after May 5th. The updated numbers will be more accurate. If your Loop data is clean and timestamps are populated, you won't see any change.

No action is required — the update rolls out automatically.

Discount totals in reports built from the Order Line Revenue Explore were not reconciling to Shopify's reported totals on orders that included shipping discounts. We've corrected the calculation so totals now match.

When an order combined a product discount with a shipping discount, the line-item calculation was treating the shipping component in the wrong direction. Both line-level and order-level rollups within the Order Line Revenue Explore came in lower than what Shopify reports. Orders without shipping discounts, and reports built from other explores, were not affected.

We corrected the calculation so all discount components sum together cleanly. Historical data recalculates automatically with the release. Discount totals on impacted orders will adjust to match Shopify — this is expected and reflects your actual data.

No action is required — the update rolls out automatically.

In February, Amazon stopped providing buyer email addresses in certain seller data feeds and deprecated its v0 Orders API. These changes impacted Daasity's ability to accurately identify customers for Amazon orders. We've deployed fixes for FBA orders and migrated to the new Orders API. FBM orders remain partially impacted.

For FBA orders, buyer email, buyer name, and shipping name are now supplemented with data from the FBA Amazon Fulfilled Shipments Report when the primary source is missing a value. Daasity has also migrated to the Orders v2026-01-01 API — table structures are unchanged, though some field values may differ per Amazon's migration guide.

FBA customer identification will be more accurate — you may see minor shifts in customer counts or profiles as previously unmatched records are now correctly attributed.

FBM customer-level reporting (new vs. returning, LTV) may be less reliable for orders after February 11th. Retrieving buyer email for FBM orders requires a restricted Amazon API role that Daasity applied for but was not approved for. We are reviewing next steps and will provide an update when a resolution is available.

No action is required, but if you notice data gaps or have questions, contact support@daasity.com.