Follow up on the latest improvements and updates.

RSS

April 24, 2025

new

Visualization

Calendar V2

*(This feature will be enabled only for Enterprise merchants
 who began using Daasity after September 2023
.)*
Overview 
Time comparisons in Daasity are about to get a big upgrade. 
The new Calendar V2 upgrade is coming out of beta and was released on April 24.
The new Calendar v2 upgrade brings the following improvements:
Easier comparison calculations.
 To compare a measure between periods, all you need to do is choose the measure and one of its companion comparison-period measures and you're done — no more table calculations or additional filtering required.
Plot current & previous periods on the same chart.
  Create the same types of charts you're used to seeing and creating in Shopify, Google Analytics, and Looker Studio.
Simplified calendar dimensions.
 We're going back to the essentials and cutting the available calendar dimensions down by 40% to make an easier, more intuitive experience for the business users on your team.
Here's a quick demo of these new features in action:
How the new time comparisons work
Comparison measures
Calendar v2 introduces new Comp, Change, and % Change companion measures that can be pulled into your reports. This makes it so you don't need to pull in comparison-period label dimensions and use table calculations to create comparison measures.
In this example, if your filter period is the last 7 days and you're analyzing on 2/14:
Total Gross Sales
 = Total Gross Sales for the last 7 days (2/8-2/14)
Total Gross Sales (Comp)
 = Total Gross Sales for the preceding 7-day period (2/1-2/7). You can also use the new Comparison Type toggle to instead compare it to the previous year. In that case, the comp measure would represent Total Gross Sales for 2/8-2/14 of the previous year.
Total Gross Sales (Change)
 = Total Gross Sales minus Total Gross Sales (Comp)
Total Gross Sales (% Change)
 = Total Gross Sales (Change) divided by Total Gross Sales (Comp)
New date filtering
There are two new date filters to use in your reports:
Date (Custom Period)
: Use this if you want to build a comparison period on the fly, e.g.: Last 7 days, Last 2 weeks, a specific date range like 2/1/2025 - 2/5/2025
Date (Preset Periods)
: Use this if you want to use one of our pre-built periods, e.g.: Yesterday, Month to date, Last retail month, Latest 4 weeks. The logic for these preset periods work the same way as the old calendar's "Pivot by" dimensions and are useful for doing apples to apples comparisons. For example, choosing the Month to date preset period will allow you to compare this month to date vs the same period last month, e.g.: 2/1-2/14 vs 3/1-3/14
Compare to Previous Period or Previous Year
Calendar v2 makes it easy to switch between comparing to the previous period or the previous year. By default, the Comp and Change measures compare to the previous period, but you can easily change that using the new Comparison Type
 parameter:
(Click to view full screen)
Getting metadata about the comparison
If you want to see what dates are being compared — either for QAing or just to include in a chart or dashboard — there are two days to do so.
You can use the Show Comparison Date (Yes/No)
 toggle to update the date label to show what date is being used for the comparison:
Or you can add the Date Comparison Info
 dimension to your data table to show the overall dates being compared. This is useful if you want to add a tile to your dashboard that contains meta data about what periods are being used for the comparison:
Will this affect all
 explores?
It will affect the following explores:
Amazon All Orders
Amazon Business Reports - By ASIN
Amazon Business Reports - By Day
Amazon Settlement Report
AppLovin
Daily Company Metrics
Daily Plan to Actual
Daily Plan to Actual Marketing
Inventory Levels
Klaviyo Campaign & Flow Performance
Klaviyo Events
Loop Returns
Marketing Attribution
Okendo Reviews
Order & Order Line Revenue
Shipstation
Shopping Stage
Subscribers
Traffic
Transactional Sales
Vendor-Reported Marketing Performance
What will happen to existing reports?
We're rolling this out in a way so that all of your existing reporting using the old version of the calendar will still work. However, if you want your existing reports to leverage the new Calendar v2 setup, you will need to modify them manually to use the new dimensions and filters. 
The old calendar dimensions will still technically be included in the above explores, but they will be hidden. If you want to re-expose them, you can reach out to our support team — or, if you have developers on your team, you can edit the view_label
 parameter for the retail_calendar
 view in the explores. We have set the view_label
 for the retail_calendar
 view to an empty string, which hides the view from the field picker but still allows them to work. Populating the view_label
 will re-expose the view in the field picker.
How to re-enable the old Calendar dimensions
If you need the old calendar dimensions back, create a generic lkml file in the base_refinements
 folder in your Looker project, and add the following contents to the file:
include: "//base_daasity/views/drp/calendar.view.lkml"
view: +retail_calendar {
  label: "Calendar"
}
What about LookML customizations that I've made?
If you have created refinements or new custom views or explores in your Looker project, you will need to do 2 things after enabling Calendar v2:
Add 2 new joins to any custom explores to include the new calendar v2 view. After enabling Calendar v2, you should do the following joins to your custom explores:
Please Note!
 If the custom explore does not already have a retail_calendar
 join, you will also need to include the //base_daasity/views/drp/calendar.view.lkml
 file and set up a join for it. The instructions below assume that retail_calendar
 is already joined in the explore.
# Add the following include statement to the top of the custom explore file
include: "//base_daasity/views/drp/calendar_v2.view.lkml"
# Add the following joins to the explore
  join: calendar_v2 {
    relationship: one_to_one
    sql: {% if calendar_v2.date_filter_preset._is_filtered %} CROSS JOIN calendar_v2 {% endif %}  ;;
    sql_where: {% if calendar_v2.date_filter_preset._is_filtered %} ${calendar_v2.date_in_period_date} IS NOT NULL {% endif %} ;;
  }
  join: calendar_labels {
    view_label: "Calendar v2"
    from: retail_calendar
    relationship: many_to_many
    sql_on: ${calendar_v2.date_in_period_date} = ${calendar_labels.calendar_date}  ;;
    fields: [calendar_labels.retail_month,calendar_labels.retail_week,calendar_labels.retail_year]
  }
