Короткий домен Telegram перестал работать

Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.

➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat

🧠 Ещё больше инсайтов → в канале AFF.top

ClickHouse или PostgreSQL для трекера: где база начнёт тормозить раньше

Если трекер живёт на сыром клике, показах, postback и логах по каждому переходу, выбор БД решает больше, чем фронт. ClickHouse тянет потоковые вставки и тяжёлые отчёты: агрегаты, срезы по GEO/UA, воронки, дедупликацию по событиям. PostgreSQL удобнее там, где важны транзакции, связи между сущностями и частые точечные UPDATE/DELETE.

Схема «всё в одной базе» обычно ломается на смешанной нагрузке. Сначала начинают проседать отчёты, потом блокируются записи, а дальше любой reindex или vacuum превращается в окно деградации. Для трекера это критично: конверсия может прийти с задержкой, а UI уже показывает пустые или неполные данные.

Практика рабочая:
— ClickHouse хранит события, логи, конверсии, сырые постбэки.
— PostgreSQL держит пользователей, кампании, офферы, правила, биллинг.
— между ними нужен явный слой синхронизации, а не ручные скрипты «по случаю».
— если отчёт строится по миллионам строк, не тащите его в OLTP-схему.

Самая частая ошибка — пытаться заставить PostgreSQL быть аналитической витриной. Вторая ошибка — держать в ClickHouse то, что требует строгих транзакций и уникальности на запись. Разделяйте OLTP и OLAP на уровне модели данных, а не после того как начались лаги.

Итог простой: для трекера PostgreSQL — про контроль и консистентность, ClickHouse — про объём и скорость чтения. Чем раньше вы разведёте эти роли, тем меньше шанс, что база станет узким местом.

Youtube тестирует поиск с AI

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

Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.

Что это значит для поиска на YouTube и когда новинка дойдёт до других…

➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai

🧠 Ещё больше инсайтов → в канале AFF.top

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

Hetzner: как не словить простои и банальные ошибки на дешёвом хостинге

Hetzner часто берут под лендинги, трекеры, прокси-обвязку и сервисы, где важны предсказуемый диск, сеть и быстрый старт. Но дешёвый VPS не прощает хаотичную эксплуатацию: один забытый бэкап, один открытый порт, один разросшийся лог — и у тебя уже не «экономия», а ночной инцидент.

Перед запуском проверь базу:
— включён ли firewall и закрыто ли всё лишнее;
— есть ли SSH только по ключам, без пароля;
— вынесены ли логи, tmp и бэкапы отдельно от системного диска;
— настроен ли мониторинг по CPU, RAM, disk, inode, latency;
— есть ли restore-процедура, а не просто архив «на всякий случай».

Отдельно смотри на storage и сеть. Для лендингов важнее стабильный отклик, чем пиковая мощность: лучше меньше сервисов на узел, чем один перегруженный VM с swap-thrashing. Если поднимаешь несколько окружений, сразу разводи их по namespace/VM и не смешивай prod с тестом — потом это экономит часы на расследованиях.

Ещё одна типовая ошибка — считать, что «раз хостинг железный, значит можно не заниматься наблюдаемостью». Без алертов на место на диске, ошибки в логах и падение веб-сервиса любой сбой выглядит как магия. Ставь минимальный набор: uptime, метрики ресурсов, централизованные логи и простую проверку health endpoint.

Если нужен спокойный Hetzner без сюрпризов, начинай не с установки CMS, а с baseline: security, backup, monitoring и понятный plan restore. Это и есть нормальный devops для кластера или одиночной VM.

↩️ Пост из @voluum_lifehacks_n1k:

На рынке трекинга назревает важный сдвиг: всё больше команд перестраивают аналитику под реальную атрибуцию, а не под «красивые» отчёты. Причина простая — классические схемы всё хуже ловят путь пользователя между креативом, лендингом и оффером, особенно когда трафик идёт из нескольких источников сразу. 📊

Что это значит на практике? Побеждают связки, где трекинг настроен максимально близко к бизнес-логике: отдельные события под ключевые действия, сегментация по устройствам и GEO, контроль дублей и быстрые сравнения связок по ROI, а не только по кликам.

Главный вывод с поля: аналитика перестаёт быть «таблицей для отчёта» и становится инструментом ежедневных решений. Чем раньше вы увидите, где теряется конверсия, тем дешевле обходится масштабирование.

Telegram запустил собственный сервер для ботов

Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.

Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.

Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…

➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov

🧠 Ещё больше инсайтов → в канале AFF.top

Google картинки станут конкурентом Pinterest

Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.

Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.

Как это будет работать и когда новинка дойдёт до других стран — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest

🧠 Ещё больше инсайтов → в канале AFF.top

SvelteKit ломается не в коде, а на границе SSR, cookies и данных

За неделю в репах чаще всего всплывают не «ошибки фреймворка», а три места: загрузка данных в load, доступ к request-local state и несовпадение server/client поведения. Если держать в голове только UI, потом внезапно ловишь странные редиректы, пустые страницы и hydration mismatch.

Что проверять в первую очередь:
— всё, что зависит от пользователя, читать на сервере, а не в компоненте;
— cookies, headers и auth не тянуть через глобальные синглтоны;
— в load отдавать только то, что реально нужно странице, иначе раздуваешь SSR;
— браузерные API трогать только после mounted-проверки или в onMount.

Отдельная ловушка — form actions и промежуточные состояния. Если после сабмита страница должна обновить данные, не пытайся вручную синхронизировать половину стора: проще вернуть данные через действие и пересобрать страницу через invalidate, чем лечить рассинхрон по кускам. Это же относится к edge-case с ошибками: лучше явно отдавать статус и сообщение, чем маскировать всё редиректом.

Ещё одно правило: если логика нужна и на сервере, и в браузере, вынеси её в чистую функцию без зависимостей от runtime. Тогда SvelteKit остаётся простым: сервер отвечает за доступ и данные, клиент — за интерактивность.

Клоакинг как технический слой: где он полезен без серых схем

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

Нормальные применения: — A/B и split-test без влияния на все сегменты сразу; — скрытие служебных страниц от индексации и превью-ботов; — раздельная выдача лендинга для webview, desktop и mobile; — защита внутренних кабинетов, когда публичная часть и рабочая часть живут на одном домене. Важен не сам факт подмены, а контролируемая логика правилами.

Если строишь такой слой, смотри на три вещи: детерминированность матчинга, журналирование решений и fallback. Без логов невозможно понять, почему трафик ушёл в одну ветку, а без запасного сценария любая ошибка фильтра превращается в потерю конверсий. Ещё один момент — не завязывайся только на fingerprint: UA, IP, ASN, cookie и поведение должны сходиться в одной модели.

Для поддержки проще держать правила в виде таблицы: источник, сегмент, действие, TTL, исключения. Тогда клоак не превращается в набор ручных if-ов, которые ломаются после первого обновления шаблона.

Если слой нужен для маршрутизации и изоляции, делай его прозрачным для команды: логи, версии правил и понятный fallback важнее самой хитрой логики.

Россияне не смогут покупать стейблкоины

Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.

Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.

Что это значит для обычных пользователей и когда правило заработает — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny

🧠 Ещё больше инсайтов → в канале AFF.top

Webhook security: подпись без валидации — это просто POST в открытую дверь

Если у тебя postback/webhook принимает конверсии, ретаргет или статусы лидов, базовый чек-лист один: проверяй источник, подпись и структуру payload. Иначе любой, кто угадает URL, сможет подсовывать фейковые события в трекер, CRM или антифрод-логи.

Минимум для защиты:
— secret в заголовке или query string, но не в открытом URL для всех интеграций
— HMAC по body, а не по сырой строке после промежуточных преобразований
— сравнение подписи через constant-time compare
— whitelist IP только как дополнительный слой, не как единственный
— timestamp/nonce, чтобы отрезать повторную отправку одного и того же webhook

На стороне приёма не доверяй полям из payload вслепую. Проверяй обязательные ключи, типы значений, допустимые статусы и связку id → campaign/source/goal. Любой webhook без idempotency key нужно считать повторяемым: при ретраях одна и та же конверсия не должна записываться дважды.

Если у тебя несколько провайдеров, делай отдельный secret и отдельный endpoint на каждого. Один общий маршрут с «универсальной» логикой быстро превращается в помойку, где невозможно отследить, кто именно прислал мусор или сломал схему.

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

User agent parsing ломается не в строке UA, а в ваших допущениях о ней

UA-парсинг нужен не для «узнать браузер», а чтобы быстро разложить трафик по платформе, движку и типу устройства. Ошибка начинается, когда библиотека считает строку стабильным идентификатором. На практике одно и то же устройство может отдавать разные UA в webview, в embedded browser и при проксировании запросов.

Смотрите на три слоя сразу:
— raw UA без нормализации;
— распарсенные поля: family, major, device class;
— согласованность с остальными fingerprint-сигналами: язык, timezone, screen, platform.

Типовые проблемы библиотек:
— устаревшие regex-таблицы режут новые браузеры в «Other»;
— мобильные браузеры маскируются под desktop-движки;
— iOS Safari и webview часто путаются;
— кастомные UA ломают классификацию, если парсер ждёт «чистую» сигнатуру.

Для трекинга важнее не идеальный детект, а стабильные правила: одинаковая нормализация на входе и в отчётах, отдельная обработка webview, логирование raw UA рядом с результатом парсинга. Иначе при разборе антифрода вы будете спорить не с трафиком, а с собственной библиотекой.

Если нужен надёжный контур, держите парсер как вспомогательный слой, а не как источник истины. Raw UA храните всегда, правила классификации версионируйте, а спорные случаи отправляйте в отдельный bucket.

Real-time и batch в трекере: где теряется атрибуция и когда нужен каждый режим

Real-time нужен там, где решение принимается сразу: редирект, антифрод, динамическая маршрутизация, быстрый postback в сеть. Batch подходит для тяжёлых расчётов: сверка конверсий, дедупликация, LTV, пересчёт окон атрибуции, отчёты по источникам.

Ошибка обычно в другом: пытаются тащить всё в real-time. Тогда растёт latency, ломаются очереди, а при пике начинают сыпаться события. Batch тоже опасен, если им закрывают критичный путь: креатив уже отработал, а фильтр ещё не увидел сигнал и пустил мусор дальше.

Практика простая: в real-time держи только то, без чего нельзя принять решение за миллисекунды — click, basic fingerprint, rule match, отправка postback. Всё, что требует агрегации, joins и тяжёлых вычислений, уводи в batch или в отдельный воркер с очередью. Между ними нужен понятный idempotency key, иначе получишь дубли или «пропавшие» конверсии.

Если архитектура трекера начинает спорить с трафиком, смотри не на UI, а на путь события: где оно ждёт, где теряется, где дублируется. Правильное разделение real-time и batch обычно чинит больше проблем, чем ещё один сервер.