Understanding Verified vs. Anonymous Responses

What "verified" actually means

Verification in TIPS is a single boolean column on the response itself — survey_responses.confirmed — that flips to 1 the moment we have affirmative evidence the email on the response belongs to a real person who actually consented to submit it. That evidence comes from one of three places:

1. An email invitation we sent. When a Traveler arrives via a per-invitation link (?inv=<invitationId>.<rawToken>) the response is tied to a specific row in survey_invitations, which is itself tied to a known email. Submitting that response auto-confirms it.
2. An external email invitation you sent. When you send the survey from your own email platform and include ?s=<publicId>&te=<email> in the link, TIPS treats the email as established the same way and auto-confirms the response. See Three Ways to Invoke a Survey for the trade-offs.
3. The Traveler clicked the verification link. Every completed response triggers a confirmation email that contains a unique link (?t=<responseId>.<hmac>). Clicking it flips confirmed to 1 retroactively, even days or weeks later.

What "anonymous" actually means

An anonymous response has no Traveler Profile attached — survey_responses.travelerId IS NULL — and was never confirmed. It happens any time someone scans a QR code or types a direct link, doesn't supply an email through the profile step, and never receives a confirmation email to click. The response is still real data: every answer, every drawn route, every selected option is saved. You just can't tie it back to a person.

That isn't a bug. For a lot of public-engagement work, that's exactly what you want.

When to prefer each

The four levers that decide which one you get

Lever 1 — how you invite people

The invitation method is the single biggest determinant of verification rate, because two of the three invitation methods auto-verify and the third produces anonymous responses by default:

• TIPS email invitation (?inv=…) — auto-verified at click. Every recipient is a row in survey_invitations with a known email. If a survey with 1,000 sent emails sees 250 completions, all 250 are verified.
• External-email invocation (?te=…) — also auto-verified at click. You send the mail from your own platform but pass the recipient's email into the URL, so TIPS knows who it is. Same verification effect as a TIPS-sent invitation, no platform migration required.
• QR code or direct link (?s=…) — anonymous by default. Verification depends entirely on the profile step (lever 2) and the post-submit verification link (lever 4).

Lever 2 — the pre-survey profile step

The pre-survey profile step is the friction-aware way to collect identity on a QR / direct-link survey. Enable it on the survey, and pick which of the four fields you want to collect:

• First name
• Last name
• Email — the field that actually unlocks verification.
• Zip code

Each field is independently optional or required. If you require email, every QR arrival has to provide one, and a Traveler Profile is created (or matched) the moment they submit. They then receive a confirmation email with the verification link — one click and the response flips to verified.

If you require nothing, the profile step is a no-op and the response will stay anonymous unless someone supplies an email mid-survey.

Lever 3 — mid-survey email questions

Even without a profile step, you can add an email field to the survey body. If a Traveler answers it, TIPS will look up or create a Traveler Profile and send the verification email after submit, exactly as it would have for a profile-step email. This is useful when you want to keep the survey low-friction up front but offer optional identification at the end ("Drop your email if you want to be notified of the results").

Lever 4 — the post-submit verification email

Every response with an associated email gets a confirmation email after submit. The link inside is a signed HMAC token tied to the specific response, so it can't be guessed or replayed. Clicks flip confirmed to 1. There's no expiration by default — somebody who completes a survey today and clicks the link a week later still counts as verified from that moment on.

Two practical implications:

• Your verification rate is partly a function of email deliverability. If the confirmation email lands in spam, the click doesn't happen. DKIM and DMARC alignment on the sending domain are not optional — we walk through that in the Three Ways to Invoke a Survey guide.
• Verification is a tail. The bulk of clicks happen in the first 24 hours, but a meaningful share trickles in over days. If you export a CSV the same afternoon the survey closes, you'll under-count verified responses. Wait at least 48 hours, and ideally a week, before reporting final verification rates.

How to maximize verification (without suppressing response)