Update any refinements or custom views. You will need to add a filter for any existing measures you want to be able to work with Calendar v2 and will need to create the Comp, Change, and % Change measures for any custom measures you have added. We have created a web app to help you make your custom code compatible with Calendar v2. (It's what we used when we made the existing views compatible with Calendar v2, and it saved us hours.) Just upload or paste your LookML code, and it will make the updates automatically. You may need to make additional tweaks, but it will at the very least do the majority of the work for you.

April 7, 2025

improved

Visualization

Adding dynamic date field to Calendar V2

Calendar V2 now gives the ability to use a dynamic date dimension and control whether that dimension displays the date, week, month, or year. This makes it easy to quickly toggle back and forth between different types of trend charts in your dashboards.

April 1, 2025

improved

Visualization

Enterprise Only

Adding field descriptions

We have added field descriptions to 16 Looker views to provide additional context when interacting with reports.

March 24, 2025

fixed

Transformation

Fix for Other Orders currency conversion

When adding orders to the

Other Orders

BSD with a non-default currency, our transformation code was not properly converting the currency amounts into the default currency. We have updated our code to fix that.

March 20, 2025

fixed

Integrations

Transformation

Updating sync keys in Amazon Ads Sponsored Brand Reports

We have updated how we extract Amazon Ads Sponsored Brands Reports data so that campaign name and ad group name are no longer part of the sync key. This was causing duplicate data issues when a campaign or ad group name was updated.

The effect of this change is that your Amazon Ads reporting in Daasity will align more closely with what you see in your Amazon Ads admin.

We have updated our Amazon Ads Sponsored Brands transform script to include a section that will update historical sync keys and remove any duplicate historical data.

For reference, the following is the code that we are running to update historical sync key data:

-- Clear out test table if it already exists
DROP TABLE IF EXISTS amazon_ads.sponsored_brands_reports_test
;
-- Clone the brands report table into a test table
CREATE TABLE IF NOT EXISTS amazon_ads.sponsored_brands_reports_test
CLONE amazon_ads.sponsored_brands_reports
;
-- Update the sync keys for different report types
-- campaigns
UPDATE amazon_ads.sponsored_brands_reports_test
SET __sync_key = MD5(ARRAY_TO_STRING(ARRAY_CONSTRUCT(
      'campaigns'
      ,COALESCE(campaign_id::STRING, '')
      ,report_date::DATE
      ,profile_id::STRING
    ), ':'))
WHERE 1=1
  AND report_type = 'campaigns'
;
-- ad_groups
UPDATE amazon_ads.sponsored_brands_reports_test
SET __sync_key = MD5(ARRAY_TO_STRING(ARRAY_CONSTRUCT(
      'ad_groups'
      ,COALESCE(campaign_id::STRING, '')
      ,COALESCE(ad_group_id::STRING, '')
      ,report_date::DATE
      ,profile_id::STRING
    ), ':'))
WHERE 1=1
  AND report_type = 'ad_groups'
;
-- keywords
UPDATE amazon_ads.sponsored_brands_reports_test
SET __sync_key = MD5(ARRAY_TO_STRING(ARRAY_CONSTRUCT(
      'keywords'
      ,COALESCE(campaign_id::STRING, '')
      ,COALESCE(ad_group_id::STRING, '')
      ,COALESCE(keyword_id::STRING, '')
      ,COALESCE(keyword_text::STRING, '')
      ,COALESCE(match_type::STRING, '')
      ,report_date::DATE
      ,profile_id::STRING
    ), ':'))
WHERE 1=1
  AND report_type = 'keywords'
;
-- Delete duplicate sync keys from test table
DELETE FROM amazon_ads.sponsored_brands_reports_test
WHERE
 (__sync_key||__synced_at) IN (
    SELECT derived_key FROM (
        SELECT
            __sync_key||__synced_at AS derived_key
            ,row_number() OVER (PARTITION BY __sync_key ORDER BY __synced_at DESC) as rn
            ,*
        FROM amazon_ads.sponsored_brands_reports_test
        ORDER BY rn DESC
    )
    WHERE rn > 1
)
;
-- Clone the brands report table into a backup table
CREATE TABLE IF NOT EXISTS amazon_ads.sponsored_brands_reports_backup
CLONE amazon_ads.sponsored_brands_reports
;
-- Remove all records from production table
DELETE FROM amazon_ads.sponsored_brands_reports
WHERE 1=1
;
-- Insert the clean data from the test table into the production table
INSERT INTO amazon_ads.sponsored_brands_reports
SELECT *
FROM amazon_ads.sponsored_brands_reports_test
;

March 19, 2025

improved

Transformation

Added shipping_cost and fulfillment_cost to uos.sales_report table

We have added 2 new columns to the uos.sales_report table:

shipping_costs

and

fulfillment_costs

This is an update to the structure of the table, so any Enterprise merchants with custom scripts that push data into the uos.sales_report table will need to be updated to use the new table structure.

After the update, this will be the structure of uos.sales_report:

    transaction_id
  , store_transaction_id
  , transaction_date
  , transaction_type
  , transaction_detail_type
  , store_name
  , store_type
  , store_country
  , store_integration_name
  , business_unit
  , business_channel
  , customer_id
  , store_customer_id
  , email_address
  , order_id
  , store_order_id
  , order_date
  , refund_date
  , order_code
  , giftcard_only_order
  , order_line_id
  , store_order_line_id
  , store_product_id
  , store_variant_id
  , original_currency
  , currency_conversion_rate
  , converted_currency
  , product_name
  , listing_sku
  , sku
  , quantity
  , price
  , gross_sales
  , discount_amount
  , shipping_amount
  , fulfillment_amount
  , shipping_cost
  , fulfillment_cost
  , tax_amount
  , refund_amount
  , net_sales
  , sku_cost
  , duties
  , __shop_id
  , __uos_integration_id
  , __loaded_at
  , __synced_at

March 11, 2025

improved

Transformation

Visualization

Network Type added to Vendor-Reported Marketing explore

The explore that allows you to analyze all of your vendor-reported marketing KPIs has a new dimension — Network Type — which will help you understand performance metrics based on the targeting and network delivery settings for your ads.

For example, if you have some adsets on Meta that are set up to run only on Instagram vs other adsets that are set up to run only on Facebook, this new dimension will allow you to do so.

March 10, 2025

fixed

Visualization

Updated default filters on Customer Retention dashboard

Some of the tiles on the Customer Retention dashboard were filtering for outdated Customer Segment default values. This resulted in blank results being returned for the tile. This updates the filter on the tile so that they use the new defaults:

1. Active Multi-Buyer
2. Lapsed Multi-Buyer
3. Active Single Buyer
4. Lapsed Single Buyer
5. Non-Buyer

March 6, 2025

improved

Visualization

Stage-specific measures in Shopping Stage explore

Our Shopping Stage explore previously required you to pivot by the Shopping Stage dimension to get useful metrics. This worked for basic use cases, but made it difficult to create measures that show continuation rates from one step to another, and also made it difficult to plot these measures over time.

This update makes it easier to see how your ecommerce funnel is performing over time, like in the visualization below:

(Click here to enlarge)

The update adds the following measures to the explore:

Percent Visit -> Purchase
Percent Visit -> Product View
Percent Product View -> Add to Cart
Percent Add to Cart -> Begin Checkout
Percent Begin Checkout -> Purchase
Total Sessions w/ Visit
Total Sessions w/ Product View
Total Sessions w/ Add to Cart
Total Sessions w/ Begin Checkout
Total Sessions w/ Purchase

It also:

Hides the old "Shopping Stage" dimension, since combining it with the new measures would give confusing results, and
Hides the old "Total Sessions" measure, since using it without the Shopping Stage dimension would result in inflated and misleading metrics

March 5, 2025

improved

Transformation

TikTok Shops conversions

All places in our data model that contained vendor-reported conversions for TikTok were including only on-site purchases (i.e. purchases on your ecommerce site). They will now contain on-site purchases as well as purchases through TikTok Shops.

→