Виды запросов по частотности: Виды поисковых запросов: классификация с примерами

Виды поисковых запросов: классификация с примерами

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

Классификация поисковых запросов

1. По частотности

2. По уровню конкуренции

3. По уровню конкуренции и частотности

4. По степени ценности для бизнеса

5. По зависимости от местоположения пользователя

6. По информационной потребности пользователя (интенту)

7 советов по работе с разными типами ключевых слов

Классификация поисковых запросов

1. По частотности

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

По этому признаку запросы делят на:

• высокочастотные (ВЧ),
• среднечастотные (СЧ),
• низкочастотные (НЧ),
• микронизкочастотные (микроНЧ),
• нулевые.

Отнесение запроса к одному из этих типов (кроме нулевых) зависит от тематики и региона. Далее мы приводим средние цифры частотности по России.

Высокочастотные запросы

Состоят из 1-2 слов: «стол», «пластиковое окно», «помада» и т. п.

Количество обращений к ВЧ-фразам зависит от тематики и может колебаться в пределах от 3-5 до 10-20 и более тысяч запросов в месяц.

SEO по ВЧ-запросам сложное, длительное и дорогое, особенно в регионах с многомиллионной аудиторией типа Москвы или Санкт-Петербурга. Для вывода сайта в ТОП по ВЧ нужно работать по всем фронтам:

И все это должно быть лучше, чем у конкурентов.

В поисковой контекстной рекламе этот тип ключей используются ограниченно, поскольку нет понимания, чего именно хочет пользователь (он может вводить фразу «пластиковое окно» с целью заказать его, посмотреть фото, почитать о монтаже и т.д.). Особенно в этом смысле коварны «однословники» («двери», «ноутбук»). Рекламу по ВЧ-запросам заказывают крупные бренды для тотальной экспансии — чтобы не пропустить ни одного потенциального клиента.

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

Среднечастотные запросы

Эти фразы состоят, как правило, из 2-3 слов: «телевизор самсунг 27 дюймов», «тренажер беговой торнео» и т. п.

Их частотность составляет от 500-800 до 2000-3000 запросов в месяц. Запрос содержит намного больше конкретики, чем в случае с ВЧ, а значит легко понять намерение пользователя и привести его на релевантную посадочную страницу. Например, к среднечастотным запросам относятся названия категорий на сайте, разделы и подразделы каталога.

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

Низкочастотные и микронизкочастотные запросы

Их еще называют long tale запросы или запросы с длинным хвостом. Они имеют частотность до 10. НЧ запросы сформулированы максимально конкретно: «заказать круглое пластиковое окно Балашиха», «фото деревянных столов с резьбой» и т. п.

Раньше грамотная SEO-оптимизация страниц под эти ключевые фразы была практически гарантией попадания в ТОП. Теперь из-за развития алгоритмов поисковых систем (обновление Вега от Яндекса и RankBrain от Google) по низко- и микронизкочастотным запросам во многих случаях высоко ранжируются те же авторитетные сайты, что и по ВЧ.

По НЧ выгодно запускать контекстную рекламу на поиске, поскольку достигается высокая кликабельность объявлений и конверсия при минимальной цене клика. Для рекламных кампаний в партнерских сетях подобные запросы не используются.

Привлечь трафик по НЧ? Не проблема! Закажите в системе PromoPult регулярное наполнение сайта полезным для посетителей контентом, «заточенным» под НЧ. Копирайтер напишет тексты под вашу тематику, редактор проверит их, а верстальщик — разместит на вашем сайте.

Нулевые запросы

Это запросы, частотность которых равна нулю. Но не спешите их отбрасывать. Проверьте сезонность спроса. Нулевые запросы часто появляются вследствие периодического падения интереса к продукту. Если это не учесть, то при очередном росте спроса вы упустите клиентов.

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

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

2. По уровню конкуренции

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

• Высококонкурентные (ВК). По ним поисковая выдача «пестрит» авторитетными сайтами с ценным контентом. Оптимизаторы тратят колоссальные ресурсы для получения трафика по ВК-запросам. Молодым сайтам по ВК практически невозможно пробиться в ТОП.
• Среднеконкурентные (СК). Это основная масса коммерческих запросов. Под них оптимизируется большинство сайтов и по ним запускается контекстная реклама.
• Низкоконкурентные (НК). Можно сфокусироваться на оптимизации под НК фразы. С одной стороны, по ним можно быстро продвинуться в ТОП без серьезных вложений. С другой – малое количество конкурентов в большинстве случаев означает несформированный спрос и небольшой трафик, а значит и отдача от продвижения по ним будет минимальной. Если только вы не обладаете инсайдерской информацией о взрывном росте спроса на ваш продукт.

Как понять, к какому типу относятся запросы: ВК, СК или НК? Введите в поиске ключевую фразу и посмотрите на выдачу. По ВК в выдаче все страницы будут релевантными запросу. По СК будет пара «окон», релевантность страниц не такая высокая. А по НК в ТОПе может вообще не быть релевантных страниц.

Для примера сравним выдачу по запросам «купить женские найк» и «купить синего ужа с фиолетовой полоской»:

В первом случае выдача «забита» интернет-магазинами и агрегаторами. Перейдя по любой ссылке, можно купить женские кроссовки Nike. А вот синего ужа с фиолетовой полоской никто не предлагает. Поэтому если бы вы продавали такой товар (и кому-то бы в голову пришло ввести что-то подобное в поиске), то, скорее всего, ваша страница вышла бы в ТОП-1.

Важно понимать, что разделение запросов по уровню конкуренции «в вакууме» не имеет практического смысла. Но эта классификация используется для сопоставления уровня конкуренции с частотностью — и смысл появляется. Об этом далее.

3. По уровню конкуренции и частотности

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

• ВЧ+ВК. Сюда относится основная масса высокочастотников. Продвижение по ним длительное и дорогое.
• ВЧ+СК. Если такие запросы и существуют, то их переход в категорию ВК — лишь вопрос времени.
• ВЧ+НК. Подобных запросов, наверное, не осталось. Их нужно «ловить» в новых тематиках, предугадывать популярность тех или иных фраз в будущем. В этом случае есть шанс в перспективе закрепиться в ТОПе. Примеры: «гироскутеры», «барбершоп» (когда-то они были НЧ/СЧ, но с ростом популярности стали ВЧ).
• СЧ+ВК. Это запросы в популярных коммерческих тематиках. Продвижение по ним сложное, контекстная реклама дорогая.
• СЧ+СК. Сюда относятся удобные с точки зрения продвижения запросы: при относительно небольших затратах генерируется хороший трафик.
• СЧ+НК. Такие запросы еще можно найти, особенно в регионах. Но для этого необходимо хорошо проработать семантику в вашей нише. Результат будет относительно быстрым и недорогим.
• НЧ+ВК. Эти фразы связаны с дорогими и популярными тематиками (оффшоры, криптовалюты, форекс и т. п.). Продвижение по ним требует денег и времени, при этом стоимость трафика высокая.
• НЧ+СК. Это могут быть фразы, связанные с популярными товарами в разных сферах (электроника, парфюмерия и т. п.). Продвигаться по ним непросто, но при правильной оптимизации можно добиться результата.
• НЧ+НК. Это основная масса НЧ запросов. Зачастую достаточно просто создать посадочную страницу и оптимизировать ее под такой запрос, чтобы попасть в ТОП. По таким ключам вы получаете фактически бесплатный трафик.

Сбор семантического ядра — кропотливая работа. Ускорьте ее — используйте профессиональный парсер Wordstat. Сбор фраз сразу в нескольких регионах, поддерживаются операторы соответствия, отчет хранится неограниченное время в личном кабинете. Первые 1000 запросов — бесплатно!

4. По степени ценности для бизнеса

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

Коммерческие запросы

Это запросы, которые обеспечивают конверсию. Их вводят пользователи, которым нужен товар или услуга. Содержат слова: «купить», «заказать», «цена», «стоимость» и т. п.

Коммерческие ключи составляют основу семантики в контекстной поисковой рекламе, т.к. предполагают охват «горячих» пользователей со сформированным спросом на продукт.

Стоимость и сроки SEO-продвижения по коммерческим запросам зависят от региона, тематики, конкурентности и частотности запросов.

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

Некоммерческие (информационные) запросы

Такие ключевые слова описывают потребность пользователя, напрямую не связанные с покупкой товара или услуги. Содержат фразы: «своими руками», «как сделать», «что такое», «когда выгодно», «отзывы» и т. п.

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

Правильно распределить запросы по страницам сайта поможет кластеризация. Со специальным инструментом от PromoPult семантическое ядро кластеризуется в один клик.

5. По зависимости от местоположения пользователя

Запросы по этому признаку делятся на:

• Геозависимые. Поисковая выдача по таким запросам формируется в зависимости от местоположения пользователя. Например, если пользователь в Барнауле вводит фразу «салон красоты», то он получит в ТОПе список салонов красоты в Барнауле, а не в других городах и регионах. Затраты на продвижение по таким запросам могут существенно отличаться в зависимости от региона. В городе-миллионнике продвигаться сложнее и дороже, чем в районном центре с населением 50 тыс. человек.
• Геонезависимые. Поисковая выдача по этим запросам мало отличается от региона к региону. Обычно это информационные запросы или запросы с указанием конкретного города (в этом случае выдача не будет зависеть от региона нахождения пользователя). Эффективность продвижения по таким фразам во многом зависит от качества сайта и контента.

Разделение запросов по географическому признаку необходимо для правильного продвижения сайта в одном или нескольких регионах. Вот подробное руководство по региональному SEO для коммерческих площадок.

6. По информационной потребности пользователя (интенту)

В зависимости от интента (намерения) пользователя поисковые запросы делятся на такие группы:

• Общие (запросы с неясным интентом). Это ВЧ запросы-однословники типа «платье», «стол», «книга». В таких случаях потребность не уточнена дополнительными словами, чтобы определить намерение пользователя. Поэтому выдача по таким запросам смешанная — здесь и коммерческие страницы, и информационные. Ключи отличаются высокой частотностью и низкой конверсией. Поисковую контекстную рекламу по ним не запускают и страницы под них не оптимизируют.
• Навигационные. Их пользователи вводят, когда хотят попасть на конкретный сайт. Это фразы типа «магазин Техносила» или «promopult.ru». Частным случаем навигационных являются витальные запросы — они содержат только название бренда без дополнительных поясняющих слов и вводятся с целью попадания на официальный сайт. Для продвижения по этим запросам важно правильно заполнить страницу с контактами, оформить главную страницу, составить текст о компании, добавить сайт в Яндекс.Справочник и Google Мой Бизнес, указать, что это официальный сайт и т. п.
• Информационные. В этом случае человек хочет найти ответ на конкретный вопрос, поэтому для высокого ранжирования сайта важно качество контента: полнота раскрытия темы, структурированность текста, понятное изложение, иллюстрации и видео, если это необходимо.
• Транзакционные. Это запросы, содержащие слова «купить», «заказать», «цена», «стоимость», которые приводят конверсионный трафик на сайт. Пользователи вводят их с целью покупки товара, заказа услуги, скачивания программы и т.п.
• Мультимедийные. С помощью этих фраз пользователи ищут фотографии, видеоролики, аудиозаписи, документы и прочие медиафайлы. Эти фразы содержат слова «фото», «видео», «галерея», «клип». При создании контекстной рекламной кампании фразы с этими словами исключаются с помощью списков минус-слов, чтобы на сайт шел только целевой трафик.
• В особую группу выделяют LSI-запросы, они дополняют семантический кластер, к которому относится основной запрос. Например, для группы ключей «ремонт иномарки» запросы «сайлентблок» и «тормозные колодки» можно обозначить как LSI. Употребление в текстах на посадочных страницах LSI-запросов стало необходимо после обновлений поисковых алгоритмов, которые все лучше «понимают» запросы на естественном языке и строят выдачу по смыслу фразы, а не по точному значению составляющих ее слов.

7 советов по работе с разными типами ключевых слов

1. Учитывайте частотность и конкурентность запросов при планировании затрат на продвижение.
2. Не смешивайте коммерческие и информационные запросы на одной посадочной странице.
3. Используйте информационную семантику для привлечения дополнительного трафика.
4. Учитывайте геозависимость запросов: правильно присваивайте регион в Яндекс.Вебмастере, употребляйте топонимы в метаданных, создавайте отдельные страницы для каждого региона.
5. Избегайте запросов с неясным интентом.
6. Сделайте все, чтобы вас нашли по навигационным запросам: зарегистрируйте организацию в Яндекс.Справочнике и Google Мой бизнес, заполните страницы «Контакты» и «О компании», укажите ссылку на официальный сайт на всех площадках, где есть информация о компании.
7. Используйте LSI-семантику для более полного ответа на запрос пользователя.

Типов ключевых запросов много, и новичку в них запутаться ничего не стоит. Если у вас недостаточно опыта и знаний для самостоятельного сбора ключевиков, вы рискуете допустить ошибку и снизить эффективность продвижения. Что делать? Подключить услугу персональный менеджер от PromoPult. Специалист подберет подходящие для ваших целей ключевые слова, распределит их по страницам и поможет настроить и запустить рекламную кампанию.

геозависимость, тип, частотность и конкурентность запросов в поисковых системах

§ 6. 

У поисковых систем есть классификации поисковых запросов. Каждая группа запросов может обрабатываться по разному.

1. По геозависимости

По геозависимости запросы бывают 2 видов:

1. Геозависимые.
2. ГеоНЕзависимые.

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

Практически все коммерческие запросы («заказать пиццу», «купить велосипед» и т.п.) геозависимы. Маловероятно, что кто-то будет заказывать себе пиццу в Москве, когда живет в Санкт-Петербурге. Все информационные запросы («как сделать пиццу», «как выбрать велосипед» и т.п.) геоНЕзависимые. Человеку без разницы в каком городе искать ответ на подобный вопрос.

Еще раз: если запрос геозависимый, то пользователю из Санкт-Петербурга будут показаны сайты предоставляющие услуги в Санкт-Петербурге. Если запрос геоНЕзависимый, то пользователю из Санкт-Петербурга будут показаны сайты по всей России.

Есть одна тонкость: если вы указываете коммерческий запрос с указанием города («заказать пиццу в Москве», «купить велосипед в Санкт-Петербурге»), то он геоНЕзависимый и поисковая система не будет учитывать ваше месторасположение.

Как проверить геозависимость запроса

В Яндексе в get запросе существует параметр lr, который отвечает за регион поиска.

Для определения геозависимости запроса необходимо открыть выдачу 2 разных регионов (например 2 — Санкт-Петербург и 213 — Москва) и сравнить ее. Если выдача одинаковая — запрос геоНЕзависимый, если разная — геозависимый.

2. По виду запроса

Существует 5 разных типов запросов:

1. Витальные (навигационные).
2. Транзакционные.
3. Информационные.
4. Общие.
5. Мультимедийные.

Витальные запросы — запросы, где потребность пользователя выражается в поиске определенного сайта. Примеры витальных запросов: «эльдорадо», «спбгу», «путин официальный сайт» и т.п. По витальным запросам могут показываться быстрые ссылки:

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

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

Общие запросы — запросы с разной потребностью пользователей. Примеры общих запросов: «беговел», «дрель» и т.п. Общие запросы достаточно популярные, но менее эффективные для бизнеса. Как правило, у пользователя еще не сформировалась конкретная потребность и он еще не готов сделать покупку.

Мультимедийные запросы — запросы, связанные с поиском видео, фото, презентаций, картинок и т.п. Примеры мультимедийных запросов: «котик на рабочий стол», «видео как выровнять стену по маякам» и т.п. Как правило, по мультимедийным запросом появляются поисковые колдунщики (поисковые колдунщики Яндекса). Вот так:

