Комментарии 16
Добрый день.
Тестирую. Есть вопросы:
1. А можно ли как-то во что-нибудь заворачивать передаваемые данные? А то ведь они так открытым текстом и светятся:
2. В «воронке» считаются «отказами» те, кто перед уходом посмотрел целую кучу товаров. Но вроде как в отказные принято записывать только закрывших страницу в первые Х секунд… Иначе ерунда получается.
Тестирую. Есть вопросы:
1. А можно ли как-то во что-нибудь заворачивать передаваемые данные? А то ведь они так открытым текстом и светятся:
visitor_uid: '000000',
visitor_info: {
first_name: 'Вася',
last_name: 'ПУПКИН',
email: 'vasia@pupkin.com',
},
app_key: '1234567891234567899876543210'
2. В «воронке» считаются «отказами» те, кто перед уходом посмотрел целую кучу товаров. Но вроде как в отказные принято записывать только закрывших страницу в первые Х секунд… Иначе ерунда получается.
1. Как-то замаскировать данные в JS не получится, но я, если честно, не совсем понимаю смысл этого мероприятия, ведь они «светятся» только для их владельца, сервер же генерирует вам персонализированный кусок JS-а. Думаете Вася Пупкин не знает, что он Вася Пупкин с таким-то емейлом? :)
Если, не смотря на выше сказанное, вы все-таки не хотите передавать данные через JS, то можете делать это с бекэнда, для этого у нас есть полнофункциональная библиотека на Ruby с Readme и примерами, а также чуть хуже документированная библиотека на PHP. С помощью этих библиотек вы вообще можете интегрировать ваш магазин с Convead практически без JS-а, передавая все данные с бекенда.
2. Вы говорите про понятие «Отказ» в привычных терминах веб-аналитики (Яндекс.Метрика или Google Analytics) — там действительно «отказами» считаются закрытия страницы без переходов. Convead же оперирует терминами жизненного цикла клиента в интернет-магазине. С точки зрения воронки продаж вашего бизнеса «отказной» клиент — это тот, что не проявил интереса к товарам (не добавлял их в корзину и не покупал).
Если, не смотря на выше сказанное, вы все-таки не хотите передавать данные через JS, то можете делать это с бекэнда, для этого у нас есть полнофункциональная библиотека на Ruby с Readme и примерами, а также чуть хуже документированная библиотека на PHP. С помощью этих библиотек вы вообще можете интегрировать ваш магазин с Convead практически без JS-а, передавая все данные с бекенда.
2. Вы говорите про понятие «Отказ» в привычных терминах веб-аналитики (Яндекс.Метрика или Google Analytics) — там действительно «отказами» считаются закрытия страницы без переходов. Convead же оперирует терминами жизненного цикла клиента в интернет-магазине. С точки зрения воронки продаж вашего бизнеса «отказной» клиент — это тот, что не проявил интереса к товарам (не добавлял их в корзину и не покупал).
Вася увидит открытый текст и будет кричать про безопасность :)
И потом уже эта $auth передается JSом.
Но это конечно не основное.
2 — все так, но тогда «отказников» будет настолько много, что никакой полезной информации из этого показателя не вытащить: там все смешалось в кучу.
И главное: тогда какая разница между «смотрели», «не заинтересовались» и «отказ», если во всех этих группах они посмотрели кучу товаров?
И еще более интересная подробность выяснилась: на тысячу заходов нет ни одного «по рекламе». Это абсолютно точно не так, основной трафик идет из Директа, это я знаю точно. Счетчик показывает половину «прямых», половину «поиска». СТОЛЬКО прямых быть не может, это тоже известно.
Это пока что интереснее всего.
$json = '.......' //тут данные юзера
$secret = ''; // Секретный ключ,
$user_base64 = base64_encode( json_encode($json) );
$sign = md5($secret . $user_base64 . $time);
$auth = $user_base64 . "_" . $time . "_" . $sign;
И потом уже эта $auth передается JSом.
Но это конечно не основное.
2 — все так, но тогда «отказников» будет настолько много, что никакой полезной информации из этого показателя не вытащить: там все смешалось в кучу.
И главное: тогда какая разница между «смотрели», «не заинтересовались» и «отказ», если во всех этих группах они посмотрели кучу товаров?
И еще более интересная подробность выяснилась: на тысячу заходов нет ни одного «по рекламе». Это абсолютно точно не так, основной трафик идет из Директа, это я знаю точно. Счетчик показывает половину «прямых», половину «поиска». СТОЛЬКО прямых быть не может, это тоже известно.
Это пока что интереснее всего.
Вася увидит открытый текст и будет кричать про безопасность :)
Мы, конечно, думали о шифровании, но решили не заморачиваться с этим по целому ряду причин. Если интересно — перечислю их отдельно.
тогда какая разница между «смотрели», «не заинтересовались» и «отказ», если во всех этих группах они посмотрели кучу товаров?
Я ввел вас в заблуждение своим предыдущим комментарием, поторопился. На самом деле обстоит так:
- Покинули сайт (отказы) — это те, кто не посмотрел ни одного товара.
- Смотрели товары — это те, кто посмотрел хотя бы один товар за визит.
- Не заинтересовались — это те, кто посмотрел хотя бы один товар за визит, однако не прошел дальше по бизнес-процессу (ничего не купил и не положил в корзину).
Важно: под «Смотрели товары», «Положили в корзину» и пр. понимается наличие соответствующих эвентов ViewProduct, AddToCart и т.п., которые должны корректно передаваться с вашего сайта.
И еще более интересная подробность выяснилась: на тысячу заходов нет ни одного «по рекламе».
Напишите пожалуйста мне в ЛС id вашего аккаунта или домен, я посмотрю изнутри, что там насчет источников визитов.
Нет, б-г с ним, шифрованием. Не главное.
Вот сейчас пробежался по «отказным» — они все посмотрели как минимум один товар. Видел тех, кто посмотрел пару десятков товаров.
Эвенты тестировал на тестовом :) клиенте, вроде как все отлавливается корректно. Может чего пропустил конечно…
Вот сейчас пробежался по «отказным» — они все посмотрели как минимум один товар. Видел тех, кто посмотрел пару десятков товаров.
Эвенты тестировал на тестовом :) клиенте, вроде как все отлавливается корректно. Может чего пропустил конечно…
Посмотрел ваш магазин и аккаунт изнутри. Тут имеет место ряд проблем:
На самом деле эвент «Просмотр товара» ваш магазин не присылает. В инструкции по настройке написано, что он должен вызываться после основного кода Convead, а он у вас стоит на странице выше кода. В консоли JS есть ошибка об этом: «ReferenceError: convead is not defined».
Кстати, вообще обратите внимание на ошибки JS на странице товара, там у вас есть синтаксическая ошибка выше по коду в var displayPrice = ; — из-за нее потенциально тоже могут быть разные проблемы.
Если ставить код эвента 'view_product' после основного кода неудобно — просто заверните его в DOM.ready():
Здесь есть определенная терминологическая проблема. Вы настроили ключевую страницу «Product», но Convead не считает это просмотром товара, т.к. для него «просмотр товара» — это именно эвент «view_product», про который я написал выше. Звучит довольно бредово, согласен, но здесь проблема в том, что мы находимся в стадии активного развития, проверяем различные гипотезы и часто изменяем поведение системы и в результате можем просто забыть о чем-то важном или считать это само собой разумеющимся.
Так, изначально мы придерживались идеи настройки системы без необходимости добавлять какие-либо куски JS на сайт, кроме основного кода. Мы думали, что достаточно проассоциировать какую-либо страницу на сайте с тем или иным этапом воронки продаж и все заработает. Так появился механизм «Ключевых страниц» и их типы («Product», «Cart», «Purchase» и т.п.). Идея была в том, чтобы просто настроить паттерны для этих ключевых страниц и ваши посетители будут распределяться по воронке. Однако со временем мы поняли, что не все так просто… У кого-то роуты сайта постоены на использовании GET-параметров, у кого-то — нет. У кого-то нет отдельной страницы чекаута или совершения заказа и т.д. Все это конечно можно было бы решить через настройку аккаунта, но когда мы прикинули, сколько галочек и полей нужно будет заполнить пользователю, то отказались от этой идеи и перешли от системы ключевых страниц к системе эвентов. Эвенты, кроме всего прочего, открыли также возможность учитывать такие важные для интернет-магазина события, как «положил товар в корзину» и некоторые другие. В настоящее время мы поддерживаем около десятка различных эвентов, в т.ч. и кастомные, которые удобно ставить на всякие кнопочки на сайте и затем сегментировать своих пользователей по этим эвентам.
А ключевые страницы мы решили оставить, поскольку бывает необходимость в том, чтобы отслеживать посещение именно определенной страницы. Кроме того, только посещения ключевых страниц сохраняются навсегда в таймлайне посетителя. Вот что действительно следовало бы сделать, так это убрать типы ключевых страниц, потому что именно они вас и смутили, за это прошу прощения :)
В общем, если вы отладите JS на страницах товаров, то Convead начнет учитывать просмотры товаров в воронке продаж.
При определении источника визита Convead в первую очередь ориентируется на заголовок HTTP referer. Мы разбираем его на части и пытаемся понять, на что он похож, и к какому источнику его можно отнести. Так же должен определяться и Яндекс.Директ. Я просмотрел выборочно порядка сотни ваших посетителей, но среди них не обнаружил ни одного с реферером из директа. Может быть вы точно знаете, что кто-то пришел из директа и сможете прислать мне ссылку на него?
Есть еще такое предположение: у вас много прямых заходов (с пустым referer), это может например говорить о том, что переход осуществлен из https:// на http://, в этом случае как раз реферер будет пустым. Последние новости из мира SEO говорят, что поисковики активно экспериментируют с шифрованием всего трафика, так что такая ситуация с переходом из поиска по рекламе теоретически может быть. Правда, обычно они используют промежуточный редиректер, который как раз редиректит с http:// на http://, но все же прецеденты появления пользователей с пустыми реферерами из поиска и рекламы уже были.
Лайфхак: если Convead не сможет определить источник по рефереру, то он попробует поискать в текущем URL вашего сайта параметр utm_source. Если найдет его — то он запишет визит в источник «Реклама» независимо от реферера. Так что просто добавьте ко всем вашим ссылкам в объявлениях что-то типа "...?utm_source=yandex_direct" и все будет считаться правильно. Эта рекомендация, кстати, пригодится при любом анализе трафика, не только в Convead.
Вообще хочу поблагодарить вас за фидбек, нам этого очень не хватает! Мы знаем свой проект слишком хорошо, чтобы объективно оценить удобство его использования и настройки, а также пользу от внедрения. Поэтому такая обратная связь от живых людей и настоящих магазинов бесценна, это открывает глаза и позволяет взглянуть по-новому на то, что мы считали не столь уж важным (хороший пример в ключевыми страницами, которые только путают). Еще раз спасибо :) Я доступен для любых вопросов.
Вот сейчас пробежался по «отказным» — они все посмотрели как минимум один товар.
На самом деле эвент «Просмотр товара» ваш магазин не присылает. В инструкции по настройке написано, что он должен вызываться после основного кода Convead, а он у вас стоит на странице выше кода. В консоли JS есть ошибка об этом: «ReferenceError: convead is not defined».
Кстати, вообще обратите внимание на ошибки JS на странице товара, там у вас есть синтаксическая ошибка выше по коду в var displayPrice = ; — из-за нее потенциально тоже могут быть разные проблемы.
Если ставить код эвента 'view_product' после основного кода неудобно — просто заверните его в DOM.ready():
$(document).ready(function() {
convead('event', 'view_product', {
product_id: '1239',
product_name: 'Чехол Oxford, 229х125х99',
product_url: 'http://motokofr.com/product.php?id_product=1239'
});
Видел тех, кто посмотрел пару десятков товаров.
Здесь есть определенная терминологическая проблема. Вы настроили ключевую страницу «Product», но Convead не считает это просмотром товара, т.к. для него «просмотр товара» — это именно эвент «view_product», про который я написал выше. Звучит довольно бредово, согласен, но здесь проблема в том, что мы находимся в стадии активного развития, проверяем различные гипотезы и часто изменяем поведение системы и в результате можем просто забыть о чем-то важном или считать это само собой разумеющимся.
Так, изначально мы придерживались идеи настройки системы без необходимости добавлять какие-либо куски JS на сайт, кроме основного кода. Мы думали, что достаточно проассоциировать какую-либо страницу на сайте с тем или иным этапом воронки продаж и все заработает. Так появился механизм «Ключевых страниц» и их типы («Product», «Cart», «Purchase» и т.п.). Идея была в том, чтобы просто настроить паттерны для этих ключевых страниц и ваши посетители будут распределяться по воронке. Однако со временем мы поняли, что не все так просто… У кого-то роуты сайта постоены на использовании GET-параметров, у кого-то — нет. У кого-то нет отдельной страницы чекаута или совершения заказа и т.д. Все это конечно можно было бы решить через настройку аккаунта, но когда мы прикинули, сколько галочек и полей нужно будет заполнить пользователю, то отказались от этой идеи и перешли от системы ключевых страниц к системе эвентов. Эвенты, кроме всего прочего, открыли также возможность учитывать такие важные для интернет-магазина события, как «положил товар в корзину» и некоторые другие. В настоящее время мы поддерживаем около десятка различных эвентов, в т.ч. и кастомные, которые удобно ставить на всякие кнопочки на сайте и затем сегментировать своих пользователей по этим эвентам.
А ключевые страницы мы решили оставить, поскольку бывает необходимость в том, чтобы отслеживать посещение именно определенной страницы. Кроме того, только посещения ключевых страниц сохраняются навсегда в таймлайне посетителя. Вот что действительно следовало бы сделать, так это убрать типы ключевых страниц, потому что именно они вас и смутили, за это прошу прощения :)
В общем, если вы отладите JS на страницах товаров, то Convead начнет учитывать просмотры товаров в воронке продаж.
И еще более интересная подробность выяснилась: на тысячу заходов нет ни одного «по рекламе». Это абсолютно точно не так, основной трафик идет из Директа, это я знаю точно. Счетчик показывает половину «прямых», половину «поиска». СТОЛЬКО прямых быть не может, это тоже известно.
При определении источника визита Convead в первую очередь ориентируется на заголовок HTTP referer. Мы разбираем его на части и пытаемся понять, на что он похож, и к какому источнику его можно отнести. Так же должен определяться и Яндекс.Директ. Я просмотрел выборочно порядка сотни ваших посетителей, но среди них не обнаружил ни одного с реферером из директа. Может быть вы точно знаете, что кто-то пришел из директа и сможете прислать мне ссылку на него?
Есть еще такое предположение: у вас много прямых заходов (с пустым referer), это может например говорить о том, что переход осуществлен из https:// на http://, в этом случае как раз реферер будет пустым. Последние новости из мира SEO говорят, что поисковики активно экспериментируют с шифрованием всего трафика, так что такая ситуация с переходом из поиска по рекламе теоретически может быть. Правда, обычно они используют промежуточный редиректер, который как раз редиректит с http:// на http://, но все же прецеденты появления пользователей с пустыми реферерами из поиска и рекламы уже были.
Лайфхак: если Convead не сможет определить источник по рефереру, то он попробует поискать в текущем URL вашего сайта параметр utm_source. Если найдет его — то он запишет визит в источник «Реклама» независимо от реферера. Так что просто добавьте ко всем вашим ссылкам в объявлениях что-то типа "...?utm_source=yandex_direct" и все будет считаться правильно. Эта рекомендация, кстати, пригодится при любом анализе трафика, не только в Convead.
Вообще хочу поблагодарить вас за фидбек, нам этого очень не хватает! Мы знаем свой проект слишком хорошо, чтобы объективно оценить удобство его использования и настройки, а также пользу от внедрения. Поэтому такая обратная связь от живых людей и настоящих магазинов бесценна, это открывает глаза и позволяет взглянуть по-новому на то, что мы считали не столь уж важным (хороший пример в ключевыми страницами, которые только путают). Еще раз спасибо :) Я доступен для любых вопросов.
Продлил вам триал до 15 января, спасибо, что не поленились отписать фидбек!
Добрый день
Любопытненько… значит «Ключевые стр» рекомендуете убить, дабы не вводили в заблуждение?
view_product завернул в ready, спасибо за наводку. Грузить сторонние скрипты из хедера не могу, сорри. Кстати виджет не обидится, если я его defer?
displayPrice это не цена — да, вот так придумал разработчик, ее значение к цене товара отношения не имеет. Изначально это место выглядит как var displayPrice = {$priceDisplay}, то есть если у данного товара в темплейт не передана $priceDisplay, то уже ничего не поделать.
Директ добавляет ?yclid= ко всем объявлениям, если в установках кампании это разрешено. Можно отловить заход оттуда по наличию этого агрумента. Как добавить кастомный агрумент в настройках Директа не нашел — возможно нужно отредактировать ВСЕ ссылки… ох :)
Для теста — только что сделал motokofr.com/product.php?id_product=3142&yclid=5813559884561105753, в заходах «по рекламе» пока не отобразилось.
Спасибо.
Любопытненько… значит «Ключевые стр» рекомендуете убить, дабы не вводили в заблуждение?
view_product завернул в ready, спасибо за наводку. Грузить сторонние скрипты из хедера не могу, сорри. Кстати виджет не обидится, если я его defer?
displayPrice это не цена — да, вот так придумал разработчик, ее значение к цене товара отношения не имеет. Изначально это место выглядит как var displayPrice = {$priceDisplay}, то есть если у данного товара в темплейт не передана $priceDisplay, то уже ничего не поделать.
Директ добавляет ?yclid= ко всем объявлениям, если в установках кампании это разрешено. Можно отловить заход оттуда по наличию этого агрумента. Как добавить кастомный агрумент в настройках Директа не нашел — возможно нужно отредактировать ВСЕ ссылки… ох :)
Для теста — только что сделал motokofr.com/product.php?id_product=3142&yclid=5813559884561105753, в заходах «по рекламе» пока не отобразилось.
Спасибо.
значит «Ключевые стр» рекомендуете убить, дабы не вводили в заблуждение?
Все не обязательно, но «Product» при нормально работающих эвентах точно не нужна, т.к. они фактически дублируют друг друга. К слову, завтра мы планируем релиз, где просто уберем понятие «тип» у ключевых страниц, чтобы они больше никого не смущали.
Кстати виджет не обидится, если я его defer?
Не тестировали, если честно. Но я бы не рекомендовал этого делать по тем же причинам, по которой GA и Метрика рекомендуют вставлять свои скрипты именно в head: так меньше вероятность того, что что-то не сработает из-за ошибок на странице или если пользователь быстро закроет вкладку. Ну и сам код асинхронный и не должен что-то сильно тормозить (это стандартная отмазка GA и Метрики :)).
Директ добавляет ?yclid= ко всем объявлениям, если в установках кампании это разрешено. Можно отловить заход оттуда по наличию этого агрумента. Как добавить кастомный агрумент в настройках Директа не нашел — возможно нужно отредактировать ВСЕ ссылки…
Огромное спасибо за наводку, вот про yclid-то мы и забыли! В завтрашнем релизе это тоже учтем (тогда не нужно добавлять ничего руками в ссылки).
Дальнейшее обсуждение предлагаю перенести в приват, т.к. оно уже становится слишком частным. Спасибо!
Добрый день
Продолжаем тест.
Выделяем тестового юзера (по email) в отдельный сегмент. Назначаем тестовую рассылку в этот сегмент.
Видимо из-за того, что этот юзер засветился в 26 сессиях, тестовое письмо пришло ему 26 раз…
Продолжаем тест.
Выделяем тестового юзера (по email) в отдельный сегмент. Назначаем тестовую рассылку в этот сегмент.
Видимо из-за того, что этот юзер засветился в 26 сессиях, тестовое письмо пришло ему 26 раз…
Посмотрел, ваша рассылка ушла не 26 раз одному человеку, а 26 разным людям с одинаковым емейлом (это видно, если посмотреть на id-шники визиторов). Видимо, когда вы тестировали, вы как-то передали 26 раз один и тот же емейл для разных визиторов. Convead специально не склеивает визиторов по емейлу, потому что это не всегда правильно. А вот что делать с одинаковыми емейлами у разных юзеров в рассылках мы пока думаем (в т.ч. поэтому рассылки еще в beta). Ну, видимо, исходя из вашего фидбека, надо все-таки склеивать их при отправке :)
Давайте посмотрим на вопрос с другой стороны.
Мне кажется, отсылка более одного — в рамках одной рассылки — письма одному и тому же емейлу есть однозначный и безусловный косяк. Юзер не виноват, что кто-то где-то считает Карла Маркса и Фридриха Энгельса четырьмя разными людьми :) и скорее всего не хочет получать даже одно письмо, а тут на его голову сваливается вот такое счастье.
Например, юзер в процессе «жизни» может назваться разными именами: при регистрации он написал Лёха, а как дело дошло до отправки посылки по почте, пришлось переназываться Алексеем. Иначе получится как у Печкина: посылка-то пришла, «но я тебе ее не отдам» :) Что делать? Считать Лёху и Алексея двумя разными людьми?
Вообще, тут необходимо понимать, как движок сайта (ИМ) присваивает user_id:
Например, мы не раз видели вот такую надпись: «Здравствуйте Вася Пупкин! Войдите: вход (Вы не Вася?)».
Это движок сайта подцепил свою куку, но на всякий случай предлагает юзеру ввести пароль. Вот в этом случае к вам уйдет email якобы другого юзера, но вместо customer_id уйдет «гостевой» visitor_id.
Предполагаю, мы столкнулись именно с этим случаем и Convead решил, что visitor_id «главнее» email. И как мне кажется такие случаи (а их будет много, т.к. многие движки имеют подобный механизм) нужно абсолютно четко отсекать.
Мне кажется, отсылка более одного — в рамках одной рассылки — письма одному и тому же емейлу есть однозначный и безусловный косяк. Юзер не виноват, что кто-то где-то считает Карла Маркса и Фридриха Энгельса четырьмя разными людьми :) и скорее всего не хочет получать даже одно письмо, а тут на его голову сваливается вот такое счастье.
Например, юзер в процессе «жизни» может назваться разными именами: при регистрации он написал Лёха, а как дело дошло до отправки посылки по почте, пришлось переназываться Алексеем. Иначе получится как у Печкина: посылка-то пришла, «но я тебе ее не отдам» :) Что делать? Считать Лёху и Алексея двумя разными людьми?
Вообще, тут необходимо понимать, как движок сайта (ИМ) присваивает user_id:
- незарегистренный юзер имеет рандомный «гостевой» visitor_id
- зарегистренный имеет постоянный customer_id
- зарегистренный, но не залогиненный юзер имеет «гостевой» visitor_id, но т.к. ранее движок ИМ подложил ему куку, то из этой куки подтягивается его емейл и имя.
Например, мы не раз видели вот такую надпись: «Здравствуйте Вася Пупкин! Войдите: вход (Вы не Вася?)».
Это движок сайта подцепил свою куку, но на всякий случай предлагает юзеру ввести пароль. Вот в этом случае к вам уйдет email якобы другого юзера, но вместо customer_id уйдет «гостевой» visitor_id.
Предполагаю, мы столкнулись именно с этим случаем и Convead решил, что visitor_id «главнее» email. И как мне кажется такие случаи (а их будет много, т.к. многие движки имеют подобный механизм) нужно абсолютно четко отсекать.
Мне кажется, отсылка более одного — в рамках одной рассылки — письма одному и тому же емейлу есть однозначный и безусловный косяк. Юзер не виноват, что кто-то где-то считает Карла Маркса и Фридриха Энгельса четырьмя разными людьми :) и скорее всего не хочет получать даже одно письмо, а тут на его голову сваливается вот такое счастье.Вы правы, один и тот же емейл не должен получать несколько одинаковых писем, это мы решим в ближайшее время.
Предполагаю, мы столкнулись именно с этим случаем и Convead решил, что visitor_id «главнее» email. И как мне кажется такие случаи (а их будет много, т.к. многие движки имеют подобный механизм) нужно абсолютно четко отсекать.Если в случае с рассылками все достаточно однозначно, то вот здесь мы пока не пришли к единому мнению. Дело в том, что ряд сайтов (в т.ч. среди наших клиентов) по каким-то причинам используют фейковые емейлы, которые вполне могут быть и не уникальными. Мы долго думали, стоит ли рассматривать такие граничные случаи, но сейчас уже наверное склоняемся к тому, что не стоит, и что действительно визиторов нужно «склеивать» по емейлу, т.к. в подавляющем большинстве случаев это будет правильным. Сделаем это в ближайшее время, спасибо за фидбек!
Добрый день. Спасибо за плюсики, к сожелению не могу ответить взаимностью — слишком молод ;)
Мне кажется, что отношение к фейковым емейлам должно быть как к фейку… а разве может быть по-другому?
Я задавал вопрос в местную чатилку, но он куда-то провалился, поэтому продублирую.
Настраиваем виджет «Нужна помощь?».
Задача простейшая: расположить на нем кнопку вызова чата с оператором.
Проблема: невозможно подвесить на эту кнопку onclick.
Или я плохо смотрел? Буду благодарен за пинок в нужном направлении.
Мне кажется, что отношение к фейковым емейлам должно быть как к фейку… а разве может быть по-другому?
Я задавал вопрос в местную чатилку, но он куда-то провалился, поэтому продублирую.
Настраиваем виджет «Нужна помощь?».
Задача простейшая: расположить на нем кнопку вызова чата с оператором.
Проблема: невозможно подвесить на эту кнопку onclick.
Или я плохо смотрел? Буду благодарен за пинок в нужном направлении.
Настраиваем виджет «Нужна помощь?».Смотрели хорошо, действительно beta-версия виджетов этого не умеет. Но функция интересная и, безусловно, нужная. Записали это в roadmap :)
Задача простейшая: расположить на нем кнопку вызова чата с оператором.
Проблема: невозможно подвесить на эту кнопку onclick.
Или я плохо смотрел? Буду благодарен за пинок в нужном направлении.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как увеличить продажи в интернет-магазине с помощью сегментирования листов email-рассылок