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


Например, в метрике зафиксировано что клиент оформил заказ на сайте, в CRM есть информация что он этот заказ завершил (оплатил и выкупил товар) или отменил.



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

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


Что касается сегмента, то куда проще в Яндекс.Аудитории загрузить оставленные клиентами email/телефон - система сама найдет их в сети.
Или же помучить конверсии: возможно, удастся генерить их в обход, имитирую достижение цели по ClientID уже своими средствами.

> Или же помучить конверсии: возможно, удастся генерить их в обход, имитирую достижение цели по ClientID уже своими средствами.
Как раз в этом-то и проблема, я знаю ClientID и я знаю что он завершил заказ. Как я в метрику могу передать информацию, что заказ, который он сделал в сессии номер 123456, все же завершился успехом?  Я же не могу после того как клиент уже ушел с сайта - в Яндекс.Метрику добавить к его сессии номер 123456 параметр "Заказ успешно выкуплен".

Или даже более полезный пример: Есть составная цель "Оформление заказа" где есть шаги "Корзина - Заполнение заказа - Подтверждение - Заказ оформлен". Далее есть оффлайн события, которые тоже хотелось бы видеть в метрике: "Клиент пришел за заказом в магазин чтобы посмотреть, Клиента товар устроил, он оплатил заказ и выкупил товар".
И далее в метрике строим сегмент "Полностью выкупленные заказы", где смотрим источники, которые дают нам больше выкупленных заказов.

Конверсии - никак.
Только сымитировать фиктивный заход на фиктивную страницу сайта, указав в ней нужный ClientID.


А вот произвольные параметры - уже можно: https://yandex.ru/blog/metrika/parametry-posetiteley

"Только сымитировать фиктивный заход на фиктивную страницу сайта, указав в ней нужный ClientID." - это как раз именно то, что нужно, можете подробнее описать каким образом можно сымитировать такой фиктивный заход?

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

Страничку на сайте сгенерить не проблема, проблема в том, кто будет выполнять на ней JS-код метрики, эмулирующий визит пользователя. Серверные скрипты не очень умеют выполнять JS как браузер, а запускать виртуальный браузер для этой цели как-то уж слишком замудрено. Было бы удобно иметь возможность передавать оффлайн-event через какой-то API. Параметры посетителей для этого не подходят, т.к. они не привязаны к времени ;(

Тогда по фиктивным страничкам придется походить кому-то из сотрудников - главное чтобы сайт их корректно генерировал.

"по фиктивным страничкам придется походить кому-то из сотрудников" - огненный совет )))

Ну еще бы! Кто-то ведь должен :)

передавать через файл и интерфейс сложно?
Или сложно, когда сами коллтрекеры за вас передают данные?

 
да, именно так. Передавать через файл не сложно, но неудобной - это атавизм, ИМХО. Колтрекеры и прочие сервисы - это хорошо, но не все внедрили и не все может устраивать в том как внедряют.
В гугле в этом плане очень удобный универсальный способ передачи единичных конверсий через get-запрос с множеством параметров. У вас же для этого целый скрипт-посредник надо будет писать, чтобы он обращался к метрике и передавал данные. 



Нафига такая сложность?! может я че не понимаю как маркетолог.


Такое ощущение что создавая функционал вы смотрели на программистов, хотя целевая аудитория для данного функционала маркетологи и именно нам надо облегчить жизнь ))) 



Может у вас тех.задание на данный функционал программист писал для программистов, не? ;)


Если бы у вас была возможность передачи единичных конверсий через вебхуки, как это допустимо в google measurement protocol, то конверсии можно было бы передавать куда проще.



Webhook наружу по событию не сложно отправить из многих crm-систем, партнерских CPA программ (там это называется postback) или просто с сайта. Такая возможность есть, странно что вы ее не предусмотрели. И не надо было бы никаких скриптов дополнительных писать, программистов дергать, а потом еще обслуживать этот скрипт, дорабатывать.  

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

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

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

 > - чтобы исключить риск рефспама
Бронебойная защита, конечно, не излишне и риск спама не приувеличили? 



Это не совсем рефспам,  да и как можно этот спам сделать если нужно знать реальный ClientID чтобы запрос был принят системой. А ClientID он почти как пароль - его просто так не узнаешь на чужом сайте..


Вы бы посмотрели как в гугле сделано ))


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



Правильно рассуждаю?


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



В гугле сосуществуют две возможности - отправки через файл и простая отправка через measurement protocol (привет вебхуки и простота интеграций).

мы прекрасно знаем, как это устроено в GA и помним истории про Vote for Trump, например. Или про накрутку конверсий недобросовестными партнерами. Поэтому риск рефспама не преувеличен.

> помним истории про Vote for Trump, например
А как это связано с нашей темой разговора, можно чуть подробней.

> Или про накрутку конверсий недобросовестными партнерами
Какая связь яндекс.метрики и партнеров?  чуть подробней можно

оба примера подтверждают, что Measurement Protocol не защищен от использования в целях навредить владельцу сайта, намеренно (накрутки трафика и/или конверсий) или ненамеренно (массовый спам по счетчикам).
Поэтому мы приняли решение передавать данные по токену, чтобы минимизировать такие риски.

>оба примера подтверждают, что Measurement Protocol не защищен от использования в целях навредить владельцу сайта


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


Совершенно разные вещи. Этот спам не привязан к прошлым визитам других посетитетелей, он гененерит визит сам за себя.



Или я что-то не понимаю и вы пытаетесь съехать с темы. Киньте в меня пруф линком, пжта, где там использование накрутки конверсий?



мы ведь именно об этой части работы метрики и гугла говорим

простой поиск нашел, например, эту статью http://blog.completo.ru/manipulirovanie-dannyimi-v-google-analytics/
Вне зависимости от того, привязан визит к истории посетителя или нет, он влияет на статистику и искажает ее.

>

> простой поиск нашел, например, эту статью
> http://blog.completo.ru/manipulirovanie-dannyimi-v-google-analytics/
> Вне зависимости от того, привязан визит к истории
> посетителя или нет, он влияет на статистику и искажает ее.

От подобной накрутки показателей нерадивыми продвиженцами ни метрика, ни гугл не защищены. В любой реализации, т.к. всегда остается возможность накрутить и конверсии и посещаемость. Ботами или студентами.

Тут вопрос скорее у умении отфильтровать такой траф. Если конверсии накручены намеренно продвиженцами, то ваша реализация тоже не спасет, т.к. у них есть доступы к метрике, как правило, административные и к кодам сайта тоже, с возможностью установить скрипты.

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



К чему весь этот спор?! я правильно понимаю, что вы не хотите услышать пожелание сделать более простую реализацию учета офлайн-конверсий?