opencode-knowledge-work 0.0.0-stage → 0.1.1

package/content/data/skills/data-sql-queries/SKILL.md

@@ -0,0 +1,428 @@
+---
+name: sql-queries
+description: Write correct, performant SQL across all major data warehouse dialects (Snowflake, BigQuery, Databricks, PostgreSQL, etc.). Use when writing queries, optimizing slow SQL, translating between dialects, or building complex analytical queries with CTEs, window functions, or aggregations.
+user-invocable: false
+---
+
+# SQL Queries Skill
+
+Write correct, performant, readable SQL across all major data warehouse dialects.
+
+## Dialect-Specific Reference
+
+### PostgreSQL (including Aurora, RDS, Supabase, Neon)
+
+**Date/time:**
+```sql
+-- Current date/time
+CURRENT_DATE, CURRENT_TIMESTAMP, NOW()
+
+-- Date arithmetic
+date_column + INTERVAL '7 days'
+date_column - INTERVAL '1 month'
+
+-- Truncate to period
+DATE_TRUNC('month', created_at)
+
+-- Extract parts
+EXTRACT(YEAR FROM created_at)
+EXTRACT(DOW FROM created_at)  -- 0=Sunday
+
+-- Format
+TO_CHAR(created_at, 'YYYY-MM-DD')
+```
+
+**String functions:**
+```sql
+-- Concatenation
+first_name || ' ' || last_name
+CONCAT(first_name, ' ', last_name)
+
+-- Pattern matching
+column ILIKE '%pattern%'  -- case-insensitive
+column ~ '^regex_pattern$'  -- regex
+
+-- String manipulation
+LEFT(str, n), RIGHT(str, n)
+SPLIT_PART(str, delimiter, position)
+REGEXP_REPLACE(str, pattern, replacement)
+```
+
+**Arrays and JSON:**
+```sql
+-- JSON access
+data->>'key'  -- text
+data->'nested'->'key'  -- json
+data#>>'{path,to,key}'  -- nested text
+
+-- Array operations
+ARRAY_AGG(column)
+ANY(array_column)
+array_column @> ARRAY['value']
+```
+
+**Performance tips:**
+- Use `EXPLAIN ANALYZE` to profile queries
+- Create indexes on frequently filtered/joined columns
+- Use `EXISTS` over `IN` for correlated subqueries
+- Partial indexes for common filter conditions
+- Use connection pooling for concurrent access
+
+---
+
+### Snowflake
+
+**Date/time:**
+```sql
+-- Current date/time
+CURRENT_DATE(), CURRENT_TIMESTAMP(), SYSDATE()
+
+-- Date arithmetic
+DATEADD(day, 7, date_column)
+DATEDIFF(day, start_date, end_date)
+
+-- Truncate to period
+DATE_TRUNC('month', created_at)
+
+-- Extract parts
+YEAR(created_at), MONTH(created_at), DAY(created_at)
+DAYOFWEEK(created_at)
+
+-- Format
+TO_CHAR(created_at, 'YYYY-MM-DD')
+```
+
+**String functions:**
+```sql
+-- Case-insensitive by default (depends on collation)
+column ILIKE '%pattern%'
+REGEXP_LIKE(column, 'pattern')
+
+-- Parse JSON
+column:key::string  -- dot notation for VARIANT
+PARSE_JSON('{"key": "value"}')
+GET_PATH(variant_col, 'path.to.key')
+
+-- Flatten arrays/objects
+SELECT f.value FROM table, LATERAL FLATTEN(input => array_col) f
+```
+
+**Semi-structured data:**
+```sql
+-- VARIANT type access
+data:customer:name::STRING
+data:items[0]:price::NUMBER
+
+-- Flatten nested structures
+SELECT
+    t.id,
+    item.value:name::STRING as item_name,
+    item.value:qty::NUMBER as quantity
+FROM my_table t,
+LATERAL FLATTEN(input => t.data:items) item
+```
+
+**Performance tips:**
+- Use clustering keys on large tables (not traditional indexes)
+- Filter on clustering key columns for partition pruning
+- Set appropriate warehouse size for query complexity
+- Use `RESULT_SCAN(LAST_QUERY_ID())` to avoid re-running expensive queries
+- Use transient tables for staging/temp data
+
+---
+
+### BigQuery (Google Cloud)
+
+**Date/time:**
+```sql
+-- Current date/time
+CURRENT_DATE(), CURRENT_TIMESTAMP()
+
+-- Date arithmetic
+DATE_ADD(date_column, INTERVAL 7 DAY)
+DATE_SUB(date_column, INTERVAL 1 MONTH)
+DATE_DIFF(end_date, start_date, DAY)
+TIMESTAMP_DIFF(end_ts, start_ts, HOUR)
+
+-- Truncate to period
+DATE_TRUNC(created_at, MONTH)
+TIMESTAMP_TRUNC(created_at, HOUR)
+
+-- Extract parts
+EXTRACT(YEAR FROM created_at)
+EXTRACT(DAYOFWEEK FROM created_at)  -- 1=Sunday
+
+-- Format
+FORMAT_DATE('%Y-%m-%d', date_column)
+FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', ts_column)
+```
+
+**String functions:**
+```sql
+-- No ILIKE, use LOWER()
+LOWER(column) LIKE '%pattern%'
+REGEXP_CONTAINS(column, r'pattern')
+REGEXP_EXTRACT(column, r'pattern')
+
+-- String manipulation
+SPLIT(str, delimiter)  -- returns ARRAY
+ARRAY_TO_STRING(array, delimiter)
+```
+
+**Arrays and structs:**
+```sql
+-- Array operations
+ARRAY_AGG(column)
+UNNEST(array_column)
+ARRAY_LENGTH(array_column)
+value IN UNNEST(array_column)
+
+-- Struct access
+struct_column.field_name
+```
+
+**Performance tips:**
+- Always filter on partition columns (usually date) to reduce bytes scanned
+- Use clustering for frequently filtered columns within partitions
+- Use `APPROX_COUNT_DISTINCT()` for large-scale cardinality estimates
+- Avoid `SELECT *` -- billing is per-byte scanned
+- Use `DECLARE` and `SET` for parameterized scripts
+- Preview query cost with dry run before executing large queries
+
+---
+
+### Redshift (Amazon)
+
+**Date/time:**
+```sql
+-- Current date/time
+CURRENT_DATE, GETDATE(), SYSDATE
+
+-- Date arithmetic
+DATEADD(day, 7, date_column)
+DATEDIFF(day, start_date, end_date)
+
+-- Truncate to period
+DATE_TRUNC('month', created_at)
+
+-- Extract parts
+EXTRACT(YEAR FROM created_at)
+DATE_PART('dow', created_at)
+```
+
+**String functions:**
+```sql
+-- Case-insensitive
+column ILIKE '%pattern%'
+REGEXP_INSTR(column, 'pattern') > 0
+
+-- String manipulation
+SPLIT_PART(str, delimiter, position)
+LISTAGG(column, ', ') WITHIN GROUP (ORDER BY column)
+```
+
+**Performance tips:**
+- Design distribution keys for collocated joins (DISTKEY)
+- Use sort keys for frequently filtered columns (SORTKEY)
+- Use `EXPLAIN` to check query plan
+- Avoid cross-node data movement (watch for DS_BCAST and DS_DIST)
+- `ANALYZE` and `VACUUM` regularly
+- Use late-binding views for schema flexibility
+
+---
+
+### Databricks SQL
+
+**Date/time:**
+```sql
+-- Current date/time
+CURRENT_DATE(), CURRENT_TIMESTAMP()
+
+-- Date arithmetic
+DATE_ADD(date_column, 7)
+DATEDIFF(end_date, start_date)
+ADD_MONTHS(date_column, 1)
+
+-- Truncate to period
+DATE_TRUNC('MONTH', created_at)
+TRUNC(date_column, 'MM')
+
+-- Extract parts
+YEAR(created_at), MONTH(created_at)
+DAYOFWEEK(created_at)
+```
+
+**Delta Lake features:**
+```sql
+-- Time travel
+SELECT * FROM my_table TIMESTAMP AS OF '2024-01-15'
+SELECT * FROM my_table VERSION AS OF 42
+
+-- Describe history
+DESCRIBE HISTORY my_table
+
+-- Merge (upsert)
+MERGE INTO target USING source
+ON target.id = source.id
+WHEN MATCHED THEN UPDATE SET *
+WHEN NOT MATCHED THEN INSERT *
+```
+
+**Performance tips:**
+- Use Delta Lake's `OPTIMIZE` and `ZORDER` for query performance
+- Leverage Photon engine for compute-intensive queries
+- Use `CACHE TABLE` for frequently accessed datasets
+- Partition by low-cardinality date columns
+
+---
+
+## Common SQL Patterns
+
+### Window Functions
+
+```sql
+-- Ranking
+ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)
+RANK() OVER (PARTITION BY category ORDER BY revenue DESC)
+DENSE_RANK() OVER (ORDER BY score DESC)
+
+-- Running totals / moving averages
+SUM(revenue) OVER (ORDER BY date_col ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as running_total
+AVG(revenue) OVER (ORDER BY date_col ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as moving_avg_7d
+
+-- Lag / Lead
+LAG(value, 1) OVER (PARTITION BY entity ORDER BY date_col) as prev_value
+LEAD(value, 1) OVER (PARTITION BY entity ORDER BY date_col) as next_value
+
+-- First / Last value
+FIRST_VALUE(status) OVER (PARTITION BY user_id ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
+LAST_VALUE(status) OVER (PARTITION BY user_id ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
+
+-- Percent of total
+revenue / SUM(revenue) OVER () as pct_of_total
+revenue / SUM(revenue) OVER (PARTITION BY category) as pct_of_category
+```
+
+### CTEs for Readability
+
+```sql
+WITH
+-- Step 1: Define the base population
+base_users AS (
+    SELECT user_id, created_at, plan_type
+    FROM users
+    WHERE created_at >= DATE '2024-01-01'
+      AND status = 'active'
+),
+
+-- Step 2: Calculate user-level metrics
+user_metrics AS (
+    SELECT
+        u.user_id,
+        u.plan_type,
+        COUNT(DISTINCT e.session_id) as session_count,
+        SUM(e.revenue) as total_revenue
+    FROM base_users u
+    LEFT JOIN events e ON u.user_id = e.user_id
+    GROUP BY u.user_id, u.plan_type
+),
+
+-- Step 3: Aggregate to summary level
+summary AS (
+    SELECT
+        plan_type,
+        COUNT(*) as user_count,
+        AVG(session_count) as avg_sessions,
+        SUM(total_revenue) as total_revenue
+    FROM user_metrics
+    GROUP BY plan_type
+)
+
+SELECT * FROM summary ORDER BY total_revenue DESC;
+```
+
+### Cohort Retention
+
+```sql
+WITH cohorts AS (
+    SELECT
+        user_id,
+        DATE_TRUNC('month', first_activity_date) as cohort_month
+    FROM users
+),
+activity AS (
+    SELECT
+        user_id,
+        DATE_TRUNC('month', activity_date) as activity_month
+    FROM user_activity
+)
+SELECT
+    c.cohort_month,
+    COUNT(DISTINCT c.user_id) as cohort_size,
+    COUNT(DISTINCT CASE
+        WHEN a.activity_month = c.cohort_month THEN a.user_id
+    END) as month_0,
+    COUNT(DISTINCT CASE
+        WHEN a.activity_month = c.cohort_month + INTERVAL '1 month' THEN a.user_id
+    END) as month_1,
+    COUNT(DISTINCT CASE
+        WHEN a.activity_month = c.cohort_month + INTERVAL '3 months' THEN a.user_id
+    END) as month_3
+FROM cohorts c
+LEFT JOIN activity a ON c.user_id = a.user_id
+GROUP BY c.cohort_month
+ORDER BY c.cohort_month;
+```
+
+### Funnel Analysis
+
+```sql
+WITH funnel AS (
+    SELECT
+        user_id,
+        MAX(CASE WHEN event = 'page_view' THEN 1 ELSE 0 END) as step_1_view,
+        MAX(CASE WHEN event = 'signup_start' THEN 1 ELSE 0 END) as step_2_start,
+        MAX(CASE WHEN event = 'signup_complete' THEN 1 ELSE 0 END) as step_3_complete,
+        MAX(CASE WHEN event = 'first_purchase' THEN 1 ELSE 0 END) as step_4_purchase
+    FROM events
+    WHERE event_date >= CURRENT_DATE - INTERVAL '30 days'
+    GROUP BY user_id
+)
+SELECT
+    COUNT(*) as total_users,
+    SUM(step_1_view) as viewed,
+    SUM(step_2_start) as started_signup,
+    SUM(step_3_complete) as completed_signup,
+    SUM(step_4_purchase) as purchased,
+    ROUND(100.0 * SUM(step_2_start) / NULLIF(SUM(step_1_view), 0), 1) as view_to_start_pct,
+    ROUND(100.0 * SUM(step_3_complete) / NULLIF(SUM(step_2_start), 0), 1) as start_to_complete_pct,
+    ROUND(100.0 * SUM(step_4_purchase) / NULLIF(SUM(step_3_complete), 0), 1) as complete_to_purchase_pct
+FROM funnel;
+```
+
+### Deduplication
+
+```sql
+-- Keep the most recent record per key
+WITH ranked AS (
+    SELECT
+        *,
+        ROW_NUMBER() OVER (
+            PARTITION BY entity_id
+            ORDER BY updated_at DESC
+        ) as rn
+    FROM source_table
+)
+SELECT * FROM ranked WHERE rn = 1;
+```
+
+## Error Handling and Debugging
+
+When a query fails:
+
+1. **Syntax errors**: Check for dialect-specific syntax (e.g., `ILIKE` not available in BigQuery, `SAFE_DIVIDE` only in BigQuery)
+2. **Column not found**: Verify column names against schema -- check for typos, case sensitivity (PostgreSQL is case-sensitive for quoted identifiers)
+3. **Type mismatches**: Cast explicitly when comparing different types (`CAST(col AS DATE)`, `col::DATE`)
+4. **Division by zero**: Use `NULLIF(denominator, 0)` or dialect-specific safe division
+5. **Ambiguous columns**: Always qualify column names with table alias in JOINs
+6. **Group by errors**: All non-aggregated columns must be in GROUP BY (except in BigQuery which allows grouping by alias)

