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

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

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

Соответственно, форма — уязвимое место приема таких обращений, которое может сократить их число из-за своей неэффективности.

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

Однажды в очередной раз возникла задача о закачке относительно больших файлов. Говоря конкретно, клиент захотел заливать на сайт через админку видеоролики размером 20-40 мегабайт. Казалось бы, в наше просвещенное время подобный размер — это такая мелочь, о коей и говорить стыдно. Но внезапно все уперлось в настройки виртуального хостинга. Мы с ужасом обнаружили, что максимальный размер закачиваемого файла — 2M, и поменять эту цифру нет возможности. И менять хостинг по ряду причин нельзя — по крайней мере не сейчас.

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

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

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

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

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

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

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

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

18 июня Яндекс анонсировал публичный доступ к API Яндекс Директ. Мы, как рекламное агентство, получили этот доступ немного раньше и сейчас используем его для управления ставками в рекламных кампаниях. Хотелось бы поделиться нашим опытом.

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

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

Что такое междоменное отслеживание и зачем оно нужно?

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

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

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

В Google Analytics существует раздел «Обратный путь к цели», с помощью которого мы можем проследить путь посетителя до совершения им заказа.

Вот как можно это использовать на практике.

В этой статье хотелось бы поделиться опытом разработки слоя контроллера в нашем веб-фреймворке. Что мы хотим от этого слоя:

• абстракция HTTP-запроса и отклика, компенсирование неудобств встроенной реализации;
• возможность компоновки обработчиков запросов из отдельных модулей (middleware);
• самое главное: диспетчеризация URL, простая структура набора правил диспетчеризации;
• REST как наиболее универсальная архитектура.