Custom Metrics

Introduction to Custom Metrics

Summary: In this article, we introduce the concept of custom metrics in Daasity – what they are, why you might need them, and how to create or manage them. Daasity provides a comprehensive set of standard metrics (like Gross Sales, AOV, CAC, LTV, etc.), but every business has unique KPIs or definitions that sometimes require customization. We’ll explain the difference between standard metrics and custom metrics, the options for defining custom metrics as a user, and how Daasity’s team can assist (especially for Managed or Enterprise customers) in implementing custom metrics in your data model. By tailoring metrics to your business, you ensure that the numbers in your dashboard align perfectly with your internal goals and definitions.

What are Custom Metrics?

A custom metric is any KPI or calculated measure that is not readily available in Daasity’s out-of-the-box data model, or one that you define differently from the default. Daasity’s standard model comes with dozens of metrics pre-defined (see the Metrics Glossary for the full list and definitions). These cover common e-commerce and retail needs – e.g., Gross Sales, Net Sales, Orders, Average Order Value, New Customer Count, Repeat Purchase Rate, ROAS, CPA, and so on. Custom metrics come into play when:

• You have a unique business definition of a metric. For example, “Active Customers” might be defined by your team as “customers who purchased at least twice in the last 12 months.” The standard model might not explicitly have “Active Customers” as a metric, or might define active differently (say, any purchase in last X days). You’d want a custom metric to reflect your definition.

• You want a new calculated metric that combines existing ones. For instance, maybe you want a “Gross Margin per New Customer” metric (combining margin and new customers) or a custom index or score that’s specific to your strategy.

• The default metric logic might not match your needs. Daasity might calculate “Customer Lifetime Value (LTV)” in a specific way (e.g., 12-month revenue per customer cohort). If you prefer a different method (like a predictive LTV model or a different timeframe), you’d consider customizing that metric.

In short, custom metrics let you extend or adjust the analytics to speak your language. They ensure that when you look at a dashboard, the figures align with how your team measures success internally.

Standard Metrics vs. Custom Metrics

Standard Metrics: These are provided by Daasity and are consistent across all clients unless changed. They are defined in the underlying LookML model and data transformations. They often have industry-standard formulas. For example, AOV = total revenue / total orders; CAC = marketing spend / new customers; Repeat Purchase Rate = percent of customers with more than one order. Using standard metrics has the benefit of comparability – your team is using definitions that are common and vetted. Also, all standard dashboards use these, so if you change a standard metric definition, it could impact many places.

Custom Metrics: Can be thought of in two ways:

• Ad-hoc custom metrics: These are ones you create on the fly in an Explore or dashboard via table calculations or custom fields. For instance, you can create a calculated field in an Explore that says Conversion Rate = Orders / Sessions. If the base model didn’t have “Conversion Rate” metric explicitly, this custom calculation would give it to you. Ad-hoc metrics are quick and easy, but they live only in that one dashboard or chart unless you recreate them elsewhere. They are not formally part of the data model and won’t automatically appear in other explores or dashboards.

• Modeled custom metrics: These are metrics that you (often with Daasity’s help) add to the data model so that they behave like any other standard metric. This could involve adding a new LookML measure or a new derived table in the ETL to calculate it. Once added to the model, the metric will appear in relevant Explores for anyone to use, and you can include it in dashboards consistently. Modeled custom metrics are more durable and shareable across the organization.

When to use which? If you just need a one-off calculation, doing it ad-hoc in a dashboard might suffice (e.g., a one-time analysis or a niche metric only one person cares about). But if you find yourself repeatedly needing that metric or it becomes important for company reporting, it’s worth formally adding it as a custom metric in the model.

Creating a Custom Metric (Standard User Approach)

As a standard Daasity user (without direct Looker development access), your tools for custom metrics are the Explore custom fields and table calculations:

• Custom Fields in Explore: Looker (and thus Daasity’s Explore) allows you to create a custom measure or dimension by writing a simple formula. For example, within an Explore, you might click “+ Add” and select “Custom Measure”. You could create something like Profit = Net Sales - COGS if Net Sales and Cost of Goods Sold are fields available. You give it a name and formula, and it will compute on the fly. This custom field can then be used like any other measure in that Explore. It’s great for quick calcs or ratios.

• Table Calculations: After you run an Explore query and have a result table, you can add a table calculation which performs math on the result set. For instance, after pulling monthly sales and orders, you might add a table calc: Average Order Size = ${Net Sales}/${Orders}. This is similar to a custom field but is computed after the data is aggregated, on the results. Table calcs are often used for percentages, ratios, or differences (like YoY growth percentage between two result columns).

Using these methods, you can achieve a lot of custom metrics without needing to touch the underlying data model. The downside is that these metrics don’t persist globally – if you go to a new Explore, you’d have to recreate them. Also, they can’t be easily filtered or referenced in other places unless you copy the formula. They also might not perform as well for very large data pulls (since they calculate client-side). Still, for many custom needs (like custom segment definitions or simple math), they do the job.

