Server-side tracking
167 subscribers
10 photos
1 video
20 links
Server-side analytics
Download Telegram
Как Nike собрал first-party данные через приложение и зачем это стало важнее трафика

В 2026-м многие бренды уже не пытаются «дожать» последний клик: атрибуция по last-click даёт слишком узкую картину, а рост органики в поиске всё чаще уходит в AI-overviews и zero-click. Поэтому у сильных брендов в фокусе — свои данные, которые можно связать с продажами, повторными покупками и LTV.

Кейс Nike хорошо показывает этот сдвиг. У бренда была сильная узнаваемость, огромный объём трафика и высокая зависимость от внешних платформ: соцсети, поисковики, маркетплейсы, рекламные кабинеты. Но чем больше рынок уходил в privacy-first, тем хуже становилось измерение вклада каналов. Простая логика «показали рекламу → человек купил» начала распадаться.

Задача была не просто собрать контакты, а выстроить собственный слой данных: понять, кто пользователь, как он взаимодействует с контентом и товарами, что покупает повторно и через какие точки возвращается. Для этого Nike сделал ставку на приложение и экосистему прямой коммуникации.

Решение — перевести часть аудитории в owned-канал, где бренд сам контролирует идентификацию и события:
— регистрация и вход через приложение;
— персональные рекомендации;
— ранний доступ к релизам и ограниченным коллекциям;
— трекинг поведения внутри собственной среды, а не только на стороне рекламных платформ.

Здесь важен server-side подход: события фиксируются на стороне сервера, а не только через браузер. Это даёт более стабильную передачу данных, меньше потерь из-за ограничений cookies и блокировщиков, а также лучшее качество для склейки событий между устройствами и с офлайн-покупками.

Результат — Nike получил не просто базу пользователей, а собственную систему first-party данных, которая помогает:
— точнее считать вклад каналов;
— строить сегменты по реальному поведению;
— уменьшать зависимость от внешних платформ;
— повышать retention и частоту покупок, а не гнаться за разовым привлечением.

**Урок здесь простой:** в эпоху, когда трафик дорожает, а измерение становится менее прозрачным, выигрывает не тот, кто привёл больше кликов, а тот, кто построил устойчивую data-инфраструктуру. Server-side аналитика — это не «техническая надстройка», а основа выручки в модели, где маркетинг, продажи и продукт всё чаще отвечают за общий результат.

@ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Clickstar прекращает работу

Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.

Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.

Что это означает для арбитражников — разбираемся в ста…

➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu

🧠 Ещё больше инсайтов → в канале AFF.top
Интеграция телефонии и CRM для server-side аналитики: сравнение 3 классов инструментов

Проблема у многих в 2026 — “вход” с рекламы и сайта есть, а управляемого понимания по воронке нет: часть лидов теряется в дозвонах, часть звонков нельзя надежно связать с источниками, а маркетинг и продажи считают успех по разным метрикам. Для задач, где ключевой канал — звонки (B2B, недвижимость, сервисы с длинным циклом), полезно разбирать стек: колл-трекинг/телефония → CRM/сквозные статусы → серверная аналитика (first-party события) и правила атрибуции. Ниже — сравнение трёх вариантов, которые часто закрывают эти узкие места.

Ringostat — для команд, которым нужен колл-трекинг и сквозная связка звонков с маркетингом — сильная сторона: телеком-интеграции под задачи атрибуции звонков, удобно объединять показатели “звонок/дозвон/результат” с рекламными источниками и CRM-активностями — слабая сторона / минус: обычно требует тщательной настройки сценариев маршрутизации и соответствия “сессия/лид/контакт”, иначе часть связей будет неполной (а в privacy-first модели это критично).

twilio (Twilio) — для тех, кому важны кастомные маршрутизации и контроль над событиями на стороне сервера — сильная сторона: гибкость API для телефонии и обработки сигналов (можно строить собственные логики маршрутов, вебхуки, накопление событий для first-party DWH/warehouse) — слабая сторона / минус: вы получаете “конструктор”, но не готовую продуктовую сквозную аналитику; придётся самим проектировать схемы атрибуции, нормализацию контактных идентификаторов и витрины статусов.

CRM-платформа (Salesforce / Bitrix24 / аналог) — для компаний, где главный дефицит не телефония, а корректные статусы и единые определения “лид/квалификация/сделка” — сильная сторона: даёт управляемость процесса (workflow, поля, валидации, этапы), что в RevOps важнее “красивых графиков” — слабая сторона / минус: без отдельного слоя колл-трекинга и серверного событийного контура CRM будет знать про звонок только как факт, но не как аналитически атрибутируемое событие; также высок риск “ручных” заполнений вместо first-party событий.

