Простой способ оснастить UTM метками рекламные кампании в Гугл Адвордс.

О чем пойдет речь?

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

Зачем вообще использовать UTM метки?

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

Однако, когда вы просто поставили счетчик и собираем данные, то все, что сможет нам предложить интерфейс, это общее определение источника перехода на сайт, входную страницу. Да, по умолчанию, Яндекс Директ передает в Яндекс метрику много данных: данные по кампании, о группах объявлений и даже о ключевой и поисковой фразе, по которой был переход. Аналогично работает связка Adwords-Analytics. Все это позволяет найти слабое звено в вашей рекламной кампании. Однако, если вы используете несколько источников платной рекламы, то любой счетчик будет вам сообщать только об источнике перехода. Ни о каких дополнительных параметрах речи не идет. Т.е. вы будете использовать, так называемый «котловой метод», по которому нельзя ничего толком определить, кроме средней эффективности по источнику в целом.

Что такое «котловой метод». Представьте себе любую проработанную кампанию в Директ или Adwords. Хорошо проработанный проект будет содержать в себе несколько десятков/сотен отдельных кампаний. Каждая кампания будет содержать несколько групп объявлений, в каждой группе объявлений несколько разных видов объявлений, которым соответствует группа ключевых фраз, по которым осуществляются показы в рекламной сети.

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

Что это значит? Надо ли закрывать этот канал как неэффективный? Конечно же нет!

Средняя цифра 2600 на самом деле будет подразумевать, что у вас есть кампании, в которых вы тратили сильно меньше 2000 рублей за обращение, есть такие, которые стоили около 2000 рублей, а есть такие, которые сильно превышали 2000 рублей. Надо иметь возможность выяснить, что это за кампании и применить к ним несколько различные подходы.

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

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

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

Сейчас я привел этот пример исключительно для того, чтобы показать, что UTM метки нам очень нужны )) Только с их помощью, мы можем получать данные о разных кампаниях, группах объявлений и ключевых фраз из различных систем в едином интерфейсе.

Состав UTM метки

Типичный шаблон url посадочной страницы выглядит так:

www.site.ru\?utm_source=google&utm_medium=cpc&utm_campaign=cid_{campaignid}&utm_target={target}&utm_group=gid_{adgroupid}&placement={placement}

utm_source

Содержит информацию об источнике, откуда совершен переход

Примеры значения: google, yandex, email,vk,facebook

utm_medium

В этой переменной указывается тип перехода

Примеры значения: cpc (оплачивается стоимость клика), cpa (оплачивается стоимость какого-либо действия)

utm_campaign

Идентификационный номер или имя кампании

utm_group

Идентификационный номер кампании

utm_content

Содержит информацию о контенте, который показан пользователю.

placement

Переменная {placement} передает домен сайта, с которого был клик по объявлению в рекламной сети Google.

Для того, чтобы оснастить кампании в системах Яндекс Директ и Google Adwords метками, самый простой и быстрый способ – воспользоваться программами для работы в этих сервисах: Direct Commander и Google Adwords Editor. Вообще, для массовой обработки рекламной кампании  это весьма удобные инструменты.

Массовое добавление UTM меток в кампаниях Adwords с помощью Google Adwords Editor

Открываем Google Adwords Editor, выбираем все кампании и переходим во вкладку «Параметры URL”

Далее вставляем в «Шаблон отслеживания» такую строку:

{lpurl}?utm_source=google&utm_medium=cpc&utm_campaign=cid_{campaignid}&utm_target={target}&utm_group=gid_{adgroupid}&placement={placement}

{lpurl} – в данном случае, это любой входной URL, который вы вставили в кампаниях.

Все остальные значения – переменные, которые понимает Адвордс. Вместо них он вставит нужные значения — {campaignid} – ID кампании, {adgroupid} – ID группы объявления и по другим переменным аналогично.

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

И всего делов-то. Далее жмите «Опубликовать» и публикуйте изменения.

В самом интерфейсе рекламной кампании в разделе «Настройки»,  это выглядит так:

 

 

 

 

Неприятный побочный эффект при использовании целевого звонка Яндекс Метрика

Система Яндекс Метрика предлагает своим пользователям сервис подмены номера телефона для людей, которые приходят из разных источников. При этом внедрение и настройка такой подмены занимает буквально 15 минут и все очень удобно.

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

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

В моем случае это выстрелило в магазине бытовой техники, где надо было для 3 сайтов разделить каналы по Директу, Поиску и Маркету. Я повесил на сайты 9 телефонов, все эти телефоны вели в единый колл-центр. И со следующего дня началось… Вопросы по лендроверу, заказы на пошив костюмов, запросы на поставку запчастей …. 20 звонков за первый день… из них 12 левых.

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

Откуда берутся все эти звонки? Номера никто не держит в отстойнике. Т.е. взяла компания номер, подавала рекламу, навывешивала объяв по каталогам и сайтам типа авито, а потом перестали платить. И тут я беру номер для своей подмены… а мне куча мусора по старым объявлениям на этот номер.

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

В общем, если бы у меня было и так в районе 100 звонков, то 5-7 левых не сильно бы исказили статистику, но в случае, если вы и так ожидаете 5-10 звонков в день, то половина левака вообще не оставляют шансов что-то понять и деньги, которые вы потратите на номер в Яндекс Метрике — это выброшенные деньги. В этом случае лучше уж потратиться на IP номер в специализированной компании и убедиться, что номер до вас хотя бы 6 месяцев никто не использовал.

 

 

Что значит «хороший программист»?

Я уже неоднократно в своих статьях упоминал о той огромной важности, которой обладает скорость загрузки сайта интернет-магазина. Стоит скорость загрузки страниц уменьшить с 0.5 до 3-4 секунд, то конверсия падает в РАЗЫ. Вы осознаете это? Вдумайтесь очень внимательно! Это значит, что если страницы грузятся более 4 секунд, то ваш доход будет в 3-8 раз ниже. А это разница, которая может поставить крест практически на любом бизнесе.

Посмотрите на график ниже. Это зависимость уровня конверсии от скорости загрузки страниц в крупном ИМ (Walmart.com). По ней четко видно, что граница 1-2 секунды, это тот предел, при котором вы будете впереди планеты всей, а как только время загрузки зашкалит за 3 секунды, вы превращаетесь в унылую серую массу.


Согласно онлайн опросам факты такие:

• 60% пользователей ожидают, что страница загрузится в течение 3с
• Около 75% пользователей смартфонов покинут мобильную страницу, если она будет загружаться дольше 5с
• Те, кто ушел с сайта из-за низкой скорости, скорее всего покинут его, если зайдут другим путем.

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

Знаете, как обычно в веб студиях рождается пункт в перечне достоинств, что «Сайт полностью оптимизирован для SEO»? Очень просто! Просто берут и добавляют этот пункт в перечень достоинств CMS, на основе которой создается сайт. Еще бы, ведь это утверждают создатели CMS.

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

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

1) Программист оптимизирует БД

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

Приведу конкретный пример. Как-то ко мне попал в руки интернет-магазин, у товаров которого было 45 различных свойств: материал, страна производства, оптовые и розничные цены, вес, размеры, количества на разных складах, наличие специальных атрибутов и куча других… Под все эти свойства по умолчанию резервировалась строка в 256 текстовых символов. Время загрузки страницы, которое по куче параметров (по фильтру), выдергивало нужные товары, составляло около 20 секунд. Товаров было более 50тысяч, свойств много, код ужасен. В результате время загрузки было такое, что пользоваться сайтом было нельзя.

После оптимизации одной ресурсов одной только БД, время загрузки упало до 11-12 секунд. В два раза!
Этим обычно никто не заморачивается. А надо.

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

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

Оптимизация этих процессов в нашем примере сократила время загрузки страницы до 3 секунд

3) Программист должен ломать голову, что из «якобы» нужных динамически обрабатываемых вещей можно убрать в статику и не трогать.

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

4) Программист должен кешировать все, что возможно.

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

Те страницы, которые грузились за 1.2-1.3 секунды, при повторном обращении к ним, выдавались частично из кэша и скорость формирования страниц составляла 0.3-0.6с.

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

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

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

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

И еще раз про выбор CMS для интернет магазина

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

  • Надо иметь возможность прописать ЧПУ для любой страницы (из соображений SEO). Часто во многих движках url формируется по своим неизменным законам;
  • Тitle и Meta можно прописать отдельно от заголовка и названия страниц (в некоторых cms это бич);
  • Должно быть много разработчиков, хорошо знающих этот движок – высокая популярность;
  • Должна быть тех. поддержка пользователей;
  • Должна быть возможность богатого выбора готовых шаблонов, а также возможность натянуть свой нарисованный дизайн и настроить;
  • Должна быть возможность кастомизировать компоненты каталога, чтобы отображать данные в том виде, каком это понадобится;
  • Должна быть возможность гибко управлять ценами в магазине: создавать скидки (например, в зависимости от объема), делать спецпредложения и т.п.
  • Создавать большое количество нестандартных свойств продукта для тонкой фильтрации. Это нужно для сортировки товаров под пользователей, которые ищут очень жесткую конкретику. Например, человек вводит запрос «черные кошельки из кожи», тогда надо привести его на страницу, где на витрине будут только черные кожаные кошельки. Так мало кто продумывает магазин, поэтому в лице таких пользователей можно рассчитывать на существенное преимущество. Речь идет о страницах со СТАТИЧЕСКИМ URL, где возможно разместить свой текст и прописать ручками уникальные заголовки страницы.
  • Быстрая работа ЦМС под высокими нагрузками

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

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

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

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

CMS должна быть максимально легкой. Если это обычный сайт, то если для ваших нужд хватает WordPress, то не надо ничего выдумывать. Упаси вас бог настраивать маленький корпоративный сайт из сотни страниц на Битрикс, Друпал или Джумлу. Это приведет к тому, что надо будет брать мощный хостинг стоимостью от 800 р в месяц, а быстодействие такого сайта будет очень сильно проигрывать аналогичному сайту на WP, который висит на самом дешевом тарифе.

 Что касается мощных проектов, типа Интернет магазина или Портала, то тут было и остается лучшим решением для быстродействия связка Фреймворк + программист. В общем неважно, что за фреймворк. Это может быть ASP, Ruby, ModX. Я лично выбирал бы для своих проектов ModX хотя бы потому, что там php, который я знаю, а по нему легче всего найти программистов в случае проблем с первым разработчиком.

Видео по выбору CMS для Интернет-магазина

Перенос сайта на другой движок (CMS)

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

Требования довольно простые. Они относятся к скорости работы сайта, к наличию ЧПУ, возможности прописывать заголовки и мета теги на любой странице вручную, качеству верстки макета, а также возможности создавать выборку товаров на статической страние по любому набору свойств. Последнее относится к интернет магазинам и каталогам-справочникам.

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

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

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

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

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

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

Удачного переноса. Если у вас возникнут вопросы по переносу сайта на другой вопрос, а я тут ответил с точки зрения SEO не на все — спрашивайте в комментах. Я постараюсь ответить.

Как установить счетчик на сайт?

Предположим, вы уже определились, какой счетчик ставить. Я уже в некоторых заметках отмечал, что в общем виде, вполне достаточно одного счетчика. Максимум двух. Я обычно ставлю Яндекс метрику. Иногда, если скорость работы сайта очень хороша, еще могу повесить и гугл аналитикс. Если ваш поисковой трафик преимущественно с Яндекса, то ставьте метрику, если с Гугла, то аналитикс.

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

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

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

Ниже я показал условно схему:

структура формирования страниц на сайте

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

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

Для начала нам надо получить этот код счетчика. Для этого заходим в Метрику под своим логином и жмем добавить счетчик https://metrika.yandex.ru/add/

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

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

Далее копируете код. Его надо будет добавить на страницы вашего сайта.

Теперь о том, как добавить этот код для Вордпресс.

  1. Заходим в админку и открываем Редактор в управлении внешним видом

Кликаем на «Подвал» – файл footer.php и вставляем этот код прямо перед тегом </body>

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

Как снизить нагрузку на сервер?

И меня постигла необходимость уменьшать нагрузку на сервер. Один из моих сайтов интернет магазинов довольно тяжелый. И несмотря на включенное кеширование, шустрый хостинг, он очень сильно грузил сервак. Когда я переехал с выделенного сервера на обычный хостинг с увеличенной мощностью, необходимость уменьшения нагрузки стала особенно остро, т.к. при разрешенных 150cp у меня один только один этот сайт давал нагрузку до 250ср. Это никуда не годилось. Чистка емких скриптов, например динамическая обработка фото, не была очень эффективной и мне пришлось копать далее.

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

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

Итак, п.1. Снижаем нагрузку на сервер с помощью блокировки деятельности ненужных ботов.

Для этого вставляем в файл .htaccess следующую запись:

<Files 403.shtml>

order allow,deny

allow from all

</Files>

# Далее список юзерагентов которым мы запрещаем доступ

SetEnvIfNoCase User-Agent MJ12bot bad_bot

SetEnvIfNoCase User-Agent JS-Kit bad_bot

SetEnvIfNoCase User-Agent PostRank bad_bot

SetEnvIfNoCase User-Agent Python-urllib bad_bot

SetEnvIfNoCase User-Agent UnwindFetchor bad_bot

SetEnvIfNoCase User-Agent facebookexternalhit bad_bot

SetEnvIfNoCase User-Agent TweetmemeBot bad_bot

SetEnvIfNoCase User-Agent Butterfly bad_bot

SetEnvIfNoCase User-Agent MFE_expand bad_bot

SetEnvIfNoCase User-Agent Java bad_bot

SetEnvIfNoCase User-Agent Summify bad_bot

SetEnvIfNoCase User-Agent MetaURI bad_bot

SetEnvIfNoCase User-Agent FlipboardProxy bad_bot

SetEnvIfNoCase User-Agent ScribdReader bad_bot

SetEnvIfNoCase User-Agent RockMelt bad_bot

SetEnvIfNoCase User-Agent InAGist bad_bot

SetEnvIfNoCase User-Agent NING bad_bot

SetEnvIfNoCase User-Agent TweetedTimes bad_bot

SetEnvIfNoCase User-Agent PaperLiBot bad_bot

SetEnvIfNoCase User-Agent Library bad_bot

SetEnvIfNoCase User-Agent Ezooms bad_bot

SetEnvIfNoCase User-Agent strawberryj bad_bot

SetEnvIfNoCase User-Agent Scooper bad_bot

SetEnvIfNoCase User-Agent Ahrefs bad_bot

SetEnvIfNoCase User-Agent Spider bad_bot

SetEnvIfNoCase User-Agent None bad_bot

SetEnvIfNoCase User-Agent EventMachine bad_bot

SetEnvIfNoCase User-Agent aiHitBot bad_bot

SetEnvIfNoCase User-Agent SolomonoBot bad_bot

SetEnvIfNoCase User-Agent SearchBot bad_bot

SetEnvIfNoCase User-Agent Wget bad_bot

SetEnvIfNoCase User-Agent Crawler bad_bot

Order Allow,Deny

Allow from all

Deny from env=bad_bot

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

Список можно пополнять. В моем случае особые проблемы вызывал MJ12bot, который по 1-3К запросов делал в сутки.

п.2. Уменьшение нагрузки за счет установки тайминга

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

Загружая по многу страниц, эти боты вполне себе тоже могут положить сайт и весь сервер вместе с ними.

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

Это можно сделать в файле robots.txt. Добавьте туда следующие записи:

User-agent: Yandex

Crawl-delay:5

Эта запись означает, что ботам Яндекса запрещено делать обращения к сайту чаще, чем 1 раз в 5 секунд.

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

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

Важность высокой скорости загрузки страницы для пользователя на продвижение

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

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

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

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

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

Давайте разберем основные моменты подробнее.

  1. Графика

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

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

  1. Сжатие данных на сервере

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

Так вот. Сервер может отправлять данные, как есть, а может их предварительно заархивировать. Архивация незначительно увеличивает нагрузку на сервер, но сокращает время передачи данных для слабых каналов в разы. Подробнее можете прочитать об этом. Вбейте в яндексе «nginx gzip-сжатие». Хорошие хостинги обычно сжимают данные по умолчанию. Как всегда, я порекомендую timeweb )) Проверить есть у вас сжатие или нет можно с помощью любого онлайн сервиса анализа скорости страницы. Параметр content-encoding.

