Пользователь
0,0
рейтинг
14 апреля 2011 в 16:06

Учим Google Analytics дружить с Яндекс.Директ из песочницы

Google Analytics —бесплатный сервис статистики для веб-сайтов от компании неравнодушия Google, предоставляет настолько детальную статистику под управлением множества мощных инструментов, что мгновенно стал популярным среди веб-мастеров, включая специалистов Рунета. Но и столь развитая и продуманная система имеет ряд своих недостатков. И справится с ними получается далеко не всегда, и уж точно не малой кровью, ведь все инструменты Google Analytics, скрипты для обработки данных и, главное, вся полученная статистика хранятся на серверах Google, официальная справка и консультанты выдают минимум информации, а основной скрипт для сбора ga.js и тот обфусцирован до невозможности. Всё это связывает руки при попытках решения возникающих с обработкой данных проблем.
Множеством из таких проблем Google бережно треплет нервы именно русскоязычным пользователям: тут и загадочные проблемы с кодировками, пренебрежение к поисковикам Рунета и проблема, давно угнетающая, как скромных владельцев интернет-магазинов, так и матёрых веб-аналитиков — категорический отказ воспринимать рекламные площадки Яндекс.Директ. Причём такая ненависть не взаимна, и Яндекс.Метрика честно пытается обработать, как умеет, переходы с Google Adwords, но максимум, как предлагает выходить из положения поддержка Analytics — пользоваться Компоновщиком URL для пометки своих рекламных кампаний. Мне всё-таки удалось найти решение сложившейся ситуации и подружить суровый Google со своим русскоязычным коллегой.

1) Используем компоновщик URL

Первый, самый популярный и почти единственно используемый всеми метод для отслеживания собственных рекламных кампаний. В том числе и кампаний Яндекс.Директ.
Инструмент для реализации данного метода предлагает сам Google Analytics — Компоновщик URL. Суть инструмента в добавлении к целевому URL вашего рекламного объявления определённых параметров-меток, которые в свою очередь с успехом распознаёт и сортирует Analytics.
Это метки:
utm_source (обязательная) —для пометки источника перехода, в нашем случае YandexDirect;
utm_medium (обязательная) —средство кампании, например, баннер или рассылка. У нас — cpc;
utm_campaign (обязательная) — название кампании для удобства их различения. Тот же YandexDirect;
utm_term — само ключевое слово. Например, tort_habrahabr;
utm_content — пометка объявления или каких-либо различий в размещении в пределах одного источника. Например, text_ad1.
В итоге получается ссылка вроде:
yummyhabr.ru/tort/?utm_source=YandexDirect&utm_medium=cpc
...&utm_term=tort_habrahabr&utm_content=text_ad1&utm_campaign=YandexDirect
Которую мы и должны сделать целевой для наших объявлений в Яндекс.Директ.

Рассмотрим плюсы и минусы такого способа:
+ Работает наверняка и достаточно точно. Ведь сам Analytics обещает его работу.
+ Учёт разных параметров (средство, содержание, название) при пометке объявлений.

Это всё. И при этом:
Не зря в примере я не использовал кириллицу. С ней всё очень и очень туго. Редко когда стабильно работает и распознаётся. Используйте транслит.
И вместо пробелов лучше использовать символы нижнего подчёркивания.
Если у вас в Яндекс.Директ уже запущена рекламная кампания с сотней-другой объявлений, то вас ждёт та ещё работёнка по переводу ключевых слов с горячо ценимого русского на транслит и пометке всей этой доброй сотни.
Кроме того, у многих на одном объявлении крутятся несколько ключевых фраз. Так вот с помощью такой пометки мы сможем отслеживать только сами объявления, а не фразы, им соответствующие, ведь Яндекс.Директ позволяет назначать целевые URL непосредственно объявлению.

Бонус:
При особом обострении лени желании можно написать свой небольшой скрипт для автоматической генерации URL и пометки объявлений. Например, используя класс PHPExcel и возможность выгрузки данных из кампаний в xls-файл, которую любезно предоставляет Яндекс.Директ. Я «на коленке» набросал вот такой (принимает выгруженные xls или созданные по шаблону Яндекса).

2) Используем _openstat

