IAB Tech Lab: дорожная карта стандартов для attribution без стабильных ID
Если собираете server-side измерение и думаете не только про Meta CAPI/Enhanced Conversions, стоит следить за IAB Tech Lab. По их ленте видно, куда двигается слой стандартов вокруг privacy-preserving attribution.
Что уже вышло:
— 27 июня 2024: финальные результаты fit analysis Google Privacy Sandbox для Protected Audiences auctions.
— 22 октября 2024: запуск Ad Format Hero — инициатива по стандартизации emerging Connected TV ad formats.
— 25 февраля 2025: первый релиз Attribution Data Mapping Protocol, ADMaP. Формулировка IAB: стандарт использует advanced cryptographic techniques для measurement with privacy guarantees.
— 18 марта 2025: финальные версии ACIF и спецификации ACIF Validation API готовы к implementation.
— 17 июля 2025: финальное руководство ID-Less Solutions — сравнение ID Solutions и ID-Less Solutions.
Что это значит для performance:
1. Атрибуция уходит от “передадим больше идентификаторов” к формальным протоколам и privacy guarantees.
2. Server-side слой должен быть готов не только к CAPI/Events API, но и к маппингу attribution data между системами.
3. ACIF Validation API выглядит как сигнал: валидация attribution payload может стать отдельным обязательным этапом, а не ad-hoc проверкой в логах.
Если собираете server-side измерение и думаете не только про Meta CAPI/Enhanced Conversions, стоит следить за IAB Tech Lab. По их ленте видно, куда двигается слой стандартов вокруг privacy-preserving attribution.
Что уже вышло:
— 27 июня 2024: финальные результаты fit analysis Google Privacy Sandbox для Protected Audiences auctions.
— 22 октября 2024: запуск Ad Format Hero — инициатива по стандартизации emerging Connected TV ad formats.
— 25 февраля 2025: первый релиз Attribution Data Mapping Protocol, ADMaP. Формулировка IAB: стандарт использует advanced cryptographic techniques для measurement with privacy guarantees.
— 18 марта 2025: финальные версии ACIF и спецификации ACIF Validation API готовы к implementation.
— 17 июля 2025: финальное руководство ID-Less Solutions — сравнение ID Solutions и ID-Less Solutions.
Что это значит для performance:
1. Атрибуция уходит от “передадим больше идентификаторов” к формальным протоколам и privacy guarantees.
2. Server-side слой должен быть готов не только к CAPI/Events API, но и к маппингу attribution data между системами.
3. ACIF Validation API выглядит как сигнал: валидация attribution payload может стать отдельным обязательным этапом, а не ad-hoc проверкой в логах.
IP anonymization в sGTM через Variable Template
Jude Nwachukwu Onyejekwe разобрал IP Transformer/Anonymizer для server-side GTM. Задача шаблона — управлять тем, как IP-адрес собирается и передаётся в ads/analytics vendors внутри sGTM.
Что умеет template:
— Remove Last octet
— Remove Last two octets
— Remove Last three octets
— Redact IP Address
— Replace with Static IP
— Hash IP Address через SHA-256
Практический смысл для performance:
если в server container уходят события в рекламные и аналитические системы, IP можно трансформировать на уровне sGTM до отправки vendor’у. Это не «магия атрибуции», а контроль над тем, какие данные реально покидают ваш tagging server.
Prerequisite простой:
— нужен server-side Google Tag Manager container
— нужен рабочий tagging server
Без этого variable template использовать не получится.
Хороший паттерн для команд, которые уже держат sGTM и хотят централизованно управлять IP-политикой не в каждом отдельном теге, а на уровне переменной.
Jude Nwachukwu Onyejekwe разобрал IP Transformer/Anonymizer для server-side GTM. Задача шаблона — управлять тем, как IP-адрес собирается и передаётся в ads/analytics vendors внутри sGTM.
Что умеет template:
— Remove Last octet
— Remove Last two octets
— Remove Last three octets
— Redact IP Address
— Replace with Static IP
— Hash IP Address через SHA-256
Практический смысл для performance:
если в server container уходят события в рекламные и аналитические системы, IP можно трансформировать на уровне sGTM до отправки vendor’у. Это не «магия атрибуции», а контроль над тем, какие данные реально покидают ваш tagging server.
Prerequisite простой:
— нужен server-side Google Tag Manager container
— нужен рабочий tagging server
Без этого variable template использовать не получится.
Хороший паттерн для команд, которые уже держат sGTM и хотят централизованно управлять IP-политикой не в каждом отдельном теге, а на уровне переменной.
IAB Tech Lab держит фокус на signal loss и privacy, но теперь в связке с agentic advertising.
Что есть в их последней ленте:
— Signal Shift в NYC 19 марта: privacy considerations в эпоху agentic advertising и потери сигналов
— Signal Shift West Coast прошёл 25 сентября 2025 в Mountain View
— Supply Chain APIs получили Supply Chain Validation for Sellers: продавцы могут понимать, где listed их domain
— Summit 2025 был sold out и покрывал AI, CTV, curation, privacy regulations
— отдельный акцент на taxonomies в AI world; Mixpeek сделал donation, который может помочь с upgrade taxonomies
Что это значит для performance / attribution:
1. Privacy больше не отдельный compliance-трек. Он становится частью инфраструктуры сигналов: supply chain, taxonomy, API validation.
2. Для server-side атрибуции это сдвиг от “передать больше идентификаторов” к “доказать качество и происхождение сигнала”.
3. Supply Chain Validation for Sellers — важный кусок для доменной прозрачности. Если домен участвует в programmatic / CTV / retail media цепочках, вопрос “где он listed” становится operational, не юридическим.
4. Taxonomies в AI-контексте — не косметика. Без нормальной классификации агентные и ML-системы будут принимать решения на грязной семантике.
#privacy_sandbox #iabtechlab
Что есть в их последней ленте:
— Signal Shift в NYC 19 марта: privacy considerations в эпоху agentic advertising и потери сигналов
— Signal Shift West Coast прошёл 25 сентября 2025 в Mountain View
— Supply Chain APIs получили Supply Chain Validation for Sellers: продавцы могут понимать, где listed их domain
— Summit 2025 был sold out и покрывал AI, CTV, curation, privacy regulations
— отдельный акцент на taxonomies в AI world; Mixpeek сделал donation, который может помочь с upgrade taxonomies
Что это значит для performance / attribution:
1. Privacy больше не отдельный compliance-трек. Он становится частью инфраструктуры сигналов: supply chain, taxonomy, API validation.
2. Для server-side атрибуции это сдвиг от “передать больше идентификаторов” к “доказать качество и происхождение сигнала”.
3. Supply Chain Validation for Sellers — важный кусок для доменной прозрачности. Если домен участвует в programmatic / CTV / retail media цепочках, вопрос “где он listed” становится operational, не юридическим.
4. Taxonomies в AI-контексте — не косметика. Без нормальной классификации агентные и ML-системы будут принимать решения на грязной семантике.
#privacy_sandbox #iabtechlab
GTM recipe: маппинг ecommerce.items без JavaScript
Jude Nwachukwu Onyejekwe описал шаблон Advanced Item Array Transformation для GTM. Важное для sGTM: шаблон работает и в web, и в server containers, а Google Tag Manager team его одобрила.
Что делает шаблон:
— Source selection: берет массив из ecommerce.items в dataLayer или из custom variable
— Attribute mapping: переименовывает ключи через таблицу
— Validation: проверяет структуру массива и маппингов
— Data formatting: приводит данные к нужному формату
— Static attributes: добавляет фиксированные атрибуты к items
Практический кейс: когда frontend отдает item_id/item_name/item_category, а downstream-теги или server-side routing ждут другую схему. Вместо Custom JS Variable можно вынести трансформацию в template и использовать один и тот же подход в web GTM и sGTM.
Почему это полезно для server-side:
— меньше кастомного JS в клиентском контейнере
— единый слой нормализации item array перед отправкой событий
— проще поддерживать схемы для GA4 / рекламных endpoints, если названия атрибутов расходятся
Подводный камень: шаблон решает трансформацию структуры, но не заменяет проверку самой ecommerce-разметки на сайте. Если ecommerce.items уже приходит неполным или нестабильным, маппинг это не исправит.
Jude Nwachukwu Onyejekwe описал шаблон Advanced Item Array Transformation для GTM. Важное для sGTM: шаблон работает и в web, и в server containers, а Google Tag Manager team его одобрила.
Что делает шаблон:
— Source selection: берет массив из ecommerce.items в dataLayer или из custom variable
— Attribute mapping: переименовывает ключи через таблицу
— Validation: проверяет структуру массива и маппингов
— Data formatting: приводит данные к нужному формату
— Static attributes: добавляет фиксированные атрибуты к items
Практический кейс: когда frontend отдает item_id/item_name/item_category, а downstream-теги или server-side routing ждут другую схему. Вместо Custom JS Variable можно вынести трансформацию в template и использовать один и тот же подход в web GTM и sGTM.
Почему это полезно для server-side:
— меньше кастомного JS в клиентском контейнере
— единый слой нормализации item array перед отправкой событий
— проще поддерживать схемы для GA4 / рекламных endpoints, если названия атрибутов расходятся
Подводный камень: шаблон решает трансформацию структуры, но не заменяет проверку самой ecommerce-разметки на сайте. Если ecommerce.items уже приходит неполным или нестабильным, маппинг это не исправит.
Анти-кейс: double UTM ломает GA4-атрибуцию ещё до sGTM
DumbData разобрали типовую ошибку: UTM-параметры добавлены к landing page URL больше одного раза. Если в URL повторяется один и тот же UTM-параметр, Google Analytics берёт последнее значение.
Что это значит для performance:
— utm_source / utm_medium / utm_campaign могут перезаписаться не тем значением;
— GA4 получит «валидный» hit, но с неправильной разметкой;
— дальше sGTM, CAPI или Enhanced Conversions уже будут работать с искажённым source/medium;
— проблема выглядит как атрибуционная, но корень — в URL hygiene.
Пример паттерна:
?utm_source=facebook&utm_medium=paid&utm_source=meta
Для GA последнее значение utm_source будет meta.
DumbData также выпустили бесплатный GA4 UTM Auditor Tool для поиска таких ошибок. По статье, инструмент поддерживает проверки по девяти рекламным платформам.
Практика для sGTM:
перед тем как дебажить Client / Tag / Event Data в GTM Server, проверьте, не приезжают ли в GA4 уже конфликтующие UTM. Иначе server-side слой аккуратно прокинет дальше мусорную атрибуцию.
DumbData разобрали типовую ошибку: UTM-параметры добавлены к landing page URL больше одного раза. Если в URL повторяется один и тот же UTM-параметр, Google Analytics берёт последнее значение.
Что это значит для performance:
— utm_source / utm_medium / utm_campaign могут перезаписаться не тем значением;
— GA4 получит «валидный» hit, но с неправильной разметкой;
— дальше sGTM, CAPI или Enhanced Conversions уже будут работать с искажённым source/medium;
— проблема выглядит как атрибуционная, но корень — в URL hygiene.
Пример паттерна:
?utm_source=facebook&utm_medium=paid&utm_source=meta
Для GA последнее значение utm_source будет meta.
DumbData также выпустили бесплатный GA4 UTM Auditor Tool для поиска таких ошибок. По статье, инструмент поддерживает проверки по девяти рекламным платформам.
Практика для sGTM:
перед тем как дебажить Client / Tag / Event Data в GTM Server, проверьте, не приезжают ли в GA4 уже конфликтующие UTM. Иначе server-side слой аккуратно прокинет дальше мусорную атрибуцию.
GA4 alternatives: что из статьи Crazy Egg попадает в стек измерения
Crazy Egg опубликовали подборку альтернатив Google Analytics. Для server-side атрибуции это не замена CAPI/sGTM, но полезный слой для продуктовой аналитики и диагностики конверсий.
Что зафиксировано в материале:
— Crazy Egg
Starting price: $0
Free forever plan включает web analytics, conversion tracking, surveys и instant heatmaps.
— Plausible
Starting price: $9/month
— PostHog
Starting price: $0
Практический вывод для performance-команд: если GA4 используется не только как источник конверсий для Google Ads, а еще как поведенческая аналитика, часть задач можно закрывать отдельными инструментами: web analytics, conversion tracking, surveys, heatmaps. Но связку рекламной атрибуции, Enhanced Conversions, CAPI и deduplication это само по себе не заменяет.
Дата публикации статьи: March 23, 2026.
Crazy Egg опубликовали подборку альтернатив Google Analytics. Для server-side атрибуции это не замена CAPI/sGTM, но полезный слой для продуктовой аналитики и диагностики конверсий.
Что зафиксировано в материале:
— Crazy Egg
Starting price: $0
Free forever plan включает web analytics, conversion tracking, surveys и instant heatmaps.
— Plausible
Starting price: $9/month
— PostHog
Starting price: $0
Практический вывод для performance-команд: если GA4 используется не только как источник конверсий для Google Ads, а еще как поведенческая аналитика, часть задач можно закрывать отдельными инструментами: web analytics, conversion tracking, surveys, heatmaps. Но связку рекламной атрибуции, Enhanced Conversions, CAPI и deduplication это само по себе не заменяет.
Дата публикации статьи: March 23, 2026.
Shopify → Facebook CAPI через GTM: гибридная схема
Analytics Mania разобрали сетап для Shopify, где Conversions API и browser-side Facebook Pixel работают параллельно. Это не замена Pixel, а hybrid setup: браузерные события остаются, серверные идут через sGTM.
Контекст:
стартовая точка — Shopify-сайт и Google Tag Manager container. Дальше данные магазина отправляются в server-side GTM container через data tags, разработанные Stape.
Какие события в фокусе:
— PageView
— AddToCart
— Purchase
Что важно для performance:
— гибридная архитектура нужна для параллельной работы Pixel + CAPI
— Shopify-события не тащатся «магически»: их нужно собрать в web GTM и передать в sGTM
— Stape data tags используются как транспорт данных из магазина в server container
— Purchase лучше сразу проектировать с учетом дедупликации Pixel/CAPI, иначе параллельный запуск даст дубли
Анти-паттерн: включить CAPI поверх существующего Pixel без стратегии event_id. В статье явно идет речь о двух системах, работающих параллельно — значит, дедупликация должна быть частью схемы внедрения.
Analytics Mania разобрали сетап для Shopify, где Conversions API и browser-side Facebook Pixel работают параллельно. Это не замена Pixel, а hybrid setup: браузерные события остаются, серверные идут через sGTM.
Контекст:
стартовая точка — Shopify-сайт и Google Tag Manager container. Дальше данные магазина отправляются в server-side GTM container через data tags, разработанные Stape.
Какие события в фокусе:
— PageView
— AddToCart
— Purchase
Что важно для performance:
— гибридная архитектура нужна для параллельной работы Pixel + CAPI
— Shopify-события не тащатся «магически»: их нужно собрать в web GTM и передать в sGTM
— Stape data tags используются как транспорт данных из магазина в server container
— Purchase лучше сразу проектировать с учетом дедупликации Pixel/CAPI, иначе параллельный запуск даст дубли
Анти-паттерн: включить CAPI поверх существующего Pixel без стратегии event_id. В статье явно идет речь о двух системах, работающих параллельно — значит, дедупликация должна быть частью схемы внедрения.
GTM без Custom HTML для first-party cookies
Jude Nwachukwu Onyejekwe опубликовал гайд по установке и чтению cookies в Google Tag Manager без JavaScript и Custom HTML tags.
Что важно для server-side / attribution сетапов:
— фокус именно на first-party cookies
— подход no-code внутри GTM
— covered tag templates одобрены Google и доступны в GTM Template Gallery
Практический смысл: если в проекте запрещены Custom HTML tags или есть строгий review контейнера, approved template из Gallery проще провести через governance, чем самописный JS для set/read cookie.
Но это не магия атрибуции. Речь про управление first-party cookies в GTM, а не про обход браузерных ограничений или восстановление всех потерянных событий.
Где может пригодиться:
— хранить собственный идентификатор в first-party cookie
— читать cookie как переменную GTM
— использовать значение дальше в web/server-side пайплайне, если это соответствует consent и privacy policy
Jude Nwachukwu Onyejekwe опубликовал гайд по установке и чтению cookies в Google Tag Manager без JavaScript и Custom HTML tags.
Что важно для server-side / attribution сетапов:
— фокус именно на first-party cookies
— подход no-code внутри GTM
— covered tag templates одобрены Google и доступны в GTM Template Gallery
Практический смысл: если в проекте запрещены Custom HTML tags или есть строгий review контейнера, approved template из Gallery проще провести через governance, чем самописный JS для set/read cookie.
Но это не магия атрибуции. Речь про управление first-party cookies в GTM, а не про обход браузерных ограничений или восстановление всех потерянных событий.
Где может пригодиться:
— хранить собственный идентификатор в first-party cookie
— читать cookie как переменную GTM
— использовать значение дальше в web/server-side пайплайне, если это соответствует consent и privacy policy
Analytics Mania обновил гайд по GTM Server-Side Tagging со Stape
Задача: настроить server-side GTM так, чтобы Google Analytics-теги шли через серверный контейнер, а не напрямую из браузера в GA.
Контекст:
В классическом client-side варианте GTM установлен прямо на сайте. При server-side tagging данные сначала уходят в server-side Google Tag Manager container, и уже оттуда пересылаются в Google Analytics.
Что важно для performance-команды:
— нужен отдельный серверный хостинг для sGTM
— Stape в статье указан как вариант с ценой примерно от $20/мес
— на крупных cloud-платформах стоимость может доходить до $90/мес и выше
— биллинг масштабируется вместе с трафиком
Практический вывод:
sGTM — это не “включить галочку в GTM”, а отдельная инфраструктура между сайтом и аналитикой. При миграции нужно заранее считать не только трекинг-схему, но и стоимость хостинга под объем событий.
Анти-кейс для планирования: если просто перенести GA-теги на сервер без оценки трафика, стоимость может стать сюрпризом уже после запуска.
Задача: настроить server-side GTM так, чтобы Google Analytics-теги шли через серверный контейнер, а не напрямую из браузера в GA.
Контекст:
В классическом client-side варианте GTM установлен прямо на сайте. При server-side tagging данные сначала уходят в server-side Google Tag Manager container, и уже оттуда пересылаются в Google Analytics.
Что важно для performance-команды:
— нужен отдельный серверный хостинг для sGTM
— Stape в статье указан как вариант с ценой примерно от $20/мес
— на крупных cloud-платформах стоимость может доходить до $90/мес и выше
— биллинг масштабируется вместе с трафиком
Практический вывод:
sGTM — это не “включить галочку в GTM”, а отдельная инфраструктура между сайтом и аналитикой. При миграции нужно заранее считать не только трекинг-схему, но и стоимость хостинга под объем событий.
Анти-кейс для планирования: если просто перенести GA-теги на сервер без оценки трафика, стоимость может стать сюрпризом уже после запуска.
GTM debug stack: два изменения в Chrome-расширениях
Google переносит всю функциональность Tag Assistant Companion в Tag Assistant. Если Companion ещё установлен в рабочем профиле аналитика, расширение будет автоматически удалено в ближайшие месяцы.
Практика для команды:
— проверьте, не завязаны ли внутренние инструкции по QA тегов на Tag Assistant Companion;
— обновите документацию и onboarding на использование Tag Assistant;
— учтите автодеинсталляцию Companion при воспроизведении старых debug-сценариев.
Отдельно по Adswerve dataLayer Inspector+: функция “Insert GTM container”, которая позволяла добавлять GTM-контейнер на сайт, больше недоступна.
Это важно для аудитов и тестирования: если в чек-листе указан именно этот пункт расширения, инструкция уже не соответствует текущему интерфейсу.
Статья Analytics Mania обновлена 17 марта 2026 года.
Google переносит всю функциональность Tag Assistant Companion в Tag Assistant. Если Companion ещё установлен в рабочем профиле аналитика, расширение будет автоматически удалено в ближайшие месяцы.
Практика для команды:
— проверьте, не завязаны ли внутренние инструкции по QA тегов на Tag Assistant Companion;
— обновите документацию и onboarding на использование Tag Assistant;
— учтите автодеинсталляцию Companion при воспроизведении старых debug-сценариев.
Отдельно по Adswerve dataLayer Inspector+: функция “Insert GTM container”, которая позволяла добавлять GTM-контейнер на сайт, больше недоступна.
Это важно для аудитов и тестирования: если в чек-листе указан именно этот пункт расширения, инструкция уже не соответствует текущему интерфейсу.
Статья Analytics Mania обновлена 17 марта 2026 года.
Calendly → GTM → GA4: какие события можно забрать из embedded-календаря
Analytics Mania обновил схему трекинга Calendly через Google Tag Manager с отправкой событий в GA4.
Что фиксируется:
— загрузка embedded Calendly на странице профиля;
— просмотр event type;
— выбор даты и времени;
— успешное бронирование события.
Для события scheduled Calendly дополнительно отдает invitee_uri. Его можно добавить в dataLayer.push и передать дальше через GTM в GA4.
Ограничение реализации: события показывают этап взаимодействия с календарем, но не дают granular-параметры:
— точную выбранную дату или время;
— какой именно event type просмотрели;
— какой event type забронировали.
Что это значит для аналитики: setup подходит для воронки view → select → scheduled в GA4. Для отчетов по слотам или типам встреч описанного набора данных недостаточно.
Материал обновлен 13 марта 2026.
Источник: https://www.analyticsmania.com/post/how-to-track-calendly-with-google-tag-manager-and-google-analytics-4
Analytics Mania обновил схему трекинга Calendly через Google Tag Manager с отправкой событий в GA4.
Что фиксируется:
— загрузка embedded Calendly на странице профиля;
— просмотр event type;
— выбор даты и времени;
— успешное бронирование события.
Для события scheduled Calendly дополнительно отдает invitee_uri. Его можно добавить в dataLayer.push и передать дальше через GTM в GA4.
Ограничение реализации: события показывают этап взаимодействия с календарем, но не дают granular-параметры:
— точную выбранную дату или время;
— какой именно event type просмотрели;
— какой event type забронировали.
Что это значит для аналитики: setup подходит для воронки view → select → scheduled в GA4. Для отчетов по слотам или типам встреч описанного набора данных недостаточно.
Материал обновлен 13 марта 2026.
Источник: https://www.analyticsmania.com/post/how-to-track-calendly-with-google-tag-manager-and-google-analytics-4
HIPAA и mobile attribution: когда device_id/IP/cookie становятся PHI
Branch разобрал практику для healthcare marketing. Ключевой момент для аналитиков: цифровые идентификаторы сами по себе не всегда PHI, но становятся PHI, когда связаны с health-related activity.
Что это значит для attribution-стека:
— Device ID, IP, cookies в связке с медицинским действием = PHI
— Analytics platform / MMP / marketing agency, которые обрабатывают PHI, становятся business associates
— HIPAA применим к analytics, если одновременно:
1) организация — covered entity или business associate
2) она обрабатывает PHI
3) PHI создаётся, получается, хранится или передаётся для её программ
Практическое следствие: передавать health-related события в рекламные/атрибуционные системы как обычный marketing payload — рискованная зона. Нужно заранее определить категорию данных.
HIPAA даёт 3 рабочих класса:
— fully identifiable PHI
— de-identified data
— limited data sets
Для server-side схем это влияет на routing: какие события уходят в MMP/CAPI/GA4, какие остаются внутри HIPAA-eligible контура, какие должны быть де-идентифицированы до аналитики.
Источник: https://www.branch.io/resources/blog/hipaa-eligible-analytics-best-practices-for-healthcare-marketing
Branch разобрал практику для healthcare marketing. Ключевой момент для аналитиков: цифровые идентификаторы сами по себе не всегда PHI, но становятся PHI, когда связаны с health-related activity.
Что это значит для attribution-стека:
— Device ID, IP, cookies в связке с медицинским действием = PHI
— Analytics platform / MMP / marketing agency, которые обрабатывают PHI, становятся business associates
— HIPAA применим к analytics, если одновременно:
1) организация — covered entity или business associate
2) она обрабатывает PHI
3) PHI создаётся, получается, хранится или передаётся для её программ
Практическое следствие: передавать health-related события в рекламные/атрибуционные системы как обычный marketing payload — рискованная зона. Нужно заранее определить категорию данных.
HIPAA даёт 3 рабочих класса:
— fully identifiable PHI
— de-identified data
— limited data sets
Для server-side схем это влияет на routing: какие события уходят в MMP/CAPI/GA4, какие остаются внутри HIPAA-eligible контура, какие должны быть де-идентифицированы до аналитики.
Источник: https://www.branch.io/resources/blog/hipaa-eligible-analytics-best-practices-for-healthcare-marketing
Branch разложил базовую рамку выбора attribution model для app-маркетинга.
Суть без пересказа учебника:
Single-touch attribution:
— весь credit за conversion уходит в одну interaction в user journey
— проще для отчётности и имплементации
— но модель намеренно игнорирует остальные касания
Multi-touch attribution:
— credit распределяется между несколькими touchpoints до conversion
— отражает сценарий, где app user взаимодействует с несколькими campaigns и channels перед конверсией
— требует аккуратнее определить, какие interactions попадают в путь и как делится credit
Практический вывод для server-side / CAPI / app analytics: перед тем как спорить про модель, нужно зафиксировать, что именно считается touchpoint и conversion event. Иначе single-touch и multi-touch будут отличаться не только логикой credit, но и качеством входных событий.
Branch делит модели на две большие категории:
— credit одному touchpoint
— credit нескольким interactions
Это полезная рамка для миграций: сначала нормализуем event collection и идентификаторы, потом выбираем attribution logic.
Источник: https://www.branch.io/resources/blog/attribution-models-explained-how-to-choose-and-implement-the-right-approach-for-your-app
Суть без пересказа учебника:
Single-touch attribution:
— весь credit за conversion уходит в одну interaction в user journey
— проще для отчётности и имплементации
— но модель намеренно игнорирует остальные касания
Multi-touch attribution:
— credit распределяется между несколькими touchpoints до conversion
— отражает сценарий, где app user взаимодействует с несколькими campaigns и channels перед конверсией
— требует аккуратнее определить, какие interactions попадают в путь и как делится credit
Практический вывод для server-side / CAPI / app analytics: перед тем как спорить про модель, нужно зафиксировать, что именно считается touchpoint и conversion event. Иначе single-touch и multi-touch будут отличаться не только логикой credit, но и качеством входных событий.
Branch делит модели на две большие категории:
— credit одному touchpoint
— credit нескольким interactions
Это полезная рамка для миграций: сначала нормализуем event collection и идентификаторы, потом выбираем attribution logic.
Источник: https://www.branch.io/resources/blog/attribution-models-explained-how-to-choose-and-implement-the-right-approach-for-your-app