What this is

The MUD\WTR Review Explorer is an internal tool for the team to mine 87,460 real customer reviews — the complete all-time Okendo dataset (the current review platform, including the migrated Bazaarvoice era), with legacy reviews preserved from earlier platforms. Every review is the actual verbatim text the customer wrote: nothing summarized, paraphrased, or rewritten. It exists so anyone scripting ads, writing copy, planning campaigns, or doing audience research can hear customers in their own words instead of relying on second-hand summaries.

📥 Download the full dataset

Want to run your own analysis in Excel, Google Sheets, Python, or anywhere else? Grab the complete database as a single CSV: 📥 Download Full Dataset (CSV, ~42 MB) — requires your site login plus a team password (checked server-side; the file is not at any public URL). Ask Aidan if you need it.

87,460 rows × 22 columns: rid, date, name, email, age, location, rating, title, body (verbatim), sentiment, verified-buyer flag, inferred gender, product + product group, source, personas (pipe-separated), topics, sub-themes, pain points, emotion score, body length, Bazaarvoice review link. Contains customer emails — treat it accordingly. Always in sync with the site — rebuilt automatically whenever the team refreshes review data.

The data

• 87,460 reviews dating from April 2019 to September 28, 2026 — and for the first time, most reviews carry the customer's email (90.4%), plus age and post-purchase form answers where the customer provided them
• 74,282 from Bazaarvoice (the current review platform — May 2026 export, includes all recent reviews)
• 10,730 unique Okendo reviews that don't exist in Bazaarvoice (preserved from the prior platform's archive)
• Each review carries: raw body, star rating, sentiment label, reviewer name, date, product, verified-buyer flag (where known), inferred gender (where confident from name), and a source tag (Okendo vs Bazaarvoice)
• Updated when new CSVs are dropped in and the build script is rerun — no manual editing of individual reviews, ever

Why two sources?

MUD\WTR ran Okendo as the review platform from 2019 until switching to Bazaarvoice in 2024–2025. When the team pulled a Bazaarvoice export, Bazaarvoice had migrated most of the Okendo history — but not all of it. About 10,730 reviews from the Okendo era never made it across.

Rather than lose those reviews, this site keeps both. The merge logic:

