Комментарии 51
Спасибо за статью. Попробую подружить Google Analytics с Яндекс.Директ
-3
Отличный на редкость грамотный материал, и спасибо за скрипт :)
С ним совсем ушли все проблемы с кодировкой?
С ним совсем ушли все проблемы с кодировкой?
+1
Для браузеров Opera, Firefox, Chrome, IE ушли. Возможны проблемы с другими менее распространёнными браузерами. Но в любом случае всё решаемо, можно добавить новые функции перекодировки в этот скрипт.
Да, и не стоит использовать заглавную букву «Р» в ключевых словах. А то перекодировщик для IE с win1251 на UTF8 спотыкается на этом моменте. )
Да, и не стоит использовать заглавную букву «Р» в ключевых словах. А то перекодировщик для 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.
Есть гипотеза, что Google Analytics по разному обрабатывает данные в кирилице в зависимости от браузера.
Могу сказать, что Opera честно отдавала всё в UTF8. Некоторые версии Firefox и Chrome в KOI8-R или ISO-8859, IE в win1251, некоторые версии Safari в win1252.
0
Сохранение точного реферера с помощью пользовательской переменной также доступно при использовании способа №4. Для этого достаточно назначить порядок применения фильтра для YandexDirect первым в списке. И после того, как он перепишет содержимое пользовательской переменной, как наше ключевое слово, можно пользоваться этой переменной в последующих фильтрах в любых целях.
0
Пример использования только шаблонов Яндекса без скриптов можно посмотреть в способе №3. Там они использовались для utm_content, то есть для содержания объявления. Что из этого получилось можно увидеть на приложенном скриншоте. Кодировка часто сбоит.
0
Если честно, гугл.аналитикс иногда откидывает какие-то невероятные вещи. Типа не показывает версии браузеров — только «производителей». Некоторые мелкие ошибки в интерфейсе месяцами не исправляют.
Но в статье можно было бы написать, почему надо было сдруживать гугловую статистику с Яндекс.директом и чего не хватает в Метрике. Сам ей не пользовался.
Но в статье можно было бы написать, почему надо было сдруживать гугловую статистику с Яндекс.директом и чего не хватает в Метрике. Сам ей не пользовался.
+1
Вот как раз это у меня и вызывает удивление в этой статье и ряде других похожих на «Как забить гвоздь микроскопом» Как правило гвоздь забить удается, но вопрос почему все-таки нельзя было использовать молоток остается открытым.
И тут. Все эти телодвижения. Зачем они?
Допустим, задача получить самый тривиальный отчет «по каким ключевым словам с Директа мы получаем хорошую конверсию, и по каким — плохую». У нас есть 2 варианта решения задачи.
1) Прочитать все что использовал автор, долго переваривать это, в итоге потратить десяток человекочасов на ( а если использовать пункт 1, то даже средняя РК обычного интернет-магазина на 2 тыщи объявлений обеспечит пару недель адски тупого и монотонного труда по проставлению меток на каждое объявление — это вообще безумие)
2) За 4 клика получить точно такой же отчет по любому срезу в Яндекс.Метрике, которая подключается к аккаунту Директа за пару секунд. Если такая неприязнь к продуктам яндекса крайнем случае счетчик ливинтернета — он тоже из коробки работает.
Я могу понять когда это делается just for fun или для саморазвития. Но судя по статье автора — это не так. Потрачена тонна сил и времени чтобы получить самый тривиальный отчет. Статья интересна в техническом плане, но абсолютно безумна в качестве практического руководства.
И тут. Все эти телодвижения. Зачем они?
Допустим, задача получить самый тривиальный отчет «по каким ключевым словам с Директа мы получаем хорошую конверсию, и по каким — плохую». У нас есть 2 варианта решения задачи.
1) Прочитать все что использовал автор, долго переваривать это, в итоге потратить десяток человекочасов на ( а если использовать пункт 1, то даже средняя РК обычного интернет-магазина на 2 тыщи объявлений обеспечит пару недель адски тупого и монотонного труда по проставлению меток на каждое объявление — это вообще безумие)
2) За 4 клика получить точно такой же отчет по любому срезу в Яндекс.Метрике, которая подключается к аккаунту Директа за пару секунд. Если такая неприязнь к продуктам яндекса крайнем случае счетчик ливинтернета — он тоже из коробки работает.
Я могу понять когда это делается just for fun или для саморазвития. Но судя по статье автора — это не так. Потрачена тонна сил и времени чтобы получить самый тривиальный отчет. Статья интересна в техническом плане, но абсолютно безумна в качестве практического руководства.
0
Вы правы и не правы одновременно.
Вы абсолютно правы, что стоит остановить выбор на Яндекс.Метрике, если её хватает для анализа. Но попробую объяснить зачем нужны все эти телодвижения.
Вы правильно дали определения, Analytics — действительно микроскоп, но Метрика в таком случае — лупа. И если поверхностного анализа хватает, то ни к чему прибегать к тонкостям и объёму инструментов Analytics. Если же нужны расширенные фильтры, профили, сегментация, удобное отслеживание последовательностей, разделение доступа к аккаунту и прочее, следует обратить внимание на Analytics. Вкратце, к нему чаще прибегают агентства и маркетологи для более глубокого анализа. Но, конечно, лучше выбрать Метрику или более простой из четырёх способ отслеживания (поэтому я и привёл все их нюансы), если их хватает!
Тут же рассматриваются проблемы обладателей микроскопов…
Вы абсолютно правы, что стоит остановить выбор на Яндекс.Метрике, если её хватает для анализа. Но попробую объяснить зачем нужны все эти телодвижения.
Вы правильно дали определения, Analytics — действительно микроскоп, но Метрика в таком случае — лупа. И если поверхностного анализа хватает, то ни к чему прибегать к тонкостям и объёму инструментов Analytics. Если же нужны расширенные фильтры, профили, сегментация, удобное отслеживание последовательностей, разделение доступа к аккаунту и прочее, следует обратить внимание на Analytics. Вкратце, к нему чаще прибегают агентства и маркетологи для более глубокого анализа. Но, конечно, лучше выбрать Метрику или более простой из четырёх способ отслеживания (поэтому я и привёл все их нюансы), если их хватает!
Тут же рассматриваются проблемы обладателей микроскопов…
0
На самом деле все проще — достаточно распарсить openstat, сохранить и использовать его для идентифкации директа :) Кармы не хватает просто написать (
Кстати, setVar — deprecated, рекомендую проапдейтиться
Кстати, setVar — deprecated, рекомендую проапдейтиться
0
Как я написал, openstat хранит только идентификационные номера объявлений и ключевых слов в системе Яндекс.Директ. Поэтому даже если его декодировать и распарсить, нас вряд ли устроят эти цифры в статистике Google Analytics.
setVar используется намеренно, так как с его заменой setCustomVar нельзя работать через фильтры. Прошу заметить, что setVar в данном случае используется в связке с новым кодом, что вполне работоспособно. Апдейтиться некуда.
setVar используется намеренно, так как с его заменой setCustomVar нельзя работать через фильтры. Прошу заметить, что setVar в данном случае используется в связке с новым кодом, что вполне работоспособно. Апдейтиться некуда.
0
чем вам мало ID кампании, ID объявления и ключевого слова посетителя? Это ВСЯ необходимая информация.
setCustomVar можно заюзать в сегментах и кастомных отчетах, чего вполне достаточно, при том, что setVar собираются убрать вообще
setCustomVar можно заюзать в сегментах и кастомных отчетах, чего вполне достаточно, при том, что setVar собираются убрать вообще
0
В статье исследуется проблема именно в корректном отображении русскоязычных ключевых слов в отчётах по Яндекс.Директу в Google Analytics. Я специально привёл несколько других способов, минусы и плюсы каждого, чтобы любой мог воспользоваться наиболее подходящим ему. Да, конечно, если кому-то достаточно номеров ключевых слов и с ними вполне удобно работать, то можно использовать их в компоновщике URL, вместо транслита задавая идентификационные номера.
Если удобно пользоваться сегментами, то можно использовать описанный способ №2.
Способ №4 я предлагаю для полного удобства, чтобы всё работало и отображалось именно так, как и должно бы отображаться в отчётах по рекламным кампаниям и в общих отчётах по ключевым словам из всех источников.
Если удобно пользоваться сегментами, то можно использовать описанный способ №2.
Способ №4 я предлагаю для полного удобства, чтобы всё работало и отображалось именно так, как и должно бы отображаться в отчётах по рекламным кампаниям и в общих отчётах по ключевым словам из всех источников.
0
еще раз. При правильном обращении с опенстат в GA можно иметь:
— ID кампании
— ID объявления
— Ключевое слово (в той форме, которую набрал посетитель)
И это — только небольшой конфигурацией кода и без фильтров/utm_меток
— ID кампании
— ID объявления
— Ключевое слово (в той форме, которую набрал посетитель)
И это — только небольшой конфигурацией кода и без фильтров/utm_меток
0
Да, можно. Для этого придётся также дописывать код на страницы и настраивать фильтры. Но в любом случае при работе с openstat появляются минусы, изложенные к способу №2. Не забывайте, что метка openstat не дописывается к внутренним ссылкам на сайте, а значит при переходе посетителя внутрь сайта, он уже не будет учитываться, как пришедший с Яндекс.Директ. То есть, мы не сможем отслеживать глубину просмотра, конверсии, страницы выхода.
0
1. Никаких фильров
2. setCustomVar позволят ставить переменные уровня сессии/перманетные, которые будут на всю сессию, не важно куда он перешел ;)
2. setCustomVar позволят ставить переменные уровня сессии/перманетные, которые будут на всю сессию, не важно куда он перешел ;)
0
Значит опять-таки использовать переменные. Итак, что мы получаем:
1. Ключевое слово не в том виде, что задан в нашей кампании. Но в некоторых случаях это даже устраивает.
2. Без фильтров не получится использовать эту переменную. В ином же случае:
3. Наши данные мы сможем наблюдать только в отчётах по заданным переменным, что не совсем корректно.
1. Ключевое слово не в том виде, что задан в нашей кампании. Но в некоторых случаях это даже устраивает.
2. Без фильтров не получится использовать эту переменную. В ином же случае:
3. Наши данные мы сможем наблюдать только в отчётах по заданным переменным, что не совсем корректно.
0
2/3. Кастомные сегменты не выучили?
0
Для способа №2 предлагаю воспользоваться именно ими. Но это не удобно.
Раз уж мы в любом случае используем модифицированный код, создаём сегмент/фильтр (не понимаю, чем Вам так не нравятся фильтры), то почему не использовать приведённый метод №4. И получить данные именно в таком виде, в каком их, например, удобно сравнивать с другими источниками переходов, данными из Яндекс.Метрики, платными переходами с Google.Adwords?
Раз уж мы в любом случае используем модифицированный код, создаём сегмент/фильтр (не понимаю, чем Вам так не нравятся фильтры), то почему не использовать приведённый метод №4. И получить данные именно в таком виде, в каком их, например, удобно сравнивать с другими источниками переходов, данными из Яндекс.Метрики, платными переходами с Google.Adwords?
0
Вам в любом случае, нужно поставить GA код. Сразу втыкаете модифицированный и вуаля
0
Мне для статистики кроме информации о компании хотелось бы знать ещё и точный запрос, по которому пришёл посетитель, т.к. запускаем контекст по запросу «валенки», а перейти могут по «валенки розовые каталог».
Так вот когда добавляешь utm-параметры, текст keywords почему-то каверкается, пример каверканья в моём камменте.
Так вот когда добавляешь utm-параметры, текст keywords почему-то каверкается, пример каверканья в моём камменте.
0
habrahabr.ru/blogs/context/117480/?reply_to=3832438#comment_3825340 — еще раз внимательно читаем
0
А существует ли какой нибудь простой способ отделить посещения с директа, от простых посетителей, с целью узнать сколько посетителей прихоят не с директа? Без компоновщика URL и по возможности вообще без изменений в самом директе.
0
Используйте способ №2 с openstat. Достаточно отметить один параметр в настройках кампании Яндекс.Директ и включить описанный фильтр.
Проблема в том, что для Google Analytics нет различия пришёл источник из естественной выдачи Яндекса или с объявления в той же выдаче, переход будет одинаково с адреса вида: yandex.ru/yandsearch?text=... Без дополнительных манипуляций отличий никаких.
Проблема в том, что для Google Analytics нет различия пришёл источник из естественной выдачи Яндекса или с объявления в той же выдаче, переход будет одинаково с адреса вида: yandex.ru/yandsearch?text=... Без дополнительных манипуляций отличий никаких.
0
У себя использую определение через utm-параметры, но вот почему-то с переходов по результатам поиска keyword всегда нормальный, а вот с контекста — в поле keywords какая-то кривота лезет:
Причём даже с помощью скрипта самописного научился её декодировать частично, но всё-равно их присутствие как-то не радует.
Кто-нибудь знает как их победить?
В 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
У кого-нибудь встречалась схожая проблема?
Причём даже с помощью скрипта самописного научился её декодировать частично, но всё-равно их присутствие как-то не радует.
Кто-нибудь знает как их победить?
В 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.
В вашем примере это ключевое слово «трубы канализационные», вероятнее всего по переходу пользователя с браузером 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:
Т.к. аналитикс обрезает get-параметры у referrer в статистике, а они для меня бывают весьма полезны.
Field A -> Extract A: referral - (.*)
Field B -> Extract B: -
Output To -> Constructor: User Defined - $A1
Т.к. аналитикс обрезает get-параметры у referrer в статистике, а они для меня бывают весьма полезны.
0
Если UserDefined занят, нужно просто поместить описанный в способе №4 фильтр выше фильтра записи перехода. Тогда мы успеем и вытащить из него наше декодированное ключевое слово и записать в следующем фильтре реферер.
Насчёт шаблонов Яндекса. В нашем случае шаблоны используются в URL объявления, а не в заголовке. Его длины нам должно вполне хватить.
Почитайте ещё раз повнимательнее статью и все основные вопросы должны отпасть.
Насчёт шаблонов Яндекса. В нашем случае шаблоны используются в URL объявления, а не в заголовке. Его длины нам должно вполне хватить.
Почитайте ещё раз повнимательнее статью и все основные вопросы должны отпасть.
0
Кстати, а по поводу этого глюка с кодировками есть какой-нибудь баг-репорт где можно прийти проголосовать за него?
0
Кстати, ещё можно с помощью js разбирать openstat и записывать всё это в параметры Custom Variables, вот пример:
После этого в openstat вместо набора буков видно более читаемый текст:
Ещё к моему скрипту можно добавить js-разбор строки openstat по элементам, но CustomVar всего 5 штук и у меня, к сожалению, 4 оставшихся заняты под другие цели, поэтому пока не делал разбор.
ЗЫ: функция atob, которая собственно делает основное волшебство, есть только в Firefox и ещё нескольких браузерах, поэтому её для некоторых браузеров приходится эмулировать на js.
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 вместо набора буков видно более читаемый текст:
Ещё к моему скрипту можно добавить js-разбор строки openstat по элементам, но CustomVar всего 5 штук и у меня, к сожалению, 4 оставшихся заняты под другие цели, поэтому пока не делал разбор.
ЗЫ: функция atob, которая собственно делает основное волшебство, есть только в Firefox и ещё нескольких браузерах, поэтому её для некоторых браузеров приходится эмулировать на js.
0
Конечно, можно использовать и метки openstat, если способ №4 чем-то не подходит. zzeus также выше в комментариях описал свой вариант такого использования.
0
Спасибо за материал. Мне лично google analitycs нравится куда больше, чем яндекс метрики. Просто по удобству. Но я никак не мог простить analitycs того, что он не определяет яндекс директ в отдельный источник… С вашими советами analitycs стал для меня еще более мил…
0
UTM-метки значительно больше дают возможностей, чем подобная расшифровка openstat.
А если хочется заморочиться, то конечно же можно использовать и то, и то, но при этом не забудьте _openstat вырезать из URL в Аналитиксе.
А utm-метки в Метрике дают уникальную возможность видеть количество зафиксированных переходов, а не визитов, посетителей и тп, чего в Аналитиксе нет.
А если хочется заморочиться, то конечно же можно использовать и то, и то, но при этом не забудьте _openstat вырезать из URL в Аналитиксе.
А utm-метки в Метрике дают уникальную возможность видеть количество зафиксированных переходов, а не визитов, посетителей и тп, чего в Аналитиксе нет.
0
Самый простой способ — тупо создать для каждого ключевого слова отдельное обьявление в Директе и пометить ссылки с ключевиками транислитом. Так даже удобнее смотреть отчет — если сегменты врут, то понятно что это ключевое слово от Яндекс Директа.
0
скажите, а где потом этот отчет смотреть по рекламным кампаниям, помеченным параметрами utm_source, utm_medium и т.д.?
сделал все по статье по варианту #4, думал что такой отчет автоматически появится в Источники трафика -> Campaigns
но там ничего не появилось. хотя ждал 3 дня
сделал все по статье по варианту #4, думал что такой отчет автоматически появится в Источники трафика -> Campaigns
но там ничего не появилось. хотя ждал 3 дня
0
Там и должны появляться. Если у вас есть в ссылке параметр utm_campaign=YandexDirect, а в Источники трафика -> Campaigns так ничего и не появилось, значит проблема на самых первых шагах. Проверьте работоспособность ссылок, корректность установленного счётчика на целевых страницах, проверьте создаются ли utmz cookie с информацией о кампании.
0
ну вроде из url параметры ничем не удаляются
по крайней мере моя ссылка в браузере при переходе по объявлению показывается
счетчик установлен. уж не знаю на сколько корректно, но js ошибок браузер не показывает и в гугле статистика считается
но там переходы по директу записываются просто как переходы из яндекса
может сможете помочь? я бы мог прислать, как выглядят мои ссылки и мой код счетчика
по крайней мере моя ссылка в браузере при переходе по объявлению показывается
счетчик установлен. уж не знаю на сколько корректно, но js ошибок браузер не показывает и в гугле статистика считается
но там переходы по директу записываются просто как переходы из яндекса
может сможете помочь? я бы мог прислать, как выглядят мои ссылки и мой код счетчика
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Учим Google Analytics дружить с Яндекс.Директ