Есть метрики, которые принципиально живут без пользователя.

- Выручка за день.
- Количество заказов.
- Средний чек.
- Сумма транзакций по категориям.

Это агрегаты "по событиям".
Им не важно, кто именно сделал действие - важно, что действие произошло.

Бизнес часто живёт именно на этом уровне, и на старте ему кажется, что этого достаточно.

Проблемы с клиентскими метриками возникают в тот момент, когда появляется аналитика "на повторы".

- Повторные покупки.
- Возвраты клиентов.
- LTV.
- Retention.
- Конверсия по шагам воронки.

Все эти метрики - не про события.
Они про людей.

А без user_id "человек" в данных перестаёт существовать.

И когда user_id отсутствует, бизнес начинает выкручиваться.

Вместо user_id появляются:

• номер телефона

• email

• cookie

• device_id

• хэш паспорта

• комбинации из "телефон + дата рождения + регион"

Это не плохие решения.
Это компромиссы.

Каждый такой "заменитель пользователя" решает одну задачу и ломает другую.

Телефон:
- отлично для CRM
- плохо для веба и офлайна

Cookie:
- хорошо для сессий
- бесполезно для долгой аналитики

Email:
- стабилен
- но есть одноразовые email-ы

Device_id:
- у клиента может быть несколько устройств
- может жить до переустановки приложения
- может стоять запрет на трекинг

В итоге бизнес не считает "пользователей".
Он считает версии пользователей.

Из-за этого появляются странные эффекты:

• пользователей стало больше, но денег больше не стало

• retention упал, но продажи выросли

• конверсия пляшет, а поведение вроде то же

И это не всегда ошибка данных.
Это ограничение идентификации.

Важно понимать:
отсутствие user_id - это не техническая проблема, а продуктовая.

Она говорит о том, как система была спроектирована изначально:

• думали ли о пользователе как о сущности

• или думали только о событиях и операциях

Поэтому аналитика без user_id возможна.
Но она всегда:

• менее точная

• более приближённая

• и требует аккуратной интерпретации

Хуже всего - считать "пользовательские" метрики и делать вид, что всё ок.

Лучше честно сказать:

Мы считаем это так, потому что другого способа у нас нет

Данные могут существовать без user_id.
Запросы SQL может работать без user_id.
Отчёты можно построить без user_id.

Но аналитика поведения - нет.

НО... Главный НО...

Наличие user_id не спасет вас от того, что клиента "на входе" не идентифицировали и завели ему новый идентификатор. Либо при объединении клиентских баз у вас не задвоится один и тот же клиент.

Это повседневные процессы бизнеса. И уникальность клиента зависит от культуры ведения данных в базе, от технических процессов и бизнес процессов.

Для дедупликации клиентских записей существуют системы класса CDI (Customer Data Integration). Такие системы помогают идентифицировать клиента и вести его мастер карточку.

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!

💡 Что такое база данных и зачем нужны таблицы?

Представьте себе огромную библиотеку, полную полок с книгами. Чтобы быстро найти нужную книгу, вы используете каталог, который помогает организовать книги по авторам, жанрам или годам издания. Примерно так же устроены и базы данных — системы структурированного хранения информации, позволяющие эффективно искать, обновлять и анализировать данные.
(Позвольте мне далее по тексту использовать сокращённое наименование базы данных — БД.)

На первых этапах знакомства с базами данных у меня сформировалось предвзятое мнение, что все базы данных непременно представляют собой таблицы с рядами записей. Однако реальность гораздо разнообразнее, и далее Мы рассмотрим какие вообще виды баз данных существуют.
(такое представление имеет место быть, так-как самые часто встречающиеся базы данных соответствуют именно такому описанию)

📊 Виды БД (за 4-е место в топе выдаем шоколадку 😄)
(Прошу Вас относится к этому рейтингу как к ориентировочному показателю, иллюстрирующему общую картину популярности различных типов баз данных на сегодняшний день. Приведённые проценты отображают частоту использования каждой категории технологий среди разработчиков и компаний.)

• Реляционные БД (~ 70 %) 🏆

• Документные БД (~ 20%) 🥈

• Ключ-значение БД (~ 10-15%) 🥉

• Облачные БД (~ 10%) 🍫

• Графовые БД (~ 5-7%)

• Колоночные БД (~ 3-5%)

