# Home Inverse Finance powered Analytics {% hint style="info" %} This website is currently in construction. Please bear with us and don't hesitate to[ reach out to the AWG in discord for any questions.](https://discordapp.com/channels/790157548845924352/848225246443470848) {% endhint %} On March 9, 2022, Inverse Finance holders voted for the launch of the **Analytics Working Group** (AWG) within the DAO to support our growth, define further and execute the Data Strategy as per [proposal 7 of Mills era.](https://www.inverse.finance/governance/proposals/mills/7)

The main goal of the AWG is to enable members and users to seamlessly **access the data of their interest**, and to be able to **use it in the environment of their choice**. Because of all the tools and range of skills involved in the space, it is not always an easy task to do so. Within that perspective, the Analytics Working Group provides our members and users with the following : [**Dynamic Dashboards :**](/products/inverse-watch) based on **PostgreSQL** queries and relying on **an in house** flexible environment (forked from Redash), allowing on-the-fly analysis and CSVs extractions for specific or urgent needs ; [**GraphQL endpoints :**](/products/inverse-subgraphs) based on **The Graph** enabling to index on-chain events as soon as they happen and making the protocol information accessible to everyone through a **GraphQL endpoint ;** [**Alert and Social notifications :**](/products/inverse-alerts) thanks to our extensive infrastructure we are able to display beautiful notifications and alerts in Discord or Twitter, from any data source. Inverse Watch is a platform created by the AWG with the goal of centralizing its services, and make data analytics tasks less repetitive and more efficient in order to better serve the DAO. # Governance This page lists the governance proposals empowering the Analytics Working Group to carry its tasks and duties. ## **Proposal 7** {% embed url="" %} ## **Proposal 25** {% embed url="" %} ## **Proposal 52** {% embed url="" %} ## **Proposal 107** {% embed url="" %} ## **Proposal 147** ## ## **Proposal 189** ## # Inverse Alerts InverseAlerts is a robust and innovative bot based on the inverse.watch platform designed to deliver real-time blockchain market information to the public via Twitter. The primary objective of this bot is to democratize the complex realm of blockchain information and render it accessible, thereby making market movements and trends readily comprehensible for the general public.

The bot leverages the power of blockchain's transparency by tracking and analyzing complex on-chain activities. It identifies significant market moves, patterns, and trends on various blockchain networks and swiftly broadcasts this information on Twitter, making it easily accessible to anyone, anywhere. This on-demand, readily accessible information significantly aids in risk management by enabling users to make informed decisions and act swiftly based on market dynamics. Furthermore, InverseAlerts bolsters the transparency of blockchain transactions by delivering these insights to the public domain. The democratization of this information goes a long way in educating individuals about blockchain activities, thus promoting blockchain literacy and stimulating informed participation. The real-time, automated nature of the bot ensures that users are always kept abreast of the most current trends, fostering a sense of trust, confidence, and empowerment among users. [Follow us to stay informed !](https://twitter.com/InverseAlerts) # Inverse Chatbot The Inverse Flaskbot is a sophisticated Discord bot designed specifically to support the Inverse Finance DAO community. With its advanced data processing and AI capabilities, it serves as a pivotal tool in facilitating access to information, enhancing community engagement, and supporting content creation. By integrating a comprehensive set of machine learning and AI technologies, the Flaskbot provides a seamless experience for users to query finance-related documentation and generate creative visuals, aiding contributors in social media and web development endeavors. **Infrastructure and Key Technologies** The Flaskbot’s robust infrastructure is built upon a selection of cutting-edge technologies: * **Machine Learning Libraries (Ollama & Torch)**: These are the backbone for the bot's AI functionalities, allowing for complex data analysis and processing tasks. * **Natural Language Processing (Diffusers & Transformers)**: These tools enable the bot to understand and generate human-like text responses, making interactions intuitive. * **Image Generation (Open Source Models & Stablediffusion Pipeline)**: Powers the bot's ability to create images from textual descriptions, catering to the creative needs of the community. * **Adaptive AI Model Integration**: With the flexibility to switch between self-hosted models and OpenAI's cloud services, the Flaskbot ensures optimal performance for both text and image generation tasks, depending on resource availability and specific user requirements. This technology stack ensures that the Flaskbot is not just a chatbot but a comprehensive tool for information retrieval and creative content generation, tailored to the needs of the Inverse Finance DAO community. # /doc The `/doc` command is a cornerstone feature of the Inverse Flaskbot, designed to empower the Inverse Finance DAO community by providing quick and easy access to a vast repository of financial documentation. Whether it's detailed information about tokens, protocols, or lending practices, the `/doc` command ensures that community members can find accurate and relevant information instantly. **How to Use the `/doc` Command** 1. **Initiate a Query**: Simply type `/doc` followed by your specific question or keywords in any Discord channel where the Flaskbot is active. For example: `/doc what are DOLA and DBR ?` 2. **Review the Bot's Response**: The Flaskbot will quickly sift through the documentation and return a concise, relevant answer to your query.

3. **Iterate for More Details**: If necessary, refine your query with additional keywords to narrow down the search results for more precise information. # /imagine The `/imagine` command within the Inverse Flaskbot toolkit is a revolutionary feature designed for the Inverse Finance DAO community, particularly benefiting contributors focused on marketing, social media outreach, and web design. It provides an intuitive way to generate images that align with the DAO's unique brand identity, incorporating specific color schemes and thematic elements that resonate with the community's vision. **Crafting Images that Reflect the DAO's Identity** The Inverse Finance DAO's brand identity is characterized by its distinctive color palette of seafoam green, dark and light purples, and its iconic pixel invaders, all wrapped in a graffiti cypherpunk style. The `/imagine` command is perfectly suited to creating visuals that embody these elements, offering an endless stream of creativity for digital content that stands out. **How to Use the `/imagine` Command for Brand-Themed Visuals** 1. **Compose Your Description**: When using the `/imagine` command, craft a prompt that encapsulates the essence of the DAO's brand. Mention the specific colors, themes, and styles that should be featured. \ For example: `/imagine` a vibrant cityscape at night, illuminated by seafoam green and purple lights, pixel invaders tagging buildings with graffiti in a cypherpunk style `height: 1024` `width: 1792`

