Методологія

Звідки ми беремо дані

Джерелом є публічні відгуки про вашу компанію, опубліковані в Google Картах - ті самі, які бачить кожен відвідувач вашої картки. Ми не купуємо даних у когось іншого і не проводимо опитувань.

Google не підтверджує, що автор відгуку справді був вашим гостем або клієнтом. Зіставляйте числа з цього звіту з власними даними - бронюваннями, опитуваннями, скаргами - замість того, щоб спиратися на одне джерело.

Завантаження виконує зовнішній постачальник, названий у політиці приватності. Глибина завантаження залежить від тарифу: безкоштовний обліковий запис зберігає найновіші відгуки, платні тарифи сягають далі в минуле.

Завантаження - це знімок конкретного дня. Якщо автор пізніше змінить або видалить свій відгук, звіт і далі описує стан на момент завантаження. Дати й зіркові оцінки приймаємо так, як їх публікує Google - нічого не виправляємо і не доповнюємо.

Безкоштовний зразок звіту - окремий випадок: він свідомо стоїть на 50 найновіших відгуках закладу, а не на всьому масиві. Документ каже про це прямо на першій сторінці («Основа: 50 найновіших із N відгуків»), а розділи, які потребують довшої історії - наприклад історичні теми - у ньому просто не з'являються замість того, щоб стояти порожніми.

ЯКІСНІ висновки - картки проблем, сильні сторони, цитати, текст - постають на ВИБІРЦІ відгуків, а не на всьому масиві: до моделі потрапляє до 500 відгуків, дібраних пропорційно до настрою (у звіті мережі - до 100 на заклад і до 500 з усієї мережі, із гарантованим мінімумом для кожного закладу). Для великого закладу це частка матеріалу, і документ каже про це прямо в примітці про метод, наводячи обидва числа. ЧИСЛА - середня оцінка, частки настрою, розподіл зірок, кількість відгуків - обчислюються з УСЬОГО матеріалу, охопленого звітом, а не з вибірки.

Є заклади, для яких ми звіту не виконаємо. Якщо заклад має в Google менше ніж 3 відгуки, ми відмовляємо в прийнятті замовлення ще до оплати - з такого малого матеріалу неможливо зробити висновки про компанію, а документ, який із нього постав би, говорив би виключно про брак даних. Ту саму умову перевіряємо вдруге після завантаження відгуків, уже на їхньому тексті: нам потрібно щонайменше 3 відгуки з текстом і загалом 400 символів цього тексту, бо з оцінки без жодного слова немає чого читати. У замовленні, що охоплює кілька компаній, умова стосується їхньої суми, а компанія з меншою кількістю відгуків залишається у звіті й описана в ньому.

Як постають числа

Кожен відгук оцінюється окремо. Мовна модель читає його і визначає тональність - похвала, скарга чи нейтральний вислів - та сферу, якої він стосується, наприклад обслуговування, ціни або чистоту. Один відгук може стосуватися кількох сфер одночасно, і тоді він зараховується до кожної з них.

Назви сфер упорядковує окремий крок: варіанти тієї самої теми - наприклад „обслуговування” і „обслуговування клієнтів” - зливаються, щоб одна проблема не розпалася на два менші лічильники.

Відгуків не перекладаємо перед аналізом. Модель читає кожен мовою, якою його написано, а результат класифікації потрапляє до одного спільного словника сфер - тож скарга англійською і скарга польською про те саме опиняються в одному лічильнику. Переклад з'являється лише біля цитат у готовому звіті - про це в розділі про цитати.

Відгуки, що складаються з самої зіркової оцінки, без тексту, повністю зараховуються до кількості відгуків і середньої оцінки, але не будують карток проблем і цитат - у них немає що читати. Тому звіт показує середню також окремо для відгуків з текстом: ці дві середні можуть різнитися, і ця різниця сама по собі є інформацією.

Усі числа у звіті - частки, лічильники скарг, діаграми - є сумою цих окремих оцінок. Жодне з них не є оцінкою на око чи округленням: кожне можна розкласти назад на конкретні відгуки.

Похвала і скарга щодо однієї ділянки виключають одна одну в межах одного відгуку: загалом позитивний відгук, який нарікає на чистоту, для чистоти рахується як скарга, а не як похвала. Картка сильної сторони і картка слабкої сторони тієї самої ділянки користуються тим самим правилом, тому подають те саме число похвал.

Позначки «сильніший», «слабший» і «подібний» біля конкурентів рахуємо відносно оцінки компанії в Google за всю історію картки, а не відносно середньої досліджуваного корпусу - ці два числа можуть відрізнятися, особливо коли звіт охоплює лише найновіші відгуки. Під таблицею конкурентів стоїть та оцінка, відносно якої пораховано позначки; поріг - 0.1 зірки.

