Okendo Reviews: Timing, Schema and Negative Reviews

What running an Okendo review programme actually requires

Okendo reviews are only as good as the setup behind them. Installing a review app is the easy part. The programme fails or succeeds on three decisions the setup wizard does not force you to make: when the request fires, whether the schema actually validates, and what happens the day a one-star review lands on your best-selling product. None of those three show up in a vendor’s feature list, because all of them depend on your fulfilment data, your theme code and your own tolerance for public criticism, not on the app.

This article is for teams already running, or seriously evaluating, a review platform on Shopify at $3M-$30M in revenue, on Shopify Plus or an equivalent paid subscription platform. If you’re below that floor, the fix that matters more than any review app is getting order volume up first: a review widget with forty reviews on it does not move conversion the way one with four hundred does.

Request timing: delivery date, not order date

The default in most review apps, Okendo included, is to trigger the request a fixed number of days after the order is placed. That’s the wrong clock. A customer who ordered on day one and received the package on day nine has had five fewer days with the product than the timer assumes, if the request goes out on day fourteen from order date. Worse, an order still in transit on the request date gets asked to rate something it hasn’t opened yet, and those requests either get ignored or, worse, get a review based on the unboxing rather than the product.

The fix is to trigger off the fulfilment or delivery-confirmation event, not the order-created event. Okendo, like most review platforms, supports fulfilment-based triggers through its Shopify integration; the setting sits in the review request flow configuration, not the order settings. If your carrier tracking data reaches Shopify reliably (tracking numbers marked delivered, not just shipped), you can trigger off actual delivery. If it doesn’t, fall back to a fulfilment-date trigger plus a delay long enough to cover typical transit time for your shipping zones: a coast-to-coast order needs a longer buffer than a regional one, and a single flat delay across all zones under-serves whichever end of the country is furthest from your warehouse.

Layer a second decision on top: how long after delivery to wait before asking. That number is product-specific, not something to copy from a case study. A consumable that gets used within days can be asked about within a week. A supplement or skincare product where the value shows up over weeks needs a longer wait; ask too early and you collect “product arrived intact” reviews instead of reviews about whether it worked. Set the delay to the point in the use cycle where a customer actually has an opinion, and if you don’t know that point, that’s the number to test rather than guess.

Review schema: what makes stars show up in search

A published review is not the same thing as a review that shows up as a star rating in a Google search result. The stars in the search snippet come from structured data, Review and AggregateRating schema markup on the product page, and Google decides independently whether to render it, based on schema validity, review volume and its own quality signals. A page can have real reviews, a correctly configured app, and still show no stars in search if the schema is broken, thin, or Google simply declines to use it that month.

Two things break this most often. First, the review schema and the product schema need to validate independently but reference the same product entity: if the base product schema has an error (a missing price, an invalid currency code), Google can suppress the review markup that sits alongside it even though the review data itself is fine. Second, theme customisation is a common point of failure: a merchant edits the product template, and the schema injection the review app relies on gets duplicated, removed, or placed outside the markup the template renders. Test the live product page in Google’s Rich Results testing tool after any theme change, not just after the review app install, since the schema can pass at setup and silently break three months later when someone edits the buy-box.

A validated schema still doesn’t guarantee a visible star snippet. Google has published no fixed review-count threshold for eligibility, and none should be assumed; what to check is whether your highest-review products are the ones showing stars, and whether newly reviewed products start showing them as volume builds.

Handling negative reviews without hiding them

The instinct on a one-star review is to make it go away: hide it from the feed, decline to publish it, or reach out and offer a refund contingent on the customer changing the rating. All three of those are worth naming as mistakes rather than options.

Deleting or suppressing a genuine negative review, one that reflects an actual buyer experience rather than spam or abuse, undermines the credibility of every review left standing. Shoppers who read only five-star reviews on a product with meaningful order volume tend to discount the whole review set as curated, which costs you more trust than the negative review itself would have. The better move is a public reply: acknowledge the specific complaint, state what was done or will be done, and leave both the review and the reply visible. That reply is doing work for every future reader, not just the one customer.

Conditioning a refund or discount on a rating change is a different problem: it’s asking a customer to alter public feedback in exchange for compensation, which most review platforms’ terms of service and general advertising-practice guidance both treat as manipulation of the review record. Handle the service issue on its own terms (refund, replace, apologise) without attaching a review-editing condition to it. If the resolution genuinely changes the customer’s view, some will update the review unprompted; that’s a different thing from being asked to.

The compliance line on incentivised reviews

