Aggregate-only by default: why your team's answers aren't attributed

Honest answers need safety. Safety, in this case, is engineered.

Every survey has the same failure mode. You ask a question people have strong feelings about, you promise their answers are confidential, and somewhere between the survey form and the leadership deck the names quietly travel too. The respondents are not stupid. They notice. And the next time you ask, the honest answers are gone.

We've watched this play out in employee engagement data for decades. It's the single biggest reason long-form engagement surveys produce platitudes instead of signal. We did not want to rebuild that mistake for AI tool measurement.

So The GAiGE is aggregate-only by default. Admins, owners, and group leaders look at dashboards and reports that show averages, totals, trends and verbatim comment text — but never who said what. This isn't a policy, it's a technical fact: the API doesn't send names, the CSV export has no name column, the UI has no per-person view. The data isn't hidden; it's not there.

What admins actually see

When an admin loads the Reports page, the network request that fetches responses returns payloads like this:

{
  "id": "resp_01HW...",
  "user": { "id": "usr_01HW..." },
  "aiTool": { "id": "tool_01HW...", "name": "Copilot", ... },
  "answers": [ ... ratings, time saved, comment ... ],
  "createdAt": "2025-04-12T09:14:00Z"
}

Notice what's not there: user.name, user.email. The user.id is a React list-key internal to the frontend — it's never displayed anywhere in the UI. An admin clicking around Reports sees this for each comment:

"Copilot's autocomplete keeps suggesting deprecated Python 3 APIs."
— Copilot · 2/5

Not "— Sarah Chen". The comment stays, the tool stays, the rating stays. The human attribution doesn't exist on that page.

Why we didn't just hide the name in the UI

The tempting shortcut is to keep names in the API payload and just not display them in the UI. That's not a privacy guarantee; that's a suggestion. A motivated admin with DevTools can inspect the raw response and read every name that was ever sent to their browser.

So the filtering happens at the API layer. The Prisma query that populates the reports endpoint explicitly selects only user.id — not name, not email. A curl'd request with an admin's own token gets the same namespace-stripped payload the browser does. An admin exporting to CSV gets no name column because the data isn't on the export's source.

This is the difference between hiding information and not having information. Only the second one survives the clever intern with a Postman collection.

The honest limits of the guarantee

Aggregate-only is not pure anonymity. Three caveats worth naming:

1. The database still knows. Every response has a user_id foreign key — that's how your personal dashboard shows your responses, how the system avoids surveying you twice in a day, and how we produce the mini-scoreboard on pulse submission. The user-to-response link is a technical fact at the row level. What changed is that it never leaves the database: no API surfaces it to an admin, no UI renders it, no export includes it.

2. Free-text comments can identify you. If you write "as the only person on the finance team using Jasper…" in the free-text field, the words themselves give you away, even with no name attached. Our guidance to end users: keep the comment about the tool, not about your specific situation. Admins see the text regardless of attribution; distinctiveness is its own signal.

3. Admins can create single-person groups. Group-level reports are scoped by group membership. If an admin puts one person in a group by themselves, the "aggregate" of that group is effectively that individual's data. We allow this because small teams are legitimate (a one-person marketing function is a real thing), but we make it deliberate and visible: members can see which groups they're in on their own profile. It's not a hidden back-door; it's an audit trail.

Each of these is a known honest limit. We'd rather state them than pretend the guarantee is airtight.

What this bought us

Higher response rates, more honest comments, and an end-user communication that we can actually stand behind when a nervous team member asks about it. The member-facing tour now says "your boss sees patterns, never your name" — and the sentence is factually true of the product as shipped, not a marketing aspiration.

The other thing it bought us is cultural. Asking a team to answer a pulse in three seconds is a small request. Doing so in an environment where anyone can look up their contributions is a much larger one. Aggregate-only lets us keep the ask small.

What we'd change if we were starting over

Two honest regrets. First, we'd have built aggregate-only first and made the per-person view the exception, not the other way round. We spent a few weeks with a product where admins could see names, and the retrofit cost us a careful audit of every endpoint that returned response data.

Second, we'd have written this post earlier. Trust postures are easier to defend when they're documented before the first hard question arrives, not after.

In short

The GAiGE does not let your admins see individual answers. Not because of a policy, but because the product is built so the names don't reach the browser. The guarantee has honest limits (which we've named), and the posture is non-negotiable — it's the reason the answers are honest in the first place.

Member-facing explanation in plain English: Your 2 cents drives real change. The methodology behind the numbers we do show: The 2.5× rule.