3. По частотности

Под частотностью подразумевается количество обращений пользователей в поисковую систему по этому запросу.

По частотности запросы делятся на:

1. Высокочастотные (ВЧ). Самые популярные запросы, относительно других.
2. Среднечастотные (СЧ). Средне популярные запросы, относительно других.
3. Низкочастотные (НЧ). Не популярные запросы, относительно других.

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

При этом деление между ВЧ, СЧ и НЧ произвольное, здесь не существует каких-то строгих правил. Например, у нас есть группа запросов и их частотность (обозначается цифрой):

• велосипед [100]
• купить велосипед [50]
• велосипед в интернет-магазине [35]
• велосипед цена [20]

Вот кто то распределит вот так:

• велосипед [100] — ВЧ
• купить велосипед [50] — СЧ
• велосипед в интернет-магазине [35] — НЧ
• велосипед цена [20] — НЧ

А кто то вот так:

• велосипед [100] — ВЧ
• купить велосипед [50] — СЧ
• велосипед в интернет-магазине [35] — СЧ
• велосипед цена [20] — НЧ

Автор не видит особой ценности в этой информации для seo специалиста, но терминологию важно понимать. Из-за того, что в своих документах вы поставите напротив запроса 2 буквы — ничего не изменится, поэтому не зацикливайтесь на этом делении.

4. По уровню конкуренции

По уровню конкуренции запросы бывают:

1. Высококонкурентные (ВК). Запросы с максимальной конкуренцией.
2. Среднеконкурентные (СК). Запросы со средней конкуренцией.
3. Низкоконкурентные (НК). Запросы с низкой конкуренцией.

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

Но существуют несколько проблем:

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

Например, вот что считает одна из самых популярных программ Key Collector:

Key Collector:

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

То есть учитывается только:

1. Количество документов (сайтов) в поисковой выдаче по запросу.
2. Количество главных страниц в поисковой выдаче по запросу.
3. Количество точных вхождений заданной ключевой фразы в заголовки страниц.

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

Выходы из ситуации не самые простые:

1. Разработка собственного программного обеспечения, которое поможет вам определять реальную конкурентность запроса.
2. Смотреть все вручную.

Автор рекомендует не зацикливаться на конкурентности запросов, особенно в первое время. Многие крупные коммерческие сайты не считают конкурентность запросов при сборе семантического ядра, так как не считают эту информацию приоритетной. Без этой информации можно прекрасно обходится и достигать высоких результатов, но для общего понимания это полезно.

Типы и виды поисковых запросов

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

Целесообразность

Классификация запросов по целесообразности

По целесообразности для конкретного веб-проекта поисковые запросы делятся на следующие типы:

Целевые

Это те слова и фразы, которые могут приводить целевой трафик из поисковых систем.
Например, для интернет-магазинов и других коммерческих сайтов целевыми являются запросы, предполагающие у пользователей коммерческий интерес.

Нецелевые

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

Критерии для определения целесообразности

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

Частотность

Часто к нецелевым определяют запросы с нулевой и около нулевой точной месячной частотой, а также фразы с неестественными показателями точной частоты.

Коммерческая значимость

Запросы с коммерческим интересом являются нецелевыми для некоммерческих проектов и целевыми для коммерческих.

Целенаправленность

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

Корректность словоформ

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

Геозависимость

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

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

Частотность (популярность)

Популярность запроса выражается в частоте его применения пользователями, которую также называют частотностью.

Частотность поискового запроса — это количество его применения в определённой поисковой системе за определённый срок (месяц, квартал или год). На основании данного показателя можно строить прогнозы трафика из поисковых систем.

Например, с фразой «playstation 5» к Яндексу в течение месяца обращались 109 569 раз, т. е. её частотность равна 109 569.

Популярность фразы «playstation 5» в Яндекс.

Виды частотности в зависимости от срока

Частотность может быть:

• недельной,
• месячной,
• квартальной,
• годовой.

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

Частотность фразы за определённый период в Яндекс.Директ.

Классификация запросов по частотности

Разделение поисковых фраз по частотности является относительным и зависит от тематики сайта. Иначе говоря, для одной тематики высокочастотными будут считаться фразы частотой в 10000, для другой – в 1000, для третьей — в 100.

В зависимости от популярности поисковые запросы делятся на следующие типы:

Высокочастотные (ВЧ)

Это самые популярные запросы относительно других фраз в семантическом ядре или в отдельном его кластере. К ВЧ-запросам в СЯ с порогом частотности в 1000 наверняка можно отнести фразы с интервалом частоты в 100-1000. Наверняка, т. к. возможно следует расширить данный интервал в зависимости от числа попадающих в него фраз. Число ВЧ-запросов составляет наименьшее количество от общего числа словосочетаний в семантическом ядре. Кроме того, высокочастотные фразы, как правило, являются самыми короткими (с наименьшим количеством слов).

Среднечастотные (СЧ)

СЧ-запросы более длинные и точные по отношению к высокочастотным, но менее длинные и точные по отношению к низкочастотным и микронизкочастотным. Для семантического ядра с порогом частотности в 1000 среднечастотные запросы могут быть в пределах частоты от 10 до 100.

Низкочастотные (НЧ)

Как правило, НЧ-запросы более длинные и точные по отношению к ВЧ- и СЧ-запросам. Для СЯ с порогом частоты в 1000 низкочастотные фразы могут находиться в интервале частотности до 10 в месяц.

Микронизкочастотные (МЧ)

Выделять МЧ-запросы целесообразно только в больших ядрах с высоким порогом частоты. Например, в СЯ с порогом частоты в 100000 микронизкочастотные фразы могут находиться в диапазоне частоты до 10.

«Пустышки»

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

Накрученные

Это фразы с неестественной популярностью, которая была повышена искусственным образом («накручена»). Определить «накрученные» запросы не сложно: их базовая и фразовая частоты приблизительно равны. Если значения этих частот в пределах 10, то это может свидетельствовать о том, что с фразой к поисковой системе несколько раз обращался один и тот же пользователь, однако если значения фразовой и базовой частоты приблизительно равны и имеют высокие значения, то это свидетельствует о «накрутке» со стороны заинтересованных лиц с целью отображения этих фраз среди поисковых подсказок.

Как определить частотность?

Популярность поискового запроса в Яндекс и Google может существенно отличаться.

Частотность в Яндекс

Частоту в ПС Яндекс можно узнать из сервисов Wordstat и Яндекс.Директ. Следует отметить, что сервисы Яндекса предоставляют 3 вида частотности:

Базовая (без применения операторов)

Это суммарная частота всех словосочетаний, включающих слова из запроса.

Фразовая (с применением операторов "")

Это частота без учета словоформ.

Точная (с применением операторов "!")

Это частота с учетом указанных словоформ.

Бывает, что базовая частота фразы имеет очень высокое значение, в то время как фразовая и, как следствие, точная частоты равны нулю. Например, запрос «семантическое ядро мебель» имеет базовую частоту 58 и фразовую частоту 0. Это значит, что такой запрос имеет расширенные версии с дополнительными словами (например «семантическое ядро магазина мебели»), суммарная частотность которых равна 58.

В SEO популярность запроса отражают его фразовая и точная частоты по сервису Подбор слов.

Частотность в Google

Частоту запроса в ПС Google можно узнать из инструмента Планировщик ключевых слов в Google Ads. Парсинг этого сервиса проблематичен, но возможен. Также можно узнать значения частотности фраз из Google Рекламы на платной основе через Топвизор.

Частотность запросов по данным Яндекс и Google в Топвизор.

Конкурентность

Под конкурентностью подразумевается сложность продвижения по запросу в топе.

Чем выше конкурентность фразы, тем сложнее по ней продвинутся.

Типы запросов по конкурентности

Высококонкурентные (ВК)

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

Среднеконкурентные (СК)

По этим «ключам» будет проще попасть на вершину поисковой выдачи, чем по высококонкурентным.

Низкоконкурентные (НК)

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

От чего зависит конкуренция?

На уровень конкурентности влияют следующие факторы:

Частотность

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

Количество результатов в поисковой выдаче (SERP-данные)

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

Наличие в топе сервисов поисковых систем и агрегаторов (SERP-данные)

Если в SERP по запросу фигурируют Яндекс.Маркет, Яндекс.Услуги, Википедия, а также региональные агрегаторы, то продвинуться по нему будет крайне сложно.

Количество вхождений слов из запроса в заголовки сниппетов (SERP-данные)

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

Количество главных страниц сайтов в топе (SERP-данные)

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

Качество контента страниц в топе

Эти данные особенно важны для информационных запросов, но их нельзя определять автоматически.

SEO-факторы сайтов в топе

Чем выше значения хостовых факторов ранжирования сайтов в топе, таких как возраст, ссылочный профиль, семантический охват и т. д., тем выше конкурентность запроса. Быстро оценить большинство хостовых факторов сайтов в SERP можно с помощью плагина для браузера RDS bar. Хостовые факторы в SERP посредством «RDS bar».

Под SERP-данными понимаются те данные, которые можно определить, проанализировав страницу результатов поиска без внутреннего анализа самих результатов.

Как определить конкурентность?

Как правило, о высокой конкурентности запроса говорит его высокая популярность, но при составлении семантического ядра также важно выделять фразы, оптимальные в соотношении частотность/конкурентность. Для этого необходимо принимать во внимание перечисленные выше факторы.

Автоматизировать процесс определения данных из SERP можно в программе Key Collector, после чего эти данные можно задействовать в формулах KEI.

Данные из SERP в Key Collector.

Кроме этого уровень конкурентности запросов на платной основе может определять сервис Мутаген, который также можно интегрировать с Key Collector.

Целенаправленность

Под целенаправленностью подразумевается характер интета пользователя, который вводит запрос.

Типы запросов по целенаправленности

В зависимости от целевой направленности поисковые фразы делятся на следующие виды:

• транзакционные,
• информационные,
• навигационные,
• мультимедийные,
• картографические,
• неопределённые.

Как определить целенаправленность?

Целенаправленность определяется по составу фразы, как правило, на неё указывают характерные интент-маркеры.

Например, маркерами транзакционных запросов могут служить слова «купить», «скачать», «онлайн»:

• взрывные котята купить,
• шаблоны word скачать,
• проверить текст на ошибки онлайн.

Если в составе фразы отсутствуют интент-маркеры, то её целенаправленность определяется по результатам выдачи. Например, по фразе «текст на ошибки» сложно понять, какую цель преследует пользователь, но по результатам поиска очевидно, что это транзакционный запрос, который может быть целевым только для сайта, функционал которого предусматривает возможность проверять текст на ошибки.

Транзакционные запросы

Такие фразы выражают намерение пользователя совершить определенное действие:

• проверить,
• перевести,
• скачать,
• записаться.

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

Примеры транзакционных запросов

С инфинитивом	Без инфинитива	Результаты поисковой выдачи
купить телевизор	телевизор samsung	Листинги товаров (телевизоров) в местных интернет-магазинах.
заказать пиццу	пицца в кемерово	Сайты местных пиццерий.
записаться к врачу	запись к врачу	Страницы с возможностью записаться на приём или с контактной информацией учреждений здравоохранения.
перевести с английского	переводчик онлайн	Онлайн-переводчики.
проверить текст	текст на ошибки	Анализаторы текста.

Транзакционные запросы делятся на коммерческие и некоммерческие.

Большинство некоммерческих транзакционных запросов являются узконаправленными и нецелевыми для коммерческих и информационных сайтов.

Информационные запросы

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

Примеры информационных запросов

Запрос c вопросительным наречием	Запрос без вопросительного наречия	Запрос в форме корректного вопроса
SEO что такое	SEO	Что такое SEO?
почему пропадает обоняние при коронавирусе	обоняние при коронавирусе	Почему пропадает обоняние при коронавирусе?
как поменять масло лада веста	замена масла веста	Как поменять масло в лада веста?
когда високосный год	високосный год	Когда бывает високосный год?
зачем увлажнитель воздуха	увлажнитель воздуха это полезно или нет	Зачем нужен увлажнитель воздуха?

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

Навигационные запросы

Через такие поисковые запросы пользователи ищут сайты или веб-страницы на определённых сайтах.

Примеры навигационных запросов

Запрос	Интент	SERP
официальный сайт Joomla	Найти конкретный сайт.	На первом месте будет главная соответствующего сайта.
интернет-магазин обуви	Найти сайты по общему признаку (продажа обуви).	Сайты обувных интернет-магазинов.
IKEA	Не очевиден.	На первом месте будет главная официального сайта IKEA.
IKEA в Минске	Найти сайты по общему признаку (продажа мебели IKEA в Минске).	Местные сайты, продающие мебель IKEA.
википедия	Найти конкретный сайт.	На первой позиции будет главная искомого сайта.
Дэвид Копперфилд википедия	Найти конкретную веб-страницу.	На первой позиции будет соответствующая страница.
ozon ru	Найти конкретный сайт.	На первом месте будет главная соответствующего сайта.

Топ поиска по навигационным запросам занимают релевантные им сайты, т. е. по запросу «авито» топ будет возглавлять главная страница сайта avito.ru и никак иначе.

Мультимедийные запросы

Через эти поисковые фразы пользователи желают найти мультимедийный контент для дальнейшего взаимодействия с ним:

• видео,
• аудио,
• изображения.

Маркерами мультимедийных запросов могут выступать слова: «смотреть», «онлайн», «фото», «картинки», «видео», «слушать» и т. д.

У поисковых систем Яндекс и Google существует отдельные области поиска по таким фразам (картинки, видео, музыка).

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

Картографические запросы

Это поисковые запросы адресов и других географических объектов для отображение на картографических сервисов. С учетом существования Google Maps и Яндекс.Карт, сложно представить целесообразность этого типа запросов для SEO.

Неопределённые запросы

Существуют поисковые фразы, интент которых не очевиден, например:

• «телевизор»,
• «увлажнитель воздуха»,
• «мобильный телефон»,
• «IKEA».

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

Пример 1: «телевизор»

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

Пример 2: «взрывные котята»

Целенаправленность этого запроса также не очевидна, поэтому следует анализировать топ:

• в Google наблюдается 9 результатов: 7 транзакционных, 2 информационных → фраза транзакционная;
• в Яндекс наблюдается 11 результатов: 5 транзакционных, 6 информационных → фраза неопределённая.

Коммерческость

Под «коммерческостью» запроса подразумевается коммерческий интерес пользователя, осуществляющего поиск.

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

Тип запросов	Коммерческие	Полукоммерческие	Некоммерческие
Описание	Запросы для поиска товаров/услуг (транзакционные), а также коммерческих сайтов (навигационные).	Неопределённые по целенаправленности запросы, включающие товарные наименования, а также информационные запросы с коммерческим контекстом.	Любые запросы, которые не подразумевают коммерческой заинтересованности.
Примеры	«купить телевизор» (транзакционный), «магазин телевизоров» (навигационный), «телевизоры в минске» (транзакционный)	«очиститель воздуха» (неопределённый), «курсы по английскому» (неопределённый), «взрывные котята» (неопределённый), «iphone 11 отзывы» (информационный), «playstation 5 характеристики» (информационный)	«мстители 3 смотреть онлайн бесплатно» (мультимедийный), «курсы по продвижению сайтов бесплатно» (транзакционный), «photoshop скачать» (транзакционный), «техника плавания брассом» (информационный)
Маркеры	«купить», «заказать», «стоимость», «цена», названия торговых объектов («магазин», «салон», «студия», «парикмахерская» и т. д.), а также топонимы	«отзывы», названия товаров, брендов, продавцов, исполнителей	«бесплатно», «торрент», «скачать», «смотреть», «онлайн», информационные маркеры
Другие признаки	Названия товаров и товарные наименования, отсутствие информационных и некоммерческих маркеров.	Отсутствие маркеров (для неопределённых запросов).	Отсутствие коммерческих маркеров.
В топе	Коммерческие страницы	Коммерческие и некоммерческие страницы (смешанная выдача).	Некоммерческие страницы.
Целесообразность	Для коммерческих сайтов.	Для коммерческих и некоммерческих сайтов.	Для некоммерческих сайтов и в зависимости от специфики.

