Дзен

Происхождение и история термина

Дзен возник в Яндексе как сервис персонального подбора материалов из интернета. В официальном сообщении от 8 июня 2016 года компания указывала, что экспериментальный запуск состоялся в мобильном браузере годом ранее, в 2015 году. На этом раннем этапе лента помогала находить интересные внешние материалы ^[7].

8 июня 2016 года Яндекс представил браузер с лентой Дзена для Windows, iPhone и Android. Она содержала ссылки на статьи, видео, изображения и другой контент из интернета. В анонсе описывался подбор с учётом посещённых сайтов и оценок пользователя, включая предложения из незнакомых источников ^[7]. Это историческое описание того, как рекомендательный сервис расширял распространение; нынешний алгоритм по нему восстановить нельзя.

30 мая 2017 года назначение сервиса расширилось: Яндекс открыл прямое размещение публикаций для издателей, брендов и авторов. В релизе компания прямо сопоставила прежние рекомендации ссылок с материалами, созданными уже внутри Дзена. Авторы получили возможность вести каналы и публиковать тексты и видео на самой платформе ^[8]. Поэтому эту дату следует понимать как открытие публикационной платформы, а не первый запуск Дзена. Изменилось и место чтения: теперь рекомендательная лента могла приводить человека к самостоятельной публикации внутри сервиса, а не только к внешнему сайту ^[8].

12 сентября 2022 года Яндекс сообщил о закрытии сделки по продаже Дзена и Новостей компании VK. Связанные с продажей изменения должны были появляться у пользователей постепенно ^[2]. Это смена владельца уже существовавшего сервиса, прошедшего путь от подбора внешних материалов до собственной публикационной площадки.

На 21 октября 2026 года приложение в Google Play называется «Дзен — новости, статьи, видео», разработчиком указан VK LLC; дата обновления — 13 октября 2026 года ^[1]. Отметка магазина относится к приложению и не датирует появление всех его возможностей. Старые инструкции полезно читать с учётом этапа развития сервиса: прежнее название, способ публикации и нынешние условия могут относиться к разным периодам.

Суть и механизм

В описании приложения заявлены чтение статей и новостей, просмотр видео и создание контента. Разработчик также описывает ленту по интересам и получение рекомендаций от новых авторов ^[1]. Поэтому читатель может встретить материал двумя путями: следить за выбранным источником через подписку или получить предложение в ленте. Это объяснение пользовательского выбора, а не формула ранжирования.

Для дальнейшего объяснения разделим четыре объекта: материал, канал, подписку и рекомендацию. Материалом будем называть конкретную публикацию; каналом — источник, с которым читатель связывает автора или редакцию. Подписка показывает выбор читателя следить за источником, а рекомендация — предложение посмотреть материал. Это рабочая схема статьи. Она помогает обсуждать действия пользователя без предположений о внутреннем алгоритме платформы.

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

Для читателя полезно другое различие: источник утверждения и способ его доставки. Рекомендательная лента объясняет, где человек встретил новость, но не удостоверяет её содержание. Если публикация пересказывает документ или выступление, проверяемость по-прежнему зависит от названного первоисточника. Персонализация не превращает мнение в факт и не заменяет указание источника сведений.

Более широкую рамку даёт доклад Организации экономического сотрудничества и развития (OECD) о цифровой трансформации малого бизнеса, опубликованный в 2021 году. Платформы рассматриваются как посредники взаимодействия разных групп, при этом обсуждаются выгоды доступа и риски зависимости. Доклад описывает цифровые платформы в целом ^[3]. Для работы редакции из него полезен вопрос: какие возможности даёт посредник и от каких его решений зависит доступ к аудитории? Ответ о конкретном канале требует собственных данных.

Виды и классификации

Ниже приведена редакционная схема задач. Она не является перечнем официальных типов каналов или условий подключения: одна редакция может решать сразу несколько таких задач.

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

Отдельно стоит различать работающую в конкретном аккаунте функцию и продуктовый анонс. Официальный канал Дзена сообщил об ИИ-Студии для СМИ: в публикации описаны варианты заголовков, а адаптация текста под разные площадки и создание других форматов обозначены как дальнейшее развитие ^[5]. Анонс показывает направление работы сервиса, но доступность инструмента конкретной редакции нужно проверять отдельно. Он не даёт основания включать обещанные возможности в обычную инструкцию по публикации.

Как применяется на практике

Для небольшой редакции разумная исходная задача может звучать так: донести объяснительный материал до читателей вне собственного сайта. Это не то же самое, что увеличить переходы на сайт или получить доход от платформы. Перед подготовкой материала редактор выбирает один основной результат и записывает, какое наблюдение позволит судить о его достижении.

Дальше стоит решить, где читатель получит основной ответ: непосредственно в платформенной публикации или в исходном материале на сайте. Это вопрос редакционного замысла. Доступный формат размещения проверяют в рабочем интерфейсе и действующих правилах: обзор платформы не заменяет инструкцию для конкретного аккаунта.

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

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

Международный контекст полезен не как обещание одинакового поведения разных сервисов, а как способ оценить зависимость от посредника. OECD обсуждает платформенные возможности и риски для организаций в целом; это не замер эффективности Дзена ^[3]. Редакция может применить эту рамку к своему плану: где хранится исходный материал, как читатель найдёт его повторно и какой результат удастся измерить вне платформы? Это вопросы для планирования, а не прогноз охвата.

Практическая карточка работы с каналом может содержать тему материала, исходный документ, ответственную роль, дату размещения, цель и место измерения. Это предложенный редакционный инструмент, а не описание обязательных полей интерфейса. Такая карточка позволяет позже понять, какой результат относился к публикации, а какой — к последующим действиям читателя.

Как измерить или проверить

Первое правило измерения — назвать объект. Показ, открытие материала, чтение внутри платформы, подписка и визит на внешний сайт описывают разные события. Их нельзя складывать как уникальных людей или сравнивать без пояснения периода и методики. Даже похожие названия отчётов не доказывают одинаковых правил подсчёта.

Яндекс Метрика относит Дзен к рекомендательным системам в соответствующем отчёте об источниках. При этом новостные агрегаторы в документации отделены от этой категории. Это классификация Метрики для входящего трафика, а не универсальное определение всех частей платформы. Она объясняет, почему источник нужно искать в корректном отчёте. ^[4]

Учебный расчёт: за выбранную неделю на внешний сайт пришло 100 визитов из Дзена, в пяти визитах посетители выполнили заранее определённое целевое действие — например, открыли страницу с исходным документом. Доля визитов с таким действием равна:

Здесь $v$ — все визиты из выбранного источника за неделю, $g$ — визиты, в которых действие произошло хотя бы раз, а $C$ — их доля в процентах. Считаются визиты с действием, а не количество повторных нажатий. Если в одном визите документ открыли трижды, в числитель он всё равно входит один раз. Результат описывает эту условную неделю и выбранную цель, а не всех читателей Дзена. При отсутствии визитов, то есть при $v=0$, доля не определена: делить на ноль нельзя. Число визитов с действием не может превышать общее число визитов из того же источника.

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

Для проверки динамики следует сохранить период, источник, фильтры и определение цели. Иначе рост может отражать изменение отчёта или продолжительности наблюдения. Полезно также записать даты собственных редакционных изменений: новый формат, иная тема, другое время публикации. Без этого объяснение «сработал алгоритм» остаётся догадкой, а не установленной причиной.

Для сравнения каналов выбирают одинаковые цель, период и единицу измерения. Для учебного отчёта удобно записать эти результаты рядом, сохранив единицы: «просмотры внутри платформы — 500», «визиты на сайт — 100», «визиты с целевым действием — 5». Эта запись показывает три разных результата и не требует складывать их в одну аудиторию. Если один оценивается по внешним визитам, другой по чтению внутри площадки, итоговая таблица должна прямо показывать разные единицы. Общую цель можно сформулировать отдельно, но механическое сведение несопоставимых показателей создаёт ложную точность.

Ошибки, ограничения и спорные вопросы

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

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

Третья ошибка — принимать обещания разработчика за прогноз результата своего канала. Для расчёта дохода нужны действующие условия конкретной программы, оплачиваемый результат и данные редакции. Самоописание приложения с упоминанием монетизации этого расчёта не даёт ^[1]. В частности, условия авторской программы и программы для СМИ нужно проверять по документам соответствующей программы.

Правовой аспект

Если редакционная работа включает обработку персональных данных, применимость оснований и ограничений проверяют отдельно. Части 2, 4 и 5 статьи 5 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных» в редакции от 26.07.2026 требуют определённых законных целей обработки, соответствия данных этим целям и отсутствия избыточности ^[6]. Это общие принципы, а не разрешение публиковать сведения о конкретном человеке.

Для практической проверки редактор может описать юристу, какие сведения о людях есть в материале, зачем они нужны и кому станет доступна публикация. Например, объяснение изменения автобусного маршрута само по себе не требует прикладывать список пассажиров с телефонами. Это учебная иллюстрация вопроса об избыточности, а не правовой вывод по реальному делу. Статья направляется на юридическую проверку до публикации.

Частые вопросы

Связанные термины

• novostnoy-agregator-dzena
• yandeks novosti i dzen novosti
• dzen-dlya-smi
• studiya dzena
• ii-studiya-dzena
• monitoring-trafika-iz-dzena
• monetizatsiya-smi-v-dzene