MAQL Reference Guide

GoodData MAQL Reference Guide
Doc Date: May 10, 2013
Copyright 2013 GoodData Corporation All rights reserved.
Table of Contents
I. Introduction to MAQL ...............................................................................................5 Whats to Come .......................................................................................................... 6 II. Basic Elements of GoodData..................................................................................7 Project Hierarchy ......................................................................................................... 7 Logical Data Model .................................................................................................. 10 III. Creating Metrics in the Custom Metric Editor ....................................................12 Accessing the Custom Metric Editor ....................................................................... 12 Using the Custom Metric Editor................................................................................ 12
Custom Metric Editor Text Field ...........................................................................................13 Project Element Sidebar.......................................................................................................14 MAQL Directory Tabs ............................................................................................................15 Local and Global Settings For Metrics ...............................................................................16
IV. Basic MAQL Syntax ...............................................................................................17 MAQL Queries Begin With SELECT............................................................................ 17 Project Elements Must Be Inserted from the Sidebar............................................. 17 V. Using MAQL Aggregations to Form Metrics ........................................................18 Aggregation Functions ............................................................................................. 18
SUM ..........................................................................................................................................18 AVG .........................................................................................................................................19 MIN...........................................................................................................................................19 MAX .........................................................................................................................................19 COUNT.....................................................................................................................................20
Counting Attribute Values In Specific Data Sets.................................................... 20 VI. Arithmetic Operations in MAQL ...........................................................................23
Numerical Variables in MAQL .............................................................................................23
VII. Miscellaneous Functions ......................................................................................24 Absolute Value, Signum and Square Root ............................................................. 24
Abs( ) .......................................................................................................................................24 Sign( ).......................................................................................................................................24 SQRT( ) .....................................................................................................................................25
VIII. The WHERE Clause Filtering in MAQL ................................................................26
Operators for Defining Filters .................................................................................... 26

= (equals)................................................................................................................................26 <> (does not equal) ..............................................................................................................27 Other Relational Operators <, >, <=, >=..........................................................................27 IN ..............................................................................................................................................28 NOT IN .....................................................................................................................................28 BETWEEN..................................................................................................................................29 NOT BETWEEN .........................................................................................................................29
Time Macros for Filtering Floating Time Periods ...................................................... 29

THIS Macro ..............................................................................................................................30 PREVIOUS Macro ...................................................................................................................30 NEXT Macro ............................................................................................................................30
Logical Expressions for Combining Filters ................................................................ 30

NOT ..........................................................................................................................................31 OR ............................................................................................................................................31 AND .........................................................................................................................................31
Adding Filtered Variables to Metric Definitions ...................................................... 32 IX. Conditional Statements ........................................................................................33
IF THEN ELSE.............................................................................................................................33 CASE ........................................................................................................................................33 IFNULL ......................................................................................................................................34
X. Referring to Past or Future Time Periods in MAQL ...............................................35 Functions For Referring to Past Time Periods........................................................... 35
FOR Previous ( ) ......................................................................................................................35 FOR PreviousPeriod( )............................................................................................................36 FOR Previous( ) vs. FOR PreviousPeriod( ) ..........................................................................37
Functions For Referring to Future Time Periods ....................................................... 38

FOR Next( ) .............................................................................................................................38 FOR NextPeriod( ) ..................................................................................................................38
XI. Overriding Report Attributes and Filters in MAQL ...............................................40 Keywords for Overriding Report Attributes ............................................................. 40
BY .............................................................................................................................................40 BY ALL ......................................................................................................................................42 BY attribute ALL IN ALL OTHER DIMENSIONS ......................................................................44 BY ALL IN ALL OTHER DIMENSIONS.......................................................................................44
GoodData MAQL Reference Guide 4 BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR attribute ................................................45
Keywords for Overriding Report Filters..................................................................... 45

WITHOUT PARENT FILTER (WITHOUT PF)................................................................................45
XII. Appendix: MAQL Expression Reference .............................................................47
I. Introduction to MAQL
The following guide provides an overview of the Multi-Dimension Analytical Query Language (MAQL) that is used to define metrics in GoodData. MAQL has two extensions: Data Definition Language (DDL) and Data Query Language (DQL). MAQL DDL is briefly introduced below, but the primary focus of this guide will be on using MAQL DQL to define project metrics.
Figure 1: MAQL has two main extensions, but this guide will primarily focus on using MAQL DQL to define project metrics.
MAQL Data Definition Language (DDL) is used for building a projects data model in GoodDatadefining the relationship between the facts and attributes that provide the foundation for any project. MAQL DDL commands can be carried out using the CL tool or project gray pages, but these processes have now been abstracted and streamlined with the introduction of GoodData CloudConnect. CloudConnect is GoodDatas end-to-end ETL data-loading tool, platform, and data modeler. At its essence, CloudConnect allows you to extract, transform and load data from multiple sources and design your projects logical data models through a graphical user interface. For more information on CloudConnect or MAQL DDL, visit the GoodData developer portal at http://developer.gooddata.com. MAQL Data Query Language (DQL) will be the focus of the remainder of this guide. DQL is the MAQL extension that you can use within the GoodData application (and more specifically, within the Advanced Metric Editor dialog) to tap a number of the applications advanced metric-building features.
Whats to Come
GoodDatas primary mission is to help you gain business insights from your metrics those numerical values that populate your GoodData reports and widgets. This guide aims to introduce GoodData users to the MAQL syntax that can be used to define advanced metrics in GoodDatas Custom Metric Editor. In the coming sections well explore the following topics: Basic concepts in GoodData Accessing and using GoodDatas Custom Metric Editor Defining metrics with MAQL syntax in order to: o Aggregate facts to form the foundation of each metric o Perform arithmetic operations on predefined metrics o Use various mathematical functions within metric definitions o Filter subsets of data to be included or excluded in a metrics computations o Return different values or carry out different computations, conditional upon the values of other project metrics o Use keywords that can customize how a metric is affected by attributes and filters within any report to which it is added
As you can see, metrics are powerful tools for anyone seeking business insights from their data. But metrics are only useful when integrated into well-designed reports and dashboards. For more information on getting the most out of GoodData, see the GoodData Reference Guide.
II. Basic Elements of GoodData