Классификация по конкретике

От точности формулировок поисковых фраз зависит, насколько конкретными будут результаты поиска. Эта классификация позволит правильно определять типы посадочных страниц и уровень их вложенности.

В зависимости от конкретики формулировок запросы делятся на следующие виды:

Общие

Это слова и словосочетания без каких-либо интент-маркеров. Для точного определения интента таких запросов необходимо анализировать поисковую выдачу. Часто по общим запросам наблюдается смешанная поисковая выдача и очень высокая конкуренция.
Примеры: «сайт», «холодильник», «opencart».

Неконкретные

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

Конкретные

Это более точные поисковые запросы, достаточно раскрывающие потребность пользователя.
Примеры: «заказать интернет-магазин автозапчастей» (коммерческий), «атлант хм 4008-022» (коммерческий), «шаблон opencart revolution» (некоммерческий).

Детальные

Максимально конкретные словосочетания, детально раскрывающие интент.
Примеры: «заказать интернет-магазин автозапчастей на битрикс» (коммерческий), «атлант хм 4008-022 в рассрочку» (коммерческий), «шаблон opencart revolution на русском» (некоммерческий).

Витальные

Это запросы, на которые можно получить конкретные ответы прямо из SERP не переходя по ссылкам, или даже из поисковых подсказок. Как правило, держать такие запросы в семантическом ядре не целесообразно. Примеры: «официальный сайт wordpress» (навигационный), «сколько лет Путину» (информационный), «год основания санкт-петербурга» (информационный).

Геозависимость

Под геозависимостью понимается зависимость поисковой выдачи по запросу от геолокации пользователя.

Виды запросов

Геозависимые

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

Геонезависимые

Это запросы, выдача по которым не зависит от геолокации. В свою очередь делятся на 2 подвида:

• Региональные. Это коммерческие запросы с топонимами. Например, по фразе «купить смартфон в Минске» будет формироваться региональная поисковая выдача независимо от геолокации пользователя.
• Глобальные. Это любые запросы, выдача по которым не отличается вне зависимости от наличия топонимов или других слов в их составе. Например, по фразе «как испечь шарлотку» результаты поиска будут приблизительно одинаковыми во всех регионах.

Как определить геозависимость?

Геозависимость поискового запроса можно определить вручную по следующему алгоритму:

1. ввести запрос,
2. просмотреть результаты поиска,
3. сменить геолокацию в настройках поисковика,
4. проверить выдачу ещё раз.

Разумеется, процесс проверки можно автоматизировать. Отличным решением для этого является программа Key Collector версии 4, которая определяет геозависимость поисковых фраз в процентном соотношении: например, если по результатам проверки в разных регионах в выдаче по запросу будут отличаться 2 результата из 10, то программа присвоит этому запросу 20% геозависимости. В Key Collector версии 4 можно вручную выбирать регионы для проверки как в Яндекс, так и в Google.

Определение геозависимости фраз в Key Collector

Классификация по смысловому значению

В зависимости от смысла поисковые запросы можно разделить на следующие виды:

• равные по смыслу,
• связанные по смыслу,
• общетематические,
• разные по смыслу,
• бессмысленные.

Равные по смыслу фразы

Это слова и фразы, которые обозначают одно и то же:

Синонимы и синонимичные фразы

Примеры: «призрак» = «привидение», «купить пиццу» = «заказать пиццу».

Аббревиатуры и акронимы

Примеры: «Санкт-Питербург» = «Питер» = «СПб», «SEO» = «поисковая оптимизация»

Кириллические аналоги иностранных слов

Примеры: «samsung» = «самсунг», «iphone» = «айфон».

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

Связанные по смыслу фразы

Эти фразы относятся к одному и тому же объекту. Например:

• «плоскостопие»,
• «плоскостопие что такое»,
• «плоскостопие симптомы»,
• «плоскостопие лечение»,
• «как лечить плоскостопие»,
• «как определить плоскостопие».

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

Общетематические фразы (LSI)

Это слова и словосочетания, которые часто встречаются в общем контексте. Например, в качественной статье про семантическое ядро невозможно обойтись без упоминания фразы «ключевые слова». В статье про WordPress нельзя обойтись без упоминания аббревиатуры CMS, а в статье про SEO нельзя обойтись без слова «оптимизация».

Примеры LSI

Запрос	Тематические фразы
битрикс	CMS, сайт, Joomla
мебель	шкаф, фурнитура, гарнитур
фитнес	спорт, кроссфит, бодибилдинг
лада	автомобиль, запчасти, веста
политика	президент, мэр, власть
Питер	Нева, Адмиралтейство, Ленинград

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

Бессмысленные фразы

Нередко после парсинга в черновом семантическом ядре находятся лишенные смысла словосочетания, такие как:

• «масло морщин вокруг» — это запрос-пустышка с очень высокой базовой частотой и нулевой фразовой частотой,
• «каааааааааааааие масло от морщин самые хие» — это «мусорный» лишенный смысла запрос.

Бессмысленные фразы следует удалять из семантического ядра как нецелевые.

Сезонность

Сезонность характеризует изменение частотности запроса в разные периоды.

Классификация запросов по сезонности

Несезонные

Это поисковые фразы, популярность которых относительно стабильная в течение года.
Пример: «купить смартфон», «что такое SEO». Динамика изменения популярности несезонного запроса

Сезонные

Частота таких запросов непостоянная, пик их популярности приходится на определённый период.
Пример: «купить лыжи», «ремонт велосипеда». Динамика изменения популярности сезонного запроса

Трендовые

Эти фразы являются временными, они запрашиваются пользователями в определённый период (месяц, год или несколько лет), после чего теряют актуальность и их частота падает вплоть до нуля. Это могут быть фразы, связанные кратковременными мероприятиями или событиями. Характерными для трендовых запросов маркерами могут служить цифры, обозначающие актуальный год.
Пример: «славянский базар 2020» (пик популярности запроса приходится на момент проведения мероприятия), «iphone 6» (запрос был популярен, пока девайс не был морально устаревшим). Динамика изменения популярности трендового запроса

Зачем определять сезонность?

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

Как определить сезонность?

Существует два сервиса поисковых систем, наглядно демонстрирующих динамику изменения популярности поисковых запросов:

trends.google.ru

Сервис позволяет оценить сезонность фраз в Google:

• за любой период,
• в любом регионе,
• в любой зоне поиска (веб-поиск, картинки, новости, YouTube).

Кроме этого можно указывать несколько словосочетаний для сравнения между собой.

wordstat.yandex.ru

Сервис демонстрирует изменение популярности запросов в Яндекс:

• с сегментацией по месяцам (за последние 2 года) и по неделям (за последний год),
• в любом регионе,
• на определённых устройствах (десктопы, смартфоны, планшеты).

Количество слов

В зависимости от количества слов поисковые запросы делятся на:

• 1-словные,
• 2-словные,
• 3-словные,
• и т. д.

Как правило, чем больше слов в запросе, тем ниже его популярность и конкурентность. Т. е. 1- и 2-словным запросам свойственна высокая частотность и продвигаться по ним в результатах поиска будет сложнее, чем по более конкретизированным фразам.

Эффективность в продвижении

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

Эффективность поискового запроса в продвижении определяется из отношения значений его частотности к конкурентности.

Чем выше частота — тем больше трафика при нахождении в топе, чем ниже конкуренция — тем быстрее попадание в топ.

Высокоэффективные

Это фразы с высокими показателями частоты и максимально низкими значениями конкуренции. Именно они должны быть первостепенными в продвижении.

Среднеэффективные

Это СЧ-фразы с максимально низкими значениями конкуренции.

Низкоэффективные

Это все остальные фразы: высококонкурентные ВЧ и СЧ, а также вся «низкочастотка».

Основные виды поисковых запросов

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

Разновидности поисковых запросов  

По частотности  

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

• Высокочастотные;
• Среднечастотные;
• Низкочастотные;
• Микро низкочастотные;
• Нулевые.

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

Высокочастотные запросы  

Зачастую высокочастотные запросы состоя из 1-2 слов, которые максимально точно описывают посадочную страницу или нишу в целом. В большинстве тематик частотность ВЧ запросов находится в диапазоне от 3-5 и до 10-20 тысяч запросов за месяц.  

SEO-продвижение по высокочастотным запросам максимально сложное, долгосрочное и при этом дорогое с финансовой точки зрения. Для вывода страницы сайта в ТОП поисковой выдачи по высокочастотным ключам необходимо подходить к работе комплексно:  

1. Улучшение юзабилити и технических характеристик всего сайта в целом;

2. Нарабатывать ссылочную массу;

3. Внедрять на сайт актуальный и экспертный контент.  

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

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

Среднечастотные запросы  

СЧ фразы включают в себя 2-3 запроса, с частотностью каждого от 500 до 3000 запросов за последний месяц. Данный запрос несет в себе существенно больше конкретики по сравнению с предыдущим аналогом, поэтому определить интент пользователя на конкретной посадочной странице крайне просто. Запросы средней частотности часто используются при названии категорий сайта, продвижение которых в органической поисковой выдаче существенно проще и быстрее. Продвижение также будет намного быстрее при условии правильного внедрения внутри контента и основных мета-тегов.  

Низкочастотные запросы  

Данный тип запросов носит название long tale, что переводится как запросы с длинным хвостом. В некоторых случаях длина запроса может составлять до 10 слов, а их формулировка максимально точно описывает намерение пользователя.  

Ранее проведение грамотной оптимизации страницы под данные типы запросов практически всегда гарантировала попадание в ТОП органической выдачи. Сегодня алгоритмы поисковых систем достаточно сильно прогрессировали, поэтому даже по НЧ запросам в ТОП выдачи присутствуют авторитетные сайты.   Запускать рекламную кампанию по НЧ запросам максимально выгодно, ведь можно достигнуть максимального уровня CTR и конверсий при условии минимальной цены за клик. В случае рекламы в партнерских сетях, данный тип запросов не применяются.  

Нулевые запросы  

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

Также стоит отметить, что нулевики используются в качестве источника семантики. Грамотная маркетинговая работа с повышением популярности компании или бренда в целом может перевести нулевые запросы в НЧ или СЧ.  

По конкурентности  

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

Запросы относительно показателя своей конкуренции можно разделить на следующие виды:  

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

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

3. Низкоконкурентные (НК). Работая с данной категорией запросов можно отметить существенное облегчение продвижения в ТОП поисковой выдачи, но при этом количество трафика также небольшое.  

Анализируя поисковую выдачу можно заметить, что по ВК запросам выдача состоит полностью из релевантных ответов, тогда как при вводе НК запроса выдача имеет окна из не релевантных страниц.  

По степени ценности  

Руководствуясь данным критерием можно разделить все запросы на 2 категории:  

• Коммерческие;
• Информационные.  

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

Коммерческие запросы  

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

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

Информационные запросы  

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

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

По интенту пользователя  

Различные интенты пользователя позволяют разделить запросы на следующие категории:  

1. Общие. Зачастую это высокочастотные запросы состоящие из одного слова. В данном случае нет уточнения намерения пользователя, поэтому итоговая выдача будет достаточно смешанной. Ключи имеют высокую частотность и при этом низкий показатель конверсий, поэтому по данным запросам не запускают рекламные кампании.

2. Навигационные. В данную категорию также можно отнести витальные запросы, которые содержат исключительно название определенной компании.  

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

4. Мультимедийные. Используются фразы с целью найти различные фотографии, аудиозаписи или документы.  

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

Рекомендации специалистов нашей студии  

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

2. Не рекомендуется мешать на одной странице запросы с разным интентом, это размывает тематику и ухудшает ранжирование.

3. На коммерческих сайтах можно также использовать информационные запросы, оформив под низ соответствующий раздел. Это может быть блог, который позволит привлекать дополнительный трафик на сайт, а также работать с холодной аудиторией.

4. Старайтесь исключать запросы с непонятным интентом.

5. Применяйте LSI-семантику при создании контента, что позволит создать развернутый ответ.  

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

Какие виды и типы поисковых запросов бывают

Если вы хотите правильно подобрать запросы (ключевые слова) для составления семантического ядра сайта Вам необходимо, более детально разобраться, какие основные виды и типы поисковых запросов бывают. 

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

Какие виды поисковых запросов бывают?

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

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

Как разделяются поисковые запросы

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

Разделение по частотности (ВЧ, СЧ, НЧ)

Под ВЧ подразумеваются запросы, количество которых в месяц согласно статистике варьируется от 1000 запросов. СЧ предусматривает согласно статистике количество запросов в пределах 100-1000 запросов. НЧ предусматривает до 100 запросов в месяц.

Разделение по конкурентности (ВК, СК, НК)

Конкурентность запроса указывается под графой поиска. ВК предусматривает от 1000000 запросов, СК – 100000-1000000, НК – до 100000 запросов.

Разделение по геозависимости

Геозависимые запросы — это запросы в поиске выдача для которых отличается в зависимости от региона.

Пример

• доставка пиццы
• купить мебель

Если вы будете в Москве вводить запрос, то для Вас будет 1 выдача, а если в Новосибирске то другая, так как данные услуги будут разными дял разных регионов страны.

Геонезависимые запросы — будут одинаковыми дял всех

Пример

• доставка пиццы в Москве
• купить мебель в Москве

Если вы в Новосибирске или Казани  введете данные запросы, выдача по ним будет примерно одинаковая, так как указан конкретный город, еще как пример можно взять запрос «Александр Сергеевич Пушкин» ответ на данный запрос будет один в независимости от региона.

Коммерческие и некоммерческие

Под коммерческими, подразумевают запросы, ориентированные на получение материальной прибыли, предпринимательскую деятельность. К таким запросам относится, к примеру: «купить ноутбук в Москве», где указываются требования посетителя относительно поиска необходимого товара в городе проживания. Под некоммерческими принято понимать запросы, ориентированные на поиск конкретных сведений, не имеющих отношения к предпринимательской деятельности. К примеру, «характеристики ноутбука Lenovo SL500», в котором можно подобрать информацию для анализа, ознакомиться с отзывами и получения иных сведений.

Какие типы поисковых запросов бывают?

Общие запросы

Общими называют запросы, ориентированные на поиск предмета, события, обусловленного, как правило, наименованием самой вещи. К примеру, это могут быть запросы: «ноутбук», «телефон», и другие.

Навигационные запросы

Навигационными называются запросы, используемые пользователями для поиска конкретного ресурса. К примерам подобного рода запросов можно отнести: «ВКонтакте», Facebook, официальный сайт Microsoft (в данном случае название компании вводится не само, что дает возможность конкретизировать объект поиска).

Информационные запросы

Информационными называют запросы, по которым пользователь ведет поиск данных, не привязанных к конкретному ресурсу. Зачастую информация предоставляется для чтения, к примеру, это может быть новость, тематические ресурсы, руководства к пользованию, вопросы и ответы на них, многое другое. К примеру, это могут быть запросы: «что изучает люциферианство», «темная сторона силы».

Транзакционные запросы

