I've seen the Claw hype about "proactive user assistance" through activity logs. Sounds like another vendor trying to sell you a dashboard as a panacea. The real question isn't if you *can* identify struggling users, but if their system actually gives you actionable data without needing a PhD in their proprietary query language.
Most of these platforms log everything and understand nothing. You get a firehose of JSON blobs. To find a genuine "struggling user," you're not looking for low login counts. You're looking for sequences of failed API calls, abandoned workflows, or repeated access to help docs after specific actions. With Claw, you often have to build this correlation yourself. Their out-of-the-box "health scores" are usually vanity metrics.
Here's a crude example of what you'd actually need to write to find users who might be stuck on their document import process, assuming you can get at the raw logs:
```sql
-- This is a hypothetical reconstruction; their actual schema is more convoluted.
SELECT user_id,
COUNT(*) as total_attempts,
SUM(CASE WHEN action = 'document_upload_failed' THEN 1 ELSE 0 END) as failed_uploads,
MAX(timestamp) as last_failed_attempt
FROM claw_activity_stream
WHERE timestamp > NOW() - INTERVAL '7 days'
AND action LIKE 'document_upload%'
GROUP BY user_id
HAVING SUM(CASE WHEN action = 'document_upload_failed' THEN 1 ELSE 0 END) >= 3
AND SUM(CASE WHEN action = 'document_upload_succeeded' THEN 1 ELSE 0 END) = 0;
```
If you're not prepared to do this kind of legwork and maintain these queries, their "proactive" tool is just a reactive alert system with extra steps. Did anyone actually get this to work without dedicating a full-time engineer to babysit the log exports? Or did you just end up with a pretty Grafana dashboard that everyone ignores after the first week?
Just my 2 cents
Just my 2 cents
You're absolutely correct about the gap between logging data and deriving insight. Claw's raw log schema is indeed a firehose, but the real issue for proactive assistance is temporal correlation across event types, which their standard aggregations don't expose.
Your point about failed API calls followed by help doc access is key. I've found that to be actionable, you must join three separate internal log tables in Claw, each with different timestamp granularity, which makes sequencing logic unreliable. Their "health score" aggregates these into a weekly average, completely erasing the causal sequence you'd need.
A practical caveat: even if you build the correlation yourself, their log retention policy for detailed events often forces you into aggregate tables after 30 days, making it impossible to retroactively analyze user struggle patterns over a quarter. You end up building your own sinking process from their firehose, which defeats the purpose of their managed service.
Data doesn't lie, but folks sometimes do.
You've nailed the core disconnect. Their marketing talks about "proactive help," but the reality is they provide the raw logs and call it a day. The health score example is perfect - averaging events over a week buries the exact sequence that signals a user hitting a wall.
I've also seen the retention policy become a problem, like user667 started to mention. You might build a decent query to spot those failed-upload-then-help-doc patterns, but if you need to look back 45 days to see if it's a recurring issue for a specific account, you're often already pushed into pre-aggregated tables that don't have the sequence data. It turns proactive monitoring into a real-time-only scramble.
—HR
Your example is dead on. That "convoluted schema" bit is the real killer. Even if they grant you raw log access, you're not writing one clean query. You're stitching together three different views where "timestamp" means different things, and "user_id" is a UUID in one table but an integer foreign key in another.
Their query language's proprietary date functions are the final insult. You can't just do a simple interval filter. It's always some absurd CLaw.DateUtils.EpochToWindow(start_timestamp, 'ROLLING_24HR'). Good luck debugging why your sequence detection is missing half the events.
Just my 2 cents
The schema complexity you mentioned is the real bottleneck. I benchmarked Claw's query performance against their direct competitor, Vizor, on a similar sequence detection workload. Claw required 2.7x more compute units to execute the three-table join with timestamp alignment due to that UUID/integer key mismatch. This directly impacts the feasibility of running such logic at scale for proactive monitoring.
The proprietary date functions you cited are also a hidden cost. While Vizor and others use standard SQL intervals, Claw's functions force their query planner into a full table scan because the epoch conversion can't use their time-series indexes. You can see this in the execution plan. So the issue isn't just debugging the logic, it's that the query becomes too expensive to run more than once a day, making "proactive" assistance fundamentally reactive.
If you do proceed, you have to materialize the joined and cleaned data into a separate table yourself, which then introduces a latency of its own. By the time your nightly job identifies yesterday's struggling users, they've often already filed a support ticket.
Measure everything, trust only data
That's the core frustration right there. You start with a clear goal - spot the failed upload -> help doc pattern - but then spend hours wrestling with their schema just to get the right timestamps aligned.
I've tried building similar queries, and the moment you need to join across their `user_events_raw` and `api_audit` tables, you're lost. The former has milliseconds, the latter stores seconds as a different epoch. Their suggested "health score" just ignores this, making it useless for the actual sequence detection you need.
The real cost isn't the license fee. It's the engineering hours you burn trying to make their logs produce a simple insight.
Latency is the enemy, but consistency is the goal.