Окремо рахуємо відповіді власника: постачальник віддає відповідь із Google Maps у тому самому записі, що й відгук, а звіт подає, скільки відгуків - і скільки негативних - не мають відповіді. Число охоплює лише відгуки зі штампом вимірювання; відгуки, завантажені до 22 вересня 2026 р., такого штампа не мають, і звіт тоді пише «не виміряно» замість нуля. Рекомендація відповідати на відгуки постає виключно з цього числа - без вимірювання немає рекомендації. Наші пропозиції відповідей, згенеровані в панелі, - це не це число: вони кажуть, що можна відповісти, а не чи відповів власник. Рекомендація з'являється лише від 10 виміряних відгуків - рекомендація з пріоритетом на підставі одного-двох відгуків казала б більше, ніж відомо. Виміряні - зазвичай найновіші відгуки, бо вимірювання додається з кожним наступним завантаженням, тож число описує поточні відповіді, а не всю історію профілю; звіт каже це поруч із числом.

Свіжі проблеми, інциденти та історичні теми

Звіт не звалює всі скарги в один мішок. Повторювані та свіжі скарги стають картками проблем. Нечисленні сигнали, переважені похвалами тієї самої сфери, потрапляють до розділу „Поодинокі інциденти”. Скарги, найновіший слід яких давній, а сфера відтоді покращилася, опиняються в розділі „Історичні теми - без нових сигналів”.

Той самий предмет скарги не може в одному документі стояти у двох станах одночасно. Коли тема з історичного розділу описує те саме, що й картка поточної проблеми - зокрема й тоді, коли її названо іншими словами, - історичний запис зникає, бо твердження про тишу спростовує живий доказ. Картку поточної проблеми залишаємо недоторканою. Окрему подію з розділу інцидентів - теж, хіба що вона є другим описом тієї самої справи, що й картка (абзац нижче): тоді вона несе лише те, що вже несе картка.

Свіжість рахуємо відносно кінця аналізованого діапазону дат, а не дня створення документа - звіт за минулий рік оцінює свіжість так, як вона виглядала наприкінці того року. Частку скарг рахуємо в межах сфери, якої вони стосуються, а не відносно всіх відгуків.

Вага картки - „Критичні”, „Важливі”, „Спостерігати” - не випливає з самої лише кількості скарг. Її підвищують частка скарг серед відгуків про сферу, свіжість останніх сигналів і рід сфери: теми, що торкаються безпеки чи гігієни, важать більше. Тому картка з меншою кількістю скарг буває важчою за картку з більшою - документ нагадує про це й поруч із самими картками.

