Google's policy lists a last name as personal information, and its reply tips ask you to use the reviewer's name

Google’s published description of the PERSONAL_INFO rejection reason names credit card details, medical records and government-issued identification. The reply this article is worried about contains none of those. It contains the customer’s first name, a note of which appointment they came to, and a booking reference quoted to prove the complaint is wrong. The policy sitting behind that enum value lists a last name among the things not to post. Google’s own tips page, on the other hand, asks you to address the reviewer by name, and no page we read puts those two sentences side by side.

What the API publishes

The v4 Business Profile API returns a reason with a rejected reply. policyViolation is documented as “Optional. Output only. The policy violation that resulted in rejection. Only populated if reviewReplyState is REJECTED.” A banner across those pages says:

You can now view the specific policy violations for any of your review replies that have been rejected in the Reviews API.

One of the values in that enum is PERSONAL_INFO. Google’s whole description of it is this:

Content that violates our policy on personal information isn’t allowed. Personal information includes private or confidential information, such as credit card details, medical records, or government-issued identification, whether yours or someone else’s.

Read that as a business owner and it sounds like somebody else’s problem. It is written for a member of the public about to paste a bank statement into a review, not for the salon owner replying underneath one.

The policy behind the value says more than the enum does

PERSONAL_INFO points at a policy, and the policy is where the useful detail is. Google’s Maps User Contributed Content policy opens its personal information section with an instruction: “Do not distribute or post personal information without consent.” It then defines the term:

Personal information is defined as information that applies to a living identifiable person and disclosure could result in risk of harm if it is compromised or misused.

And it lists what that covers. The first item is the one the API description leaves out:

Content which contains personal information of another posted without their consent such as: full name, or last name, their face in a photograph or a video, or other information which has been reported as having been posted without consent.

The second is closer to the enum’s wording: “Personally identifiable information and other personal information about yourself or others including financial information, medical information or personal identification information.”

So “full name, or last name” is on the list, and the enum description never mentions a name at all. That is the whole gap. Read only the API reason and nothing in it tells you that a name is at issue.

Where a normal reply crosses it

Four ordinary parts of a reply, each written for a good reason:

The name. The reviewer’s display name is on their review, but the surname from your booking system is not, and neither is the version of their name they did not choose to publish.

The confirmation that they were there. “the 2pm on the 14th” is information you hold as the business. If the review does not say when they came, your reply saying it is you publishing it.

The reference. “Booking 48211” identifies a record about a person to anyone who can read the profile, which is everyone.

What the service was. For a clinic, a dentist or a physiotherapist, naming the treatment in public is the medical case the enum description actually names.

The carve-outs in the policy protect the business, not the customer. Google allows a merchant’s own details: “We do allow merchants to post contact information related to their business including phone, email, or social media handles.” It also allows “An individual’s name if it is part of the commonly known or advertised business entity” and “An individual’s name if they are a public-facing professional conducting business under their name.” Your name on your own listing is fine. The customer’s is a different question.

One limit worth stating, and Google publishes both halves of it. The policy lists “full name, or last name” among the things not to post without consent. The reply tips page asks for a name in the same breath as a signature:

Personalize your reply: Address the reviewer by name and acknowledge their specific feedback. A personal sign-off with your name or initials shows that their experience matters to you.

So Google is not telling you never to use a name. It is telling you to use the reviewer’s name on one page and listing a last name as personal information on another, and no page we read reconciles them. Nor does any page we read say whether repeating a reviewer’s own public display name counts as posting personal information without consent. We have not tested it and we are not going to assert either answer. What is documented is the difference between the name the reviewer chose to publish and the one sitting in your booking system, and only the second is unambiguously yours to have leaked.

Being specific about the failure, not about the person

This is a real tension. Good practice on a negative review is to answer the actual complaint rather than post a template, because vagueness reads as indifference. Specific about the failure and specific about the person are not the same thing.

The working rule: restate only what the reviewer published, describe the failure rather than the customer, and keep your records out of it.

What not to write:

Hi Sarah M, we’re sorry the 2pm on the 14th was rushed. Booking 48211 shows you arrived late, which is why the appointment ran short.

That is a name, an appointment time, a reference and a rebuttal built from private data, in two sentences. The same answer with all four taken out:

We are sorry the appointment felt rushed, and we would like to understand what happened. The phone number on this profile reaches us directly, and we would rather go through it with you there than here.

Nobody is identified, no record is quoted, and nothing is conceded that the review did not already say. Note what it also does not do. It does not admit a cause, promise a fix or describe a procedure that has changed, because none of that is knowable from a review saying an appointment felt rushed, and a reply that invents it has swapped one fabrication for another. Redaction is the only edit being demonstrated here.

Note what the bad version is really doing: “which is why the appointment ran short” wins the argument by disclosing the customer’s record. If your reply needs their file to make sense, it is the wrong reply.

Move the detail off the profile. The personal information policy explicitly permits your business phone and email in public content, so inviting someone to contact you is not a conflict with this rule. It could still meet a different one, because ADVERTISING_AND_SOLICITATION is a separate value in the same enum, and the policy pages behind the two values never address replies.

Google does resolve it, though not in a policy. Its tips page for replies says to do exactly this:

Never share a reviewer’s private information or engage in personal attacks. If a situation is complex, politely request that the reviewer contact you via phone or email to resolve the issue privately.

That is guidance rather than policy, and it is the only page we found that tells an owner what to do about both rules at once. The same page draws the line on the other side: “Be conversational, not promotional: Your reviewers are already customers, so avoid using your response to offer deals or promotions.”

So the contact detail is invited and the offer is not. We have not tested how a reply containing a phone number is actually moderated, and Google’s policy text still does not say.

Two values, one subject

PERSONAL_INFO is not the only reason in this area. PRIVACY is described as “Content that violates the Maps User Contributed Content privacy policy isn’t allowed.” Two of the published reasons therefore point at personal and private information, and a rejection can arrive under either. Neither one tells you which sentence of your reply caused it. For the rest of the list, see the full list of rejection reasons.

What Google tells you, and when

Google’s help page confirms replies are moderated: “This makes sure that they follow Google’s content policies. If your reply isn’t approved to be posted, you’ll be asked to edit it.” Timing is on the same page: “Replies usually take up to 10 minutes to review, but sometimes a review can take up to 30 days.”

There is an asymmetry in how the same page describes a published reply: “If your reply is approved, it will be publicly posted under the customer’s review. It will appear like your business replied, and your personal name won’t be shown.” Google protects the identity of the person writing the reply by default. The identity of the person it is about is left to you.

Remember who reads it first: “The person who wrote the review is notified when you reply.” The customer whose surname you published gets an alert about it.

If you are on the other side of this, the policy ends with a route: “If you believe your personal information has been posted without your consent, please follow these instructions to flag the review.”

The short version

Google’s description of PERSONAL_INFO describes documents. The policy it enforces names a last name, and the tips page asks you to address the reviewer by name, which no page we read reconciles. Write replies that answer the complaint using only what the reviewer published, keep your own records out of them, and the gap stops being yours to guess at.