A review link opened. What happened next?

Key takeaways

• Check the business identity, the screen reached and the opening context separately. A successful navigation answers only one part of the question.
• Test the plain link and the QR route with recorded browser and app context. Do not infer the browser sign-in state from another app.
• Keep redirect attempts, manually observed screens and accepted public reviews as different evidence. A handoff test must stop before posting a review.

Start where your own page stops

The confirmation finishes, a link opens, and your activity record shows a review redirect. That can be a useful operational event. It does not tell the manager whether the customer saw the intended business, a review-writing screen, an account prompt or a general listing.

Treat the move to Google as a handoff with a small set of observable questions. Which exact link did the invitation use? Which business appeared? Which screen was visible? What browser or app displayed it? Those questions give a team something concrete to reproduce before changing the campaign or asking more customers to try again.

This guide is a diagnostic method, not a report of a current Google outage or a test of every phone. A local observation belongs to the device, entry point and time recorded. It should not become a claim that Google always behaves that way, or that a different link will remove every sign-in step.

Check the business before deciding the link is broken

Start with the business name and full address that should appear. A familiar brand name alone is insufficient for a group with several locations. A link that opens smoothly for another branch still fails the intended customer task.

Google provides a review link and QR option through the Business Profile review controls. Use the link associated with the intended profile as your starting reference. Keep the original input beside the campaign or artwork record so a colleague can compare what was configured with what the customer actually opened.

Then distinguish a place link from a review-writing link. Google’s developer documentation lists separate fields for opening the place, writing a review and reading reviews. The review-writing field is named writeAReviewUri. That distinction explains why finding the correct business listing is not the same observation as reaching a place to write a review.

You do not need to implement a Places API integration to run this check. Compare the owner-supplied review link, the stored campaign destination and the visible business identity. If identity is wrong, stop the rollout and correct the source before investigating a phone-specific explanation.

Sources: Google Business Profile: create a review link or QR code; Google Maps Platform: different links for a place, writing a review and reading reviews

Record the opening context instead of guessing at sign-in

Google says a customer needs to be signed into a Google Account to leave a review. The account does not have to use a Gmail address. A sign-in prompt therefore deserves its own result in a test log; it is not automatically evidence that the business link is wrong.

Record where the link started and where it opened. A camera scan, a tapped email link, an in-app browser and a link pasted into the phone’s browser are different test entries. If the Maps app appears, record that too. Describe the account state visible in the tested context, rather than writing “signed in” because the tester uses a Google app elsewhere on the phone.

There is also a scope limit in Google’s developer documentation: its links for reviews and photos are supported on the web version of Google Maps. That is a reason to inspect the destination context when assessing those documented API links. It is not evidence that every Google review link has the same mobile behavior or that your customer should be forced through an app.

Do not ask a customer to share a password, authentication code or screenshot of their account to complete your test. Use an authorized team device and stop at the visible destination or sign-in prompt. If a test needs an account, the account owner handles sign-in privately.

Sources: Google Business Profile: review invitations and Google Account sign-in; Google Maps Platform: different links for a place, writing a review and reading reviews

Give the QR and plain link the same test

A QR code is an entry to a link, not an independent review platform. Compare the link encoded in the QR with the plain link you intend to share. If one contains a short-link or campaign route, record that intermediate route and its configured destination. Do not assume two routes are equivalent because their labels both say Google reviews.

First open the plain link in a recorded context. Then scan the QR and record the context it opens. Keep the business and visible-screen checks identical. If the plain route and the scanned route differ, you have a narrower question about the inputs or opening path. If they reach the same account prompt, changing the QR artwork alone has not yet been shown to solve it.

Keep the customer promise consistent with the route. A direct invitation asks for an honest review. A Ripple benefit form first performs its own customer task, then hands the customer to the configured destination. The benefit remains independent of writing a review or choosing a rating, and the public route remains available at every rating. Neither entry point gives the business control of Google’s account interface.

For a digital invitation, include an ordinary clickable link. Someone already reading on their phone should not need another device to scan the only route you provided. That is an accessibility decision about the invitation, separate from proving where either route lands.