Транзакционными принято называть конкретные целевые запросы, рассчитанные на формирование определенной конверсии. Данные запросы говорят о том, что посетитель ресурса готов приобрести товар. К примеру, это могут быть запросы: « купить телефон Blackberry», «заказать создание сайта».

Какие виды и типы запросов важны для коммерческого сайта

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

Какие виды и типы запросов важны для информационного сайта и блогам

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

Я так же рекомендую ознакомиться со статьей из которой вы узнаете как провести анализ поискового запроса и сделать аналитику конкурентности запроса.

Полезное видео «Типы и виды поисковых запросов пользователей»

 

Автор статьи

Если у Вас остались вопросы, напишите мне в социальных сетях!

Написано статей

Виды поисковых запросов — статья из блога экспертов

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

Деление поисковых запросов по частотности

Как классифицировать поисковые запросы в поисковиках по уровню частотности? Здесь вам поможет сервис сбора частоты вбиваемых ключей Яндекс Вордстат. Именно уровень частотности является важнейшим из типов классификации запросов. В зависимости от популярности запроса в поисковиках Google и Yandex ключи делятся на 3 вида.

Микро НЧ

Микро-низкочастотные запросы редко доходят до 10 показов в месяц. Это очень узкая тематика, подходящая бизнесу, у которого есть небольшая, но довольно «преданная» аудитория. Предположим, это ключ «Изготовление игрушечных велосипедов из красного дерева в Вологде».

Такие запросы максимально конкретизированы, а потому считаются довольно эффективными в продвижении веб-ресурсов.

НЧ-запросы (низкочастотные)

Низкочастотники схожи с микро НЧ-запросами, но поиск по ним выполняется чуть чаще. В зависимости от тематики это 100-1000 показов в месяц. Также довольно эффективны вследствие своей конкретности.

Такие запросы состоят из 5-8 слов. Планка между типами НЧ-запросов сильно размыта. Такие ключи именуются также «товарными» или «продуктовыми». Связано это с тем, что пользователи уже знают, чего они хотят найти. НЧ-ключи обладают неплохой конверсионностью, а в сумме с невысокой конкурентностью цена продвижения таких запросов не очень большая.

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

СЧ-запросы (среднечастотные)

Среднечастотники – это более популярные запросы. Их частота достигает пару тысяч показов. В таких ключах имеется уточнение, нежели в высокочастотных запросах. Например, пользователи только начинают исследовать спрос – то есть находятся на промежуточной стадии между покупкой и поиском направления.

СЧ-запросы включают 3-4 слова. Пример СЧ-запроса – «ремонт стиральной машины цен» — 400 запросов в месяц.

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

ВЧ-запросы (высокочастотные)

Высокочастоники – это самые популярные запросы тематики. Число показов по ним гораздо больше тысчи. Иногда это десятки и сотни тысяч. Но опять же, все зависит от тематики.

Коммерческие (транзакционные)

ВЧ-ключи могут быть и коммерческими, и информационными, и брендовыми. По ним поступает громадные объемы трафика. ВЧ-запросы всегда высококонкурентные. Для вывода их в ТОП нужно провести большое количество анализов и приложить немало усилий, а также отдать немало денег. Сроки продвижения затянутся от полугода до пары лет – но только в случае, если сайт уже хорошо воспринимается поисковыми системами. Если же веб-ресурс молодой, то о продвижение по ВЧ-запросам стоит забыть минимум на год. Пример ВЧ-запроса – «Адидас» или «Купить смартфон».

Примерное соотношение поисковых запросов выглядит следующим образом:

• НЧ-запросы – 45-70%;
• СЧ-запросы – 20-40%
• ВЧ-запросы – 10-15%.

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

Деление по интенту

Классификация поисковых запросов – это группирование ключей по тому или иному значению. Важное значение здесь имеет понятие интента. Под интентом подразумевается потребность пользователя. В каждом запросе есть основной и дополнительный интент. Например, ключ из одного простого слова «Такси» содержит сразу два интента. Первый – это желание вызывать такси, а второй – желание посмотреть одноименный фильм или почитать статью о формировании такси как системы. Получается, что первый интент будет коммерческим, а второй – информационным. Основные типы интентов рассмотрим далее.

Информационные

Запрос информационного типа удовлетворяет потребность пользователя обнаружить соответствующую информацию в сети. Он не подразумевает какой-то конкретный сайт. Например, это следующие варианты:

• История Древней Руси;
• Почему котам нельзя молоко;
• Как сделать обрезку деревьев и т.д.

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

Определить тип поискового запроса информационного типа довольно просто: часто содержат слова «Почему», «Как», «Отзывы», «Форум» и т.д. Люди могут искать полные и исчерпывающие сведения, а потому вероятна ориентация на несколько сайтов сразу.

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

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

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

Коммерческие

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

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

Навигационные

Следующий тип запросов именуется навигационными. Когда пользователь вводит их в поисковик, он желает найти конкретный сайт. Например, «Эльдорадо сайт», «Одноклассники.ру» и т.д. Этот же тип запросов именуется витальным или брендовым.

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

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

Смешанные

Такие запросы называются также нечеткими или общими. Сюда относятся неявные, но зачастую довольно короткие запросы. Пользователь попросту не уточняет своего желание. Например, «Окна», «Планировка спальни» и т.д.

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

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

При продвижении стоит обращать внимание на оценивание смешанных запросов. Будут ли оправданы затраты на их продвижение? Возможно, больше покупателей приведут менее частотные транзакционные запросы.

По геозависимости

Большая часть запросов ориентирована на поиск информации в каком-то конкретном регионе, где находится интернет-пользователь. Поисковики учитывают этот фактор, а потому дорабатывают собственные алгоритмы и присваивают тем или иным запросам географическую привязку.

Геозависимые

Отличный пример геозависимого запроса – ключ «Заказ машины» или «Доставка еды». Очевидно, что набирая такая запрос, пользователь рассчитывает увидеть телефоны из своего города, а не компании из другой части страны.

Геозависимые запросы бывают информационными. Например, «Музей» или «В какой театр сходить». За географической привязкой веб-ресурса нужно следить с самого начала продвижения. Если сайту присвоен регион, допустим, «Екатеринбург», то и ранжироваться он будет лучше по геозависимым ключам, вводимым из Екатеринбурга.

Геонезависимые

Такие запросы будут показаны вне зависимости от региона России, в котором проживает пользователь. Выдача везде будет одинаковой. Например, это запрос «Как ушить рубашку». И в Санкт-Петербурге, и во Владивостоке показы должны быть одинаковыми.

Получается, что географическую привязку имеют, в основном, коммерческие запросы. Но происходит так не всегда. Например, ключевики «Доставка еды в Воронеже» или «Купить надувную лодку в Зеленограде» уже будут геонезависимыми. В них четко указан регион, а потому не важно, откуда запрос задается. Выдача должна быть одинаковой, поскольку человек ищет, где именно купить ему тот или иной товар.

Типы и виды поисковых запросов в Яндекс и Google

Когда человек что-то ищет в сети интернет ему нужно вводить поисковые запросы в поисковике, на основе ключевых слов, которые используются в этих запросах, поисковая система выдаёт ответ.

Нужно ли учитывать поисковые запросы только при работе с SEO сайта? Однозначно, нет! Потому что во всех сетях сейчас есть поле «Поиск», так же это поле есть на сайтах объявлений и на некоторых коммерческих и поисковых сайтах. Поэтому, если вы хотите, чтобы пользователи в первую очередь находили не только Ваш сайт, но и группу ВКонтакте, объявление на Авито или запись в Facebook, проанализируйте поисковые запросы.

Получайте до 18% от расходов на контекст и таргет!

Рекомендуем: Click.ru – маркетплейс рекламных платформ:

• Более 2000 рекламных агентств и фрилансеров уже работают с сервисом.
• Подключиться можно самому за 1 день.
• Зарабатывайте с первого потраченного рубля, без начальных ограничений, без входного барьера.
• Выплаты на WebMoney, на карту физическому лицу, реинвестирование в рекламу.
• У вас остаются прямые доступы в рекламные кабинеты, рай для бухгалтерии по документообороту и оплатам.

Попробовать бесплатно >> Реклама

Например, в качестве названия группы для такси, можно выбрать самые популярный запрос, «Такси Омск» или «Такси Москва», в зависимости от города. А во вторую часть наименования группы вписать сам бренд, после прямой черты. Получится что-то вроде этого: «Такси Москва | Мигом 999-99-99».

Виды запросов в поисковых системах

Мы выделяем четыре основные классификации поисковых запросов:

1. по частотности;
2. по цели;
3. по конкуренции;
4. по геозависимости.

БОНУС: Конверсионные запросы — по которым чаще всего покупают.

Классификация по частотности предполагает деление запросов в зависимости от того, какое количество раз в месяц они вводятся. Ранжирование по цели, это разделение запросов в зависимости от цели, с которой они вводятся, прочитать статью или что-то купить. Запросы по конкуренции зависят не от частотности, а от количества хорошо оптимизированных сайтов в ТОП-10 поисковой выдачи. Ну, и соответственно геозависимость, говорит о том, важен ли Вам регион или нет.

Кстати, в том случае, когда Яндекс или Google видит Ваше местоположение, если Вы введёте запрос без указания города, тем не менее поисковая система покажет региональные результаты выше. Этот момент очень важен для продвижения интернет магазинов.

Типы поисковых запросов по частотности

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

• высокочастотные;
• среднечастотные;
• низкочастотные;

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

По цели

Разделение запросов по целям, более интеллектуальный и современный подход, т.к. ориентирован не только на количественные, но и на качественные показатели. Ведь для коммерческого сайта важно, придёт 10 посетителей просто посмотреть или 1 купить. Итак, поисковые запросы по целям делятся следующим образом:

• коммерческие (купить, заказать, доставка, цена)
• информационные (где, как, почему, что такое)
• по бренду (название компании)
• общие (окна, такси, сайты, т.е. без указания конкретики)

В первую очередь имеет смысл продвижение по коммерческим запросам, т.к. это позволит получить наиболее быстрый результат от SEO продвижения.

По конкуренции

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

• высококонкурентные ниши
• среднеконкурентные ниши
• низкоконкурентные ниши

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

Геозависимость

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

Анализ поисковых запросов и вывод

Прежде чем начинать поисковое продвижение, мы рекомендуем сделать детальный анализ поисковых запросов по классификации приведённой выше. При этом, при составлении семантического ядра сайта, не стоит акцентировать на каком-то одном виде подхода, оценка каждого запроса должна быть многогранна. А чтобы составить наиболее достоверную картину по используемым запросам, рекомендуем использовать не только данные Вордстата, но и статистику запросов Google Adwords.

Например, если Вы занимаетесь настройкой контекстной рекламы в Ижевске, то казалось бы запрос «Яндекс Директ» будет Вам интересен, но по данному запросу скорее всего ищут информацию те, кто хочет сделать настройку Директа самостоятельно, либо просто узнать что это такое. Соответственно для продвижения будет более интересен запрос «Настройка Яндекс Директ в Ижевске».

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

запросов и ответов API

Buzz API отвечает на каждый запрос статусом http, указывающим, был ли запрос успешным, вместе с ответом json. Ответ json включает:

Элемент JSON	Описание	Всегда присутствует
успех	Логическое значение с истиной = успех, ложь = неудача
полезная нагрузка	json результаты запроса.Для запроса GET будут включены результаты. Для POST или PUT будет включать уникальный идентификатор объекта.	Нет
сообщение	Текстовое описание результата	Нет
ошибка	сообщения json с любыми ошибками предупреждения	№
id	ID вновь созданного объекта по посту	№

Первым элементом любого ответа API будет элемент «Успех», который может иметь значение «истина» или «ложь».Пример:
«успех»: верно

Когда GET-запрос успешно выполняется, вторым элементом в ответе будет полезная нагрузка , которая будет содержать запрошенные данные. Пример успешного получения права:

Успешный ответ GET

  {
    "успех": правда,
    "payload": {
            "user_id": 1,
            "first_name": "Дэнни"
            ...
    }
}
  

При успешном выполнении POST элемент полезной нагрузки будет сообщением об успешном завершении, и будет возвращен элемент id , указывающий уникальный идентификатор созданного объекта.Пример успешного POST справа:

Успешный ответ POST

  {
    "успех": правда,
    "payload": "пользователь обновлен с ID 4",
    "id": 4
}
  

Когда запрос DELETE или PUT успешно выполняется, элементом «полезной нагрузки» будет список сообщений и полезных данных для каждого затронутого объекта. Пример успешного POST справа:

Успешный ответ PIUT / DELETE

  {
    "успех": правда,
    "полезная нагрузка": [
        {
            "id": 1,
            "успех": ложь,
            "error_code": "AD_BAD_VALIDATION",
            "сообщение": [
                "ОШИБКА: Ошибка при создании бюджета кампании, поле неправильно отформатировано в десятичном формате"
            ]
        },
        {
            "id": 30,
            "успех": правда,
            "message": "кампания успешно обновлена"
        }
        ],
        "ошибки": [
       «ОШИБКА: обновление кампании: 1 обновлено успешно, 1 - с ошибками»
    ]
}
  

Неудачные ответы объединят все ошибки в элементе «errors», как показано в примере справа:

Неудачный ответ

  {
    "успех": ложь,
    "payload": "Ничего не найдено или проблема с запросом",
    "errors": {
        "ОШИБКА: ничего не найдено по этим критериям",
        «ВНИМАНИЕ: случилось кое-что не так уж и плохо»
    }
}
  

Обратите внимание: если единственное условие ошибки, возникшее в результате запроса, было ПРЕДУПРЕЖДЕНИЕ, запрос будет иметь успех = истина , но также будет иметь непустой элемент ошибок.

Buzz использует коды состояния HTTP, чтобы указать, был ли запрос успешным. Если HTTP-код ответа 200, все работает нормально. Следующие коды представляют другие исходы:

HTTP-код	Значение
200	OK
400	Bad Request, метод не поддерживается Buzz.
401	Неавторизованный, пользователь не имеет прав. См. Учетные записи, Пользователи, Роли, Разрешения.
405	Метод, запрещенный API. Например, некоторые элементы доступны только для чтения и не могут принимать запросы POST .
406	Неприемлемо, отсутствуют параметры или неверные параметры. Это наиболее распространенный код ошибки, когда проверка поля не выполняется по какой-либо причине.
409	Конфликт, возникающий, когда запрос API выдает WARNING и запрос был выполнен в строгом режиме. Когда не находится в «строгом» режиме, WARNING вернет 200. См .: Использование дополнительных возможностей для точной настройки использования API для получения дополнительной информации о строгом режиме.
429	Ограничение скорости, возникающее, когда чрезмерное количество запросов выполняется за короткий промежуток времени. В настоящее время ограничение скорости применяется к конечным точкам очереди отчетов и аутентификации.
500	Внутренняя ошибка сервера, обычно проблема с базой данных или настройкой системы.

Веб-службы Федерального резерва Сент-Луиса: fred / series / наблюдения

Описание

Получите наблюдения или значения данных для ряда экономических данных.

Примеры

Этот запрос может возвращать XML, JSON, сжатый текст с разделителями табуляцией или сжатую электронную таблицу Excel, задав для параметра file_type значение xml, json, txt или xls.Обратите внимание, что значение по умолчанию для file_type — xml. Ключ API «abcdefghijklmnopqrstuvwxyz123456» предназначен только для демонстрационных целей. Вместо этого используйте зарегистрированный ключ API.

XML

Запрос (HTTPS GET)

 https://api.stlouisfed.org/fred/series/observations?series_id=GNPCA&api_key=abcdefghijklmnopqrstuvwxyz123456 

Ответ

