Store Sales в Google Ads 2026: как отдавать офлайн-покупки через Data Manager API

У магазина с офлайн-точками половина выручки не существует для Google Ads. Человек кликнул по объявлению в телефоне, приехал в торговый зал через три дня и заплатил картой на кассе. В кабинете это выглядит как клик без конверсии, Smart Bidding считает такой трафик бесполезным и постепенно уводит от него бюджет. Проблема не в алгоритме — ему просто не отдали половину результата. Механизм, который это чинит, называется Store Sales в Google Ads.

Способов вернуть офлайн-выручку в кабинет три, и их постоянно путают: визиты в магазин, импорт офлайн-конверсий по GCLID и Store Sales в Google Ads. Это три разных механизма с разными требованиями к данным и разной точностью. Ниже — что именно делает store sales, что изменилось в 2026 году после переезда загрузок в Data Manager API, кому эта история вообще доступна и как её внедрить без месяца переписок с поддержкой.

Три способа завести офлайн в Google Ads — и чем они отличаются

Прежде чем что-то настраивать, стоит понять, какой из трёх механизмов решает вашу задачу. Они не взаимозаменяемы, и попытка «настроить всё сразу» чаще всего заканчивается двойным учётом конверсий.

Механизм	Что измеряет	Что нужно от вас	Точность
Визиты в магазин (store visits)	Факт прихода в точку после клика или показа	Ничего, кроме связанного профиля компании и достаточного объёма данных	Смоделированная оценка, не список конкретных людей
Импорт офлайн-конверсий	Сделку, привязанную к конкретному клику	GCLID/GBRAID/WBRAID, сохранённый в CRM в момент лида	Точная привязка к клику, но только там, где идентификатор клика удалось сохранить
Store sales	Покупку в офлайне, сопоставленную по данным покупателя	Хешированные email/телефон/адрес из чеков и программы лояльности	Сопоставление части транзакций, масштабируемое на весь чековый поток

Ключевая разница между вторым и третьим пунктом: импорт офлайн-конверсий требует идентификатор клика, который у офлайн-покупки в подавляющем большинстве случаев взять неоткуда — человек не заполнял форму, а просто пришёл на кассу. Store sales не требует GCLID вообще: он берёт данные покупателя из чека, хеширует их и пытается сопоставить с аккаунтом Google, который видел рекламу. Именно поэтому store sales — единственный вариант для ритейла с массовым офлайн-чеком, а импорт офлайн-конверсий остаётся инструментом лидогенерации.

Если вы ещё не разобрались с базой, начните не отсюда, а с двух соседних материалов: импорт офлайн-конверсий в Google Ads закрывает лидген-сценарий с CRM, а визиты в магазин объясняют, откуда берётся смоделированная офлайн-статистика, которую многие ошибочно принимают за реальные продажи.

Как работает сопоставление в store sales

Механика простая на словах и требовательная в деталях. Вы отдаёте Google список транзакций: когда была покупка, на какую сумму, в какой валюте, в какой точке, и какие данные покупателя с ней связаны. Данные покупателя перед отправкой превращаются в хеш SHA-256 — до отправки, на вашей стороне. Google хеширует свою базу тем же способом и ищет совпадения. Совпало — транзакция привязывается к рекламному взаимодействию и попадает в отчёты как конверсия с реальной суммой.

Какие идентификаторы работают

• Email — самый результативный идентификатор. Перед хешированием email нормализуется: убираются пробелы, всё приводится к нижнему регистру.
• Телефон — работает только в формате E.164 (код страны, плюс, без пробелов и скобок), затем хешируется.
• Имя, фамилия, почтовый индекс, код страны — идут комплектом, поодиночке смысла не имеют. Имя и фамилия хешируются, индекс и страна передаются открытым текстом.

Практический вывод: чем больше идентификаторов на одну транзакцию, тем выше шанс сопоставления. Чек, где есть и email, и телефон, матчится заметно лучше, чем чек с одним только индексом и фамилией. Ваш процент сопоставления — прямая функция от того, насколько дисциплинированно касса и программа лояльности собирают контакты.

Confidential matching и шифрование

С 2025 года Google продвигает confidential matching — сопоставление внутри доверенной среды выполнения, где ни одна из сторон не получает доступ к исходным данным другой. В Data Manager API этот режим поддерживается вместе с дополнительным шифрованием идентификаторов поверх хеширования. Для вас это в первую очередь аргумент в разговоре с юристами и службой безопасности: данные покупателей не «отправляются в Google» в привычном смысле, а участвуют в сопоставлении в зашифрованном виде.

При этом юридическая база обработки — по-прежнему ваша зона ответственности. Согласие на передачу данных третьей стороне для рекламных целей должно быть получено, и здесь стоит перечитать разбор Consent Mode v2 и приватности в рекламе: логика согласий у офлайн-загрузок та же, что у веб-сигнала, просто точка сбора другая.