MAQL DQL (from this point on, simply referred to as MAQL) is primarily used as a way to build advanced reporting metrics in GoodData. In order to understand the power of metrics defined directly through MAQL it will be important to have a grounding in common GoodData terminology.
Project Hierarchy
Projects > Dashboards > Dashboard Tabs > Reports > Metrics > Facts & Attributes > Data In GoodData, your projects are organized into dashboards, dashboard tabs, reports, and the metrics that are contained within those reports. At the lowest level, facts, attributes, and source data represent the foundational components that are aggregated to form the metrics displayed in GoodDatas dashboard reports. These terms will be explored in greater detail in the coming pages. Heres one way to conceptualize the hierarchy:
Key Terminology
Term Data
Definition
Raw records that GoodData users load into project data sets for use in the projects data model.
Examples
1, IBM, $50000, 10/10/2012
Facts
Individual numerical measurements attached to each data set in the source data. Facts are always numbers and are the smallest units of data.
Opportunity amount (i.e. $25,000) Campaign clicks (i.e. 212); Website views (i.e. 4,508)
Metrics
Aggregations of facts, or counts of unique attribute values, presented as numbers in GoodData reports. Metrics are defined by customizable aggregation formulas. Metrics represent what is being measured in a given report.
sum of sales average salary total costs count of Opportunity (attribute)
Attributes
Non-measurable descriptors, or categories, used to break apart metrics and provide context to reports data. Attributes dictate how metrics are calculated and represented.
(by) Month (by) Store (by) Employee (by) Region (by) Department
Attribute Values
Descriptive values that belong to some common category, or attribute.
An Employee attribute might include attribute values like Sally, Steve, and Hubert. A Department attribute might include attribute values like Sales, Marketing, Customer Support, Finance, and Documentation.
GoodData MAQL Reference Guide Dimensions

Broad categories for organizing attributes within a data setoften within a hierarchy. The Date dimension in a project could consist of a number of attributes ordered by granularity: Year > Quarter >
Month > Week > Date
One project may even have multiple date dimensions, such as Date (Lead Created), Date (MQL Qualified), or Date (Snapshot) each with its own attribute hierarchy.
Filters
Specifications that serve to limit the set of metric values that are returned by a given metric. Filters are defined by selecting attribute values of interest. Any metric values associated with these attribute values can then be filtered in (included in) or filtered out of (excluded from) a report. Filters can be applied to a report definition (relating to multiple metrics) or to an individual metric definition.
Sales from 2008 and 2009 Sales from the stores with the top 10 sales figures Sales from those stores where sales were less than $10,000 in 2009
Reports
Visualizations of data that fall into one of three categories: tables, charts, and headline reports. All reports contain at least one metric (what is being measured), and often contain one or more attributes (dictating how that metric is broken down).
A table that shows employee salaries (metric) broken down by quarter (attribute) A line graph that shows revenue (metric) generated across each month in the past year (attribute) A bar graph that shows sales figures (metric) broken down by region (attribute)
Dashboard Tabs
The pages upon which reports (either tables or charts) and other dashboard elements (lines, embedded content from the web, widgets, and filters) are displayed.
ROI

Dashboard tabs are typically used to organize reports within a given dashboard. Funnel/Goals
10
Dashboards
Groups of one or more dashboard tabs that contain reports belonging to a common category of interest.
From Leads to Won Deals (marketing dashboard)
Projects
Groups of one or more dashboards containing tabs, reports, metrics, data models, data sets, and users. Projects are often provisioned for use by an entire team or department. In these cases, a change made by one editor would be visible to all.
GoodSales GoodMarketing GoodSubscriptions
Data Set
A collection of related facts and attributes, presented as a table.
An opportunity data set, containing facts related to attributes like name, opportunity amount, and stage.
Logical Data A model of the relationship between all of the LDM Diagram in the form of an oriented graph: Model (LDM) facts and attributes within a project.
Logical Data Model

A Logical Data Model (LDM) is a model of the relationships between all of the facts and attributes within a project. As such, it defines which of a projects attributes can be used to break each metric (an aggregation of facts). LDMs are typically visualized as oriented graphs like the simplified one below. The LDM shows five attributes (in rectangles), including two date attributes (Date Created, and Date Closed), all of which relate to some sales opportunity. From the oriented graph, we can tell that each opportunity in the data set has several facts attached to it, including numerical values that represent the amount of money that the opportunity is worth and the probability the opportunity will be won.
11
Figure 2 An oriented graph of an LDM with five attributes (in rectangles) and two facts (ovals).
12
III. Creating Metrics in the Custom Metric Editor

The remainder of this guide will explore how you can create custom metrics from GoodDatas Metric Editor Dialog. This section will explain how to access the Metric Editor and how to use the Editors core features. In GoodData, project users with the editor or administrator role can create new metrics from the Metric Editor Dialog within the Manage Page. You can also create new metrics from the Report Page, while defining what a report will be measuring.
Accessing the Custom Metric Editor

To access the Metric Editor from the Manage Page: 1. Select Manage from the Navigation Bar. 2. Select the Data tab and then select Metrics from the sidebar. 3. Click the + Create Metric button. To access the Metric Editor from the Report Page: 1. Click on a reports name from the Report Directory or click the Create Report button. 2. Select What and then click (Advanced) next to + Add New Metric.
Using the Custom Metric Editor

When the Metric Editor is first opened, you are presented with four options. The first three, Share (in %), Difference, and Ratio are Metric Wizards that provide a structure for creating specific types of advanced metrics with MAQL. You can learn more about the Metric Wizards in the Metric Editor Dialog chapter of the GoodData Reference Guide. This guide will focus on the fourth option for creating metrics: Custom metric. The Custom Metric Editor provides an interface that serves as a guide for creating your own metrics in GoodDatas powerful data query language: MAQL.
13
Figure 3 This guide focuses on using MAQL to define metrics from scratch in the Custom Metric Editor.
Custom Metric Editor Text Field

From the Custom Metric Editor you can define a metric by entering GoodDatas MAQL data query language directly into a text field.
Figure 4 From the Custom Metric Editor you can define a metric by entering GoodDatas MAQL data query language.
Project elements in your MAQL definitions are automatically color-coded so you can keep track of which elements youve included in your metric and ensure your MAQL syntax is valid.
Figure 5 Formatting styles highlight the project elements that appear in MAQL metric syntax.
Project elements are distinguished by the following colors: Facts, Metrics, Attributes, Attribute Values, Variables.
GoodData MAQL Reference Guide 14 MAQL syntax must be valid in order for a custom metric to be saved. In the event that you try to save a metric with invalid MAQL syntax, you will be prompted with an alert that will help you pinpoint the issue. In the following example, the SELECT keyword is missing from the start of the metrics definition. All MAQL definitions begin with SELECT.
Figure 6 Improper MAQL syntax results in a warning message when a metric is saved.
Project Element Sidebar

The sidebar to the right provides an organized directory of all the projects elements (facts, metrics, attributes, attribute values, and variables)all in the form of snippets that can be inserted directly into your metrics definition. NOTE: While MAQL syntax can typically be typed directly into the Metric Editor text field, project elements like facts, metrics, attributes, attribute values, and variables must be added to metric definitions using the Project Element Sidebar. Click an elements heading to view its contents.
Figure 7 The Project Element Sidebar is used to select and insert project elementslike facts, metrics, attributes, attribute values, and variablesto metric definitions written in MAQL.
When you find an element of interest, double click it, or select it and click Add Selected, to insert it into your metrics MAQL definition in the text field.
15
Figure 8 Double click Project Elements in the sidebar to insert them into metric definitions.
MAQL Directory Tabs

Tabs beneath the Metric Editor contain additional MAQL expressions that can be added to your metric definitions. Unlike the project elements, which must be added to your syntax from the sidebar, the MAQL syntax snippets within the tab directories are for reference and convenience.
Figure 9 Tabs beneath the Metric Editor contain additional MAQL operators, functions, macros, and keyword snippets for reference and convenience.
In the tab directories, click the linked name of a MAQL operator, function, or keyword to insert the correctly structured MAQL syntax into the Metric Editor. Clicking the colored ellipses opens the project element sidebar to the appropriate directory. From there, you can select which project element should be inserted into the syntax.
16
Figure 10 Click an ellipsis within a pre-structured MAQL snippet to open the Project Element Sidebar where you can select which element should be inserted into the MAQL syntax.
Local and Global Settings For Metrics

New metrics created from the Report Editor of the Reports Page can either be left local (report-specific) or made global (available to all project users for use in other project reports). New metrics that are created from the Report Editor are local by default, but can be made global by selecting the Add to Global Metrics checkbox in the Metric Editor.
Figure 11 The Add to Global Metrics checkbox makes the new metric available for use in other reports within a given project.
In the case where a user deletes a global metric that is being used in one or more report, the metric is removed from the list of global metrics but remains as a local metric within the reports in which it already appears. New metrics that are created from the Manage Page are global by default.
17
IV. Basic MAQL Syntax

MAQL Queries Begin With SELECT
MAQL syntax is used to define metrics in GoodDatas Custom Metric Editor. The first thing youll need to know when writing custom metric definitions is that every metric definition is preceded with the SELECT command. Think of this command in terms of making a request to the data warehouse, and selecting which information youd like to be returned. This is the case when you are using MAQL syntax to aggregate a fact into a metric: SELECT SUM(Payments) You will also use SELECT to introduce one or more predefined metrics within a metric definition: SELECT Payment_metric / (SELECT Payment_metric BY Year) In the first example above, the MAQL statement defines a metric that computes the sum total of all payment fact values across all available records in the current project.
Project Elements Must Be Inserted from the Sidebar

As mentioned in the previous section, while the MAQL expression directory beneath the Custom Metric Editors text field can come in handy for formulating correctly structured expressions, MAQL expressions can also be typed directly into the Custom Metric Editors text field. An important exception is with project elements, such as facts, metrics, attributes, attribute values, and variables. These must be added to metric definitions using the Project Element Sidebar.
18
V. Using MAQL Aggregations to Form Metrics

As individual numerical measurements, facts arent very interesting on their own. In order to pull interesting insights from your data, youll want to aggregate facts into metrics. These metrics will be what your reports measure. While all metrics are fundamentally aggregations of facts, thats not to say they dont contain other interesting features as well. Later on in this guide well discuss optional metric customizations. These include using arithmetic to operate on metrics, filtering out certain subsets of data in metric computations, adding mathematical functions and conditionals to metric definitions, and using MAQL keywords to specify how metrics are affected by the reports within which they reside. But first well revisit the idea that the one thing common to all metrics is a foundation composed of an aggregation of some fact (or set of attribute values).
Aggregation Functions
Above all, GoodDatas dashboards and reports allow you to gain insights from your business metrics which determine what will be computed in any given report. Metrics are really just aggregations of facts. Here, when say fact we mean a numerical record that represents an individual business transaction. In other words, facts are the numbers youd find in each cell of a spreadsheet: Revenue earned from a sale Cost of some item purchased The hours worked by one employee The number of items shipped in one delivery
Facts can be aggregated by any of four operations, explained in further detail below:
SUM
Description Adds facts together to form a metric. Syntax Examples SELECT SUM(fact) The metric defined by the SUM of the Sales fact would be computed by adding revenue earned from all individual sales transactions: SELECT SUM(Sales)
19
AVG
Description Calculates the mean of a set of facts to form a metric. Syntax Examples SELECT AVG(fact) The metric AVG of Payment would be computed by adding all payment transactions together and dividing by the number of payment transactions: SELECT AVG(Payment)
MIN
Description Identifies the lowest value from a set of facts. Syntax Examples SELECT MIN(fact) The MIN of the Opportunity Amount fact is the lowest opportunity amount value on record: SELECT MIN(Opportunity_Amount)
MAX
Description Identifies the largest value from a set of facts. Syntax Examples SELECT MAX(fact) The MAX of the Store Sales fact is the highest sales transaction value on record: SELECT MAX(Sales) A fifth aggregation operation for forming metrics is COUNT. COUNT is distinct from the other operations because it aggregates attributes rather than facts.
20
COUNT
Description Counts the number of unique values belonging to an attribute. COUNT of Store will return the number of different stores based on the number of distinct values of the Store attribute.
Syntax
SELECT COUNT(attribute) SELECT COUNT(attribute1, connection_point*) * Where connection_point is the foreign key, connecting to the data set in which the COUNT is to take place. NOTE: For more information on the second parameter of a COUNT operation, see the following section.
Examples
SELECT COUNT(Store) SELECT COUNT(Employee, Facts_of_Call)
Counting Attribute Values In Specific Data Sets