<наблюдения realtime_start = "2013-08-14" realtime_end = "2013-08-14" Наблюдение_start = "1776-07-04" Наблюдение_end = "9999-12-31" units = "lin" output_type = "1" file_type = "xml" order_by = "Дата наблюдения" sort_order = "asc" count = "84" offset = "0" limit = "100000">
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1929-01-01" value = "1065.9 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1930-01-01" value = "975.5" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1931-01-01" value = "912.1" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1932-01-01" value = "794.1" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1933-01-01" value = "783.3" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1934-01-01" value = "866.7 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1935-01-01" value = "944.3" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1936-01-01" value = "1065.0" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1937-01-01" value = "1120.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1938-01-01" value = "1083.9" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1939-01-01" value = "1170.2 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1940-01-01" value = "1271.7" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1941-01-01" value = "1497.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1942-01-01" value = "1779.4" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1943-01-01" value = "2081.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1944-01-01" value = "2247.3 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1945-01-01" value = "2224.7" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1946-01-01" value = "1969.3" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1947-01-01" value = "1950.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1948-01-01" value = "2033.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1949-01-01" value = "2021.1 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1950-01-01" value = "2197.5" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1951-01-01" value = "2376.4" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1952-01-01" value = "2473.1" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1953-01-01" value = "2587.7" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1954-01-01" value = "2574.2 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1955-01-01" value = "2758.4" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1956-01-01" value = "2818.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1957-01-01" value = "2878.5" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1958-01-01" value = "2854.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1959-01-01" value = "3050.8 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1960-01-01" value = "3130.4" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1961-01-01" value = "3211.9" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1962-01-01" value = "3409.8" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1963-01-01" value = "3559.0" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1964-01-01" value = "3764.8 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1965-01-01" value = "4008.8" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1966-01-01" value = "4269.4" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1967-01-01" value = "4386.7" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1968-01-01" value = "4602.8" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1969-01-01" value = "4745.2 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1970-01-01" value = "4754.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1971-01-01" value = "4913.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1972-01-01" value = "5172.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1973-01-01" value = "5475.1" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1974-01-01" value = "5454.1 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1975-01-01" value = "5430.4" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1976-01-01" value = "5729.1" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1977-01-01" value = "5997.3" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1978-01-01" value = "6326.9" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1979-01-01" value = "6547.0 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1980-01-01" value = "6530.3" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1981-01-01" value = "6688.0" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1982-01-01" value = "6564.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1983-01-01" value = "6863.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1984-01-01" value = "7352.5 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1985-01-01" value = "7640.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1986-01-01" value = "7890.9" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1987-01-01" value = "8161.0" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1988-01-01" value = "8509.9" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1989-01-01" value = "8822.6 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1990-01-01" value = "9003.0" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1991-01-01" value = "8988.6" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1992-01-01" value = "9305.0" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1993-01-01" value = "9559.8" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1994-01-01" value = "9932.2 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1995-01-01" value = "10206.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1996-01-01" value = "10595.1" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1997-01-01" value = "11058.1" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1998-01-01" value = "11540.7" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "1999-01-01" value = "12108.9 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2000-01-01" value = "12614.3" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2001-01-01" value = "12750.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2002-01-01" value = "12970.8" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2003-01-01" value = "13352.2" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2004-01-01" value = "13879.0 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2005-01-01" value = "14340.8" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2006-01-01" value = "14690.9" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2007-01-01" value = "15009.7" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2008-01-01" value = "15009.0" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2009-01-01" value = "14565.1 "/>
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2010-01-01" value = "14966.5" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2011-01-01" value = "15286.7" />
<наблюдение realtime_start = "2013-08-14" realtime_end = "2013-08-14" date = "2012-01-01" value = "15693.1" />

 

JSON

Запрос (HTTPS GET)

 https://api.stlouisfed.org/fred/series/observations?series_id=GNPCA&api_key=abcdefghijklmnopqrstuvwxyz123456&file_type=json 

Ответ

{
    «realtime_start»: «2013-08-14»,
    "realtime_end": "2013-08-14",
    "наблюдение_старт": "1776-07-04",
    "наблюдение_конец": "9999-12-31",
    "единицы": "лин",
    "output_type": 1,
    "file_type": "json",
    "заказ_би": "дата наблюдения",
    "sort_order": "asc",
    «count»: 84,
    "смещение": 0,
    «лимит»: 100000,
    "наблюдения": [
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1929-01-01",
            "значение": "1065.9 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1930-01-01",
            "value": "975,5"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1931-01-01",
            "value": "912.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1932-01-01",
            "значение": "794.1 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1933-01-01",
            "value": "783,3"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1934-01-01",
            "значение": "866,7"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1935-01-01",
            «значение»: «944.3 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1936-01-01",
            "value": "1065.0"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1937-01-01",
            "value": "1120,6"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1938-01-01",
            "значение": "1083.9 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1939-01-01",
            "value": "1170.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1940-01-01",
            "value": "1271,7"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1941-01-01",
            «значение»: «1497.6 дюймов
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1942-01-01",
            "value": "1779,4"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1943-01-01",
            "value": "2081.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1944-01-01",
            "значение": "2247.3 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1945-01-01",
            "value": "2224,7"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1946-01-01",
            "value": "1969,3"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1947-01-01",
            "значение": "1950.6 дюймов
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1948-01-01",
            "value": "2033.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1949-01-01",
            "value": "2021.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1950-01-01",
            "значение": "2197.5 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1951-01-01",
            "value": "2376,4"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1952-01-01",
            "value": "2473.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1953-01-01",
            "значение": "2587.7 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1954-01-01",
            "value": "2574.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1955-01-01",
            "value": "2758,4"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1956-01-01",
            "значение": "2818.6 дюймов
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1957-01-01",
            "value": "2878,5"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1958-01-01",
            "value": "2854,6"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1959-01-01",
            "значение": "3050.8 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1960-01-01",
            "value": "3130,4"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1961-01-01",
            "value": "3211.9"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1962-01-01",
            "значение": "3409.8 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1963-01-01",
            "value": "3559.0"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1964-01-01",
            "value": "3764,8"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1965-01-01",
            "значение": "4008.8 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1966-01-01",
            "value": "4269,4"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1967-01-01",
            "value": "4386,7"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1968-01-01",
            "значение": "4602.8 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1969-01-01",
            "value": "4745.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1970-01-01",
            "value": "4754.6"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1971-01-01",
            "значение": "4913.6 дюймов
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1972-01-01",
            "value": "5172.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1973-01-01",
            "value": "5475.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1974-01-01",
            "значение": "5454.1 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1975-01-01",
            "value": "5430,4"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1976-01-01",
            "value": "5729.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1977-01-01",
            "значение": "5997.3 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1978-01-01",
            "value": "6326.9"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1979-01-01",
            "value": "6547.0"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1980-01-01",
            "значение": "6530.3 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1981-01-01",
            "значение": "6688.0"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1982-01-01",
            "value": "6564.6"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1983-01-01",
            "значение": "6863.2 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1984-01-01",
            "value": "7352,5"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1985-01-01",
            "value": "7640.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1986-01-01",
            "значение": "7890.9 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1987-01-01",
            "значение": "8161.0"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1988-01-01",
            "value": "8509.9"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1989-01-01",
            "значение": "8822.6 дюймов
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1990-01-01",
            "значение": "9003.0"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1991-01-01",
            "value": "8988.6"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1992-01-01",
            "значение": "9305.0 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1993-01-01",
            "value": "9559.8"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1994-01-01",
            "значение": "9932.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1995-01-01",
            "значение": "10206.2 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1996-01-01",
            "value": "10595.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1997-01-01",
            "value": "11058.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1998-01-01",
            "значение": "11540.7 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "1999-01-01",
            "value": "12108.9"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2000-01-01",
            "value": "12614.3"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "дата": "01.01.2001",
            "значение": "12750.2 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "дата": "01.01.2002",
            "value": "12970,8"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2003-01-01",
            "value": "13352.2"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2004-01-01",
            "значение": "13879.0 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2005-01-01",
            "value": "14340,8"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "дата": "01.01.2006",
            "value": "14690.9"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2007-01-01",
            "значение": "15009.7 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2008-01-01",
            "value": "15009.0"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2009-01-01",
            "value": "14565.1"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "дата": "01.01.2010",
            "значение": "14966.5 "
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2011-01-01",
            "value": "15286,7"
        },
        {
            «realtime_start»: «2013-08-14»,
            "realtime_end": "2013-08-14",
            "date": "2012-01-01",
            "value": "15693.1"
        }
    ]
}
 

Параметры

api_key

Прочтите ключи API для получения дополнительной информации.

• 32-символьная буквенно-цифровая строка в нижнем регистре, обязательная

file_type

Ключ или расширение файла, указывающее тип отправляемого файла.

series_id

Идентификатор серии.

realtime_start

Начало периода реального времени. Для получения дополнительной информации см. Периоды реального времени.

• Строка в формате ГГГГ-ММ-ДД, необязательно, по умолчанию: сегодняшняя дата

realtime_end

Конец периода реального времени. Для получения дополнительной информации см. Периоды реального времени.

• Строка в формате ГГГГ-ММ-ДД, необязательно, по умолчанию: сегодняшняя дата

предел

Максимальное количество возвращаемых результатов.

• целое число от 1 до 100000, необязательно, по умолчанию: 100000

смещение

• неотрицательное целое число, необязательно, по умолчанию: 0

sort_order

Сортировка результатов осуществляется в порядке возрастания или убывания даты наблюдения.

• Одна из следующих строк: «asc», «desc».
• необязательно, по умолчанию: asc

Наблюдение_старт

Начало периода наблюдения.

• Строка в формате YYYY-MM-DD, необязательно, по умолчанию: 1776-07-04 (самое раннее доступное)

наблюдение_конец

Конец периода наблюдения.

• Строка в формате YYYY-MM-DD, необязательно, по умолчанию: 9999-12-31 (последняя доступная)

шт.

Ключ, указывающий на преобразование значения данных.

• строка, необязательно, по умолчанию: lin (без преобразования)
• Одно из следующих значений: ‘lin’, ‘chg’, ‘ch2’, ‘pch’, ‘pc1’, ‘pca’, ‘cch’, ‘cca’, ‘log’

  lin = уровни (без преобразования)
  chg = изменение
  ch2 = изменение по сравнению с предыдущим годом
  pch = процентное изменение
  pc1 = процентное изменение по сравнению с предыдущим годом
  pca = совокупная годовая скорость изменения
  cch = непрерывно сложенная скорость изменения
  cca = Непрерывно начисленная годовая скорость изменения
  log = Натуральный логарифм

• Формулы преобразования единиц см. В: https: // альфред.stlouisfed.org/help#growth_formulas

частота

Необязательный параметр, указывающий на более низкую частоту агрегирования значений. Функция агрегирования частоты FRED преобразует ряды данных с более высокой частотой в ряды данных с более низкой частотой (например, преобразует ряды ежемесячных данных в ряды годовых). В FRED данные с самой высокой частотой — ежедневно, а данные с самой низкой периодичностью — за год. Доступны 3 метода агрегирования: среднее значение, сумма и конец периода.См. Параметр aggregation_method.

• строка, необязательно, по умолчанию: нет значения для отсутствия агрегирования частот
• Одно из следующих значений: ‘d’, ‘w’, ‘bw’, ‘m’, ‘q’, ‘sa’, ‘a’, ‘wef’, ‘weth’, ‘wew’, ‘wetu’ , wem, wesu, wesa, bwew, bwem

  Частот без описания периодов:

  d = ежедневно
  w = еженедельно
  bw = каждые две недели
  m = ежемесячно
  q = ежеквартально
  sa = полугодовые
  a = годовые

  Частоты с описанием периодов:

  wef = еженедельно, конечная пятница
  weth = еженедельно, конечный четверг
  wew = еженедельно, конечная среда
  wetu = еженедельно, конечный вторник
  wem = еженедельно, конечный понедельник
  wesu = еженедельно, конечное воскресенье
  wesa = еженедельно, конечная суббота
  bwew = Раз в две недели, конец среды
  bwem = Раз в две недели, конец понедельника

• Обратите внимание, что будет возвращена ошибка, если указана частота выше, чем собственная частота серии.Например, если у серии есть собственная частота «Ежемесячно» (как возвращено запросом fred / series), невозможно агрегировать ряды с более высокой частотой «Ежедневно» с использованием значения параметра частоты «d».
• Агрегирование частот не произойдет, если частота, указанная параметром частоты, совпадает с собственной частотой ряда. Например, если значение параметра частоты равно ‘m’, а собственная частота серии — ‘Ежемесячно’ (как возвращено запросом fred / series), наблюдения будут возвращены, но они не будут агрегированы с более низкой частотой.
• В большинстве случаев будет достаточно указать более низкую частоту без описания периода (например, ‘d’, ‘w’, ‘bw’, ‘m’, ‘q’, ‘sa’, ‘a’) вместо частоты с описанием периода (например, ‘wef’, ‘weth’, ‘wew’, ‘wetu’, ‘wem’, ‘wesu’, ‘wesa’, ‘bwew’, ‘bwem’), которые существуют только для еженедельной и двухнедельной периодичности.
  • Еженедельные и двухнедельные частоты с периодами существуют, чтобы предложить больше вариантов и переопределить периоды по умолчанию, подразумеваемые значениями «w» и «bw».
  • Значение «w» по умолчанию — частота и период «Еженедельно, конец пятницы» при агрегировании дневных рядов.
  • Значение «bw» по умолчанию соответствует частоте и периоду «Дважды в неделю, Конечная среда» при агрегировании дневных и недельных рядов.
  • Рассмотрим разницу между значениями «w» для «Weekly» и «wef» для «Weekly, Ending Friday». При агрегировании наблюдений от ежедневного до еженедельного, значение «w» по умолчанию равняется частоте и периоду «Еженедельно, конечная пятница», что совпадает с «wef».Здесь разница в том, что период «Конечная пятница» неявно указан для значения «w», но явным для значения «wef». Однако, если для серии задана собственная частота «Еженедельно, конец понедельника», будет возвращена ошибка для значения «wef», но не для значения «w».
• Обратите внимание, что агрегирование частоты в настоящее время доступно только для file_type, равного xml или json, из-за ограничений по времени.
• Прочтите раздел «Агрегация частот» в разделе часто задаваемых вопросов FRED. для деталей реализации.

aggregation_method

Ключ, который указывает метод агрегирования, используемый для агрегирования частот. Этот параметр не влияет, если параметр частоты не установлен.

output_type

Целое число, указывающее тип вывода.

• целое число, необязательно, по умолчанию: 1
• Одно из следующих значений: «1», «2», «3», «4».

  1 = Наблюдения по периоду в реальном времени
  2 = Наблюдения по старинной дате, все наблюдения
  3 = Наблюдения по старинной дате, только новые и исправленные наблюдения
  4 = Наблюдения, только первоначальная публикация

• Для типов вывода ‘2’ и ‘3’ некоторые имена атрибутов XML начинаются с идентификатора серии, который может иметь первый символ, являющийся числом (т. Е.е. От 0 до 9). Только в этом случае имя атрибута XML начинается с подчеркивания, а затем с идентификатора серии, чтобы избежать недопустимого XML. Если идентификатор серии начинается с буквы (например, от A до Z), то символ подчеркивания не добавляется.
• Для получения дополнительной информации прочтите: https://alfred.stlouisfed.org/help/downloaddata#outputformats

vintage_dates

Разделенная запятыми строка дат в формате YYYY-MM-DD в истории (например, 2000-01-01,2005-02-24). Для загрузки данных используются старые даты в том виде, в каком они существовали в эти указанные даты в истории.Винтажные даты могут быть указаны вместо периода реального времени с помощью realtime_start и realtime_end.

