Data Engineer

Контекст проєкту

Ми побудували acquisition-систему під Instagram-воронку: масово підписуємося на цільову аудиторію, щоб користувачі бачили сповіщення, заходили в профіль і рухались по воронці. Критична точка цієї системи — таргети (Instagram IDs).

Якщо таргети “брудні” (не те гео/мова, багато ботів, дублікати, старі або неактивні акаунти) — падає конверсія і ефективність, і масштабування стає нестабільним.

Тому ми будуємо якісний data-layer для таргетів: стандарти якості, автоматичний контроль партій, дедуп, versioning, сегментація, і поступовий перехід ключових процесів в in-house.

Як ми організовуємо команду

Ми розділяємо цю зону на дві ролі:

1) Data Engineer — data quality + пайплайни + storage + автоматизація

Твоя зона — зробити так, щоб дані були чисті, контрольовані, відтворювані і готові до масштабування.

2) Data Analyst — тести/конверсія/метрики

Аналітик буде постійно тестувати різні конфіги фільтрів і джерел, рахувати конверсію та давати тобі фідбек.

Кого ми шукаємо (Data Engineer — data quality & pipelines)

Сильний Data Engineer, який любить порядок у даних і вміє будувати системи, де:

• є quality rules,
• є автоматична перевірка партій,
• є історія: що купили → як відфільтрували → що отримали на виході,
• є контроль дублікатів / freshness / сегментів,
• і все це працює стабільно на мільйонних обсягах.

Це роль не про “порахувати конверсію” (це буде робити аналітик), а про інженерну якість і масштабованість data-процесів.

Технічні навички (must have)

• Python: скрипти, ETL, обробка великих файлів/партій, автоматизація QA.
• SQL: витяги, перевірки, контроль якості, побудова таблиць/мартів.
• Досвід із data workflows: дедуп, versioning, “single source of truth”, інкременти, контроль помилок.
• Розуміння storage/архітектури під великі обсяги (з файлів → до Postgres/BigQuery або іншого DWH).
• Практичний підхід до data cleaning: правила, пороги, red flags, автоматичні “pass/fail”.

Плюсами будуть:

• досвід з парсингом
• будь-який досвід з ML/AI для класифікації/фільтрації (бот/не бот, мова, підозрілі патерни).

Soft skills

• Самостійність: “прийшов → розібрався → стандартизував → автоматизував → задеплоїв → підтримує”.
• Уміння працювати в хаосі і швидко робити з нього систему.
• Вміння комунікувати з аналітиком: брати результати тестів і переводити їх у зміни правил/пайплайнів.

За що ти будеш відповідати (end-to-end, але в межах Data Engineering)

1) Data quality стандарт і правила

• Зафіксувати, що таке якісний таргет: must-have / nice-to-have / red flags.

• Описати acceptance criteria для партій і фільтрів.

  Результат: у нас є один стандарт, який можна версіонувати й повторювати.

2) Автоматичний QA партій

• Скрипти/процедури: дедуп, freshness, базові сигнали бот-ності, перевірки формату.

• Автоматичне рішення “прийняти/відхилити/попросити заміну”.

  Результат: ми не “віримо постачальнику”, ми перевіряємо і контролюємо.

3) Storage + versioning + історія результатів

• Побудувати структуру: source → batch → filter_version → output сегменти.

• Зберігати історію, щоб можна було швидко відповісти: “чому зараз гірше / що змінилось”.

  Результат: дані не губляться, не дублюються, і зрозуміло, що дає результат.

4) Ключові фільтри та “змінні” якості аудиторії

• Визначати ключові фільтри, які реально впливають на якість аудиторії (гео/мова/активність/патерни/сигнали бот-ності тощо).
• Формалізувати “змінні” (features/signals) і правила, за якими будується фільтрація: пороги, пріоритети, комбінації правил, винятки.

• Підтримувати ці правила як версіоновану систему: оновлення → перевірка → деплой.

  Результат: фільтрація працює не “на око”, а як керована система правил, яку можна швидко змінювати і масштабувати.

5) Перехід критичних частин в in-house

• Там, де це дає контроль якості / швидкість / економіку: фільтрація, нормалізація, дедуп, частково парсинг.

  Результат: менше залежності від підрядників, більше стабільності.

Як виглядає взаємодія з Data Analyst (щоб було прозоро)

Аналітик:

• запускає A/B тести фільтрів/джерел,
• рахує конверсію і дає висновки,
• формує рекомендації “який фільтр/джерело краще”.

Ти:

• береш ці рекомендації,
• переводиш у зміни правил/пайплайнів/QA,
• робиш rollout/rollback,
• і забезпечуєш стабільність.

Якщо ти читаєш це і думаєш: “Нарешті нормальна задача — навести порядок у даних, зробити стандарти й автоматичний контроль, і побудувати систему, яка витримує масштаб” — пиши. Ми не шукаємо “спокійного підтримувальника існуючого процесу”. Ми будуємо data-фундамент, який прямо впливає на масштаб і гроші.