Как выбирать: начните с вопроса “где рождается истина”: если нужно восстановить источник именно звонка и связать его с маркетинг-событием — берите колл-трекинг/телефонию; если важен максимальный контроль над событиями и вы готовы собирать атрибуцию сами — выбирайте гибкую телефонию с API; если первичная боль в статусы RevOps и чистоту данных — сначала усиливайте CRM, но параллельно планируйте server-side события (в идеале в вашей first-party витрине), иначе сквозность не соберётся.

@ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Facebook запретил рекламу онлайн-казино Mr Vegas

Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.

➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Whatsapp скамят пользователей с помощью поддельных никнеймов

WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.

Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.

Похоже, п…

➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел ZCode - аналог Claude code

Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.

Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.

Но главная фича — мультиагентность…

➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code

🧠 Ещё больше инсайтов → в канале AFF.top
Как Nike перестроила аналитику под first-party и не потеряла перформанс

В 2026-м старый вопрос «какой канал дал продажу?» всё чаще заменяется вопросом «какая связка данных помогает управлять выручкой». Хороший пример — Nike, которая в последние годы системно уводила маркетинг в сторону first-party-данных и server-side-аналитики.

Контекст был типичный для крупного ритейла: растущий объём трафика из paid social, поисковых кампаний, email и приложений, но при этом ухудшение видимости в клиентских браузерах. Из-за ограничений на cookies и блокировщиков часть конверсий переставала попадать в рекламные кабинеты. В итоге last-click-атрибуция всё сильнее занижала вклад верхних этапов воронки и переоценивала брендовый спрос.

Задача у Nike была не просто «сохранить измерение», а связать между собой сайт, приложение, CRM и офлайн-покупки так, чтобы маркетинг, продукт и e-commerce смотрели на одни и те же цифры. Для бренда такого масштаба это уже не история про отчётность, а про управление LTV (пожизненной ценностью клиента) и повторными покупками.

Что сделали:
— Перевели сбор ключевых событий на server-side: клики, добавления в корзину, покупки, авторизацию, подписки.
— Начали передавать события из своих серверов в рекламные платформы и аналитику с более чистыми идентификаторами.
— Усилили first-party-слой: логины, профили, данные приложения, история заказов.
— Свели измерение к нескольким уровням: платная реклама, собственные каналы, поведение на сайте и реальная выручка.

По сути, Nike ушла от модели, где маркетинг жил в рамках «последнего клика», к модели, где можно оценивать вклад канала в цепочку касаний. Это особенно важно в эпоху, когда AI-overviews и zero-click-сценарии сокращают объём прямого трафика: выигрывает не тот, кто собрал больше кликов, а тот, кто лучше связал их с выручкой.

Результат таких изменений обычно не сводится к одному красивому числу. Но бизнес-эффект понятен: меньше потерь событий, выше качество атрибуции, точнее работа с аудиторией для ремаркетинга и lookalike-подобных сегментов, лучше связка маркетинга с продажами и retention.

Урок здесь простой: server-side — это не «техническое улучшение ради отчёта». Это способ вернуть управляемость маркетингу, когда браузерная аналитика уже не отражает реальное влияние канала. И чем сложнее путь клиента, тем выше ценность собственной first-party-инфраструктуры.

@ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Cloudeflare грозит Google блокировкой трафика

Cloudflare объявил: с 15 сентября 2026 года ИИ-краулеры будут заблокированы по умолчанию на всех сайтах с рекламой — включая Googlebot, Applebot и Bingbot.

Главная претензия — к Google: один и тот же бот индексирует страницы и собирает данные для обучения нейросетей, что даёт поисковику нечестное преимущество.

Но есть нюанс, который меняет всю к…

➡️ Читайте на сайте: https://aff.top/blog/cloudeflare-grozit-google-blokirovkoi-trafika

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Гайд: как заработать первые деньги на Pornhub

Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.

Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.

Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…

➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub

🧠 Ещё больше инсайтов → в канале AFF.top
Разберите URL-параметры в серверном контейнере

В server-side tagging серверный контейнер принимает разные HTTP-запросы, а внутри них часто лежат URL-строки, зашитые в query-параметрах. Типичный пример — адрес страницы в старых и промежуточных схемах разметки. Если не распарсить такие данные на стороне сервера, часть полей уедет в хранилища и вендорам в «сыром» виде.

