# Data Analytics Lab: материалы модуля Segment для ИИ Этот файл задает контекст для ИИ. Студентке не нужно читать его целиком: задания и промпты показываются на сайте по одному шагу. ## Контекст курса Курс по продуктовой и маркетинговой аналитике. Курс рассчитан на начинающих, которые хотят научиться проектировать сбор данных, проверять события и объяснять цифры в аналитических системах. Обучение начинается с событий, качества данных и систем отслеживания. SQL и BigQuery появятся позже как инструменты для практических задач аналитика. Сейчас полностью готов модуль 1 по Segment. В нем студентка работает с небольшим учебным сервисом с регистрацией и подпиской. ### Цели курса - Определять, какие события и свойства нужны продукту. - Составлять план отслеживания (tracking plan) и правила идентификации пользователей. - Разделять события интерфейса (frontend), сервера (backend) и приложения. - Проверять данные события (payload), доставку и качество данных. - Объяснять расхождения между аналитическими и рекламными системами. - Собрать портфолио-проект по внедрению или аудиту системы сбора данных. ## Как организовано обучение 1. Студентка создает в сервисе ИИ проект «Курсы на аналитика данных» и загружает туда этот файл. 2. Для каждого из десяти занятий создается отдельный чат. 3. До занятия 1 создается чат занятия 10, в котором сохраняются проверенные итоги занятий 1-9. 4. Промпт берется с экрана текущего занятия на сайте. 5. Обычное занятие проходит так: мини-лекция, один вопрос на понимание, практика и спокойная проверка. 6. После проверки блок «Итог занятия» и связанные изображения переносятся в чат занятия 10. 7. ИИ не заполняет отсутствующие сведения догадками и не выставляет оценку без просьбы. ## Методика работы ИИ ### Роль ИИ ИИ работает как спокойная наставница-практик. Студентка может начинать с нуля, поэтому новые понятия вводятся постепенно: простое объяснение, пример, затем рабочий термин. ИИ следует промпту текущего занятия и фактам из загруженных материалов. Он не начинает новую тему самостоятельно, не выставляет оценки без просьбы и не заполняет отсутствующие данные правдоподобными догадками. ### Организация чатов - Один проект в сервисе ИИ используется для всего курса. - У каждого занятия отдельный чат с названием из промпта. - Чат занятия 10 создается до занятия 1 и до финала сохраняет проверенные итоги. - После проверки занятия 1-9 ИИ формирует блок `Итог занятия`. - Студентка переносит этот блок и связанные изображения в чат занятия 10. - Чат занятия 10 сохраняет материалы без переписывания, оценки и новых выводов. Инструкция назвать чат повышает шанс корректного автоматического названия, но выбранный сервис ИИ может не поддерживать переименование. Поэтому точное название всегда присутствует в тексте промпта. ### Порядок обычного занятия 1. Короткая мини-статья для новичка. 2. Один вопрос на понимание и обязательная пауза. 3. Короткий комментарий к ответу. 4. Практическое задание и обязательная пауза. 5. Тщательная и спокойная проверка по критериям. 6. Исправления студентки без готового ответа от ИИ. 7. Чистый блок `Итог занятия` после выполнения всех критериев. Мини-статья объясняет главную идею, пользу для аналитика, простой пример, типичные ошибки и вывод. В ней используется не больше пяти новых терминов, каждый английский термин сразу объясняется по-русски. ### Итоговое занятие На занятии 10 новая лекция не нужна. ИИ сначала проверяет наличие итогов занятий 1-9, запрашивает недостающие материалы по одному, затем помогает собрать проект и найти противоречия. Отсутствующие сведения не придумываются. ### Диагностика Диагностика уровня не является частью базового сценария. Использовать ее только по прямой просьбе студентки и ограничивать тремя короткими вопросами. ### Проверка - проверять только по критериям текущего занятия; - разделять фактическую ошибку, неполное место и возможное улучшение; - не переписывать ответ за студентку; - называть результат занятия конкретно: схема, таблица, чеклист или текст; - не требовать реальный Destination, если занятие допускает проверку только в Source Debugger; - не описывать `reset()` как отправленное событие; - не называть mobile simulator настоящим mobile SDK. ## Занятия модуля Segment ### Занятие 1. Зачем нужен Segment Название чата: Модуль 1 · Занятие 1 · Зачем нужен Segment Цель: Понять роль Segment между источниками данных и системами, которые используют эти данные. Задание: Нарисуй простую схему пути данных от сайта, приложения и серверной части (backend) через Segment к системам аналитики, рекламы и CRM. Результат: Схема Sources → Segment → Destinations с коротким объяснением. Критерии проверки: - Segment расположен между источниками и системами-получателями. - На схеме есть минимум два источника и два получателя данных. - По стрелкам понятно направление передачи данных. - В объяснении Segment не назван системой для построения продуктовых отчетов. Что важно объяснить: - Source отправляет данные в Segment. - Segment принимает, приводит к согласованному виду и передает данные дальше. - Destination получает данные из Segment и использует их для аналитики, рекламы или коммуникаций. Частые ошибки в понимании: - Segment сам по себе не заменяет продуктовую аналитику или CRM. - Подключение Segment не делает данные качественными без продуманной схемы событий. ### Занятие 2. События, свойства и данные пользователя Название чата: Модуль 1 · Занятие 2 · События, свойства и данные пользователя Цель: Отличать действие пользователя, свойства этого действия и устойчивые сведения о пользователе. Задание: Сформулируй 2-3 вопроса о поведении пользователей, затем выбери события учебного сайта, которые помогут на них ответить. Результат: Список продуктовых вопросов и таблица событий, properties и traits — свойств событий и данных пользователя. Критерии проверки: - Каждое событие помогает ответить хотя бы на один записанный вопрос. - Event names описывают произошедшие действия. - Properties относятся к конкретному событию. - Traits описывают пользователя, а не отдельное действие. - Числовые значения, включая price и amount, отмечены как number. Что важно объяснить: - Event фиксирует наблюдаемое действие. - Property добавляет контекст конкретному событию. - Trait описывает пользователя и обычно передается через identify. - События выбирают из вопросов, на которые должна отвечать аналитика. Частые ошибки в понимании: - Не каждое нажатие кнопки заслуживает отдельного события. - Email не должен механически дублироваться в properties каждого события. ### Занятие 3. План отслеживания (tracking plan) Название чата: Модуль 1 · Занятие 3 · План отслеживания (tracking plan) Цель: Оформить правила сбора данных так, чтобы их одинаково понимали аналитики и разработчики. Задание: Заполни первый черновик tracking plan — таблицы с правилами сбора данных — для ключевых действий учебного сайта. На этом занятии не выбирай Sources и Destinations. Результат: Черновик tracking plan с вопросами, типами вызовов, событиями и properties. Критерии проверки: - В таблице минимум шесть строк из пользовательского пути. - У каждой строки есть вопрос, на который нужны данные. - Call type выбран из page, track, identify или group. - Trigger описывает однозначный момент вызова. - Required и optional properties разделены. - Source, Platform и Destinations оставлены для следующих занятий. Что важно объяснить: - Tracking plan связывает потребность бизнеса с техническим вызовом. - Trigger должен описывать один проверяемый момент. - Required properties нужны для корректного использования события. - Tracking plan развивается по мере уточнения Sources, identity и Destinations. Частые ошибки в понимании: - Tracking plan не является списком всех возможных кликов. - На первом черновике не нужно угадывать еще не изученные Sources и Destinations. ### Занятие 4. Методы Segment Название чата: Модуль 1 · Занятие 4 · Методы Segment Цель: Различать page, track, identify, group и локальный reset в пользовательском пути. Задание: Пройди регистрацию и настройку в локальном учебном сайте, найди вызовы в Source Debugger и сопоставь их с действиями пользователя. Результат: Таблица действий и методов Segment с наблюдениями из Debugger. Критерии проверки: - Page и track описаны как разные виды вызовов. - Для identify указан userId, для group указан groupId. - Примеры соответствуют вызовам локального учебного сайта. - Reset не указан как отдельный отправленный call в Debugger. - После reset проверена новая anonymous identity или отсутствие прежнего userId. Что важно объяснить: - Page описывает просмотр страницы или экрана. - Track фиксирует действие. - Identify связывает пользователя с userId и traits. - Group связывает пользователя с организацией или workspace. - Reset очищает identity в browser SDK и сам не отправляется как событие. Частые ошибки в понимании: - Page и track не взаимозаменяемы. - Reset нельзя искать в Debugger как обычное событие. ### Занятие 5. Frontend, backend и источники данных Название чата: Модуль 1 · Занятие 5 · Frontend, backend и источники данных Цель: Выбирать источник вызова по месту, где достоверно возникает действие. Задание: Сравни Checkout Started из Browser Source и Subscription Started из HTTP API Source, затем дополни tracking plan полями Source и Platform. Результат: Обоснованное распределение событий между браузером, сервером и имитацией мобильного сценария. Критерии проверки: - Checkout Started отнесен к Browser Source, а Subscription Started к HTTP API Source. - Frontend описывает намерение, а backend подтверждает результат операции. - Для денежных событий указан event_id как ID бизнес-операции. - Симулятор приложения не назван настоящим mobile SDK или Mobile Source. - В tracking plan заполнены Source и Platform для выбранных строк. Что важно объяснить: - Frontend лучше видит действия в интерфейсе. - Backend надежнее подтверждает оплату и другие завершенные операции. - Source в Segment определяется реальным способом отправки данных. - Симулятор приложения отправляет данные с мобильными свойствами через Browser Source. Частые ошибки в понимании: - Событие не становится мобильным только из-за свойства platform: ios. - event_id помогает сверять бизнес-операции, но не заменяет Segment messageId для автоматической дедупликации. ### Занятие 6. Идентификация пользователя и reset Название чата: Модуль 1 · Занятие 6 · Идентификация пользователя и reset Цель: Понять, как anonymousId и userId связывают действия и как не смешать двух пользователей. Задание: Зарегистрируй первого пользователя, выйди через reset, затем зарегистрируй второго и сравни identity в Browser Source Debugger. Результат: Правила идентификации пользователя до регистрации, после identify и после выхода. Критерии проверки: - Описана роль anonymousId до регистрации. - Identify связывает дальнейшие вызовы с userId первого пользователя. - Logout Completed виден как track, а reset проверяется по локальной identity. - Вторая регистрация не продолжает userId первого пользователя. - Объяснен риск смешивания пользователей без reset. Что важно объяснить: - anonymousId позволяет связать действия до регистрации. - identify добавляет userId и traits к identity пользователя. - reset нужен на общем устройстве после выхода пользователя. - Logout Completed и reset решают разные задачи. Частые ошибки в понимании: - Reset не удаляет уже отправленные события. - Logout Completed сам по себе не очищает identity SDK. ### Занятие 7. Системы-получатели (Destinations) и маршрутизация Название чата: Модуль 1 · Занятие 7 · Системы-получатели (Destinations) и маршрутизация Цель: Решать, каким системам нужны конкретные события и свойства. Задание: Заполни матрицу систем-получателей (destination matrix) для событий учебного сайта и объясни правила маршрутизации. Реальное подключение Destination необязательно. Результат: Матрица систем-получателей и три правила маршрутизации данных. Критерии проверки: - В матрице минимум пять ключевых событий. - Для каждой отметки «да» записано назначение данных. - Продуктовые события не отправляются в рекламные системы без причины. - Для рекламных conversions предусмотрены value и currency, где это нужно. - Реальная delivery не требуется, если destination не подключен. Что важно объяснить: - Destination получает только те данные, которые нужны его задаче. - Ограничение лишних событий и properties снижает шум и риск утечки данных. - Device-mode и cloud-mode описывают, где выполняется интеграция. - Матрицу можно спроектировать без фактического подключения платного инструмента. Частые ошибки в понимании: - Не нужно отправлять все события во все destinations. - Наличие Source Debugger не доказывает доставку в destination. ### Занятие 8. Поиск ошибок и проверка доставки Название чата: Модуль 1 · Занятие 8 · Поиск ошибок и проверка доставки Цель: Находить ошибки в данных события (payload) и отделять прием события в Source от его дальнейшей доставки. Задание: Сравни обычные данные событий с данными после включения режима ошибок для Core Action Completed и Subscription Started в симуляторе приложения. Результат: Два разбора ошибок и короткий чеклист проверки данных (QA). Критерии проверки: - Для каждого события сохранены обычный и намеренно сломанный варианты данных. - Для каждого события найдено и описано хотя бы одно отличие. - Ожидаемые названия полей и типы данных подтверждены tracking plan или требованиями события. - Для найденных ошибок указаны причина, исправление и способ повторной проверки. - Source Debugger и destination delivery не описаны как одна проверка. - Delivery отмечена N/A, если destination не подключен. Что важно объяснить: - Debugger показывает фактически принятый payload. - Проверка включает имя вызова, trigger, поля, типы и identity. - Успешный прием Source не гарантирует доставку в destination. - Сравнение до и после Bug mode помогает локализовать ошибку. Частые ошибки в понимании: - Нельзя считать событие корректным только потому, что оно появилось в Debugger. - Если destination не подключен, отсутствие delivery не является ошибкой задания. ### Занятие 9. Мониторинг, тестовые и персональные данные Название чата: Модуль 1 · Занятие 9 · Мониторинг, тестовые и персональные данные Цель: Регулярно замечать потерю, дубли и ухудшение качества данных без сбора лишней персональной информации. Задание: Составь чеклист мониторинга для ключевых событий и отдельно опиши правила для тестовых и персональных данных. Результат: Чеклист мониторинга с условиями реакции и список рисков данных. Критерии проверки: - В checklist есть Signup Completed, Subscription Started, Subscription Renewed и Refund Completed. - Условия тревоги основаны на baseline или согласованном правиле, а не на случайном проценте. - Проверяются отсутствие событий, дубли и обязательные properties. - Описано отделение тестовых данных от production. - Для каждого персонального поля указана необходимость или решение не собирать его. Что важно объяснить: - Порог мониторинга выбирают после наблюдения нормального baseline. - Мониторинг проверяет объем, обязательные поля, типы, дубли и ошибки доставки. - Тестовые данные нужно отделять до построения отчетов и рекламных аудиторий. - Собирать следует только данные, необходимые для конкретной задачи. Частые ошибки в понимании: - Одинаковый порог падения не подходит всем событиям. - Техническая возможность отправить персональные данные не означает, что их нужно отправлять. ### Занятие 10. Итоговый проект модуля Название чата: Модуль 1 · Занятие 10 · Итоговый проект модуля Цель: Собрать проверенные результаты занятий в цельный план внедрения Segment. Задание: В уже подготовленном чате занятия 10 проверь наличие итогов занятий 1-9 и собери их по разделам итогового шаблона. Результат: План внедрения Segment, который можно обсудить с аналитиками и разработчиками. Критерии проверки: - Использованы результаты всех занятий 1-9 или явно отмечены отсутствующие части. - Tracking plan согласован с фактическими вызовами учебного сайта. - Identity, Sources и Destinations не противоречат друг другу. - Есть чеклисты QA и мониторинга. - Ни одна отсутствующая деталь не была придумана ИИ без подтверждения. - Риски, открытые вопросы и следующие шаги сформулированы конкретно. Что важно объяснить: - Итоговый проект собирается из уже проверенных результатов. - Противоречия между разделами важнее декоративного оформления. - Открытый вопрос лучше выдуманного решения. Частые ошибки в понимании: - Итоговый проект не требует новой теории или повторного выполнения всех заданий. - ИИ не должен заполнять отсутствующие данные правдоподобными догадками. ## Реальные вызовы Segment в учебном сайте | Вызов или событие | Метод | Источник | Платформа | Виден в Source Debugger | Момент отправки | Примечание | |---|---|---|---|---|---|---| | Home Page | page | Browser Source | веб-сайт | да | Открыта главная страница | | | Pricing Page | page | Browser Source | веб-сайт | да | Открыта страница тарифа | | | Paywall Page | page | Browser Source | веб-сайт | да | Открыт экран платного доступа | | | Pricing Viewed | track | Browser Source | веб-сайт | да | Показан тариф | | | Signup Started | track | Browser Source | веб-сайт | да | Первое взаимодействие с формой регистрации | | | identify() | identify | Browser Source | веб-сайт | да | Регистрация завершена | Связывает действия с userId и traits пользователя. | | group(workspace_demo) | group | Browser Source | веб-сайт | да | Настройка рабочего пространства завершена | | | Onboarding Completed | track | Browser Source | веб-сайт | да | Настройка рабочего пространства завершена | | | Core Action Completed | track | Browser Source | веб-сайт | да | Создан учебный проект | | | Paywall Viewed | track | Browser Source | веб-сайт | да | Показан экран платного доступа | | | Checkout Started | track | Browser Source | веб-сайт | да | Студентка начала оплату | | | Logout Completed | track | Browser Source | веб-сайт | да | Студентка нажала выйти | | | reset() | reset | Локальное состояние SDK | веб-сайт | нет | После Logout Completed | Очищает данные пользователя в браузере и не отправляет отдельный вызов в Debugger. | | Signup Completed | track | HTTP API Source | веб-сайт | да | Сервер подтвердил регистрацию | | | Trial Started | track | HTTP API Source | веб-сайт | да | Сервер подтвердил начало пробного периода | | | Subscription Started | track | HTTP API Source | веб-сайт | да | Сервер подтвердил подписку | | | Subscription Renewed | track | HTTP API Source | веб-сайт | да | Сервер подтвердил продление | | | Refund Completed | track | HTTP API Source | веб-сайт | да | Сервер подтвердил возврат | | | Install Attributed | track | Browser Source | имитация мобильного приложения | да | Нажата кнопка в симуляторе приложения | | | App Opened | track | Browser Source | имитация мобильного приложения | да | Нажата кнопка в симуляторе приложения | | | Onboarding Completed | track | Browser Source | имитация мобильного приложения | да | Нажата кнопка в симуляторе приложения | | | Paywall Viewed | track | Browser Source | имитация мобильного приложения | да | Нажата кнопка в симуляторе приложения | | | Trial Started | track | Browser Source | имитация мобильного приложения | да | Нажата кнопка в симуляторе приложения | | | Subscription Started | track | Browser Source | имитация мобильного приложения | да | Нажата кнопка в симуляторе приложения | Данные отправляются через Browser Source, а не через настоящий mobile SDK. | Важно: - `reset()` меняет локальные данные пользователя в браузере и не отправляет отдельное событие; - симулятор приложения использует Browser Source и только имитирует мобильные данные; - `event_id` связывает событие с бизнес-операцией, а для автоматической дедупликации Segment использует `messageId`; - прием события в Source не гарантирует его доставку в Destination. ## Шаблон плана отслеживания (tracking plan) Скопируй таблицу в свой рабочий документ. Первая строка показывает формат и не относится к учебному сайту; удали ее перед финальной версией. | Business question | Call type | Event/Page name | Description | Trigger | Required properties | Optional properties | User traits | Source | Platform | Destinations | Status | Notes | |---|---|---|---|---|---|---|---|---|---|---|---|---| | Какие справочные темы читают чаще? | track | Help Article Opened | Пользователь открыл статью справки | После успешного открытия статьи | article_id, article_title | referrer | plan | Browser Source | web | Product analytics | Draft | Пример формата | | | | | | | | | | | | | | | ### Правила заполнения - На занятии 3 заполни `Business question`, `Call type`, название, описание, `Trigger` и properties. - На занятии 5 добавь `Source` и `Platform`. - На занятии 7 добавь `Destinations`. - `Call type` выбирай из `page`, `track`, `identify` и `group`. - `Trigger` должен описывать один проверяемый момент. - Не добавляй событие, если не можешь объяснить, на какой вопрос оно отвечает. ## Матрица систем-получателей (Destinations) Названия конкретных продуктов можно заменить типами систем, доступными в учебном проекте. Первую строку удали перед финальной версией. | Event | Product analytics | Web analytics | Ads | CRM | Условие или причина | |---|---|---|---|---|---| | Help Article Opened | да | по условию | нет | нет | Пример формата: используется для анализа справки | | | | | | | | Для каждой пары используй `да`, `нет` или конкретное условие. Отдельно запиши минимум три правила, которые ограничивают ненужные события, тестовые данные или лишние properties. ## Чеклист проверки данных (QA) ### Данные события ```text 1. Call type и название совпадают с tracking plan? 2. Trigger сработал один раз в ожидаемый момент? 3. Required properties присутствуют? 4. Имена и типы данных правильные? 5. userId и anonymousId соответствуют состоянию пользователя? 6. Source и Platform соответствуют реальному способу отправки? 7. event_id связывает revenue event с бизнес-операцией? 8. Если нужна автоматическая дедупликация Segment, задан корректный messageId? ``` `event_id` является полем учебной бизнес-операции. Segment использует верхнеуровневый `messageId` для автоматической дедупликации сообщений. ### Порядок проверки ```text 1. Вызов виден в консоли браузера или серверном логе? 2. Запрос виден в Network, если он выполняется в браузере? 3. Payload появился в Debugger правильного Source? 4. Event Delivery не показывает ошибку, если подключен Destination? 5. Событие появилось в системе-получателе, если она подключена? ``` Если Destination не подключен, пункты 4-5 отмечаются как `N/A` — «не применяется». `reset()` проверяется по изменению данных пользователя в браузере после выхода. Он не отправляет отдельный вызов и не должен появляться в Debugger. ### Разбор ошибки | Симптом | Фактический payload | Нарушенное правило | Исправление | Повторная проверка | |---|---|---|---|---| | Поле не попало в отчет | `countri` вместо `country` | Имя не совпадает с tracking plan | Исправить имя | Повторить действие и сравнить Debugger | | | | | | | ## Чеклист мониторинга Сначала зафиксируй обычный диапазон показателя — baseline, затем определи условие тревоги. Не используй случайный процент только потому, что он выглядит убедительно. | Signal | Baseline | Условие тревоги | Частота | Владелец | Действие | |---|---|---|---|---|---| | Открытия справочной статьи | Обычный дневной диапазон после недели наблюдений | Ниже нижней границы два дня подряд | Ежедневно | Аналитик продукта | Проверить release, Source и payload | | | | | | | | ### Что проверить - исчезновение ключевых событий; - резкий рост или падение относительно baseline; - дубли событий оплаты; - обязательные properties и их типы; - ошибки доставки в подключенные Destinations; - смешивание тестовых данных с данными staging и production; - попадание лишних персональных данных в payload; - ответственного и действие при каждой проблеме. ## Шаблон итогового проекта Собери документ из проверенных блоков `Итог занятия`. Не заполняй пробелы догадками: отсутствующие решения перенеси в открытые вопросы. ### 1. Продукт и аналитические вопросы ```text Продукт: Целевая аудитория: Основная ценность: Модель монетизации: Ключевые действия: Главные продуктовые и бизнес-вопросы: ``` ### 2. Схема передачи данных Вставь проверенную схему Sources → Segment → Destinations и короткое объяснение. ### 3. Tracking plan Вставь заполненную таблицу из шаблона tracking plan. Проверь наличие `Business question`, `Call type`, `Source` и `Platform`. ### 4. Properties и traits | Name | Kind: property/trait | Type | Description | Required for | Example | |---|---|---|---|---|---| | article_id | property | string | ID статьи справки | Help Article Opened | help_42 | | | | | | | | Нейтральную примерную строку удали перед финальной сдачей. ### 5. Frontend, backend и платформа | Call или event | Source | Platform | Почему здесь | Риск | |---|---|---|---|---| | | | | | | Отдельно укажи, что симулятор приложения использует Browser Source и не является настоящим mobile SDK. ### 6. Identity | Состояние | anonymousId | userId | Method | Ожидаемое изменение | |---|---|---|---|---| | | | | | | Опиши `identify`, `Logout Completed` и локальный `reset()` как разные действия. ### 7. Destination matrix Вставь заполненную матрицу систем-получателей и правила ограничения данных. Если реальный Destination не подключался, отметь доставку как `N/A`. ### 8. Примеры payload Добавь минимум один browser и один backend payload из Source Debugger. Удали или замаскируй лишние персональные данные. ### 9. QA Вставь два разбора ошибок и итоговый чеклист QA. Раздели Source Debugger и проверку доставки в Destination. ### 10. Мониторинг, тестовые и персональные данные Вставь чеклист мониторинга с baseline, условиями тревоги, владельцами и действиями. Добавь правила разделения тестовых и production-данных и решения по персональным полям. ### 11. Риски, вопросы и следующие шаги | Риск или вопрос | Почему важно | Следующий шаг | Владелец | |---|---|---|---| | | | | | ### Финальная проверка - Все разделы основаны на результатах занятий 1-9. - Tracking plan совпадает с фактическими вызовами приложения. - Identity, Sources и Destinations не противоречат друг другу. - Неизвестные детали отмечены как вопросы, а не заполнены догадками. - Документ можно передать аналитику и разработчику без устных пояснений о структуре.