Your comments

Чтобы построить отчёт по крайнему (в общем случае по произвольным уровням) уровню и для вк и для фейсбука, так как там содержится информация о конкретных объявлениях(креативах) . Построив отчёт с "креативами" на верхнем уровне будет всё понятно.

Еще нет. Это настроить довольно быстро. Сейчас не сохраняется, потому что нет смысла: ведь в roistat ещё не реализован этот функционал.

Присоединяюсь к автору темы.

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

Пожалуйста не нужно предлагать здесь варианты как узнать номер визита. Номера нет и всё, это "дано".

Задача: объединить данные без номера визита с данными с номером в одну строчку, даже когда используется группировка по параметрам, хранящимся в номере визита, таким как домен, параметры roistat_param, если для сделок без номера визита указаны соответствующие параметры.

Например, есть два сайта site1, site2.

Есть рекламные кампании, например в директе. По три на каждый сайт.

site1: rk1,rk2,rk3

site2: rk4,rk5,rk6

Плюс, кампании сгруппированы по меткам:roistat_param1=groop1 roistat_param1=groop2

site1: rk1+roistat_param1=groop1,rk2+roistat_param1=groop1,rk3+roistat_param1=groop2

site2: rk4+roistat_param1=groop1,rk5+roistat_param1=groop1,rk6+roistat_param1=groop2


Есть несколько сделок с номером визита.

Есть несколько сделок без номера визита, но вся вышеуказанная информация известна.

Задача в том, чтобы эти данные можно было объединить. То есть при группировке по доменам, в строку "Не определено" не попадали сделки, для которых из CRM указан домен. Аналогично по roistat_param.

Также хотелось бы иметь произвольную группировку. Например для канала vk метка имеет три уровня:

rs=vk1_{campaign_id}_{ad_id}

Для facebook 4 уровня:

rs=facebook{ID канала в Roistat}_{ID рекламной кампании}_{ID группы объявлений}_{ID конкретного объявления} 


Хотелось бы иметь возможность в одном отчёте на одном уровне видеть и третий уровень vk и четвертый уровень facebook.

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

Была ситуация с дублированием сделки при повторной отправке формы пользователем через 30 сек из-за задержки загрузки в проект. Сдесь обсуждают дубли в CRM, но оказывается бывают и такие. Ответ поддержки:

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

Плюс номер был указан один раз на 7, другой раз на 8. Поддерживаю, что не нужно учитывать ни +7, ни 7, ни 8 в начале при проверке на дубли. Поспорю с автором темы по поводу маски. Лучше внутри алгоритма оба сравниваемых номера превращать в голые цифры. Придётся помудрить, если есть всякие доп., доб. номера, Но на то они и разработчики.

Интересная тема. В LP Tracker настроена например такая воронка: профиль ВК захвачен, написал в личку, ответил, добавил в CRM.

Сейчас он попадает в аналитику только с крайнего шага воронки из LP Tracker.

Хочется видеть воронку и само собой источники.