Example: Let’s say your marketing team defines Blended CAC differently – they want to include cost of goods in the acquisition cost. The standard CAC = Marketing Spend / New Customers. Your twist: (Marketing Spend + COGS for new customers) / New Customers. If the data is available (COGS by customer or on new customers), you could write a custom field for that. If not at hand, that might hint that a model change is needed to bring COGS and customer acquisition together.

Implementing Custom Metrics via Daasity (Managed/Enterprise)

If a custom metric is critical and complex, you’ll likely involve Daasity’s data team to implement it in the model. Enterprise customers or those on a Managed Data Service plan have the option to request these enhancements (often via your Customer Success Manager or support ticket). Here’s how that process might work:

1. Define the Metric Clearly: You provide the precise definition and calculation logic. For example, “We define an ‘Engaged Subscriber’ as a customer who has opened at least 3 emails in the last 30 days AND made a purchase in the last 90 days. We want a metric that counts Engaged Subscribers.” This clarity is necessary so it can be translated to code.

2. Assess Data Availability: Daasity will check if the data required is already in the warehouse. In our example, we’d need email open counts (likely from Klaviyo or ESP integration) and purchase data. If everything’s there, great. If not, the integration might need to be adjusted or an additional data source integrated.

3. Develop the Metric in the Model: This could involve adding a derived table or LookML measure. Perhaps a SQL transformation is written to flag those customers and count them. Or a LookML dimension is created with a yes/no for “Engaged Subscriber” and a measure to count them. The Daasity team would typically implement this in your custom code repository or deliver an update that includes the metric. (Enterprise customers might even do this themselves if they have a data analyst with LookML skills and a development branch – Daasity’s Looker model is extensible for those with access.)

4. Testing and Validation: Once added, the metric is tested to ensure it calculates correctly and matches any known values or sample cases you have. You might get a preview in a staging dashboard or an Explore to verify the numbers align with expectations.

5. Release to Production: The custom metric becomes part of your Daasity model. It will appear in relevant Explores (perhaps in a custom section or under a specific explore if it’s niche). From then on, you and your team can use it just like any built-in metric. It can be pulled into dashboards, used in filters (e.g., filter to only Engaged Subscribers’ revenue), and even scheduled in reports.

Examples of custom metrics we often implement:

• Custom definitions of Lifetime Value (LTV) (e.g., 60-day LTV as a specific metric).

• Custom cohort metrics – e.g., repurchase rate among customers acquired during a specific campaign (blending marketing source with customer behavior, possibly requiring custom ETL).

• Unique ratios or indices – e.g., an “Engagement Score” that combines email clicks, site visits, and purchase frequency into one score.

• Custom financial metrics – if a brand wants to include certain adjustments like VAT or refunds differently than standard Net Sales, a custom metric can be made to reflect “Adjusted Net Sales” etc.

Viewing and Managing Custom Metrics

After creating custom metrics (either ad-hoc or model-based), here’s how to manage them:

• Ad-hoc (Dashboard-specific) Metrics: If you created a table calculation on a dashboard, it will live on that dashboard. If you need to adjust it, go into edit mode and modify the formula. If you want to reuse it, you’ll have to recreate it on another dashboard. There isn’t a central place in the UI listing all your custom calcs; you manage them where you made them. Keep documentation of any complex ones in case you need to replicate.

• Model-defined Metrics: These will show up in Explores typically with a friendly name. Often, the Daasity team might put them under a section or with a label like “Custom Metrics – [Your Company]” in the field picker for clarity. If something looks off or needs tweaking, you’d go back to Daasity support to adjust the logic in the model. Enterprise users with LookML access can manage it through the code repository – e.g., updating the LookML in a custom views file. It’s advisable not to tinker without coordination, as these definitions can be complex and interconnected.

• Metrics Dictionary Updates: If you add an important custom metric, you should also update your internal documentation or data dictionary so others know what it is. For instance, if your team added “Active Customer Count (90-day)” as a custom measure, add the definition in your own wiki or even request Daasity to include a note in the help center if it’s generally useful. A clear definition helps prevent confusion down the line (i.e., what exactly does “Active Customer” mean?). Remember that down the road new team members won’t know it’s custom vs. standard – to them it’s just another metric, so treat its documentation with equal importance.

Standard vs. Managed Approach Summary

To summarize the avenues for custom metrics:

• You create it on the fly – quick, no code, but local to your analysis (good for experimentation and one-offs).

• Daasity adds it to the model – robust, reusable, but requires coordination and possibly available only to higher-tier plans or via services (good for critical business metrics).

Daasity’s goal is to have its standard model cover as many common needs as possible. So always check the existing Metrics Glossary and standard Explores – perhaps the metric you need is already there under a different name. If not, don’t hesitate to use the above methods to define what you need. Data-driven decisions depend on having the right metrics, and with Daasity you have the flexibility to get those metrics into your dashboards one way or another.

Related Articles:

• Metrics Glossary (for understanding standard metric definitions)

• Custom Reporting (tips on building reports, including using custom fields)

• Customizing Base Daasity Code (for technical users, how to extend Daasity’s data model in LookML)