Обзор

Партнеры, участвующие в интеграции предложений, должны завершить настройку учётной записи для этапа интеграции на уровне продавца или организации (пилотный проект) до начала работы. Реализация, тестирование и запуск интеграции предложений подробно описаны в этом руководстве. Перед началом интеграции ознакомьтесь с этим обзором и правилами в отношении предложений .

Предложения

Интеграция предложений позволяет передавать структурированную информацию о промоакциях и скидках продавцов, действующих на определённые услуги в определённое время. Предложения включают в себя само предложение (процентная скидка, скидка в долларах США и т. д.), периоды действия (определённое время, дни недели и т. д.) и условия использования (предложение можно использовать только на определённые услуги), а также сложные комбинации ограничений.

Примеры предложений:

• Скидки на закуски по средам и четвергам в декабре с 12:00 до 17:00.
• Купите один десерт и получите второй бесплатно на ужин в честь Дня матери с 18:00 до 22:00
• Скидка 5 долларов на основное блюдо для бранча каждое воскресенье с 10:00 до 14:00
• Скидка 10% при личном обращении, которую можно комбинировать со скидкой 5% для премиум-подписчиков и скидкой 5%, если пользователь платит через ваше приложение.

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

Реализация предложений

Интеграция предложений состоит из двух каналов, которые будут загружаться ежедневно или с частотой, обеспечивающей высокую точность (что означает снижение вероятности устаревания):

• Торговцы кормят
• Предложения по ленте

Загрузка ленты

Фид предложений должен быть загружен на SFTP-сервер Generic Feed. Следуйте инструкциям в руководстве «Как использовать SFTP-сервер Generic Feed» и используйте name google.offer в файле дескриптора.

Частота загрузки

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

Данные появятся в Google через несколько часов.

Категоризация предложений

• OFFER_CATEGORY_BASE_OFFER : Предложения, которые можно использовать отдельно, не объединяя с другими предложениями. Сюда входят:
  • Фиксированные скидки на весь счет (например, скидка 20%)
  • Предложения по подписке (например, бесплатный десерт при подписке)
  • Предложения по оплате в случаях, когда нет других базовых предложений для ресторана
• Дополнительные предложения: предложения, для которых требуется базовое предложение. К ним относятся:
  • OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER (например, дополнительная скидка 10% при использовании определенной кредитной карты)
  • OFFER_CATEGORY_ADD_ON_COUPON_OFFER (например, бесплатный напиток с определенным кодом купона)
  • OFFER_CATEGORY_ADD_ON_SUBSCRIPTION_OFFER (например, дополнительная скидка 10% для подписчиков)

Другие соображения:

• Если у ресторана нет базового предложения, дополнительные предложения отображаться не будут. Если базового предложения нет, любое предложение по оплате, подписке или купону, которое можно использовать без добавления к другому предложению, должно быть помечено как OFFER_CATEGORY_BASE_OFFER .
  • В зависимости от типа необходимо установить соответствующие данные для PaymentInstrument , Subscription или Coupon .
  • Партнеры должны предоставить две копии каждого из этих предложений, чтобы охватить сценарии, в которых они действуют как базовые предложения, так и предложения-дополнения. Копию предложения-дополнения можно затем настроить для нескольких ресторанов, используя entity_ids или add_on_offer_applicable_to_all_entities .
• Если в ресторане имеется несколько базовых предложений, которые можно суммировать, все базовые предложения следует пометить как OFFER_CATEGORY_BASE_OFFER , а базовые предложения, которые являются предложениями по оплате, подписке или купонам, следует отправлять дополнительно как соответствующий тип дополнительного предложения.
• ValidityPeriod следует использовать для активации дополнительных предложений в качестве базовых предложений только в случае отсутствия активного базового предложения.

Примеры сценариев:

• Ресторан предлагает скидку 5% при оплате определенной кредитной картой и бесплатный напиток по определенному промокоду.

  • Предложение о скидке 5% по кредитной карте должно быть отправлено в двух экземплярах, один с тегом OFFER_CATEGORY_BASE_OFFER и один с тегом OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER с указанием данных PaymentInstrument .
  • Предложение о бесплатном напитке с купоном следует отправлять как OFFER_CATEGORY_ADD_ON_COUPON_OFFER с указанием данных Coupon .

• Ресторан предлагает скидку 10% при личном посещении и скидку 5% при оплате определенной кредитной картой, причем обе скидки можно комбинировать.

  • Предложение со скидкой 10% при личном посещении должно быть помечено как OFFER_CATEGORY_BASE_OFFER .
  • Предложение о скидке 5% по кредитной карте должно иметь 2 копии, одна из которых должна быть помечена как OFFER_CATEGORY_BASE_OFFER , а другая — как OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER .

• Ресторан предлагает скидку 10% только на обед по будням и скидку 5% в любое время при оплате определенной кредитной картой.

  • Для предложения скидки 10% необходимо установить период действия ValidityPeriod так, чтобы он действовал только в обеденное время в ресторане по будням.
  • Предложение о скидке 5% по кредитной карте должно быть отправлено в 2 экземплярах.
    • Один экземпляр должен быть помечен тегом OFFER_CATEGORY_BASE_OFFER с указанием PaymentInstrument . ValidityPeriod следует установить так, чтобы исключить обеденные часы по будням, когда действует скидка 10% на обед.
    • Один экземпляр должен быть помечен как OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER с указанием данных PaymentInstrument .
  • Все остальные предложения по оплате для этого ресторана должны быть помечены как OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER .

Процесс разработки и запуска

На протяжении всей интеграции партнёрский портал будет предоставлять вам информацию и отзывы о вашей разработке. Процесс разработки будет проходить следующим образом:

• Интеграция будет сначала разработана в среде Sandbox. Вам следует использовать экспорт производственной среды (или даже непосредственно производственных данных) в среду Google Sandbox. Это гарантирует, что ваша разработка учитывает все пограничные случаи, а Google сможет оценить качество данных и более эффективно помогать вам на основе вашей модели данных.
• После того, как вы начнете регулярно и ежедневно загружать полный фид «Торговцы, Услуги и Сделки» в среду Google Sandbox, команда Google оценит ваши фиды. После одобрения команды Google вы сможете запустить свой код в эксплуатацию и начать отправлять данные в рабочую среду Google.
• После полного тестирования интеграции с продакшеном команда Google также проведёт тестирование. После завершения тестирования ваша интеграция будет запущена.

Мониторинг

Чтобы обеспечить пользователям комфортный опыт, Google будет проверять предлагаемые предложения на предмет их действительности, корректности и соответствия нашим критериям до и после запуска. Для этого Google будет использовать сочетание ручной и автоматизированной проверки. Результаты этих проверок будут доступны на панели инструментов предложений в Центре действий (только в рабочей версии). Результаты этого мониторинга могут быть использованы для влияния на рейтинг предложений.

Убедитесь, что загрузка страницы со всеми предложениями занимает не более 5 секунд , в противном случае это будет считаться ошибкой и будет помечено как Bad link .

Автоматизированные проверки (сканеры)

Команда Google по качеству внедряет сканеры. Сканерами называют скрипты, которые автоматизируют веб-браузер для выполнения некоторых кликов и извлечения информации о предложениях исключительно для целей проверки качества .

Количество запросов

Например, если мы решили отправлять 5000 чеков в день, это означает, что 5000 раз в день ( равномерно распределенных в течение дня, то есть примерно один раз каждые 17 секунд ) наш сканер выполнит все следующие действия, которые выполнил бы обычный пользователь:

• Откройте поиск Google и нажмите на партнерскую ссылку.
• Ознакомьтесь с информацией о предложении.
• Если предложение требует бронирования, оно будет передано в процесс бронирования для подтверждения доступности предложения в указанное время (бронирование не будет выполнено).

Обнаружение веб-скрейперов

Чтобы избежать блокировки веб-скрейпера (что может привести к выводу о недоступности предложений), убедитесь, что ваша система разрешает нашему веб-скрейперу постоянно запрашивать информацию на вашей странице. Чтобы идентифицировать наш веб-скрейпер:

• User-Agent веб-скрапера будет содержать строку « Google-Offers »:
  • Пример: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, как Gecko; Google-Offers ) Chrome/104.0.5112.101 Safari/537.36
• Вы также можете проверить, исходят ли вызовы от Google, используя обратный DNS, как рекомендовано в разделе «Проверка робота Googlebot и других поисковых роботов Google» . В нашем конкретном случае обратное разрешение DNS происходит по следующему шаблону: google-proxy-***-***-***-***.google.com .

Техническое поведение

Кэширование

Для снижения нагрузки на сайт-партнёр наши роботы, как правило, настроены на обработку всех стандартных HTTP-заголовков кэширования, присутствующих в ответе. Это означает, что для правильно настроенных сайтов мы избегаем повторной загрузки редко изменяющегося контента (например, библиотек JavaScript). Подробнее о реализации кэширования см. в этой документации по HTTP-кэшированию .