Use a small matrix that another teammate can repeat

Choose a few contexts the business actually expects customers to use, rather than attempting every possible combination. Start with an ordinary phone browser, the real QR entry and one relevant digital entry such as an email. Add an app-opening case only when it is part of the observed journey. Record the phone, browser or app version where practical and the test date.

The test is successful when it produces a clear observation, including a problem. “Correct business; account prompt reached” is more useful than a green tick labelled “works.” “Not observed” is a valid entry when the tester cannot establish the state. Do not turn an untested row into a pass based on what another device did.

Keep the log small and private. It needs the business reference, test context, screen category and next action. It does not need customer names, email addresses, passwords, account avatars or screenshots containing private information. Record a textual observation when a clean screenshot cannot be captured.

• Confirm the intended business and review link with the profile owner.
• Compare the configured destination with the plain link and QR input.
• Open each selected route and record the actual browser or app context.
• Classify the visible screen and stop before posting a review.
• Assign one correction or next check, then repeat the affected case.

A fictional two-location team finds two different questions

This is a fictional teaching example, not a Ripple customer case or a production Google test. A café group is preparing invitations for its Harbor and Market locations. The manager records the intended address before testing three routes for Harbor.

The QR sample opens Market’s listing. The plain review link opens Harbor and shows an account prompt in the tested browser. A colleague’s browser reaches Harbor’s review-writing screen. These are three observations, not evidence of a general QR defect, a Google outage or a conversion rate.

The team has an immediate correction and a separate question. Replace the mismatched QR input with the confirmed Harbor route and retest that sample. Keep the account-prompt result in the browser context where it occurred, without promising that the corrected QR will remove sign-in. The colleague’s successful screen does not erase either finding.

After correction, the manager repeats the same affected route and records the new visible result. Nobody submits a public review to make the checklist look complete. The team can now explain what changed and what still needs checking before distributing more invitations.

Do not rename a redirect as a completed review

Keep three evidence layers separate. Your system may record that it attempted a redirect or that someone followed an outbound link. An authorized tester may manually observe the destination screen. Google may later display an accepted public review. These records answer different questions and do not automatically join into one customer-level funnel.

For Ripple’s benefit-first flow, a completed form and a benefit confirmation describe work on the Ripple side of the journey. A subsequent handoff event does not prove that Google loaded a particular screen, the customer submitted a review or Google accepted it. The customer can still have received the promised benefit without leaving a public review.

When matching evidence is unavailable, report the counts separately with their source and date window. Do not divide total destination reviews by unrelated redirect attempts and call the result a conversion rate. A small manual test matrix is diagnostic evidence about those tested contexts, not a measurement of all customers.

Keep the invitation neutral while investigating friction. Google requires genuine experiences and prohibits benefits offered in exchange for reviews. A broken or inconvenient handoff is a reason to improve the route, not to offer a reward for completing a review, coach a rating or exclude dissatisfied customers.

Sources: Google Business Profile: create a review link or QR code

Finish with one owner and one next check

A useful diagnostic ends with a decision the team can act on. A wrong business needs an identity or configuration correction. A general listing instead of the expected writing screen needs a route check. An account prompt needs an honest explanation of the observed context. An error or unexplained transition needs a reproducible record, not a claim that every customer is blocked.

Assign the responsible person and a review date. Retest the affected contexts after a destination change, a location change or a reported customer problem. Avoid rewriting every invitation or purchasing another integration before the evidence identifies which part of the handoff needs attention.

Use Ripple’s Google review-link tool to prepare a QR from the confirmed route, or bring a configured Ripple customer flow to a product discussion. Then use the same matrix to inspect what happens after the link opens. Start with one location and one customer entry point. The next useful step is a clearer handoff, not a promise of one-tap reviews on every device.

Sources and further reading

• Google Business Profile: create a review link or QR code
• Google Business Profile: review invitations and Google Account sign-in
• Google Maps Platform: different links for a place, writing a review and reading reviews