COUNT is different from the other aggregation operations in that it aggregates attribute values rather than facts. It does so by counting the number of unique values belonging to an attribute. In the example below, the total number of employees could be computed with the COUNT operation: SELECT COUNT(Employee)
Figure 12 The Facts of Call, and Facts of Opportunity data sets are both related to the Employee data set, but this doesnt mean the values of Employee are the same in each of the three data sets.
GoodData MAQL Reference Guide 21 But there are some limitations to this approach. Here, weve specified what wed like to count, but not where it should be counted. This is important because the number of unique employee values may be different in each of the three data sets insofar as some employees may not be associated with any opportunities and other employees may never have made a call. The end result is that the SELECT COUNT(Employee) metric can only be broken down by the Name and Department attributes. Now consider the case where youd like to measure the number of employees who have made a phone call. Because Facts of Call is connected to Employee in the logical data model above, we know that for every call that is made, the employee who made it is also stored in the Facts of Call data set. To count the number of unique Employee values within the Facts of Call data set, well incorporate a second parameter in our COUNT function that establishes the data set in which the count will take place. To count the number of unique employee values in the Facts of Call data set we would formulate our COUNT metric in the following way: SELECT COUNT (Employee, Facts_of_Call). The first parameter in the COUNT syntax represents the attribute whose values you wish to count. The second parameter specifies in which data set those attribute values should be counted.
Figure 13 In the Metric Editor, the COUNT function includes two parameters.
As a second example, consider the (Customer Support) Tickets, Employees, and Payroll data sets below. Ticket_ID and Salary each represent connection points from their respective data sets to the Employees data set. So while counting the total number of employees could be carried out with a COUNT(Employee)metric, this renders the Tickets and Payroll datasets unusable. Using this method, it would not be possible to count the number of employees who have resolved a customer support ticket, nor would it be possible to count the number of employees who are on payroll.
22
Figure 14 The Tickets and Payroll data sets share a common data setthat of Employees. The Employee, Ticket_ID, and Salary attributes are the primary key attributes in their respective data setseach representing a unique value.
Once again, a second parameter must be added to the COUNT operation in order to designate the data set within which the COUNT will take place. To count the number of employees who have responded to at least one customer support ticket the following syntax should be used: SELECT COUNT(Employee, Ticket_ID) To count the number of employees who are on payroll the following syntax should be used: SELECT COUNT(Employee, Salary) (Where the values of the attribute Salary are unique ID numbers that identify each employee who is on payroll.)
23
VI. Arithmetic Operations in MAQL

After a fact has been aggregated and saved as a metric, it can be used as a component of another metric. Predefined metrics can be manipulated with any basic arithmetic operation: addition (+), subtraction (-), multiplication (*), and division (/). Description You can add, subtract, multiply, or divide predefined metrics. Syntax SELECT metric1 + metric2 SELECT metric1 - metric2 SELECT metric1 * metric2 SELECT metric1 / metric2 Examples SELECT Expenses + Salary SELECT Revenues - Costs SELECT Profit * 0.03 SELECT New_Revenue / Revenue_Last_Year NOTE: Where Expenses, Salary, Revenues, Costs, Profit, New_Revenue, and Revenue_Last_Year are predefined metrics.
Numerical Variables in MAQL

You can also introduce dynamic values into arithmetic operations within MAQL. These values, known as numerical variables, can be assigned to specific project members by a project administrator in GoodDatas Manage section. In the example below, a variable is used to calculate the users sales commissions. Description You can use numerical variableswith user-specific dynamic valuesin arithmetic expressions. Syntax Examples SELECT metric1 * variable SELECT Amount_Won * commission_rate_variable
24
VII. Miscellaneous Functions

Absolute Value, Signum and Square Root
Abs( )
Description The absolute value function returns a number or metric input as a positive number. Positive inputs will remain unchanged. Negative inputs will be rendered positive. Syntax SELECT ABS(number) SELECT ABS(metric) Examples SELECT ABS(-5) returns the value 5 SELECT ABS(10) returns the value 10 SELECT ABS((Total_Amount)-(SELECT Total_Amount WITHOUT PF))
Sign( )
Description The signum function returns a number or metric input as one of three values, conditional upon the value of the input. For inputs greater than zero, signum returns the value 1. For inputs equal to zero, signum returns the value 0. For inputs less than zero, signum returns the value -1. In effect, signum follows the rule: SIGN(number_input) = number_input/abs(number_input) Syntax SELECT SIGN(number) SELECT SIGN(metric) Examples SELECT SIGN(-3) returns the value -1 SELECT SIGN(3) returns the value 1 SELECT SIGN(0) returns the value 0
25
SQRT( )
Description The square root function returns the square root of a number or metric input. Negative or complex inputs result in a NULL output. Syntax SELECT SQRT(number) SELECT SQRT(metric) Examples SELECT SQRT(25) returns the value 5 SELECT SQRT(33.6) returns the value 5.796550698 SELECT SQRT(SELECT SUM(Sales)) returns the sqrt of the Total Sales metric
26
VIII. The WHERE Clause Filtering in MAQL

Once you have aggregated a fact to form the foundations of a metric, you can use MAQL syntax to add filters to your metric definition. Filters are optional features that can be used to narrow the set of data from which a metric is computed. With logical expressions, its also possible to combine two or more filters within a single metric definition. The basic syntax for filters uses the word WHERE to introduce the filter expression: SELECT metric WHERE filter_conditions This section will explore several types of syntax for customizing metric filters: Special operators for defining filters (e.g. SELECT Revenues WHERE Year = 2006) Time macros for filtering for floating time periods (e.g. SELECT Payment WHERE Date = {This} 1) Logical expressions for combining filters (e.g. SELECT Revenues WHERE Year=2006 AND Month=5)
Operators for Defining Filters

Special operators are used in metric definitions to determine which data to include or exclude from metric computations. Operators help establish filters by specifying the conditions that determine whether any given fact value will be included or excluded from computing the metric at hand. Because facts are categorized by attributes, filter conditions are defined by referring to particular attribute values of interest (e.g. WHERE Year = 2007) or by referring to scenarios where two attributes have the same value (e.g. WHERE Date_Ordered = Date_Shipped). By specifying these conditions, you are able to delineate a wide range of fact values and specify whether they should be included or excluded from metric computations.
= (equals)
Description A filtering operator that includes only a single attribute value of interest. It can also be used to define the filter condition where two attributes have the same value.
GoodData MAQL Reference Guide Syntax SELECT WHERE = SELECT metric WHERE attribute = attribute_value Examples
27
SELECT SELECT SELECT SELECT SELECT SELECT
Salary WHERE Year = 2007 Revenues WHERE Month = {This} Expenses WHERE Quarter = {Previous} Expenses WHERE Quarter = {This} - 2 Employee WHERE Payment = 10000 Amount WHERE Date_Ordered = Date_Shipped
<> (does not equal)