Что изменилось в 2026 году: store sales переехал в Data Manager API

Главное изменение года — инфраструктурное. Раньше офлайн-загрузки жили в Google Ads API через связку сервисов офлайн-заданий: создать job, добавить операции, запустить, дождаться, разобрать ошибки. Это была многошаговая оркестрация, где каждый шаг мог упасть по своей причине.

В мае 2026 года версия Data Manager API v1.6 принесла поддержку store sales в принципиально другой форме: одиночный запрос приёма событий вместо многошагового задания. Вместе с этим появились поля, которых раньше не хватало:

• event_location с store_id — транзакция привязывается к конкретной торговой точке, а не к аккаунту целиком;
• расширенный ресурс Item — merchant_id, merchant_feed_label, merchant_feed_language_code, conversion_value, пользовательские переменные;
• coupon_codes в корзине — промокод из чека едет вместе с транзакцией;
• third_party_user_data — только для партнёров по данным, обычному рекламодателю это поле недоступно.

Второй слой изменений пришёлся на сентябрь 2026 года: Data Manager получил прямую интеграцию с Google Analytics и Display & Video 360, универсальный API на базе стандартов IAB Tech Lab и встроенную диагностику, которая подсвечивает проблемы с данными до того, как они испортят кампании. Общая логика Google здесь читается однозначно: все загрузки первичных данных сводятся в один контур. Если вы ещё не смотрели на этот контур целиком, начните с обзора Data Manager и данных первой стороны — store sales там один из источников, а не отдельная вселенная.

Отдельно отметим: в том же цикле обновлений появилась метрика, которая показывает, сколько дополнительных конверсий вы вернули за счёт настройки первичных данных. Как её читать и почему она обычно оказывается скромнее рекламных обещаний, разобрано в материале про Data Strength в Google Ads.

Кому Store Sales в Google Ads вообще доступен

Здесь стоит сразу снять лишние ожидания. Приём store sales ограничен аккаунтами из белого списка, и Google прямо называет категории: ритейл, рестораны и автопроизводители вместе с региональными дилерскими группами. Это не «включается галочкой в интерфейсе» — нужны подтверждённая категория бизнеса, соответствие требованиям к данным и прохождение проверки.

Что это значит на практике:

• у интернет-магазина без физических точек store sales не появится — и не нужен, там достаточно веб-конверсий и расширенных конверсий;
• у сервисного бизнеса с длинным циклом сделки правильный путь — импорт офлайн-конверсий из CRM, а не store sales;
• у аффилиатных и медиабаинговых команд, которые гонят трафик на чужие офферы, store sales не появится никогда: транзакции происходят не у вас, идентификаторов покупателей у вас нет, а рекламодатель отдаёт вам постбек, а не чеки.

Последний пункт важно проговорить честно, потому что вокруг офлайн-измерений много маркетингового шума. Если ваша модель — закупка трафика под партнёрские офферы, ваш инструмент измерения это трекер и постбеки, а рычаги роста лежат в другом месте: качество аккаунта, структура кампаний, скорость прохождения модерации. С инфраструктурной частью — агентскими аккаунтами Google Ads и сопровождением запуска — помогает команда PPC Rebels, но измерять офлайн-выручку чужого рекламодателя вы всё равно не сможете.

Как подготовить данные: схема транзакции

Девять из десяти проваленных внедрений ломаются не на API, а на данных. Минимальный набор полей, который должен уметь отдавать ваш бэкенд или BI:

• Идентификаторы покупателя — email и/или телефон, нормализованные и хешированные; по возможности комплект «имя + фамилия + индекс + страна» как запасной канал сопоставления.
• Время транзакции — с явным указанием часового пояса. Это отдельная ловушка: часовой пояс рекламного аккаунта не меняется никогда, и если ваш склад отдаёт время в локальной зоне магазина, отчёты поедут. Подробно про это — в разборе часового пояса и валюты аккаунта Google Ads.
• Сумма и валюта — сумма в валюте чека с явным кодом валюты, а не «уже пересчитанная» в валюту аккаунта.
• Идентификатор транзакции — сквозной ключ для дедупликации. Без него повторная загрузка того же дня удвоит выручку.
• store_id — если хотите видеть разрез по точкам, а не общий котёл.
• Состав корзины — если у вас есть товарный фид и вы хотите связать офлайн-покупку с конкретными товарами.

Три решения, которые нужно принять до первой загрузки