Offering an incentive (a discount code, a loyalty-points bonus, an entry into a giveaway) in exchange for leaving a review is common practice and generally permitted. The line sits in two places, and it’s worth being specific about the difference. First, disclosure: if the reviewer received something of value for reviewing, most current guidance expects that to be disclosed, either on the review itself or in how the request was framed. Second, and stricter, is conditioning the incentive on the review’s content or star rating: asking for a positive review, or only rewarding reviews above a certain rating, or excluding critical reviews from the incentive. That’s the practice regulators have specifically targeted in recent enforcement, and it applies regardless of which review platform sits underneath the request.

The practical version: word the request as “leave a review” or “share your experience,” never “leave us five stars,” and apply the incentive the same way whether the review is glowing or critical. This is general guidance, not legal advice; the specifics of what disclosure language is required, and where, change and vary by market, so confirm the current requirement with counsel before finalising the request copy and the incentive terms, particularly if requests go to a US and a UK or EU audience from the same flow.

How okendo reviews compare to other Shopify review apps

Merchants weighing a review programme usually aren’t choosing between two Okendo configurations; they’re choosing between a dedicated review-and-UGC platform, Shopify’s native product review app, and a lighter single-purpose review app. Each is built for a different point in the growth curve.

The table’s read: pick the dedicated platform when reviews are one piece of a wider retention stack (loyalty, referral, UGC on ad creative) you intend to run under one vendor. Pick the lighter option when the requirement is genuinely “get reviews on the product page,” full stop, and the rest of retention lives elsewhere.

Migration effort: what moving review data actually costs

No vendor page publishes what it costs to move a review history in or out of their platform, because the honest answer discourages both directions of the trade. Here’s what the move involves in practice.

Exporting out. Most platforms will export existing reviews as a CSV: reviewer name, rating, text, date, sometimes a verified-purchase flag. Photos and video almost never travel cleanly in that export; expect to either lose them or handle a separate media-migration step. The schema markup that made stars appear in search does not migrate at all; it’s generated fresh by whatever platform is now installed, and until it’s live and validated again, the product page has no review schema running.

Importing in. The receiving platform needs the export mapped to its own field structure, and verified-purchase status usually can’t be reconstructed unless the new platform can cross-reference the original order data, which most can’t, for reviews collected under a previous vendor. The practical outcome: older reviews often import as unverified text-only entries, even when they were originally collected from real buyers.

The gap that costs the most time. Between disconnecting the old app and validating the new schema, the product pages run with no review markup, a window during which any review-rich search snippets you’d built up can disappear from results, and take time to reappear even after the new setup is live and correct. Plan the cutover for a low-traffic week, and validate schema on a sample of top-selling products before the old app is removed, not after.

Photo and video reviews: collection, moderation, and where they change conversion

Star ratings and text are the baseline; photo and video UGC is what most review platforms, Okendo included, sell as the upgrade. The collection mechanics differ from a text review: a photo or video ask usually runs as a separate step in the request flow, either an upload field on the same form or a follow-up prompt once a written review is submitted, because asking for both at once depresses the response rate on both. Expect photo/video attach rates on a review form to run well below the text-review completion rate itself; most shoppers who bother to write a review still won’t stop to attach a file, so a programme that wants meaningful photo coverage needs either a dedicated incentive for the media upload or a second, separate ask after the text review lands.

Moderation load rises with photo and video in a way text reviews don’t create. A text review needs a read for profanity, spam and obvious abuse. A photo or video needs the same check plus a visual one: wrong product in frame, a competitor’s packaging visible, an image that’s actually a screenshot of a complaint rather than the product itself, or content that’s simply unusable (blurry, dark, not showing the product at all). None of that is optional if the media is going to display on the product page or feed into ad creative; an unmoderated photo queue is how a brand ends up with a five-star review sitting next to a photo of the wrong item.

Where it actually moves conversion is narrower than the marketing claims. Photo and video UGC does the most work on products where the buyer can’t otherwise judge fit, scale, texture or true colour from a studio shot: apparel, furniture, cosmetics on different skin tones, anything where the customer’s real concern is “will this look like the product photo in my house / on my body.” On a commodity product with low visual ambiguity, added photo UGC on the product page moves the needle far less than the same effort spent on getting delivery-triggered timing right. Prioritise photo/video collection on the SKUs where visual uncertainty is actually the objection, not across the whole catalogue evenly.

Review syndication to Google Shopping

A review platform that syndicates to Google Shopping (pushing product ratings into the seller ratings or product ratings feed Google reads for Shopping ads and free listings) needs a data feed that meets Google’s own structural requirements, separate from the on-site schema question. The feed generally needs to carry, per product: a stable product identifier that matches the Merchant Center catalogue (GTIN, MPN or a consistent SKU), the aggregate rating and review count, and individual review content where the platform supports full review syndication rather than just an aggregate score. If the identifier in the review feed doesn’t match the identifier in the Shopping feed exactly, Google can’t associate the rating with the listing, and the syndication silently does nothing even though the platform reports it as connected.