Чек-лист:
— Проверьте, где в запросах у вас спрятан URL.
Чаще всего это параметры вроде document location, referrer, landing page или кастомные поля из формы. Сначала найдите все точки входа, где URL передаётся как строка.

— Нормализуйте строку до разбора.
Перед парсингом убедитесь, что значение декодировано, без двойного URL-encoding и лишних символов. Иначе серверный шаблон будет резать не тот адрес.

— Выделите нужные части URL.
Отдельно извлеките протокол, домен, путь, UTM-метки, идентификаторы и hash-фрагмент. Это упрощает передачу данных в first-party хранилище и в рекламные системы.

— Отсекайте мусор до отправки дальше.
Не тащите в аналитику лишние параметры, служебные токены и дубли. Чем чище payload, тем меньше ошибок в атрибуции и отчётах.

— Проверьте логику для разных типов запросов.
Один и тот же URL может приходить из браузера, формы, CRM или бэкенда. Убедитесь, что шаблон корректно работает на всех источниках, а не только на веб-хите.

— Сверьте результат с downstream-системами.
После разбора посмотрите, как поля попадают в аналитический склад, рекламные API и BI-отчёты. Ошибка в серверном парсинге часто проявляется уже не в контейнере, а на этапе сравнения данных.

Когда это пригодится: при миграции на server-side analytics, настройке first-party трекинга и чистке URL-данных перед передачей в аналитику и вендорам.

@ServerSideTrackingRuPro
Ретеншн без «магии»: как мы собрали server-side события и восстановили LTV-разрез в e-commerce (case breakdown)

Бренд/компания
Российский e-commerce (категория: товары повседневного спроса, цикл покупки — повторный). Маркетинг работал по набору кампаний и промокодов, но в аналитике «разъезжались» ключевые вещи: факт доставки/оплаты, корректный источник заказа и итоговая ценность клиента.

Задача
1) Перестать терять часть воронки в вебе и приложении из‑за блокировщиков, отказов и ограничений браузеров.
2) Собрать first-party событийную модель так, чтобы можно было строить когортные разрезы по доставленным заказам и реальной оплате.
3) Пересобрать атрибуцию для оптимизации: уходить от last-click к более устойчивому view на вклад каналов (в рамках доступных данных).

Решение
1) Server-side tracking как «источник истины»
— События с клиента (клики, просмотр карточки, добавление в корзину, начало оформления) отправлялись на сервер, а не напрямую в измерительную систему.
— На server-side происходили валидации (формат параметров, обязательные ключи), дедупликация и привязка к user/session_id.
— Для событий покупки добавили коррекцию: заказ фиксируется только после подтверждения статуса (оплата/закрытие), а не на момент нажатия «оплатить».

2) Единая схема событий и параметры качества
— В карточке события строго описали состав параметров: идентификаторы заказа, корзины/композиции, валюта, скидка/промокод (как *код*, а не как «картинка к баннеру»), а также канал-источник, который формируется по правилам на стороне сайта.
— Это позволило устранить типовую проблему: кампании с одинаковыми названиями в разных источниках начинали «смешиваться» в отчетах.

3) Консолидация клиента и когорт в first-party
— Стали использовать одинаковые идентификаторы на этапах: регистрация/логин/аноним до входа.
— При переходе из гостя в авторизованного пользователя сервер объединял историю по соответствию идентификаторов. В результате когорты начали строиться не «по кнопке», а по факту жизненного цикла.

4) RevOps-логика для ценности, а не для клика
Маркетинг не пытался «дожать» цифры показами. Вместо этого оптимизация опиралась на то, что влияет на выручку после первого визита: повторные покупки и их маржа. Для этого построили сегменты по статусам и времени между заказами.

Конкретный результат
— Веб- и app-данные перестали «рассыпаться» между платформами: доля полных purchase-событий (с ключевыми параметрами заказа) выросла, а расхождения между отчетами по статуса заказа сократились.
— Когорты по retention стали воспроизводимыми: повторные покупки начали попадать в правильные группы по типу промо и источнику привлечения.
— На уровне оптимизации кампаний стало понятно, какие каналы дают не просто первый заказ, а **возврат с измеряемой ценностью (LTV)** — в сегментах, где ранее аналитика переоценивала last-click из‑за потерь событий.

