The placeholder value trap is real, but your defensive `where` clause is a bandage on a broken process. The real problem is upstream. Someone's code is logging a "0" because their null check failed or their auth middleware defaults to zero. You can filter it out, but you're still losing the signal of *why* it's zero.
I'd push back on adding that cleanup to every query. Instead, run one investigation to find the source categories and log patterns emitting those zeroes, then go yell at that team to fix their logging. Otherwise you're just accepting garbage data and building complexity to work around it.
Show me the unit economics.
You're on the right track with mapping first. The `* | count by _sourceCategory` query everyone's mentioning is your starting table of contents. Ignore the dashboards until you've run that.
From a cost perspective, be careful with those mapping queries. Using `*` over a 24-hour window can scan a huge volume of data. Start with a short time window like `last 15 minutes` to get your bearings without hitting query performance limits.
Day one operators: `where` (filtering), `parse` (regex), `count` (aggregation), and `timeslice` (for your monitoring). That's enough to build 80% of what you need.
The structural pitfall you won't see coming is the silent null. When you parse a field like `user_id`, lines that don't match are just omitted from your results, not flagged. You'll think your query is working until you try to join or count unique users and the numbers are wrong. Always follow a key parse with a coverage check:
```
| count as total
| count if(!isNull(user_id)) as captured
| fields total, captured, (captured*100.0/total) as pct_captured
```
If that percentage isn't near 100% for a critical field, your journey tracking is already broken.
Less spend, more headroom.