• Loads all Bazaarvoice reviews first (the spine of the dataset)
• Then walks every Okendo review and adds it ONLY if it doesn't already exist in Bazaarvoice
• "Already exists" is detected by a body-text fingerprint (normalized first 200 characters) — catches the same review across both platforms even when formatting differs (smart quotes, whitespace, emoji)
• 68,187 Okendo reviews were correctly identified as duplicates and skipped (they're already represented by their Bazaarvoice equivalent)

Every review card shows a colored pill (purple for Bazaarvoice, gray for Okendo) so you always know which platform a review came from. Click the pill to filter the whole list by that source.

Metadata enrichment (verified flag + sentiment)

Important: review body text is never changed during merge. But the Bazaarvoice CSV export didn't include two pieces of metadata that Okendo had — the verified-buyer flag and the original sentiment label. So when we found a duplicate (Okendo + Bazaarvoice both have the same review), we filled in those two metadata fields on the Bazaarvoice record using Okendo's values:

• 66,730 reviews (78.5%) are marked verified=true — these are confirmed paid customers
• 7,264 (8.5%) are verified=false — Amazon-side reviewers, influencer seeds, gifts, etc.
• 11,018 (13.0%) are verified=unknown — Bazaarvoice reviews not in Okendo (mostly post-platform-switch reviews). The "Verified buyers only" filter excludes these to be safe.
• 85,004 reviews have a sentiment label (Positive / Negative / Mixed / Neutral) — 68,181 of these came directly from Okendo's professional classification; the remaining ~17,000 were assigned by a rule-based classifier (rating + positive/negative keyword density)

The merge takes the best available data from each platform. Body text always comes from Bazaarvoice (matching the live mudwtr.com site exactly). Metadata is taken from whichever platform had it.

"Wait — the pill says Bazaarvoice but the verified filter passes. What gives?"

Important nuance worth reading once and remembering. Here's the lifecycle of one of those 66,730 verified-buyer reviews:

1. Customer wrote the review sometime in 2019–2024
2. Review lived on Okendo, tagged verified=true automatically (email matched a paid Shopify order)
3. MUD\WTR switched platforms → Okendo's data migrated into Bazaarvoice
4. Bazaarvoice now serves it on mudwtr.com (the live, customer-facing version)
5. The Bazaarvoice CSV export didn't include the verified-buyer flag
6. The Okendo CSV export did include it
7. The build script saw the same review in both files, recognized it as a duplicate by body-text fingerprint
8. It kept the Bazaarvoice version (text, dates, name — matches mudwtr.com exactly)
9. It copied the verified=true flag from Okendo's record onto the Bazaarvoice record

Result on the site: the pill says "Bazaarvoice" (because the current authoritative version of the review is the Bazaarvoice one — matches the live site), and the verified filter passes (because Okendo confirmed this customer paid).

Both are accurate. Nothing was fabricated. We just composed the best data from both records of the same review — text from Bazaarvoice, verified flag and original sentiment from Okendo. Same review either way, stitched together from two records of it.

The 11,018 Bazaarvoice reviews still showing verified=unknown are reviews that have no Okendo match (mostly post-platform-switch — customer never used Okendo). For those we genuinely don't know, and the "Verified buyers only" filter excludes them to be safe. Re-exporting from Bazaarvoice with the verified field selected would fix this last 13% gap.

Two views of the audience: data-driven (this site) vs official (MUD\WTR's marketing library)

This site has two layers of persona thinking, and both matter. Understanding the difference between them is the most important context for anyone using this tool.

The data-driven layer (8 personas, this site)

The 8 personas on the homepage — The Wired-and-Tired Quitter, The Ritual Keeper, The Body-Said-No Switcher, The Brain-Fog Fighter, The Wanted-to-Love-It Defector, The Sleep Reclaimer, The Pot-a-Day Prisoner, The Mushroom Stacker — were re-derived in a 2026 clean-room audit: 12 independent AI readers each studied hundreds of raw reviews and survey answers (with NO access to prior persona work or the official persona doc), 3 judges merged their proposals, and every keyword rule was then adversarially validated against sampled real contexts. Every persona's exact criteria — keywords, guards, confidence — are shown on its card.

These personas weren't decided in a marketing room. No agency built them. No focus group informed them. They emerged from clustering reviewers by the language patterns and pain points they used unprompted. A reviewer who writes about "brain fog" and "couldn't focus" gets tagged as a Foggy Grinder because they explicitly said those things. The classification is reproducible — run the build script and you get the same answers, byte for byte.

This is the unbiased view. It reflects who's already buying MUD\WTR and why they say they bought it. The data has no agenda — it can't lie about what customers are saying because the customers said it themselves.

The official MUD\WTR library (5 personas, in Notion)

The marketing team also maintains an official 2026 Persona Library (in Notion → Marketing → Personas 2026): The Calm Seeker, The Mental Performer, The Maximalist Optimizer, The Gut Guardian, and The Switcher.

Those 5 weren't built from reviews. They were built from market demand data — SPINS 2025 trend reports, McKinsey 2025 Future of Wellness research, Numerator 2025 consumer behavior data. They answer a different question: "Where is the entire wellness market heading, and which large, valuable audience segments should MUD\WTR be acquiring?"

So the official library is the strategic view. It's about who MUD\WTR should be targeting in 2026 based on where demand is moving (calmative beverages +25%, nootropics +19%, prebiotic soda +88%, etc.), not just who's already in the customer base.

Why we have both, and what they're each used for

These are two answers to two different questions, and we need both:

• "Who's actually buying us right now and what are they saying?" → use the data-driven personas (this site). Use for: writing ad copy in real customer language, mining verbatim testimonials, validating positioning, finding objections to handle, picking pain-point hooks that you know land because customers already said them.
• "Who SHOULD we be acquiring next, and which growth trends should we ride?" → use the official library (Notion). Use for: media targeting, channel strategy, campaign briefs, hook generation aimed at growth segments, prioritizing personas for the quarter.

The validation: they overlap almost perfectly

Here's the encouraging part. When we ran the audit (verified by reading the live Notion doc directly), we found that every fully-developed persona in the official library has a matching cluster in the review data. The marketing team's audience theory isn't speculative — it's already reflected in who's buying:

• Foggy Grinder = aka The Mental Performer — both about cognitive output, brain fog, afternoon crashes
• Wellness Stacker = aka The Maximalist Optimizer — both about methodical ingredient research, supplement consolidation, science-backed dosing
• Anxious Overcaffeinator = aka The Calm Seeker — both about jitters, anxiety, nervous system under pressure
• Mood Stabilizer = aka The Calm Seeker (overlaps with Anxious Overcaffeinator) — same underlying audience, two distinct ways reviewers describe it (one calls out "jitters," the other calls out "irritability")
• Coffee Breakup = aka The Switcher — both about loving the coffee ritual but hitting a wall with side effects, often with guilt and sentimentality about quitting
• Gut-Wrecked = aka The Gut Guardian — both about coffee-induced bloating, reflux, gut sensitivity
• Burned-Out Sleeper has no aka — the sleep-deprivation-loop story is real in the reviews but doesn't appear as its own persona in the official library. Kept anyway because the data is real and the cluster is significant (5,085 reviews). Could be folded under The Switcher or The Calm Seeker depending on emphasis, but felt cleaner to keep it standalone.

What the overlap tells us

Marketing isn't targeting hypothetical audiences — they're targeting audiences that are already showing up in reviews. That's a powerful signal. It means:

• The customer base is already aligned with the strategic direction, which de-risks the marketing strategy.
• Creative aimed at official personas should land — because real customers in those clusters are already writing about those exact pain points and benefits.
• Verbatim quotes mined from this site can be used directly in creative for any official persona, because the data-driven clusters map cleanly to the official targeting framework.
• If the marketing team adds a new official persona in the future, we can check this database to see if there's evidence of that audience already buying — before committing to acquire more of them.

A note on the "aka" labels

Every persona card on the homepage and detail page shows an "aka [Official Name]" subtitle in purple where there's a clean mapping. This isn't a rename — it's a translation layer. Our data-driven names (Foggy Grinder, Wellness Stacker, etc.) stay because they reflect the actual language reviewers use. The aka makes it possible to walk into a marketing meeting and say "Foggy Grinder reviews tell us X" while the team hears "Mental Performer customer voice tells us X." Same audience, two vocabularies, zero confusion.

How the 7 personas were derived

The personas come from the original Voice-of-Customer Persona Briefing — but every claim has been re-audited against the raw data. Here's what's actually under the hood:

1. Each persona has a curated keyword list (e.g. The Foggy Grinder includes brain fog, foggy, mental clarity, can't focus, dragging, zombie, focus, energy). The exact lists live in scripts/build-data.py and are documented in the V2 briefing.
2. Word-boundary regex matching — searching for "son" only matches the standalone word, not "person" or "lesson." Same for every term. This is what makes the counts trustworthy.
3. One review can match multiple personas. A reviewer talking about jitters AND brain fog AND quitting coffee will appear in three personas — by design. Total persona counts intentionally exceed the unique review count.
4. Counts are reproducible. Anyone with the project repo can run python3 scripts/build-data.py and produce the same numbers byte-for-byte. No black-box AI scoring, no hidden methodology.

"Why are only some of 87,460 reviews 'persona-matched'?"

This is a common question — and the answer is important. All 87,460 reviews are on this site and fully searchable. The "persona-matched" number reflects how many reviews contain language specific enough to tag with one of the 7 personas. The personas are a classification overlay, not a filter that excludes anything.

Here's the precise breakdown:

• Total reviews loaded: 87,460 — the all-time Okendo export (person-aware deduplicated) plus every legacy review preserved from earlier platform eras
• ~33,360 (39.2%) match at least one persona — these reviewers explicitly told their pain-point story using language like "brain fog," "jitters," "quit coffee," "acid reflux," etc.
• ~33,285 (39.2%) match a topic but no persona — these reviewers talked about Taste, Ritual, Texture, Price, Health, Family, etc., but didn't reference a specific pain point. Useful for browsing by theme.
• ~18,367 (21.6%) are truly generic — no persona, no topic. These are the short happy reviews like "Delicious!" "Love it!" "Tastes great." Real customers, real feedback, just not a story.

The "uncategorized" reviews break down like this:

• ~12,083 are very short (under 50 chars) — quick happy notes ("Delicious", "5 stars", "Love it"). Real reviews, just no story.
• ~27,155 are medium-length generic praise — things like "Tastes great, will buy again, fast shipping." Genuine endorsements that don't reference a pain point.
• ~12,414 are long but persona-neutral — full reviews about taste, packaging, gifting, etc. that just don't use any of our 7-persona vocabulary.

What this means for your work:

• Use the persona pages when you're targeting a specific pain point with creative — those reviews tell stories about WHY someone switched.
• Use keyword search when you want to find anything across all 78,917 reviews — including all the short happy ones for testimonial/social-proof mining.
• Use star-rating filters + keyword search to surface generic 5★ pull-quotes, or 1★ critical reviews regardless of persona.

None of the unmatched reviews are "missing" — they're all here, just not labeled as a specific persona because they don't tell a specific persona's story. The classification is intentionally strict so the persona counts mean something. Everything is searchable; only some things are categorizable.

What you can do here

• 📊 Dashboard charts on the homepage — see rating distribution, sentiment breakdown, and gender split at a glance
• Browse by Persona — click any of the 7 cards to see that persona's reviews, top keywords, pain points, sentiment, sub-filter tabs (Heartfelt, Shortest, 5-Star, Critical, by topic)
• Keyword search with stacking — type a word, press Enter to add it as a removable chip. Stack multiple words for AND search. Works across all 78,917 reviews in milliseconds.
• 🧒 Persona Finder — explore who reviewers are by stacking "language signals" (e.g., kids + daughter + son). Shows each word's reviews, the overlap, and a Persona Profile with sentiment + topics + other words those reviewers use.
• 🎯 Sub-Themes — smaller clusters worth filtering on: Subscription Customers, Migraine sufferers, Husband mentions, Healthcare Workers, ADHD, Workout/Fitness, etc.
• 🔖 Saved drawer — bookmark reviews while you're mining for ad copy. Stored per-browser.
• 🆕 Recent — sort all reviews by newest or oldest date.
• Click any keyword pill, pain point, or topic bar inside a persona to drill deeper.

The verbatim principle

Every quote you see — in a persona detail, in search results, in the briefing PDF — is the actual customer's actual words, exactly as they wrote them. We don't fix typos, edit grammar, or shorten sentences. Style, voice, even ALL-CAPS rants are preserved. This matters because customer language is the asset. If a review reads "I'm SO done with the jitters!!!" you should be able to use that pattern in an ad — not a polished version of it.

Demographics

Gender is inferred from the reviewer's first name using a US Social Security baby-name list. Names that appear on both lists (Jordan, Taylor, Casey) are classified as "unknown" rather than guessed. About 38% of reviewers fall into "unknown." Of the 48,542 names that can be classified, the split is 58.6% female / 41.4% male. Age is not provided in the dataset — age ranges in persona descriptions are qualitative inferences from review language, not statistics.

When updates ship

Whenever the team pushes a new version, the version tag in the top bar updates and you'll see a purple banner offering "Refresh now." Background polling runs every 5 minutes plus an instant check whenever you switch back to the tab — so you'll never spend more than a few minutes on a stale build.

Companion document

For the full strategic narrative — pain points by persona, top emotional triggers, demographic breakdown, ad-ready quote list, and a transparent methodology section — see MUD-WTR-Voice-of-Customer-Persona-Briefing-V2.md (also available as a .docx for Google Docs import).

Institutional memory for engineering decisions, formulas, and "why" behind the things you see. The About modal explains what the site does for users; this one explains how it works under the hood and why specific decisions were made. Read top-to-bottom or jump to a section.

📌 Why the Source UI was removed (v8.6)

The site used to show a "Source" pill on every review revealing "Bazaarvoice" or "Okendo" on hover, plus an "All Sources" dropdown filter and a source chip in the active-filters bar.

Why we removed it: new team members getting onboarded didn't know what Bazaarvoice / Okendo were. The distinction was technical-platform trivia (the review collection vendors MUD\WTR used) and not actionable for the people using this tool to mine customer language for ads, copy, and strategy. Worse, it was confusing — people kept asking "what does Bazaarvoice mean?" and "should I filter by it?" The answer to both is basically "no, it doesn't matter for what you're trying to do."

What's still there: the underlying source field is still stored on every review and still flows through the API. We just stripped the UI surface (pill on cards, dropdown filter, scope chip, and the JS handlers that drove them). If you ever need to filter by source for debugging, the API still accepts a source param.

For background on what the two sources actually are: see the About modal → "Why two sources?" section. Short version: Okendo was the review platform 2019–2024, Bazaarvoice is the current one (2024+). The dataset is a merge of both with body-text fingerprint dedup, preserving 10,730 unique Okendo reviews that didn't make it to Bazaarvoice.

🧮 How Emotion Score is calculated

Every review gets an emotion score used by the "Most Emotional" sort and the small "Emotion: X" label on each card. The formula (in build-data.py):

excl = number of "!" characters in body
caps = number of ALL-CAPS words (2+ letters) in body
length_bonus = min(len(body) / 500, 2.0)
emotion = round(excl * 0.3 + caps * 0.2 + length_bonus, 2)

So a long all-caps review with lots of exclamation points scores very high (10+), and a short polite review scores under 1. The cap on the "Emotional Intensity" bar viz is 12 to give visual headroom; some reviews score 50+ but the bar pegs at 100% above 12.

🧠 Persona detection methodology

Each review is tagged with 0+ personas based on keyword pattern matching against the body text. Rules live in persona_rules at the top of build-data.py. Each persona has 30–50 trigger phrases; if any phrase matches (word-boundary regex, case-insensitive), the persona is added.

This is best-effort tagging, not ground truth. A review mentioning "brain fog" sarcastically would still tag as Foggy Grinder. Strength: it's transparent and tweakable. Weakness: keyword lists can miss novel phrasings. The 7 personas capture roughly 4 in 10 of the 87,460 reviews; the rest are either short generic reviews ("Love it!") or use language outside the rule sets.

Personas are data-driven (mined from this dataset). MUD\WTR's official marketing 2026 Persona Library has 5 personas derived from external trend research (McKinsey, SPINS). The aka labels on persona cards bridge the two vocabularies.

🩹 Pain points + topic detection

Same approach as personas: keyword lists. Pains include "jitters", "crash", "anxiety", "tired", "brain fog", etc. Topics include "Coffee", "Taste", "Ritual", "Energy", "Sleep", etc. Multi-tag per review (a review can hit several pains and several topics).

🛡️ Title integrity audit (v6.6 rollout)

When Bazaarvoice review titles were added to the site in v6.6, a positional cross-reference audit confirmed 100.0000% mapping accuracy across all 74,282 BV reviews. Bodies and titles are read from the same CSV row in the same loop pass — there's no fingerprint lookup or join, so they cannot be mismatched. 99.87% of BV reviews have a title; 0.13% (96 reviews) have an empty title because the reviewer left the title field blank.

Okendo's export has no title field — those 10,730 reviews render without a title line (no placeholder).

🪞 Duplicate review handling

The CSV contains 1,623 rows with body text that exactly matches at least one other row. 462 unique body strings appear 2+ times. Most are short generic phrases like "Love it" (156 reviewers, 5+ years of dates) or "Great" (64 reviewers). 36 are paragraph-length duplicates (200+ chars) and almost all of those are clear bundle purchases — same customer reviewing multiple products with copy-pasted body text but different titles.

The build script does not dedupe by body. Each CSV row becomes its own review record with its own product / title / date. This is correct — they're real separate reviews, not data integrity issues. A full breakdown lives in duplicate-reviews-audit.csv at the workspace root.

📥 CSV download

The footer link 📥 Download Full Dataset (CSV) calls POST /api/download, which gzip-streams data/exports/all-reviews.csv — written by build-data.py on every rebuild from the same data the site reads. Always in sync.

v9.0 hardening: the CSV now contains customer emails, so the v8.16 setup (client-side JS password guarding a public static URL) was retired. The file no longer exists anywhere under /public. The endpoint verifies the site auth token AND the team download password server-side. The password comes from the DOWNLOAD_PASSWORD Vercel env var (with a legacy fallback baked in — set the env var to rotate it without a deploy).

📐 Architecture

• Hosting: Vercel (auto-deploy from GitHub main branch on every push)
• Backend: Vercel serverless functions in /api (search, stats, persona, product, recent, etc.)
• Frontend: Vanilla JS + Chart.js + flatpickr (CDN). No framework — keeps the site fast and dependency-light.
• Data: Pre-built JSON files in /data (reviews.json, personas.json, stats.json, products.json, changelog.json). Built by scripts/build-data.py from the source CSVs.
• Auth: Password gate via /api/auth. Site password lives in Vercel env vars (SITE_PASSWORD).
• Updating reviews: drop new CSVs in the source folder, run python3 scripts/build-data.py, commit the new /data JSON files, push. Vercel redeploys automatically.

📜 Version history

The full version-by-version changelog is in the 📋 Version History button in this footer (or click the version tag in the top bar). Every release back to v3.x is documented with the why, not just the what.