Python Web & Scripts — Django, FastAPI, скрипты

CTV fraud: 6 проверок, которые спасают бюджет от «умных» бот-стримов CTV выглядит как релиз года для медиа, пока не начинаешь смотреть в логи. Там внезапно всплывают странные устройства, одинаковые сессии, пустые профили и просмотр без нормального сигнала о реальном экране. IVT в CTV часто маскируется под «качественный инвентарь», потому что экран большой, а вопросов мало. Проверяйте не только охват, но и контекст доставки: — device/app bundle: мусорные приложения и неожиданные связки; — session length и повторяемость: одинаковые паттерны у сотен «зрителей»; — гео и таймзоны: когда домохозяйство живёт в трёх странах сразу, это уже fraud; — ad pod behavior: слишком ровное досмотренное видео без пауз и промахов; — supply path: лишние реселлеры любят прятать невалидный трафик. Отдельно смотрите на spoofing: подмена модели устройства, ОС, app-идентификатора и даже производителя. Для brand safety это не только про потерю денег, но и про риск оказаться рядом с сомнительным контентом, который в отчётах красиво замаскирован под premium reach. Если у вас нет контроля на уровне supply path и верификации сигнала, CTV легко превращается в дорогую иллюзию. Начинайте с аномалий, режьте подозрительные связки и не верьте инвентарю на слово — ad fraud в CTV обычно улыбается шире всех. Может, конечно, ни хуя не взлетит, но проверять всё равно придётся.

Лонгрид о мемном кейсе Melbet vs Pepper Partners - реально ли оценить в аффилейтке репутационный ущерб в деньгах? История на $2,000 вряд ли разрушит крупный бренд. Но она вполне может стоить ему сотен тысяч долларов и более, если публично остаётся без внятного решения. Я в аффилейт-маркетинге более 25 лет, а последние пару лет одно из моих основных направлений - B2B matchmaking. Поэтому я регулярно вижу споры между компаниями о выплатах и претензии, и таких ситуаций в рынке явно становится больше. Знаю многие кейсы, которые были в итоге решены благополучно до выхода в публичное поле и всегда приятно видеть, когда так происходит, но все больше и больше кейсов, которые не просто выходят в паблик, а еще и очень странным и глупым образом в паблике продолжают долго оставаться и наносить ущерб в то время как имеют очень простые и адекватные для обеих сторон варианты решения. Вот например про один из таких кейсов писал уже здесь весной. Если неконструктивны обе стороны (а бывает и так), то можно к этому относиться просто как к развлекательному контенту. Но когда одна сторона открыта к адекватной коммуникации и поиску оптимального решения, а вторая сторона просто игнорирует проблему, при этом не уходя с рынка в закат, а продолжая тратить огромные бюджеты на PR и маркетинг бренда - это любопытная аномалия. Сейчас самый заметный в аффилейт рынке пример это кейс Melbet <> Pepper Partners, который уже более месяца развивается в публичном поле и о нем уже писали и многие аффилейт медиа, и отдельные блоги, я наверно один из последних, кто у себя в блоге еще об этом не писал) Изначальное заявление кейса и описание претензии от Pepper Partners можно почитать здесь. Очень приличный на мой взгляд разбор со стороны и указание пары простых и логичных вариантов решения ситуации написал Артем Кравченко, можно почитать у него. А я хочу разобрать эту историю с другой стороны, как можно оценивать репутационные потери от подобных историй непосредственно в деньгах и принимать более… Leggi tutto →

Flask ломается не на роутинге, а на мелочах вокруг приложения За неделю в репах чаще всего всплывают не «сложные баги», а одни и те же промахи: — держат глобальное состояние в модуле, а потом ловят гонки между запросами; — тянут конфиг вручную по файлам, вместо одного объекта настроек; — смешивают view, бизнес-логику и доступ к БД в одном обработчике. У Flask сильная сторона — минимальный каркас. Но именно поэтому важно сразу разделить слои: route только принимает и возвращает, сервисы считают, репозитории читают и пишут. Как только логика расползается по handlers, тесты становятся дорогими, а любой рефакторинг превращается в лотерею. Ещё одна типовая ошибка — жить на расширениях как на магии. Они удобны для auth, миграций и сессий, но если каждый пакет начинает управлять всем приложением, дебаг становится неприятным. Лучше явно собирать зависимости в фабрике приложения и передавать их туда, где они нужны. Это хорошо ложится и на unittest, и на интеграционные тесты 🧩 Если нужен Flask-проект, который переживёт не один спринт, держите простое правило: приложение должно быть маленьким, а доменная логика — независимой от Flask. Тогда смена шаблонов, БД или точки входа не сносит весь код.

Starlette часто ломают не роуты, а мелкие ошибки вокруг ASGI Starlette любят за минимализм: быстрые ответы, WebSocket, фоновые задачи, middleware. Но в бою чаще всего страдает не сам фреймворк, а обвязка вокруг него. — Не смешивайте тяжёлую логику с endpoint: вынесите парсинг, валидацию и доступ к данным в отдельные функции. — Не ждите чудес от sync-кода внутри async: блокирующие вызовы сразу бьют по задержкам и конкурентности. — Не вешайте middleware «на всякий случай»: каждая прослойка добавляет стоимость на каждый запрос. — Не игнорируйте lifespan: там удобно поднимать пул соединений, кэш и внешние клиенты, а не создавать их на каждый запрос. Ещё одна частая ошибка — думать, что Starlette сам решит вопрос с архитектурой. Он даёт тонкий слой для ASGI, а порядок в проекте задаёте вы: схема ответов, границы модулей, обработка ошибок, логирование, таймауты. Если нужен надёжный каркас, держите ручки тонкими, а бизнес-логику — отдельно. Тогда Starlette остаётся тем, чем и должен быть: быстрым серверным скелетом, а не местом, где живёт весь проект.