Hex Usage in Euno

Hex Usage in Euno

Euno tracks the usage history of Hex projects (hex_project) to help you understand adoption and impact. Use Hex usage data to:

• Identify published projects (apps) that are frequently viewed and deserve investment.

• Find projects with low or no activity to archive or consolidate.

• Correlate user interest (impressions) with warehouse load (read queries).

Types of Usage Data Captured

Euno associates two kinds of usage information to hex_projects. These represent different perspectives and may not always align.

1) Impression Records (from Hex)

• Definition: A view event captured by Hex when end‑users open a published Hex project (i.e., an app).

• Source: Hex API.

• Availability: Only for projects where is_published is true. Impressions do not exist for drafts/unpublished projects.

• Aggregations Provided:

  • total_impressions_{x}d

  • distinct_impressions_users_{x}d

• Notes:

  • {x} denotes a trailing window in days (e.g., 14d, 30d, 60d).

  • These metrics reflect viewing/adoption, not compute load.

2) Warehouse Query Records (from your data warehouse)

• Definition: Read queries issued to the warehouse as a result of running Hex projects (whether published or not), where the specific project is tagged via comments/metadata.

• Source: Warehouse query logs (e.g., Snowflake) if Hex usage observation is enabled in your data‑warehouse source configuration in Euno.

• Association Mechanism: Euno parses comments with Hex tags to associate queries back to the relevant hex_project resource.

• Aggregations Provided:

  • total_read_queries_{x}d

  • distinct_users_{x}d

• Notes:

  • Available for any project whose queries carry the Hex tags, regardless of publication status.

  • These metrics reflect compute/cost impact and operational load.

When to Use Which

• Use Impression Records when you care about popularity and organizational adoption (what people are actually viewing/opening).

• Use Warehouse Query Records when you care about cost, database load, and latency (actual workloads submitted to the warehouse).

Why Impressions and Warehouse Queries Can Differ

There are several reasons these two signals won’t match exactly:

• Published vs. Draft: Draft/unpublished projects can generate warehouse reads (runs, edits, tests) without producing impressions (since impressions exist only for published apps).

• Scheduled/Automated Runs: Scheduled or programmatic executions can generate warehouse queries without any corresponding human views in the same window.

• Editing & Iteration: While editing a project, developers can trigger multiple read queries even if there are zero or very few impressions.

• Caching & Data Source Differences: Downstream caching layers or federated sources may reduce/increase warehouse reads independently of view counts.

Prerequisites & Configuration

• Impressions: Ensure Hex projects are published to collect total_impressions_{x}d and distinct_impressions_users_{x}d.

• Warehouse Queries: In Euno, enable the Hex usage observation option for your data‑warehouse source so that comments with Hex tags are ingested and mapped to hex_projects.