Collect Testimonials After Purchase: Email vs In-App Prompts

How to collect testimonials after purchase: when in-app beats email, when hybrid wins, and how to test using approved submissions—not opens or clicks.

Sev LeoLinkedInTwitter

Founder and sole developer of ShowTrust.to and Skribra.com

What “better” means

If your goal is to collect testimonials after purchase, “better” isn’t a vanity metric like opens or clicks. It’s the channel that produces more usable testimonials with less risk and less ongoing work.

An in-app prompt—a message or modal shown inside your product while a user is actively using it—can only be “better” if your customers actually return and see it; Intercom’s guidance is explicit that inactive customers won’t receive in-app messages at all. On the measurement side, keep “response rate” and “completion rate” separate: response rate is the share who start/respond, while completion rate is the share who finish the flow, and those can diverge when the ask takes multiple steps.

Fake testimonials cross a bright legal line. The Federal Trade Commission’s Consumer Reviews and Testimonials Rule (16 C.F.R. Part 465) took effect October 21, 2024, and the FTC states that if testimonials on your own website are fake or false, you could be liable for disseminating them.

Win criteria

• Reach: How many post-purchase customers can you actually put the ask in front of?
• Participation: Response rate and completion rate, measured on finished submissions.
• Quality/length: Specific, on-topic details you can publish without heavy editing.
• Consent/compliance risk: Truthful claims, real purchasers/users, and clear permission to use it in marketing.
• Operational cost: Build/maintenance effort, targeting, follow-ups, and moderation time.

Reach and timing

Email and in-app prompts don’t just perform differently—they can literally miss different customers.

Retently reports that more than 95% of surveys in its 2025 ecommerce dataset were delivered through email, largely because you can send post-purchase even if the customer never returns to the product. But inbox reach is conditional: Gmail says once you send about 5,000+ messages/day to personal Gmail accounts, you must meet added sender requirements and keep spam rates (in Postmaster Tools) below 0.30%, and hitting that threshold even once makes you a bulk sender permanently. Also, Apple Mail Privacy Protection can download tracking pixels in the background regardless of whether someone read your email—so “saw it” timing is fuzzy.

Benchmark reality check

Benchmarks are only useful if you know what the “rate” is divided by. The same prompt can look “dead” or “amazing” depending on whether you count invitations sent, screens shown, or unique people eligible.

Retently benchmarks

Retently’s 2025 dataset spans 600 ecommerce brands and over 25 million survey invitations (January–December 2025), covering email invites, in-app prompts during active usage, and direct-access links.

That last number is the tell: once someone chooses to click a link and land on the form, “response rate” is no longer measuring persuasion—it’s mostly measuring who opted in.

Denominator traps

Now compare those to SurveyMonkey’s 2025 platform benchmarks: Email at 49.17% versus Mobile SDK / in-app at 34.37%, with “response rate” defined as participation (not opens or clicks). Those figures aren’t “wrong”—they’re just counting a different denominator than an ecommerce post-purchase send.

The trap shows up fastest in-product, because “seen it” is ambiguous. Refiner’s 2025 in-app benchmarks report 27.52% response and 24.84% completion, based on 1,382 surveys and ~50 million views. A “view” here is an exposure event (the prompt rendered), not a unique person—and repeat exposures can swing the rate.

That’s why practitioners argue about “responses / total views” versus “responses / total visitors” as the denominator for an in-app NPS response rate. If your prompt can be shown multiple times to the same person, a views-based rate can move a lot without any change in how many customers actually participated.

Pick your denominator first, then compare channels. Otherwise you’ll “optimize” a metric that changed definitions halfway through your funnel.

Email constraints

Email feels like the obvious way to collect testimonials after purchase—until volume turns it into a deliverability and measurement problem.

• Gmail sets a “bulk sender” floor. A bulk sender (Gmail) is a sender that hits ~5,000+ messages to personal Gmail accounts in a 24-hour period (counted at the primary-domain level). Once you’re in that lane, Gmail expects you to behave like a high-volume program, not a one-off request.
• Authentication stops being optional. Gmail’s 2024 requirements for bulk senders include SPF and DKIM (two standards that prove your domain is allowed to send and that the message wasn’t altered) and DMARC alignment—meaning the visible From: domain matches the domain authenticated by SPF and/or DKIM.
• Complaints become a hard ceiling. Your spam complaint rate—the percentage of delivered emails recipients mark as spam—is a core reputation signal, and Gmail explicitly ties bulk-sender standing to keeping spam rates low.
• Unsub has to be frictionless. One-click unsubscribe is part of the floor, which changes how aggressively you can follow up without training inbox providers that your mail is unwanted.
• Performance is noisy to measure at scale. M3AAWG documents nonhuman interactions (security scans that record opens/clicks that no person made); for B2B, it reports unpublished data showing overall impact between 20–80%. If you judge “working” by opens or clicks, you’ll overestimate reach and undercount the real bottleneck: completed submissions—and you’ll wonder why video testimonial requests get ignored even when the campaign “looks” healthy.

