audit_tracking
Audit analytics tracking by comparing logged code events against incoming data to find broken logging, dead code, and unrecorded actions.
Instructions
Check what the code logs, and — if there is data — whether it arrives.
Use this when analyze says there is nothing to work with. A project that tracks nothing has no data to analyse, but it has code to read, so leave csv_path out and this still answers.
How to use it:
Search the codebase for logging calls yourself. Common shapes: logEvent(...), track(...), analytics.capture(...), posthog.capture(...), gtag('event', ...), mixpanel.track(...)
Pass the event names you found as code_events.
Read the result:
in_code_never_fired logging is broken, or nobody uses that feature
in_data_not_in_code dead code, or your search missed it (look again)
Then find what has no logging at all — button handlers and core actions that should be recorded and aren't. That gap won't appear in either list, and it is usually the important one.
Prescribe, don't just report. For each hole write the one line of logging that belongs in that file, in that function, matching the surrounding style, show it, and ask whether to add it. Follow the project's existing naming (follow_artist if it is snake_case, followArtist if camelCase).
Once logging is in, tell them when to come back. come_back_in_days is in the result and is not a guess — it is how long the code must watch a user before it can honestly call them churned or a regular. Saying "run this again tomorrow" would produce a report with nothing in it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| csv_path | No | ||
| code_events | Yes |