1. Что считать конверсией. Чек целиком или отдельные позиции? Решение влияет на всю дальнейшую отчётность и меняется потом только болезненно.
2. Что делать с возвратами. Офлайн-возврат — это не «минус конверсия» в отчёте, это отдельная механика корректировок. Как её выстроить, разобрано в материале про корректировки конверсий. Если возвраты игнорировать, Smart Bidding будет оптимизироваться на выручку, которой не было.
3. Как избежать двойного учёта. Если человек оформил онлайн-заказ с самовывозом, эта покупка может приехать и как веб-конверсия, и как офлайн-транзакция. Нужен фильтр на стороне выгрузки: заказы с онлайн-оплатой в store sales не отправляются.

Пошаговое внедрение

1. Подтвердите доступ. До любой разработки выясните у своего представителя Google, попадает ли аккаунт в допустимую категорию. Наличие доступа к API не равно праву загружать store sales.
2. Соберите инвентарь источников. Кассовая система, программа лояльности, эквайринг, ERP — выпишите, где именно лежат чеки и контакты, и кто владеет каждой системой.
3. Согласуйте юридическую базу. Согласие покупателей, политика обработки, срок хранения. Этот шаг длиннее технического — закладывайте недели, а не дни.
4. Спроектируйте схему. Сопоставьте свои поля с полями Data Manager API: транзакция, идентификаторы, локация, товары, валюта, время.
5. Настройте нормализацию и хеширование на своей стороне. Хеш считается у вас, сырые данные никуда не уезжают.
6. Сделайте тестовую загрузку небольшого среза — например, за одну неделю по одной точке — и проверьте, что сопоставления появляются, а суммы совпадают с кассовым отчётом.
7. Поставьте регулярность. Практичная частота — ежедневно или еженедельно. Загрузка «раз в квартал за квартал» технически пройдёт, но данные придут слишком поздно, чтобы влиять на обучение стратегий.
8. Включите мониторинг. Логи ошибок, счётчик отправленных и принятых транзакций, алерт на падение объёма загрузки. Молчаливо сломавшийся пайплайн — самая дорогая поломка в измерениях, потому что её замечают через месяц.

Как читать результат

Первое, на что смотрят — процент сопоставления. Абсолютных бенчмарков здесь не существует: он зависит от того, как вы собираете контакты. Ориентир, который стоит держать в голове: если сопоставляется меньше пятой части транзакций, проблема почти наверняка в качестве идентификаторов, а не в Google. Первым делом проверяйте нормализацию телефонов и долю чеков без email.

Второе — окно загрузки. Транзакции, приехавшие слишком поздно, теряют ценность для оптимизации, даже если формально попадают в отчёт. Именно поэтому редкая пакетная загрузка обесценивает всю затею.

Третье — влияние на ставки. Store sales имеет смысл включать в цель кампании только тогда, когда поток стабилен. Разовая большая загрузка на обученной кампании — это резкий скачок в данных, на который стратегия отреагирует не так, как вам хотелось. Если планируете такое включение, посмотрите, как вообще ведут себя стратегии ставок Google Ads при изменении состава конверсий: правило «не менять цель и данные одновременно» здесь работает так же.

Офлайн-данные меняют не отчёт, а решения алгоритма. Пока поток нестабилен, честнее держать store sales как наблюдательную конверсию и не отдавать в него управление ставками.

Сколько это стоит по ресурсам и срокам

Store sales — не задача для одного маркетолога с вечером свободного времени. Реалистичная сборка команды выглядит так: разработчик или аналитик, который поднимает выгрузку и пишет интеграцию; владелец кассовой системы, который подтверждает состав полей; юрист или DPO, который согласует основание обработки; и сам специалист по рекламе, который принимает решения о том, что считать конверсией.

По срокам самый длинный этап — не код, а согласования. Техническая часть в простом случае занимает недели, юридическая проверка и подтверждение доступа могут растянуться на месяц-полтора, особенно если данные лежат в нескольких системах с разными владельцами. Планировать запуск «к следующей распродаже» имеет смысл только тогда, когда до неё остаётся хотя бы квартал.

Отдельная статья затрат — поддержка. Пайплайн придётся сопровождать: обновления кассового ПО, смена схемы выгрузки, ротация ключей доступа. Если в компании некому взять это на регулярной основе, честнее не начинать: сломавшаяся загрузка хуже её отсутствия, потому что создаёт иллюзию полной картины при реально неполных данных.

Что проверить через месяц после запуска

• Совпадает ли суммарная офлайн-выручка в кабинете с кассовым отчётом за тот же период — с поправкой на долю сопоставления.
• Не выросла ли доля отклонённых транзакций после очередного релиза кассового ПО.
• Стабильна ли задержка между покупкой и появлением конверсии в отчёте.
• Не изменилось ли поведение стратегий ставок после включения офлайн-конверсии в цель — и если изменилось, в ту ли сторону.

