🌀 Умение просто объяснять сложное

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

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

🍪🍪 У всего есть своя аудитория.
Я знаю, что в канале собрались ребята очень разного уровня: кто-то уже работает в индустрии и глубоко копает в ресёрчи или A/B-тесты, кто-то только начинает свой путь в аналитике, а кто-то вообще пока просто наблюдает со стороны. И это классно, так как разные перспективы помогают смотреть на одни и те же вещи под разными углами. Поэтому я стараюсь чередовать форматы: где-то глубже, где-то проще, чтобы каждому было комфортно и интересно.

👀 И да, интересное наблюдение. Иногда вижу подпись: «Простыми словами о сложном».

Сразу вопрос: а что это вообще значит? Упростить НЕ РАВНО донести мысль 🧠

На самом деле этот навык про понимание своей аудитории и способности говорить на её языке.

🥳 Умение аналитика не только в том, чтобы посчитать метрику или построить модель. Главное, что ожидается, это упаковать результат так, чтобы он легко ложился в голову любого человека. Где-то объяснить на пальцах, где-то достать формулы, но всегда через призму главного вопроса: зачем это нужно?

Работаем переводчиками, а чо, плотити еще сверху, так как мы считаем эскуельки и рисуем графички 💰

😮 Очень сильно помогает совет: объясняй так, будто разговариваешь с человеком, который вообще не разбирается в домене, сложных методах и так далее (например, человек из бизнеса, который отвечает за коммерческий департамент). Представь, что перед тобой первый попавшийся прохожий. Если он поймёт, значит, ты действительно донёс мысль. В его голове могут появляться самые разные вопросы, и твоя задача будет заключаться в том, чтобы выстроить понятное повествование. Иначе весь смысл разговора теряется.

А вы что думаете? Ставьте 🐳, пишите комментарии! А я пойду я готовить следующий пост 🤟

А вы знали, что аналитики пишут на R?

Я то знаю...

Хочу порекомендовать вам канал @stats_for_science

Автор канала: Лена, продуктовый аналитик Литрес 📚, ранее работала в X5 Tech 💚 , ранее занималась наукой. В своих постах она сравнивает научные и бизнесовые подходы.

😎 Выделил для себя несколько, которые мне откликаются

🟢 Про поправки на множественное тестирование. Лена написала большой лонгрид на эту тему. Актуально при проверке нескольких гипотез (например, когда принимаем решение по нескольким целевым метрикам / по > 2 группам).

🟢 Что самое сложное в работе продуктовым аналитиком. Здесь говорится о работе с метриками и общие размышления автора + в комментах написал свое мнение по поводу этого поста.

🟢 Виды пределов погрешностей. В мире мы работаем со случайными величинами, зачастую мы работаем с интервальными оценками. В этом посте как раз про это. От боксплотов до доверительных интервалов, годное чтиво!

+ Я очень люблю мемы про статистику (скажите мне, пожалуйста, что это не профдеформация).

🔵 про p-value в ящике
🔵 слишком большие запросы

Да начнется холивар по поводу R, не Python единым! 🖥🐍

P.S: Идеи, которые предлагаются в канале можно переложить на Python, так как главное — это понимать идею, а языки между собой очень сильно похожи в плане синтаксиса. Питонистам актуально!

Подписывайтесь на @stats_for_science, чтобы разбираться в статистике еще лучше!

🙊 Прохожу значит я курс по SQL в своей магистратуре и тут вижу интересный кейс, решил поделиться с вами. Если честно, ни разу не видел в продовых решениях ни в аналитических таблицах CHAR, ни в хранении логов с различных сервисов, но возможно пригодиться или кто-то использовал (делитесь в комментах) 🔽

DROP TABLE IF EXISTS zasql_python_table;

create table zasql_python_table (
value1 CHAR(5),
value2 VARCHAR(5)
);

INSERT INTO zasql_python_table VALUES ('abcd', 'abcd');

SELECT CONCAT(value1, value2) as result_1_2, CONCAT(value2, value1) as result_2_1
from zasql_python_table;

🗣 Результат будет следующий 🙃

| result_1_2 | result_2_1 |
|-------------|-----------|
| abcd abcd   | abcdabcd  |

Видите пробел между abcd и abcd? Это как раз CHAR, который дополнил строку до фиксированной длины.

Ну или после этого сообщения начнуть кошмарить на собесах по SQL... 👩‍💻

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

🐸 Если очень грубо:

🥳 CHAR(n) используется для хранения строк фиксированной длины.
Если строка короче, чем n, она автоматически дополняется пробелами до нужной длины. При выводе эти пробелы обычно сохраняются (зависит от СУБД). Подходит, когда все значения примерно одинаковой длины (например, коды, индексы).

🥳 VARCHAR(n) хранит строки переменной длины.
Если строка короче n, то пустоты не добавляются, сохраняются только фактические символы. Если строка длиннее n, она будет обрезана до заданного размера. Подходит, когда длина строк сильно варьируется.

Например, в одной статье говорится следующее:

For instance, CHAR often outperforms VARCHAR in scenarios with consistently sized data due to its fixed length, resulting in faster index lookups—up to 20% quicker on average. Conversely, VARCHAR excels in space efficiency for variable-length data, making it an ideal choice for dynamic datasets. The decision between CHAR vs VARCHAR is not just about storage but also about optimizing your database’s speed and efficiency.

⬆️ CHAR часто превосходит VARCHAR в сценариях с данными одинакового размера благодаря фиксированной длине, что приводит к ускорению поиска по индексу — в среднем на 20 %.

Или в другой:

The amount of work the database engine has to perform to store and retrieve VARCHAR columns is more than it takes for a CHAR column. Every time a VARCHAR column is retrieved, the Database engine has to use the length information stored with the data to retrieve a VARCHAR column value. Using this length information takes extra CPU cycles. Whereas a CHAR column and its fixed length allow SQL Server to more easily chunk through CHAR column based on their fixed-length column definitions.

⬆️ Для хранения и извлечения VARCHAR столбцов ядру базы данных требуется больше ресурсов, чем для CHAR столбцов. При каждом извлечении VARCHAR столбца ядру базы данных приходится использовать информацию о длине, хранящуюся вместе с данными, чтобы извлечь значение столбца VARCHAR. Использование этой информации о длине требует дополнительных вычислительных ресурсов.

Авторы предлагают использовать CHAR для фиксированной длины и в этом случае скорость будет выше, но я опять скажу, что пока что ни разу не видел такие витрины, где бы использовался этот тип данных. Может вы сможете привести РЕАЛЬНЫЙ кейс, где бы это использовали.

Понравился пост? Ставьте 🐳, если понравился пост, пишите комментарии! Может вы использовали CHAR и это помогло? Нужны кейсы!

@zasql_python