Description A filtering operator that excludes a single attribute value. This operator can also be used to define the filter condition where two attributes have different values. Syntax SELECT WHERE <> SELECT metric WHERE attribute <> attribute_value SELECT metric WHERE attribute1 <> attribute2 Examples
SELECT Revenues WHERE Year <> 2006 SELECT Amount WHERE Date_Ordered <> Date_Shipped
Other Relational Operators <, >, <=, >=

Description Relational operators can be used with facts, metrics, or attributes to define filter conditions within a metric definition. When defining filters with attributes, the unique numerical IDs of ordinal attribute values can be extremely useful. Attribute value IDs are invisible to end users but knowledge of how they are applied can allow relational operator filters to be applied to certain attributes. For example, in the case of date values, attribute IDs are ordinal and chronological so within the Month/Year attribute, the ID value for May 2007 is higher than the ID value for April 2007. This allows you to refer to all months after May 2007 in the following way: Month/Year < May 2007. (More examples provided below)
GoodData MAQL Reference Guide Syntax SELECT WHERE < SELECT metric WHERE fact1 < fact2 SELECT metric WHERE fact1 < number SELECT metric1 WHERE metric2 < number SELECT metric WHERE attribute < attribute_value Examples SELECT SELECT <=20 SELECT SELECT SELECT SELECT Number of Transactions WHERE Total_Amount > 10,000 Number_of_Transactions WHERE AMOUNT > 6 AND AMOUNT Profit Profit Profit Profit WHERE WHERE WHERE WHERE Month/Year < May 2007 Year > 2007 Date <= 12/22/2010 Month of Quarter >= 2
28
IN
Description A filtering operator that includes two or more attribute values of interest, separated by commas. Syntax SELECT WHERE IN (,)
SELECT metric WHERE attribute IN (attribute_value1, attribute_value2) Examples SELECT Profit WHERE Year IN (2006, 2007)
NOT IN
Description A filtering operator that excludes two or more attribute values of interest, separated by commas. Syntax SELECT WHERE NOT IN (,) SELECT metric WHERE attribute NOT IN (attribute_value1, attribute_value2) Examples SELECT Profit WHERE Year NOT IN (2006, 2007) SELECT Sales WHERE Quarter NOT IN ({This}, {Previous})
29
BETWEEN
Description A filtering operator that includes only those attribute values that fall within some specified range. The range is specified by two inclusive attribute value endpoints. Syntax SELECT WHERE BETWEEN AND SELECT metric WHERE attribute BETWEEN attribute_value1 AND attribute_value2 Examples
SELECT Profit WHERE Year BETWEEN 2005 AND 2008 SELECT Sales WHERE Quarter BETWEEN {This} - 5 AND {This})
NOT BETWEEN
Description A filtering operator that excludes attribute values that fall within some specified range. The range is specified by two inclusive attribute value endpoints. Syntax SELECT WHERE NOT BETWEEN AND SELECT metric WHERE attribute NOT BETWEEN attribute_value1 AND attribute_value2 Examples
SELECT Profit WHERE Year NOT BETWEEN 2005 AND 2008 SELECT Sales WHERE Quarter NOT BETWEEN {This} - 5 AND {This})
Time Macros for Filtering Floating Time Periods

Time macros are floating date attribute values that are defined relative to the present. GoodData supports the following three time macros: {This} {Previous} {Next}
Because time macros are values that belong to some date attribute, they inherit the granularity of the attribute with which they are associated. Macros are useful for creating reports that relate to data from today or yesterday, or data from quarterto-date or year-to-date floating periods.
30
THIS Macro
In the following example, the time macro {This} inherits the day granularity from the Date attribute. As a result, in this context, {This} means this date, or today: SELECT Payment WHERE Date = {This} You could also modify this syntax to refer to yesterday: SELECT Payment WHERE Date = {This} 1 If the attributes granularity changes, so does the granularity of the macro. In the following example {This} means this month. SELECT Payment WHERE Month={This} Below, {This} means this year in the first instance and this day of year in the second (e.g. March 2nd would be day 61 of the year). SELECT Payment WHERE Year={This} AND Day of Year={This}
PREVIOUS Macro
In the following example, {Previous} means previous quarter. SELECT Payment WHERE Quarter={Previous} You can also use two time macros within the same metric definition. In the next example, {Previous} would mean last quarter and {This} would refer to this day, last quarter (e.g. February 2nd and May 3rd are both day 33 of their respective quarters, so they have the same Day of Quarter value). SELECT # of Employees WHERE Quarter={Previous} AND Day of Quarter={This}
NEXT Macro
In the following example, {Next} refers to the opportunity probability in the coming month. SELECT Opp_Probability WHERE Month={Next}
Logical Expressions for Combining Filters

Logical expressions allow you to combine multiple filters within a single metric definition.
31
NOT
Preceding a filter with NOT excludes the specified attribute values when the metric is computed. SELECT Revenues WHERE NOT(Year=2006 AND Month=5)
OR
Combining filters using OR indicates that all metric values associated with the specified attribute values should be combined. In the following example, all metric values associated with the attribute values 2006 and 2005 will be returned. SELECT Revenues WHERE Year=2006 OR Year=2005 OR can also be used to combine two different types of filters. Consider the case where you wish to return the total of all payments from the year 2006 and the first four months of 2007: SELECT SUM(Payment) WHERE Year=2006 OR Month IN (January 2007, February 2007, March 2007, April 2007)
AND
Combining filters with AND applies all filters simultaneously when the metric is computed. SELECT Revenues WHERE Year=2006 AND Month=5 While OR combines filters in a way that allows more data to pass through report computations, AND restricts, or limits, the amount of data that is used in computations. Consider the case where our metric has a filter that serves to include all data from 2006 as well as data from the first four months of 2007. Adding an additional AND clause onto the metric definition limits the data that is used in the metrics computations because now there are more conditions than before that data must meet in order to be included in computations. In the following example, payments must come from 2006 or the first four months of 2007 to be included in metric computations. They must also be greater than $10,000. SELECT SUM(Payment) WHERE Year=2006 OR Month IN (January 2007, February 2007, March 2007, April 2007) AND (Payment > 10000) Payment values that come from 2006 or the first four months of 2007 but are less than 10,000 will be excluded.
32
Adding Filtered Variables to Metric Definitions