package/content/data/skills/data-statistical-analysis/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: statistical-analysis
+description: Apply statistical methods including descriptive stats, trend analysis, outlier detection, and hypothesis testing. Use when analyzing distributions, testing for significance, detecting anomalies, computing correlations, or interpreting statistical results.
+user-invocable: false
+---
+
+# Statistical Analysis Skill
+
+Descriptive statistics, trend analysis, outlier detection, hypothesis testing, and guidance on when to be cautious about statistical claims.
+
+## Descriptive Statistics Methodology
+
+### Central Tendency
+
+Choose the right measure of center based on the data:
+
+| Situation | Use | Why |
+|---|---|---|
+| Symmetric distribution, no outliers | Mean | Most efficient estimator |
+| Skewed distribution | Median | Robust to outliers |
+| Categorical or ordinal data | Mode | Only option for non-numeric |
+| Highly skewed with outliers (e.g., revenue per user) | Median + mean | Report both; the gap shows skew |
+
+**Always report mean and median together for business metrics.** If they diverge significantly, the data is skewed and the mean alone is misleading.
+
+### Spread and Variability
+
+- **Standard deviation**: How far values typically fall from the mean. Use with normally distributed data.
+- **Interquartile range (IQR)**: Distance from p25 to p75. Robust to outliers. Use with skewed data.
+- **Coefficient of variation (CV)**: StdDev / Mean. Use to compare variability across metrics with different scales.
+- **Range**: Max minus min. Sensitive to outliers but gives a quick sense of data extent.
+
+### Percentiles for Business Context
+
+Report key percentiles to tell a richer story than mean alone:
+
+```
+p1:   Bottom 1% (floor / minimum typical value)
+p5:   Low end of normal range
+p25:  First quartile
+p50:  Median (typical user)
+p75:  Third quartile
+p90:  Top 10% / power users
+p95:  High end of normal range
+p99:  Top 1% / extreme users
+```
+
+**Example narrative**: "The median session duration is 4.2 minutes, but the top 10% of users spend over 22 minutes per session, pulling the mean up to 7.8 minutes."
+
+### Describing Distributions
+
+Characterize every numeric distribution you analyze:
+
+- **Shape**: Normal, right-skewed, left-skewed, bimodal, uniform, heavy-tailed
+- **Center**: Mean and median (and the gap between them)
+- **Spread**: Standard deviation or IQR
+- **Outliers**: How many and how extreme
+- **Bounds**: Is there a natural floor (zero) or ceiling (100%)?
+
+## Trend Analysis and Forecasting
+
+### Identifying Trends
+
+**Moving averages** to smooth noise:
+```python
+# 7-day moving average (good for daily data with weekly seasonality)
+df['ma_7d'] = df['metric'].rolling(window=7, min_periods=1).mean()
+
+# 28-day moving average (smooths weekly AND monthly patterns)
+df['ma_28d'] = df['metric'].rolling(window=28, min_periods=1).mean()
+```
+
+**Period-over-period comparison**:
+- Week-over-week (WoW): Compare to same day last week
+- Month-over-month (MoM): Compare to same month prior
+- Year-over-year (YoY): Gold standard for seasonal businesses
+- Same-day-last-year: Compare specific calendar day
+
+**Growth rates**:
+```
+Simple growth: (current - previous) / previous
+CAGR: (ending / beginning) ^ (1 / years) - 1
+Log growth: ln(current / previous)  -- better for volatile series
+```
+
+### Seasonality Detection
+
+Check for periodic patterns:
+1. Plot the raw time series -- visual inspection first
+2. Compute day-of-week averages: is there a clear weekly pattern?
+3. Compute month-of-year averages: is there an annual cycle?
+4. When comparing periods, always use YoY or same-period comparisons to avoid conflating trend with seasonality
+
+### Forecasting (Simple Methods)
+
+For business analysts (not data scientists), use straightforward methods:
+
+- **Naive forecast**: Tomorrow = today. Use as a baseline.
+- **Seasonal naive**: Tomorrow = same day last week/year.
+- **Linear trend**: Fit a line to historical data. Only for clearly linear trends.
+- **Moving average forecast**: Use trailing average as the forecast.
+
+**Always communicate uncertainty**. Provide a range, not a point estimate:
+- "We expect 10K-12K signups next month based on the 3-month trend"
+- NOT "We will get exactly 11,234 signups next month"
+
+**When to escalate to a data scientist**: Non-linear trends, multiple seasonalities, external factors (marketing spend, holidays), or when forecast accuracy matters for resource allocation.
+
+## Outlier and Anomaly Detection
+
+### Statistical Methods
+
+**Z-score method** (for normally distributed data):
+```python
+z_scores = (df['value'] - df['value'].mean()) / df['value'].std()
+outliers = df[abs(z_scores) > 3]  # More than 3 standard deviations
+```
+
+**IQR method** (robust to non-normal distributions):
+```python
+Q1 = df['value'].quantile(0.25)
+Q3 = df['value'].quantile(0.75)
+IQR = Q3 - Q1
+lower_bound = Q1 - 1.5 * IQR
+upper_bound = Q3 + 1.5 * IQR
+outliers = df[(df['value'] < lower_bound) | (df['value'] > upper_bound)]
+```
+
+**Percentile method** (simplest):
+```python
+outliers = df[(df['value'] < df['value'].quantile(0.01)) |
+              (df['value'] > df['value'].quantile(0.99))]
+```
+
+### Handling Outliers
+
+Do NOT automatically remove outliers. Instead:
+
+1. **Investigate**: Is this a data error, a genuine extreme value, or a different population?
+2. **Data errors**: Fix or remove (e.g., negative ages, timestamps in year 1970)
+3. **Genuine extremes**: Keep them but consider using robust statistics (median instead of mean)
+4. **Different population**: Segment them out for separate analysis (e.g., enterprise vs. SMB customers)
+
+**Report what you did**: "We excluded 47 records (0.3%) with transaction amounts >$50K, which represent bulk enterprise orders analyzed separately."
+
+### Time Series Anomaly Detection
+
+For detecting unusual values in a time series:
+
+1. Compute expected value (moving average or same-period-last-year)
+2. Compute deviation from expected
+3. Flag deviations beyond a threshold (typically 2-3 standard deviations of the residuals)
+4. Distinguish between point anomalies (single unusual value) and change points (sustained shift)
+
+## Hypothesis Testing Basics
+
+### When to Use
+
+Use hypothesis testing when you need to determine whether an observed difference is likely real or could be due to random chance. Common scenarios:
+
+- A/B test results: Is variant B actually better than A?
+- Before/after comparison: Did the product change actually move the metric?
+- Segment comparison: Do enterprise customers really have higher retention?
+
+### The Framework
+
+1. **Null hypothesis (H0)**: There is no difference (the default assumption)
+2. **Alternative hypothesis (H1)**: There is a difference
+3. **Choose significance level (alpha)**: Typically 0.05 (5% chance of false positive)
+4. **Compute test statistic and p-value**
+5. **Interpret**: If p < alpha, reject H0 (evidence of a real difference)
+
+### Common Tests
+
+| Scenario | Test | When to Use |
+|---|---|---|
+| Compare two group means | t-test (independent) | Normal data, two groups |
+| Compare two group proportions | z-test for proportions | Conversion rates, binary outcomes |
+| Compare paired measurements | Paired t-test | Before/after on same entities |
+| Compare 3+ group means | ANOVA | Multiple segments or variants |
+| Non-normal data, two groups | Mann-Whitney U test | Skewed metrics, ordinal data |
+| Association between categories | Chi-squared test | Two categorical variables |
+
+### Practical Significance vs. Statistical Significance
+
+**Statistical significance** means the difference is unlikely due to chance.
+
+**Practical significance** means the difference is large enough to matter for business decisions.
+
+A difference can be statistically significant but practically meaningless (common with large samples). Always report:
+- **Effect size**: How big is the difference? (e.g., "Variant B improved conversion by 0.3 percentage points")
+- **Confidence interval**: What's the range of plausible true effects?
+- **Business impact**: What does this translate to in revenue, users, or other business terms?
+
+### Sample Size Considerations
+
+- Small samples produce unreliable results, even with significant p-values
+- Rule of thumb for proportions: Need at least 30 events per group for basic reliability
+- For detecting small effects (e.g., 1% conversion rate change), you may need thousands of observations per group
+- If your sample is small, say so: "With only 200 observations per group, we have limited power to detect effects smaller than X%"
+
+## When to Be Cautious About Statistical Claims
+
+### Correlation Is Not Causation
+
+When you find a correlation, explicitly consider:
+- **Reverse causation**: Maybe B causes A, not A causes B
+- **Confounding variables**: Maybe C causes both A and B
+- **Coincidence**: With enough variables, spurious correlations are inevitable
+
+**What you can say**: "Users who use feature X have 30% higher retention"
+**What you cannot say without more evidence**: "Feature X causes 30% higher retention"
+
+### Multiple Comparisons Problem
+
+When you test many hypotheses, some will be "significant" by chance:
+- Testing 20 metrics at p=0.05 means ~1 will be falsely significant
+- If you looked at many segments before finding one that's different, note that
+- Adjust for multiple comparisons with Bonferroni correction (divide alpha by number of tests) or report how many tests were run
+
+### Simpson's Paradox
+
+A trend in aggregated data can reverse when data is segmented:
+- Always check whether the conclusion holds across key segments
+- Example: Overall conversion goes up, but conversion goes down in every segment -- because the mix shifted toward a higher-converting segment
+
+### Survivorship Bias
+
+You can only analyze entities that "survived" to be in your dataset:
+- Analyzing active users ignores those who churned
+- Analyzing successful companies ignores those that failed
+- Always ask: "Who is missing from this dataset, and would their inclusion change the conclusion?"
+
+### Ecological Fallacy
+
+Aggregate trends may not apply to individuals:
+- "Countries with higher X have higher Y" does NOT mean "individuals with higher X have higher Y"
+- Be careful about applying group-level findings to individual cases
+
+### Anchoring on Specific Numbers
+
+Be wary of false precision:
+- "Churn will be 4.73% next quarter" implies more certainty than is warranted
+- Prefer ranges: "We expect churn between 4-6% based on historical patterns"
+- Round appropriately: "About 5%" is often more honest than "4.73%"