Summary
When a review is published, Shopify emails the partner account with the rating, review text, shop, and timestamp, nothing that identifies where the review came from. Partners who ask merchants for reviews can’t connect a review to the request that earned it.
The request
Echo an attribution parameter back in the review notification email. Two halves of one change, neither is useful alone. Shopify already supports UTM parameters on listing links for attributed installs. This extends an established pattern to reviews.
a. Return the value in the notification email. Shopify already sends it. One additional field is the smallest change that fully solves this. No new API surface, no new UI, no polling. It turns our probabilistic matcher into a direct lookup.
b. Preserve a server-visible parameter on the deep link, so there’s something to return. Accept the standard UTM set, or a single reserved parameter, or even let us specify our own. Persist it onto the review record:
https://apps.shopify.com/<app-handle>?ref=<opaque-id>#modal-show=WriteReviewModal
Two constraints worth stating. It must be a query parameter, not part of the fragment, everything after `#` is client-side only and never reaches the server, so an id appended to #modal-show=WriteReviewModal can’t be captured. And the value can be fully opaque: stored and echoed, never parsed, validated, or interpreted.
What’s missing today
As far as we can tell:
- The notification email carries no attribution or referral field (see above).
- Query parameters on the listing URL aren’t carried through the `#modal-show=WriteReviewModal` flow in any way a partner can later observe.
Why the shop name doesn’t close this. The email identifies the store by display name. A label merchants can change at any time, and one that isn’t unique across the App Store. But even a stable identifier like the myshopify.com domain wouldn’t be enough. It tells us which store left the review, not which request prompted it. Any merchant we’ve asked more than once (a different conversation, a different month, a different person on our team) remains ambiguous. Store identity narrows the candidate set. Only a value we supplied ourselves resolves it.
Why it matters
Today the path ends in a guess. One preserved parameter makes it end in a fact.
We can see a request go out, to which merchant, from which team member, then the trail stops… The review appears some indeterminate time later with nothing tying it back.
So we infer. We built a probabilistic matcher that scores candidate requests against each new review and emits a confidence score. It works, but delayed reviews, multiple outstanding requests to the same merchant on different surfaces, and merchants who review from a different context than the one they were asked in all degrade it. That’s a lot of infrastructure to reconstruct one value that exists at submission time and is then discarded.
The real cost isn’t reporting. Asks are sent by our support team inside real conversations, so if we can’t tell which ones convert, we can’t learn, and we can’t coach team members from real examples. The asks never improve, the merchant’s experience during the ask stays sub-par. Attribution means sending fewer and better-targeted asks, not more.
Also useful, not required
Neither of these is the ask, but both would help:
- The same value surfaced as a “Source” column in the Partner Dashboard review list, the CSV export, and the Partner API.
- A read endpoint on the Review API, which today only requests a review modal in-app. Fetching a review by the parameter above would remove the need to parse notification emails entirely.
- A
review.createdwebhook. Useful independently of everything above, and it would remove the need to parse notification emails at all.
Scope
This asks for nothing about reviewer identity, and gives us no ability to gate, filter, or condition a review on the value. It’s a random id (12345) that means nothing to anyone but us. It appears in the merchant’s URL bar, as any query parameter does, but reveals nothing, and never needs to be rendered back into the listing page or the review itself. A length cap would be entirely reasonable.
Nothing here changes what merchants can write, or how reviews are moderated.