Типичные ошибки и чем они заканчиваются

• Нет идентификатора транзакции. Повторная загрузка дублирует выручку, ROAS в отчёте растёт, реальных денег больше не становится, стратегия начинает переплачивать за трафик.
• Время без часового пояса. Транзакции размазываются по соседним суткам, дневная аналитика и расписание показов перестают биться с реальностью.
• Валюта пересчитана заранее. Двойная конвертация, расхождение с бухгалтерией, невозможность свести отчёты.
• Онлайн-заказы едут в store sales. Двойной учёт, завышенная офлайн-эффективность, неправильное перераспределение бюджета.
• Возвраты не передаются. Алгоритм оптимизируется на аннулированные сделки — особенно больно в категориях с высокой долей возвратов.
• Пайплайн запустили и забыли. Смена версии кассового ПО ломает выгрузку, никто не замечает, через шесть недель кампании уже переучились на неполных данных.

Когда store sales не нужен

Если офлайн-выручка составляет небольшую долю оборота, а чеки почти не содержат контактов, затраты на внедрение не окупятся. В этом случае разумнее выжать максимум из того, что уже доступно: корректно собрать веб-сигнал через серверный трекинг sGTM, подключить расширенные конверсии и навести порядок в аудиториях. Кстати, о втором: у большинства аккаунтов данные первой стороны страдают ровно там, где их проще всего поправить — в списках. Разбор порогов и сроков участия есть в материале про менеджер аудиторий Google Ads.

Если же вы только выстраиваете систему измерений и не уверены, в каком порядке закрывать пробелы, логика приоритетов разобрана в гайде по Google Ads, а разбор конкретного аккаунта с настройкой конверсий можно вынести в формат обучения с практикой.

FAQ

Чем store sales отличается от импорта офлайн-конверсий?

Импорт офлайн-конверсий привязывает сделку к конкретному клику по идентификатору GCLID, сохранённому в CRM. Store sales не использует идентификатор клика вообще — он сопоставляет транзакцию по хешированным данным покупателя. Первый механизм для лидогенерации, второй для розничного чека.

Нужен ли GCLID для store sales?

Нет. В этом и смысл механизма: офлайн-покупатель никогда не оставлял вам идентификатор клика, поэтому сопоставление идёт по email, телефону или комплекту «имя + индекс + страна».

Кому доступна загрузка store sales?

Аккаунтам из белого списка в категориях ритейла, ресторанов и автопроизводителей с дилерскими группами. Доступ подтверждается до начала разработки, наличие технического доступа к API его не заменяет.

Какой процент сопоставления считать нормальным?

Универсального норматива нет — он определяется тем, как вы собираете контакты на кассе. Как ориентир: сопоставление ниже пятой части транзакций почти всегда означает проблему с качеством или нормализацией идентификаторов, а не с алгоритмом Google.

Как часто загружать данные?

Ежедневно или еженедельно. Редкие пакетные загрузки формально пройдут, но приедут слишком поздно, чтобы влиять на обучение стратегий, и ценность внедрения обнулится.

Что произошло со store sales в Data Manager API v1.6?

Приём транзакций перешёл на единый запрос событий вместо многошагового офлайн-задания, появилась привязка к торговой точке через store_id, расширился набор полей товара и добавились промокоды в составе корзины.

Как избежать двойного учёта с онлайн-заказами?

Фильтровать на стороне выгрузки: заказы, оплаченные онлайн, в store sales не отправляются, даже если товар был выдан в магазине. Плюс сквозной идентификатор транзакции для дедупликации повторных загрузок.

Как передавать возвраты?

Через механику корректировок конверсий, а не удалением строк из следующей загрузки. Возврат должен отменять ранее засчитанную сумму, иначе стратегия оптимизируется на выручку, которой уже нет.

Безопасно ли отдавать данные покупателей?

Идентификаторы хешируются на вашей стороне до отправки, а сопоставление поддерживает confidential matching и дополнительное шифрование. Но юридическое основание обработки и сбор согласий остаются вашей ответственностью.

Подходит ли store sales для арбитража трафика?

Нет. Транзакции происходят у рекламодателя, а не у вас, доступа к чекам и контактам покупателей у байера нет. Для партнёрских моделей инструмент измерения — трекер с постбеками, а не офлайн-загрузки.

Стоит ли сразу включать store sales в цель кампании?

Нет, если поток данных ещё нестабилен. Разумнее сначала держать конверсию наблюдательной, убедиться в стабильности объёма и сопоставления, и только потом отдавать ей управление ставками.

Смысл store sales не в красивом отчёте, а в том, что алгоритм наконец видит ту половину выручки, ради которой вы и покупали клики. Пока данные приезжают криво или с опозданием, лучше не включать их в оптимизацию вовсе.