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.

Merchants on BigQuery can now access transformed TikTok and Pinterest paid advertising data through the UMS layer.

Added BigQuery-compatible UMS transformation scripts for TikTok (spend and vendor performance) and Pinterest paid results. Data is now processed through the standard UMS pipeline — including currency conversion, store association, and daily spend rollups into the cross-channel marketing spend table — for merchants whose warehouses run on BigQuery.

TikTok and Pinterest data will now appear in UMS reporting for BigQuery-based merchants. No action is required.

An issue with how Loop Returns data was being processed caused return figures in the Returns dashboard to be under-reported. This fix applies to BigQuery merchants only.

Some return records were being excluded during daily updates, causing the Returns dashboard to display lower numbers than expected.

We corrected the data processing logic so that all return records are accurately captured during each update cycle. Returns dashboard numbers may increase slightly as previously missing records are restored — this is expected and reflects your actual returns data. No action is required.

Subscription counts in the Subscription Monthly Churn Rates explore were appearing higher than what you see in Recharge. We've corrected this and introduced a clearer way to view subscription data at the level that matches Recharge.

The Subscription Monthly Churn Rates explore was reporting subscription counts at the product level rather than the customer level. This meant customers subscribed to multiple products were counted more than once, causing active subscription counts, new subscriptions, and churned subscriptions to appear inflated compared to what you see in Recharge.

We made two changes. First, the existing Subscription Monthly Churn Rates explore has been renamed to Subscription Monthly Churn Rates – Product Level, with the product dimension now visible, clarifying that it reports at the month + product level. Second, we created a new Subscription Monthly Churn Rates – Aggregated explore that reports at the month level, matching the subscription counts you see in Recharge.

Merchants should review the following:

Recharge extractions were hitting API rate limits, triggering throttling errors that caused workflows to run significantly longer than expected.

The Recharge extractor now implements rate limit handling aligned with Recharge's API constraints, including automatic retry logic with backoff when a rate limit is encountered.

Recharge workflows should complete faster with fewer interruptions. No action is required.

GA4 extractions were paginating at 1,000 rows per API call instead of the allowed maximum, generating excessive API requests and causing rate limit issues for high-volume merchants.

The default page size has been increased to 250,000 rows per API call, significantly reducing the number of requests required per extraction. The page size is also now configurable per integration for merchants with specific needs.

GA4 extractions will complete faster and with fewer API calls. No action is required.

A specific NetSuite permission error was not being caught during pre-launch checks, leaving merchants without a clear explanation when their account lacked access to SuiteAnalytics Connect (ODBC). The error is now detected automatically and surfaced with actionable guidance.

The pre-launch validation for NetSuite datasources now detects the SuiteAnalytics Connect permission error and returns a clear message directing merchants to their NetSuite administrator to enable access.

If your NetSuite account does not have SuiteAnalytics Connect enabled, you will now see a specific error message during setup rather than a generic failure. No action is required unless you encounter this error — if you do, contact your NetSuite admin to enable SuiteAnalytics Connect and grant your user the appropriate permissions.