Как быстро и удобно делать скриншоты на компьютере?

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

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

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

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

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

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

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

Чаще всего нужен какой-то фрагмент. Вы нажимаете ctrl+F1, появляется панель управления, там вы выбираете зону, делаете пометки, которые надо сделать на скрине и жмете кнопку OK. Через 3 секунды, ваш скриншот (адрес картинки на joxi.ru) будет в буфере обмена.

А там вы можете сделать что угодно: просто вставить картинку в документ, использовать онлайн ссылку, чтобы прямо с joxi.ru человек мог видеть изображение или же скопировать к себе на диск/сервер.

Очень удобно. Рекомендую.

Установка кода счетчика Google Analytics и Яндекс Метрики с помощью Google Tag Manager

После того, как вы решили воспользоваться плюсами Google Tag Manager и установили его, как это описано в предыдущем посте, самое время использовать его по назначению. Давайте посмотрим, как подключить счетчики отслеживания Яндекс Метрика и Google Analytics. Сделать это несложно.

Подключение счетчика Google с помощью GTM

Заходите в панель Google Tag Manager и жмите «Создать новый тег»

Установка кода счетчика Google Analytics и Яндекс Метрики с помощью Google Tag Manager

В качестве конфигурации тега выбирайте Universal Analytics Google Analytics

Далее надо только указать свой идентификатор отслеживания. Его надо поставить сюда

Его можно найти в своем аккаунте Гугл Аналитикс https://analytics.google.com/analytics/web/

Выглядит это так

Именно этот идентификатор вставляйте в конфигурацию тега.

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

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

Подключение кода Яндекс Метрики через Google Tag Manager

 Обратите внимание, что подключение любого другого скрипта, который вы хотите выполнять на всех страницах – полностью аналогично тому, что я сейчас опишу для Yandex Metrika. В любом случае, при подключении онлайн консультантов, кодов ретаргетинга и т.п. вам просто будет предложен некий код, который надо внедрить на сайт. Далее мы рассмотрим, как это сделать с помощью Google Tag Manager.

Получите код счетчика в системе Яндекс Метрика. Это вы можете сделать со страницы списка своих счетчиков — https://metrika.yandex.ru/list/

Заходите в настройки

 

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

 

Возвращайтесь в нужный аккаунт на https://tagmanager.google.com и выбирайте «Создать новый тег». В этот раз, в качестве конфигурации, выбирайте «Пользовательский HTML»

И просто вставляйте код, который у вас в буфере обмена сюда

В качестве тригера выбираем All pages

После создания нового триггера необходимо опубликовать изменения, которые вы проделали. На рабочем столе, странице, куда вы попадаете при входе в аккаунт сайта в Google Tag Manager появится красная кнопка «Опубликовать»

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

Google Tag Manager

Несколько месяцев назад открыл для себя GTM. Сегодня хочу рассказать простыми словами о том, что это такое, зачем он нужен и показать пару примеров его применения – как настраивать с помощью Google Tag Manager передачу событий в Google Analytics и оснащать кодом на все страницы сайта.

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

Зачем нужен Google Tag Manager?

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

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

О, да. Это и есть одна из задач, которую вы сможете решить с помощью кода GTM.

Установка кода Google Tag Manager на сайт

Я не буду описывать процесс регистрации. Он стандартный для любого сервиса Google. На странице https://tagmanager.google.com вам предложат либо зайти под существующей текущей записью, либо зарегистрироваться. Уверен, что с этой задачей вы вполне можете справиться.

После авторизации, на указанной мной странице надо создать аккаунт системыGoogle Tag Manager - добавить аккаунт

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

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

Google Tag Manager - код вставки на сайт

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

Как установить код Google Tag Manager на сайт на примере сайта WordPress

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

Заходите в админку своего сайта и найдите там редактор текущего шаблона

Затем найдите в списке подключаемых шаблонов имя header.php

Вставьте часть кода после

И аналогично после кода

Жмите «Обновить файл» и все – вы теперь счастливый обладатель кода GTM у себя на сайте. Теперь самое время сделать с ним что-то хорошее.