Первое к чему я пришёл, не удовлетворившись официальным компоновщиком URL — это извращённый метод использования меток OpenStat. OpenStat — это закодированный в base64 набор параметров, который включается в URL и распознаётся некоторыми системами статистики, как например, LiveInternet или SpyLog, но не нашим любимым Google Analytics. Яндекс.Директ поддерживает и позволяет использовать эти метки в автоматическом режиме в своих рекламных кампаниях. При этом в метку включается идентификационный номер объявления в системе Яндекс.Директ, номер ключевого слова, источник и позиция объявления на странице выдачи. Метки генерируются Яндексом автоматически для каждого объявления при каждой выдаче пользователю. Включается на странице параметров кампании галочкой на «Внешняя интернет статистика: — Подключиться». Теперь целевые URL, помеченные параметром _openstat можно фильтровать в Google Analytics, как принадлежащие Яндекс.Директ.
Для этого в Google Analytics создаём три пользовательских расширенных фильтра (подробнее здесь):
• Фильтр1
Поле А-> “URI запроса”: (/?_openstat=.*)
Вывод в-> “Источник кампании”: YandexDirect
• Фильтр 2
Поле А-> “Средство кампании”: organic
Поле B-> “Источник кампании”: YandexDirect
Вывод в-> “Средство кампании”: cpc
*Поле Б обязательно для заполнения
• Фильтр 3
Поле А-> “Источник кампании”: YandexDirect
Вывод в-> “Название кампании”: Яндекс.Директ
Таким образом мы берём все переходы сделанные по URL, содержащему параметр openstat и определяем их как переходы с объявлений Яндекс.Директ.
Получим такую картину:

Что получилось:
+ Быстро одним щелчком включаем слежение по всем объявлениям сразу.
+ Под ключевыми словами видим именно запросы пользователей, по которым они нас нашли.
+ Всё на русском языке.

