Ка — Счётчики перестали работать (полный ноль без https)

Яндекс.Метрика — Счётчики перестали работать (полный ноль без https)

Недавно заметил, что где-то несколько недель назад, среднее количество посетителей по данным Яндекс.Метрики однозначно резко упало.

Так вот, «чисто случайно», захожу на один из своих сайтов, http://BXR.SU/, с публичного компьютера на OS X Yosemite 10.10.5, и моментально получаю следующее сообщение:

Parental Controls
SeaMonkey attempted to access a secure website
https://mc.yandex.ru
Parental Controls restricts access to secure websites. To add this website to your approved list, click Add Website. To do this, you need an administrator password.

Не веря своим глазам, идём в консоль:

Оказывается, теперь вместо учёта посетителей, Яндекс.Метрика просто redirect’ы на https делает!

P.S. Кстати, специально проверил — данные редиректы действительно на статистику никакого впечатления не оказывают, т.е. посетители просто идут лесом (а счётчик прямиком в /dev/null).

ЛОР похож на багтрекер Яндекса? 🙂

Parental Controls restricts access to secure websites

Тебе ж родители запретили, зочем ты лезешь?

С разморозкой. xml.yandex так уже пару месяцев минимум делает

А можно что-то подобное с газовым счётчиком провернуть?

Ну так мне на BXR.SU не запрещали, а на mc.yandex.ru я сам-то вообще не хожу! Мамочка, это вирус?

ЯННП, на моих сайтах все нормально считает, просадки не видно.

Ну так это разные вещи — в xml.yandex идёт аутентификация, TLS нужен для секурности, ну и вообще, там разве раньше без https работало?

А здесь они просто напросто отрубили считалку для X процента пользователей, да ещё и несанкционированные всплывающие окна отдают. Такое поведение ну ни в какие ворота не лезет.

Это они тебе так намекают, чтобы ты с шняндекс счётчиков на нормальные технологии ушёл.

Ну уж не знаю, как ты не заметил. Может аудитория разная?

А я вот заметил просадку где-то месяц или два назад.

Сам счётчик вон, например, из OpenBSD вообще теперь не грузится:

Это да, я тоже так чувствую. Просто лень везде менять. Пытался несколько раз обращаться в суппорт, но они вообще прикидываются, что проблемы даже не понимают. Мол, счётчики пользователи иногда блокируют. WTF?

Если это у них не баг, а фича, то должна быть запись в базе знаний, а никаких записей до сих пор нет.

Неужели и правда всем всё безразлично?

Т.е., вы просто не хотите, чтобы можно было сменить DNS у пользователя, и с минимальными затратами запускать любой JavaScript на любых сайтах рунета?

ИМХО, здесь проблема громоздких счётчиков, а не https. Mail.ru (бывший top.list.ru) выдаёт счётчики с простейшим JavaScript для учёта HTTP_REFERER и разрешения экрана, и никаких внешних скриптов, а вся остальная статистика, которую можно собирать исключительно с JavaScript, для многих всё равно особого интереса не представляет. Они по определению не подвержены вашей уязвимости, так как внешнего JavaScript’а у них таким образом нет.

Так что long-term нужно делать не принудительный https, а опциональную подгрузку внешнего громоздкого JS, возможно с обязательным https и с отдельного хоста. А сам пиксель счётчика оставить типа «//mc.yandex.ru/watch/21237232» — по желанию.

Для меня проблема в том, что из-за принудительного gif’а по https, некоторые пользователи теперь конкретно на моих сайтах получают навязчивые popup сообщения об ошибках, конкретно на OS X как указано выше. Т.е. из-за Яндекса, мне конкретно теперь нужно встать с дивана, и удалить ваш (вредоносный) код, который лично у меня вообще никакого JavaScript’а не содержит:

А в Android 4.2 Browser, например, есть такой баг, что при проблемах сертификата одного из элементов, выдаётся всплывающее окно о сертификате, и если в нём не нажать Continue (например, игнорировать, и перевести фокус обратно на страницу), то браузер автоматически переходит на предыдущую страницу. Мой сайт на моём девайсе в данный момент не подвержен данной проблеме, но кто знает, что будет с завтрашним сертификатом, или на другом чуть устаревшим девайсе?

Хотелось бы видеть отмены https для подгрузки изображений счётчика без JS (как у меня), и введения легкой версии счётчика JavaScript, которая не загружает никакого стороннего JS. Технически, в данной ситуации и с вашей позиции, придётся в определённое время изменить исходный код из-за HSTS, так как Yandex.Metrica не предусмотрела отдельного хоста для самого изображения пикселя.

Предлагаю отменить https при запросе gif’ов, и ввести отдельный новый хост http для продолжения gif’ов, дабы избежать проблем с потерей учёта посетителей по http из-за HSTS в будушем.

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

Я не могу говорить за Яндекс, я там больше не работаю, но, думаю, что

Предлагаю отменить https при запросе gif’ов, и ввести отдельный новый хост http для продолжения gif’ов, дабы избежать проблем с потерей учёта посетителей по http из-за HSTS в будущем.

это предложение расходится со стратегией всех крупных сайтов быть полностью https-only на всех своих доменах.

Представь, как бы ты сам чувствовал, если на твоём сайте в библиотеке тебе бы выдавались постоянные ошибки как выше, при том, что сам сайт у тебя специально является справочным ресурсом, и доступен по http, конкретно для избежания подобных проблем?

Как я написал в блоге, в свое время измерили penalty по тотальному https и оно было признано незначительным по сравнению с теми рисками, которые этот тотальный https предотвращает. Например, не нужно забывать, что некоторые пользователи (их много, десятки миллионов) аутентифицированы в Яндексе и куки для домена yandex.ru могут передаваться открытым текстом в случае обращения к mc.yandex.ru.

В противном случае, я останусь очень недоволен данной ситуацией, и никогда больше не буду использовать такую ненадёжную штуку, как Yandex.Metrica.

Мне искренне жаль. Напомню, что Google уже объявлял, что Google Analytics будет https-only, но я не следил, сделали они это уже, или нет.

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

аутентифицированы в Яндексе и куки для домена yandex.ru могут передаваться открытым текстом в случае обращения к mc.yandex.ru

Ну, блин, тоже мне! Т.е. вы сами хотите до сих пор использовать http, а мне навязываете https? Кто мешает выдавать куки secure, или использовать отдельный домен, как это делает Google-Analytics?

Если https:// так хорош и безпроблемен, почему и yandex, и google, до сих пор можно использовать по «устаревшему» http://?

Google уже объявлял, что Google Analytics будет https-only, но я не следил, сделали они это уже, или нет.

Нет, всё до сих пор работает.

Дополнительно, у них весь API cчётчика открытый: https://developers.google.com/analytics/devguides/collection/protocol/v1/para. , т.е. мало того, что, получается, можно скорее всего их собственный код просто самому себе на сайт залить, и сделать code review, но и использовать GA с более простым кодом счётчика, как на Mail.ru, например. Т.е. они уже предоставляют массу вариантов защиты от атаки.

Ни про какой переход на https я ничего не слышал, и на сайте такого не указано. Более того, это может вызвать многочисленные проблемы на embedded devices, так что очень сомневаюсь, что они будут отключать пиксели по http. Чего и Яндексу рекомендую.

В этой конкретно ситуации я считаю, что проблема находится на стороне браузеров, которые в XXI веке не понимают https — по технологическим или по политическим причинам.

Я привёл личный пример, где лично мне был запрешён https на публичном компе. PHK говорит, что это ситуация, между прочим, встречается очень часто:

The so-called «multimedia business,» which amounts to about 30% of all traffic on the net, expresses no desire to be forced to spend resources on pointless encryption. There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on. Yet, despite this, HTTP/2.0 will be SSL/TLS only, in at least three out of four of the major browsers, in order to force a particular political agenda. The same browsers, ironically, treat self-signed certificates as if they were mortally dangerous, despite the fact that they offer secrecy at trivial cost.

И чем https поможет пользователем Казахстана? Раньше они могли банковские счета проверять без MitM, теперь — нет, всё из-за вездесущего https на каждом левом сайте. Или в ситуации enterprise, использование https — хороший способ несанкционированной передачи коммерческих тайн и секретной информации, распространению вирусов, так что им тоже приходится https либо полностью запрещать, либо ломать. И в чём тогда мне смысл, если мой сайт либо неоткрывается вообще, либо выдаёт ошибки? Яндекс и Гугл не хотят терять ни одного посетителя, а почему я для них должен с HSTS?

Например, мне очевидно, что объяснять выключение https защитой детей — это просто обман.

Это почему ещё так?

В пост-сноуденовскую эпоху использование https является самоочевидным, это должны понимать все, кто претендует на техническую грамотность.

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