In-app execution

An in-app testimonial ask is only visible during real product usage. So don’t trigger it off the purchase timestamp by default—trigger it off product events that prove the customer actually got value (first successful outcome, repeated use of the core feature, or a milestone that shows they’re past setup).

Build the prompt as a short, two-step flow: (1) a lightweight ask that’s easy to dismiss, then (2) the full form only after they opt in. That structure also makes it easier to separate response rate (who opts in) from completion rate (who finishes the longer form).

Overprompting is where in-app programs stall: you keep increasing exposures while training users to close the modal on sight. Add a frequency cap (a hard limit on how often a user can see the ask) plus a cooldown (a minimum time before you’re allowed to show it again). Also add permanent suppression rules: if they submitted, said “not now,” or closed it twice, stop showing it for a long window. Don’t show it in high-stress moments (errors, billing failures) or on every login.

Instrument the funnel like a product feature: eligible users → prompt seen → started → submitted → approved/publishable. If you run an “in-app + email” fallback, keep the in-app window explicit—Pendo’s setup uses a 14-day timeframe, then emails visitors who didn’t see the in-app survey—and segment carefully so you don’t end up emailing churned customers. If your targeting is sloppy, your follow-up becomes a complaint generator.

Testimonial examples

• Short quote (fast): “I shipped ___ in a day instead of a week.” Attribution: Name, role, company, website. Permission: “I agree you may publish this quote and my attribution in marketing.”
• Detailed story (high quality): “Before: ___. After: ___. Specific result: ___. What I’d tell a friend: ___.” Attribution: Name, role, company, industry. Permission: “You can edit for length without changing meaning.”
• Rating + comment (structured): “Rating (1–5): __. One sentence why: __. What feature mattered: __.” Attribution: Name, company size, use case. Permission: “You may display my rating and comment publicly.”

Testimonial examples

Decision and test

Default decision: make the in-app prompt your primary channel for customers who return, and use email as the backstop for customers who never come back into the product. That setup matches the real constraint: in-app can win on participation when it’s shown in-context, but it can’t reach non-returners at all.

Decision matrix

Test design that isolates channel impact

Judge channels on outcomes you can publish, not inbox metrics. Apple Mail Privacy Protection (MPP)—Apple Mail’s privacy feature that can preload remote content—can log an “open” even if the person didn’t read the email. Nonhuman interactions (NHI)—automated opens/clicks from security scanning systems rather than a person—add more distortion; M3AAWG documents NHI during security scans and reports overall impact under 10% in B2C datasets, while B2B can see 20–80% overall impact.

Run an A/B testing rollout (or a sequential rollout) with one rule: every variant must point to the same testimonial form and the same approval policy.

1. Define eligibility once. Same post-purchase cohort, same suppression rules (submitted / “not now” / already approved).
2. Randomize by user/account. Assign to In-app primary vs Email primary (add Hybrid as a third arm only if you can keep targeting clean).
3. Log server-side funnel events. Eligible → seen (in-app) / delivered (email) → submitted → approved.
4. Pick the winner on two numbers. Primary: approved testimonials per eligible. Diagnostic: approval rate (approved ÷ submitted) to spot a “more volume, worse quality” trade.

If the hybrid arm wins, it’s usually because your product has a real non-returner slice—so the email backstop is doing actual reach work, not just adding noise.

Pick a primary, prove it

If you can put the ask in front of customers while they’re actively getting value, make the in-app prompt your primary channel—and treat email as the backstop for the customers who won’t return to see anything in-product. Don’t let the decision ride on opens or clicks: define one eligibility cohort, send both variants to the same form with the same approval rules, and choose the winner on approved testimonials per eligible. Trigger in-app off real usage moments with caps and suppression so you don’t train people to dismiss it, and keep the email follow-up tightly segmented so it doesn’t turn into a complaint problem. Once you’re judging the funnel from eligible → submitted → approved, the “email vs in-app” argument stops being theoretical and becomes a defensible operational choice.