http://pr-cy.ru/speed_test — проверка скорости загрузки страницы для пользователя

  1. Используйте советы от Гугл для оптимизации страницы

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

https://developers.google.com/speed/pagespeed/insights/

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

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

в) Система предложит вам варианты, как сжать JS скрипты и текст страницы

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

Также нет никакого смысла держать по 3-5 счетчиков на странице. Выберите себе один – Метрику или GA и хватит. Остальные лишь тормозят сайт и увеличивают вес страницы. Больше данных вы все равно от кучи счетчиков не получите, а на посещаемость они будут влиять скорее негативно.

И обязательно блокируйте деятельность ботов у себя на сайте. Они часто создают огромную нагрузку на сервер.

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

И еще о поставщиках и парсерах

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

Иметь на сайте неактуальную информацию очень затратно. При нормальном раскладе мне звонят, говорят, что хотят купить (или заполняют форму на сайте) и я просто перезваниваю подтвердить заказ. Если же я не знаю актуальное наличие товара (хотя бы с 90% уверенностью), то мне приходится предлагать клиенту подождать 20 минут, чтобы я связался со складом и узнал, есть ли тот товар. Когда оказывается, что его нет, опять надо звонить клиенту, сообщать ему эту новость. Клиент часто может спросить «а есть ли такое же, но другого цвета, или другое, но такого же цвета» процесс перезвона повторяется. При этом звонков много, а в результате дай бог одному из 4-5 людей, кому сразу сказали «товара не оказалось», удается подобрать замену.

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

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

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

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

Вчера я буквально за 5 часов добавил к себе на сайт еще около 300 новых товаров с уникальными title, содержащие запросообразующие слова, уникализированными описаниями и актуальными ценами и информацией о наличии. Также я создал скрипт, который позволит мне раз в 2-3 дня проверять данные, полученные парсером с тем, что на моем сайте и отключать товары, которых нет в наличии. При тех исходных данных, которые поставщик мне предоставлял, я бы потратил 3000 т.р. на помощников, 2 дня времени на работу помощника и еще около 2 суток сам – разбираясь с тем, что мне насобирали помощники. Именно так я поступал вначале. Потом, как я разобрался с php, это стало ненужным.

Еще одна причина пользоваться парсерами

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

К следующей записи >>

К списку записей по проекту >>

Подготовка данных для экспорта данных каталога в Интернет магазин

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

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

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

Наименование | Ссылка на фото | Цвет | Описание | Цена | Единицы измерения | Материал | Производитель | Как носится | Статус | Особенность | Страна производства

Это минимальный набор свойств, которые на начальном этапе необходимо заполнить. Прайс, который я получил от поставщика, содержит только Наименование, Цену и Цвет. И еще неприятный сюрприз заключался в том, что фотографии, которые у меня есть по названиям никак не связаны с продукцией. Поэтому, чтобы заполнить таблицу мне необходимо открывать сайт поставщика, искать очередной продукт, смотреть, что там за фото, сравнивать это фото с фотографиями, что у меня есть, и наконец,  копировать описание непосредственно из магазина поставщика. Это довольно емкая по времени процедура. За час мне удалось собрать данные для 40 наименований. Т.е. тут работы примерно на 30 человекочасов.

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

Нормальный копирайтер берет около 150 рублей за 1000 знаков. Для 1200 товаров по 200 знаков это составит 240 тысяч знаков. Общая сумма 36000 рублей. Можно в принципе и самим это делать, только боюсь с моими выделенными 1-2 часа в день на развитие Интернет магазина это будет очень долго. У меня есть по крайней мере 4 хороших копирайтера, которых можно будет привлечь к этой работе и выполнить все очень быстро.

Средняя скорость копирайта для такой задачи – 4000 знаков в час. Значит 60-70 человеко-часов можно это дело выполнить. С привлечением копирайтеров задачу можно будет выполнить буквально за 3-5 дней. Другой вопрос, что у меня в настоящий момент маловато наличных средств для их найма, поэтому придется либо сильно растянуть этот процесс во времени, либо большую часть работы взвалить на себя и супругу.

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

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

В ближайшие 2 недели мне писать будет особо нечего – буду заниматься созданием заполнением магазина. Об очередной записи сообщу на Facebook

К следующей записи >>
К списку записей по проекту >>