Re-platforming a catalogue’s SKUs breaks this quietly, because the review data is tied to the old identifier and the new one arrives with no rating history attached until the feeds are reconciled. Anyone syndicating reviews to Shopping should check the feed against Merchant Center’s diagnostics after any SKU renumbering, not assume the review platform’s “connected” status means the ratings are actually reaching the ads.

Attribute ratings and returns on apparel

Beyond the single star average, most dedicated review platforms support attribute-level ratings: fit (runs small / true to size / runs large), quality, and sometimes a size-purchased field tied to the reviewer’s profile. On apparel specifically, this data does something a plain star rating can’t: it lets a shopper on the fence about sizing see that a garment “runs small” before they buy, rather than finding out from the return. That’s the mechanism, not a guessed number; a fit-rating breakdown displayed near the size selector gives the shopper the information a return would otherwise have supplied, at the point where they can still act on it.

Getting attribute data worth displaying requires asking for it specifically in the review form, a fit question with fixed options rather than a free-text field a shopper has to think to fill in, and it only becomes useful once enough responses accumulate per size to show a real pattern rather than one outlier review. A product with a handful of reviews showing an attribute breakdown reads as noise; the same breakdown on a product with a few hundred reviews reads as signal. Decide the display threshold per product rather than turning attribute display on catalogue-wide the day the feature ships.

Writing the moderation policy before the first bad review arrives

Every review platform ships a default moderation setting, usually auto-publish unless a review is flagged for profanity or spam, but “default” is not the same as “decided.” The moderation policy is the document that says, in writing, before the first genuinely bad review lands: what gets published automatically, what gets held for a human read, and what gets rejected outright versus what gets published with a reply. Without that written policy, the first sharply negative but legitimate review becomes a judgment call made under pressure by whoever’s logged in that day, and left undecided, the instinct tends toward suppression.

A workable policy is short: publish anything from a genuine buyer that isn’t spam, hate speech, personal information about staff, or content unrelated to the product (a shipping complaint aimed at the carrier, say, might get a reply rather than rejection, but rejecting it outright looks like censorship if a reader can see it was clearly about the product experience). Reject only clear abuse, competitor content, and reviews that aren’t about a real purchase. Hold nothing for “this makes us look bad”; that’s the line moderation exists to prevent someone from crossing. Whoever owns the review inbox should be working from that written policy, not improvising it per review.

What happens to reviews when a product is discontinued or re-SKU’d

A discontinued product doesn’t need its reviews deleted, but it does need a decision about where they live. Most review platforms keep reviews attached to the product record even after the product is marked out of stock or hidden from the storefront, which means the reviews simply stop being visible to shoppers rather than being lost, useful if the product might return, useless if it won’t. If the product page itself is being removed or redirected, decide before that happens whether the review history is worth preserving anywhere, since once the page is gone the reviews attached to it typically go with it unless the platform offers an archive or export first.

A rename or re-SKU is the more common and more disruptive case, because it looks like a small change but breaks the identifier the reviews are keyed to. Swapping a product’s SKU, splitting one listing into several variants, or merging several listings into one all sever the link between the existing reviews and the product record unless the review platform explicitly supports a review-transfer or product-merge operation, and not all do, or do so cleanly. Before a catalogue-wide SKU renumbering (a common side effect of a platform migration or an ERP change), check whether the review app has a supported re-mapping path; if it doesn’t, the reviews on renamed products effectively start over at zero, which is a conversion cost worth weighing against whatever the renumbering is meant to solve.

Who this is not for

A catalogue with a handful of SKUs and low order volume doesn’t need a dedicated review-and-UGC platform; the setup and monthly cost outweigh what a thin review count can return in conversion lift, and a lighter single-purpose app covers the requirement fine. A team not yet ready to reply publicly to criticism, or one inclined to suppress negative reviews rather than answer them, will get worse results from any review platform than from none; the tool amplifies a review programme that’s already being run honestly; it doesn’t create one. And a brand running review requests through the same automation platform as its subscription and win-back flows should check for overlap before adding a fourth trigger to an already crowded post-purchase sequence: a customer getting a review request, a subscription upsell and a replenishment reminder in the same week tends to unsubscribe from all three rather than engage with any.

Review programmes and subscription retention sit closer together than the org chart usually suggests: a delivery-triggered review request is timed off the same fulfilment event that should be triggering a subscription check-in, and a customer who leaves a critical review is a churn signal worth routing to the same team handling subscription retention, not a separate one. Run the timing and the routing as one system, check what that churn signal is actually costing with the subscription churn calculator, and compare your numbers against the subscription churn benchmark for DTC consumables before deciding the review programme needs a bigger budget than the retention flow that could use the same signal for free.