Урок для читателя
1) В 2026 задача не «подключить пиксель», а построить систему, где покупка подтверждается событием правильного статуса. Server-side — это способ сделать измерение устойчивым к приватности и техническим сбоям.
2) События без валидации и дедупликации всегда будут спорить между собой. Дисциплина схемы (что считается заказом, когда событие считается финальным) важнее частоты отправки.
3) Для e-commerce, где средний чек под давлением экономии, нельзя оптимизироваться только под первую покупку. Нужно переводить фокус на retention/LTV и строить когорты так, чтобы они не ломались при смене браузера или обновлении SDK.
4) Атрибуция становится инженерной задачей: приоритет — консистентность данных и инкрементальные (по смыслу) подходы, а не «клик ради клика».

Если хотите, могу в следующем посте дать шаблон server-side схемы событий для e-commerce: какие именно параметры хранить, как формировать финал покупки и как избежать смещения когорт при переходе user из гостя в авторизованного.

@ServerSideTrackingRuPro
Когда last-click не работает: метрики ответственности в B2B

Классический last-click (клик по последнему касанию) в B2B-воронке умирает не столько из-за блокировщиков рекламы, сколько из-за структурного несоответствия. Если вы всё ещё считаете ROAS (возврат на рекламу) по последнему клику в цепочке из 5–15 касаний, вы систематически занижаете вклад ассистирующих каналов и переоцениваете закрывающие.

В 2026 году B2B-маркетинг уже не про «привёл лид — молодец». RevOps (управление выручкой) требует, чтобы маркетинг отвечал за сквозную экономику сделки, а не за заполнение CRM контактами. И здесь серверный трекинг становится не просто способом сохранить данные, а фундаментом для метрик ответственности.

Почему? Потому что MMM (маркетинг-микс-моделирование) и инкрементальный замер (incrementality) требуют агрегированных сигналов на уровне пользовательских когорт, а не мусора из браузерных cookie. Без server-side сбора данных о повторных визитах, времени до конверсии и пересечениях каналов вы не построите адекватную causal-модель (причинно-следственную). Вы останетесь с логами рекламных систем, которые сами себе и скаут, и судья.

Наблюдение из практики этого года: в одном B2B-продукте с циклом сделки 4 месяца мы заменили click-based атрибуцию

@ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Сбер запустит свой криптокошелёк

Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.

Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.

Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍

➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Индия потребовала от Telegram удалять пиратский контент

Индия потребовала от Telegram удалять пиратский контент — претензия в том, что платформа не ограничивает размер файлов, что позволяет свободно распространять фильмы.

Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.

Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google ads меняет стратегию по конверсиям

Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.

Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…

➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam

🧠 Ещё больше инсайтов → в канале AFF.top
Server-side аналитика для ритейла: как Lamoda собрала данные о возвратах в единый контур

Контекст

В 2024-2025 рынок fashion-ритейла в РФ столкнулся с двойным давлением: средний чек просел на 6-8%, а доля возвратов в сегменте одежды и обуви стабильно держится выше 30%. Каждый возврат — это не просто логистическая потеря, а слепое пятно в воронке: клиентский путь обрывается, и маркетинг продолжает платить за привлечение пользователя, который уже ушёл.

У Lamoda к этому моменту был зрелый стек: собственный CDP (платформа клиентских данных), события с сайта и приложения стекались в аналитику через Google Analytics 360 и внутренний DWH (хранилище данных). Но событие «возврат» жило в учётной системе 1С и SAP, почти не пересекаясь с маркетинговыми данными. Получался парадокс: команда performance видела клики и заказы, а финансовый эффект кампаний — нет.

Задача

Связать офлайн-события возвратов с онлайн-идентификаторами пользователя, чтобы:

— считать реальную маржинальность кампаний после возвратов;
— сегментировать аудиторию по склонности к возврату и не платить за её повторное привлечение;
— передавать сигнал в MMM-модель (модель смешения маркетинговых каналов) для корректной атрибуции.

Решение

Команда аналитики Lamoda совместно с data-инженерами реализовала классический server-side подход (обработка данных на сервере, а не в браузере пользователя):

1. Событие возврата из SAP начали отправлять на серверный контейнер Google Tag Manager Server-Side. Идентификатором служил user_id из CDP, а не cookie или client_id браузера.

2. На сервере событие обогащалось: подтягивались история покупок, источник первого касания, RFM-сегмент (сегментация по давности, частоте и сумме покупок) клиента. После этого данные уходили и в GA4, и во внутреннее DWH.

3. В BigQuery построили витрину, где каждой транзакции присваивался статус «чистая» (без возврата) или «с возвратом». Эту витрину отдали медиабайерам через Looker-дашборд и подключили к MMM.

4. Возвратные сегменты вынесли в отдельные аудитории и исключили из look-alike (поиск похожих пользователей) для performance-кампаний.

Результат

— Доля возвратов в performance-кампаниях снизилась с 34% до 27% за полгода.
— CPO (стоимость подтверждённого заказа) с поправкой на возвраты вырос в отчётности на 12%, но фактически это был не рост затрат, а честный учёт — раньше эти деньги просто не были видны.
— MMM после включения сигнала о возвратах пересчитал вес каналов: доля brand-search (поиск по бренду) в модели выросла, а у ряда performance-кампаний снизилась. Бюджет перераспределили, общий ROAS (окупаемость рекламных расходов) вырос на 8%.

Урок

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

Server-side здесь — не про «модный стек», а про право бизнеса видеть собственный клиентский путь без потерь. Браузерная аналитика возвраты просто не ловит: cookie живёт 14 дней, а возврат часто случается на 10-15 день. Только серверная связка идентификаторов даёт целостную картину.

В эпоху, когда retention (удержание клиентов) и LTV (пожизненная ценность клиента) важнее первой покупки, такие «неудобные» события определяют, кто из маркетологов выживет — тот, кто считает метрики честно.

@ServerSideTrackingRuPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Codex внедрят GPT-5.6 Ultra

OpenAI добавит в Codex эксклюзивную версию GPT-5.6 Sol Ultra — не ту, что выйдет в паблик, а отдельную, усиленную модель.

Два ключевых режима: расширенные рассуждения (модель думает дольше) и мульти-агентная работа с параллельными субагентами. Релиз ожидается 7–9 июля 2026.

Но есть один нюанс, который OpenAI пока не раскрывает 👀 Подробности — в …

➡️ Читайте на сайте: https://aff.top/blog/v-codex-vnedriat-gpt-5-6-ultra

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Компания Meta выпустила Muse Image

Meta выпустила Muse Image — нейросеть, которая генерирует изображения как агент: сама ищет референсы, пишет код и рассуждает перед созданием картинки.

Одна из фишек — можно скинуть ссылку на публичный профиль человека в соцсети, и модель возьмёт его внешность за референс.

Есть один вопрос, который интересует всех арбитражников: как это повлияет …

➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-image

🧠 Ещё больше инсайтов → в канале AFF.top
Server-side не про “теги”, а про ответственность

Мне кажется, в 2026 большинство команд по-прежнему спорят только о том, куда поставить очередной пиксель. А проблема глубже: без серверной валидации и единых first-party правил события легко превращаются в шум, и тогда любые метрики (конверсии, доля повторных визитов, качество лидов) начинают спорить с бизнесом. Особенно в RevOps-реальности, где маркетинг, sales и customer success отвечают за выручку — не за красивый отчёт. Если вы не управляете сбором данных как продуктом, “точность” всегда будет случайной.

@ServerSideTrackingRuPro
Forwarded from Я ЗЛОЙ, Я ГАНГСТА
This media is not supported in your browser
VIEW IN TELEGRAM
Хоменок потребовал, чтобы кардиналы уволили Иванова — новая драма из нижней аффилки.

Вспоминаем этого персонажа: в преддверии МАК и джигейт конф овнер Х6 Group Антон Хоменок назвал себя «инфлюенсером года» и заявил, что если не выиграет награды — значит, премии на конфах купленные. Как и можно было ожидать, умник ничерта не выиграл, но это унижение не помешало ему сделать предложение своей девушке на «коррумпированной» сцене джигеев.

Так вот, на конфе Хоменок посоветовал СЕО кардиналов уволить ЕЮ — мол, он фрик, с которым нельзя сотрудничать. Эта инфа разумеется дошла до Иванова — в ответ он предложил выкупить всю конторку кардиналов (их овнер пока не ответил). Вообще удивительно, с какой уверенностью Антоха даёт коллегам по сфере советы, не понимая базовые вещи (например, тот факт, что ЕЮ — вообще не наёмный сотрудник). Под конец Хоменок слился со стрима с Ивановым, заваливая его комплиментами — ожидаемое лицемерие, что тут скажешь.

К слову, когда ЕЮ спросил у Алексеева, уволил бы тот его, овнер приватов ответил, что скорее Иванов его уволит (что, может, и не так, но главному алкашу сферы всё равно было приятно).

🥴 — «инфлюенсер года», хуле
🤡 — типичный ЧСВшник без реальных достижений в сфере, такая лайф

😈 Я ЗЛОЙ, Я ГАНГСТА
Please open Telegram to view this post
VIEW IN TELEGRAM