Одна картка не підлягає цим порогам: картка з позначкою ЖИТТЯ / ЗДОРОВ'Я. Вона збирає відгуки, у яких мовна модель - читаючи окремо кожну скаргу-кандидата - розпізнала подію, що загрожує здоров'ю або життю гостя: отруєння, травму, інфекцію, комах, плісняву, пожежу, затоплення, фізичну агресію, відсутність допомоги в надзвичайній ситуації або небезпечну конструкцію. Кандидатів визначає код (фрагменти скарг, які класифікатор відніс до сфер здоров'я, безпеки, чистоти, якості продуктів і їжі, а коли фрагментів немає - негативний відгук із такою сферою; текст кандидата - до 320 символів), модель виносить вердикт, а код виконує: картка критична від першого повідомлення, стоїть першою, а її числа рахують лише підтверджені відгуки. Картки, інциденти та історичні теми про ту саму подію вона поглинає, щоб та сама подія не стояла в документі двічі з різною вагою. Чому вердикт за текстом, а не лише категорії класифікатора: виміряно 22 вересня 2026 р. на 45 випадкових скаргах зі сфер «Здоров'я» і «Безпека» - 28 стосувалися здоров'я або життя гостя, 17 ні (добробут тварин, крадіжка, камера в роздягальні, маски); за такої похибки червона позначка коштувала б довіри замість того, щоб її будувати. Вердикт теж може помилятися в обидва боки; кожне повідомлення з цієї картки потребує перевірки з вашого боку. Тією самою подією вважається лише запис, УСІ цитати якого дослівно стоять у відгуку, визнаному загрозою, і описують саму подію, а не іншу скаргу з цього відгуку; сама категорія «Здоров'я» не є підставою. Такий запис зникає, коли має не більше скарг, ніж картка ЖИТТЯ / ЗДОРОВ'Я; більший лишається зі своїми числами, а його рекомендації переходять під картку ЖИТТЯ / ЗДОРОВ'Я - тоді цитата може повторитися під обома картками. Картка з десятками скарг на інше лишається незмінною. Першою рекомендацією під цією карткою завжди є та сама: перевірити кожне повідомлення за власними записами; рекомендації з аналізу стоять після неї. Найбільшим ризиком на обкладинці картка стає лише тоді, коли останнє повідомлення припадає на 12 місяців перед кінцем періоду звіту - старші повідомлення лишаються на картці, але обкладинка говорить про поточну проблему. Коли перевірка охопила не всі відгуки-кандидати (ліміт часу або помилка моделі), примітка в PDF каже це прямо, а рекомендації під картками про здоров'я та безпеку лишаються в документі навіть зі статусом «Спостерігати».

Та сама проблема не стоїть у документі водночас як поточна картка і як поодинокий інцидент чи історична тема - інакше документ казав би про одну справу дві протилежні речі («триває» і «згасло»). Кандидатів визначає код (записи з тієї самої категорії), а те, чи йдеться про той самий предмет скарги, вирішує мовна модель за назвою та описом обох записів: спільної категорії замало, бо в одній сфері буває кілька різних проблем. До цього рішення не потрапляє запис, який несе те, чого немає в картці: подія, позначена як небезпечна, подія з об’єкта мережі поза доказами картки або запис, новіший за дату останнього повідомлення, яку подає картка, - тоді обидва записи залишаються, бо видалення забрало б із документа найновіший сигнал щодо цієї справи. Запис, визнаний тією самою проблемою, випадає, поточна картка залишається зі своїми числами, а рекомендації, що на нього вказували, переходять під картку й підпорядковуються її правилам - під карткою зі статусом «Спостерігати» вони не друкуються. У разі сумніву обидва записи залишаються.

Розділ «Що змінилося від попереднього звіту?» показує нові, стійкі й закриті проблеми та середню оцінку нових відгуків лише тоді, коли від попереднього звіту додалося щонайменше 10 відгуків. За меншої кількості різниця між переліками проблем походила б із самого аналізу, а не від клієнтів - тоді залишається тільки оцінка, чи спрацювали попередні рекомендації. Це інший розділ, ніж «Що змінилося від попереднього періоду?», який порівнює два рівні послідовні періоди відгуків; його пункти «Раптові зміни» з датами - це скупчення відгуків з оцінкою 1-2 зірки в короткому вікні, помітно понад звичайний ритм цього об’єкта; скупчення оцінок 5 зірок до цього переліку не входять, а те саме скупчення одиниць і скарг рахується один раз. Коли порівняння періодів не має жодного пункту, розділ не друкується.

За наявності картки ЖИТТЯ / ЗДОРОВ'Я рядок «Найбільший ризик» у підсумку на першій сторінці вказує на цю картку - кількість повідомлень і посилання на неї, - а «Дія прямо зараз» - це рекомендація перевірити кожне повідомлення під цією карткою (з-поміж негайних і короткострокових рекомендацій). Рядок «Очікуваний ефект» з аналізу тоді не стоїть, бо описував іншу дію. Картка критична й стоїть першою, тож підсумок не може називати найбільшим ризиком щось інше. Її дата останнього повідомлення походить від найновішої підтвердженої події, навіть якщо цю подію не цитовано.

Та сама цитата - в тому самому формулюванні - стоїть у документі в одному місці. Коротший уривок відгуку, процитованого деінде довше, не вважається повтором, бо зазвичай несе іншу тему того самого відгуку; утім, буває тією самою скаргою під двома записами. Якщо те саме речення клієнта мало б потрапити під два записи, воно залишається при ранішому в такому порядку: картки проблем, інциденти, історичні теми, сильні сторони - змішане речення («смачно, але холодно») є доказом скарги. Коли цитата стоїть водночас під карткою проблеми й під інцидентом або історичною темою, вона залишається при інциденті чи темі, бо ті мають зазвичай один доказ, а картка - цілий запас. Винятки: запис, усі цитати якого є повторами, зберігає одну - останню, - бо запис без доказу був би гіршим за повтор; залишається також цитата, яка є єдиним доказом об’єкта мережі, названого біля запису; і, нарешті, картка ЖИТТЯ / ЗДОРОВ'Я, під якою цитата про загрозу може стояти поруч із карткою, з якої її перейнято.

Формули, на яких стоїть звіт

Частку скарг у сфері рахуємо з відгуків, що висловлюються про цю сферу: частка скарг = скарги про сферу ÷ відгуки про сферу. Знаменником не є вся маса відгуків - скарга на парковку не розчиняється в сотні похвал кухні.

Частки настрою на кільцевій діаграмі рахуємо методом найбільших залишків, щоб вони сумувалися рівно до 100%, а чистий сентимент виводимо з тих самих часток: чистий сентимент = % похвал - % скарг. Одне означення для діаграми й тексту означає, що два числа про те саме не можуть розійтися навіть на пункт.

Свіжість сигналу - це різниця дат: вік сигналу = кінець аналізованого діапазону - дата найновішої скарги в темі. Тією самою різницею користуються ваги карток і розділ історичних тем.

Вага картки - це порогове правило, а не середнє. Спрощено: картка дістає позначку „Критичні”, коли скарги у сфері водночас численні та свіжі, або коли сфера високого ризику - безпека, гігієна - має свіжий, вагомий сигнал. Пороги кількості масштабуються з розміром матеріалу: за кількох тисяч відгуків планка висить вище, ніж за сотні, щоб жменька скарг у великому закладі не діставала червоної позначки. Точні значення порогів належать кодові й змінюються разом із ним, тому ми їх тут не переписуємо.

Звідки беруться цитати

Цитати наводимо дослівно, у тому вигляді, як їх написали клієнти, разом з друкарськими помилками. Ми не скорочуємо їх так, щоб змінився зміст, і не склеюємо речення з різних відгуків.

До кожної цитати додаємо дату публікації, а у звіті для мережі - також заклад, якого вона стосується. Завдяки цьому кожну цитату можна знайти в Google Картах і перевірити.

Цитату, написану іншою мовою, ніж мова звіту, документ показує в перекладі з позначкою „(переклад)”. Вибір цитати і зіставлення дати завжди відбуваються на оригіналі, слово в слово - перекладається лише остаточно вибрана версія, а переклад виконує мовна модель.

Добір цитати під картку - рішення моделі, тому окрема перевірка з'ясовує згодом, чи цитата стосується теми картки, під якою стоїть. Натомість прив'язку цитати до закладу й дати виконує код - це просте зіставлення з вихідним відгуком, без участі моделі.

Що робить модель, а що код

Над звітом працюють дві моделі різної сили: швидша читає кожен відгук окремо і класифікує його, сильніша пише описовий зміст - текст, описи проблем і запропоновані дії. Модель відповідає за все, що потребує розуміння речення.

Код відповідає за все, що можна перевірити без розуміння: числа, дати, підсумовування класифікацій, прив'язку цитати до закладу, узгодженість розділів між собою. Для коду результат роботи моделі - матеріал для перевірки, а не істина в останній інстанції.

Готовий звіт проходить набір перевірок, перш ніж ми його віддамо. Перевіряємо, зокрема: чи описує заголовок картки один предмет скарги, а не кілька одразу; чи стосується доказ під карткою її теми; чи не описують дві картки ту саму проблему; чи немає в тексті неіснуючих слів, тобто друкарських помилок моделі; чи має свою картку кожна сфера з видимою проблемою. Частина перевірок - чистий код, частина - повторний суд моделі над готовим текстом. Перевірка, яка не має певності, залишає текст без змін, замість виправляти його силоміць; звіт, який перевірок не пройде, створюється заново.

Звіт для мережі та звіти окремих закладів

Звіт для мережі - не склейка звітів закладів. Усі відгуки мережі аналізуємо як один масив: проблема, видима в кількох закладах, стає однією карткою з позначкою, скількох закладів вона стосується, а проблема одного закладу потрапляє до частини про місцеві справи. Кожна цитата несе назву закладу, з якого походить.

Тому числа у звіті мережі можуть відрізнятися від чисел у звітах окремих закладів - і це не суперечність. Теми у звіті мережі ширші: одна мережева картка може охопити кілька вужчих карток закладів, тож її лічильник буває більшим за їхню суму, а самих карток менше. Обидві перспективи описують той самий матеріал з різною зернистістю.

Речення в описі картки, теми, інциденту або сильної сторони, яке називає об’єкт мережі, не охоплений доказами цього запису - ні переліком об’єктів біля запису, ні підписами цитат, - видаляється повністю; запис, увесь опис якого стосується такого об’єкта, залишається без змін. Рекомендацію оцінюють інакше, бо вона стоїть не біля цитат, а спрямовує дію: об’єкт, названий у рекомендації, мусить мати в документі скаргу з тієї самої сфери, що й запис, на який вказує рекомендація, - у будь-якому розділі, зокрема серед локальних проблем, - або похвалу з цієї сфери серед сильних сторін - вона враховується лише тоді, коли рекомендація називає також об’єкт зі скаргою з цієї сфери; похвалений об’єкт тоді вважаємо взірцем - код не розпізнає ролі об’єкта в реченні, він перевіряє лише це сусідство. Об’єкт без такої опори, що стоїть у переліку поруч з об’єктами, які опору мають, зникає з переліку разом зі своїм сполучником, а решта рекомендації залишається, - якщо це справді перелік вигляду «A, B і C» (спершу коми, потім «і» чи «та» - після сполучника коми вже немає): щонайменше три об’єкти або два, поєднані сполучником наприкінці речення, без іменника в множині безпосередньо перед ними, - і якщо безпосередньо перед переліком стоїть прийменник місця («в», «на», «для», «при») або іменник об’єкта («об’єкта», «закладу»), перелік завершує речення, а речення не містить числівника (крім позначення часу, суми, відсотка чи кількості разів, як-от «кожні два тижні») і слів «кожен» чи «всі». Інакше решта речення, слово перед переліком («крім», «між») або число («обидва», «у 3 об’єктах») могли б стосуватися саме вилученого пункту. У кожному іншому випадку рекомендація випадає повністю, бо кома між двома назвами буває межею двох речень, а вилучення назви змінило б зміст. Рекомендація без такої опори не друкується повністю, а не частково, бо видалення одного речення могло забрати саму вказівку; із заголовка знімається лише кінцеве «… у закладі X». Рекомендації, що не вказують на жоден запис, оцінює перевірка опори рекомендацій. У таблиці дій для кожного закладу речення про підтримання стандарту не стоїть біля об’єкта, який має в документі критичну або важливу картку, - його замінює посилання на цю картку з кількістю скарг цього об’єкта, коли картка її подає, та рекомендацією під нею. Об’єкт із повідомленнями на картці ЖИТТЯ / ЗДОРОВ'Я отримує посилання на неї також тоді, коли дію в таблиці написав аналіз, - ця дія стоїть після посилання. Рекомендація потрапляє в рядок об’єкта лише тоді, коли не називає іншого об’єкта мережі. Біля об’єкта, найновіший відгук якого старший за 12 місяців від кінця періоду звіту, документ подає його дату в таблиці закладів, у рамці найкращого й найгіршого закладу та в таблиці дій - оцінка такого об’єкта описує стан понад річної давності.

Чим це відрізняється від вставлення відгуків у чат зі ШІ

Найчастіше запитання про цей продукт: навіщо платити, якщо відгуки можна вставити в безкоштовний чат зі ШІ. Перша різниця приземлена: чат не має даних. Google Карти не віддають відгуків зручно в повному обсязі - зібрати їх за весь аналізований діапазон, з датами й зірковими оцінками, це окрема робота, і все подальше рахується на цьому наборі, а не на фрагменті, що вміщається в розмову.

Друга різниця - спосіб рахування. Модель, що читає тисячі відгуків за раз, не рахує - вона прикидає. Спитайте її про кількість скарг на обслуговування - вона назве число, якого ніхто не перевірить. Тут кожен відгук класифікується окремо, а кожне число у звіті - порахована кодом сума цих окремих вердиктів, і кожне можна розкласти назад на конкретні відгуки.

Третя різниця - контроль. Відповідь чату - це перший начерк, якого ніхто не перевіряє. Цей звіт проходить описаний вище набір перевірок - докази під картками, дублікати, покриття сфер, неіснуючі слова - а узгодженість чисел між розділами пильнує код, а не пам'ять моделі. До того ж є правила, однакові для кожної компанії: класи істотності, пороги, масштабовані розміром матеріалу, свіжість відносно діапазону дат.

Чесно: за жменьки відгуків різниця мала - кілька десятків вставлених відгуків добрий чат підсумує розумно. Різниця росте з матеріалом: за сотень чи тисяч відгуків, кількох закладів і довгого діапазону дат підсумок за один прохід перестає бути злічуваним і перевірним - а саме за злічуваність і перевірність відповідає цей документ.

Де хиблять дані

Відгуки описують те, що клієнти вирішили написати. Задоволені пишуть рідше, ніж розчаровані, тож картина з відгуків не є тим самим, що картина з опитування всіх клієнтів. Звіт вимірює голос тих, хто пише, - і тільки їхній.

За малої кількості відгуків один вислів важить дуже багато. Звіт позначає такі місця застереженням про розмір вибірки, але застереження не змінює суті: це все одно висновок з тонкого матеріалу, і один новий відгук може його перекинути.

Розділ історичних тем робить висновок з тиші: якщо свіжих скарг немає, проблема, ймовірно, ущухла. Проте тиша - не доказ: клієнти могли перестати писати з інших причин, а проблема може тривати. Слово „ймовірно” біля таких тем слід читати дослівно.

Де хибить автоматика

Для неоднозначних відгуків - які хвалять одне, а ганять інше - класифікація буває помилковою, і відгук потрапляє не до тієї сфери. Кожне число у звіті успадковує якість цієї класифікації: у лічильнику з сотень відгуків поодинокі помилки тонуть, але у сфері з кількома відгуками одна помилка помітно зсуває картину.

Описовий текст пише модель, тож трапляються вади письма: заголовок картки може наголосити меншість описаних питань, опис може піти на крок далі, ніж сягає доказ, а в тексті може стати друкарська помилка, що творить неіснуюче слово. Описані вище перевірки ловлять частину таких вад - не всі.

Самі перевірки теж хибні, причому в обидва боки. Ми налаштували їх обережно: перевірка без певності залишає текст, бо силуване виправлення прибирало б і правдивий зміст. Ціна цієї обережності - те, що окрема вада може пройти крізь сито: наприклад, дві картки про дуже схожі проблеми зрідка можуть стати поруч.

Поділ на системну проблему, інцидент та історичну тему спирається на пороги кількості й свіжості сигналів, а кожен поріг щось ділить на волосину. Рідкісна, але серйозна скарга може потрапити до інцидентів, хоча ви оцінили б її важче. Тому розділ інцидентів показує такі сигнали відкрито, замість їх ховати.

Кількість скарг біля картки визначає перевірка обсягу: мовна модель позначає, які скарги говорять про тему із заголовка картки. Вона робить це тричі, незалежно, і скарга зараховується до картки, коли її позначають щонайменше два з трьох прочитань - одне прочитання на тих самих відгуках могло дати картці то з десяток, то понад сто скарг. Інколи картка проблеми стоїть у звіті без власної кількості скарг і без плашки ваги - тоді вона має позначку «Вага: не виміряна». Так стається, коли перевірка обсягу не знайшла відгуків, що однозначно говорять про вузьку тему картки, або коли вона не змогла перевірити картку, додану наприкінці аналізу. Замість підставити числа всієї, ширшої категорії - які описували б щось інше, ніж каже заголовок - звіт подає числа категорії з названою сукупністю і прямо визнає, що покриття цієї теми не виміряв. Таку картку слід читати як сигнал для власної перевірки, а не як виміряний висновок. Захід, що спирається на таку картку, друкується без оцінки вартості й без високого пріоритету - витрата на проблему, масштабу якої звіт не виміряв, не отримує у звіті вартісного діапазону.

Дуже рідко графічну частину документа не вдається скласти - за незвично довгої назви або незвичного набору даних. Тоді звіт виходить у простому вигляді: повний зміст, усі числа та цитати, без діаграм і кольорових карток. Документ повідомляє про це в першому абзаці та подає адресу, за якою можна попросити повну версію. Ми воліємо віддати звіт без графічної частини, ніж не віддати жодного.

У звіті по мережі картка проблеми зазвичай стосується кількох об’єктів водночас. Біля кожної назви ми тоді подаємо кількість скарг САМЕ ЦЬОГО об’єкта та кількість його відгуків із скаргами: запис «Вілла Гирни 13 з 84» означає, що тринадцять із вісімдесяти чотирьох відгуків із скаргами цього об’єкта стосуються теми картки. Порядок у цьому рядку визначає частка, а не сама кількість - менший об’єкт іноді має менше скарг, а відсотком виявляється найгіршим, і тоді стоїть першим. Розклад з’являється лише тоді, коли сума частин дорівнює числу під карткою і коли його можна обчислити для кожного названого об’єкта; в інших випадках картка подає одне спільне число, яке не слід приписувати кожному об’єкту окремо.

Перелік об’єктів біля картки - рядок «Стосується» - випливає з доказів, а не лише з твердження моделі. Якщо перевірка обсягу не знайшла в названого об’єкта жодного відгуку про тему картки, його назва зникає з цього переліку; числа картки від цього не змінюються, бо цей об’єкт нічого до них не додавав. Виняток: об’єкт, який опис картки згадує за назвою, залишається в переліку, і картка тоді подає одне спільне число без розкладу. Відсутність об’єкта в переліку не означає, що проблеми в ньому немає - лише те, що у відгуках, охоплених звітом, ми не знайшли цьому підтвердження. Картка, додана перевіркою покриття сфер, тобто тоді, коли сфера з видимою проблемою не отримала власної картки, рахує скарги лише в тих об’єктах, які сама називає, а не в усій мережі.

Рекомендації у звіті постають виключно з відгуків і не знають ваших витрат, графіків, договорів чи даних про бронювання. Це припущення для перевірки, а не висновок операційного аудиту: звіт може показати, скільки клієнтів і відколи пишуть про певну проблему, але не знає, чи причина лежить там, куди він вказує, і чи виправлення вміщається у ваші витрати. Перевірте їх у себе перед кадровим, ціновим, операційним або інвестиційним рішенням.

Рекомендація має стояти під карткою, яка дає підставу діяти. Картку зі статусом «Спостерігати» - сигнал нижче порога обсягу, частки або свіжості - звіт показує з її числами, але рекомендації під нею не друкує: він не може в одному місці казати спостерігати і казати витрачати. Те саме стосується рекомендації, яка не вказує на жодну картку, інцидент чи історичну тему цього документа - вона випадає зі звіту замість того, щоб отримати застереження. Виняток - рекомендація, явно позначена як підтримувальна, у звіті без поточних слабких сторін. Виміряно на 586 збережених звітах (22 вересня 2026 р.): правило знімає 1328 із 2785 рекомендацій, з яких 889 стояли під картками «Спостерігати»; у 126 звітах не залишається жодної рекомендації, і документ повідомляє про це в примітці про метод. Більшість із них - звіти до 4 серпня 2026 р., коли рекомендації ще не мусили вказувати на картку: серед звітів від цього дня без рекомендацій лишаються 14 зі 184. Примітка називає, скільки рекомендацій випало, а коли випали всі - розділ рекомендацій лишається в документі з одним реченням, яке це каже, замість зникнути. Позначка «підтримання» не рятує рекомендацію, що вказує на картку, якої в документі немає.

Відгуки, позначені для перевірки

Окрім змісту, ми перевіряємо одну річ за календарем: чи не з’явилися відгуки неприродним скупченням. Історію компанії ділимо на неперетинні двотижневі вікна й рахуємо, скільки відгуків припадає на кожне з них. Поріг не є однією цифрою для всіх - визначаємо його окремо для кожної компанії з розподілу, підігнаного до її власної історії, так щоб звичайні коливання потоку перетинали його рідко. Скупчення рахуємо окремо у двох рядах низьких оцінок - в самих однозіркових відгуках і в однозіркових разом із двозірковими - бо скупчення найнижчих оцінок означає інше, ніж звичайний гірший тиждень. Для половини компаній нашого набору поріг випадає на трьох таких відгуках за два тижні, а в компанії з густішим потоком буває майже вчетверо вищим. Оцінки на три та чотири зірки до цього розрахунку не входять: ми виміряли це на всьому нашому наборі, і їхня присутність майже вдвічі збільшувала кількість хибних вказівок, не покращуючи виявлення справжніх скупчень. У більшості досліджених компаній сам розрахунок дав би ще нижчий поріг - але нижче трьох відгуків ми не спускаємося, бо два відгуки за два тижні - це звичайний тиждень, а не закономірність. Перевірка не відбувається, коли історія коротша приблизно за три місяці: з коротшої неможливо визначити те, що для компанії звичайне. Від 6 вересня 2026 р. перевірка виконується під час кожної синхронізації відгуків, а її результат видно в панелі компанії на окремій вкладці - разом із зазначенням, яких відгуків вона стосується. Генерувати звіт для цього не потрібно.

Саме скупчення нічого не вирішує і не є достатнім для позначення відгуку. Воно передається моделі як непряма ознака, а модель може позначити відгук лише тоді, коли знайде щонайменше дві незалежні підстави; за сумніву вона не позначає. Різка, але конкретна та достовірна критика справжнього візиту не є підставою для позначення.

Позначення - це інформація, а не вирок. Ми не стверджуємо, що відгук неправдивий, і не оцінюємо особу, яка його написала. Позначені відгуки ЗАЛИШАЮТЬСЯ в усіх числах звіту - у середній оцінці, у розподілі зірок і в частках настрою - саме тому, що позначення є сигналом до перевірки, а не рішенням. Чи порушує відгук правила Карт Google, вирішує виключно Google.

Ми не виявляємо всіх скоординованих дій і говоримо це прямо. Перевірка охоплює ОБИДВІ родини відгуків - і низькі, і п'ятизіркові - бо про неприродність свідчить ритм, у якому відгуки надходять, а не те, чи вони приємні. Проте два списки в цій послузі мають різний обсяг, і цю різницю варто назвати: список скупчень у панелі охоплює виключно оцінки 1 і 2 зірки, бо саме на них ми рахуємо скупчення, а список позначених відгуків у самому звіті - оцінки від 1 до 4 зірок. У самому Дослідженні позначеним періодом може бути виключно період оцінок 1-2 зірки: нетипового напливу похвал ми там не позначаємо як період, бо з нього для вас не випливає жодної дії - п'ятизіркових відгуків ми не подаємо. Проте ми й далі їх рахуємо, і це важить у зворотний бік: якщо водночас надійшло також більше решти оцінок, період скарг пояснюється звичайним рухом у закладі, і кандидатів з нього ми не вказуємо. Похвал на вашому власному профілі ми не оскаржуємо: повідомляємо про них окремо, не вказуючи конкретних відгуків, бо Google карає компанії за куплені відгуки й тоді, коли їх замовив хтось інший. Гірше бачимо також дію, розтягнуту в часі: скупчення, розтягнуте на кілька вікон, підіймає те, що для компанії звичайне, і через це частково в ньому ховається. Тому відсутність позначення не означає, що нічого не сталося. Від 8 вересня 2026 р. сама перевірка розподілу відгуків у часі є окремим платним Дослідженням скупчень відгуків - його можна замовити без створення облікового запису або докупити до одноразового звіту. У Сервісі ця послуга подається під назвою «Перевірка відгуків за правилами Google». Результатом Дослідження є сторінка з переліком позначених періодів і відгуків, які до них належать; звіт подає з цього лише кількість періодів. У Дослідженні текст кожного відгуку про заклад - незалежно від кількості зірок і без жодного обмеження їхньої кількості - додатково читає мовна модель і вирішує лише одне: чи сам вислів порушує правила публікації вмісту, що діють у Google Maps - наприклад містить нецензурну лексику, рекламу або напад на конкретну особу. Сама кількість зірок не кваліфікує жодного відгуку до переліку - це робить лише його текст. Одне обмеження діє у зворотний бік: відгуків із оцінкою п'ять зірок до переліку для скарги ми НЕ додаємо, навіть якщо вони порушують правила вмісту. Не радимо на них скаржитися: видалення похвали знизило б вашу оцінку, тобто діяло б проти мети, задля якої ви замовили цю послугу. Ми все одно їх читаємо, щоб добір не йшов за самою негативністю. Кожен відгук модель читає двічі й незалежно, а до переліку потрапляє порушення, вказане в будь-якому з двох прочитань - у вимірюванні одне прочитання пропускало від кількох до тридцяти відсотків порушень, які знаходило друге (у середньому приблизно кожне шосте). Нецензурні слова додатково пильнує словник у нашому коді: якщо жодне з двох прочитань моделі не вказало лайливого слова, яке стоїть у тексті, відгук усе одно потрапляє до переліку з цим словом як цитатою - у вимірюванні модель пропускала майже два з п'яти таких слів. Відгук із позначеного періоду без власного порушення ми показуємо як кандидата на рішення Клієнта лише тоді, коли період не пояснюється загальним рухом закладу (у той самий час не зросла кількість інших оцінок) і текст не містить конкретики відвідування; рішення належить Клієнтові. Обґрунтування скарги постає у два етапи. Факти - категорію порушення, дослівний фрагмент відгуку, дати й числа періоду та цитату правила Google Maps - визначає наш код. Мовна модель складає з них речення. Результат потім перевіряється автоматично: текст, у якому з'явиться число, цитата або твердження поза набором фактів, ми відкидаємо і підставляємо готовий шаблон. Речення, що оцінює правдивість відгуку чи його автора, не напише ні модель, ні код - Google вирішує про порушення правила, а не про правдивість вислову. У вимірюванні на всьому нашому масиві (8 вересня 2026 р., понад дванадцять тисяч відгуків із текстом) таке порушення мав менш ніж один відгук зі ста, тож перелік буває коротким або порожнім.

Чого цей звіт не робить

Він не охоплює відгуків із сервісів, інших ніж Google Карти, а також подій, про які клієнти не написали.

Він не є юридичною, податковою чи інвестиційною порадою. Оцінки вартості є орієнтовними і слугують для визначення черговості робіт, а не для замовлення послуг без власного розгляду.

Участь штучного інтелекту

Описовий зміст звіту - текст, описи проблем і запропоновані дії - постає за участю мовної моделі. Ми повідомляємо про це в кожному звіті.

Файли PDF додатково несуть позначення, зчитуване програмами, яке вказує, що зміст створено системою штучного інтелекту. Це відповідає статті 50(2) Регламенту (ЄС) 2024/1689 - акта Європейського Союзу про штучний інтелект.