3. **Receive and Review Your Image**: The Flaskbot processes your detailed prompt and generates an image that brings your vision to life. This image will be shared in the Discord chat, providing you with a visual asset that perfectly aligns with the DAO's branding. 4. **Refine Your Request**: Don't hesitate to experiment with different combinations of themes, colors, and elements. The more specific you are with your descriptions, the closer the generated images will be to your envisioned outcome. #### Tips for Maximizing the Impact of the `/imagine` Command * **Be Detailed in Your Descriptions**: The effectiveness of the AI in generating your desired image heavily relies on the specificity and clarity of your prompt. Include details about the ambiance, key elements, and the overall mood you aim to capture. * **Incorporate Brand Elements**: Always weave in the DAO's core brand elements — seafoam green, dark and light purples, pixel invaders, and a graffiti cypherpunk style — to maintain a consistent and recognizable brand identity across all visuals. * **Utilize for Diverse Content Creation**: Think beyond social media posts. Use the `/imagine` command to create visuals for blog posts, website banners, promotional materials, and more, ensuring a cohesive and engaging brand presence across all platforms. The `/imagine` command is a potent tool in the Inverse Finance DAO's arsenal, empowering community members to generate visually compelling content that echoes the DAO's ethos and aesthetic preferences. By harnessing this feature, the community can ensure that every piece of content not only captures attention but also reinforces the unique identity of the Inverse Finance DAO across the digital landscape. # /data The `/data` command is an innovative feature of the Inverse Flaskbot designed to provide the Inverse Finance DAO community with direct access to a wealth of financial data and insights. By leveraging advanced AI agents, this command queries our extensive databases to fetch precise information, analytics, and insights, thereby supporting data-driven decision-making within the DAO. **How to Use** To utilize the `/data` command effectively, follow these steps: 1. **Invoke the Command**: Type `/data` followed by your specific query in any Discord channel where the Inverse Flaskbot is active. Ensure your query is clear and concise to facilitate accurate data retrieval. 2. **Wait for the Bot's Response**: The Flaskbot processes your query using AI agents and returns the requested data directly in the chat. The response will include key insights and information relevant to your query, formatted for easy comprehension. 3. **Refine Your Query if Needed**: If the initial response doesn't fully meet your needs, consider refining your query with additional details or keywords and repeat the process. **Example** * **User**: `/data current liquidity of DOLA in DeFi protocols` * **Bot Response**: "The current liquidity of DOLA across DeFi protocols is approximately $X,XXX,XXX. For more detailed breakdowns, please refer to \[link]." # /graph The `/graph` command is a sophisticated feature within the Inverse Flaskbot toolkit, designed to make GraphQL data fetching intuitive and accessible for the Inverse Finance DAO community. Unlike traditional GraphQL queries that require specific syntax, the `/graph` command understands natural language queries. This functionality allows users to request complex data sets from subgraphs without needing detailed knowledge of GraphQL query structure, significantly simplifying data access for community members. **How to Use** Fetching data with the `/graph` command is straightforward and user-friendly: 1. **Invoke the Command**: Type `/graph` followed by your query in natural language in any Discord channel where the Inverse Flaskbot is active. Clearly state what data you are looking for in a concise manner. Example : `/graph Show me the total value locked in Inverse Finance` 2. **Bot Processes Your Query**: The Flaskbot interprets your natural language query, formulates a corresponding GraphQL query, and fetches the requested data from the appropriate subgraph. 3. **Receive Your Data**: The bot will reply with the data you requested, presented in a clear and concise format directly in the Discord chat. 4. **Refine Your Query if Necessary**: If the initial response doesn't fully satisfy your request, you can refine your query with additional details or keywords and repeat the proc This approach to data fetching not only democratizes access to complex data sets but also enhances the overall user experience by allowing more intuitive interaction with the Inverse Flaskbot. By catering to natural language queries, the `/graph` command ensures that even users without technical backgrounds can effectively engage with and benefit from the wealth of data available through the DAO's subgraphs. # Inverse Subgraphs Subgraphs are open APIs that index blockchain data in a highly structured and accessible manner, enabling dApps and other users to query that data efficiently. They form an integral part of The Graph, a decentralized protocol for indexing and querying data from blockchains.

Inverse-Subgraph is a specialized subgraph developed to primarily index data from the deprecated lending protocol known as Frontier. Even though Frontier is no longer in active use, the historical data indexed and stored by Inverse-Subgraph can provide valuable insights into past trends, operations, and user behavior. This information can be instrumental for understanding and improving upon past practices, as well as aiding in the creation of new strategies and products. {% embed url="" %} See on mainnet {% endembed %} Inverse-Governance-Subgraph, on the other hand, is designed to index data from the Inverse DAO's governance model and the latest Fixed Rate Market lending protocol, FiRM. By tracking and storing all governance-related activities, this subgraph provides transparency and accountability, key aspects of any decentralized governance model. The indexing of FiRM data aids in monitoring its functioning and detecting any patterns or anomalies that may occur, thereby providing a robust risk management mechanism. {% embed url="" %} See on mainnet {% endembed %} Having subgraphs for the Inverse DAO is of immense value. They allow the DAO to structure its blockchain data effectively, making it easily accessible and queryable. This enhances the transparency, efficiency, and data utilization capacity of the DAO, promoting better governance and informed decision-making. Moreover, subgraphs can improve the performance of the DAO's dApps by enabling them to retrieve necessary data rapidly and accurately. # Inverse Watch Inverse Watch is an innovative product developed by the Inverse DAO Analytics Working Group. Designed to deliver comprehensive data analysis and alerting services, it equips stakeholders with the knowledge necessary to make informed decisions. Inverse Watch has positioned itself as a reliable source of transparent information, striving to deliver clear insights based on accurate and real-time data.

This sophisticated tool has been built leveraging Redash, an open-source platform for teams to query, visualize and collaborate around data. Redash has been integrated with a range of functionalities specific to the Web3 environment. Inverse Watch facilitates its users to monitor and analyze a wide array of blockchain activities. By integrating its systems with Twitter and Discord, it disseminates alerts and reports across these platforms, ensuring that information reaches users swiftly and conveniently. For Twitter, these reports manifest as tweet alerts about significant market movements and trends, while on Discord, the bot channels comprehensive reports for community members to analyze and discuss.

