Сейчас в сети: 568
Настройка целей, отслеживание электронной торговли, многоканальные последовательности и тд
Подсказки
star_border
Ответить

Вопрос по особенностям ClientID (cid) и Measurement Protocol (MP)

Студент ✭

Коллеги всем привет!

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

 

Основная моя задача для понимания вопросов: настроить точную передачу первых и повторных событий (из бекенда по Measurement Protocol в аналитикс) отложенных оплат от пользователей с точной привязкой к первому источнику привлечения этого пользователя.

 

Вопросы:

 

а) Что если у пользователя нет cid?

В этой статье нашел решение:

 1.jpg 

Правильно ли я понял, что сгенерированный в этом случае в бекенде cid по MP отправится в GA и в отчетах GA будет создан новый пользователь с каналом direct / none ? В GA же еще нет этого пользователя с новосгенерированным cid, в этом случае он просто появится в GA? Существует ли другой метод, по которому можно все же определить источник текущего пользователя, если у него по какой-то причине нет cid?

 

б) Вопрос в примере: у меня есть пользователь, который пришел сначала с канала Яндекс.Директ и совершил первую покупку (данные о первой покупке я передал в GA по cid пользователя через MP). Когда этот же пользователь купит повторно, при этом, придет уже с другого канала (скажем, Facebook ads или прямой заход), то как будет передано повторное событие оплаты? cid один и тот же, а каналы разные, в какой канал уйдет сессия с новой конверсией и ее ценность? Насколько я понимаю, канал каждый раз перезаписывается, но могу ошибаться.

 

в) Если мне нужно, чтобы событие оплаты отправлялось с привязкой к первому каналу (с которого совершалась первая оплата), то при передаче события оплаты через MP нужно ли мне принудительно указать "источник/канал"? (см справку)

 

г) В той же самой статье увидел это:

2.jpg

Что понимается под "не инициализировать новую сессию"? Как тогда зафиксируется событие в GA? Или же все-таки новая сессия инициируется, но с параметрами ее первого источника (т.е. тогда это получается альтернативный способ решения задачи привязки пользователя к его первому источнику - см. вопрос "в"). Может я вообще не понял смысла этого параметра ni и он несет другую функцию (какую?)

 

д) Есть одна задача: у меня есть клиенты, у которых в админке нету cid (не писался ранее). Сейчас я получаю в GA события из бекенда с дефолтным всегда одинаковым cid. Следовательно, группа клиентов, генерирует мне по одному и тому же cid в канал direct / none - платежи и выручку. Я хочу первое - их разделить на разных клиентов (тут, судя по всему, поможет решение в п. "а" моего поста). Второе - все-таки присвоить им канал (по некоторым клиентам я могу его выяснить) и отправлять принудительно с нужным каналом, который я знаю что их источник (тут потребуется для начала разобраться в п. "в" и "г" этого вопроса). Как мне навести тут порядок, хелп?

 

е) Для отслеживания событий передаваемых через MP, какой уровень при заведении спец. параметра ClientID следует использовать: хит, сеанс, пользователь?

 

ё) Возможно, у Вас есть мысли и советы, которые хотите добавить, которые помогут мне настроить точную передачу первых и повторных событий оплат от пользователя с точной привязкой к источнику привлечения этого пользователя?

1 Ответ экспертаverified_user

Re: Вопрос по особенностям ClientID (cid) и Measurement Protocol (MP)

Ведущий участник

 

а) Именно так. Новый пользователь с прямым заходом.
Если не передавать принудительно источники трафика.

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

в) смотрите выше


г) ni-  работает только с событиями. Аналитикс, не просто бд для архива. Отправка данных в него, инициализруют сессию.

д) если слать - в аналитикс будет выглядеть , как один человек много чего купил.


е) Вам в принципе надо разобраться с областью действия. В частном случае для события, хит, сеанс.


ё) прочитайте справку по MP и Аналитикс. Если вы ее прочтете отпадет 99% вопросов, и Вы поймете, что MP не сам по себе, не какое то отдельное "изобретение". А единый протокол для Analytics Universal, по нему работает и js код установленный на сайте.  

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


 

C уважением,
Павел

Вопрос по особенностям ClientID (cid) и Measurement Protocol (MP)

Студент ✭

Павел, спасибо за пояснения, но все же мне не все понятно, сейчас попробую уточнить вопросы:

 

а) -

б) т.е., верно я понял, что по умолчанию новое событие, переданное в GA по MP создает новый источник для новой сессии (если его не передавать принудительно)? Т.е. данные об источнике лучше передавать принудительно, если я хочу привязаться к первому каналу привлечения?

в) -

г) вот тут не понял вообще. Для сего это решение нужно в принципе? (у меня противоречие: с одной стороны на скриншоте написано, что новая сессия не создается, с другой - как она может не создаваться?). Видимо я не понял практическое применение этого момента, поясните пжлст.

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

е) В моем случае, где мне нужно отслеживать первые и повторные покупки пользователей, верно я понимаю, что уровень "пользователь" - это то, что нужно?

ё) спс!)

Вопрос по особенностям ClientID (cid) и Measurement Protocol (MP)

Ведущий участник

Давайте по другому.
Обращение без CID -гугл не примет.
рассмотрим 4 варианта
а) Отправляете с реальным cid просто событие.
данные приклеятся к последней сессии. И к тому источнику что был.


б) Вы отправляете с придуманным cid, аналитикс на своих складах данных не найдет этот cid, не с чем склеивать. Событие запишется с direct / none


в) отправляете реальный cid + в ручную задаете источники
запишется новый источник


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

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

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

C уважением,
Павел

Re: Вопрос по особенностям ClientID (cid) и Measurement Protocol (MP)

Студент ✭

Таак, теперь понятнее, спасибо)

 

Но еще уточнения:

1. В варианте г) - "Есть одно но, сессии могут не склеиваться." - как это понять? Что значит "склеивание сессии" в данном случае? Сессия ведь генерируется каждый раз новая.

2. По поводу ni так и не понятно. Верно я понимаю, что для отправки именно событий первых и повторных оплат (для целей) мне не нужно его прописывать?  И, честно говоря, я так и не понял его практическое применение, т.е. чтобы что!?)

3. Задавая вопрос "верно я понимаю, что уровень "пользователь" - это то, что нужно?", я имел ввиду это:

3.jpg

Вопрос по особенностям ClientID (cid) и Measurement Protocol (MP)

Студент ✭

Павел, приветствую!

 

Верно я понимаю, что для того, чтобы присваивать нужный источник для сессии с оплатой (в данном случае, меня интересует превый), у меня есть 2 варианта:
1. Записать источник вручную (создать спец. поля в бекенде и записать туда в случае, когда я знаю источник. Это решит проблему с теми клиентами, у которых ранее не было cid - я его сгенерировал автоматически, я знаю первый источник этого клиента, пишу его руками и отправляю в GA). Это разовая ручная работа, которая поправит ситуацию с теми клиентами, которые сейчас платят, но я не вижу их реальный канал, хотя его знаю.

 

2. Для всех клиентов, у кого есть cid, я должен записать все его посещения в бекенд (т.е. создаю базу данных посещений с источниками) и когда пришла пора отправлять событие оплаты, я должен оратиться к этому списку посещений, а именно к первому источнику и передать его по MP. Это уже автоматически.

 

Отдельно:

Вы говорите один из вариантов: "отправляете придуманный cid + в ручную задаете источники, запишется новый источник. Есть одно но, сессии могут не склеиваться."

Вопрос: Что значит "склеивание сессии" в данном случае? Сессия ведь генерируется каждый раз новая.