Filtered variables rely on attribute values to filter out data that only pertains to certain users. This is useful for restricting users access to data for security reasons, but may also be helpful for streamlining large and complex projects so that users are not bogged down by data that does not relate to them. Filtered variables are set up in the Manage section and allow project administrators to determine which values within a given attribute should be available to particular users. Once a filtered variable has been established, you can apply it to a metrics definition using the WHERE filtering keyword. The variable will allow for dynamic (user-specific) metric computations in whatever report the metric is used. In the following example, the variable Var_Industry has been defined such that the number of leads calculated will relate only to those industries that are relevant to each user. SELECT #Leads WHERE Var_Industry
Figure 15 Use the WHERE MAQL keyword to introduce filtered variables in MAQL syntax. As with numerical variables, filtered variables are added by double clicking a variables name in the Custom Metric Editors sidebar.
33
IX. Conditional Statements

IF THEN ELSE
Description IF THEN ELSE statements return one of two possible values, or perform one of two possible computations, depending on whether some condition is met. The condition that needs to be met follows the keyword IF and can be constructed using any of the filtering keywords or relational operators (IN, NOT IN, BETWEEN, NOT BETWEEN, =, < , <=, >, >=, <>). The first possible outcome follows the keyword THEN, and the second possible outcome follows the keyword ELSE. The outcomes that are returned can be numerical values or arithmetic operations. All IF THEN ELSE statements conclude with the END keyword. Syntax SELECT IF THEN ELSE END SELECT IF condition THEN number ELSE number END SELECT IF condition THEN arithmetic_operation ELSE arithmetic_operation END Examples SELECT IF SUM(Amount) >= AVG(Amount) THEN 10 ELSE 0 END SELECT IF SUM(Duration) - AVG(Duration) > 2000 1 END THEN 0 ELSE
SELECT IF AVG(Probability) > 0.5 THEN SUM(Amount) * 10 ELSE SUM(Amount) / 10 END
CASE
Description CASE is used for complex conditional statements that contain two or more conditionswhere conditions and outcomes follow the WHEN and THEN keywords respectively. If none of the WHEN conditions are met, the outcome following ELSE is returned. The outcomes that are returned can be numerical values or arithmetic operations. All CASE statements conclude with the END keyword. Syntax SELECT CASE WHEN THEN , WHEN THEN ELSE END SELECT CASE WHEN condition1 THEN outcome1, WHEN condition2
GoodData MAQL Reference Guide THEN outcome2 ELSE outcome3 END Examples
34
SELECT CASE WHEN ACTIVITY_TYPE IN(Email,Web_Meeting) THEN 1, WHEN ACTIVITY_TYPE IN(Phone_Call,In_Person_Meeting) THEN 2 ELSE 0 END SELECT CASE WHEN SUM(Amount) > SUM(Lost) AND SUM(Amount) SUM(Lost) > 100,000 THEN 2, WHEN SUM(Amount) > SUM(Lost) AND SUM(Amount) SUM(Lost) < 100,000 THEN 1 ELSE 0 END
IFNULL
Description IFNULL allows you to predefine the way GoodData deals with any missing values that are returned by a metric expression (metric, fact aggregation, arithmetic operation). If a metric expression that is wrapped within an IFNULL statement ever returns a null value, the value will be replaced by the replacement value specified in the second parameter of the IFNULL function. Syntax SELECT IFNULL(,) SELECT IFNULL(metric/operation,replacement_value) Examples SELECT IFNULL(SUM(Amount), 0) SELECT IFNULL(SUM(FB_Cost + TW_Cost), 0) SELECT IFNULL(SUM(Amount) + 100, 1)
35
X. Referring to Past or Future Time Periods in MAQL

Functions For Referring to Past Time Periods
Two functions in MAQL allow you to create metrics showing a time over time comparison (e.g., month over month, or quarter over quarter) of past time periods: FOR Previous( ) FOR PreviousPeriod( )
FOR Previous ( )
Description A function that allows you to compute a metric for a previous, fixed time period. Syntax SELECT FOR Previous(,); SELECT metric FOR Previous(time_attribute) SELECT metric FOR Previous(time_attribute,#periods_ago) Examples SELECT Revenues FOR Previous(Quarter) NOTE: By default, FOR Previous()refers to values from one time period ago. This can be customized by adding a second parameter to the function. For example, you might want to return a revenue value from three quarters ago (see below). SELECT Revenues FOR Previous(Quarter , 3); Note how the Previous Qtr column in the table below displays a metric that is linked to the metric values in the Amount column with the FOR Previous( ) function.
Figure 16 Column 3 and column 2 metric values are linked with the For Previous(quarter) function.
36
Figure 17: Payment FOR Previous(Quarter,2) refers to the payment from two quarters ago.
Even in cases where metric values are broken across a date attribute of smaller time granularity, GoodData intelligently calculates FOR Previous(quarter) metric values. In the case illustrated below, each month in a quarter is linked to the corresponding month in the previous quarter.
Figure 18 Metric values in column 4 are related to column 3 values using the For Previous(quarter) function. Note how GoodData intelligently interprets FOR Previous(quarter) by associating each month within a quarter to the corresponding month in the previous quarter.
FOR PreviousPeriod( )
Description A function that allows you to compute a metric for a previous time period the granularity of which is determined contextually by the most granular date attribute that is defined in the report at hand. Syntax SELECT FOR PreviousPeriod(,) SELECT metric FOR PreviousPeriod(time_attribute)
GoodData MAQL Reference Guide Examples SELECT Payment FOR PreviousPeriod(Quarter) SELECT Payment FOR PreviousPeriod(Quarter,2)
37
FOR Previous( ) vs. FOR PreviousPeriod( )

The difference between the Previous( ) and PreviousPeriod( ) functions becomes clear when the date attribute in a report is smaller that the time period specified within the functions parentheses. FOR Previous( ) strictly follows the date attribute specified by the metric author within the parentheses of the function. On the other hand, FOR PreviousPeriod( ) adapts to the context of the report at hand. Regardless of the date attribute specified by the metric author, the PreviousPeriod( ) function takes on the date attribute of the smallest granularity from the report. In the example below, even though the metric in the final column has been defined as FOR PreviousPeriod(quarter), the function returns values from the previous month, as month is the most granular date attribute in this report.
Figure 19 The Previous( ) function strictly follows the date attribute specified within the functions parentheses. PreviousPeriod ( ) takes on the most granular date attribute that is contained within the report.
NOTE: Even if PreviousPeriod( ) automatically takes on the granularity of the smallest date attribute in a report, it is still important to specify a date attribute within the PreviousPeriod( ) function as a way of specifying the date dimension of interest. This is because projects often have multiple date dimensions, such as Date (Lead Created), Date (MQL Qualified), or Date (Snapshot).
38
Functions For Referring to Future Time Periods

You can also create a metric that incorporates metric values from a future time period. Doing so requires one of two functions that are analogous to Previous( ) and PreviousPeriod( ) but relate to the future: FOR Next( ) FOR NextPeriod( )
FOR Next( )
Description A function that allows you to compute a metric for a future, fixed time period. Syntax SELECT FOR Next(,) SELECT metric FOR Next(time_attribute) Examples SELECT Revenue FOR Next(Quarter) NOTE: By default, FOR Next()refers to values from one time period in the future. This can be customized by adding a second parameter to the function. For example, you might want to return a payment value from three quarters in the future with respect to a certain time period (see below.) SELECT Payment FOR Next(Quarter,3)
FOR NextPeriod( )
Description A function that allows you to compute a metric for a future time period the granularity of which is determined contextually by the most granular date attribute that is defined in the report at hand. Syntax SELECT FOR NextPeriod(,) SELECT metric FOR NextPeriod(time_attribute) Examples SELECT Revenue FOR NextPeriod(Quarter) SELECT Payment FOR NextPeriod(Quarter,3) As was the case for the functions Previous( ) and PreviousPeriod( ), the differences between Next( ) and NextPeriod( ) become most relevant when a report contains a
GoodData MAQL Reference Guide more granular date attribute than is specified within the functions themselves. The chart below demonstrates the differences between Leads FOR Next(Quarter) and Leads FOR NextPeriod(Quarter) in a report broken across a more granular date attribute.
39
Figure 20 The Next( ) function strictly follows the date attribute specified within the functions parentheses. NextPeriod ( ) takes on the most granular date attribute that is contained within the report.
40
XI. Overriding Report Attributes and Filters in MAQL

Once defined, metrics are added to reports, where they determine what data the report computes and displays. But because reports may have any number of filters and attributes that further determine how report data is computed, metrics are contextually impacted by the characteristics of the reports in which they reside. At times it may be useful to define a metric in a way that determines how the metric will be affected by these contextual report characteristics. This is where MAQL keywords come into play. For example, you could use MAQL to keep a metric from being affected by report filters, or to override report attributes. This section will explore how you can use MAQL keywords to further customize how your metrics compute data once added to GoodData reports. NOTE: MAQL keywords are added to metric syntax in the following order: BY clauses, WHERE clauses, WITHOUT clauses. Note that the order of MAQL keywords is alphabetical.
Keywords for Overriding Report Attributes

BY
Description The BY keyword is used to set a minimum level of granularity by which a metric can be broken down. The BY keyword effectively sets an aggregation floor, overriding report attributes that would serve to break the metric down into smaller units of granularity than is specified in the BY clause. Syntax SELECT BY SELECT metric BY attribute SELECT metric BY attribute1, attribute2 Examples SELECT Payment BY Year SELECT Payment / (SELECT Payment BY Year) SELECT Payment BY Quarter, Department
41
By Clauses With One Attribute

The example below shows customer support ticket resolution time by month and quarter. Note how the BY clause is used in the third column to establish that the metric values should not be broken down by any date attribute smaller than Quarter. The effect of the BY keyword can be seen by comparing column 3 and column 2 cell values. Even though the reports Month/Year attribute breaks report data in column 2 down by month, column 3 data remains at the Quarter level.
Figure 21 Customer support ticket resolution time for each month, each quarter, and the share of a quarters resolution time that can be attributed to each month.
Column 4 provides an interesting use case for the BY keyword: it displays the percent share of the total resolution time in a quarter that can be attributed to each month. This is found by dividing the metric from column 2 by the metric from column 3 using the following syntax: SELECT(SELECT SUM(Resolution_time)) / (SELECT SUM(Resolution_time) BY Quarter) Continuing on with this example, note what happens when we replace the reports Month attribute with a Year attribute (with larger granularity than the metrics Quarter BY attribute). The chart below shows that the BY keyword no longer affects the data returned by the metric in column 2. The BY keyword provides a flooror minimum aggregation levelat the Quarter level, but does not affect metric data that is aggregated at the larger Year level of granularity.
42
Figure 22 The BY Quarter clause does not override report attributes of larger granularity. Rather, it only serves to set a minimum aggregation level.
By Clauses With Multiple Attributes

The BY clause also supports multiple attributes, including non-date attributes. For example, the syntax below sets an aggregation floor at the Quarter and Department levels. SELECT SUM(Payment) BY Quarter, Department Due to the second attribute in the BY clause above, sub-attributes of Department like Product_Team or Employee could be added to a report definition, but values returned by this metric would still be aggregated at the Department level.
BY ALL
Description The BY ALL keyword is used to override a specified attribute dimension. (e.g. Date/Year lead created, Month/Year lead created, Quarter/Year lead created all represent attributes of varying granularity within the same dimension). This effectively prohibits any attribute of that dimension from breaking down the metric at hand. Syntax SELECT BY ALL
SELECT metric BY ALL attribute SELECT metric BY ALL attribute1, ALL attribute2
Examples
SELECT Payment BY ALL Year SELECT Payment / (SELECT Payment BY ALL Year) SELECT Payment / (SELECT Payment BY ALL Year, ALL Industry)
Note how in the example below, the number of leads is broken down by quarter in column 3, in column 4, the BY keyword has been used to set an aggregation floor at the Year level, returning annual lead values for 2012 and 2013. Compare these values to the final column: #Leads BY ALL Year. These numbers represent the total number of leads across all timethe sum of all leads recorded in the entire data set.
43
Figure 23 The BY ALL Year clause serves to override all attributes from the attribute dimension to which Year belongs.
Also of interest in the example above, is how #Leads BY ALL DATE, #LEADS BY ALL MONTH, and #LEADS BY ALL YEAR metrics all return identical values. This demonstrates that the granularity of the attribute added to the BY ALL clause doesnt affect the values that are returned. The attribute that follows BY ALL simply dictates that the dimension to which it belongs should not be able to break down the metric at hand. For this reason, even if the precise granularity of the attribute used in the BY ALL clause doesnt matter, an attribute must always be specified as a way of defining the dimension of interest. As the BY ALL YEAR metric from the final column of the table above shows, BY ALL overrides other date attributes in the reportkeeping them from affecting metric values in the final column. But this doesnt mean those metric values are immune to being broken down by non-date attributes as well. In the example below, note how the #Leads BY ALL Year metric values can be broken down by an Industry attribute even if they are not affected by date attributes. (#Leads BY ALL Year values for each industry are aggregated across all time. See how the industry figures are identical between Q4/2012 and Q1/2012.)
Figure 24 The BY ALL keyword only overrides the dimension of attributes specified within the BY ALL clause. The metric can still be broken down by attributes of other dimensionsin this case, that of Industry.
GoodData MAQL Reference Guide In the example above, we could also add ALL Industry to the end of our #Leads BY ALL Year metric syntax to override both the date attribute and industry attribute dimensions.
44
BY attribute ALL IN ALL OTHER DIMENSIONS

Description The first part of this keyword serves a similar role as the BY statement, defining an aggregation floor at the granularity level of the specified attribute. But the keyword also overrides all attributes in all other dimensionskeeping them from having any affect on the metric. NOTE: ALL IN ALL OTHER DIMENSIONS can be abbreviated as All Other Syntax SELECT BY ALL IN ALL OTHER DIMENSIONS
SELECT metric BY attribute IN ALL OTHER DIMENSIONS
Examples
SELECT SUM(Resolution_time) BY Quarter ALL IN ALL OTHER DIMENSIONS
BY ALL IN ALL OTHER DIMENSIONS

Description This keyword overrides all attributeskeeping the metric from being broken down at all. The metric remains aggregated at the highest possible level of aggregation across all dimensions. NOTE: ALL IN ALL OTHER DIMENSIONS can be abbreviated as All Other Syntax SELECT BY ALL IN ALL OTHER DIMENSIONS SELECT metric BY ALL IN ALL OTHER DIMENSIONS
GoodData MAQL Reference Guide Examples

SELECT Payment BY ALL IN ALL OTHER DIMENSIONS
45
SELECT Payment / (SELECT Payment BY ALL IN ALL OTHER DIMENSIONS)

NOTE: The second example above could be useful in a report that breaks data down with a Month attribute. The above metric would show the percent share of each months payments relative to the sum of all payments across all time and all other dimensions.
BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR attribute

Description This keyword clause overrides all attributes except for those attributes within the dimension of the attribute that is specified. NOTE: ALL IN ALL OTHER DIMENSIONS can be abbreviated as All Other Syntax SELECT BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR SELECT metric BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR attribute Examples
SELECT Payment BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR Date NOTE: In this example, Payment could be broken down by the Date attribute as well as any other attribute in the Date hierarchy, such as Month/Year, Quarter/Year, or Year.
Keywords for Overriding Report Filters

WITHOUT PARENT FILTER (WITHOUT PF)
Description This keyword overrides all filters that are defined in the active report. Syntax SELECT WITHOUT PARENT FILTER SELECT metric WITHOUT PARENT FILTER
Examples
SELECT Payment WITHOUT Parent Filter SELECT(SELECT Payment BY ALL Year WITHOUT PF) (SELECT
GoodData MAQL Reference Guide Payment)

NOTE: The second example above, when used in a report that filters out certain Payment values, would show the difference between all Payments and filtered Payments.
46
47
XII. Appendix: MAQL Expression Reference

The following MAQL expressions are displayed in the Aggregation, Filters, and Logical tab directories in GoodDatas Custom Metric Editor.
Aggregation functions are simple mathematical functions that can be performed on your facts to create metrics. (One exception is COUNT, which counts the number of distinct values of an attribute.)
Functions: SUM MAX MIN AVG COUNT Operations: Simple Arithmetic (+ - * /)
Filters allow you to narrow the set of data from which a metric is computed by targeting attribute values you wish to include or exclude from consideration. e.g. A metric showing sales from a particular region only
Logical expressions allow you to combine multiple filters. e.g. A metric showing sales from a particular region AND associated with a certain product
Special Operators: = (equals) <> (does not equal) IN NOT IN BETWEEN NOT BETWEEN BY BY ALL IN ALL OTHER DIMENSIONS BY attribute ALL IN ALL OTHER DIMENSIONS BY ALL IN ALL OTHER DIMENSIONS EXCEPT (FOR) attribute WITHOUT PARENT FILTER {This} {Previous} {Next}
Logical Expressions: NOT AND OR
Keywords
Macros
Copyright 2013 GoodData Corporation - All Rights Reserved.

MAQL Reference Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MAQL Reference Guide

Hochgeladen von

Copyright:

Verfügbare Formate

GoodData MAQL Reference Guide

Doc Date: May 10, 2013

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

GoodData MAQL Reference Guide

VIII. The WHERE Clause Filtering in MAQL ................................................................26

Operators for Defining Filters .................................................................................... 26

Time Macros for Filtering Floating Time Periods ...................................................... 29

Logical Expressions for Combining Filters ................................................................ 30

Functions For Referring to Future Time Periods ....................................................... 38

Keywords for Overriding Report Filters..................................................................... 45

XII. Appendix: MAQL Expression Reference .............................................................47

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

II. Basic Elements of GoodData

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

sum of sales average salary total costs count of Opportunity (attribute)

Descriptive values that belong to some common category, or attribute.

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide Dimensions

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

From Leads to Won Deals (marketing dashboard)

GoodSales GoodMarketing GoodSubscriptions

A collection of related facts and attributes, presented as a table.

Logical Data Model

GoodData MAQL Reference Guide

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

III. Creating Metrics in the Custom Metric Editor

Accessing the Custom Metric Editor

Using the Custom Metric Editor

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

Custom Metric Editor Text Field

Project Element Sidebar

GoodData MAQL Reference Guide

MAQL Directory Tabs

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

Local and Global Settings For Metrics

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

IV. Basic MAQL Syntax

Project Elements Must Be Inserted from the Sidebar

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

V. Using MAQL Aggregations to Form Metrics

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

SELECT COUNT(Store) SELECT COUNT(Employee, Facts_of_Call)

Counting Attribute Values In Specific Data Sets

Copyright 2013 GoodData Corporation All rights reserved.

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide

Copyright 2013 GoodData Corporation All rights reserved.

GoodData MAQL Reference Guide