1. Default to TIPS email invitations when you have a list. If you already have email addresses for your audience, sending through TIPS (or via the ?te= flow) gets you 100% verified at zero respondent friction.
2. For QR / link campaigns, enable the profile step with email required. Yes, it costs you a few percentage points of completion rate compared to no profile step. The trade is usually worth it for the verification it produces — budget roughly 5 to 10 percentage points of completion-rate impact for a single required email field on a well-designed profile step.
3. Make the post-submit confirmation feel useful. The default confirmation email already explains why we're asking them to click the link. If you customize the survey's boilerplate in Branding & Boilerplate, lean into "we want to make sure your input is counted" — not "verify your email." The former is about them; the latter sounds like spam-filter friction.
4. Mix anonymous and verified intentionally. A QR code at a station and an email blast to a stakeholder list can run against the same survey. Your Report page and your CSV both surface the confirmed flag, so you can filter or weight by it at analysis time. You don't have to pick one strategy and stick with it — pick both and tag the data.

Reading verification status in your exports

Both the on-screen Report and the CSV export include a verification column (Verified in the CSV, a green check / dash on the response drill-down at /client/survey-response). Counts on the Report page show separate totals for "responses" and "verified responses" so you can see both numbers side by side.

For grant documentation specifically, what reviewers usually want is a defensible count of distinct verified responses with their geographic distribution. The CSV gives you everything you need: Response ID, date, verified flag, zip code (if you collected it via the profile step), and every answer. Pair it with the GeoJSON export from any Route Creator field for spatial documentation — see Working with GeoJSON Route Data for the full GIS workflow.

Common questions about verification

What does "verified" mean in TIPS?

A verified response is one where TIPS has affirmative evidence the email address on the response is real. That evidence comes from either the survey arriving via a per-Traveler email link (?inv=…), an external email invocation (?s=…&te=…), or the Traveler clicking the verification link in the post-submit confirmation email. Verified responses have survey_responses.confirmed = 1.

What does "anonymous" mean in TIPS?

Anonymous responses have no Traveler identity attached. They happen when someone arrives via QR code or direct link (?s=<uuid>) and you have not configured the pre-survey profile step to collect their information. These responses still count toward your data but cannot be tied back to a person.

When should I prefer anonymous responses?

Anonymous responses are best when you are doing broad public outreach where requiring identification would suppress participation, when you are gathering sensitive feedback (e.g. perceptions of safety), or when statistical totals matter more than per-respondent follow-up. Posted QR codes at transit stops and links shared on social media are classic anonymous-response use cases.

When should I prefer verified responses?

Verified responses are best when you need defensible evidence of public input (federal grant applications, Title VI documentation), when you may need to follow up with respondents, when you want to de-duplicate by person, and when you want to weight or filter analytics by who responded (residents vs. visitors, etc.).

How do I maximize my verification rate?

Send invitations through TIPS's email system (the ?inv= flow) or use the external-email invocation (?te=) when you send from your own platform. Both auto-verify the response since the identity is established at click-time. For QR / link arrivals, enable the pre-survey profile step and follow up — the post-submit confirmation email contains a one-click verification link.

Does enabling the profile step force someone to identify themselves?

Only if you mark a field as required. The profile step has four optional fields (first name, last name, email, zip code), each independently toggleable. You can require email but leave the rest optional — or skip the step entirely. A survey with no profile step and no email-based invitation will produce 100% anonymous responses by design.

Can a response be partially identified?

Yes. If you collect only zip code on the profile step, you have a partially identified response — no email, no name, but you do have a geographic anchor. The response is still flagged anonymous in the database (no Traveler Profile linkage), but the profile data flows through to your reports. This is a useful middle ground for spatial analysis without personal contact.

What happens if a Traveler clicks the verification link days later?

The link works as long as the response still exists. Verification flips survey_responses.confirmed to 1 retroactively, so a response submitted today and verified next week shows up as verified in any export run after that point. There is no expiration on the verification token by default.