I've been using Grammarly's personal editor data export for some time now. As someone who analyzes cloud spend data for patterns, I couldn't resist applying the same analytical lens to my own writing. The goal: quantify my most common errors and see if there's a measurable "cost" to my bad habits, in terms of both corrections and potential efficiency gains.
I wrote a Python script to parse the `writing-review.json` file from their data export package. The most interesting finding wasn't the total error count, but the distribution and context. Here are the key metrics from my last six months of data:
* **Top correction category:** Punctuation (42%), primarily missing commas.
* **Most "expensive" habit:** Wordiness suggestions. While only 15% of total corrections, they required the most active engagement and rethinking, not just a quick click.
* **Consistency score:** My accuracy improved by roughly 18% in technical documents (architecture docs, posts like this) versus informal communication. This suggests a clear context switch penalty.
Here's the core part of the script that aggregates the data by correction type:
```python
import json
from collections import Counter
with open('writing-review.json', 'r') as f:
data = json.load(f)
correction_counter = Counter()
for review in data.get('writingReviews', []):
for correction in review.get('corrections', []):
# Group by high-level category
category = correction.get('category', 'Other')
correction_counter[category] += 1
# Output sorted results
for category, count in correction_counter.most_common():
print(f"{category}: {count}")
```
The data raises operational questions similar to cloud cost optimization. Is there a "reserved instance" equivalent for writing? Investing focused time in grammar drills for my top two error categories (punctuation, conciseness) could reduce the daily "compute" spent on corrections. I'm now tracking my corrections-per-1000-words metric weekly, treating it like a service error rate. Next, I plan to segment the data by time of day to see if fatigue creates a noticeable spike in certain error types.
Right-size or die
That's a fascinating angle, quantifying the "cost." It reminds me of tracking a high churn rate in a subscription funnel, where the issue isn't just the count but the cognitive load of fixing it.
You mentioned parsing the `writing-review.json`. I'm curious about the data schema - did you find the structure consistent enough to build a recurring report? Or was there a lot of manual mapping for the correction categories?
Great analogy with the subscription funnel churn. The user experience "latency" is real.
> curious about the data schema
It's surprisingly consistent, which makes automation possible. The main `reviews` array is well structured. Each entry has clear fields for `text`, `timestamp`, and an array of `feedbacks`. The tricky part, like any third-party API, is the `feedbacks` sub-schema. The `category` and `subcategory` labels (like "punct_commas" or "clarity_conciseness") are stable, but new ones can appear in newer data dumps. I built a simple lookup table to map them to my own readable groups.
For a recurring report, I'd add a sanity check step to flag any unmapped `category` strings. Honestly, it's more consistent than some cloud service IAM policy JSON I've had to parse 😅.
security by default