In-Email Review Capture. The 2026 Conversion Frontier

The click-out tax

Before you build anything, measure where your current request loses people. Most ESPs and review tools can give you the first three stages; your form or reviews platform gives you the last two. Instrument the funnel for a month and look for the biggest single drop.

If the biggest drop is between open and first action, the email itself is the problem and AMP may help. If it is between form start and submit, the form is too long, and an in-email version of the same long form will not fix it. For the message itself, how to ask customers for reviews covers timing and copy.

AMP for Email, demystified

AMP for Email is an extra MIME part, text/x-amp-html, sent alongside the usual HTML and text parts. A supporting inbox renders the AMP part, which can contain a restricted set of interactive components such as forms, carousels and live lists. Every other inbox ignores it and shows the HTML. The AMP project maintains the list of supporting clients and sending platforms.

Gmail requires registration. Google only renders dynamic email from senders it has registered. The registration guidelines require SPF, DKIM and DMARC authentication, a consistently low spam complaint rate, and an HTML or text MIME part that is similar to the AMP content. Registration works per sender email address, so a review request from reviews@ and a newsletter from news@ are separate registrations. The process starts by sending a real, production-ready email with the AMP part from your production servers to ampforemail.whitelisting@gmail.com.

Your endpoint has to speak AMP's CORS. An AMP form posts to an HTTPS endpoint you control, but the request comes through the email client's proxy. Per the AMP documentation, your server must check the sender header on the request, confirm the sender is one you trust, and return the matching allow header (AMP-Email-Allow-Sender, or the older Access-Control and AMP-Access-Control-Allow-Source-Origin pair). Get that wrong and the form renders but every submission fails.

<!doctype html>
<html ⚡4email data-css-strict>
<head>
  <meta charset="utf-8">
  <script async src="https://cdn.ampproject.org/v0.js"></script>
  <script async custom-element="amp-form"
          src="https://cdn.ampproject.org/v0/amp-form-0.1.js"></script>
  <style amp4email-boilerplate>body{visibility:hidden}</style>
</head>
<body>
  <form method="post" action-xhr="https://reviews.example.com/amp/submit">
    <input type="hidden" name="order_token" value="ORDER-TOKEN">
    <!-- star radios, a short text field, and an unticked consent box -->
    <input type="submit" value="Send review">
    <div submit-success><template type="amp-mustache">Thanks, it's in.</template></div>
    <div submit-error><template type="amp-mustache">That didn't send. Use the link below.</template></div>
  </form>
</body>
</html>

That second step matters for the content itself: photo and video reviews versus text reviews covers what visual reviews add on the product page.

The fallback ladder

You do not detect the inbox. You send a multipart email and the client renders the richest part it supports. That makes the fallback design simple: each rung must work on its own.

The hosted form is the floor. Whichever rung the customer starts on, they may end on the hosted form, so it should load quickly on mobile, remember the rating they tapped, and ask for no more than you will use. Keep one reminder. A single follow-up to non-responders is reasonable; a sequence of them is how review requests end up in spam. SMS or WhatsApp reminders are an option only where you already have consent to message on that channel; see SMS and WhatsApp social proof.

Consent inside the email

An in-email form collects personal data and, often, permission to reuse the customer's words or photo on your site. Treat those as separate questions. Submitting a review does not by itself mean the customer agreed to be featured in a gallery or an ad, and it certainly does not mean they agreed to marketing email.

• Unticked by default. The UK ICO's guidance on valid consent is plain: "Silence, pre-ticked boxes or inactivity should not therefore constitute consent."
• Granular. The ICO expects separate options for separate purposes where that is practical, so "feature my review on your site" and "send me marketing" are two boxes, not one.
• Recorded. Store who consented, when, through which form, and the exact wording shown, alongside the review. The ICO lists missing records as a sign consent is not valid.
• Easy to withdraw. A clear route to remove a review or withdraw permission to feature it, which your moderation workflow can action.

The same principles apply to hosted forms, so build one consent model and use it on every rung. The wider rights workflow, including scope and expiry for featured content, is covered in GDPR consent and UGC. This is general guidance, not legal advice; Canadian (CASL) and other regimes have their own rules, so check with counsel for the markets you mail.

A build recipe, and what Idukki handles today

What Idukki does today. On Shopify, Idukki sends a standard HTML review-request email, triggered by the order or by its fulfilment status (in transit, out for delivery or delivered) with a delay in days. The email offers tappable stars and a button that open a hosted form accepting photos and video, and merchants choose from built-in presets for the copy, button text, accent colour and an optional incentive line. Requests are off by default and need both the merchant's opt-in and Idukki's approval before any shopper is emailed. Idukki does not currently send an AMP version of this email. Submissions land in the reviews inbox for moderation; see the reviews page.

If you want to add an AMP rung yourself, the work sits with your ESP and your own endpoint. The steps below are the minimum.

1. 1Confirm your ESP can send it. Check that your plan and template editor support adding the AMP MIME part, not only that the platform appears on amp.dev's list.
2. 2Authenticate the sending domain. SPF, DKIM and DMARC in place for the exact sender address you will register.
3. 3Build the endpoint. An HTTPS endpoint that accepts the form post, validates a signed per-order token so only the buyer can submit, implements AMP email CORS headers, and writes the review and consent record to your reviews system.
4. 4Build the HTML part in parallel. One-tap stars into the hosted form, so non-AMP inboxes get a complete experience.
5. 5Validate and register. Validate the AMP markup, then send a production email to Google's registration address and wait for approval before you rely on it in Gmail.
6. 6Roll out behind a holdout. Start with a randomised share of the list and measure as described below.

If you use a separate reviews platform as your system of record, confirm how its API accepts submissions before you design the endpoint; the endpoint is only as useful as where it can write. For using collected reviews and UGC back inside email, see UGC in email and Klaviyo flows.

Measuring lift

The common mistake is to compare submission rates for customers who saw the AMP version with those who saw HTML. That comparison is biased before it starts: AMP rendering depends on the inbox provider, and Gmail and Yahoo users are not a random slice of your list. Any difference mixes the effect of the form with the effect of who uses which inbox.

Report submissions per email sent, not per open, because open tracking is unreliable. Track photo and video submissions separately, since an in-email form that raises text reviews but lowers photo reviews may be a net loss for your PDPs. The testing mechanics are in how to A/B test UGC and social proof.