Иногда может быть полезно ввести дату выпуска, которая не является датой, когда значения данных были пересмотрены. Например, вы можете узнать последние доступные изменения на 2001-09-11 (атаки Всемирного торгового центра и Пентагона) или на дату заседания Федерального комитета по открытым рынкам (FOMC). Ввод даты урожая также полезен для сравнения серий разных выпусков с разными датами выпуска.

• строка, необязательная, по умолчанию даты не заданы.

Дросселирование запросов

Стратегию можно применить тремя способами:

Эти методы можно использовать в любой комбинации. Sitecore сочетает в себе результаты стратегий.

Sitecore использует следующие правила, когда применяет две или более стратегии для запроса:

• Если вы укажете одну и ту же стратегию несколькими способами, Sitecore применит ее только один раз.

• Если вы указываете несколько стратегий для метода или контроллера, Sitecore объединяет стратегии.

Если вы используете одну и ту же стратегию несколько раз, стратегии разделяют состояние. Например, если вы укажете стратегию скользящего окна с временным интервалом = 1000 мс, и Допустимое количество запросов = 5 запросов, параметры и примените ее к двум службам, результатом будет всего 5 запросов в любом Окно 1000 мс.

Если при применении стратегии Sitecore возникает ошибка, запрос получает внутреннюю ошибку сервера (код 500).

Использование ключа API

Когда вы применяете стратегию с помощью ключа API, Sitecore применяет стратегию ко всем запросам Sitecore.Services.Client, использующим этот ключ API. Вы можете применить стратегию, используя ключ API, а также ключ API OData.

Например:

 [ServicesController]
[RequiredApiKey]
открытый класс SampleController: ApiController
    [Маршрут ("api / throttle / datawithkey")]
    общедоступный IEnumerable <строка> GetData ()
    {
        вернуть новый []
        {
            «Ключ:» + гид.NewGuid ()
        };
    }
} 

В этом примере определен атрибут [RequiredApiKey], и ключ API является обязательным для доступа к этому контроллеру. Sitecore проверяет, действителен ли ключ API и готов ли он к использованию. Если ключ действителен, Sitecore применяет к запросу любую определенную стратегию.

Вы определяете стратегию в поле «Стратегия дросселирования» в разделе «Данные» ключевого элемента API.

Использование метода контроллера API

Чтобы применить стратегию к методу контроллера API, определите свой контроллер и примените стратегии непосредственно к действиям.Например:

 [ServicesController]
открытый класс SampleController: ApiController
{
    [Дроссельная заслонка («Скользящее окно»)]
    [Маршрут ("api / throttle / data")]
    общедоступный IEnumerable <строка> GetData ()
    {
        вернуть новый []
        {
            «Ключ:» + Guid.NewGuid ()
        };
    }
    [Дроссель ("Составной")]
    [Маршрут ("api / throttle / compositedata")]
    общедоступный IEnumerable <строка> GetCompositeData ()
    {
        вернуть новый []
        {
            «Ключ:» + Guid.NewGuid ()
        };
    }
} 

Использование контроллера

Чтобы применить стратегию к контроллеру, определите контроллер, а затем примените стратегии к классу контроллера.Например:

 [RequiredApiKey]
[Дроссельная заслонка («07 на контроллере»)]
открытый класс ThrottledOnControllerController: ApiController
{
        [Маршрут ("api / ThrottledOnController / data")]
        общедоступный IEnumerable <строка> GetData ()
        {
            return new [] {"Контроллер api / ThrottledOnController / data был вызван:" + DateTime.Now};
        }
} 

Sitecore применяет стратегию 07 On Controller к любым методам контроллера ThrottledOnControllerController .

apache 2.4 — Почему резко увеличивается время отклика при падении частоты запросов?

Чем больше я смотрю на это, тем больше склоняюсь к мысли, что есть проблема со сбором данных.

Во-первых, с вашим TPS происходит что-то действительно странное. В то время как общая картина выглядит нормально, есть очень резкий разрыв, происходящий примерно в 9 вечера, а затем снова примерно в 7 утра. Нормальный график будет намного более плавным во время перехода в непиковые часы.

Это говорит о том, что в профиле произошли изменения, и у вас, возможно, есть 2 разных типа клиентов:

1. Тот, который работает только с 7:00 до 21:00, при большой громкости, и
2. — еще один, который, вероятно, работает круглосуточно с меньшей громкостью.

Вторая подсказка около 18:00. Большую часть времени до и после мы имеем профиль громкости высокий — высокий TPS и низкая задержка. Но примерно в 18:00 происходит резкое падение с 800-1000 об / мин до менее 400 об / мин. Что могло быть причиной этого?

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

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

Следующие шаги

На этом этапе я бы глубоко погрузился в журналы, чтобы выяснить, чем отличаются сэмплы малого объема 18:00 от сэмплов большого объема до и после него.

Я бы поискал:

• различия в географическом расположении (в случае, если задержка влияет на $ request_time)
• различий в URL (не должно быть)
• различий в методе HTTP (POST / GET) (не должно быть)
• повторных запроса с одного IP
• и любые другие отличия …

Кстати, «событие» в 18:00 является для меня достаточным доказательством того, что оно не имеет ничего общего с перегрузкой / активностью центра обработки данных. Чтобы это было правдой, перегрузка должна вызвать падение TPS, которое возможно в 18:00, но крайне маловероятно, чтобы вызвать устойчивое и плавно изгибающееся падение TPS в течение 10 часов с 21:00 до 7:00.

Ограничения скорости

— API Graph — Документация

Сценарии использования для бизнеса Ограничения скорости

Все запросы Marketing API и запросы Pages API, сделанные с помощью токена доступа к системе или странице, подчиняются ограничениям скорости Business Use Case (BUC) и зависят от запрашиваемых конечных точек.

Статистика рекламы

запросов, отправленных вашим приложением к Ads Insights API, засчитываются в счетчике вызовов приложения. Счетчик вызовов приложения — это количество вызовов, которое оно может совершить в течение одного часового окна, и рассчитывается следующим образом:

Для приложений с расширенным доступом:

Звонков за час = 1

+ 400 * Количество активных объявлений - 0.001 * Ошибки пользователя

Для приложений со стандартным доступом:

Звонков в течение одного часа = 60 + 400 * Количество активных объявлений - 0,001 * Ошибки пользователей

Количество активных объявлений — это количество объявлений, показываемых в настоящее время на рекламный аккаунт. Ошибки пользователя — это количество ошибок, полученных при вызове API.

Управление рекламой

Для v4.0 + приложения следуют ограничениям скорости BUC.

запросов, отправленных вашим приложением к Ads Management API, засчитываются в счетчике вызовов приложения.Счетчик вызовов приложения — это количество вызовов, которое оно может совершить в течение одного часового окна, и рассчитывается следующим образом:

Для приложений с расширенным доступом:

Звонков в течение одного часа = 100000 + 40 * Количество активных объявлений

Для приложений со стандартным доступом:

Звонков в течение одного часа = 300 + 40 * Количество активных объявлений

Количество активных объявлений — это количество объявлений для каждой рекламной учетной записи.

Для Graph API v3.3 и старше приложения следуют логике ограничения скорости Marketing API до 29 октября 2019 г., когда все приложения будут автоматически перенесены в логику BUC.

Индивидуальная аудитория

Для v4.0 + приложения следуют ограничениям скорости BUC.

запросов, сделанных вашим приложением к Custom Audience API, засчитываются в счетчик вызовов приложения. Счетчик вызовов приложения — это количество вызовов, которое оно может совершить в течение одного часового окна, и рассчитывается следующим образом, но никогда не превышает 700000:

Для приложений с расширенным доступом:

Звонков в течение одного часа = 1

+ 40 * Количество активных настраиваемых аудиторий

Для приложений со стандартным доступом:

Звонков в течение одного часа = 5000 + 40 * Количество активных настраиваемых аудиторий

Число активных настраиваемых аудиторий — это количество активных настраиваемых аудиторий для каждой рекламной учетной записи.

Для Graph API v3.3 и старше приложения следуют логике ограничения скорости Marketing API до 29 октября 2019 г., когда все приложения будут автоматически перенесены в логику BUC.

Instagram Graph API

вызовов API-интерфейса Instagram Graph засчитываются в счетчик вызовов вызывающего приложения. Счетчик вызовов приложения уникален для каждой пары приложение и приложение пользователя и представляет собой количество вызовов, выполненных приложением в скользящем 24-часовом окне. Рассчитывается следующим образом:

Звонков в течение 24 часов = 4800 * Количество показов

Количество показов — это количество раз, когда любой контент из учетной записи Instagram пользователя приложения попал на экран человека за последние 24 часа.

Банкноты

LeadGen

Для v4.0 + приложения следуют ограничениям скорости BUC.

запросов, отправленных вашим приложением к LeadGen API, засчитываются в счетчике вызовов приложения. Счетчик вызовов приложения — это количество вызовов, которые оно может совершить в течение 24-часового окна, и рассчитывается следующим образом:

Звонков в течение 24 часов = 4800 * Сгенерированных лидов

Количество сгенерированных лидов — это количество лидов, сгенерированных на страницу для этого Рекламного Аккаунта за последние 30 дней.

Для Graph API v3.3 и старше приложения следуют логике ограничения скорости Marketing API до 29 октября 2019 г., когда все приложения будут автоматически перенесены в логику BUC.

Посланник

Для v4.0 + приложения следуют ограничениям скорости BUC.

запросов, сделанных вашим приложением к Messenger API, засчитываются в счетчик вызовов приложения. Счетчик вызовов приложения — это количество вызовов на страницу, которое оно может совершить в течение 24-часового окна, и рассчитывается следующим образом:

Звонков в течение 24 часов = 4800 * Количество вовлеченных пользователей

Количество вовлеченных пользователей — это количество пользователей, которым ваше приложение может отправлять сообщения.

Для Graph API v3.3 и старше приложения следуют логике ограничения скорости Marketing API до 29 октября 2019 г., когда все приложения будут автоматически перенесены в логику BUC.

Страниц

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

Запросы, сделанные вашим приложением к Pages API с использованием токена доступа к странице или системного токена доступа пользователя, учитываются при подсчете количества вызовов приложения. Счетчик вызовов приложения — это количество вызовов, которое оно может совершить в течение одного часового окна, и рассчитывается следующим образом:

Звонков в течение одного часа = 4800 * Количество вовлеченных пользователей

Количество вовлеченных пользователей — это количество пользователей, которые взаимодействовали со страницей в течение 24 часов.

Запросы, сделанные вашим приложением к API страниц с использованием токена доступа пользователя или токена доступа к приложению, следуют логике ограничения скорости платформы.

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

Заголовки

Все ответы API, сделанные вашим приложением, которые ограничены по скорости с помощью логики BUC, включают заголовок HTTP X-Business-Use-Case-Usage (для v3.3 и более ранних вызовов Ads API) со строкой в ​​формате JSON, описывающей текущее использование лимита нормы внесения. Этот заголовок может возвращать до 32 объектов за один вызов.

Содержание заголовка использования X-Business-Use-Case

Код ошибки	Значение Описание
business-id	Идентификатор предприятия, связанного с токеном, выполняющим вызовы API.
call_count	Целое число, выражающее процент разрешенных вызовов, совершенных вашим приложением за период в один час.
Estimated_time_to_regain_access	Время в минутах до прекращения регулирования вызовов.
total_cputime	Целое число, выражающее процент процессорного времени, выделенного на обработку запросов.
total_time	Целое число, выражающее процент от общего времени, выделенного на обработку запроса.
тип	Тип применяемого ограничения скорости. Значение может быть одним из следующих: ads_insights , ads_management , custom_audience , instagram , leadgen , messenger или страниц .

Общее время ЦП

Количество процессорного времени, которое требуется для обработки запроса. Когда total_cputime достигает 100, вызовы могут регулироваться.

Общее время

Время, необходимое для обработки запроса. Когда total_time достигает 100, вызовы могут быть ограничены.

Пример значения заголовка X-Business-Use-Case-Usage

 x-business-use-case-usage: {
    "{идентификатор-бизнес-объекта}": [
        {
            "type": "{rate-limit-type}", // Тип применяемой логики ограничения скорости BUC."call_count": 100, // Процент совершенных звонков.
            "total_cputime": 25, // Процент общего использованного процессорного времени.
            "total_time": 25, // Процент от общего времени, которое было использовано.
            "Estimated_time_to_regain_access": 19 // Время в минутах, чтобы восстановить доступ.
        }
    ],
    "66782684": [
        {
            "type": "ads_management",
            "call_count": 95,
            "total_cputime": 20,
            "total_time": 20,
            «приблизительное_время_то_регайн_акцесс»: 0
        }
    ],
    "10153848260347724": [
        {
            "type": "ads_management",
            "call_count": 97,
            "total_cputime": 23,
            "total_time": 23,
            «приблизительное_время_то_регайн_акцесс»: 0
        }
    ],
...
} 

Коды ошибок

Когда ваше приложение достигает предела скорости бизнес-варианта использования, последующие запросы, сделанные вашим приложением, завершатся ошибкой, и API ответит кодом ошибки.

Код ошибки	Тип ограничения скорости BUC
код ошибки 80000, субкод ошибки 2446079	Ads Insights
код ошибки 80004, субкод ошибки 2446079	Управление рекламой
код ошибки 80003, субкод ошибки 2446079	Индивидуальная аудитория
код ошибки 80002	Instagram
код ошибки 80005	LeadGen
код ошибки 80006	Посланник
код ошибки 32	Вызовы страниц, сделанные с помощью токена доступа пользователя
код ошибки 80001	Вызовы страницы, сделанные с помощью токена доступа пользователя страницы или системы
код ошибки 17, субкод ошибки 2446079	V3.3 и более ранние версии Ads API, за исключением Ads Insights .

Пример сообщения с кодом ошибки

 {
"ошибка": {
    "message": "(# 80001) Слишком много обращений к этой учетной записи Page. Подождите немного и повторите попытку. Для получения дополнительной информации перейдите по ссылке https://developers.facebook.com/docs/graph-api/ обзор / ограничение скорости. ",
    "тип": "OAuthException",
    «код»: 80001,
    "fbtrace_id": "AmFGcW_3hwDB7qFbl_QdebZ"
    }
} 

Передовой опыт

• По достижении лимита прекратите выполнение вызовов API.Продолжая совершать звонки, вы будете продолжать увеличивать количество звонков, что увеличит время до того, как звонки снова станут успешными.
• Проверьте HTTP-заголовок X-Business-Use-Case-Usage , чтобы узнать, насколько близок ваш рекламный аккаунт к пределу и когда вы можете возобновить звонки.
• Проверьте код ошибки и конечную точку API, чтобы подтвердить тип регулирования.
• Переключитесь на другие рекламные аккаунты и вернитесь к этому аккаунту позже.
• Лучше создать новое объявление, чем менять существующие.
• Распределите запросы равномерно между двумя временными интервалами, чтобы избежать пиков трафика.
• Используйте фильтры, чтобы ограничить размер ответа данных и избежать вызовов, которые запрашивают перекрывающиеся данные.

Руководство по регулированию Microsoft Graph — Microsoft Graph

• 05.12.2020
• Читать 20 минут

В этой статье

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

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

Что происходит при дросселировании?

При превышении порога регулирования Microsoft Graph ограничивает любые дальнейшие запросы от этого клиента на определенный период времени.Когда происходит регулирование, Microsoft Graph возвращает код состояния HTTP 429 (слишком много запросов), и запросы не выполняются. Предлагаемое время ожидания возвращается в заголовке ответа на неудавшийся запрос. Поведение регулирования может зависеть от типа и количества запросов. Например, если у вас большой объем запросов, все типы запросов регулируются. Пределы порогов зависят от типа запроса. Таким образом, вы можете столкнуться со сценарием, когда записи регулируются, но чтение по-прежнему разрешено.