Карта поведения в Google Analytics

Решил сегодня рассказать об одном из преимуществ счетчика Google Analytics – карте поведения. Карта поведения — это замечательный и совершенно уникальный на сегодняшний день, отчет системы статистики GA, который позволяет очень быстро и эффективно обнаруживать проблемные страницы на сайте.

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

Чтобы понять, какие страницы являются помощниками, а какие вредителями, было бы чудесно иметь инструмент, который наглядно показывал трафик который «течет» по вашему сайту. Причем так, чтобы было сразу очевидно, какая часть людей проходит дальше, а какая отскакивает. А еще было бы здорово, чтобы можно было посмотреть эти потоки для разных сегментов людей. Например, только для посетителей из Москвы, или для женщин, или для людей, которые интересовались каким-то определенным разделом… И этот инструмент существует и реализован в лучшем виде в Гугл Аналитикс – называется он «Карта поведения пользователей». Давайте посмотрим на него в действии.

Карта поведения Google Anallytics

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

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

Алгоритм решения проблемы следующий

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

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

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

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

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

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

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

Сам отчет карты поведения находится в разделе «Поведение»-«Карта поведения»

Видео с использованием карты поведения (пока без звука — чуть позднее поставлю озвучку)

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

Система Яндекс Метрика предлагает своим пользователям сервис подмены номера телефона для людей, которые приходят из разных источников. При этом внедрение и настройка такой подмены занимает буквально 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мс загрузки не так много, это одновременно проклятье и огромный позитив.

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

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

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

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

При таком раскладе, когда ТЗ состоит на бумаге в виде кучи, часто плохо согласующихся друг с другом пунктов, всегда возникает ситуация, что делается макет, очень долго дорабатывается с дизайнером, потом со слезами принимается, верстается, а на этапе программирования начинаются гениальные идеи, чего бы еще добавить/изменить. Как правило, заказчик, который плохо понимает объем работы, возмущается, если его просят оплатить эти работы дополнительно. Еще бы, ведь для того, чтобы внести изменения на этапе программирования на сайт, необходимо куча трудозатрат:

  • Руководителю проекта нужно вникнуть в суть изменения;
  • Далее надо эту суть донести до дизайнера;
  • Дизайнер это должен нарисовать, т.е. изменить уже существующий макет под новые требования. Причем часто изменения таковы, что куча соседних блоков «едут» и надо согласовывать с заказчиком, что и куда можно приткнуть;
  • Макет вторично принимается;
  • Далее верстальщик должен с учетом измененных блоков сверстать измененный шаблон. Замечу при этом, что вносить изменения сложнее, чем верстать страницу с нуля.
  • Потом программист должен внедрить новый вариант верстки. Тут тоже позволю себе заметить, что тут задача усложняется тем, что можно запутаться в вариантах, в результате вся верстка на сайте едет и программист тратит кучу времени, пытаясь понять, где он потерял дополнительный закрывающий тег </div>

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

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

Что это такое?

Делается такая штука http://jtm7ml.axshare.com/#p=интернет_магазины

Вот скрин примера (полностью как это выглядит, можно посмотреть по ссылке выше)

Создать такой прототип можно за 2-3 часа. Особенность в том, что время для изменений в этом макете в 100 ниже, чем в сверстанном в реальности сайте. Динамический прототип дает возможность расположить все элементы на будущей странице: тексты, места под картинки, эмблемы, формы, ссылки, слайдеры, баннеры и другие активные элементы. Тексты можно писать сразу реальные, места под картинки можно сразу обозначить, что там будет конкретно.

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

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

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

Если вы создаете сайт – требуйте от ваших разработчиков создание такого прототипа. Это реально сохранит ваши нервные клетки )) Как правило, разработка прототипа стоит отдельных денег, но оно стоит того. В общем виде, полное ТЗ должно состоять из такого прототипа и пояснительной записки к нему. Не в виде большого перечня слабо связанных документов, в виде кучи страниц с различным функционалом или информацией для персонала или пользователей.

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

ЗЫ Кстати, у меня можно заказать такую услугу, мои контакты  здесь