Как 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
Forwarded from AffPapa! Клуб спящих бизнесменов! Потрачено!
МАККГРЕГОР! Не только лишь одни синие как оказалось умееют играть в амбасадоров :-) Если вы понимаете
Суть простая, Мак Грегор хуйнул ставочку, и вроде бы хуйня, но все мы понимаем что это значит и это работает на всех нас!
Амбассадор 1xBet сделал прогноз на $100 000 на точный счет финала WCMUC2026: Испания v Аргентина – 2:3. Коэффициент – 36. Потенциальный выигрыш – $3,6 миллиона! На мой взгляд вообще похуй какой именно прогноз он сделал, тут важен сам факт, это без проблем используется во всех крео!
Думаю не надо объяснять что Конор это пиздец какой триггер для игроков и соц. пруф! Самый известный спортсмен мира сделал прогноз на главный матч года, а значит миллионы болельщиков будут следить не только за финалом, но и за его выбором. Используй этот инфоповод, чтобы подтолкнуть аудиторию к собственному прогнозу!
В финале WCMUC2026 победитель будет только один, а вот в борьбе за трафик может победить каждый и урвать свой кусок! Используй, хули сидеть!
Тыкай, там интиресно!
Суть простая, Мак Грегор хуйнул ставочку, и вроде бы хуйня, но все мы понимаем что это значит и это работает на всех нас!
Амбассадор 1xBet сделал прогноз на $100 000 на точный счет финала WCMUC2026: Испания v Аргентина – 2:3. Коэффициент – 36. Потенциальный выигрыш – $3,6 миллиона! На мой взгляд вообще похуй какой именно прогноз он сделал, тут важен сам факт, это без проблем используется во всех крео!
Думаю не надо объяснять что Конор это пиздец какой триггер для игроков и соц. пруф! Самый известный спортсмен мира сделал прогноз на главный матч года, а значит миллионы болельщиков будут следить не только за финалом, но и за его выбором. Используй этот инфоповод, чтобы подтолкнуть аудиторию к собственному прогнозу!
В финале WCMUC2026 победитель будет только один, а вот в борьбе за трафик может победить каждый и урвать свой кусок! Используй, хули сидеть!
Тыкай, там интиресно!
Nike и «пропавшие» конверсии: как мы починили full-funnel атрибуцию через server-side events
В 2025 году Nike начал масштабировать кампании на новые сегменты, но в отчетности маркетинг стал видеть неприятную картину: часть конверсий «тонко» расходилась между рекламными платформами и внутренней аналитикой. Раньше расхождения списывали на погрешность пикселей и антибот-логику. Но когда падение совпало по времени с ростом рекламного бюджета, стало ясно: проблема не в креативе, а в данных.
Контекст
Эпоха 2026 бьет по last-click — модели все больше уходят в privacy-first измерения. Когда вы переходите на новые браузерные ограничения, блокировки и «zero-click» поиск, серверные события становятся не «улучшением», а фундаментом. В Nike параллельно усиливали retention-подход: измерять нужно было не только первую покупку, но и повторные заказы, подписки на сервисы, а также возвраты (как источник качества сегмента).
Задача
Нужно было:
— восстановить сопоставимость данных между рекламными витринами и аналитикой сайта/app
— корректно считать события, влияющие на RevOps-метрики (выручка и путь до повторной покупки), а не только lead/checkout
— внедрить first-party трекинг так, чтобы выдерживать блокировки и изменения в клиентах
Решение
1) Перенесли ключевые события на server-side. Клиент отправлял в браузер/приложение минимум: идентификатор сессии + параметры события. Дальше события подписывались на сервере и уходили в аналитическую систему и в места назначения в уже «чистом» виде.
2) Разрулили дедупликацию. Самая частая ошибка при миграциях: дубль события из-за одновременной отправки с клиента и с сервера. Мы ввели единый event-id и правило приоритета (серверный — истинный).
3) Починили сопоставление пользователей. Мы использовали first-party cookie и app-instance id, плюс матчили пользователя через salted-хэши (без хранения лишних данных). Это позволило связать визит → добавление в корзину → покупку → повтор.
4) Добавили контроль качества данных. Для каждого события ввели SLA на доставку и валидацию полей (currency, value, item_id, путь страницы). Когда поле пустое или тип невалиден — событие логируется как «degraded», но не портит отчет.
Результат
После внедрения в течение двух недель:
— доля «неподтвержденных» конверсий снизилась на 31% (по внутренним сопоставлениям с заказами)
— расхождения между внутренней выручкой и витринной атрибуцией сократились с ~12–15% до ~4–6%
— в сегментах, где раньше «проваливали» repeat, стало видно реальное влияние кампаний: прирост повторных покупок в атрибутируемых когортах составил **+8%** к контрольной группе по инкрементальности (incrementality-подход, сравнение с удержанием маркетингового воздействия)
— маркетинг смог быстрее пересобирать гипотезы: цикл оптимизации сократился с недель до дней за счет стабильных событий
Урок
1) Если цифры «плывут», не начинайте с креатива. Начинайте с цепочки данных: где событие теряется, дублируется или искажается.
2) Server-side — это не «перенос пикселя», а управление качеством события: дедуп, схемы полей, идентификаторы и контроль доставки.
3) В 2026 маркетинг отвечает за выручку вместе с RevOps, поэтому аналитика должна поддерживать не только funnel до первой покупки, но и повтор и возвраты. Иначе вы оптимизируете не то.
Если хотите, разберу типовую схему миграции (что переносить первым, как вводить event-id и какие поля обязательно стандартизировать), на примере вашего stack: web+app+CRM.
— @ServerSideTrackingRuPro
В 2025 году Nike начал масштабировать кампании на новые сегменты, но в отчетности маркетинг стал видеть неприятную картину: часть конверсий «тонко» расходилась между рекламными платформами и внутренней аналитикой. Раньше расхождения списывали на погрешность пикселей и антибот-логику. Но когда падение совпало по времени с ростом рекламного бюджета, стало ясно: проблема не в креативе, а в данных.
Контекст
Эпоха 2026 бьет по last-click — модели все больше уходят в privacy-first измерения. Когда вы переходите на новые браузерные ограничения, блокировки и «zero-click» поиск, серверные события становятся не «улучшением», а фундаментом. В Nike параллельно усиливали retention-подход: измерять нужно было не только первую покупку, но и повторные заказы, подписки на сервисы, а также возвраты (как источник качества сегмента).
Задача
Нужно было:
— восстановить сопоставимость данных между рекламными витринами и аналитикой сайта/app
— корректно считать события, влияющие на RevOps-метрики (выручка и путь до повторной покупки), а не только lead/checkout
— внедрить first-party трекинг так, чтобы выдерживать блокировки и изменения в клиентах
Решение
1) Перенесли ключевые события на server-side. Клиент отправлял в браузер/приложение минимум: идентификатор сессии + параметры события. Дальше события подписывались на сервере и уходили в аналитическую систему и в места назначения в уже «чистом» виде.
2) Разрулили дедупликацию. Самая частая ошибка при миграциях: дубль события из-за одновременной отправки с клиента и с сервера. Мы ввели единый event-id и правило приоритета (серверный — истинный).
3) Починили сопоставление пользователей. Мы использовали first-party cookie и app-instance id, плюс матчили пользователя через salted-хэши (без хранения лишних данных). Это позволило связать визит → добавление в корзину → покупку → повтор.
4) Добавили контроль качества данных. Для каждого события ввели SLA на доставку и валидацию полей (currency, value, item_id, путь страницы). Когда поле пустое или тип невалиден — событие логируется как «degraded», но не портит отчет.
Результат
После внедрения в течение двух недель:
— доля «неподтвержденных» конверсий снизилась на 31% (по внутренним сопоставлениям с заказами)
— расхождения между внутренней выручкой и витринной атрибуцией сократились с ~12–15% до ~4–6%
— в сегментах, где раньше «проваливали» repeat, стало видно реальное влияние кампаний: прирост повторных покупок в атрибутируемых когортах составил **+8%** к контрольной группе по инкрементальности (incrementality-подход, сравнение с удержанием маркетингового воздействия)
— маркетинг смог быстрее пересобирать гипотезы: цикл оптимизации сократился с недель до дней за счет стабильных событий
Урок
1) Если цифры «плывут», не начинайте с креатива. Начинайте с цепочки данных: где событие теряется, дублируется или искажается.
2) Server-side — это не «перенос пикселя», а управление качеством события: дедуп, схемы полей, идентификаторы и контроль доставки.
3) В 2026 маркетинг отвечает за выручку вместе с RevOps, поэтому аналитика должна поддерживать не только funnel до первой покупки, но и повтор и возвраты. Иначе вы оптимизируете не то.
Если хотите, разберу типовую схему миграции (что переносить первым, как вводить event-id и какие поля обязательно стандартизировать), на примере вашего stack: web+app+CRM.
— @ServerSideTrackingRuPro
Forwarded from Я ЗЛОЙ, Я ГАНГСТА
Когда AffPapa попытались кикнуть Иванова из сферы, другие компании скинули ему $100к.
Как мы обсуждали вчера, овнер AffPapa взбесился на ЕЮ и пригрозил аффилке: AffPapa прекратят все формы сотрудничества с компаниями-партнёрами Иванова. Логика простая: мне приносит неудобства этот чел, значит, я сделаю так, чтобы с ним никто больше не работал, тем самым вытеснив его из сферы.
Будь это кто-то другой, идея, может, и сработала бы, но мы говорим о ЕЮ, который тут же понял кипиш. В ответ Алексеев закинул ему $5к с комментом «Кайфуй», а дальше к этому недо-флэшмобу подтянулись другие компании: $25к от Roi Media, $15к от TopX, $10к от GloryPartners, $7.5к от неизвестного Эдуарда, $7.5к от Кардиналов, $5.5к от некого Владимира. И вишенка на торте — $50к от «влиятельной iGaming фигуры, пожелавшей остаться анонимной».
Овнер AffPapa тем временем выдал жиденький ответ на ситуацию: они «не хотят ассоциироваться с брендами, поддерживающими площадки, построенные на срачах», но это не значит, что они прекращают сотрудничество со всеми вышеперечисленными конторами. Иначе говоря, чел понял, что не на того наехал, и быстро переобулся — у него тупо не было другого выбора.
🥴 — чего и следовало ожидать
🍾 — поздравляем ЕЮ с неожиданной премией )0
😈 Я ЗЛОЙ, Я ГАНГСТА
Как мы обсуждали вчера, овнер AffPapa взбесился на ЕЮ и пригрозил аффилке: AffPapa прекратят все формы сотрудничества с компаниями-партнёрами Иванова. Логика простая: мне приносит неудобства этот чел, значит, я сделаю так, чтобы с ним никто больше не работал, тем самым вытеснив его из сферы.
Будь это кто-то другой, идея, может, и сработала бы, но мы говорим о ЕЮ, который тут же понял кипиш. В ответ Алексеев закинул ему $5к с комментом «Кайфуй», а дальше к этому недо-флэшмобу подтянулись другие компании: $25к от Roi Media, $15к от TopX, $10к от GloryPartners, $7.5к от неизвестного Эдуарда, $7.5к от Кардиналов, $5.5к от некого Владимира. И вишенка на торте — $50к от «влиятельной iGaming фигуры, пожелавшей остаться анонимной».
Овнер AffPapa тем временем выдал жиденький ответ на ситуацию: они «не хотят ассоциироваться с брендами, поддерживающими площадки, построенные на срачах», но это не значит, что они прекращают сотрудничество со всеми вышеперечисленными конторами. Иначе говоря, чел понял, что не на того наехал, и быстро переобулся — у него тупо не было другого выбора.
🥴 — чего и следовало ожидать
🍾 — поздравляем ЕЮ с неожиданной премией )0
🎣Лей Fishing Time на TopX, участвуй в раздаче 1kk$ среди баеров и команд! Стань серьёзной iGaming-фигурой! 😎 Подробности ТУТ
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from high profit — low life
Маэстро снова всех переиграл - будто по нотам блестяще выступил и остался с деньгами и респектом улиц
Че было?
Кто-то вспомнил про сообщество Affpapa - кто конкретно такие и чем занимаются кроме организации местечковых митапов, я не ебу, но пафоса как всегда много - доступ к серьезным iGaming фигурам у них только по подписке за 2100 евриков.
ЕЮ купил доступ и предложил поделиться им за шекели со всеми желающими - казалось бы нихуя нового под арбитражной луной, купить базу любой партнерки или сообщества проще чем щелкнуть пальцами.
Но обиженный владелец папки пошел плакать в линкедине на тему того «какжи так, никогда такого не было и вот опять».
Также он пообещал всем брендам так или иначе связанным с Юрьичем (то есть 90% СНГ рынка) закрытие доступа к аффпапе и немедленное прекращение сотрудничества.
После этого ситуация плавно перетекла в iGaming Chat, где пошла настоящая возня - вместо НЕМЕДЛЕННОГО РАЗРЫВА С ОПОРОЧИВШИМ ИМЯ АФФПАПЫ, бренды предпочли поддержать Евгения вечнозелеными долларами и накидали ему под сто косых на ход ноги и новый контент, засветились PVT, Roimedia, Кардиналы, TopX и Glory, а также несколько анонимных iGaming-фигур.
Дальше - больше, обиженный владелец Аффпапки выступил с уже более жидкими заявлениями о том, что его не так поняли и что прекращать сотрудничество ни с кем пока не будут, просто советуют быть аккуратнее и бла-бла-бла.
Собственно, понятно что без топовых брендов, которые в том числе оплачивают существование Аффпапы вряд ли оно сможет фунциклировать.
Как и любой медийный конфликт - этот Евгений Юрьевич выиграл в одну калитку, прямо как Испания Аргентину вчера.
Мораль?
Не пиздите на маэстро.
High Profit — Low Life | Прислать сплетню
Че было?
Кто-то вспомнил про сообщество Affpapa - кто конкретно такие и чем занимаются кроме организации местечковых митапов, я не ебу, но пафоса как всегда много - доступ к серьезным iGaming фигурам у них только по подписке за 2100 евриков.
ЕЮ купил доступ и предложил поделиться им за шекели со всеми желающими - казалось бы нихуя нового под арбитражной луной, купить базу любой партнерки или сообщества проще чем щелкнуть пальцами.
Но обиженный владелец папки пошел плакать в линкедине на тему того «какжи так, никогда такого не было и вот опять».
Также он пообещал всем брендам так или иначе связанным с Юрьичем (то есть 90% СНГ рынка) закрытие доступа к аффпапе и немедленное прекращение сотрудничества.
После этого ситуация плавно перетекла в iGaming Chat, где пошла настоящая возня - вместо НЕМЕДЛЕННОГО РАЗРЫВА С ОПОРОЧИВШИМ ИМЯ АФФПАПЫ, бренды предпочли поддержать Евгения вечнозелеными долларами и накидали ему под сто косых на ход ноги и новый контент, засветились PVT, Roimedia, Кардиналы, TopX и Glory, а также несколько анонимных iGaming-фигур.
Дальше - больше, обиженный владелец Аффпапки выступил с уже более жидкими заявлениями о том, что его не так поняли и что прекращать сотрудничество ни с кем пока не будут, просто советуют быть аккуратнее и бла-бла-бла.
Собственно, понятно что без топовых брендов, которые в том числе оплачивают существование Аффпапы вряд ли оно сможет фунциклировать.
Как и любой медийный конфликт - этот Евгений Юрьевич выиграл в одну калитку, прямо как Испания Аргентину вчера.
Мораль?
Не пиздите на маэстро.
High Profit — Low Life | Прислать сплетню
Серверная аналитика перестала быть «дополнением» к вебу
В 2026 это уже не про модный стек, а про выживание в privacy-first среде. Когда last-click всё хуже объясняет выручку, а часть трафика просто не доезжает в клиентские пиксели, серверный слой становится базой для нормальной атрибуции. И здесь важен не сам факт передачи событий, а то, что бизнес наконец начинает смотреть на данные как на актив, а не как на отчёт в кабинете.
— @ServerSideTrackingRuPro
В 2026 это уже не про модный стек, а про выживание в privacy-first среде. Когда last-click всё хуже объясняет выручку, а часть трафика просто не доезжает в клиентские пиксели, серверный слой становится базой для нормальной атрибуции. И здесь важен не сам факт передачи событий, а то, что бизнес наконец начинает смотреть на данные как на актив, а не как на отчёт в кабинете.
— @ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
X перезапустил прилу на Android
X.com не просто обновила приложение, а фактически пересобрала его вокруг скорости и синхронного запуска фич с iOS. Для арбитража это сигнал снова тестировать X Ads и УБТ-связки: платформа уходит от старого формата коротких постов к видео и стримам, а значит меняются охваты, креативы и точки входа в трафик.
➡️ Читайте на сайте: https://aff.top/blog/x-perezapustil-prilu-na-android
🧠 Ещё больше инсайтов → в канале AFF.top
X.com не просто обновила приложение, а фактически пересобрала его вокруг скорости и синхронного запуска фич с iOS. Для арбитража это сигнал снова тестировать X Ads и УБТ-связки: платформа уходит от старого формата коротких постов к видео и стримам, а значит меняются охваты, креативы и точки входа в трафик.
➡️ Читайте на сайте: https://aff.top/blog/x-perezapustil-prilu-na-android
🧠 Ещё больше инсайтов → в канале AFF.top