PHPMem v2.0.1
Version
1.6.45
Uptime
15 days 12 hours 51 minutes 35 seconds
Memory
Total
512MB
Used
9,60MB (1.88%)
Free
502,40MB
Keys
Current
11 842
Total (since start)
35 066
Evictions
0
Reclaimed
731
Expired Unfetched
0
Evicted Unfetched
0
Connections
Current
14 / 1 024 max
Total
173 939
Rejected
0
llm:1eaa052ee3fe5b2185bc74da307d7ee3fbf5aac3ff7b44ec7d67b8b8a8acd0f7
Edit
**Short answer:** the dataset has 1 identifier, 6 categorical dimensions, 11 numeric metrics, and no real event dates. The only timestamp is an ingestion stamp. This comes from the column profile (step 0) and the exact counts (step 2).
**Identifier (1)**
- `user_id` is the key, one row per user. There are 8,500 rows and 8,500 distinct values (USR-00001 to USR-08500). The catalog's "~7,297 distinct" is only an approximation; the exact count is 8,500.
**Categorical dimensions (6)**
- `gender` has 3 distinct values.
- `occupation_type` has 5.
- `chronotype` has 3.
- `primary_bedtime_app` has 6.
- `sleep_debt_category` has 4. It is derived from `total_sleep_hours`, so treat it as an outcome label, not an independent input.
- `blue_light_filter_active` is a 0/1 flag stored as BIGINT with 2 distinct values. It is a binary dimension, not a metric, so don't average it as if it were a quantity.
**Numeric metrics (11)**
- `age` (18–65)
- `bedtime_phone_minutes` (1–180)
- `screen_brightness_pct` (10–100)
- `caffeine_post_5pm_mg` (0–250)
- `physical_activity_min` (0–112)
- `sleep_latency_min` (6.0–123.3)
- `total_sleep_hours` (3.2–9.8)
- `deep_sleep_pct` (8.1–28.0)
- `rem_sleep_pct` (9.6–27.0)
- `morning_alarm_snoozes` (0–7)
- `next_day_fatigue_score` (1.0–10.0)
`age` is better used as a demographic or banding variable than as a quantity to sum. `bedtime_phone_minutes` is flagged as "temporal" in the profile, but it is a duration in minutes, not a date or time, so it belongs with the metrics. The ontology card also marks it as person-identifying, so aggregate it and don't quote individual values.
**Dates/times (1, technical only)**
- `_ingestion_timestamp` (TIMESTAMP) holds a single value (2026-10-01 03:08:19), so it carries no analytical time signal. The dataset has no event-level date, so trend-over-time questions can't be answered from it.
**Pipeline metadata (3, not analytical)**
- `_batch_id`, `_source_file` and `_source_system` each have one constant value. They are lineage fields and can be ignored in analysis.
There are no nulls in any of the 22 columns.