Но:
Мы не можем разделить и оценить статистику именно по нашим ключевым словам.
Вся картина рушится, если мы ещё где-то для статистики используем пометки openstat или такие ссылки где-то засветились (например, были проиндексированы поисковыми системами или добавлены пользователем в закладки). Поэтому сразу добавляем в robots.txt параметр Disallow: /*_openstat.
А главный минус в том, что после захода на наш сайт пользователя с использованием помеченного URL и его перехода на другую внутреннюю страницу, метка теряется, а значит, не обрабатывается нашими фильтрами и не помечается как рекламный переход. В итоге, мы не получим отчёты по конверсиям по этому источнику и среднее число посещённых страниц тут всегда будет меньше 2.

Бонус:
Если же этот способ вам чем-то понравился, не смущает отображение в ключевых словах поисковых запросов пользователей, то для отслеживания полной статистики по таким переходам можно использовать Пользовательский сегмент в Google Analytics (справа вверху в отчётах «Сегменты с расширенными настройками»), где параметр «Кампания» «точно соответствует» «Яндекс.Директ», то есть заданному нами в фильтрах названию. В таком случае Google Analytics для этого сегмента показывает не только статистику по заходам на сайт, у которых источник YandexDirect, но и внутренние переходы по сайту посетителей с таким источником, а соответственно конверсии и прочее. Отчего он так загадочно поступает, мне неведомо. Ведь получается, что знает, хитрец, про источник захода нашего блуждающего пользователя, но в статистику по кампаниям внутренние переходы заносить отказывается.

3) Используем шаблоны Яндекс.Директ

Пытаемся улучшить первый способ и научить Google Analytics хоть как-то распознавать отдельные ключевые запросы и дружить с русским языком. Пока учил, пытался даже создавать 30 внутренних фильтров по обратной транслитерации наших ключевых фраз, но ничего хорошего из этого не получилось…
Но обращаем своё внимание на инструмент «шаблоны» у Яндекс.Директ. Работает он просто. Если мы выделяем какое-либо слово или фразу в нашем текстовом объявлении тегами # (октоторп, он же «решётка»), то при выдаче пользователю в поиске нашего объявления слово или фраза между этими тегами будет заменено на ключевое слово, соответствующее поисковому запросу этого пользователя. В случае невозможности замены используется по умолчанию заключенное в эти теги слово или фраза.
И самое для нас полезное в этом инструменте то, что возможно применение шаблонов даже к целевому URL объявления. В этом случае кириллица ключевых слов подставляется в ссылку в формате UTF-8.
Теперь уже мы можем составить с помощью компоновщика URL нечто такое:
yummyhabr.ru/tort/?utm_source=YandexDirect&utm_medium=cpc…
...&utm_term=tort_habrahabr&utm_content=#text_ad1#&utm_campaign=YandexDirect

И увидим в статистике это:

В столбце «содержание объявления» теперь показываются наши ключевые запросы, полученные после применения шаблонов. Сразу видно, что далеко не всегда у нас тут UTF-8. Впрочем, это уже очередная радость от Google Analytics, инструмент Яндекс.Директ тут ни при чём. И становится понятно, почему, чтобы не портить статистику, мы использовали шаблоны именно в utm_content («содержание объявления»), а не в utm_term («ключевые слова»).

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

Минусы очевидны:
«Кракозябру» никто не любит и тяжело понять «откуда же именно пришли те 23 человека».
Опять придётся возиться со всеми нашими объявлениями.
В итоге полно мусора, всё равно приходится ломать глаза над транслитом, да теперь ещё и над «левыми» кодировками.

4) Используем все наработки

На этот метод меня натолкнул пример Брайана Клифтона (Brian Clifton), главы отдела Веб-Аналитики Google, который он привёл в своей книге «Advanced Web Metrics with Google Analytics». В том примере описывалась возможность добавления в основной скрипт Google Analytics, размещаемый на каждой странице сайта, собственного кода, позволяющего работать с Cookie и собирать информацию по источникам перехода.
Итак, возьмём всё, что мы использовали ранее и добавим немного JavaScript.
Для этого мы:
• Помечаем все объявления в нашей кампании метками компоновщика Google, с использованием шаблонов Яндекс.Директ, как в третьем способе. Получаем:
yummyhabr.ru/tort/?utm_source=YandexDirect&utm_medium=cpc…
...&utm_term=tort_habrahabr&utm_content=#text_ad1#&utm_campaign=YandexDirect

• Пишем скрипт на JavaScript (назовём его, к примеру, directdecode.js), который будет вытаскивать параметр utm_content из URL нашей страницы (location.search), раскодируем его с помощью decodeURIComponent и в случае с IE применяем ещё конвертор из Win-1251 в UTF-8. Полученное значение записываем с помощью функции Directkey() в пользовательскую переменную методом "_gaq.push(['_setVar', keyw]);", где keyw — раскодированное нами значение.
• Подключаем на страницы скрипт directdecode.js и добавляем в код Google Analytics, размещаемый на всех наших страницах, вызов функции Directkey() таким образом:
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXXX-X']);
//Вызов функции
Directkey();
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();


Эта функция будет вытаскивать из URL наше ключевое слово, заботливо подставленное туда шаблоном Яндекс.Директа, в случае, необходимости декодировать его и записывать как пользовательскую переменную Analytics.
• Добавляем в нашем аккаунте Google Analytics следующий пользовательский расширенный фильтр к профилю:
Фильтр YandexDirect
Поле А-> “Источник кампании”: YandexDirect
Поле B-> “Определено пользователем”: (.*)
Вывод в-> “Условие поиска кампании”: $B1
*Поле Б обязательно для заполнения

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

Плюсы:
+ Всё на русском языке.
+ Все данные полноценны, отображаются во всех отчётах.
+ Статистика по конкретным ключевым словам.

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


У меня была возможность тщательно протестировать все способы на большой выборке сайтов достаточное время, и я остановился именно на четвёртом способе. Теперь с удовольствием собираю в Google Analytics статистику по контекстной рекламе Яндекс.Директ.
Погрешность измерения по переходам во всех способах составляет 5-10%. Это в пределах нормы.
Алексей Денисов @DeoZ
карма
31,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (51)

  • –3
    Спасибо за статью. Попробую подружить Google Analytics с Яндекс.Директ
  • +1
    Отличный на редкость грамотный материал, и спасибо за скрипт :)
    С ним совсем ушли все проблемы с кодировкой?
    • 0
      Для браузеров Opera, Firefox, Chrome, IE ушли. Возможны проблемы с другими менее распространёнными браузерами. Но в любом случае всё решаемо, можно добавить новые функции перекодировки в этот скрипт.
      Да, и не стоит использовать заглавную букву «Р» в ключевых словах. А то перекодировщик для IE с win1251 на UTF8 спотыкается на этом моменте. )
  • 0
    Спасибо! Интересное решение! Буду пробовать. Раньше приходилось статистику по кампаниям Директа собирать яндексовской же Метрикой.
  • 0
    Для учета ключевых слов используем в ссылке объявления utm_term=## и всё лишние скрипты от лукавого
    • 0
      Пользовательскую переменную лучше для точного реферера приберечь
      • 0
        И с кодировкой проблем не возникает?
        • 0
          Очень мало, со скрипом тоже будут
          • 0
            Я так предполагаю, что кодировки глючат из-за разных рекламных площадок, где выставлены разные кодировки. Вы не выясняли причину?
            • 0
              Нет, дело не в рекламных площадках. Я тестировал и на аккаунтах с отключённой ротацией на тематических площадках, которые крутились только в поисковой выдаче Яндекса.
              Есть гипотеза, что Google Analytics по разному обрабатывает данные в кирилице в зависимости от браузера.
              Могу сказать, что Opera честно отдавала всё в UTF8. Некоторые версии Firefox и Chrome в KOI8-R или ISO-8859, IE в win1251, некоторые версии Safari в win1252.
              • 0
                Вот оно что… об этом я не думал, но тоже очень похоже на правду. Спасибо а ваше исследование. На днях как раз планирую заняться рекламой и для меня этот вопрос очень кстати.
              • 0
                это не гипотеза, это так и есть. самые большие проблемы с FF
      • 0
        Сохранение точного реферера с помощью пользовательской переменной также доступно при использовании способа №4. Для этого достаточно назначить порядок применения фильтра для YandexDirect первым в списке. И после того, как он перепишет содержимое пользовательской переменной, как наше ключевое слово, можно пользоваться этой переменной в последующих фильтрах в любых целях.
    • 0
      Пример использования только шаблонов Яндекса без скриптов можно посмотреть в способе №3. Там они использовались для utm_content, то есть для содержания объявления. Что из этого получилось можно увидеть на приложенном скриншоте. Кодировка часто сбоит.
  • +1
    Если честно, гугл.аналитикс иногда откидывает какие-то невероятные вещи. Типа не показывает версии браузеров — только «производителей». Некоторые мелкие ошибки в интерфейсе месяцами не исправляют.

    Но в статье можно было бы написать, почему надо было сдруживать гугловую статистику с Яндекс.директом и чего не хватает в Метрике. Сам ей не пользовался.
    • 0
      Вот как раз это у меня и вызывает удивление в этой статье и ряде других похожих на «Как забить гвоздь микроскопом» Как правило гвоздь забить удается, но вопрос почему все-таки нельзя было использовать молоток остается открытым.

      И тут. Все эти телодвижения. Зачем они?

      Допустим, задача получить самый тривиальный отчет «по каким ключевым словам с Директа мы получаем хорошую конверсию, и по каким — плохую». У нас есть 2 варианта решения задачи.
      1) Прочитать все что использовал автор, долго переваривать это, в итоге потратить десяток человекочасов на ( а если использовать пункт 1, то даже средняя РК обычного интернет-магазина на 2 тыщи объявлений обеспечит пару недель адски тупого и монотонного труда по проставлению меток на каждое объявление — это вообще безумие)
      2) За 4 клика получить точно такой же отчет по любому срезу в Яндекс.Метрике, которая подключается к аккаунту Директа за пару секунд. Если такая неприязнь к продуктам яндекса крайнем случае счетчик ливинтернета — он тоже из коробки работает.

      Я могу понять когда это делается just for fun или для саморазвития. Но судя по статье автора — это не так. Потрачена тонна сил и времени чтобы получить самый тривиальный отчет. Статья интересна в техническом плане, но абсолютно безумна в качестве практического руководства.
      • 0
        Вы правы и не правы одновременно.
        Вы абсолютно правы, что стоит остановить выбор на Яндекс.Метрике, если её хватает для анализа. Но попробую объяснить зачем нужны все эти телодвижения.
        Вы правильно дали определения, Analytics — действительно микроскоп, но Метрика в таком случае — лупа. И если поверхностного анализа хватает, то ни к чему прибегать к тонкостям и объёму инструментов Analytics. Если же нужны расширенные фильтры, профили, сегментация, удобное отслеживание последовательностей, разделение доступа к аккаунту и прочее, следует обратить внимание на Analytics. Вкратце, к нему чаще прибегают агентства и маркетологи для более глубокого анализа. Но, конечно, лучше выбрать Метрику или более простой из четырёх способ отслеживания (поэтому я и привёл все их нюансы), если их хватает!
        Тут же рассматриваются проблемы обладателей микроскопов…
  • 0
    На самом деле все проще — достаточно распарсить openstat, сохранить и использовать его для идентифкации директа :) Кармы не хватает просто написать (

    Кстати, setVar — deprecated, рекомендую проапдейтиться
    • 0
      Как я написал, openstat хранит только идентификационные номера объявлений и ключевых слов в системе Яндекс.Директ. Поэтому даже если его декодировать и распарсить, нас вряд ли устроят эти цифры в статистике Google Analytics.
      setVar используется намеренно, так как с его заменой setCustomVar нельзя работать через фильтры. Прошу заметить, что setVar в данном случае используется в связке с новым кодом, что вполне работоспособно. Апдейтиться некуда.
      • 0
        чем вам мало ID кампании, ID объявления и ключевого слова посетителя? Это ВСЯ необходимая информация.

        setCustomVar можно заюзать в сегментах и кастомных отчетах, чего вполне достаточно, при том, что setVar собираются убрать вообще
        • 0
          В статье исследуется проблема именно в корректном отображении русскоязычных ключевых слов в отчётах по Яндекс.Директу в Google Analytics. Я специально привёл несколько других способов, минусы и плюсы каждого, чтобы любой мог воспользоваться наиболее подходящим ему. Да, конечно, если кому-то достаточно номеров ключевых слов и с ними вполне удобно работать, то можно использовать их в компоновщике URL, вместо транслита задавая идентификационные номера.
          Если удобно пользоваться сегментами, то можно использовать описанный способ №2.
          Способ №4 я предлагаю для полного удобства, чтобы всё работало и отображалось именно так, как и должно бы отображаться в отчётах по рекламным кампаниям и в общих отчётах по ключевым словам из всех источников.
          • 0
            еще раз. При правильном обращении с опенстат в GA можно иметь:
            — ID кампании
            — ID объявления
            — Ключевое слово (в той форме, которую набрал посетитель)

            И это — только небольшой конфигурацией кода и без фильтров/utm_меток
            • 0
              Да, можно. Для этого придётся также дописывать код на страницы и настраивать фильтры. Но в любом случае при работе с openstat появляются минусы, изложенные к способу №2. Не забывайте, что метка openstat не дописывается к внутренним ссылкам на сайте, а значит при переходе посетителя внутрь сайта, он уже не будет учитываться, как пришедший с Яндекс.Директ. То есть, мы не сможем отслеживать глубину просмотра, конверсии, страницы выхода.
              • 0
                1. Никаких фильров
                2. setCustomVar позволят ставить переменные уровня сессии/перманетные, которые будут на всю сессию, не важно куда он перешел ;)
                • 0
                  Значит опять-таки использовать переменные. Итак, что мы получаем:
                  1. Ключевое слово не в том виде, что задан в нашей кампании. Но в некоторых случаях это даже устраивает.
                  2. Без фильтров не получится использовать эту переменную. В ином же случае:
                  3. Наши данные мы сможем наблюдать только в отчётах по заданным переменным, что не совсем корректно.
                  • 0
                    2/3. Кастомные сегменты не выучили?
                    • 0
                      Для способа №2 предлагаю воспользоваться именно ими. Но это не удобно.
                      Раз уж мы в любом случае используем модифицированный код, создаём сегмент/фильтр (не понимаю, чем Вам так не нравятся фильтры), то почему не использовать приведённый метод №4. И получить данные именно в таком виде, в каком их, например, удобно сравнивать с другими источниками переходов, данными из Яндекс.Метрики, платными переходами с Google.Adwords?
              • 0
                Вам в любом случае, нужно поставить GA код. Сразу втыкаете модифицированный и вуаля
        • 0
          Мне для статистики кроме информации о компании хотелось бы знать ещё и точный запрос, по которому пришёл посетитель, т.к. запускаем контекст по запросу «валенки», а перейти могут по «валенки розовые каталог».
          Так вот когда добавляешь utm-параметры, текст keywords почему-то каверкается, пример каверканья в моём камменте.
          • 0
            habrahabr.ru/blogs/context/117480/?reply_to=3832438#comment_3825340 — еще раз внимательно читаем
            • 0
              Если использовать шаблоны директ — там ключевая фраза разве не обрезается если она слишком длинная? У директа в заголовке максимум 33 символа, а запросы могут быть и длиннее. Сам протестить не могу, т.к. кампанию директа веду не я ;(
  • 0
    А существует ли какой нибудь простой способ отделить посещения с директа, от простых посетителей, с целью узнать сколько посетителей прихоят не с директа? Без компоновщика URL и по возможности вообще без изменений в самом директе.
    • 0
      Используйте способ №2 с openstat. Достаточно отметить один параметр в настройках кампании Яндекс.Директ и включить описанный фильтр.
      Проблема в том, что для Google Analytics нет различия пришёл источник из естественной выдачи Яндекса или с объявления в той же выдаче, переход будет одинаково с адреса вида: yandex.ru/yandsearch?text=... Без дополнительных манипуляций отличий никаких.
  • 0
    У себя использую определение через utm-параметры, но вот почему-то с переходов по результатам поиска keyword всегда нормальный, а вот с контекста — в поле keywords какая-то кривота лезет:
    image
    Причём даже с помощью скрипта самописного научился её декодировать частично, но всё-равно их присутствие как-то не радует.
    Кто-нибудь знает как их победить?
    В user defined я копирую содержимое referrer, вот наглядный пример:
    keyword: b@c1k :0=0

    referrer: yandex.ru/yandsearch?text=%D1%82%D1%80%D1%83%D0%B1%D1%8B+%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5&lr=213

    landing page: /content/blogcategory/3/9/?utm_source=yandex&utm_medium=cpc&utm_campaign=direct&_openstat=ZGlyZWN0LnlhbmRleC5ydTsxODM4NzY4OzU3MzczNDg7eWFuZGV4LnJ1OnByZW1pdW0

    У кого-нибудь встречалась схожая проблема?
    • 0
      Такова загадка Google Analytics, которая и описывается в данной статье. Он по-своему обрабатывает данные, помеченные utm-метками и использует свой набор кодировок для разных браузеров.
      В вашем примере это ключевое слово «трубы канализационные», вероятнее всего по переходу пользователя с браузером Firefox или Chrome.
      • 0
        Да если бы просто была какая-то другая кодировка, то это было-бы лучше, но он каверкает как-то по-своему, что половина фразы бывает вообще отрезается, и декодировать довольно сложно, вот мой самописный скрипт для декодирования этих кракозябр:
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru" dir="ltr">
          <head>
            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        
              <form name="getstring" method="post">
                <input name="string">
                <input type="submit">
              </form>
        <i>Длинные строки могут обрезаться, большие буквы пропадать из запроса.</i>
        
        <?php
        mb_internal_encoding("UTF-8");
        
        
        if(!isset($_POST['string'])) return 'no string!';
          else $str=$_POST['string'];
        
        // $str='';
        // $str2='';
        
        // $str='купить аквариум';
        // $str2=':c?8bl 0:20@8c<';
        
        // $str='где дешево купить аквариум для черепахи';
        // $str2='345 45h52> :c?8bl 0:20@8c< 4';
        
        // $str2='0:20@8c<k, @k1:b =86=89 =>23>@>4';
        
        
        
        echo "String: $str
        ";
        $str_conv='';
        
        for($i=0; $i<strlen($str); $i++) {
          $char=substr($str,$i,1);
        //   $char3='ы';
        //   $char3[0]=chr(256);
        //   $char3[1]=$char2;
          $val=ord($char);
          
          if($val<=47) $decoded=$char;
          elseif($val<=96) $decoded=unichr(1024+$val);
          elseif($val<=108) $decoded=unichr(992+$val);
        //   elseif($val<=108) $decoded=unichr(991+$val);
        //   elseif($val<=107) $decoded=unichr(992+$val);
          else { $decoded="[$char]";
            $test_symb='и';
            echo "character $char val $val - ".uniord($test_symb).' = '.(uniord($test_symb)-$val).'<br />';
          }
        
        //   echo "char $char val $val dec $decoded<br />";
          
          $str_conv.=$decoded;
        }
        
        echo "
        Converted: $str_conv";
        
        function uniord($c)
        {
          $ud = 0;
          if (ord($c{0})>=0 && ord($c{0})<=127)
           $ud = ord($c{0});
          if (ord($c{0})>=192 && ord($c{0})<=223)
           $ud = (ord($c{0})-192)*64 + (ord($c{1})-128);
          if (ord($c{0})>=224 && ord($c{0})<=239)
           $ud = (ord($c{0})-224)*4096 + (ord($c{1})-128)*64 + (ord($c{2})-128);
          if (ord($c{0})>=240 && ord($c{0})<=247)
           $ud = (ord($c{0})-240)*262144 + (ord($c{1})-128)*4096 + (ord($c{2})-128)*64 + (ord($c{3})-128);
          if (ord($c{0})>=248 && ord($c{0})<=251)
           $ud = (ord($c{0})-248)*16777216 + (ord($c{1})-128)*262144 + (ord($c{2})-128)*4096 + (ord($c{3})-128)*64 + (ord($c{4})-128);
          if (ord($c{0})>=252 && ord($c{0})<=253)
           $ud = (ord($c{0})-252)*1073741824 + (ord($c{1})-128)*16777216 + (ord($c{2})-128)*262144 + (ord($c{3})-128)*4096 + (ord($c{4})-128)*64 + (ord($c{5})-128);
          if (ord($c{0})>=254 && ord($c{0})<=255) //error
           $ud = false;
         return $ud;
        }
        
        function unichr($u) {
            return mb_convert_encoding('&#' . intval($u) . ';', 'UTF-8', 'HTML-ENTITIES');
        }
        
        function uniord2($u) {
            $k = mb_convert_encoding($u, 'UCS-2LE', 'UTF-8');
            $k1 = ord(substr($k, 0, 1));
            $k2 = ord(substr($k, 1, 1));
            return $k2 * 256 + $k1;
        }


        Восстанавливает частично, чтобы хотя бы понять о чём фраза.
        • 0
          Чем Вам не подходит описанный в статье способ №4? Он справляется с этой кодировкой. Заодно справляется с проблемами кодировки в IE. Данные хранит в «Пользовательском значении», Ваши пользовательские переменные при этом не будут заняты.
          • 0
            UserDefined у меня уже занято ;( Под полный referrer:
            Field A -> Extract A: referral - (.*)
            Field B -> Extract B: -
            Output To -> Constructor: User Defined - $A1

            Т.к. аналитикс обрезает get-параметры у referrer в статистике, а они для меня бывают весьма полезны.
            • 0
              Если UserDefined занят, нужно просто поместить описанный в способе №4 фильтр выше фильтра записи перехода. Тогда мы успеем и вытащить из него наше декодированное ключевое слово и записать в следующем фильтре реферер.
              Насчёт шаблонов Яндекса. В нашем случае шаблоны используются в URL объявления, а не в заголовке. Его длины нам должно вполне хватить.
              Почитайте ещё раз повнимательнее статью и все основные вопросы должны отпасть.
              • 0
                Спасибо, не знал что такой вариант сработает ;) Попробую тогда таким способом вытаскивать.
          • 0
            Кстати, а по поводу этого глюка с кодировками есть какой-нибудь баг-репорт где можно прийти проголосовать за него?
            • 0
              Не видел такого. Зато видел, что на все подобные вопросы поддержка Google Analytics отвечает: «Используйте компоновщик URL для пометки своих кампаний» и «Не используйте в компоновщике кириллицу».
  • 0
    Кстати, ещё можно с помощью js разбирать openstat и записывать всё это в параметры Custom Variables, вот пример:
    function qs(k,w) { // get GET param from referrer or location (when w='l')
    if(!qs.l) {
    qs.l=window.location.href;
    qs.l=((p=qs.l.indexOf('?'))>0)?qs.l.substring(p):'';
    qs.r=document.referrer;
    qs.r=((p=qs.r.indexOf('?'))>0)?qs.r.substring(p):'';
    }
    var re = new RegExp( "[\?&]" + k + "=([^&$#]*)", "i" );
    var o = (!w)?qs.l.match( re ):qs.r.match( re );

    return ( o == null )?false:o[1];
    }

    if('atob' == typeof window.noFunc) {
    function atob (text) {
    text = text.replace(/\s/g,"");

    if(!(/^[a-z0-9\+\/\s]+\={0,2}$/i.test(text)) || text.length % 4 > 0){
    throw new Error("Not a base64-encoded string.");
    }

    //local variables
    var digits = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/",
    cur, prev, digitNum,
    i=0,
    result = [];

    text = text.replace(/=/g, "");

    while(i < text.length){

    cur = digits.indexOf(text.charAt(i));
    digitNum = i % 4;

    switch(digitNum){

    //case 0: first digit - do nothing, not enough info to work with

    case 1: //second digit
    result.push(String.fromCharCode(prev << 2 | cur >> 4));
    break;

    case 2: //third digit
    result.push(String.fromCharCode((prev & 0x0f) << 4 | cur >> 2));
    break;

    case 3: //fourth digit
    result.push(String.fromCharCode((prev & 3) << 6 | cur));
    break;
    }

    prev = cur;
    i++;
    }

    return result.join("");
    }
    }
    o=qs('_openstat','l')
    ostat_decoded=atob(o)
    pageTracker._setCustomVar(1,"openstat",atob(o));

    После этого в openstat вместо набора буков видно более читаемый текст:
    image

    Ещё к моему скрипту можно добавить js-разбор строки openstat по элементам, но CustomVar всего 5 штук и у меня, к сожалению, 4 оставшихся заняты под другие цели, поэтому пока не делал разбор.

    ЗЫ: функция atob, которая собственно делает основное волшебство, есть только в Firefox и ещё нескольких браузерах, поэтому её для некоторых браузеров приходится эмулировать на js.
    • 0
      Конечно, можно использовать и метки openstat, если способ №4 чем-то не подходит. zzeus также выше в комментариях описал свой вариант такого использования.
  • 0
    Спасибо за материал. Мне лично google analitycs нравится куда больше, чем яндекс метрики. Просто по удобству. Но я никак не мог простить analitycs того, что он не определяет яндекс директ в отдельный источник… С вашими советами analitycs стал для меня еще более мил…
  • 0
    UTM-метки значительно больше дают возможностей, чем подобная расшифровка openstat.
    А если хочется заморочиться, то конечно же можно использовать и то, и то, но при этом не забудьте _openstat вырезать из URL в Аналитиксе.
    А utm-метки в Метрике дают уникальную возможность видеть количество зафиксированных переходов, а не визитов, посетителей и тп, чего в Аналитиксе нет.
  • 0
    Самый простой способ — тупо создать для каждого ключевого слова отдельное обьявление в Директе и пометить ссылки с ключевиками транислитом. Так даже удобнее смотреть отчет — если сегменты врут, то понятно что это ключевое слово от Яндекс Директа.
  • 0
    скажите, а где потом этот отчет смотреть по рекламным кампаниям, помеченным параметрами utm_source, utm_medium и т.д.?

    сделал все по статье по варианту #4, думал что такой отчет автоматически появится в Источники трафика -> Campaigns

    но там ничего не появилось. хотя ждал 3 дня
    • 0
      Там и должны появляться. Если у вас есть в ссылке параметр utm_campaign=YandexDirect, а в Источники трафика -> Campaigns так ничего и не появилось, значит проблема на самых первых шагах. Проверьте работоспособность ссылок, корректность установленного счётчика на целевых страницах, проверьте создаются ли utmz cookie с информацией о кампании.
      • 0
        ну вроде из url параметры ничем не удаляются

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

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

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

        может сможете помочь? я бы мог прислать, как выглядят мои ссылки и мой код счетчика

        • 0
          Постараюсь, конечно. Шлите в личку.

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