Как стать автором
Обновить

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

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

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

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

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

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

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

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

И это — только небольшой конфигурацией кода и без фильтров/utm_меток
Да, можно. Для этого придётся также дописывать код на страницы и настраивать фильтры. Но в любом случае при работе с openstat появляются минусы, изложенные к способу №2. Не забывайте, что метка openstat не дописывается к внутренним ссылкам на сайте, а значит при переходе посетителя внутрь сайта, он уже не будет учитываться, как пришедший с Яндекс.Директ. То есть, мы не сможем отслеживать глубину просмотра, конверсии, страницы выхода.
1. Никаких фильров
2. setCustomVar позволят ставить переменные уровня сессии/перманетные, которые будут на всю сессию, не важно куда он перешел ;)
Значит опять-таки использовать переменные. Итак, что мы получаем:
1. Ключевое слово не в том виде, что задан в нашей кампании. Но в некоторых случаях это даже устраивает.
2. Без фильтров не получится использовать эту переменную. В ином же случае:
3. Наши данные мы сможем наблюдать только в отчётах по заданным переменным, что не совсем корректно.
2/3. Кастомные сегменты не выучили?
Для способа №2 предлагаю воспользоваться именно ими. Но это не удобно.
Раз уж мы в любом случае используем модифицированный код, создаём сегмент/фильтр (не понимаю, чем Вам так не нравятся фильтры), то почему не использовать приведённый метод №4. И получить данные именно в таком виде, в каком их, например, удобно сравнивать с другими источниками переходов, данными из Яндекс.Метрики, платными переходами с Google.Adwords?
Вам в любом случае, нужно поставить GA код. Сразу втыкаете модифицированный и вуаля
Мне для статистики кроме информации о компании хотелось бы знать ещё и точный запрос, по которому пришёл посетитель, т.к. запускаем контекст по запросу «валенки», а перейти могут по «валенки розовые каталог».
Так вот когда добавляешь utm-параметры, текст keywords почему-то каверкается, пример каверканья в моём камменте.
Если использовать шаблоны директ — там ключевая фраза разве не обрезается если она слишком длинная? У директа в заголовке максимум 33 символа, а запросы могут быть и длиннее. Сам протестить не могу, т.к. кампанию директа веду не я ;(
А существует ли какой нибудь простой способ отделить посещения с директа, от простых посетителей, с целью узнать сколько посетителей прихоят не с директа? Без компоновщика URL и по возможности вообще без изменений в самом директе.
Используйте способ №2 с openstat. Достаточно отметить один параметр в настройках кампании Яндекс.Директ и включить описанный фильтр.
Проблема в том, что для Google Analytics нет различия пришёл источник из естественной выдачи Яндекса или с объявления в той же выдаче, переход будет одинаково с адреса вида: yandex.ru/yandsearch?text=... Без дополнительных манипуляций отличий никаких.
У себя использую определение через 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

У кого-нибудь встречалась схожая проблема?
Такова загадка Google Analytics, которая и описывается в данной статье. Он по-своему обрабатывает данные, помеченные utm-метками и использует свой набор кодировок для разных браузеров.
В вашем примере это ключевое слово «трубы канализационные», вероятнее всего по переходу пользователя с браузером Firefox или Chrome.
Да если бы просто была какая-то другая кодировка, то это было-бы лучше, но он каверкает как-то по-своему, что половина фразы бывает вообще отрезается, и декодировать довольно сложно, вот мой самописный скрипт для декодирования этих кракозябр:
<!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;
}


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

Т.к. аналитикс обрезает get-параметры у referrer в статистике, а они для меня бывают весьма полезны.
Если UserDefined занят, нужно просто поместить описанный в способе №4 фильтр выше фильтра записи перехода. Тогда мы успеем и вытащить из него наше декодированное ключевое слово и записать в следующем фильтре реферер.
Насчёт шаблонов Яндекса. В нашем случае шаблоны используются в URL объявления, а не в заголовке. Его длины нам должно вполне хватить.
Почитайте ещё раз повнимательнее статью и все основные вопросы должны отпасть.
Спасибо, не знал что такой вариант сработает ;) Попробую тогда таким способом вытаскивать.
Кстати, а по поводу этого глюка с кодировками есть какой-нибудь баг-репорт где можно прийти проголосовать за него?
Не видел такого. Зато видел, что на все подобные вопросы поддержка Google Analytics отвечает: «Используйте компоновщик URL для пометки своих кампаний» и «Не используйте в компоновщике кириллицу».
Кстати, ещё можно с помощью 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.
Конечно, можно использовать и метки openstat, если способ №4 чем-то не подходит. zzeus также выше в комментариях описал свой вариант такого использования.
Спасибо за материал. Мне лично google analitycs нравится куда больше, чем яндекс метрики. Просто по удобству. Но я никак не мог простить analitycs того, что он не определяет яндекс директ в отдельный источник… С вашими советами analitycs стал для меня еще более мил…
UTM-метки значительно больше дают возможностей, чем подобная расшифровка openstat.
А если хочется заморочиться, то конечно же можно использовать и то, и то, но при этом не забудьте _openstat вырезать из URL в Аналитиксе.
А utm-метки в Метрике дают уникальную возможность видеть количество зафиксированных переходов, а не визитов, посетителей и тп, чего в Аналитиксе нет.
Самый простой способ — тупо создать для каждого ключевого слова отдельное обьявление в Директе и пометить ссылки с ключевиками транислитом. Так даже удобнее смотреть отчет — если сегменты врут, то понятно что это ключевое слово от Яндекс Директа.
скажите, а где потом этот отчет смотреть по рекламным кампаниям, помеченным параметрами utm_source, utm_medium и т.д.?

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

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

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

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

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

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

Постараюсь, конечно. Шлите в личку.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории