Урлы по обоим проектам будьте добры в личку и доступ к стате (гостевой доступ к метрике дал бы более положительный предварительный профит)
Это боты. Сталкиваюсь постоянно. Решение проблемы:
Настройки счетчика метрики - фильтры - фильтрация роботов - установить на "фильтровать роботов по строгим правилам и поведению".---------- Добавлено 28.12.2015 в 19:25 ----------
Риэлторское агентство по продаже элитной зарубежной недвижимости.
Итак.
1. При запуске рекламной кампании нужно, чтобы ключевой запрос - текст и заголовок объявления - посадочная страница (с актуальной информацией) были релевантны друг другу. И тогда будут и звонки и заказы. Также стоит учитывать сезонность, конкурентные преимущества или недостатки, товар с отложенным спросом и прочие моменты. Не бывает такого, что запустив рекламную кампанию - сразу идут продажи, вне зависимости от кучи сопутствующих факторов.
2. Вносить корректировки надо не наугад, а на основе аналитики и аудита сайта и рекламной кампании, если вы вносите правки "наугад", то лучше обращаться к специалистам, которые проведут те или иные работы и укажут на недочеты в плане рекламных материалов, юзабилити и внешних факторов.
3. Скрипт StopExit - зло. Если человек решил уйти с сайта - пофиг ему (в большинстве своем) на ваши вопросы. А ответы меньшинства не дадут объективной картины.
4. Человека, который заходил на сайт можно найти вКонтакте и написать. - Есть такой сервис, называется Intarget. Весьма неплохая штука, для некоторых проектов бывает очень полезной. Ставится счетчик, есть интерфейс, где все понятно. Сам им пользовался и иногда устанавливаю.
5. Чисто гипотетически можно использовать ретаргетинг и ремаркетинг с различными формулировками в объявлении, где в вопросах и текстах будут использоваться варианты "почему" они ушли с сайта. Например - "Не нашли, что искали? Получите скидку, написав нам" или "У нас слишком дорого, напишите нам и снизим цену". Ну русло для направления мысли я задал - дальше уже Ваша фантазия.
Да, вы все правильно пишите, спасибо за конструктив.
Разобрался в общем. В коде ecommerce были внесены коррективы, чтобы данные только с онлайн оплат попадали. В коде этом черт ногу сломает.
Всем спасибо, тему можно закрывать.
Там урЫл, естественно.
"посмотреть" когда платят онлайн, а когда отложено - нет возможности.
И сразу хочу объяснить:
1. Цели, код на сайте, электронная коммерция, веб аналитика и прочие моменты - я и так знаю.
Интересует лишь 1 момент и желательно, если кто-то действительно знает и сталкивался - e-commerce, который настроен через старый способ при помощи jquery - записывает в "заказ" все оформленные заказы через сайт или только оплаченные онлайн?
Других вопросов нет. И настройки, цели, коды - все стоит по стандарту. Проверять "заказы" вручную и получать внутреннюю информацию из 1с нет возможности, поэтому с этого ракурса смотреть не надо.
Гипотез выдвинуть можно мульон, различных вопросиков позадавать - это все трата времени.
Кто-то знает, как стандартный код ecommerce для метрики (старый вариант) считывает инфу или нет? Вот и все.
Теоретики, плз, давайте без флуда.
P.S. уточню - меня интересует не ИМЕННО данный проект, а принцип восприятия информации кодом ecommerce (старая версия) информации при оформлении заказов. Только то, что оплачено "сейчас" или все подряд, что было "отправлено через форму".
Если кто-то знает ПО ФАКТУ и сталкивался НА ПРАКТИКЕ или ИЗУЧАЛ ДАННЫЙ ВОПРОС ДЕТАЛЬНО - буду рад ответу.
Теории и гипотезы - не интересуют, я их могу сам напридумывать.
Закажите аудит.
Без достаточной вводной информации и без цифр - все советы, как вилами на воде.
Вы ecommerce настраивали хоть раз через метрику?
Где данные видно в "параметры интернет магазина".
Там цели стандартно прописываются с привязкой к коду екоммерс, установленного на сайте.
Именно интересует при стандартном установленном коде ecommerce, когда данные передаются через jquery - срабатывает запись только при заказе с онлайн покупкой или же запись срабатывает и через покупку, с отложенным платежом.
Спасибо огромное за конструктивный ответ. А если продолжить:
Код ecommerce идет через jQuery, по старому варианту. Код имеет стандартный вид.
Если код ecommerce имеет стандартный вид, то в коде эта "непередача транзакции" имеется по умолчанию или она появляется только в том случае, если ее дописать дополнительно?
3500 рублей
Этой инфой, к сожалению, не владею, иначе я бы наверное посчитал, как Вы считаете? Если гипотеза такая есть, то, если бы была возможность - уже бы проверил.
Вопрос касается того, в целом, что, может кто-то непосредственно сталкивался с данным нюансом или же знает, каким образом по умолчанию ecommerce считывает информацию (те заявки, которые оплачены онлайн или те, которые просто попадают в корзину и заявка оформляется, вне зависимости от способа оплаты) и как принципиально работает аналитика форм.