• Файловые БД (~ 2-3%)

• Объектно-ориентированные БД (< 1%)

❗️❗️ Ввиду того, что данная статья посвящена именно реляционным базам данных, основное внимание сосредоточено на этом типе. В последующих статьях мы также рассмотрим и другие виды БД.

Мы можем заметить, что наиболее распространенным видом БД являются реляционные и это не просто так !

🌟 Почему реляционные базы настолько популярны?

• Зрелость модели - реляционная модель, предложенная в 20-м веке ученым Эдгаром Коддом успела пройти проверку временем

• Универсальность и совместимость технологий - существует более 160 реляционных СУБД, поддерживающих общие стандарты и язык запросов SQL. Это в значительной степени облегчает миграцию данных и совместимость решений

• Поддержка транзакций - реляционные БД предлагают мощный функционал поддержки транзакций, обеспечивающий сохранение целостности данных (что является ключевым параметром многих решений)

• Поддержка большинства корпоративных систем (ERP, CRM, BI) - данные системы исторически проектировались под реляционную модель, поэтому в настоящее время большинство крупных и средний предприятий имеют готовые решения, построенные на базе реляционных моделей.

Простота проектирования схем и стандартизация подходов, делают выбор реляционных моделей хранения данных более предпочтительным в отношении других подходов.
Но, реляционные БД это не "серебряная пуля", решающая все проблемы и не имеющая недостатков.

😱 Проблемы реляционных БД

• Масштабирование - реляционные БД обладают определенными трудностями при горизонтальном масштабировании (чаще всего по причине, что каждая отдельная БД размещена на физическом сервере с ограниченными ресурсами, что значительно усложняет задачу разделения нагрузки)

• Поддержка ACID-транзакций - не смотря на то, что поддержка транзакций является преимуществом реляционных БД, одновременно с этим она может быть и ее недостатком. Поддержание таких свойств, как: атомарность (Atomicity), согласованность (Consistency), изолированность (Isolation), надежность (Durability) может потребовать значительные ресурсы, что в свою очередь повлияет на скорость и производительность системы.

• Проблема самой концепции - данные в реляционной БД хранятся разнесенные по таблицам (часто стараются хранить нормализованные данные), со временем увеличивается объемы таблиц, усложняются JOIN- запросы (одна из функций языка SQL), что в свою очередь снижает производительность при работе с данными. (не смотря на наличие индексов)
  
  Перечисленные Выше проблемы (а это далеко не все, но, как мне кажется, одни из основных проблем) влияют на производительность системы и требуют поиска дорогих решений для обхода данных особенностей при использовании реляционных БД

Выше Мы уже упомянули, что основой реляционный БД являются таблицы.
Давайте посмотрим поближе на то, как выглядят таблицы в реляционной БД и что это такое

Рассмотрим пример таблицы на иллюстрации. Мы видим, что таблицы в реляционной БД имеют свою структуру, описание которой приведем ниже.

Структура таблицы

• Таблица (отношение) - основной элемент реляционной БД, представляет собой массив данных, состоящий из строк (записи) и столбцов (атрибуты)

• Атрибуты - свойства, определяющие характеристики каждой сущности. Каждому атрибуту соответствует определенный тип данных (числовой, формат даты, строковый).
  (Идентификатор, чаще всего, не приходит вместе с данными, а создается искусственно в момент создания записи в таблице)

• Записи (кортеж) - строка таблицы, которая содержит совокупность значений атрибутов.

• Мощность - количество записей в таблице (в нашей таблице мощность = 4)

• Размерность - количество атрибутов, описывающих характеристики сущности (в нашей таблице размерность = 4)

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

Давайте теперь рассмотрим то, как может выглядеть самая простая схема реляционной БД на примере нашей таблицы (Продукты) и двух новых таблиц. (Покупатели и Покупки).

Ранее мы отмечали, что в реляционной базе данных обычно имеется множество таблиц, каждая из которых описывает отдельную сущность. Все эти таблицы связаны между собой с помощью ключевых механизмов — первичных (PK) и внешних (FK) ключей.

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

Аналогично построена связь между таблицей «Покупки» и таблицей «Продукты». Таким образом, любая покупка может быть легко ассоциирована с соответствующим товаром.

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

Теперь перейдем непосредственно к основным типам связей между таблицами.

🔗 Типы связей

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

• Один-ко-многим - одна запись первой таблицы, связана с множеством записей второй таблицы. Самый распространенный тип связи на практике.

• Многие-ко-многим - множество записей первой таблицы, связаны с множеством записей второй таблицы. Так же достаточно распространенный тип связи, который на практике требует создание таблицы-посредника (связующая таблица).
  
  (Ниже приведены иллюстрации к видам связи. Прошу Вас учитывать, что примеры гипотетические)

Завершая рассказ об основах реляционных баз данных, особое внимание уделим важной теме — первичным (PK) и внешним (FK) ключам.

Хотя формально использование ключей необязательно, практически их отсутствие нарушает фундаментальные принципы проектирования реляционных БД. Ключи позволяют точно идентифицировать записи, устанавливать связи между таблицами и поддерживать целостность данных.

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

🔑 Рассмотрим виды ключей

Первичный ключ (Primary Key)
Первичный ключ — это атрибут или набор атрибутов, однозначно идентифицирующих каждую запись в таблице. Основная характеристика первичного ключа — его уникальность: каждая запись обладает уникальным значением.

При создании первичного ключа накладываются следующие ограничения:

• Уникальность (каждая запись имеет уникальное значение ключа)

• Обязательность заполнения (атрибут не может быть пустым)

• Постоянство (значение ключа должно быть постоянным)

Первичные ключи удобно классифицировать по двум критериям:

Способ формирования

• Естественный PK - атрибут, присутствующий в самих данных и обладающий уникальностью (например ИНН гражданина, серийный номер товара)

• Искусственный PK (суррогатный ) - специально созданный атрибут, формируемый системой автоматически. (самый простой способ - автоинкрементируемое целое число)

Количество элементов

• Простой PK - включает единственный атрибут.

• Составной PK - формируется из нескольких атрибутов, с целью достижения уникальности.

Важно отметить следующее, что естественный или искусственные ключи могут быть как простыми, так и составными.

Внешний ключ (Foreign Key)
Внешний ключ — это атрибут или набор атрибутов, ссылающийся на значение первичного ключа другой таблицы. Благодаря внешним ключам обеспечивается согласованность и целостностью данных.

Особенности внешнего ключа

• Допускает пустые значения, если связь между таблицами необязательна

• Проверяет существование соответствующей записи в родительской таблице

• Гарантирует соблюдение целостности данных (любая запись ссылается на реально существующую запись в другой таблице)

• Определяет иерархические или ассоциативные связи между таблицами. (тут мы имеем ввиду ранее рассмотренные связи один-к-одному, один-ко-многим, многие-ко-многим)

Итак, мы завершили знакомство с основами реляционных баз данных. Рассмотрели базовые понятия, структуру таблиц, типы связей и способы организации ключей.

❤️ Спасибо за Ваше внимание! Надеюсь, эта статья помогла разобраться с ключевыми принципами реляционных баз данных.

📱 Оставайтесь с нами, чтобы получать свежие публикации и полезную информацию по системному анализу в нашей группе системного анализа

Хорошего дня, друзья!

А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!

Бизнес редко приходит с чётким запросом.
Не потому что он глупый или ленивый.
А потому что бизнес живёт ощущениями, а не формулами.

Продажи "просели".
Конверсия "стала хуже".
Клиенты "ведут себя странно".

Это язык боли, а не требований.

И тут аналитик хочет обезопасить себя со всех сторон:
- написать запрос
- вытащить все данные
- построить отчёт "на всякий случай"
- показать цифры и сказать: "Вот"

Но в реальности это почти всегда заканчивается одинаково:
- "А это не совсем то"
- "А можно по-другому?"
- "А мы вообще не это имели в виду"

Когда бизнес не знает, что ему нужно,
аналитик не исполнитель,
аналитик - переводчик.

Ты начинаешь переводить бизнесовые ощущения в конкретные показатели, и смотреть как эти показатели подтверждают/опровергают эти ощущения. Ты переводишь эмоции в конкретные метрики. Подсознательное ощущение "что-то не так", ты переводишь в конкретные вопросы к данным.

И вот на этом этапе SQL становится не просто инструментом, а следствием мышления.

Очень часто проблема не в том, что запрос неправильный.
А в том, что вопроса не существовало.

Например:

• "Продажи упали" - относительно чего?

• "Конверсия плохая" - на каком этапе?

• "Клиенты уходят" - кто именно и когда?

Пока бизнес не ответил хотя бы на это - любой запрос будет случайным.
Или аналитик с приличным бэкграундом, задаст их сам себе, задаст эти вопросы данным и получит развернутый ответ, чтобы у бизнеса были аргументированные показатели.

И это самый важный навык аналитика. Аналитик не должен просто писать сложные JOIN-ы, он должен уметь задавать вопросы так, чтобы:
- стало понятно, что именно ищем
- появилось ощущение направления
- сузилось пространство неопределенности.

И да - бывает, что бизнес так и не может сформулировать запрос.

Тогда аналитик делает не отчёт, а гипотезу.

Я предполагаю, что проблема может быть здесь.
Давайте проверим это.

Это нормальная практика.
Гораздо честнее, чем молча строить отчёт "на всякий случай".

Самое важное:
если бизнес не знает, что ему нужно - это не ошибка бизнеса.

Это точка, где аналитика становится ценностью!

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

Рассмотрим задачу.

Есть таблица заказов. Нужно:

1. Взять только оплаченные заказы

2. Посчитать сумму заказов по пользователям

3. Оставить пользователей, у которых сумма больше 10 000

4. Отсортировать по убыванию суммы

Как это выглядит в SQL

SELECT

user_id,

SUM(amount) AS total_amount

FROM orders

WHERE status = 'paid'

GROUP BY user_id

HAVING SUM(amount) > 10000

ORDER BY total_amount DESC;

Что происходит на самом деле?

Хотя запрос написан сверху вниз, выполняется он иначе:

1. FROM — база берёт таблицу orders

2. WHERE — отфильтровывает только status = 'paid'

3. GROUP BY — группирует строки по user_id

4. SUM(amount) — считает сумму внутри каждой группы

5. HAVING — отбрасывает группы с суммой ≤ 10 000

6. SELECT — формирует финальные колонки

7. ORDER BY — сортирует результат

SQL не идёт шаг за шагом как сценарий. Для него каждый запрос - это единый слепок результата

Ты не "живешь" внутри процесса, ты его декларируешь.

Теперь тот же самый запрос в Python (pandas)

Чтобы не увеличивать объем строк с подключением к БД, сделаем так, что наши данные мы читаем из CSV файла

1. Ты загружаешь данные. Ты их уже видишь. Они лежат в память, у них есть текущее состояние.

import pandas as pd

df = pd.read_csv('orders.csv')

2. Фильтрация

paid_orders = df[df['status'] == 'paid']

paid_orders.head()

Здесь отфильтровали данные, можно посмотреть, что получилось, можно вернуться назад.
Это состояние сохранилось.

3. Группировка и агрегация

grouped = (

paid_orders

.groupby('user_id')['amount']

.sum()

.reset_index(name='total_amount')

)

grouped.head()

Ты видишь промежуточный результат:

• пользователей

• их суммы

• можешь проверить аномалии

4. Фильтр по агрегату

filtered = grouped[grouped['total_amount'] > 10000]

filtered.head()

5. Сортировка

result = filtered.sort_values('total_amount', ascending=False)

result

Ключевая разница

SQL

- нет "текущего состояния"
- каждый запрос - это новый расчет
- описываем, что хотим получить
- оптимизатор решает как

Python

- данные живут в памяти
- каждый шаг меняет состояние
- на каждом шаге можно остановиться, посмотреть, вернуться, ветвить логику

На практике аналитик:
- думает как в Python
- реализует как в SQL
- и постоянно переключается между этими моделями

Получается, что SQL и Python - это два разных способа мышления.
SQL говорит нам - вот результат
Python - вот процесс.

Python - это процедурный подход.
Аналитик говорит КАК делать:
- возьми данные
- отфильтруй
- посчитай
- отсортируй
- покажи результат
Здесь происходить управление процессом: мы ведем данные по шагам

SQL - декларативный подход.
Аналитик не говорит КАК делать, он говорит, что хочет получить.

В разбираемом примере мы говори:

Хочу видеть сумму заказов по пользователям,
только оплаченные,
только больше 10 000

Для SQL есть входные данные, правила отбора, финальный результат.
SQL не живет во времени, он живет в описании результата

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!