Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Компания Meta выпустила Muse Spark 1.1
Meta выпустила Muse Spark 1.1 почти одновременно с новой ChatGPT-5.6. Это мультимодальный агент, который сам дробит задачу на подзадачи и распределяет их между субагентами.
Стоимость тоже заметно ниже топовых западных моделей: $1.25 за миллион входных токенов и $4.25 за миллион выходных.
Но главный вопрос — насколько она реально сильна на фоне к…
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-spark-1-1
🧠 Ещё больше инсайтов → в канале AFF.top
Meta выпустила Muse Spark 1.1 почти одновременно с новой ChatGPT-5.6. Это мультимодальный агент, который сам дробит задачу на подзадачи и распределяет их между субагентами.
Стоимость тоже заметно ниже топовых западных моделей: $1.25 за миллион входных токенов и $4.25 за миллион выходных.
Но главный вопрос — насколько она реально сильна на фоне к…
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-spark-1-1
🧠 Ещё больше инсайтов → в канале AFF.top
Как за 1 неделю собрать server-side событие покупки без потери данных
Если у вас уже есть сайт, CRM и рекламные кабинеты, но события теряются из-за блокировщиков, iOS и ограничений браузеров, начните с самого ценного события — покупки. Ниже схема, которую можно поднять за неделю.
1. Определите одно событие и один маршрут данных. Для первого этапа берите purchase: оно влияет и на оптимизацию рекламы, и на выручку. Маршрут должен быть коротким: сайт → сервер → аналитика → рекламные системы.
2. Зафиксируйте состав события. Минимум: order_id, сумма, валюта, timestamp, client_id, user_id, источник, статус согласия на обработку данных. Не тащите всё подряд: чем чище схема, тем меньше расхождений.
3. Поставьте server-side контейнер. Чаще всего это отдельный контейнер в GTM Server-Side или аналог на своём сервере. Его задача — принять веб-событие, проверить его и отправить дальше в нужные системы.
4. Настройте передачу идентификаторов. Важно передавать не только cookie, но и first-party идентификаторы: внутренний user_id, order_id, при наличии — email/телефон в хешированном виде. Это помогает связать сессии, которые браузер уже «потерял».
5. Добавьте проверку на дубли. Purchase должен уходить один раз. Используйте order_id как ключ идемпотентности: если событие пришло повторно, сервер его отбрасывает.
6. Сверьте данные с тремя источниками: сайт, CRM, рекламная платформа. Разница до 3–5% для старта допустима, но вы должны понимать, где именно она возникает: на отправке, на матчингe или на стороне кабинета.
7. Введите ежедневный контроль. Один отчет: число покупок, сумма, доля событий, ушедших с сервера, и доля ошибок. Через неделю у вас уже будет базовая картина, где теряются деньги.
**Смысл server-side не в моде, а в том, чтобы вернуть управляемость данным.** Начните с покупки, а не со всей воронки: так быстрее увидите эффект и не утонете в настройках.
— @ServerSideTrackingRuPro
Если у вас уже есть сайт, CRM и рекламные кабинеты, но события теряются из-за блокировщиков, iOS и ограничений браузеров, начните с самого ценного события — покупки. Ниже схема, которую можно поднять за неделю.
1. Определите одно событие и один маршрут данных. Для первого этапа берите purchase: оно влияет и на оптимизацию рекламы, и на выручку. Маршрут должен быть коротким: сайт → сервер → аналитика → рекламные системы.
2. Зафиксируйте состав события. Минимум: order_id, сумма, валюта, timestamp, client_id, user_id, источник, статус согласия на обработку данных. Не тащите всё подряд: чем чище схема, тем меньше расхождений.
3. Поставьте server-side контейнер. Чаще всего это отдельный контейнер в GTM Server-Side или аналог на своём сервере. Его задача — принять веб-событие, проверить его и отправить дальше в нужные системы.
4. Настройте передачу идентификаторов. Важно передавать не только cookie, но и first-party идентификаторы: внутренний user_id, order_id, при наличии — email/телефон в хешированном виде. Это помогает связать сессии, которые браузер уже «потерял».
5. Добавьте проверку на дубли. Purchase должен уходить один раз. Используйте order_id как ключ идемпотентности: если событие пришло повторно, сервер его отбрасывает.
6. Сверьте данные с тремя источниками: сайт, CRM, рекламная платформа. Разница до 3–5% для старта допустима, но вы должны понимать, где именно она возникает: на отправке, на матчингe или на стороне кабинета.
7. Введите ежедневный контроль. Один отчет: число покупок, сумма, доля событий, ушедших с сервера, и доля ошибок. Через неделю у вас уже будет базовая картина, где теряются деньги.
**Смысл server-side не в моде, а в том, чтобы вернуть управляемость данным.** Начните с покупки, а не со всей воронки: так быстрее увидите эффект и не утонете в настройках.
— @ServerSideTrackingRuPro
Почему серверная аналитика — это фундамент вашей RevOps-стратегии
В 2026 году классическая воронка, где маркетинг отвечает за лиды (потенциальных клиентов), а отдел продаж — за закрытие сделок, окончательно уходит в прошлое. Мы перешли в эпоху RevOps (объединенного управления выручкой), где ценность маркетинга измеряется не количеством заявок, а вкладом в итоговую прибыль. И здесь серверная аналитика перестает быть просто техническим инструментом для обхода ограничений браузеров. Она становится «единым источником правды» для всех департаментов.
Когда мы настраиваем сбор данных на стороне сервера (server-side tagging), мы решаем главную проблему эпохи: фрагментацию пути клиента. В условиях, когда средний чек падает, а пользователь совершает десятки касаний с брендом, полагаться на стандартные куки-файлы (cookies) — значит сознательно искажать реальность. Вы теряете данные о пользователях, использующих блокировщики рекламы или жесткие настройки приватности, и в итоге получаете искаженную картину LTV (пожизненной ценности клиента).
Моя практика показывает, что компании, внедрившие серверную аналитику, фиксируют рост точности атрибуции (определения источника конверсии) на 15–20% в сравнении с клиентскими методами. Это дает возможность не просто «сливать» бюджет, а управлять удержанием (retention). Когда данные о поведении пользователя передаются в CRM напрямую с сервера, мы получаем возможность корректировать коммуникацию в реальном времени, не дожидаясь, пока рекламные системы «обучатся» на неполных данных.
— Отказ от last-click (атрибуции по последнему клику) в пользу MMM (маркетингового моделирования на основе данных) невозможен без чистого потока данных из серверного контейнера.
— В модели RevOps данные должны быть идентичны для маркетинга, продаж и службы заботы о клиентах. Серверный подход устраняет расхождения, которые возникают из-за блокировок на стороне браузера.
— Контент в эпоху нулевых кликов (zero-click) сложнее отследить. Серверная аналитика позволяет видеть реальный путь пользователя, даже если он не совершил целевое действие на первом же сайте.
Если ваш отдел маркетинга до сих пор спорит с отделом продаж о том, «откуда пришли деньги», — проблема не в качестве трафика, а в качестве данных. Перевод сбора событий на серверную сторону — это первый шаг к тому, чтобы превратить маркетинг из центра затрат в архитектора стабильной выручки. Хватит гадать, какие касания приносят доход, пора начать их учитывать с хирургической точностью.
— @ServerSideTrackingRuPro
В 2026 году классическая воронка, где маркетинг отвечает за лиды (потенциальных клиентов), а отдел продаж — за закрытие сделок, окончательно уходит в прошлое. Мы перешли в эпоху RevOps (объединенного управления выручкой), где ценность маркетинга измеряется не количеством заявок, а вкладом в итоговую прибыль. И здесь серверная аналитика перестает быть просто техническим инструментом для обхода ограничений браузеров. Она становится «единым источником правды» для всех департаментов.
Когда мы настраиваем сбор данных на стороне сервера (server-side tagging), мы решаем главную проблему эпохи: фрагментацию пути клиента. В условиях, когда средний чек падает, а пользователь совершает десятки касаний с брендом, полагаться на стандартные куки-файлы (cookies) — значит сознательно искажать реальность. Вы теряете данные о пользователях, использующих блокировщики рекламы или жесткие настройки приватности, и в итоге получаете искаженную картину LTV (пожизненной ценности клиента).
Моя практика показывает, что компании, внедрившие серверную аналитику, фиксируют рост точности атрибуции (определения источника конверсии) на 15–20% в сравнении с клиентскими методами. Это дает возможность не просто «сливать» бюджет, а управлять удержанием (retention). Когда данные о поведении пользователя передаются в CRM напрямую с сервера, мы получаем возможность корректировать коммуникацию в реальном времени, не дожидаясь, пока рекламные системы «обучатся» на неполных данных.
— Отказ от last-click (атрибуции по последнему клику) в пользу MMM (маркетингового моделирования на основе данных) невозможен без чистого потока данных из серверного контейнера.
— В модели RevOps данные должны быть идентичны для маркетинга, продаж и службы заботы о клиентах. Серверный подход устраняет расхождения, которые возникают из-за блокировок на стороне браузера.
— Контент в эпоху нулевых кликов (zero-click) сложнее отследить. Серверная аналитика позволяет видеть реальный путь пользователя, даже если он не совершил целевое действие на первом же сайте.
Если ваш отдел маркетинга до сих пор спорит с отделом продаж о том, «откуда пришли деньги», — проблема не в качестве трафика, а в качестве данных. Перевод сбора событий на серверную сторону — это первый шаг к тому, чтобы превратить маркетинг из центра затрат в архитектора стабильной выручки. Хватит гадать, какие касания приносят доход, пора начать их учитывать с хирургической точностью.
— @ServerSideTrackingRuPro
Сервера, которые “путают” воронку: как я лечу разъехавшиеся события в first-party аналитике
Когда мы переходим с клиентских пикселей (или смешанной схемы) на server-side аналитика, самая частая боль звучит одинаково: «воронка стала хуже». При этом заказов не меньше, а в отчётах конверсия просела — иногда на десятки процентов. На практике причина почти всегда не в маркетинге, а в том, что события начали “жить” в разных мирах: разные таймлайны, разные ключи пользователя, разные правила дедупликации.
Моё рабочее правило: если воронка “сломалась” сразу после внедрения server-side, я не трогаю кампании и бюджеты. Я сначала проверяю, как именно собираются и сшиваются события на сервере.
1) Самая частая ошибка — двойные события с разными “верситетами”
На клиенте событие могло отправляться с одного источника, а в server-side вы добавили ещё один маршрут (например, ретрай, параллельные трекеры, расширение из тег-менеджера + прямой event API). В результате одно и то же действие попадает в систему дважды, но с разными параметрами: один раз — с user_id, второй — только с client_id.
Я обычно начинаю с простого теста: беру событие “Sign Up” (или “Add to Cart”) и строю частоту по связке ключей:
— client_id + session_id
— user_id + session_id
— только user_id
Дальше сравниваю распределение во времени (до/после) и смотрю, где появился второй “хвост”. Если второй хвост есть — это не “органика ухудшилась”, а схема матчинга ключей стала несовместимой.
2) Тайм-ауты и очереди: события не исчезают, но меняют порядок
В server-side часто добавляют буферизацию, повторные отправки (retry) и очереди для устойчивости. Это улучшает надёжность доставки, но создаёт новый класс артефактов: событие “purchase” может прийти раньше “view_product”, потому что оно отправляется позже по пользовательскому пути, но раньше доезжает до сервера (или наоборот).
Мой приём: я храню для каждого события два времени:
— event_time (время действия в браузере/приложении)
— received_time (время прихода на сервер)
И дальше строю проверку монотонности: для одной сессии “view → add → purchase” разница event_time должна соответствовать ожидаемому порядку чаще, чем сейчас. Если монотонность упала — проблема в транспортной логике, а не в воронке.
Наблюдение из практики: при первой попытке server-side иногда получается, что 3–7% purchase-событий оказываются “раньше” своих предшественников по event_time (из‑за несогласованного часового пояса/смещения или сериализации). Это не звучит страшно, но для расчётов конверсии в “строгих” последовательностях даёт заметный эффект.
3) Дедупликация должна быть не “по событию”, а по смыслу
“Дедуплицируем по event_name + timestamp” — плохая стратегия. Timestamp часто округляется, имеет дрожание из-за сетевых задержек, а один и тот же timestamp может встречаться в разных сценах.
Я перехожу на дедупликацию по детерминированному fingerprint (отпечатку) события:
— user_key (user_id или client_id, что доступно)
— event_type
— source (внутренний роутинг/канал)
— параметр-идентификатор (например, order_id, transaction_id, item_id+quantity+price или request_id)
И делаю окно допустимой повторяемости (например, 10–30 минут) по received_time. Тогда ретраи не ломают аналитику, а реальные повторные действия остаются.
4) Контракт события важнее “магии тегов”
В 2026 году выигрывает тот, кто мыслит как инженер: фиксирует схему данных, контракты и инварианты. В first-party аналитике нельзя жить “как получится”: если вы меняете параметры события, меняется семантика. Если вы меняете ключи атрибуции — меняется всё.
Поэтому я ввожу минимальный “контроль качества” на стороне сервера:
— обязательные поля (user_key, session_key, event_id / request_id)
— допустимые типы/форматы
— проверка полноты (процент событий без ключей)
— алерты на скачки долей “пустых” user_id и на рост событий без идентификаторов
…
Когда мы переходим с клиентских пикселей (или смешанной схемы) на server-side аналитика, самая частая боль звучит одинаково: «воронка стала хуже». При этом заказов не меньше, а в отчётах конверсия просела — иногда на десятки процентов. На практике причина почти всегда не в маркетинге, а в том, что события начали “жить” в разных мирах: разные таймлайны, разные ключи пользователя, разные правила дедупликации.
Моё рабочее правило: если воронка “сломалась” сразу после внедрения server-side, я не трогаю кампании и бюджеты. Я сначала проверяю, как именно собираются и сшиваются события на сервере.
1) Самая частая ошибка — двойные события с разными “верситетами”
На клиенте событие могло отправляться с одного источника, а в server-side вы добавили ещё один маршрут (например, ретрай, параллельные трекеры, расширение из тег-менеджера + прямой event API). В результате одно и то же действие попадает в систему дважды, но с разными параметрами: один раз — с user_id, второй — только с client_id.
Я обычно начинаю с простого теста: беру событие “Sign Up” (или “Add to Cart”) и строю частоту по связке ключей:
— client_id + session_id
— user_id + session_id
— только user_id
Дальше сравниваю распределение во времени (до/после) и смотрю, где появился второй “хвост”. Если второй хвост есть — это не “органика ухудшилась”, а схема матчинга ключей стала несовместимой.
2) Тайм-ауты и очереди: события не исчезают, но меняют порядок
В server-side часто добавляют буферизацию, повторные отправки (retry) и очереди для устойчивости. Это улучшает надёжность доставки, но создаёт новый класс артефактов: событие “purchase” может прийти раньше “view_product”, потому что оно отправляется позже по пользовательскому пути, но раньше доезжает до сервера (или наоборот).
Мой приём: я храню для каждого события два времени:
— event_time (время действия в браузере/приложении)
— received_time (время прихода на сервер)
И дальше строю проверку монотонности: для одной сессии “view → add → purchase” разница event_time должна соответствовать ожидаемому порядку чаще, чем сейчас. Если монотонность упала — проблема в транспортной логике, а не в воронке.
Наблюдение из практики: при первой попытке server-side иногда получается, что 3–7% purchase-событий оказываются “раньше” своих предшественников по event_time (из‑за несогласованного часового пояса/смещения или сериализации). Это не звучит страшно, но для расчётов конверсии в “строгих” последовательностях даёт заметный эффект.
3) Дедупликация должна быть не “по событию”, а по смыслу
“Дедуплицируем по event_name + timestamp” — плохая стратегия. Timestamp часто округляется, имеет дрожание из-за сетевых задержек, а один и тот же timestamp может встречаться в разных сценах.
Я перехожу на дедупликацию по детерминированному fingerprint (отпечатку) события:
— user_key (user_id или client_id, что доступно)
— event_type
— source (внутренний роутинг/канал)
— параметр-идентификатор (например, order_id, transaction_id, item_id+quantity+price или request_id)
И делаю окно допустимой повторяемости (например, 10–30 минут) по received_time. Тогда ретраи не ломают аналитику, а реальные повторные действия остаются.
4) Контракт события важнее “магии тегов”
В 2026 году выигрывает тот, кто мыслит как инженер: фиксирует схему данных, контракты и инварианты. В first-party аналитике нельзя жить “как получится”: если вы меняете параметры события, меняется семантика. Если вы меняете ключи атрибуции — меняется всё.
Поэтому я ввожу минимальный “контроль качества” на стороне сервера:
— обязательные поля (user_key, session_key, event_id / request_id)
— допустимые типы/форматы
— проверка полноты (процент событий без ключей)
— алерты на скачки долей “пустых” user_id и на рост событий без идентификаторов
…
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Российские букмекеры увеличили закуп трафика с мобильных приложений
Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.
По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…
➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii
🧠 Ещё больше инсайтов → в канале AFF.top
Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.
По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…
➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Mia Khalifa стала амбпссадором 1win
Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».
Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.
Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…
➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win
🧠 Ещё больше инсайтов → в канале AFF.top
Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».
Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.
Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…
➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from КРАВЧЕНКО
Дорогие коллеги и партнеры,
Наш маршрут конференций за последние недели, получился особенно насыщенным.
Со стендами PoshFriends мы побывали на MAC и GGate, а затем продолжили встречи уже в полях iGB Live в Лондоне.
В Ереване увиделись с любимыми SEO-командами, попробовали местные вина, обменялись новостями и зарядились энергией УБТ-команд.
В Тбилиси обсуждали тренды, новые связки и совместные планы, встречались с действующими партнерами и знакомились с новыми. А за настроение на стенде отвечала Черемша, которая чуть не стала маскотом одного из наших продуктов. С этой задачей, кажется, справилась лучше всех.
В Лондоне все было уже по-деловому. Провели серию встреч с топ-партнерами, обсудили Японию, бурж и новые точки роста. География интересов растет, планы становятся амбициознее. Воротники, как выяснилось, нагладили не зря.
Спасибо всем, с кем удалось увидеться на этом маршруте. За открытые разговоры, новые идеи, доверие и планы, которые постепенно превращаются в реальные проекты.
Конференционный сезон продолжается. Скоро увидимся снова.
Всегда ваши, Команда Posh Friends 🤝
Наш маршрут конференций за последние недели, получился особенно насыщенным.
Со стендами PoshFriends мы побывали на MAC и GGate, а затем продолжили встречи уже в полях iGB Live в Лондоне.
В Ереване увиделись с любимыми SEO-командами, попробовали местные вина, обменялись новостями и зарядились энергией УБТ-команд.
В Тбилиси обсуждали тренды, новые связки и совместные планы, встречались с действующими партнерами и знакомились с новыми. А за настроение на стенде отвечала Черемша, которая чуть не стала маскотом одного из наших продуктов. С этой задачей, кажется, справилась лучше всех.
В Лондоне все было уже по-деловому. Провели серию встреч с топ-партнерами, обсудили Японию, бурж и новые точки роста. География интересов растет, планы становятся амбициознее. Воротники, как выяснилось, нагладили не зря.
Спасибо всем, с кем удалось увидеться на этом маршруте. За открытые разговоры, новые идеи, доверие и планы, которые постепенно превращаются в реальные проекты.
Конференционный сезон продолжается. Скоро увидимся снова.
Всегда ваши, Команда Posh Friends 🤝
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Короткий домен Telegram перестал работать
Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.
➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat
🧠 Ещё больше инсайтов → в канале AFF.top
Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.
➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat
🧠 Ещё больше инсайтов → в канале AFF.top
Разночтения в событиях: как одна и та же конверсия перестаёт быть конверсией
В последний месяц чаще замечаю паттерн: компании встраивают server-side разметку (или “успешный” прокси-слой), но итоговые отчёты начинают расходиться уже на уровне базовых событий — без смены трекинг-стека и без редизайна воронки. Обычно это выглядит так: в веб-аналитике событие “Lead/Submit” считается по одному набору триггеров, а в CRM или BI — по другому (например, отличается условие валидации полей, или часть запросов помечается как retries). В результате одна и та же форма даёт два разных “источника правды”: маркетинг видит конверсию, а RevOps (работа за выручку вместе с sales и customer success) — подтверждённый оффер уже после внутренней обработки.
Что именно бросается в глаза при разборе: рост доли дубликатов/пересчётов после включения очередей, ретраев и дедупликации по key (например, по message_id, но формируется он нестабильно).
Вы тоже видите, что разъезжаются не кампании, а сами определения событий? На вашей стороне причина чаще в дедупе, в условиях “успешности”, или в том, как вы связываете user/session с CRM-идентификаторами?
— @ServerSideTrackingRuPro
В последний месяц чаще замечаю паттерн: компании встраивают server-side разметку (или “успешный” прокси-слой), но итоговые отчёты начинают расходиться уже на уровне базовых событий — без смены трекинг-стека и без редизайна воронки. Обычно это выглядит так: в веб-аналитике событие “Lead/Submit” считается по одному набору триггеров, а в CRM или BI — по другому (например, отличается условие валидации полей, или часть запросов помечается как retries). В результате одна и та же форма даёт два разных “источника правды”: маркетинг видит конверсию, а RevOps (работа за выручку вместе с sales и customer success) — подтверждённый оффер уже после внутренней обработки.
Что именно бросается в глаза при разборе: рост доли дубликатов/пересчётов после включения очередей, ретраев и дедупликации по key (например, по message_id, но формируется он нестабильно).
Вы тоже видите, что разъезжаются не кампании, а сами определения событий? На вашей стороне причина чаще в дедупе, в условиях “успешности”, или в том, как вы связываете user/session с CRM-идентификаторами?
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Youtube тестирует поиск с AI
YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.
Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.
Что это значит для поиска на YouTube и когда новинка дойдёт до других…
➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai
🧠 Ещё больше инсайтов → в канале AFF.top
YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.
Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.
Что это значит для поиска на YouTube и когда новинка дойдёт до других…
➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai
🧠 Ещё больше инсайтов → в канале AFF.top
Как Converse сократили зависимость от сторонних данных и усилили first-party аналитику
Converse столкнулись с типичной для 2026 года задачей: классическая performance-модель стала хуже считать вклад каналов, а запас данных для точной атрибуции сузился из-за privacy-first подхода и ограничений по сторонним cookie. Для бренда с сильным e-commerce и длинным путём до покупки это особенно болезненно: если не видишь вклад касаний, начинаешь переплачивать за «удобные» каналы и недооценивать верх воронки.
Решение они построили вокруг серверной аналитики и first-party данных. В фокусе были:
— перевод части событий с клиентской стороны на сервер;
— более чистая передача конверсий и параметров кампаний;
— объединение данных сайта, CRM и медиабаинга в единую логику измерения;
— акцент на более устойчивой атрибуции, а не только на last-click (последнем клике).
Что это дало на практике? Бренд не раскрывает полный финансовый эффект, но сам кейс важен другим: у Converse получилось уменьшить разрыв между рекламными платформами и фактическими продажами, а также собрать более надёжную базу для оптимизации бюджета. Это критично в эпоху, когда AI-overviews и zero-click-сценарии забирают часть верхнего трафика, а маркетинг всё чаще должен доказывать вклад в выручку, а не просто в клики.
**Главный урок:** серверная аналитика — это не «технический апгрейд ради галочки», а способ вернуть управляемость маркетингу, когда пользовательских данных меньше, а стоимость ошибки в медиаплане выше. Если бренд не строит first-party контур сейчас, он будет всё сильнее зависеть от чужих алгоритмов и неполной картины спроса.
— @ServerSideTrackingRuPro
Converse столкнулись с типичной для 2026 года задачей: классическая performance-модель стала хуже считать вклад каналов, а запас данных для точной атрибуции сузился из-за privacy-first подхода и ограничений по сторонним cookie. Для бренда с сильным e-commerce и длинным путём до покупки это особенно болезненно: если не видишь вклад касаний, начинаешь переплачивать за «удобные» каналы и недооценивать верх воронки.
Решение они построили вокруг серверной аналитики и first-party данных. В фокусе были:
— перевод части событий с клиентской стороны на сервер;
— более чистая передача конверсий и параметров кампаний;
— объединение данных сайта, CRM и медиабаинга в единую логику измерения;
— акцент на более устойчивой атрибуции, а не только на last-click (последнем клике).
Что это дало на практике? Бренд не раскрывает полный финансовый эффект, но сам кейс важен другим: у Converse получилось уменьшить разрыв между рекламными платформами и фактическими продажами, а также собрать более надёжную базу для оптимизации бюджета. Это критично в эпоху, когда AI-overviews и zero-click-сценарии забирают часть верхнего трафика, а маркетинг всё чаще должен доказывать вклад в выручку, а не просто в клики.
**Главный урок:** серверная аналитика — это не «технический апгрейд ради галочки», а способ вернуть управляемость маркетингу, когда пользовательских данных меньше, а стоимость ошибки в медиаплане выше. Если бренд не строит first-party контур сейчас, он будет всё сильнее зависеть от чужих алгоритмов и неполной картины спроса.
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Z.ai анонсировала новую GLM-5.5
Z.ai готовит релиз флагманской GLM-5.5: модель обещают показать в августе 2026 года.
Главная интрига — рост до 1 трлн параметров при том же контекстном окне в 1 млн токенов. Новинка снова будет заточена под код и агентные задачи.
Почему версия сразу 5.5, без 5.3 и 5.4, и что это может означать для рынка — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/z-ai-anonsirovala-novuiu-glm-5-5
🧠 Ещё больше инсайтов → в канале AFF.top
Z.ai готовит релиз флагманской GLM-5.5: модель обещают показать в августе 2026 года.
Главная интрига — рост до 1 трлн параметров при том же контекстном окне в 1 млн токенов. Новинка снова будет заточена под код и агентные задачи.
Почему версия сразу 5.5, без 5.3 и 5.4, и что это может означать для рынка — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/z-ai-anonsirovala-novuiu-glm-5-5
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Telegram запустил собственный сервер для ботов
Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.
Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.
Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…
➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov
🧠 Ещё больше инсайтов → в канале AFF.top
Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.
Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.
Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…
➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov
🧠 Ещё больше инсайтов → в канале AFF.top
Утилитные переменные в GTM: возвращаем функции, а не значения
Пользовательская переменная JavaScript в Google Tag Manager — это анонимная функция с return. По умолчанию она не принимает параметров, но это легко обойти, если заставить её возвращать другую функцию. Тогда внешний код вызывает внешнюю функцию без аргументов, получает «фабрику» и уже ей передаёт всё, что нужно: ID счётчика, название события, путь к dataLayer. Результат — переиспользуемая утилита вместо десятка копипастных переменных.
Чек-лист внедрения:
— Определитесь, какие параметры повторяются чаще всего: ID серверного контейнера GA4, имя GTM-контейнера, префиксы событий, значения по умолчанию.
— Создайте пользовательскую переменную Custom JavaScript, внутри которой напишите `function() { return function(param) { ... }; }`. Внешняя функция возвращает внутреннюю — внутренняя уже умеет принимать аргументы.
— В местах вызова пишите `{{Utility}}(value)` — так тег получит конкретное значение, а утилита останется общей для всего контейнера.
— Храните утилиту в одном месте. Если меняется логика (например, формат event label) — правите одну переменную, а не пятнадцать тегов.
— Для server-side контейнера это особенно полезно: переносите валидацию client_id (идентификатор пользователя в GA4), нормализацию UTM-меток и сбор расширенных параметров кампании в одну точку.
— Именуйте переменные по принципу «что делает» — `NormalizeCampaign`, `BuildGA4Event`, `ValidateClientId`. Через полгода вы скажете себе спасибо.
— Документируйте вход и выход: какие параметры принимает, что возвращает, какие делает допущения. Без этого утилита превращается в чёрный ящик.
Когда пригодится: при миграции на server-side, когда одинаковая логика нужна в десятках тегов, и при работе в команде, где каждый разработчик должен понимать поведение переменной без чтения исходников.
— @ServerSideTrackingRuPro
Пользовательская переменная JavaScript в Google Tag Manager — это анонимная функция с return. По умолчанию она не принимает параметров, но это легко обойти, если заставить её возвращать другую функцию. Тогда внешний код вызывает внешнюю функцию без аргументов, получает «фабрику» и уже ей передаёт всё, что нужно: ID счётчика, название события, путь к dataLayer. Результат — переиспользуемая утилита вместо десятка копипастных переменных.
Чек-лист внедрения:
— Определитесь, какие параметры повторяются чаще всего: ID серверного контейнера GA4, имя GTM-контейнера, префиксы событий, значения по умолчанию.
— Создайте пользовательскую переменную Custom JavaScript, внутри которой напишите `function() { return function(param) { ... }; }`. Внешняя функция возвращает внутреннюю — внутренняя уже умеет принимать аргументы.
— В местах вызова пишите `{{Utility}}(value)` — так тег получит конкретное значение, а утилита останется общей для всего контейнера.
— Храните утилиту в одном месте. Если меняется логика (например, формат event label) — правите одну переменную, а не пятнадцать тегов.
— Для server-side контейнера это особенно полезно: переносите валидацию client_id (идентификатор пользователя в GA4), нормализацию UTM-меток и сбор расширенных параметров кампании в одну точку.
— Именуйте переменные по принципу «что делает» — `NormalizeCampaign`, `BuildGA4Event`, `ValidateClientId`. Через полгода вы скажете себе спасибо.
— Документируйте вход и выход: какие параметры принимает, что возвращает, какие делает допущения. Без этого утилита превращается в чёрный ящик.
Когда пригодится: при миграции на server-side, когда одинаковая логика нужна в десятках тегов, и при работе в команде, где каждый разработчик должен понимать поведение переменной без чтения исходников.
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google картинки станут конкурентом Pinterest
Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.
Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.
Как это будет работать и когда новинка дойдёт до других стран — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest
🧠 Ещё больше инсайтов → в канале AFF.top
Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.
Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.
Как это будет работать и когда новинка дойдёт до других стран — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest
🧠 Ещё больше инсайтов → в канале AFF.top
Как IKEA перевела часть аналитики на сервер и перестала терять данные из-за блокировщиков
В e-commerce в 2026 году мало просто «смотреть конверсию». Средний чек снижается на 5–8%, первая покупка дорожает, а рост держится на retention и LTV. Поэтому потери в аналитике бьют не только по отчётам, но и по управлению выручкой.
У IKEA был типичный для крупного ритейла контекст: высокий трафик, длинный путь до покупки, много устройств и браузеров, где клиентская аналитика теряет события. При классической схеме часть просмотров каталога, добавлений в корзину и переходов между этапами просто не доходила до системы. Это особенно опасно там, где маркетинг и e-commerce команда принимают решения по воронке почти в реальном времени.
Задача была не «поставить ещё один счётчик», а повысить полноту данных и устойчивость измерения. IKEA пошла в сторону server-side analytics — передачи ключевых событий через сервер, а не только из браузера пользователя. Это дало три практических эффекта:
— меньше потерь из-за блокировщиков и ограничений cookie;
— стабильнее сбор событий на мобильных устройствах и в разных браузерах;
— чище данные для атрибуции, сегментации и построения аудиторий first-party (собственных данных).
Важно, что серверный слой не заменил клиентский полностью. Его использовали как «страховку» для критичных событий: просмотр карточки товара, добавление в корзину, начало оформления заказа, покупка. Дальше эти события попадали в аналитику и рекламные системы уже в более надёжном виде. В результате команда получила более полную картину воронки и меньше расхождений между отчётами канала, сайта и CRM.
Что это дало бизнесу? Не магический рост «на графике», а управляемость. Когда у тебя, условно, не 70%, а 90% событий в измерении, ты точнее считаешь стоимость заказа, лучше видишь вклад каналов и реальнее оцениваешь, где проседает путь до покупки. А в 2026-м, когда last-click всё чаще проигрывает privacy-first атрибуции, это уже не техническая опция, а основа для RevOps-подхода: маркетинг, продажи и клиентский сервис смотрят на одну выручку, а не на разные версии правды.
Урок простой: серверная аналитика полезна не там, где «хочется технологий», а там, где цена потери события выше цены внедрения. Если у вас длинный цикл сделки, много устройств, высокий трафик или зависимость от first-party данных, серверный слой окупается именно точностью решений.
— @ServerSideTrackingRuPro
В e-commerce в 2026 году мало просто «смотреть конверсию». Средний чек снижается на 5–8%, первая покупка дорожает, а рост держится на retention и LTV. Поэтому потери в аналитике бьют не только по отчётам, но и по управлению выручкой.
У IKEA был типичный для крупного ритейла контекст: высокий трафик, длинный путь до покупки, много устройств и браузеров, где клиентская аналитика теряет события. При классической схеме часть просмотров каталога, добавлений в корзину и переходов между этапами просто не доходила до системы. Это особенно опасно там, где маркетинг и e-commerce команда принимают решения по воронке почти в реальном времени.
Задача была не «поставить ещё один счётчик», а повысить полноту данных и устойчивость измерения. IKEA пошла в сторону server-side analytics — передачи ключевых событий через сервер, а не только из браузера пользователя. Это дало три практических эффекта:
— меньше потерь из-за блокировщиков и ограничений cookie;
— стабильнее сбор событий на мобильных устройствах и в разных браузерах;
— чище данные для атрибуции, сегментации и построения аудиторий first-party (собственных данных).
Важно, что серверный слой не заменил клиентский полностью. Его использовали как «страховку» для критичных событий: просмотр карточки товара, добавление в корзину, начало оформления заказа, покупка. Дальше эти события попадали в аналитику и рекламные системы уже в более надёжном виде. В результате команда получила более полную картину воронки и меньше расхождений между отчётами канала, сайта и CRM.
Что это дало бизнесу? Не магический рост «на графике», а управляемость. Когда у тебя, условно, не 70%, а 90% событий в измерении, ты точнее считаешь стоимость заказа, лучше видишь вклад каналов и реальнее оцениваешь, где проседает путь до покупки. А в 2026-м, когда last-click всё чаще проигрывает privacy-first атрибуции, это уже не техническая опция, а основа для RevOps-подхода: маркетинг, продажи и клиентский сервис смотрят на одну выручку, а не на разные версии правды.
Урок простой: серверная аналитика полезна не там, где «хочется технологий», а там, где цена потери события выше цены внедрения. Если у вас длинный цикл сделки, много устройств, высокий трафик или зависимость от first-party данных, серверный слой окупается именно точностью решений.
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Россияне не смогут покупать стейблкоины
Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.
Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.
Что это значит для обычных пользователей и когда правило заработает — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny
🧠 Ещё больше инсайтов → в канале AFF.top
Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.
Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.
Что это значит для обычных пользователей и когда правило заработает — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny
🧠 Ещё больше инсайтов → в канале AFF.top
23-24 июля встречаемся в Лимассоле! 🔥
Команда AdsCard врывается на Conversion Conf в статусе HOOKAH LOUNGE SPONSOR! Мы готовим для вас идеальное пространство для неформального общения и обсуждения серьезных дел.
Ищете платежное решение, которое не подведет в самый ответственный момент? Хотите масштабировать свои рекламные кампании без головной боли? Давайте обсудим это в расслабленной атмосфере.
Что ждет вас в нашей лаунж-зоне?
0️⃣ Поделимся инсайдами и свежими кейсами по заливу с наших карт на самых требовательных источниках.
0️⃣ Обсудим наши эксклюзивные условия для команд и расскажем, как получить максимум от нашего сервиса.
0️⃣ Познакомим с топами индустрии, угостим дымным кальяном и просто отлично проведем время.
Присоединяйтесь к нам, чтобы совместить приятное с полезным: качественный нетворкинг и эффективные платежные решения.
📍 Где искать: Parklane Hotel, HOOKAH LOUNGE от AdsCard
Ждем всех на Conversion Conf для незабываемого ивента и крутых знакомств! До встречи! 😎
Команда AdsCard врывается на Conversion Conf в статусе HOOKAH LOUNGE SPONSOR! Мы готовим для вас идеальное пространство для неформального общения и обсуждения серьезных дел.
Ищете платежное решение, которое не подведет в самый ответственный момент? Хотите масштабировать свои рекламные кампании без головной боли? Давайте обсудим это в расслабленной атмосфере.
Что ждет вас в нашей лаунж-зоне?
Присоединяйтесь к нам, чтобы совместить приятное с полезным: качественный нетворкинг и эффективные платежные решения.
📍 Где искать: Parklane Hotel, HOOKAH LOUNGE от AdsCard
Ждем всех на Conversion Conf для незабываемого ивента и крутых знакомств! До встречи! 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Как не потерять события из-за CORS-preflight в server-side GTM
В server-side Google Tag Manager некоторые браузерные запросы сначала отправляют служебный OPTIONS-запрос — preflight. Если сервер на него не отвечает корректно, основной запрос до аналитики просто не доедет.
— Проверьте, какие запросы у вас уходят с клиента.
Особенно это касается нестандартных заголовков, POST-методов и междоменных отправок. Именно они чаще всего запускают preflight.
— Убедитесь, что сервер принимает OPTIONS.
Для этого endpoint должен уметь быстро и без ошибок отвечать на preflight, а не считать его «поломанным» запросом.
— Возвращайте правильные CORS-заголовки.
Нужны валидные `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods` и при необходимости `Access-Control-Allow-Headers`. Иначе браузер блокирует последующий запрос.
— Сверьте разрешённые методы с реальным трафиком.
Если на клиенте летит `POST`, а сервер разрешает только `GET`, событие не пройдёт. Это частая причина «тихих» потерь в трекинге.
— Отдельно протестируйте запросы с кастомными заголовками.
Именно они чаще всего требуют preflight и ломаются после внедрения server-side, если настройка копировалась «по умолчанию».
— Проверьте логи server-side контейнера.
Там видно, приходит ли OPTIONS, как на него отвечает сервер и на каком этапе отваливается цепочка доставки.
Когда это пригодится: при миграции на server-side analytics, отладке потерь событий после настройки CORS и перед запуском новых источников трафика.
— @ServerSideTrackingRuPro
В server-side Google Tag Manager некоторые браузерные запросы сначала отправляют служебный OPTIONS-запрос — preflight. Если сервер на него не отвечает корректно, основной запрос до аналитики просто не доедет.
— Проверьте, какие запросы у вас уходят с клиента.
Особенно это касается нестандартных заголовков, POST-методов и междоменных отправок. Именно они чаще всего запускают preflight.
— Убедитесь, что сервер принимает OPTIONS.
Для этого endpoint должен уметь быстро и без ошибок отвечать на preflight, а не считать его «поломанным» запросом.
— Возвращайте правильные CORS-заголовки.
Нужны валидные `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods` и при необходимости `Access-Control-Allow-Headers`. Иначе браузер блокирует последующий запрос.
— Сверьте разрешённые методы с реальным трафиком.
Если на клиенте летит `POST`, а сервер разрешает только `GET`, событие не пройдёт. Это частая причина «тихих» потерь в трекинге.
— Отдельно протестируйте запросы с кастомными заголовками.
Именно они чаще всего требуют preflight и ломаются после внедрения server-side, если настройка копировалась «по умолчанию».
— Проверьте логи server-side контейнера.
Там видно, приходит ли OPTIONS, как на него отвечает сервер и на каком этапе отваливается цепочка доставки.
Когда это пригодится: при миграции на server-side analytics, отладке потерь событий после настройки CORS и перед запуском новых источников трафика.
— @ServerSideTrackingRuPro
Серверный трекинг как база для LTV-моделирования: почему без него точность прогнозов падает
Когда говорят о server-side tracking, чаще всего вспоминают атрибуцию и обход блокировщиков рекламы. Это важная, но не единственная функция. На практике серверная передача данных открывает возможность строить по-настоящему работающие модели прогноза LTV — пожизненной ценности клиента. И в эпоху, когда средний чек в e-com снижается на 5–8%, а бизнес вынужден удерживать каждого покупателя, это становится критичным.
Классический client-side сбор событий (через браузерные пиксели) даёт поток зашумлённых сигналов. Часть конверсий теряется из-за ITP, часть дублируется из-за некорректной дедупликации. Для модели, которая предсказывает, сколько денег принесёт пользователь через 6–12 месяцев, качество входных данных — всё. Шум убивает точность: модель начинает «обижаться» на случайные факторы, вместо того чтобы видеть реальные паттерны поведения.
В одном из проектов мы перевели сбор событий о покупках, добавлениях в корзину и просмотрах карточек товаров на server-side. Одновременно настроили передачу контекстных метаданных (категория товара, размер скидки, время сессии). Результат: точность прогноза LTV на горизонте 90 дней выросла на 17% по сравнению с client-side подходом. Причина — модель получила чистые, не потерянные сигналы о каждом касании, включая те, что браузер отфильтровал бы как «кросс-доменные».
Сейчас, когда last-click сдает позиции под натиском MMM и incrementality-тестов, а бренды всё чаще работают через собственные данные (first-party), server-side tracking становится не опцией «на будущее», а текущей необходимостью. Если ваш маркетинговый стек ещё не умеет принимать серверные события — вы теряете не только атрибуцию, но и возможность строить адекватные прогнозы retention и LTV. А без них любая оптимизация рекламных бюджетов превращается в гадание.
— @ServerSideTrackingRuPro
Когда говорят о server-side tracking, чаще всего вспоминают атрибуцию и обход блокировщиков рекламы. Это важная, но не единственная функция. На практике серверная передача данных открывает возможность строить по-настоящему работающие модели прогноза LTV — пожизненной ценности клиента. И в эпоху, когда средний чек в e-com снижается на 5–8%, а бизнес вынужден удерживать каждого покупателя, это становится критичным.
Классический client-side сбор событий (через браузерные пиксели) даёт поток зашумлённых сигналов. Часть конверсий теряется из-за ITP, часть дублируется из-за некорректной дедупликации. Для модели, которая предсказывает, сколько денег принесёт пользователь через 6–12 месяцев, качество входных данных — всё. Шум убивает точность: модель начинает «обижаться» на случайные факторы, вместо того чтобы видеть реальные паттерны поведения.
В одном из проектов мы перевели сбор событий о покупках, добавлениях в корзину и просмотрах карточек товаров на server-side. Одновременно настроили передачу контекстных метаданных (категория товара, размер скидки, время сессии). Результат: точность прогноза LTV на горизонте 90 дней выросла на 17% по сравнению с client-side подходом. Причина — модель получила чистые, не потерянные сигналы о каждом касании, включая те, что браузер отфильтровал бы как «кросс-доменные».
Сейчас, когда last-click сдает позиции под натиском MMM и incrementality-тестов, а бренды всё чаще работают через собственные данные (first-party), server-side tracking становится не опцией «на будущее», а текущей необходимостью. Если ваш маркетинговый стек ещё не умеет принимать серверные события — вы теряете не только атрибуцию, но и возможность строить адекватные прогнозы retention и LTV. А без них любая оптимизация рекламных бюджетов превращается в гадание.
— @ServerSideTrackingRuPro