A significant feature of Inverse Watch is its capacity to render complex blockchain information accessible to the general public. By democratizing this data, it not only improves transparency but also enables individuals to actively participate in blockchain activities. Whether you're an experienced trader seeking detailed analytics or a newcomer looking for a friendly introduction to blockchain data, Inverse Watch provides an invaluable tool for navigating the ever-evolving landscape of decentralized finance. # Quickstart ### 1. Write A Query Let's explore how to write a query: **click on “Create” in the navigation bar, and then choose “Query”**. See the [Creating and Editing Queries](https://docs.inverse.watch/user-guide/queries/creating-and-editing-queries) for detailed instructions on how to write queries.

### 2. Add Visualizations By default, your query results (data) will appear in a simple table. Visualizations are much better to help you digest complex information, so let’s visualize your data. The application supports [multiple types of visualizations](https://docs.inverse.watch/user-guide/visualizations/visualizations-types) so you should find one that suits your needs. Click the “New Visualization” button just above the results to select the perfect visualization for your needs. You can view more detailed instructions [here](https://docs.inverse.watch/user-guide/visualizations/visualizations-how-to).

### 3. Create Dashboard You can combine visualizations and text into thematic & powerful dashboards. Add a new dashboard by clicking on “Create” in the navigation bar, and then choose “Dashboard”. Dashboards are visible for your team members or they can be shared publicly. For more details, [click here](https://docs.inverse.watch/user-guide/dashboards/creating-and-editing-dashboards).

# Alerts # Setting Up an Alert The application alerts notify you when a field returned by a [Schedule a Query](https://docs.inverse.watch/user-guide/queries/how-to-schedule-a-query) meets a threshhold. Use them to monitor your business. Or integrate them with tools like Zapier or IFTTT to kickoff workflows such as user on-boarding or support tickets. Alerts complement scheduled queries, but their criteria are checked after every execution. A query schedule is not required but is *highly recommended* for alerts. If you add an alert to a non-scheduled query you will be notified only if a user executes the query manually and the alert criteria are met. {% hint style="warning" %} A query schedule is not required but is *highly recommended* for alerts. If you add an alert to a non-scheduled query you will be notified only if a user executes the query manually and the alert criteria are met. {% endhint %} {% hint style="warning" %} Alerts don’t work for queries with parameters. {% endhint %} To see a list of current Alerts, click **Alerts** on the navbar. By default, they are sorted in reverse chronological order by the **Created At** column. You can reorder the list by clicking the column headings. * **Name** shows the string name of each alert. You can change this at any time. * **Created By** shows the user that created this Alert. * **State** shows whether the Alert status is `UNKNOWN`, `TRIGGERED`, or `OK`.

### 1. Usage Click the **Create** button in the navbar and then click **New Alert**. Search for a target query. If you don’t see the one you want, make sure it is published and does not use parameters. Use the settings panel to configure your alert. * The **Value column** dropdown controls which field of your query result will be evaluated. * The **Condition** dropdown controls the logical operation to be applied. * The **Threshold** text input will be compared against the *Value column* using the *Condition* you specify.

{% hint style="info" %} If a target query returns multiple records, the application Alerts only see the first one. As you change the Value Column setting, the current value of that field in the top row is shown beneath it. {% endhint %} Next, adjust how many notifications to receive while your alert is triggered. There are three options: * **Just Once until back to normal:** means a notification will fire any time the alert status changes from `OK` to `TRIGGERED`. * **Each time alert is evaluated until back to normal:** means a notification will fire whenever the alert status is `TRIGGERED` regardless of its status as of the previous evaluation. * **Each time alert is evaluated for each row in the result**: This means a notification will fire for every individual row in the alert evaluation result that meets the criteria for being TRIGGERED. Regardless of the status of other rows or the previous evaluation of the same row, a unique notification will be generated for each row that is currently in a TRIGGERED state. This choice allows for granular notifications based on each specific row, ensuring that no triggering row goes unnoticed. * **At most every ... when alert is evaluated:** lets you set a minimum interval between notifications. It splits the difference between *Just Once* and *Each time alert is evaluated*. This choice lets you avoid notification spam for alerts that trigger often. Regardless of which notification setting you pick here, you will receive a notification whenever the status goes from `OK` to `TRIGGERED` or from `TRIGGERED` to `OK`. The schedule settings above only impact how many notifications you will receive if the status remains `TRIGGERED` from one execution to the next. Finally, pick a **Template**. The **default template** is a message with links to the Alert configuration screen and the Query screen. Many users will want to include more specific information about the Alert. To do this you can [Customize The Alert Template](https://docs.inverse.watch/user-guide/alerts/customize-alert-template). When you’re finished, click **Create Alert** and then choose an [Alert Destination](https://redash.io/help/user-guide/alerts/creating-new-alert-destination). If you skip this step you will not be notified when the alert is triggered. ![](https://redash.io/assets/images/docs/gitbook/alert_destination.png) #### i. Muting Alerts You can temporarily mute an alert’s notifications without deleting the alert entirely. Just click the vertical ellipsis (`⋮`) menu and choose *Mute Notifications*. To resume notifications again, click the vertical ellipsis menu and choose *Unmute Notifications*. ### 2. Alert Statuses * `TRIGGERED` means that on the most recent execution, the *Value Column* in your target query met the *Condition* and *Threshhold* you configured. If your alert checks whether “cats” is above 1500, your alert will be triggered as long as “cats” is above 1500. * `OK` means that on the most recent query execution, the *Value Column* did not meet the *Condition* and *Threshhold* you configured. This doesn’t mean that the Alert was not triggered previously. If your “cats” value is now 1470 your alert will show as OK. * `UNKNOWN` means the application does not have enough data to evaluate the alert criteria. You will see this status immediately after creating your Alert until the query has executed. You will also see this status if there was no data in the query result or if the most recent query result doesn’t include the *Value Column* you configured ### 3. Notification Frequency The application sends notifications to your chosen Alert Destinations whenever it detects that the Alert status has changed from `OK` to `TRIGGERED` or vice versa. Consider this example where an Alert is configured on a query that is scheduled to run once daily. The daily status of the Alert appears in the table below. Prior to Monday the alert status was `OK`. | Day | Alert Status | | --------- | ------------ | | Monday | OK | | Tuesday | OK | | Wednesday | TRIGGERED | | Thursday | TRIGGERED | | Friday | TRIGGERED | | Saturday | TRIGGERED | | Sunday | OK | If the notification frequency is set to *Just Once*, the application would send a notification on Wednesday when the status changed from `OK` to `TRIGGERED` and again on Sunday when it switches back. It will not send alerts on Thursday, Friday, or Saturday unless you specifically configure it to do so because the Alert status did not change between executions on those days. # Adding New Alert Destinations ## Intro Whenever an Alert triggers, it sends a blob of related data (called the Alert Template) to its designated **Alert Destinations**. Destinations can use this blob of data to fire off emails, Slack messages, or custom web hooks. You can set up new Alert Destinations from the settings screen.

{% hint style="warning" %} Only Admins can add new alert destinations. Destinations are available to all users once configured. {% endhint %} ## Add A New Alert Destination There are a few types of destinations to choose from: * Email * Discord * Twitter * Twitter Private * Telegram {% hint style="info" %} The default destination for any alert is the email address for the user who created it. If you made an alert and need to be notified by email then you don’t need to setup a new Alert Destination. Instead, toggle the switch beside your email address on the alert setup screen. {% endhint %} To configure one, select it from **Create a New Alert Destination** dialogue and follow its prompts.

### Discord To set up a new Alert Destination for Discord: 1. **Create a Webhook in Discord**: * Go to your Discord server settings. * Click on the 'Integrations' tab. * Click the 'New Webhook' button and configure its settings like name and channel where alerts will be posted. * Copy the Webhook URL provided by Discord. 2. **Configure in Inverse Finance App**: * From the 'New Alert Destination' dialogue, choose 'Discord'.

* Paste the copied Webhook URL into the field provided. * Optional: Test the alert destination to ensure it's working correctly. * Save your settings. Once set, the application will send alerts to the designated Discord channel when they are triggered. ### Twitter To set up a new Alert Destination for Twitter: 1. **Create a Twitter Developer Account**: * If you don’t have a Twitter Developer account, apply for one at [Twitter Developer Portal](https://developer.twitter.com/). * Create an App under your developer account to get the API Key, API Secret Key, Access Token, and Access Token Secret. 2. **Configure in Inverse Finance App**: * From the 'New Alert Destination' dialogue, choose 'Twitter'. * Fill in the API Key, API Secret Key, Access Token, and Access Token Secret into the respective fields. * Optional: Specify whether the alerts should be published as a tweet (public) or sent as a Direct Message. For private alerts, choose 'Twitter Private'. * Optional: Test the alert destination to ensure it's working correctly. * Save your settings. Once set, the application will send alerts to the specified Twitter account when they are triggered, either as tweets or direct messages based on your preference. ### Twitter Private This destination type is exactly as the latter, at the difference that it sends the content of the template to the twitter user her/himself as a direct message. This is particularly useful if you want to test twitter alert destination without spaming all your subscribers. ### *** # Customize Alert Template The application alerts can notify you when your queries match some arbitrary criteria. Next to the setting labeled “Template”, click the dropdown and select “Custom template”. A box will appear, consisting of input fields for subject and body.

Any static content is valid, and you can also incorporate some built-in template variables: * `ALERT_STATUS` - The evaluated [alert status](https://docs.inverse.watch/user-guide/alerts/setting-up-an-alert) (string). * `ALERT_CONDITION` - The alert [condition operator](https://docs.inverse.watch/user-guide/alerts/setting-up-an-alert) (string). * `ALERT_THRESHOLD` - The alert [threshold](https://docs.inverse.watch/user-guide/alerts/setting-up-an-alert) (string or number). * `ALERT_NAME` - The alert name (string). * `ALERT_URL` - The alert page url (string). * `QUERY_NAME` - The correlated query name (string). * `QUERY_URL` - The correlated query page url (string). * `QUERY_RESULT_VALUE` - The query result value (string or number). * `QUERY_RESULT_ROWS` - The query result rows (value array). * `QUERY_RESULT_COLS` - The query result columns (string array). * `QUERY_RESULT_TABLE` - Query results formatted as two dimensional array of values. An example subject, for instance, could be: `Alert "{{ALERT_NAME}}" changed status to {{ALERT_STATUS}}` Click the “Preview” toggle button to preview the rendered result and save your changes by clicking the “Save” button. The preview is useful for verifying that template variables get rendered correctly. It is not an accurate representation of the eventual notification content, as each alert destinations can display notifications differently. {% hint style="warning" %} The preview is useful for verifying that template variables get rendered correctly. It is not an accurate representation of the eventual notification content, as each alert destinations can display notifications differently. {% endhint %} To return to the default the application message templates, re-select “Default template” at any time. Examples of two types of customized templates you can provide: **Text-Based Template**: * This type uses placeholders within a string to represent real-time data. * Placeholders are enclosed in double curly braces: `{{ }}`. * Use dot notation to access list items (e.g., `{{symbol.0}}` for the first item). * Formatting options (like `.2%` or `:,.2f`) can be appended to variables to display values in specific formats. {% hint style="warning" %} When using **"Each time alert is evaluated for each row in the result"**, you don't need to specify the row (e.g., {{symbol}} for the item). {% endhint %} **JSON-Based Template**: * This type employs the JSON format, offering a more structured and rich content presentation. * Key Elements: * **content**: A string where you can place general content. * **embeds**: An array that can contain multiple embed objects. Each embed object can have: * **title**: The main heading of the embed. * **color**: A numerical value representing the color of the embed line in decimal format. * **image**: An object with a URL for the image to display. * **fields**: An array of objects, where each object represents a piece of data to display. Each field can have: * **name**: The name or label for the data. * **value**: The value of the data, with placeholders (like `{{block_link}}`). * **inline**: A boolean (true or false) indicating if the field should be displayed inline with others. By understanding these elements, you can effectively customize alert templates in the application to suit your specific needs. Remember to always test your templates to ensure they display as expected when triggered. **Let's have a look at this example, using "Each time alert is evaluated for each row in the result" notification type** If we use this query:

We can write this custom template for our alert:

here's how the columns map to the template: * **block**: Reflected in the template as `{{block_link.2}}` which is a hyperlink to the block on Etherscan, referring to the third row of "block\_link" column. * **timestamp**: Appears in the template as `{{timestamp.2}}` and will display the timestamp of the event, referring to the third row of "timestamp" column. * **amount**: Appears as `{{amount.1:,.2f}} DOLA` in the template. The format `:,.2f` indicates that the amount will be displayed with two decimal places and commas as thousand separators, followed by the word "DOLA". `.1`refers to the second row of "amount" column. * **transaction\_hash**: Reflected as `{{transaction_hash_link.0}}` in the template, which is a hyperlink to the specific transaction on Etherscan. `.0` refers to the first row of "transaction\_hash\_link" column. Now if we want to use another notification type such as "**Each time alert is evaluated until back to normal"** and specify a particular row from the query result in the template, we can write this custom template: ```json { "content":"", "embeds":[ { "title":"Debt Converter : Redemption detected", "color":78368, "image":{ "url":"" }, "fields":[ { "name":"Block", "value":"{{block_link.2}}", // Referring to the third row's block link "inline":false }, { "name":"Timestamp", "value":"{{timestamp.2}}", // Referring to the third row's timestamp "inline":false }, { "name":"Amount", "value":"{{amount.1:,.2f}} DOLA", // Referring to the third row's amount "inline":false }, { "name":"Transaction", "value":"{{transaction_hash_link.0}}", // Referring to the third row's transaction link "inline":false } ] } ] } ``` If you wish to modify an alert, click the “Edit” button at the top of the alert page.

# Multiple Column Alert There’s an indirect way to set an Alert based on multiple columns of a query: Your query can implement the alert logic and return a boolean value for the Alert to trigger on. Something like: ```sql SELECT CASE WHEN drafts_count > 10000 AND archived_count > 5000 THEN 1 ELSE 0 END FROM ( SELECT sum(CASE WHEN is_archived THEN 1 ELSE 0 END) AS archived_count, sum(CASE WHEN is_draft THEN 1 ELSE 0 END) AS drafts_count FROM queries) data ``` This query will return 1 when drafts*count > 10000 and archived*count > 5000. Then you can configure the alert to trigger when the value is 1. # Queries # Creating and Editing Queries To make a new query, click `Create` in the navibar then select `Query`.

### 1. Query Editor ### i. Query Syntax In most cases we use the query language native to the data source. In some cases there are differences or additions, which are documented on the [Data Sources](https://docs.inverse.watch/user-guide/data-sources) page. ### ii. Keyboard Shortcuts * Execute query: `Ctrl`/`Cmd` + `Enter` * Save query: `Ctrl`/`Cmd` + `S` * Toggle Auto Complete: `Ctrl` + `Space` * Toggle Schema Browser `Alt`/`Option` + `D` ### iii. Schema Browser To the left of the query editor, you will find the Schema Browser:

The schema browser will list all your tables, and when clicking on a table will show its columns. To insert an item into your query, simply click the double arrow on the right side. You can filter the schema with the search box and refresh it by clicking on the refresh button (otherwise it refreshes periodically in the background). {% hint style="danger" %} Please note that not all data source types support loading the schema. {% endhint %} You can hide the Schema Browser using the key shortcut or by double-clicking the pane handle on the interface. This can be useful when you want to maximize screen realestate while composing a query. ### iv. Auto Complete The query editor also includes an Auto Complete feature that makes writing complicated queries easier. Live Auto Complete is on by default. So you will see table and column suggestions as you type. You can disable Live Auto Complete by clicking the lightning bolt icon beneath the query editor. When Live Auto Complete is disabled, you can still activate Auto Complete by hitting `CTRL` + `Space`. {% hint style="warning" %} Live Auto Complete is enabled by default unless your database schema exceeds five thousand tokens (tables or columns). In such cases, you can manually trigger Auto Complete using the keyboard shortcut. {% endhint %} Auto Complete looks for schema tokens, query syntax identifiers (like `SELECT` or `JOIN`) and the titles of [Query Snippets](https://docs.inverse.watch/user-guide/queries/query-snippets). ### 2. Query Settings ### i. Published vs Unpublished Queries By default each query starts as an unpublished draft named **New Query**. It can’t be included on dashboards or used with alerts. To publish a query, change its name or click the `Publish` button. You can toggle the published status by clicking the `Unpublish` button. Unpublishing a query will not remove it from dashboards or alerts. But it will prevent you from adding it to any others. {% hint style="warning" %} Publishing or un-publishing a query does not affect its visibility. All queries in your organization are visible to all logged-in users. {% endhint %} ### ii. Archiving a Query You can’t delete queries, but you can archive them. Archiving is like deleting, except **direct links to the query still work.** To archive a query, open the vertical ellipsis menu at the top-right of the query editor and click Archive.

### iii. Duplicating (Forking) a Query If you need to create a copy of an existing query (created by you or someone else), you can fork it. To fork a query, just click on the Fork button (see example below)

### iv. Managing Query Permissions By default, saved queries can only be modified by the user who created them and members of the Admin group. But support to edit permissions with non-admin users has been included. An Admin in your organization needs to enable it first. Open your organization settings and check the “Enable experimental multiple owners support”. ![Managing query permissions 1/2](https://redash.io/assets/images/docs/gitbook/experimental-owners-support.png) Now the Query Editor options menu includes a `Manage Permissions` option. Clicking on it it will open a dialog where you can add other users as editors to your query or dashboard. ![Managing query permissions 2/2](https://redash.io/assets/images/docs/gitbook/experimental-permissions-button.png) Please note that currently the users you add won’t receive a notification, so you will need to notify them manually. # Querying Existing Query Results The **Query Results Data Source** (QRDS) lets you run queries against results from your other Data Sources. Use it to join data from multiple databases or perform post-processing. We use uses an in-memory SQLite database to make this possible. As a result, queries against large result sets may fail if the application runs out of memory.

### 1. Querying Existing Query Results The QRDS accepts [SQLite query syntax](https://sqlite.org/lang.html): ``` SELECT a.name, b.count FROM query_123 AS a JOIN query_456 AS b ON a.id = b.id ``` Your other queries are like “tables” to the QRDS. Each one is aliased as `query_` followed by its `query_id` which you can see in the URL bar of your browser from the query editor. For example, a query at `/queries/49588` has the alias `query_49588`. {% hint style="warning" %} The query alias like query\_49588 must appear on the same line as its associated **FROM** or **JOIN** keyword. {% endhint %} ### 2. **Querying Existing Parameterized Query Results** When you're working with the application and you want to reference a **query that has parameters**, you use a special format. Let's delve deeper into it. **Format**: `param_query__{}` 1. **param\_query\_**: This prefix signals to the application that what follows is a query with parameters. 2. **\**: A unique identifier for your query in the application. For instance, if the query URL in the application ends with `/queries/45`, the ID is `45`. 3. **{\}**: Here, you insert the parameters for the query. These parameters should be URL encoded, which translates special characters into a format safe for online transmission. **Example**: Let's say you're querying the parameterized query below (its ID is 461):

You want to querying these existing parametrized query results using the **Query Results Data Source** (QRDS). You will create a new query as below: ```sql SELECT * FROM param_query_461_{contract_address="0x865377367054516e17014ccded1e7d814edc9ce4"&end_block=17838912&event_name="Transfer"&start_block=17838000} ```

**Explanation**: * `param_query_461_`: This means you're calling a specific, predefined parametrized query in the application with the ID `461`. * `{contract_address="0x865377367054516e17014ccded1e7d814edc9ce4"&end_block=17838912&event_name="Transfer"&start_block=17838000}`: This is where you add your parameters.

Parameter (URL ENCODED KEY)	Value (VALUE PARAMETER STRING)
contract_address	`0x865377367054516e17014ccded1e7d814edc9ce4`
end_block	`17838912`
event_name	`Transfer`
start_block	`17838000`

{% hint style="info" %} In this example, `contract_address` and `event_name` are of text type and should be enclosed in quotation marks (""). `end_block` and `start_block` are of number type. The order of the parameters inside the open curly bracket doesn't matter. {% endhint %} **Important remark on URL Encoding**: When a **parameter value** has special characters or spaces, it should be URL encoded. For example, if your **value parameter string** is John Doe, the space in "John Doe" is converted to %20 (John%20Doe). This page provides a comprehensive list of characters and their corresponding URL encoded values: **Note**: Always make sure that the parameter names you use match the names defined in the original query in the application. ### 3. Cached Query Results When you query the **Query Results Data Source**, the application executes the underlying queries first. This guarantees recent results in case you [schedule a QRDS query](https://docs.inverse.watch/user-guide/queries/how-to-schedule-a-query). You can speed up QRDS queries by using `cached_query_` for your query aliases instead of `query_`. This tells the application to use the cached results from the most recent execution of a given query. This improves performance by using older data. You can mix both syntaxes in the same query too: ```sql SELECT a.name, b.count FROM cached_query_123 AS a JOIN query_456 AS b ON a.id = b.id ``` ### 4. Query Results Permissions Access to the **Query Results Data Source** is governed by the groups it’s associated with like any other Data Source. But the application will also check if a user has permission to execute queries on the Data Sources the original queries use. As an example, a user with access to the QRDS cannot execute `SELECT * FROM query_123` if query `123` uses a data source to which that user does not have access. They will see the most recently cached QRDS query result from the query screen in the application. But they will not be able to execute the query again. # Query Parameters With parameters you can substitute values into your query at runtime without having to **Edit Source**. Any string between double curly braces `{{ }}` will be treated like a parameter. A widget will appear above the results pane so you change the parameter value.

In editing mode, you can click the gear icon for each parameter widget to adjust its settings. The gear icons disappear when you click **Show Data Only** so that users who don’t own the query can’t change the parameter behavior.

### 1. Add A Parameter From The UI You can insert a parameter into your query and immediately activate its settings pane by using the `Add Parameter` button or associated keyboard shortcut. The parameter will be inserted wherever the text caret appears in your query. If you find that you’ve inserted the parameter in the wrong part of the query, you can select the entire parameter (including the curly braces!) and cut/paste it wherever necessary. {% hint style="info" %} You can discover the key shortcut on your operating system by hovering your cursor above the `Add Parameter` button. {% endhint %} #### i. Parameter Settings Click the gear icon beside each parameter widget to edit its settings: * **Title** : by default the parameter title will be the same as the keyword in the query text. If you want to give it a friendlier name, you can change it here. * **Type** : each parameter starts as a Text type. Supported types are Text, Number, Date, Date and Time, Date and Time (with Seconds), and Dropdown List.

{% hint style="danger" %} For security reasons, user must have Full Access permission to the data source to use Text-type Query Parameters. Other types such as Date, Date Range, Number or Dropdown list are available to all users. {% endhint %} #### ii. Date and Date-Range Parameters Date Parameters use a familiar calendar picking interface and can default to the current date and time. You can chose from three levels of precision: Date, Date and Time, and Date and Time with seconds. Date Range Parameters insert two markers called `.start` and `.end` which signify the beginning and end of your chosen date range. ``` SELECT a, b c FROM table1 WHERE relevant_date >= '{{ myDate.start }}' AND table1.relevant_date <= '{{ myDate.end }}' ``` {% hint style="info" %} Date parameters are passed as strings to your database. So you should wrap them in single quotes (') or whatever your database uses to declare strings. Although they behave like Text parameters Dates are still safe for use in embeds and share dashboards. {% endhint %} Date Range parameters use a combined widget to simplify range selection.

* Quick Date and Date-Range Options When you add a Date or Date Range parameter to your query, the selection widget shows a blue lightning bolt glyph. Click the glyph to see dynamic values like “Today” or “Yesterday”. There are dynamic date range options too. The complete list of dynamic date-ranges is: * This week * This month * This year * Last week * Last month * Last year * Last 7 days * Last 14 days * Last 30 days * Last 60 days * Last 90 days * Last 12 months {% hint style="warning" %} Because dynamic dates and date ranges are calculated in the front-end, they aren’t compatible with Scheduled Queries. {% endhint %} #### iii. Dropdown Lists If you want to restrict the scope of possible parameter values when running a query, you can use the application’s `Dropdown List` parameter type. When selected from the parameter settings panel, a text box appears where you can enter your allowed values, each one separated by a new line. Dropdown lists are `Text` parameters under the hood, so if you want to use dates/datetimes in your dropdown, you should enter them in the format your data source requires.

* Query Based Dropdown List Dropdown lists can also be tied to the results of an existing query. Just click `Query Based Dropdown List` under **Type** in the settings panel. Search for your target query in the **Query to load dropdown values from** bar. Performance will degrade if your target query returns a large number of records. If your target query returns more than one column, the application uses the *first* one. If your target query returns `name` and `value` columns, the application populates the parameter selection widget with the `name` column but executes the query with the associated `value`. For example, suppose this query: ``` SELECT user_uuid as ‘value’, username as ‘name’ FROM users ``` returned this data: | value | name | | ----- | ------------ | | 1001 | John Smith | | 1002 | Jane Doe | | 1003 | Bobby Tables | The application’s dropdown list widget would look like this:

But when the application executes the query, the value passed to the database would be 1001, 1002 or 1003. * Serialized Multi-Select Dropdown lists can also be serialized to allow for multi-select. Just toggle the **Allow multiple values** option and choose whether or not to wrap the parameters with single quotes or double-quotes.

In your query, change your `WHERE` clause to use the `IN` keyword. ``` SELECT ... FROM ... WHERE field IN ( {{ Multi Select Parameter }} ) ``` The parameter multi-selection widget let you pass extra values to the database. #### iv. FAQ **Can I reuse the same parameter multiple times in a single query?** Sure! Just use the same identifier in the curly brackets. In this example: ```sql SELECT {{org_id}}, count(0) FROM queries WHERE org_id = {{org_id}} ``` We use the `{{org_id}}` parameter twice. **Can I use multiple parameters in a single query?** Of course, just use a unique name for each one. In this example: ```sql SELECT count(0) FROM queries WHERE org_id = {{org_id}} AND created_at > '{{start_date}}' ``` We use two parameters: `{{org_id}}` and `{{start_date}}`. **Can I use parameters in embedded visualizations and shared dashboards?** Yes, with one exception. If a query uses a Text type parameter it cannot be embedded because Text parameters are not safe from SQL injection. All other types of query parameters can be used safely in embedded visualizations and dashboards. | Parameter Type | Safe for Embedding? | | ----------------------------- | ------------------- | | Text | No | | Number | Yes | | Dropdown List | Yes | | Query Based Dropdown List | Yes | | Date | Yes | | Date and Time | Yes | | Date and Time w/Seconds | Yes | | Date Range | Yes | | Date and Time Range | Yes | | Date and Time Range w/Seconds | Yes | **Can I change parameter values via the URL?** Yes. Each parameter appears in the URL query string preceded by `p_`. A query with id `1234` and the following query text: ``` SELECT * FROM table WHERE field = {{param}} ``` Would have link a like so: `https://app.redash.io//queries/1234?p_param=100` This is useful for linking between queries and dashboards. ### 2. Parameter Mapping on Dashboards Query Parameters can also be powerfully controlled within dashboards. You can link together parameters on different widgets, set static parameter values, or choose values individually for each widget. You select your desired parameter mapping when adding dashboard widgets that depend on a parameter value. Each parameter in the underlying query will appear in the **Parameters** list.

{% hint style="info" %} You can also access the parameter mapping interface by clicking the vertical ellipsis (⋮) on the top right of a dashboard widget then clicking **Edit Parameters**. {% endhint %} * **Title** is the display name for your parameter and will appear beside the value selector on your dashboard. It defaults to the parameter keyword (see next bullet). Edit it by clicking the pencil glyph. Note that a titles are not displayed for static dashboard parameters because the value selector is hidden. If you select `Static value` as your Value Source then the Title field will be grayed out. * **Keyword** is the string literal for this parameter in the underlying query. This is useful for debugging if your dashboard does not return expected results. * **Default Value** is what the application will use if no other value is specified. To change this from the query screen, execute the query with your desired parameter value and click the **Save** button. * **Value Source** is where you choose your preferred mapping. Click the pencil glyph to open the mapper settings. #### i. Value Source Options * **New dashboard parameter:** Dashboard parameters allow you to set a parameter value in one place on your dashboard and map it to multiple visualizations. Use this option to create a new dashboard-level parameter. * **Existing dashboard parameter:** If you have already set up a dashboard-level parameter, use this option to map it to a specific query parameter. You will need to specify which pre-existing dashboard parameter will be mapped. * **Widget parameter:** This option will display a value selector inside your dashboard widget. This is useful for one-off parameters that are not shared between widgets. * **Static value:** Selecting this option will let you choose a static value for this widget, regardless of the values used on other widgets. Statically mapped parameter values do not display a value selector anywhere on the dashboard which is more compact. This lets you take advantage of the flexibility of Query Parameters without cluttering the user interface on a dashboard when certain parameters are not expected to change frequently. #### # How to Schedule a Query You can use scheduled query executions to keep your dashboards updated or to power routine Alerts. By default, your queries will not have a schedule. But this is easy to adjust. In the bottom left corner of the query editor you’ll see the schedule area. Clicking **Never** will open a picker with allowed schedule intervals.

Your query will run automatically once a schedule is set. When you schedule queries to run at a certain time-of-day, the application converts your selection to UTC using your computer’s local timezone. That means if you want a query to run at a certain time in UTC, you need to adjust the picker by your local offset. For example, if you want a query to execute at `00:00` UTC each day but your current timezone is CDT (UTC-5), you should enter `19:00` into the scheduler. The UTC value is displayed to the right of your selection to help confirm your math. ### Scheduled Query Failure Reports The application has the ability to email query owners once per hour if one or more queries failed. These emails continue until there are no more failures. Failure report emails run on an independent process from the actual query schedules. It may take up to an hour after a failed query execution before the application sends the failure report. You can toggle failure reports from your organizations settings. Under **Feature Flags** check **Email query owners when scheduled queries fail**.

# Favorites & Tagging Users will write a lot of queries and dashboards! Favorites and Tagging are here to make finding them easy as your collection of queries and dashboards grows from a few hundred to a few thousand.

### 1. Favorites You can favorite a dashboard or query by clicking the star to the left of its title anywhere in the application. The star will turn yellow to indicate success. Your favorites are displayed at several places in the application. They appear on the homepage, in the navbar dropdown menus and as filters in the query or dashboard list views.

### 2. Tagging You can tag queries and queries by subject matter, location, user or any parameter that is meaningful to your organization. Tags are added from the query editor or the dashboard editor. Hover your mouse on the query or dashboard title and an `+Add Tag` button will appear. In the modal that appears you can select as many tags as you need. The modal will suggest previously-used tags as you type. Hit `Save` when you’re finished or `Esc` to abort tagging. {% hint style="info" %} It’s important to have predictable taxonomy for your tags. Consistency in this area makes using the application an even nicer experience and helps bring new users onboard. So we recommend that your team have an internal discussion about the tag hierarchy that will be most beneficial to your organization. {% endhint %}

Your tags will appear on the Dashboard and Query list views on the righthand side. You can filter the by tag by cliking on the desire tag on the tag section. Click a second time to remove the filter. `Shift + Click` to select multiple filters

### # Query Filters Query Filters let you interactively reduce the amount of data shown in your visualizations, similar to Query Parameters but with a few key differences. Query Filters limit data **after** it has been loaded into your browser. This makes them ideal for smaller datasets and environments where query executions are time-consuming, rate-limited, or costly. ### 1. Usage Unlike Query Parameters there isn’t a button to add a filter. Instead, if you want to focus on a specific value, just alias your column to `::filter`. Here’s an example: ```sql SELECT action AS "action::filter", COUNT(0) AS "actions count" FROM events GROUP BY action ``` {% hint style="info" %} Note that you can use`__filter` or `__multiFilter`, (double underscore instead of double quotes) if your database doesn’t support :: in column names (such as BigQuery). {% endhint %} ![](https://redash.io/assets/images/docs/gitbook/filter_example_action_create.png) If you need a multi-select filter then alias your column to `::multi-filter`. ``` SELECT action AS "action::multi-filter", COUNT (0) AS "actions count" FROM events GROUP BY action ``` ![](https://redash.io/assets/images/docs/gitbook/multifilter_example.png) You can use Query Filters on dashboards too. By default, the filter widget will appear beside each visualization where the filter has been added to the query. If you’d like to link together the filter widgets into a dashboard-level Query Filter see [these instructions](https://redash.io/help/user-guide/dashboards/dashboard-editing). ### 2. Limitations Query Filters aren’t suitable for especially large data sets or query results with hundreds or thousands of distinct field values. Depending on your computer and browser configuration, excessive data can deteriorate the user experience. # How To Download / Export Query Results ### 1. How to download a query result Visit any query page and click the vertical ellipsis (`⋮`) button beneath the results pane. Then choose to download a CSV, TSV, or Excel file. This action downloads the current query result.

### 2. How to get latest results via the API Visit any query page and click the horizontal ellipsis (`…`) above the query editor. Then choose **Show API Key**. The links in the modal that appears always point to the latest query result. You can choose between CSV and JSON formats to be returned by the API call. {% hint style="info" %} It’s not shown in the interface, but you can also get the Excel format by changing the file type suffix from `json`/`csv` to `xlsx`. {% endhint %}

{% hint style="warning" %} The latest results API is not supported for queries that use parameters. {% endhint %} # Query Snippets ### 1. Create A Query Snippet Copy and Paste are a big part of composing database queries. Because it’s much easier to duplicate prior work than to write it from scratch. This is particularly true for common `JOIN` statements or complex `CASE` expressions. As your list of queries in the application grows, however, it can be difficult to remember which queries contain the statement you need right now. Enter Query Snippets. Query Snippets are segments of queries that your whole team can share and trigger via auto complete. You create them at `Settings` -> `Query Snippets`. Here’s an example for a simple snippet: ``` JOIN organizations org ON org.id = ${1:table}.org_id ```

### 2. Insert A Query Snippet If you have Live Auto Complete enabled, you can invoke your snippet from the Query Editor by typing the trigger word you defined in the Query Snippet editor. Auto Complete will suggest it like any other keyword in your database. Here are some other ideas for snippets: * Frequent `JOIN` statements * Complicated clauses like `WITH` or `CASE`. * [Conditional Formatting](https://discuss.redash.io/t/conditional-formatting-general-text-formatting/1706/1) When the application renders the snippet, the dollar sign `$` and curly braces `{}` will be stripped away and the word `table` will be highlighted for the user to replace.

When the application renders the snippet, the dollar sign `$` and curly braces `{}` will be stripped away and the word `table` will be highlighted for the user to replace.

### 3. Insertion Points In the example above, `${1:table}` is an insertion point with placeholder text. In the example above, `${1:table}` is an insertion point with placeholder text. {% hint style="info" %} You can use the placeholder text as a desirable default value for the user to override at runtime. {% endhint %} You designate insertion points by wrapping an integer tab order with a single dollar sign and curly braces `${}`. A text placeholder preceded by a colon `:` is optional but useful for users unfamiliar with your snippet. When the application renders this snippet: ``` AND (invoices.complete IS NULL OR invoices.complete <> '${2}') AND (invoices.canceled IS NULL OR invoices.canceled <> '${1}') AND (invoices.modified IS NULL OR invoices.modified_date <> '${0: this_date}') ``` The text insertion carat will jump to the second line between the quote marks `''`. When the user presses `Tab` the carat will jump *backwards* onto the first line. When the user presses `Tab` again, the carat will jump to the third line and `this_date` will be highlighted to prompt the user for the desired value.

{% hint style="info" %} An insertion point of zero `${0}` is always the *last* point in the tab order. {% endhint %} {% hint style="warning" %} If Live Auto Complete is disabled, you can still invoke Query Snippets by pressing `CTRL + Space` and typing the trigger word for your Query Snippet. This can be necessary if your schema exceeds 5000 tokens. {% endhint %} # Visualizations # Cohort Visualizations ## Cohorts Introduction A cohort analysis examines the outcomes of predetermined groups, called cohorts, as they progress through a set of stages. The signature characteristic of a cohort chart is its comparison of the change in a variable across two different time series. For example, a common cohort definition is users by sign-up period and their usage pattern by day. Other examples include: * Monthly hard drive failure statistics by month * Weekly supplier delivery performance by week * Monthly average class GPA’s by month While there are many ways to define the stages of a Cohort analysis, the application supports Cohorts visualizations with daily, weekly, or monthly stages. Also, the application's cohort charts compare a cohort’s measurements in a given period against that group’s initial population size. #### i. Data Format The application expects your input samples to take the following format: * **Cohort Date** is the date that uniquely identifies a cohort. Suppose you’re visualizing monthly user activity by sign-up date, your cohort date for all users that signed-up in January 2018 would be January 1st, 2018. The cohort date for any user that signed-up in February would be February 1st, 2018. * **Period** is a count of how many periods transpired since the cohort date as of this sample. If you are grouping users by sign-up month, then your period will be the count of months since these users signed up. In the above example, a measurement of activity in July for users that signed up in January would yield a period value of 7 because seven periods have transpired between January and July. * **Count Satisfying Target** is your actual measurement of this cohort’s performance in the given period. In the above example, if thirty users who signed up in January showed activity in July then the Count Satisfying Target would be 30. * **Total Cohort Size** is the denominator that the application will use to calculate the percentage of a cohort’s target satisfaction for a given period. Continuing the example above, if seventy-two users signed up in January then the Total Cohort Size would be 72. When the visualization is rendered, the application would display the value as 41.67% (32 ÷ 72). ### # Visualizations How-To ### 1. Create a New Visualization Once your query has finished running for the first time, you can add a visualization by clicking the “New Visualization” button above the results table.

### 2. Edit A Visualization You can modify the settings of an existing visualization from the query editor screen. Click the visualization on the tab bar and you’ll see an `Edit Visualization` option beneath each visualization. Clicking it will open the current settings for that visualization (type, X axis, Y axis, groupings etc.). Hit “Save” to apply your changes or “Cancel” to leave no trace.

### 3. Embedding Visualizations It’s easy to embed visualizations. Just click the ellipsis button beneath any visualization to show further options and select `Embed Elsewhere`. This will pop up the `