Обзор

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

Предложения

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

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

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

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

Предлагает реализацию

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

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

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

Лента предложений должна быть загружена на SFTP-сервер Generic назначения. Следуйте инструкциям в руководстве по использованию SFTP-сервера общего назначения и укажите 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 .
  • Партнеры должны предоставить по 2 копии каждого из этих предложений, чтобы охватить сценарии, в которых они функционируют как базовые предложения и дополнительные предложения. Копию дополнительного предложения можно затем установить для нескольких ресторанов, используя либо 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% по кредитной карте следует отправить в двух экземплярах.
    • Один экземпляр должен быть помечен тегом OFFER_CATEGORY_BASE_OFFER с указанием данных PaymentInstrument . Значение ValidityPeriod должно исключать обеденные часы в будние дни, когда действует скидка 10% на обед.
    • Один экземпляр должен быть помечен тегом OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER и содержать подробную информацию PaymentInstrument .
  • Все остальные предложения по оплате в этом ресторане должны быть помечены тегом OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER .

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

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

• Интеграция будет сначала разработана в тестовой среде (Sandbox). Вам следует использовать экспорт производственных данных (или даже непосредственно производственные данные) в тестовую среду Google. Это поможет гарантировать, что ваша разработка учтет все граничные случаи, и позволит Google оценить качество данных и оказать вам более эффективную помощь на основе вашей модели данных.
• После того, как вы начнете регулярно загружать полные ежедневные данные о продавцах, услугах и предложениях в тестовую среду Google, команда 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, like Gecko; Google-Offers ) Chrome/104.0.5112.101 Safari/537.36
• Вы также можете проверить, поступают ли запросы от Google, используя обратное разрешение DNS, как рекомендовано в статье «Проверка Googlebot и других поисковых роботов Google» . В нашем конкретном случае разрешение обратного DNS соответствует следующему шаблону: google-proxy-***-***-***-***.google.com .

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

Кэширование

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