Нужно ли запрещать http://, или отказываться показывать весь неподписанный контент, для которого никакой аутенфикации пользовательских данных не требуется? Абсолютно нет.

Не вижу никакой необходимости ломать backwards compatibility, которая работала десятилетиями.

Если кафе или автозаправка в России или Кении хочет предложить доступ к моему ресурсу за счёт добавления рекламы, это их дело и их клиентов, а не моё. Пусть клиенты сами решают, где им пользоваться интернетом.

Если Казахстан хочет следить за тем, какой файл является более популярным на моём сайте, флаг им в руки!

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

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

Выкладывай на FTP.

FTP ни у кого уже не поддерживается, это вообще устаревший протокол, есть проблемы с NAT и firewall, например. Файлы нужно специально «качать» и сохранять на диск, и т.д.

Кстати, т.к. HSTS подразумевает автоматическую замену `http://` на `https://` для хоста (http://tools.ietf.org/html/rfc6797#section-8.3), то, собственно, зачем тогда вообще делать постоянный redirect из http в https? Ведь некоторые сайты всё же используют https сами, вот пусть через их счётчики и прописывается HSTS (для которого нужно установленное и корректное соединение https, http://tools.ietf.org/html/rfc6797#section-8.1), а у кого https не работает, те будут ходить по http. Получаем win/win — и хорошую защиту для активных пользователей с передовыми устройствами, и полную обратную совместимость для всех остальных.

Кстати, в документации написано, что даже нельзя пользователю давать опцию игнорировать ошибки. http://tools.ietf.org/html/rfc6797#section-12.1 Это так действительно везде сделано, или всё-таки разумность победила, и такого функционала защиты сайтов от пользователей реализовывать не стали?

Это так действительно везде сделано

Да. Прямо сегодня столкнулся — у меня на тестовом сервере несколько копий сайта запущено для отладки на разных портах. После того как один поставил HSTS с нормальными сертификатами, браузер на второй с самоподписными не захотел ходить. Пришлось сертификаты подкрутить.

Но вообще http должен помереть. То что кто-то хочет трафик снифить — не аргумент.

Но вообще http должен помереть. То что кто-то хочет трафик снифить — не аргумент.

С чего же это не аргумент? Аргументируй. HTTP нужен, и будет ещё очень долго жить.

Чем отличаются визиты от просмотров в «Яндекс.Метрике»?

Работая со статистикой в «Яндекс.Метрике», вы наверняка сталкивались с просмотрами и визитами. Их можно легко спутать, так как они схожи по значению. Чтобы этого не происходило, давайте разберемся, в чем разница.

Яндекс.Метрика

Итак, чем отличаются визиты от просмотров в «Яндекс.Метрике»? Для начала давайте дадим определение каждому понятию.

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

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

Несколько просмотров могут входить в один визит, если они совершены одним и тем же пользователем. Например, пользователь перешел на главную страницу сайта из поиска. В данный момент «Метрика» засчитала и просмотр, и визит. Спустя 5 минут он открыл страницу с тарифами. В данный момент засчитался новый просмотр, так как была открыта новая страница («Тарифы»), но не засчитался новый визит, так как с момента последнего взаимодействия пользователя с сайтом прошло менее 30 минут. Затем, спустя 10 минут, пользователь открыл страницу с контактными данными. «Метрика» засчитала еще один просмотр, так как была загружена страница «Контакты», но по-прежнему не засчитала новый визит. Потом пользователь просто закрыл сайт.

Таким образом, в результате данной сессии в отчетах «Метрики» будет зафиксирован 1 визит и 3 просмотра.

Более подробно о визитах

Один и тот же визит пользователя может длиться хоть сутки, если он не реже чем раз в 30 минут производил какое-либо действие на страницах веб-ресурса.

Новый визит будет засчитан, если:

• на сайт зайдет новый пользователь;
• с момента последнего взаимодействия одного и того же пользователя с сайтом пройдет более 30 минут;
• будет выполнен переход по рекламному объявлению.

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

Давайте рассмотрим пример. Человек ввел запрос «пылесосы купить». В органической выдаче поиска увидел ссылку вашего сайта (не реклама) и перешел по ней. Он просмотрел пару моделей и спустя 2–3 минуты закрыл сайт. Спустя 10 минут он ввел еще один запрос «недорогие пылесосы» и снова увидел ссылку вашего сайта, только на этот раз это было рекламное объявление, размещенное через «Директ». Человек перешел на ваш сайт, просмотрел несколько моделей и также спустя 2–3 минуты закрыл вкладку.

В данном случае система засчитает 2 визита. Первый длился с момента перехода из поисковой органической выдачи до первого закрытия сайта. Второй – с момента перехода по рекламному объявлению и до закрытия сайта.

Несмотря на то, что между двумя этими визитами на сайте прошло менее 30 минут, в «Метрике» отобразятся два разных визита, закрепленные за одним целевым посетителем.

Посетители

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

Как проверить цели в Яндекс Метрике?

В прошлой статье я рассказал про 2 способа проверить цели в Google Analytics. Сегодня пришло время разобраться, как убедиться, что конверсии улетают в Яндекс Метрику. Это тоже можно сделать быстро и просто. И не нужно обладать знаниями программиста.

Как проверить работу целей в Метрике?

Конечно, цели можно проверить в самой Метрике. Например, в Вебвизоре или в отчете «Конверсии». Но беда в том, что Метрика отображает цели в отчетах с опозданием. А ждать 10 минут не хочется. Хочется разобраться здесь и сейчас

В качестве испытуемого возьмем сайт по морскому фрахту fraht.ru.com

И первым делом обратимся к справке по Яндекс Метрике. А она говорит вот что:

Отладчик целей ym_debug для Метрики

Как видите, для отладки целей достаточно дописать к урлу страницы такой хвост:

В моем случае ссылка ссылка принимает вид:

Отлично, половина дела сделана — теперь мы знаем, как вызывать отладчик событий для Метрики. Теперь немножко поработаем с отладчиком кода в браузере.

Инспектор кода для отладки целей

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

Я пользуюсь Яндекс браузером и у меня при нажатии пкм среди прочего есть «исследовать элемент»:

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

Что ж, пришло время использовать дебуг от Метрики, который мы рассмотрели выше. Дописываем в адресной строке браузера к урл сайта хвост дебуг (рассмотренный ранее), жмем Enter (загружаем новый урл с хвостом) и пошла вода горячая:

Как видите, счетчик начал отправлять в метрику информацию технического характера. Но нас интересует, а работает ли цель? Давайте разбираться, друзья.

На данном сайте настроена цель-событие, которая улетает в метрику при успешной отправке формы. О том, как настроить цель на отправку формы в Метрике я рассказывал в данной статье.

Поэтому прямо сейчас (с включенной консолью и дебугом) я делаю тестовую конверсию — отправляю заявку через форму на сайте. И… что мы видим!

Как видите, дебуг сообщает, что в Метрику успешно отправлена цель, которая имеет И действительно, в Метрике у меня настроено событие с таким идентификатором:

Отлично! Событие улетает в Метрику, а это значит, что скоро в отчетах появится достижение цели. Задача выполнена.

Резюме

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

• включить отладчик кода в браузере;
• включить отладчик целей в Метрике (добавить хвост к url страницы);
• отправить тестовую конверсию.

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

Почему Google Analytics и Яндекс.Метрика показывают разные данные

Если вы используете на сайте несколько счетчиков, наверняка, замечали, что все они показывают разные значения. Google Analytics, Яндекс.Метрика, Liveinternet, и даже часто статистика в Adwords и Директ не совпадает с той, которую мы видим в системах аналитики.

За одну неделю ко мне обратились три разных человека с похожими вопросами.

“Сейчас занимаемся продвижением журналов бухгалтерской тематики и на одном из наших порталов особо заметно, что аналитикс показывает женский пол – 90%, а метрика – 65% и возраст также разнится, к примеру, в аналитиксе – 35-44 лет – 34% (большая часть), а по данным метрики 25-34 (53%). Какому из счетчиков верить? Понимаю, что они берут данные из аккаунтов, в которых нету достоверной информации, но возможно вы проводили эксперименты и можете подсказать, где более точная выборка.” / Татьяна

“Почему такая колоссальная разница в результатах яндекс-метрики и гугл-аналитики? Например, за сегодня смотрю – Яндекс.Метрика 8 визитов, 9 просмотров. Гугл.Аналитика 25 визитов, 128 просмотров… Что за дикая разница? Чем это вызвано? Каких посетителей не видит Яндекс.Метрика?” / Константин

“У меня почему то сильно отличается показатель отказов в я метрике и аналитиксе 25 и 60 процев соответственно.” / Павел

А вот наглядная картина, как это выглядит на примере. Ниже представлен скриншот отчета Яндекс.Метрики по источникам за март-месяц для одного из интернет-магазинов:

Выше приведен срез по поисковым системам, а ниже, по рекламным:

А это данные из Google Analytics за тот же период времени.

В метрике, количество визитов из Google, практически, на 1000 посетителей меньше (около 20% разницы), то же самое с посещениями из Яндекса. Показатель отказов в метрике в районе 30-40%, а в аналитиксе подозрительно мало — 2-3%. Также существенная разница наблюдается по цифрам рекламных каналов.

Почему так происходит, какие счетчики врут и кому стоит доверять?

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

Разные данные для обработки

Яндекс.Метрика и Google Analytics могут видеть разных пользователей по ряду причин.

— Счетчики установлены в разных местах HTML -кода. Например, если счетчик аналитики установлен в теге <head>, а метрики перед закрывающим тегом </body>, то большинство пользователей, не дождавшихся загрузки страницы (закрывшие её или ушедшие на другие страницы), не будут видны яндекс-метрике.

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

— Настройки фильтров. Системы аналитики имеют как фильтры “по умолчанию” (типа защиты от роботов), так и ручные фильтры, где можно запретить учитывать свои посещения или посещения с определенных IP и т.д. Разные фильтры (а фильтры “по умолчанию” по умолчанию разные) приводят также к разнице в данных.

— Учет сайтов-зеркал. Счетчик может быть установлен не только на одном сайте, но на нескольких, собирая статистику со всех из них в один аккаунт. В зависимости от корректности установки счетчиков и настройки зеркал, данные итоговой статистики также могут разниться.

— Другие настройки счетчика. К примеру, в Яндекс.Метрике имеется настройка “Таймаут визита” (время бездействия посетителя, после которого визит считается завершенным). Как только вы выставите здесь другую цифру, количество визитов в новых данных изменится.

— Залогиненные пользователи в Яндекс и Google это разные наборы данных, из которых берутся всякие показатели, типа демографических характеристик. Они всегда будут разными и тут нет вопроса кому доверять, используйте эти цифры как есть. Если нужна высокая точность, то лучше для анализа демографии использовать другие инструменты (в том числе независимые исследования, например, в компаниях GFk или TNS .).

Разная терминология

Мы привыкли называть визиты посещениями, но:
Визиты в Яндексе — число сеансов взаимодействия посетителей с сайтом, включающих один и более просмотров страниц. Визит прекращается спустя 30 минут отсутствия активности от пользователя.
К сеансу в Google привязываются все данные об использовании (просмотры, события, транзакции и др). Например, если при посещении страницы мы инициируем какое-либо событие (event, например, при клике на исходящую ссылку), то этот сеанс уже не будет считаться отказом в Google Analytics (в новом коде уже имеется параметр, которым можно регулировать, будет ли это влиять на отказ или нет).

То же самое с показателем отказов.
В Google — процент посещений, в ходе которых было открыто не более одной страницы.
В Яндексе — доля визитов, в рамках которых состоялся лишь один просмотр страницы. Если в настройках счётчика включен режим “Точный показатель отказов”, то на такие визиты накладывается дополнительное ограничение по времени активности посетителя — если страница просматривалась больше 15 секунд, то визит не считается отказом.

Также, если рекламные ссылки не помечены идентификаторами, то переходы из сторонних рекламных сервисов система будет включать в органику. Например, гугл не видит некоторые клики с Директа, а Яндекс некоторые клики с AdWords и включает всё это в органику.

Кроме того, есть и другие отличия подсчета данных. К примеру, трафик из поиска по изображениям Google включает в органику. Для тех сайтов, где из поиска по изображениям идёт ощутимый трафик, это может дополнительно разнить статистику с другими системами.

Редкие баги

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

Universal properties created prior to December 2013 may temporarily report doubled Visits counts between the hours of 0500-0800 in the View timezone. This issue corrects itself automatically. We are working on a fix to address this issue as soon as possible.

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

Как мы видим, счетчики не врут, они просто оперируют разными данными, в зависимости от своих и наших настроек. Стоит ли ориентироваться на Яндекс.Метрику или Google Analytics? Тут все зависит от того, какие параметры вы измеряете и какой смысл в них вкладываете. Полезно будет ознакомиться с документацией по этим популярным системам аналитики, чтобы лучше ориентироваться в настройках и измерениях: