MiddleData Analyst > SQL и данные > SQL
Короткий ответ Нужно объявить несколько CTE через запятую в одном блоке WITH, где каждый следующий CTE может ссылаться на предыдущие, формируя цепочку шагов «очистка → дедупликация → агрегация → финальный отбор». Как это работает подробнее в блоке WITH cte1 AS (...), cte2 AS (SELECT ... FROM cte1 ...), cte3 AS (...) каждый следующий CTE может использовать результат предыдущего по имени, как обычную таблицу; основной SELECT в конце обычно обращается к последнему CTE. Пример кода Что использовать на практике такой подход делает сложную логику читаемой и тестируемой по шагам — можно временно заменить финальный SELECT на SELECT * FROM cte2 и проверить промежуточный результат, не переписывая весь запрос. Это особенно полезно, когда данные перед агрегацией нужно почистить (убрать дубликаты, отфильтровать тестовые записи, привести типы). Проверка: временно выполнить SELECT COUNT(*) FROM cleaned_orders и SELECT COUNT(*) FROM deduped_orders, чтобы увидеть, сколько строк отсеялось на каждом шаге. Подводные камни нагром
aggregationcte
MiddleData Analyst > SQL и данные > Статистика и теория вероятностей Короткий ответ Оконные функции позволяют считать агрегаты (среднее, сумму, процентиль) по «окну» строк, связанному с текущей строкой, не сворачивая результат в одну строку на группу, как это делает GROUP BY; для скользящего среднего используют AVG(...) OVER (ORDER BY ... ROWS BETWEEN ... AND CURRENT ROW). Как это работает подробнее конструкция OVER (PARTITION BY ... ORDER BY ... ROWS/RANGE BETWEEN ...) определяет для каждой строки своё окно соседних строк, по которому и считается функция; ROWS считает окно по числу строк, RANGE — по значениям (например, по дате). Пример кода Что использовать на практике На практике. скользящее среднее полезно для сглаживания шумных временных рядов перед визуализацией трендов (например, 7-дневное скользящее среднее для устранения недельной сезонности). Для расчёта процентилей внутри группы на лету используют PERCENTILE_CONT(...) OVER (PARTITION BY ...) (поддержка синтаксиса отличается между PostgreSQL, BigQuery, ClickHouse — стоит проверять документацию конкретной СУБД). Важно
moving-averagepercentiles
MiddlePerformance Marketer > Google Ads > Взаимодействие с командами и бизнес-практики Короткий ответ RICE позволяет сравнить разные гипотезы через (Reach × Impact × Confidence) / Effort. Для сопоставимости охват оценивают в одинаковых единицах и за один период, а трудозатраты учитывают по всем участникам, необходимым для теста. Как это работает подробнее Reach — ожидаемый охват за выбранный период, например показы за месяц; Impact — размер возможного эффекта; Confidence — обоснованность ожидания; Effort — время на подготовку и проверку. После расчёта гипотезы сортируют по убыванию балла и рассматривают вместе с ограничениями команды. Унифицировать Reach. Выбирать одну единицу и одинаковое окно оценки для креативов, аудиторий и стратегий ставок. Обосновать Confidence. Использовать результаты прошлых тестов и качество данных, а не только интуитивную оценку. Посчитать Effort. Включить работу дизайнера, разработчика, аналитика, маркетолога и время модерации площадки, если оно требуется. Что использовать на практике Вести единый бэклог. Записывать гипотезу, её допущения, оценки четырёх факторов, вл
bidding-strategycreative-testing
MiddleDevOps Engineer > Контейнеры и доставка > Dockerfile и сборка Короткий ответ Стадия сборки использует полнофункциональный образ с компилятором и зависимостями, а финальная стадия строится на минимальном base image (alpine, distroless, scratch), в который копируется только скомпилированный бинарник через COPY --from=, без инструментов сборки и промежуточных артефактов. Как это работает подробнее промежуточная стадия (builder) может весить сотни мегабайт за счёт компилятора, системных заголовков и зависимостей сборки, но в финальный образ эти слои не попадают — копируется только явно указанный путь. Для статически линкуемых языков (Go, Rust) финальной стадией может быть даже scratch — полностью пустой базовый образ, содержащий только бинарник. Пример кода Что использовать на практике Практика. это значительно сокращает размер итогового образа (с сотен мегабайт до единиц–десятков), ускоряет docker pull в production и уменьшает поверхность атаки — в финальном образе физически отсутствуют компиляторы, пакетные менеджеры и build-инструменты, которые могли бы быть использованы
container-imagesdocker
MiddlePython Developer > Основы Python > ООП и модель объектов Короткий ответ property превращает вызов метода в синтаксис обычного доступа к атрибуту (obj.attr вместо obj.get_attr()), позволяя добавить геттер и сеттер с проверками (валидацией, вычислением) без изменения кода, который уже использует obj.attr = value. Как это работает подробнее Декоратор @property делает метод геттером, доступным без вызова со скобками. Метод с тем же именем, декорированный @attr.setter, перехватывает присваивание obj.attr = value и может выполнить проверку перед сохранением в "приватное" поле (по конвенции — с подчёркиванием, например self._attr). Если сеттер не определён, property становится доступной только для чтения, и попытка присвоить значение вызывает AttributeError. Пример кода Что использовать на практике Практика. property особенно полезна при рефакторинге: класс изначально хранил простое публичное поле, а позже понадобилась валидация или вычисление на основе других полей — property позволяет добавить это без изменения вызывающего кода (obj.price = 10 продолжает работать так же
object-modelproperty
MiddleSMM Manager > Общее > Площадки и основы SMM Короткий ответ Для оперативной реакции важно заранее иметь процесс мониторинга (список тем/ключевых слов, за которыми следит SMM-команда) и предварительно согласованные с руководством границы допустимого тона шуток или мнений бренда, чтобы публикация выходила быстро, но без риска, при этом не каждый трендовый повод подходит бренду — уместность нужно оценивать каждый раз отдельно. Как это работает подробнее в X/Twitter скорость реакции важна именно потому, что лента построена вокруг актуальных событий и обсуждений в моменте, и то же сообщение, опубликованное через сутки после пика обсуждения, получает заметно меньший отклик. Что использовать на практике Рекомендация. команда заранее определяет «рамки бренда» (какие темы и форматы шуток приемлемы, а какие нет) и процесс быстрого согласования (кто может одобрить публикацию без долгого цикла), чтобы не терять актуальность момента, но и не публиковать непроверенные или рискованные высказывания. Подводные камни Риск. публиковать реакцию на тренд без проверки фактов
approval-workflowcontent-formats
MiddleData Analyst > Метрики и эксперименты > A/B-тесты Короткий ответ Пользователей группируют по когорте — дате или неделе первого попадания в эксперимент — и сравнивают метрику (например, недельное удержание) для каждой когорты отдельно по группам A и B, что позволяет увидеть, устойчив ли эффект по времени и не искажён ли он смешиванием пользователей с разным 'стажем' в тесте. Как это работает подробнее Как это работает: без когортной разбивки агрегированная метрика на конкретную календарную дату смешивает пользователей, которые в тесте неделю, и тех, кто в тесте всего день — это может маскировать или искусственно усиливать эффект (например, из-за novelty effect у новых когорт). Ожидаемый результат: таблица retention-кривых по когортам и группам; sanity check — для каждой когорты retention должен монотонно не возрастать с ростом day_since_entry (это нормальное поведение удержания). Пример кода Что использовать на практике На практике: когортный анализ особенно важен для метрик удержания и LTV, где релевантен 'возраст' пользователя в продукте/тесте, а не календа
ab-testingcohort-analysis
MiddleDevOps Engineer > Контейнеры и доставка > Dockerfile и сборка Короткий ответ При ENTRYPOINT ["executable"] в exec-форме и CMD ["--default-flag"], docker run image без дополнительных аргументов выполнит executable --default-flag, а docker run image --other-flag заменит именно CMD, выполнив executable --other-flag, не трогая сам ENTRYPOINT. Как это работает подробнее Docker собирает финальную команду контейнера как конкатенацию массива ENTRYPOINT и массива аргументов — либо CMD из образа (если явных аргументов в docker run нет), либо аргументов, переданных после имени образа в docker run (если они есть, они целиком заменяют CMD, но не ENTRYPOINT). Это работает предсказуемо только при exec-форме (["..."]) обоих инструкций — shell-форма ломает эту механику, так как оборачивает команду в /bin/sh -c. Пример кода Что использовать на практике Практика. такой паттерн используют для образов-утилит, где ENTRYPOINT фиксирует саму программу, а CMD задаёт "разумные значения по умолчанию" флагов, которые пользователь образа может переопределить без необходимости переопределять весь EN
container-imagesdocker
MiddleSMM Manager > Общее > SMM-аналитика и метрики Короткий ответ Нужно привести метрики разных площадок к общим, сопоставимым категориям (охват, вовлечённость, трафик на сайт, конверсии), собрать их в единую таблицу/дашборд с разбивкой по площадкам и периоду, и явно обозначить, какие метрики не сопоставимы напрямую между площадками из-за разных методик подсчёта. Как это работает подробнее данные выгружаются из каждой нативной статистики или API площадки, нормализуются (одинаковые периоды, единицы, названия метрик) и сводятся в общую структуру — например, через Google Sheets с отдельными вкладками-источниками и сводным листом с итоговыми цифрами. Сводный лист отчёта: таблица со строками «Instagram», «VK», «Telegram», «TikTok» и столбцами «Охват», «Вовлечённость», «Клики на сайт (UTM)», «Заявки». Проверка: сумма «Клики на сайт» по всем площадкам из отчёта должна совпадать с суммой переходов по соответствующим UTM-источникам в веб-аналитике за тот же период. Что использовать на практике Практический подход. при сведении важно не складывать механически несопоста
metricsreporting
SeniorData Analyst > SQL и данные > Статистика и теория вероятностей Короткий ответ На масштабе компании с десятками одновременных тестов и множеством проверяемых метрик в каждом стоит применять централизованную поправку на множественные сравнения (например, Benjamini-Hochberg) на уровне всего портфеля значимых находок за период, а не оставлять каждую команду контролировать свой альфа независимо — единого стандарта здесь нет, выбор зависит от того, что организация готова считать "семьёй" гипотез для контроля. Как это работает подробнее если каждая из множества команд независимо тестирует на уровне альфа=0.05, ожидаемое число ложных "успешных" экспериментов в масштабе компании растёт линейно с числом тестов — при 200 тестах в квартал без реального эффекта в среднем около 10 из них покажут случайную значимость. Поправка на FDR на уровне компании (а не отдельной команды) контролирует долю таких ложных находок среди всех объявленных "успешными" экспериментов. Sanity check: сравнить число экспериментов, признанных "успешными" до и после поправки — заметное сокращение числа значимых
benjamini-hochbergexperimentation