Снова про MP

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

Например, пользователь пришле из yandex / cpc, сделал заказ. Ему позвонил на след. день менеджер и изменил статус заказа. Пользователь, например, вернулся по ретаргетингу по google / cpc или другим способом на сайт на след. день. Еще через день менеджер опять позвонил и заказ по каким-то причинам отменился. в GA уйдет транзакция и запишеться на google / cpc.
на всякий для всех написал, так как это очень частотный вопрос.
Если кто знает придумает другой способ, с удовольствием узнаю (видел порядка 5-7 архитектур и способов все не работающие, в том числе склеивание через Import Data protocol, но с удовольствием узнаю, если я что-то не учитываю или появился новый способ)

Гугл делает сервис аналитики для Adwords, Googl Analytics не создавался как инструмент бизнес или продуктовой аналитики
Он ничего не знает про юнит-экономику, ARPU, ARPPU, все еще работает в основном по сессиям (хотя API 4 года как переводят на user-base аналитику и последние новости в блоге радуют). GA — в первую очередь API first разработку делают и они ок работать с доп. сервисами — Гуглу это выгодно иначе пользователи передут на другие user base системы аналитики и гугл потеряет возможность использовать данные для анализа что люди ищут и для продажи Adwords
Вместе с тем GA действительно улучшается, просто очень медлено.
edited
Сложного в MP полно, объясните разработчикам (хотя это есть в справке), почему при отправке eventAction с не целым eventValue (например 2.0 — число почти целое, но просто разработчик тип не проверил) в ответ на post запрос вы получите 200 ОК, но событие не будет записана
объясните что питон библиотеки, которые разработчики правильно берут с гитхаба для работы с MP часто записывают свой user-agent и по этой причине легко увидеть в GA что транзакции были отправлены с браузера или устройства: Python
Объясните чем “” отличается от (not set), и почему если использовать Core API вы выгружаете данные с запросом с dimension=ga:sourceMedium, ga:campaign, ga:keyword — вы получите меньше строчек чем через dimension=ga:sourceMedium, ga:campaign — потому что пустые “” keyword не передадуться в отличие от (not set)
ну и реально еще 50 таких примеров, могу в личке рассказать.
А еще попробуйте своими силами передавать транзакции, которые в CRM были получены через jivosite, calltracking и т.д. да еще правильно положив их в GA — практика показывает, что у 90 из 100 компаний это не получается или стоит очень дорого
и нафиг ломается и падает точность статистики, если кто-то из маркетологов забыл и выложил лендинг с неверно поставленным счетчиком через ga_clientID

Или поставил счетчик через GTM (еще недавно там погрешность была 10-15% при записи ga_clientID — теперь с помощью custom Task можно ставить счетчик через GTM почти без погрешности)

Мера новых клиентов в DAX

новый клиент = COUNTROWS(
 FILTER(VALUES(mysql_transactions_facts[userPhone]); 
 CALCULATE(DISTINCTCOUNT(mysql_transactions_facts[orderId]); 
 FILTER(ALL('calendar'); 
 'calendar'[Date]<MAX('calendar'[Date])
 )
 )>1 &&
 CALCULATE(COUNTROWS('mysql_transactions_facts'))=1
 )
 )

или так

COUNTROWS (
 FILTER (
 ADDCOLUMNS (
 VALUES ( mysql_transactions_facts[userPhone] ),
 "PreviousSales", CALCULATE (
 COUNTROWS ( mysql_transactions_facts),
 FILTER (
 ALL ( 'calendar' ),
 'calendar'[Date]< MIN ( 'calendar'[Date] )
 )
 )
 ),
 [PreviousSales] = 0
 )
)

а вот так вернувшийся клиент:

COUNTROWS (
 CALCULATETABLE (
 VALUES ( mysql_transactions_facts[userPhone] ),
 VALUES ( mysql_transactions_facts[userPhone]),
 FILTER (
 ALL ( 'calendar' ),
 'calendar'[Date]< MIN ( 'calendar'[Date] )
 )
 )
)