Распространенные сценарии дросселирования

К наиболее частым причинам ограничения количества клиентов относятся:

• Большое количество запросов по всем приложениям в клиенте.
• Большое количество запросов от определенного приложения по всем клиентам.

Пример ответа

Каждый раз при превышении порога регулирования Microsoft Graph отвечает аналогичным ответом.

  HTTP / 1.1 429 Слишком много запросов
Тип содержимого: приложение / json
Повторить после: 2,128

{
  "ошибка": {
    "code": "TooManyRequests",
    "innerError": {
      «код»: «429»,
      "date": "2020-08-18T12: 51: 51",
      "message": "Повторите попытку через",
      "идентификатор-запроса": "94fb3b52-452a-4535-a601-69e0a90e3aa2",
      "status": "429"
    },
    "message": "Повторите попытку позже."
  }
}
  

Рекомендации по регулированию дросселирования

Ниже приведены рекомендации по управлению дросселированием:

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

При реализации обработки ошибок используйте код ошибки HTTP 429 для обнаружения дросселирования. Неудачный ответ включает заголовок ответа Retry-After .Отклонение запросов с использованием задержки Retry-After — это самый быстрый способ восстановления после дросселирования, поскольку Microsoft Graph продолжает регистрировать использование ресурсов во время дросселирования клиента.

1. Подождите количество секунд, указанное в заголовке Retry-After .
2. Повторите запрос.
3. Если запрос снова завершается ошибкой с кодом 429, вы все еще ограничиваетесь. Продолжайте использовать рекомендуемую задержку Retry-After и повторяйте запрос до тех пор, пока он не будет успешным.

Все ресурсы и API, описанные в разделе «Ограничения для конкретных служб», предоставляют заголовок Retry-After , если не указано иное.

Более подробное обсуждение регулирования в Microsoft Cloud см. В разделе Шаблон регулирования.

Примечание

Если в ответе отсутствует заголовок Retry-After , рекомендуется реализовать политику повторных попыток экспоненциальной отсрочки передачи. Вы также можете реализовать более сложные шаблоны при создании крупномасштабных приложений.

Microsoft Graph SDK уже реализует обработчики, которые полагаются на заголовок Retry-After или по умолчанию используют политику повторных попыток экспоненциальной отсрочки.

Рекомендации по предотвращению удушения

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

Дросселирование и дозирование

Пакетная обработка

JSON позволяет оптимизировать приложение путем объединения нескольких запросов в один объект JSON. Запросы в пакете оцениваются индивидуально на соответствие ограничениям регулирования, и если какой-либо запрос превышает эти ограничения, он завершается сбоем со статусом из 429 и ошибкой, аналогичной приведенной выше. Сам пакет завершается ошибкой с кодом состояния 424 (Failed Dependency). Возможно регулирование нескольких запросов в одном пакете.Вы должны повторять каждый неудачный запрос из пакета, используя значение, указанное в заголовке ответа retry-after из содержимого JSON. Вы можете повторить все неудавшиеся запросы в новом пакете после самого длинного повторных попыток после значения .

Если пакеты SDK автоматически повторяют дросселированные запросы, когда они не были объединены в пакет, дросселированные запросы, которые были частью пакета, не повторяются автоматически.

Пределы для конкретных услуг

Microsoft Graph позволяет получать доступ к данным в нескольких службах, таких как Outlook или Azure Active Directory.Эти службы устанавливают собственные ограничения регулирования, влияющие на приложения, использующие Microsoft Graph для доступа к ним.

Любой запрос может быть оценен по нескольким ограничениям, в зависимости от области ограничения (для каждого приложения для всех клиентов, для каждого клиента для всех приложений, для каждого приложения для каждого клиента и т. Д.), Типа запроса (GET, POST, PATCH, и так далее) и другие факторы. Первый достигнутый предел вызывает дросселирование. В дополнение к ограничениям для конкретных услуг, описанным в разделе, применяются следующие общие ограничения:

Тип запроса	На приложение для всех клиентов
Любая	2000 запросов в секунду

Примечание

Конкретные описанные здесь ограничения могут быть изменены.

Примечание: В этом разделе термин клиент относится к организации Microsoft 365, в которой установлено приложение. Этот клиент может быть таким же, как тот, в котором приложение было создано, в случае приложения с одним клиентом, или он может быть другим, в случае приложения с несколькими арендаторами.

Ограничения службы Outlook

Ограничения службы

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

Лимит	Относится к
10 000 запросов API за 10 минут	v1.0 и конечные точки бета
4 одновременных запроса	v1.0 и конечные точки бета
Загрузка 15 мегабайт (МБ) (PATCH, POST, PUT) за 30 секунд	v1.0 и бета-версии

Ресурсы службы Outlook

Следующие ресурсы предоставляются службой Outlook.

Ресурсы Search API (предварительная версия)

Ресурсы API профиля

Ресурсы Calendar API

Ресурсы API почты

Ресурсы API личных контактов

Социальные ресурсы и информационные ресурсы на рабочем месте

Ресурсы API задач To-do (предварительная версия)

Ограничения облачной связи

Ресурс	Лимиты на приложение для каждого клиента
Звонки	10 000 звонков в месяц и 100 одновременных звонков
Информация о встрече	2000 встреч / пользователь ежемесячно
Присутствие (превью)	1500 запросов за 30 секунд, на одно приложение на одного клиента

Ограничения службы OneNote

Тип ограничения	Ограничение на приложение на пользователя (делегированный контекст)	Ограничение на приложение (контекст только приложения)
Частота запросов	120 запросов за 1 минуту и ​​400 за 1 час	240 запросов за 1 минуту и ​​800 за 1 час
Одновременные запросы	5 одновременных запросов	20 одновременных запросов

Вышеуказанные ограничения применяются к следующим ресурсам:
onenote, notebook, sectionGroup, onenoteSection, onenotePage, onenoteResource, onenoteOperation

Вы можете найти дополнительную информацию о передовых методах регулирования API OneNote и о том, как этого избежать.

Примечание: Ресурсы, перечисленные выше, не возвращают заголовок Retry-After в ответах 429 Too Many Requests .

Лимиты обслуживания Project Rome

Тип запроса	Лимит на пользователя для всех приложений
ПОЛУЧИТЬ	400 запросов за 5 минут и 12000 запросов за 1 день
POST, PUT, PATCH, DELETE	100 запросов за 5 минут и 8000 запросов за 1 день

Предыдущие ограничения применяются к следующим ресурсам:
activityHistoryItem, userActivity

Ограничения службы Microsoft Teams

Пределы выражаются в запросах в секунду (об / с).

Тип запроса команды	Лимит на приложение на одного клиента	Лимит на приложение для всех клиентов
Любые вызовы API Graph для Microsoft Teams	15000 запросов каждые 10 секунд	нет данных
Команда GET, канал, вкладка, установленные приложения, каталоги приложений	60 об / с	600 об / с
Канал POST / PUT, вкладка, установленные приложения, каталоги приложений	30 об / с	300 об / с
Команда PATCH, канал, вкладка, установленные приложения, каталоги приложений	30 об / с	300 об / с
УДАЛИТЬ канал, вкладку, установленные приложения, каталоги приложений	15 об / с	150 об / с
GET / team / {team-id} , присоединился к командам	30 об / с	300 об / с
POST / team / {team-id} , PUT / groups / {team-id} / team, clone	6 об / с	150 об / с
GET сообщение канала	5 об / с	100 об / с
GET 1: 1 / сообщение группового чата	3 об / с	30 об / с
Сообщение канала POST	2 об / с	20 об / с
POST 1: 1 / сообщение группового чата	2 об / с	20 об / с
GET / team / {team-id} / schedule и все API по этому пути	60 об / с	600 об / с
POST, PATCH, PUT / team / {team-id} / schedule и все API по этому пути	30 об / с	300 об / с
DELETE / team / {team-id} / schedule и все API по этому пути	15 об / с	150 об / с

Максимум 4 запроса в секунду на одно приложение может быть выполнено для данной команды или канала.По одному каналу можно отправлять не более 3000 сообщений на одно приложение в день.

См. Также ограничения Microsoft Teams и требования к опросу.

Приведенные выше ограничения применяются к следующим ресурсам:
aadUserConversationMember, appCatalogs, changeTrackedEntity, channel, chatMessage, chatMessageHostedContent, chatMember, offerShiftRequest, openShift, openShiftChangeRequestuling, schedule, scheduleChangeRequest, командах , teamAsyncOperation, teamTab, teamTemplate, работа в команде, timeOff, timeOffReason, timeOffRequest, userSettings, workforceIntegration.

Ограничения служб идентификации и доступа

Эти лимиты на услуги применяются к следующим организациям:

Узор

Регулирование основано на алгоритме ведра токенов, который работает путем добавления индивидуальных затрат на запросы. Затем сумма затрат на запрос сравнивается с заранее установленными лимитами. Будут ограничиваться только запросы, превышающие лимиты. Если любое из ограничений будет превышено, ответ будет 429 Слишком много запросов . Можно получить ответы 429 Too Many Requests , даже если следующие ограничения не достигнуты, в ситуациях, когда службы находятся под большой нагрузкой или в зависимости от объема данных для определенного клиента.В следующей таблице перечислены существующие ограничения.

Тип ограничения	Квота единицы ресурса	Квота записи
приложение + пара арендаторов	S: 3500, M: 5000, L: 8000 за 10 секунд	3000 за 2 минуты 30 секунд
заявка	150 000 за 20 секунд	70 000 за 5 минут
арендатор	Не применимо	18 000 за 5 минут

Примечание : ограничение пары приложение + клиент зависит от количества пользователей, с которыми выполняются запросы клиента.Размеры арендаторов определяются следующим образом: S — до 50 пользователей, M — от 50 до 500 пользователей и L — более 500 пользователей.

В следующей таблице перечислены базовые затраты на запрос. Любые запросы, не указанные в списке, имеют базовую стоимость 1.

.

Эксплуатация	Путь запроса	Базовая стоимость единицы ресурса	Стоимость записи
ПОЛУЧИТЬ	заявок	2	0
ПОЛУЧИТЬ	приложений / {id} / extensionProperties	2	0
ПОЛУЧИТЬ	контрактов	3	0
ПОСТ	каталогObjects / getByIds	3	0
ПОЛУЧИТЬ	доменов / {id} / domainNameReferences	4	0
ПОСТ	getObjectsById	3	0
ПОЛУЧИТЬ	групп / {id} / участников	3	0
ПОЛУЧИТЬ	групп / {id} / transitiveMembers	5	0
ПОСТ	является членом	4	0
ПОСТ	мне / checkMemberGroups	4	0
ПОСТ	мне / checkMemberObjects	4	0
ПОСТ	мне / getMemberGroups	2	0
ПОСТ	мне / getMemberObjects	2	0
ПОЛУЧИТЬ	мне / лицензияПодробнее	2	0
ПОЛУЧИТЬ	я / член	2	0
ПОЛУЧИТЬ	мне / в собственности Объекты	2	0
ПОЛУЧИТЬ	мэ / переходный член	2	0
ПОЛУЧИТЬ	oauth3PermissionGrants	2	0
ПОЛУЧИТЬ	oauth3PermissionGrants / {id}	2	0
ПОЛУЧИТЬ	servicePrincipals / {id} / appRoleAssignments	2	0
ПОЛУЧИТЬ	подписан Skus	3	0
ПОЛУЧИТЬ	пользователей	2	0
ПОЛУЧИТЬ	Любой путь идентификации, не указанный в таблице	1	0
ПОСТ	Любой путь идентификации, не указанный в таблице	1	1
ПАТЧ	Любой путь идентификации, не указанный в таблице	1	1
ПОЛОЖИТЬ	Любой путь идентификации, не указанный в таблице	1	1
УДАЛИТЬ	Любой путь идентификации, не указанный в таблице	1	1

Другие факторы, влияющие на стоимость запроса:

• Использование $ select снижает стоимость на 1
• Использование расширения $ увеличивает стоимость на 1
• Использование $ top со значением менее 20 снижает стоимость на 1

Примечание: Стоимость запроса никогда не может быть меньше 1.Любая стоимость запроса, которая применяется к пути запроса, начинающемуся с me / , также применяется к эквивалентным запросам, начинающимся с пользователей / {id | userPrincipalName} / .

Дополнительные заголовки

Заголовки запроса

• x-ms-throttle-priority — Если заголовок не существует или имеет любое другое значение, это указывает на нормальный запрос. Мы рекомендуем устанавливать приоритет , высокий только для запросов, инициированных пользователем. Значения этого заголовка могут быть следующими:
  • Низкий — указывает, что запрос имеет низкий приоритет.Регулирование этого запроса не вызывает видимых пользователем сбоев.
  • Нормальный — По умолчанию, если значение не указано. Указывает, что запрос имеет приоритет по умолчанию.
  • Высокий — указывает, что запрос имеет высокий приоритет. Регулирование этого запроса вызывает видимые для пользователя сбои.

Примечание: Если запросы регулируются, запросы с низким приоритетом будут регулироваться первыми, запросы с обычным приоритетом — вторыми, а запросы с высоким приоритетом — последними. Использование заголовка запроса приоритета не меняет ограничений.

Обычные запросы ответов

• x-ms-resource-unit — указывает ресурсную единицу, используемую для этого запроса. Значения — положительные целые числа.
• x-ms-throttle-limit-percent — Возвращается, только когда приложение потребляет более 0,8 от своего лимита. Значение варьируется от 0,8 до 1,8 и представляет собой процент от использования лимита. Это значение может использоваться вызывающими абонентами для настройки оповещения и принятия мер.

Запросы с регулируемыми ответами

• x-ms-throttle-scope — например. Tenant_Application / ReadWrite / 9a3d526c-b3c1-4479-ba74-197b5c5751ae / 0785ef7c-2d7a-4542-b048-95bcab406e0b . Указывает область регулирования в следующем формате: / / / :
  • Объем: (строка, обязательно)
    • Tenant_Application — все запросы конкретного клиента для текущего приложения.
    • Tenant — Все запросы для текущего клиента, независимо от приложения.
    • Приложение — Все запросы для текущего приложения.
  • Лимит: (строка, обязательно)
    • Чтение: запросы на чтение для области (GET)
    • Запись: запросы записи для области (POST, PATCH, PUT, DELETE …)
    • ReadWrite: все запросы для области (любой)
  • ApplicationId (Guid, обязательно)
  • TenantId | UserId | ResourceId: (Guid, обязательно)
• x-ms-throttle-information — указывает причину дросселирования и может иметь любое значение (строка).Значение предоставляется для диагностики и устранения неполадок, некоторые примеры включают:
  • CPULimitExceeded — регулирование вызвано превышением лимита выделения ЦП.
  • WriteLimitExceeded — регулирование вызвано превышением лимита записи.
  • ResourceUnitLimitExceeded — регулирование вызвано превышением предела для выделенной единицы ресурса.

Защита информации

Следующие ограничения применяются к любому запросу на / informationProtection .

Эксплуатация	Лимит на арендатора	Лимит на ресурс (электронная почта, URL, файл)
ПОСТ	150 запросов за 15 минут и 10000 запросов за 24 часа	1 запрос в 15 минут и 3 запроса в 24 часа

Вышеуказанные ограничения применяются к следующим ресурсам:
ThreatAssessmentRequest, ThreatAssessmentResult, mailAssessmentRequest, emailFileAssessmentRequest, fileAssessmentRequest, urlAssessmentRequest.

Ограничения службы защиты личных данных и условного доступа

Тип запроса	Лимит на одного клиента для всех приложений
Любая	1 запрос в секунду

Предыдущие ограничения применяются к следующим ресурсам:
riskDetection, riskyUser, riskyUserHistoryItem, namedLocation, countryNamedLocation, ipNamedLocation, conditionalAccessPolicy.

Примечание: Ресурсы, перечисленные выше, не возвращают заголовок Retry-After в ответах 429 Too Many Requests .

Сервисные ограничения Insights

Следующие ограничения применяются к любому запросу на me / insights или users / {id} / insights .

Лимит	Относится к
10 000 запросов API за 10 минут	v1.0 и конечные точки бета
4 одновременных запроса	v1.0 и конечные точки бета

Предыдущие ограничения применяются к следующим ресурсам:
человек, тенденции, usedinsight, sharedInsight.

Ограничения службы отчетов Microsoft Graph

Следующие ограничения применяются к любому запросу на / отчеты .

Эксплуатация	Лимит на приложение на одного клиента	Лимит на одного клиента для всех приложений
Любой запрос (CSV)	14 запросов за 10 минут	40 запросов за 10 минут
Любой запрос (JSON, beta)	100 запросов за 10 минут	нет данных

Предыдущие ограничения применяются индивидуально к каждому API отчета.Например, запрос к API отчета об активности пользователей Microsoft Teams и запрос к API отчета о пользовательской активности Outlook в течение 10 минут будут считаться 1 запросом из 14 для каждого API, а не 2 запросами из 14 для обоих.

Предыдущие ограничения применяются к ресурсу report .

Лимиты услуг менеджера по приглашениям

Следующие ограничения применяются к любому запросу на / приглашения .

Эксплуатация	Лимит на одного клиента для всех приложений
Любая операция	150 запросов за 5 секунд

Обнаружения безопасности и ограничения обслуживания инцидентов

Следующие ограничения применяются к любому запросу на / безопасность .

Эксплуатация	Лимит на приложение на одного клиента
Любая операция с предупреждением , securityActions , secureScore	150 запросов в минуту
Любая операция на tiIndicator	1000 запросов в минуту
Любая операция на secureScore или secureScorecontrolProfile	10 000 запросов API за 10 минут
Любая операция на secureScore или secureScorecontrolProfile	4 одновременных запроса

Ограничения для служб открытых и расширений схемы

Тип запроса	Лимит на приложение на одного клиента
Любая	455 запросов за 10 секунд

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

Файлы и списки служебных лимитов

Ограничения службы

для OneDrive, OneDrive для бизнеса и SharePoint Online недоступны. Для получения дополнительной информации см. Почему вы не можете просто сказать мне точные пределы дросселирования ?.

Приведенная выше информация относится к следующим ресурсам:
baseItem, baseItemVersion, columnDefinition, columnLink, contentType, drive, driveItem, driveItemVersion, fieldValueSet, itemActivity, itemActivityStat, itemAnalytics, list, listItem, listItemVersion, permission, sharedDriveItem, site and thumbnail.

Лимиты обслуживания задач и планов

Лимиты обслуживания для Planner недоступны.

Приведенная выше информация применима к следующим ресурсам:
planner, plannerAssignedToTaskBoardTaskFormat, plannerBucket, plannerBucketTaskBoardTaskFormat, plannerGroup, plannerPlan, plannerPlanDetails, plannerProgressTaskBoardTaskFormator, plannerTask

Ограничения службы политики данных идентификации и доступа к данным

Тип запроса	Лимит на арендатора
Пост на экспорт Персональные данные	1000 запросов в день по любой теме и 100 запросов по теме в день
Любой другой запрос	10000 запросов в час

Вышеуказанные ограничения применяются к следующим ресурсам: dataPolicyOperation.

Примечание: Ресурсы, перечисленные выше, не возвращают заголовок Retry-After в ответах 429 Too Many Requests .

Лимиты образовательных услуг

Тип запроса	Лимит на приложение для всех арендаторов	Лимит на приложение на одного клиента
Любая	23000 запросов за 10 секунд	50000 запросов за 10 секунд

Предыдущие ограничения применяются к следующим ресурсам:
educationClass, educationOrganization, educationRoot, educationSchool, educationStudent, educationTeacher, educationTerm, educationUser.

Ограничения службы Excel

Тип запроса	Лимит на приложение для всех арендаторов	Лимит на приложение на одного клиента
Любая	5000 запросов за 10 секунд	1500 запросов за 10 секунд

Приведенные выше ограничения применяются к следующим ресурсам:
рабочей книги, workbookApplication, workbookChart, workbookChartAreaFormat, workbookChartAxes, workbookChartAxis, workbookChartAxisFormat, workbookChartAxisTitle, workbookChartAxisTitleFormat, workbookChartDataLabelFormat, workbookChartDataLabels, workbookChartFill, workbookChartFont, workbookChartGridlines, workbookChartGridlinesFormat, workbookChartLegend, workbookChartLegendFormat, workbookChartLineFormat, workbookChartPoint, workbookChartPointFormat, workbookChartSeries, workbookChartSeriesFormat, workbookChartTitle, workbookChartTitleFormat, workbookComment, workbookCommentReply, workbookFilter, workbookFormatProtection, workbookFunctionResult, workbookFunctions, workbookNamedItem, workbookOperation, workbookPivotTable, workbookRange, workbookRangeBorder, workbookRangeFill, workbookRangeFont, workbookRangeFormat, workbookRangeSort, workbookRangeView, workbookTable, workbookTableColumn, workbookTable Строка, workbookTableSort, workbookWorksheet, workbookWorksheetProtection.

Ограничения службы журналов аудита идентификации и доступа

Тип запроса	Лимит на приложение на одного клиента
Любая	100 запросов за 10 секунд

Вышеуказанные ограничения применяются к следующим ресурсам:
auditLogRoot, directoryAudit, limitedSignIn, signIn.

Ограничения на услуги провайдеров идентификационной информации

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
Любая	300 запросов в минуту	200 запросов в минуту

Предыдущие ограничения применяются к следующим ресурсам:
identityContainer, identityProvider.

Ограничения службы Intune

Ограничения службы приложений Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Приведенные выше ограничения применяются к следующим ресурсам:
iosMobileAppConfiguration, managedDeviceMobileAppConfiguration, managedDeviceMobileAppConfigurationAssignment, managedDeviceMobileAppConfigurationDeviceStatus, managedDeviceMobileAppConfigurationDeviceSummary, managedDeviceMobileAppConfigurationUserStatus, managedDeviceMobileAppConfigurationUserSummary, MobileApp, mobileAppAssignment, MobileAppCategory, mobileAppContent, mobileAppContentFile.

Ограничения службы книг Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
deviceInstallState, eBookInstallSummary, iosVppEBook, iosVppEBookAssignment, managedEBook, managedEBookAssignment, userInstallStateSummary.

Ограничения обслуживания условий компании Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
termsAndConditions, termsAndConditionsAcceptanceStatus, termsAndConditionsAssignment.

Ограничения службы настройки устройства Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Приведенные выше ограничения применяются к следующим ресурсам:
deviceComplianceActionItem, deviceComplianceDeviceOverview, deviceComplianceDeviceStatus, deviceCompliancePolicy, deviceCompliancePolicyAssignment, deviceCompliancePolicyDeviceStateSummary, deviceCompliancePolicySettingStateSummary, deviceCompliancePolicyState, deviceComplianceScheduledActionForRule, deviceComplianceSettingState, deviceComplianceUserOverview, deviceComplianceUserStatus, deviceConfiguration, deviceConfigurationAssignment, deviceConfigurationDeviceOverview, deviceConfigurationDeviceStateSummary, deviceConfigurationDeviceStatus, deviceConfigurationState, deviceConfigurationUserOverview, deviceConfigurationUserStatus, deviceManagement, iosUpdateDeviceStatus, settingStateDeviceSummary, softwareUpdateStatusSummary.

Ограничения службы регистрации устройств Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Приведенные выше ограничения применяются к следующим ресурсам:
complianceManagementPartner, deviceAppManagement, DeviceCategory, deviceEnrollmentConfiguration, deviceEnrollmentLimitConfiguration, deviceEnrollmentPlatformRestrictionsConfiguration, deviceEnrollmentWindowsHelloForBusinessConfiguration, deviceManagementExchangeConnector, deviceManagementPartner, enrollmentConfigurationAssignment, mobileThreatDefenseConnector, onPremisesConditionalAccessSettings, vppToken.

Ограничения службы устройств Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	400 запросов за 20 секунд	200 запросов за 20 секунд
Любая	4000 запросов за 20 секунд	2000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
applePushNotificationCertificate, detectApp, managedDevice, managedDeviceOverview.

Ограничения службы регистрации Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Приведенные выше ограничения применяются к следующим ресурсам:
complianceManagementPartner, deviceAppManagement, DeviceCategory, deviceEnrollmentConfiguration, deviceEnrollmentLimitConfiguration, deviceEnrollmentPlatformRestrictionsConfiguration, deviceEnrollmentWindowsHelloForBusinessConfiguration, deviceManagementExchangeConnector, deviceManagementPartner, enrollmentConfigurationAssignment, mobileThreatDefenseConnector, onPremisesConditionalAccessSettings, vppToken.

Ограничения службы управляемых приложений Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Приведенные выше ограничения применяются к следующим ресурсам:
managedAppOperation, managedAppPolicy, managedAppPolicyDeploymentSummary, managedAppRegistration, managedAppStatus, managedMobileApp, targetManagedAppPolicyAssignment, windowsInformationProtectionAppLockerFile.

Ограничения службы уведомлений Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
localizedNotificationMessage, notificationMessageTemplate.

Ограничения службы rbac Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
resourceOperation, roleAssignment, roleDefinition.

Ограничения службы удаленной помощи Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Вышеуказанные ограничения применяются к следующим ресурсам:
remoteAssistancePartner.

Ограничения службы отчетов Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Вышеуказанные ограничения применяются к следующим ресурсам:
auditLogRoot, directoryAudit, limitedSignIn, signIn.

Ограничения службы TEM для Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
telecomExpenseManagementPartner.

Ограничения службы устранения неполадок Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
deviceManagementTroubleshootingEvent, enrollmentTroubleshootingEvent.

Ограничения службы очистки Intune

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	200 запросов за 20 секунд	100 запросов за 20 секунд
Любая	2000 запросов за 20 секунд	1000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
windowsInformationProtectionAppLearningSummary, windowsInformationProtectionNetworkLearningSummary.

Лимиты услуг Skype

Тип запроса	Лимит на приложение для всех арендаторов
Любая	5000 запросов за 10 секунд

Приведенные выше ограничения применяются к следующим ресурсам:
call, cancelMediaProcessingOperation, cloudCommunications, commsOperation, invitParticipantsOperation, muteParticipantOperation, onlineMeeting, members, playPromptOperation, recordOperation, subscribeToToneOperationOperation, unmuteusPartOperation

Лимиты подписки на услуги

Тип запроса	Лимит на одного клиента для всех приложений	Лимит на приложение на одного клиента
POST, PUT, DELETE, PATCH	10000 запросов за 20 секунд	5000 запросов за 20 секунд
Любая	10000 запросов за 20 секунд	5000 запросов за 20 секунд

Предыдущие ограничения применяются к следующим ресурсам:
подписка.

Лимиты услуг по присвоению

На запросы к API бета-версии службы назначений действуют следующие ограничения:

Тип запроса	Лимит на приложение на одного клиента	Лимит на одного клиента для всех приложений
Любая	5000 запросов за 10 секунд	15 000 запросов за 10 секунд
ПОЛУЧИТЬ / Назначение	50 запросов за 10 секунд	150 запросов за 10 секунд

Вышеуказанные ограничения применяются к следующим ресурсам: образование образование educationResource

Flask by Example — Обработка текста с помощью запросов, BeautifulSoup и NLTK — Real Python

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

  import os
запросы на импорт
оператор импорта
импорт ре
импортировать nltk
from flask import Flask, render_template, request
из flask_sqlalchemy импорт SQLAlchemy
from stop_words импорт останавливается
из коллекций счетчик импорта
из bs4 импорт BeautifulSoup


app = Flask (__ имя__)
app.config.from_object (os.environ ['APP_SETTINGS'])
app.config ['SQLALCHEMY_TRACK_MODIFICATIONS'] = Истина
db = SQLAlchemy (приложение)

из импорта моделей Результат


@приложение.route ('/', методы = ['GET', 'POST'])
def index ():
    ошибки = []
    результаты = {}
    если request.method == "POST":
        # получить URL, который ввел человек
        пытаться:
            url = request.form ['url']
            r = requests.get (URL)
        Кроме:
            errors.append (
                «Не удалось получить URL. Убедитесь, что он действителен, и повторите попытку».
            )
            вернуть render_template ('index.html', errors = errors)
        если r:
            # обработка текста
            raw = BeautifulSoup (г.текст, 'html.parser'). get_text ()
            nltk.data.path.append ('./ nltk_data /') # установить путь
            tokens = nltk.word_tokenize (необработанный)
            text = nltk.Text (токены)
            # убрать пунктуацию, подсчитать сырые слова
            nonPunct = re.compile ('. * [A-Za-z]. *')
            raw_words = [w вместо w в тексте, если неPunct.match (w)]
            raw_word_count = Счетчик (raw_words)
            # стоп-слова
            no_stop_words = [w вместо w в raw_words, если w.lower () не в стопах]
            no_stop_words_count = Счетчик (no_stop_words)
            # сохраняем результаты
            результаты = отсортировано (
                no_stop_words_count.Предметы(),
                key = operator.itemgetter (1),
                reverse = True
            )
            пытаться:
                результат = Результат (
                    url = url,
                    result_all = raw_word_count,
                    result_no_stop_words = no_stop_words_count
                )
                db.session.add (результат)
                db.session.commit ()
            Кроме:
                errors.append («Невозможно добавить элемент в базу данных.»)
    вернуть render_template ('index.html', errors = errors, results = results)


если __name__ == '__main__':
    приложение.запустить()
  

  остановок = [
    «я», «я», «мой», «я», «мы», «наш», «наш», «мы», «ты»,
    «ваш», «ваш», «себя», «себя», «он», «его», «его»,
    'он', 'она', 'она', 'ее', 'сама', 'оно', 'его', 'сама',
    "они", "они", "их", "их", "сами", "что", "что",
    "кто", "кто", "этот", "тот", "эти", "те", "есть", "есть", "есть",
    'был', 'был', 'быть', 'был', 'быть', 'иметь', 'имел', 'имел', 'иметь',
    «делать», «делает», «делал», «делаю», «а», «ан», «то», «и», «но», «если»,
    'or', 'потому что', 'as', 'до', 'while', 'of', 'at', 'by', 'for',
    'с', 'около', 'против', 'между', 'в', 'через', 'во время',
    «до», «после», «вверху», «внизу», «до», «от», «вверх», «вниз», «в»,
    'out', 'on', 'off', 'over', 'under', 'again', 'далее', 'then',
    "однажды", "здесь", "там", "когда", "где", "почему", "как", "все", "любое",
    "оба", "каждый", "несколько", "больше", "большинство", "другое", "некоторые", "такие", "нет",
    'ни', 'не', 'только', 'свой', 'такой же', 'так', 'чем', 'тоже', 'очень', 's',
    't', 'can', 'will', 'just', 'don', 'should', 'now', 'id', 'вар',
    'функция', 'js', 'd', 'скрипт', '\' скрипт ',' fjs ',' документ ',' r ',
    'b', 'g', 'e', ​​'\' s ',' c ',' f ',' h ',' l ',' k '
]
  

.